On Wed, 28 Nov 2007 12:08:40 -0800
Junio C Hamano <gitster@xxxxxxxxx> wrote:
> You can still do that by hand, by doing something
like:
>
> $ 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
