From: Carl Worth <cworth@cworth.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] git-merge: preserve and merge local changes when doing fast forward
Date: Wed, 29 Nov 2006 23:32:42 -0800 [thread overview]
Message-ID: <87psb5tmn9.wl%cworth@cworth.org> (raw)
In-Reply-To: <7v1wnlmyba.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]
On Wed, 29 Nov 2006 19:02:33 -0800, Junio C Hamano wrote:
> The idea and the logic are identical to what "checkout -m" does
> when switching the branches. Instead of refusing the two-way
> merge, perform the three-way merge between the old head, the
> working tree and the new head, and leave the (potentially
> conflicted) merge result in the working tree.
This looks very appealing to me. I know I've often been frustrated
when git refuses to fast-forward just because I have dirty state, (and
stashing the diff manually into a patch file, then re-applying it
after fast forward is really annoying---getting work done in spite of
the tool and not because of it).
> * I am not sure if this is worth doing in general; it can leave
> a huge mess if the conflict with the merge and the local
> change is too extensive and does not give a good way to
> recover from it,
As I said above it seems very reasonable to me. As for the problem you
mention here, isn't "no good way to recover from it" the real problem,
and not this merge possibility? And is there enough information in the
index file such that one could implement a way to recover from this?
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2006-11-30 7:33 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-30 3:02 [PATCH] git-merge: preserve and merge local changes when doing fast forward Junio C Hamano
2006-11-30 7:32 ` Carl Worth [this message]
2006-11-30 10:32 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87psb5tmn9.wl%cworth@cworth.org \
--to=cworth@cworth.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).