Tony Luck <[EMAIL PROTECTED]> wrote:
> > * Even if it does always choose the nicer choice of the two,
> >Tony was lucky (no pun intended). Rather, we were lucky that
> >Tony was observant. A careless merger may well have easily
> >missed this mismerge (from the human point of view).
> * Even if it does always choose the nicer choice of the two,
>Tony was lucky (no pun intended). Rather, we were lucky that
>Tony was observant. A careless merger may well have easily
>missed this mismerge (from the human point of view).
Actually I can't take credit here. This was
Linus Torvalds <[EMAIL PROTECTED]> writes:
> In fact, the case that git selected ("patch applied"), is not only the one
> that is very fundamentally the one git will always select in this kind of
> situation - in some respects is actually the nicer choice of the two.
While I appreciate the excuse
>I think git did the "right thing", it just happened to be the thing that
>Tony didn't want. Which makes it the "wrong thing", of course, but from a
>purely technical standpoint, I don't think there's anything really wrong
>with the merge.
On the plus side ... at least it wasn't a dumb user error
On Wed, 24 Aug 2005, Linus Torvalds wrote:
> Now, if the shared patch hadn't been a patch, but a shared _commit_, then
> the thing would have been unambiguous - the shared commit would have been
> the merge point, and the revert would have clearly undone that shared
> commit.
Actually, it was a s
On Wed, 24 Aug 2005, Linus Torvalds wrote:
>
> Basically, he had two branches, A and B, and both contained the same patch
> (but _not_ the same commit). One undid it, the other did not. There's no
> real way to say which one is "correct", and both cases clearly merge
> perfectly, so both outcom
On Wed, 24 Aug 2005, Junio C Hamano wrote:
>
> This does not have much to do with which common ancestor
> merge-base chooses. Sorry, I am not sure what is the right way
> to resolve this offhand.
I think git did the "right thing", it just happened to be the thing that
Tony didn't want. Which m
On Wed, 24 Aug 2005, Junio C Hamano wrote:
> [EMAIL PROTECTED] writes:
>
> > So I have another anomaly in my GIT tree. A patch to
> > back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
> > in my release branch at commit
> >
> > 62d75f3753647656323b0365faa43fc1a8f7be97
> >
> > appears
[EMAIL PROTECTED] writes:
> So I have another anomaly in my GIT tree. A patch to
> back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
> in my release branch at commit
>
> 62d75f3753647656323b0365faa43fc1a8f7be97
>
> appears to have been lost when I merged the release branch to
> the t
On Tue, 23 Aug 2005, Tony Luck wrote:
>
> So GIT decides that the test branch has had a patch, and the release
> branch hasn't ... and so it merges by keeping the version in test.
>
> Plausible?
Very. Sounds like what happened.
Linus
-
To unsubscribe from this list: send the l
I'm at home, and too lazy to log in to work to look at my tree. But I
have a theory
as to what went wrong for me.
At the start I had a file, same contents in test and release branch.
I applied a patch to release, and pulled to test. So the contents are still
the same, both with the patch applie
So I have another anomaly in my GIT tree. A patch to
back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
in my release branch at commit
62d75f3753647656323b0365faa43fc1a8f7be97
appears to have been lost when I merged the release branch to
the test branch at commit
0c3e091838f02c537c
12 matches
Mail list logo
