On Sat, Sep 27, 2008 at 01:51:47AM +0200, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > Actually I think this would be ugly. MERGE_HEAD is about you can see > > what will be merged once you commit the merge, but once you include HEAD > > there, you can't easily check that. Maybe it's just me who sometimes > > have a look at that file myself directly... :-) > > The new semantic would be very simple. If there is no MERGE_HEAD, it > is an ordinary no-merge commit, and its only parent would be previous > (current) version of HEAD. If there is MERGE_HEAD it contains _all_ > parents in a merge commit, and only those heads which will be parents > (_reduced_ heads); if HEAD is symref, we modify given branch so it > points to newly created merge commit. > > Currently parents of merge commits are 'reduce(HEAD + MERGE_HEAD)' > in symbolic equation; I propose they would be simply 'MERGE_HEAD'. > then we set this branch to new commit Yes. Currently - after a merge conflict - you are able to check what heads caused were merged, which caused the conflict, but with this approach you would not be able to. I think this would be a step back...
Attachment:
pgpflfxr0Qca1.pgp
Description: PGP signature
