thanks! and a tiny comment

[Yaroslav Halchenko]

Sorry in advance for a lengthy (and may be pointless) reply 
> I am not sure it's possible. For one thing, after a merge, the two
> parent commits are identical: they have been merged, not one has
> been merged into the other.
not sure... direction of merge does matter ;-) merging A into B doesn't
imply that B gets any changes from A.

> So even if you 'merge feature A into
> main', after the merge it's not really possible to identify which of
> the two parents was 'main'. At least not by Git.
At least not with existing git user-friendly part of the interface I
would say. By tracking each branch history you (or some tool) can easily
figure out what branch each parent came from.
for instance in gitk you can figure that out since it lists you branches
where commit belongs to
another obvious possible way could be if git show-branch could show both
the name and sha1 for the commit (now it is showing one or the other).
For now I could use silly script like

refs=`git show | grep '^Merge' | sed -e 's,Merge: ,,' -e 's,\.,,'`; for ref in $refs; do echo -n "ref ";paste <(git show-branch --sha1-nabanch) | grep "$ref" | sed -e 's,.*\(\[.*\]\).*,\1,g'; done

to figure out each branch for the parent... but probably I just
misunderstood your point

> This is an issue I am taking to the git mailing list now:
>   http://marc.info/?l=git&m=119315454830638&w=2
> > Another negative side-effect that the branch would continue
> > officially be known as merged from the original branch supplied
> > the patch. Although I do not foresee any use case when we would
> > need to merge that branch again, it is somewhat to keep in mind
> > (or a log ;-))
> You can just merge the branch again, I think.
as linus pointed out it would result simply in fast forward and no
changes actually be propagated.
,---
| And that means that while you can certainly undo the *data* that the merge
| brought in, git will always know that you already merged up that branch.
| Which means that if you later decide that you *do* want to do the merge
| after all, you now really cannot - trying to merge the branch later on
| will just be a fast-forward, and you'll never get the actual changes from
| that merge (since git knows you already have them!).
`---
He just confirms to me the lack of 'unmerge' relationship in git, which
(in my wild thoughts) should be similar to merge, only with opposite
effect 

1. it  should remove the changes brought in by the merge (or
a retrospectively consecutive list of merges from the specified branch).

2. provide 'Unmerge' relationship and point out to the latest commit
from merged branch which remains merged into current branch (or common
ancestor if any if all merges were unmerged).

Due to 2, consecutive merges into working branch can properly account
for the "common ancestor" if git merge cares about Unmerge relationship

Most probably it cannot work per my simple description since we could
have merged some differences which came from branched-out branch (from
the original merged branch), thus which have to remain in...
ufff... ;-)

> > > and changes the ID & dates of the commits.
> > heh heh -- I should try that first again before keep on talking...
> > don't see why IDs and dates should be changed... 
> Cherry-picking is not what you think it is. Cherry-picking takes
> a commit, applies the diff to the worktree, and if no conflicts are
> found, then creates a *new* commit (with new ID and date) with the
> same log message and author.
yep - that is in line with my understanding of cherry picking.
Cherry-picking though doesn't create any "Parent-like" relationship to
the working branch from the commit you cherry-picked . If you are
to cherry pick later on from the same branch you would need manually to
track the commit from which you cherry picked (unless branch commits got
squashed thus possibly destroying such opportunity at all)
-- 
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik