* Bug with git merge-base and a packed ref @ 2016-10-12 10:37 Stepan Kasal 2016-10-12 16:32 ` Jeff King 0 siblings, 1 reply; 6+ messages in thread From: Stepan Kasal @ 2016-10-12 10:37 UTC (permalink / raw) To: git Hello, first, I observed a bug with git pull --rebase: if the remote branch got rebased and the loval branch was updated, pull tried to rebase the whole branch, not the local increment. A reproducer would look like that # in repo1: git checkout tmp cd .. git clone repo1 repo2 cd repo1 git rebase elsewhere tmp cd ../repo2 # edit git commit -a -m 'Another commit' git pull -r The last command performs something like git rebase new-origin/tmp instead of git rebase --onto new-origin/tmp old-origin/tmp I'm using git version 2.10.1.windows.1 I tried to debug the issue: I found that the bug happens only at the very first pull after clone. I was able to reproduce it with git-pull.sh The problem seems to be that command git merge-base --fork-point refs/remotes/origin/tmp refs/heads/tmp returns nothing, because the refs are packed. Could you please fix merge-base so that it understands packed refs? Thanks, Stepan ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug with git merge-base and a packed ref 2016-10-12 10:37 Bug with git merge-base and a packed ref Stepan Kasal @ 2016-10-12 16:32 ` Jeff King 2016-10-12 19:33 ` Stepan Kasal 2016-10-12 20:10 ` [PATCH] merge-base: handle --fork-point without reflog Jeff King 0 siblings, 2 replies; 6+ messages in thread From: Jeff King @ 2016-10-12 16:32 UTC (permalink / raw) To: Stepan Kasal; +Cc: John Keeping, git On Wed, Oct 12, 2016 at 12:37:16PM +0200, Stepan Kasal wrote: > A reproducer would look like that > > # in repo1: > git checkout tmp > cd .. > git clone repo1 repo2 > cd repo1 > git rebase elsewhere tmp > cd ../repo2 > # edit > git commit -a -m 'Another commit' > git pull -r > > The last command performs something like > git rebase new-origin/tmp > instead of > git rebase --onto new-origin/tmp old-origin/tmp > > I'm using git version 2.10.1.windows.1 > > > I tried to debug the issue: > I found that the bug happens only at the very first pull after clone. > I was able to reproduce it with git-pull.sh > > The problem seems to be that command > git merge-base --fork-point refs/remotes/origin/tmp refs/heads/tmp > returns nothing, because the refs are packed. The --fork-point option looks in the reflog to notice that the upstream branch has been rebased. I don't think clone actually writes reflog entries, though, which would explain why it happens only on the first pull after clone. I suspect the necessary information _is_ there, though. When we update the tracking branch, the new reflog entry will show it going from sha1 X to sha1 Y. So my guess is that --fork-point is looking for the entry where it became "X" (which doesn't exist, because clone did not write it), but it _could_ find that we came from "X" in the very first reflog entry. That's all without looking at the code, though. I don't have time to examine it now, but maybe that can point somebody in the right direction. > Could you please fix merge-base so that it understands packed refs? I think the packed-refs thing is probably a red herring. If merge-base didn't understand packed refs, a huge chunk of git would be horribly broken. -Peff ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Bug with git merge-base and a packed ref 2016-10-12 16:32 ` Jeff King @ 2016-10-12 19:33 ` Stepan Kasal 2016-10-12 20:10 ` [PATCH] merge-base: handle --fork-point without reflog Jeff King 1 sibling, 0 replies; 6+ messages in thread From: Stepan Kasal @ 2016-10-12 19:33 UTC (permalink / raw) To: Jeff King; +Cc: John Keeping, git Hello, On Wed, Oct 12, 2016 at 12:32:09PM -0400, Jeff King wrote: > The --fork-point option looks in the reflog [...] > On Wed, Oct 12, 2016 at 12:37:16PM +0200, Stepan Kasal wrote: > > Could you please fix merge-base so that it understands packed refs? I bet you nailed it; nothing with packed refs. Thanks for correcting me. Stepan ^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] merge-base: handle --fork-point without reflog 2016-10-12 16:32 ` Jeff King 2016-10-12 19:33 ` Stepan Kasal @ 2016-10-12 20:10 ` Jeff King 2016-10-12 21:29 ` Junio C Hamano 2016-10-13 6:34 ` Stepan Kasal 1 sibling, 2 replies; 6+ messages in thread From: Jeff King @ 2016-10-12 20:10 UTC (permalink / raw) To: Stepan Kasal; +Cc: John Keeping, git On Wed, Oct 12, 2016 at 12:32:09PM -0400, Jeff King wrote: > > The problem seems to be that command > > git merge-base --fork-point refs/remotes/origin/tmp refs/heads/tmp > > returns nothing, because the refs are packed. > > The --fork-point option looks in the reflog to notice that the upstream > branch has been rebased. I don't think clone actually writes reflog > entries, though, which would explain why it happens only on the first > pull after clone. > > I suspect the necessary information _is_ there, though. When we update > the tracking branch, the new reflog entry will show it going from sha1 > X to sha1 Y. So my guess is that --fork-point is looking for the entry > where it became "X" (which doesn't exist, because clone did not write > it), but it _could_ find that we came from "X" in the very first reflog > entry. Actually, --fork-point gets this case right; it will put the "old" sha1 for the initial reflog entry into the list of base tips. But this merge-base actually runs before we fetch, so there literally is no reflog when it runs. And it doesn't get that case right. Here's a fix. The test I added checks things more directly, but I confirmed manually that it also fixes the rebase case that you reported. -- >8 -- Subject: merge-base: handle --fork-point without reflog The --fork-point option looks in the reflog to try to find where a derived branch forked from a base branch. However, if the reflog for the base branch is totally empty (as it commonly is right after cloning, which does not write a reflog entry), then our for_each_reflog call will not find any entries, and we will come up with no merge base, even though there may be one with the current tip of the base. We can fix this by just adding the current tip to our list of collected entries. Signed-off-by: Jeff King <peff@peff.net> --- It would actually be correct to just unconditionally add the ref tip, as add_one_commit already drops duplicates. But it would only be necessary in other cases if you have a broken reflog which is missing the entry that moved us to the current tip. builtin/merge-base.c | 3 +++ t/t6010-merge-base.sh | 6 ++++++ 2 files changed, 9 insertions(+) diff --git a/builtin/merge-base.c b/builtin/merge-base.c index c0d1822..b572a37 100644 --- a/builtin/merge-base.c +++ b/builtin/merge-base.c @@ -173,6 +173,9 @@ static int handle_fork_point(int argc, const char **argv) revs.initial = 1; for_each_reflog_ent(refname, collect_one_reflog_ent, &revs); + if (!revs.nr && !get_sha1(refname, sha1)) + add_one_commit(sha1, &revs); + for (i = 0; i < revs.nr; i++) revs.commit[i]->object.flags &= ~TMP_MARK; diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh index e0c5f44..31db7b5 100755 --- a/t/t6010-merge-base.sh +++ b/t/t6010-merge-base.sh @@ -260,6 +260,12 @@ test_expect_success 'using reflog to find the fork point' ' test_cmp expect3 actual ' +test_expect_success '--fork-point works with empty reflog' ' + git -c core.logallrefupdates=false branch no-reflog base && + git merge-base --fork-point no-reflog derived && + test_cmp expect3 actual +' + test_expect_success 'merge-base --octopus --all for complex tree' ' # Best common ancestor for JE, JAA and JDD is JC # JE -- 2.10.1.587.g4098016 ^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] merge-base: handle --fork-point without reflog 2016-10-12 20:10 ` [PATCH] merge-base: handle --fork-point without reflog Jeff King @ 2016-10-12 21:29 ` Junio C Hamano 2016-10-13 6:34 ` Stepan Kasal 1 sibling, 0 replies; 6+ messages in thread From: Junio C Hamano @ 2016-10-12 21:29 UTC (permalink / raw) To: Jeff King; +Cc: Stepan Kasal, John Keeping, git Jeff King <peff@peff.net> writes: > Subject: merge-base: handle --fork-point without reflog > > The --fork-point option looks in the reflog to try to find > where a derived branch forked from a base branch. However, > if the reflog for the base branch is totally empty (as it > commonly is right after cloning, which does not write a > reflog entry), then our for_each_reflog call will not find > any entries, and we will come up with no merge base, even > though there may be one with the current tip of the base. > > We can fix this by just adding the current tip to > our list of collected entries. > > Signed-off-by: Jeff King <peff@peff.net> > --- > It would actually be correct to just unconditionally add the ref tip, as > add_one_commit already drops duplicates. But it would only be necessary > in other cases if you have a broken reflog which is missing the entry > that moved us to the current tip. Makes sense. And doing conditionally is not much more work ;-) Thanks. > > builtin/merge-base.c | 3 +++ > t/t6010-merge-base.sh | 6 ++++++ > 2 files changed, 9 insertions(+) > > diff --git a/builtin/merge-base.c b/builtin/merge-base.c > index c0d1822..b572a37 100644 > --- a/builtin/merge-base.c > +++ b/builtin/merge-base.c > @@ -173,6 +173,9 @@ static int handle_fork_point(int argc, const char **argv) > revs.initial = 1; > for_each_reflog_ent(refname, collect_one_reflog_ent, &revs); > > + if (!revs.nr && !get_sha1(refname, sha1)) > + add_one_commit(sha1, &revs); > + > for (i = 0; i < revs.nr; i++) > revs.commit[i]->object.flags &= ~TMP_MARK; > > diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh > index e0c5f44..31db7b5 100755 > --- a/t/t6010-merge-base.sh > +++ b/t/t6010-merge-base.sh > @@ -260,6 +260,12 @@ test_expect_success 'using reflog to find the fork point' ' > test_cmp expect3 actual > ' > > +test_expect_success '--fork-point works with empty reflog' ' > + git -c core.logallrefupdates=false branch no-reflog base && > + git merge-base --fork-point no-reflog derived && > + test_cmp expect3 actual > +' > + > test_expect_success 'merge-base --octopus --all for complex tree' ' > # Best common ancestor for JE, JAA and JDD is JC > # JE ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] merge-base: handle --fork-point without reflog 2016-10-12 20:10 ` [PATCH] merge-base: handle --fork-point without reflog Jeff King 2016-10-12 21:29 ` Junio C Hamano @ 2016-10-13 6:34 ` Stepan Kasal 1 sibling, 0 replies; 6+ messages in thread From: Stepan Kasal @ 2016-10-13 6:34 UTC (permalink / raw) To: Jeff King; +Cc: John Keeping, git Hello, thank you for this nice and quick fix of this corner case! Stepan ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2016-10-13 6:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-10-12 10:37 Bug with git merge-base and a packed ref Stepan Kasal 2016-10-12 16:32 ` Jeff King 2016-10-12 19:33 ` Stepan Kasal 2016-10-12 20:10 ` [PATCH] merge-base: handle --fork-point without reflog Jeff King 2016-10-12 21:29 ` Junio C Hamano 2016-10-13 6:34 ` Stepan Kasal
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git 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 read-only IMAP folder(s) and NNTP newsgroup(s).