On Thu, Apr 24, 2008 at 2:51 PM, Santi Béjar <sbejar@xxxxxxxxx> wrote: > On Wed, Apr 23, 2008 at 8:17 AM, Uwe Kleine-König > > <Uwe.Kleine-Koenig@xxxxxxxx> wrote: > > Hello Santi, > > > > > > Santi Béjar wrote: > > > On Tue, Apr 22, 2008 at 11:12 AM, Uwe Kleine-König > > > <Uwe.Kleine-Koenig@xxxxxxxx> wrote: > > > > Hello, > > > > > > > > There is a thread on the linux-arm-kernel ML that discusses handling of > > > > merge conflicts with git.[1] > > > > > > > > I played around a bit with that and wondered about a few things: > > > > > > > > ukleinek@zentaur:~/gsrc/linux-2.6$ git checkout -b test adf6d34e460387ee3e8f1e1875d > > > > Switched to a new branch "test" > > > > > > > > ukleinek@zentaur:~/gsrc/linux-2.6$ git merge v2.6.25 > > > > Auto-merged MAINTAINERS > > > > CONFLICT (delete/modify): drivers/leds/leds-tosa.c deleted in HEAD and modified in v2.6.25. Version v2.6.25 of drivers/leds/leds-tosa.c left in tree. > > > > Auto-merged drivers/serial/imx.c > > > > Automatic merge failed; fix conflicts and then commit the result. > > > > > > > > Now "git diff --merge" shows: > > > > > > > > diff --cc drivers/leds/leds-tosa.c > > > > index 7ebecc4,0000000..9e0a188 > > > > ... > > > > > > > > Shouldn't that better be reversed, i.e. 9e0a188..7ebecc4,0000000? > > > > > > It compares the versions in conflict with the version in the working copy. > > > > I have not checked in the source code, but the output of > > > > strace -f -e open git diff --merge 2>&1 >/dev/null | grep leds-tosa > > > > seems to contradict that (i.e. there is no output). > > The version in the working copy should be 7ebecc4, so there is no need > to open it as it is in the index (but maybe I'm wrong). > > > > > > 7ebecc4 = v2.6.25:drivers/leds/leds-tosa.c > > 9e0a188 = $(git merge-base test v2.6.25):drivers/leds/leds-tosa.c > > > > (Ah, I just see, that's another hint that diff --merge doesn't look in > > the working copy. The wc has 7ebecc4 which is in the LHS together with > > 000000 (i.e. the deleted file from HEAD). > > > > Maybe the combined diff format cannot have more than one rev on the RHS? > > > > > > FWIU --merge is an option for git-rev-list (and alike, git log, > gitk...). I don't know its meaning in this case. It shoud be juts: > > $git diff > > that currently says in this case: > > $ git diff > * Unmerged path file1 > > In this case: > > echo a >file1 && > git add file1 && > git commit -m initial && > git checkout -b a1 master && > git rm file1 && > git commit -m a && > git checkout -b b1 master && > echo b> file1 && > git add file1 && > git commit -m b1 && > git checkout a1 && > git merge b1 > > The merge output is: > Merging HEAD with b1 > Merging: > 3231a8a a > ace6b2d b1 > found 1 common ancestor(s): > f43806f initial > CONFLICT (delete/modify): file1 deleted in HEAD and modified in b1. > Version b1 of file1 left in tree. > > Automatic merge failed; fix conflicts and then commit the result. > > $ git ls-files -s > 100644 78981922613b2afb6025042ff6bd878ac1994e85 1 file1 > 100644 61780798228d17af2d34fce4cfbdf35556832472 3 file1 > > $ git diff [-1 | -2 | -3] > * Unmerged path file1 Actually only: git diff git diff -2 git diff -3 for: $ git diff -1 * Unmerged path file1 diff --git a/file1 b/file1 index 7898192..c9c6af7 100644 --- a/file1 +++ b/file1 @@ -1 +1 @@ -a +b1 but "-2" and "-3" do the same for different reasons -2) theres is no "2" in the index -3) is equal to the wc file1 so both output the same: * Unmerged path file1 and I still think "git diff" has to output something else than "*Unmerged path file1". > > $ git diff --merge > diff --cc file1 > index 6178079,0000000..7898192 > mode 100644,000000..100644 > --- a/file1 > +++ b/file1 > @@@ -1,1 -1,0 +1,1 @@@ > - b > ++a > > that does not make sense. > > Maybe something as? > > $ git diff > diff --cc file1 > index 0000000,6178079..0000000 > mode 000000,100644..0000000 > --- /dev/null > +++ b/file1 > > But I don't really know what to expect in this case. > > Santi > -- 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
