From: "Caleb Cushing" <xenoterracide@gmail.com>
To: "Jeff King" <peff@peff.net>
Cc: "Andreas Ericsson" <ae@op5.se>, git@vger.kernel.org
Subject: Re: more merge strategies : feature request
Date: Tue, 2 Dec 2008 09:28:41 -0500 [thread overview]
Message-ID: <81bfc67a0812020628l53c209a6yca5a619d211b6bfc@mail.gmail.com> (raw)
In-Reply-To: <20081202033013.GD6804@coredump.intra.peff.net>
>
> It's not clear to me exactly what you want. Let's say I have a file
> ....
I'm afraid I don't fully understand your example
lets say git merge foo bar
foo bar
1 1
2 8
3 3
4 4
5 5
6
7
lines 6 and 7 are new in foo line 2 has a conflict because the other
head has an 8, history wise because of an early merge the other
direction and fix, there was the 8 in foo and it was changed to a 2,
when I merge back it will overwrite the 8 with a 2. however I need
the 8 to be the 8 and the 2 to be the 2. but I want the 6 and 7 in
both.
conflict would create a conflict
such as
foo
1
<<<<<< bar
8
======
2
>>>>>> foo
3
4
5
6
7
no overwrite would result in file1 looking like this
1
8
3
4
5
6
7
> Did you want conflict markers in the resulting file? If so, what should
> the conflict markers look like, since there isn't actually a conflict?
if the the remote and local branches are not identical there's a
difference which should be able to result in a conflict. for all
purposes I'm not sure git couldn't just ignore the history of the
files and do a straight head to head merge. the steps you suggest
make it more complicated than it needs to be an if done post merge or
without merge will probably be need to be done again in a future merge
if merging back and forth
--
Caleb Cushing
next prev parent reply other threads:[~2008-12-02 14:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-29 16:48 more merge strategies : feature request Caleb Cushing
2008-12-01 9:18 ` Andreas Ericsson
2008-12-02 2:38 ` Caleb Cushing
2008-12-02 3:30 ` Jeff King
2008-12-02 14:28 ` Caleb Cushing [this message]
2008-12-02 15:30 ` Jeff King
2008-12-02 2:49 ` Leo Razoumov
2008-12-02 13:46 ` Caleb Cushing
2008-12-03 1:07 ` Leo Razoumov
2008-12-03 21:27 ` Nanako Shiraishi
2008-12-03 22:59 ` Caleb Cushing
2008-12-04 2:15 ` Junio C Hamano
2008-12-04 10:11 ` Nanako Shiraishi
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=81bfc67a0812020628l53c209a6yca5a619d211b6bfc@mail.gmail.com \
--to=xenoterracide@gmail.com \
--cc=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=peff@peff.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).