On Wed, 28 Nov 2007 12:08:40 -0800 Junio C Hamano <gitster@pobox.com> wrote:
> You can still do that by hand, by doing something
like:
Show 10 quoted lines
> > $ git merge --squash A > $ resolve only partly > $ git commit -m 'Prepare to merge A' > $ git reset --hard > $ git merge A > $ resolve the rest > $ git commit -m 'Fully merged A' > > For such a multi-step merge to make sense, the
change between B---M
> should make sense by itself for people who have to
read such a history
> later. Such a half-a-squash-merge may probably not
make sense by itself
> in most cases, so I suspect the above workflow would
not be useful in
> general. >
Junio, I resolved all the merges and then committed different files as groups to make it easy to cherry-pick after this merge. Does this "mess up" the merge info? What does the "git reset --hard" do after the commit (I'm assuming it throws away the non-resolved changes not committed)? But from my experience git wouldn't let me do the commit above it w/o first fixing the conflicts.
Am I mis-interpreting your example or are you saying that you think git would let me do the commit w/o resolving all conflicts?
Bill
____________________________________________________________________________________ Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs