Re: bug with git merge-base
Junio C Hamano writes: > Well, reading builtin/merge-base.c::handle_fork_point(), I think the > intended behaviour is: > > - die() when input is not well formed (e.g. bad commit object, >ambigous ref name, etc.); there is an error worth reporting in >this case. > > - show one that used to sit at the tip of the ref, if exists, and >signal success with exit status 0; there of course is no error in >this case. > > - if there is no such fork point found, signal failure with exit >status 1; nothing is written to the standard output as there is >no fork point to be shown, and nothing is written to the standard >error. > > I do not think the code considers the last case as an error, i.e. it > is just as natural not to have any fork point, as there is one. > > It might be OK to teach the command to say "no fork point found" to > the standard error under "--verbose" mode in the last case, but > since the command does not take --verbose or --quiet, I have a > feeling that everything is working as designed. I forgot to say that the behaviour above used by the "fork point" mode seems to match the behaviour of the more established normal "merge base" mode. builtin/merge-base.c::show_merge_base() also follows the same "die if the input is faulty, give output and succeed if a merge base is found, otherwise be silent and signal failure with exit code" pattern.
Re: bug with git merge-base
Eric Sunshine writes: > On Wed, Sep 19, 2018 at 6:25 PM Alexander Mills > wrote: >> The following command sequence exits with 1, and no stderr >> >> base='remotes/origin/dev'; >> fork_point="$(git merge-base --fork-point "$base")"; >> >> I cannot figure out why it's exiting with 1, but there is no stdout/stderr > > Unable to reproduce the problem. Perhaps you can provide more context. Well, reading builtin/merge-base.c::handle_fork_point(), I think the intended behaviour is: - die() when input is not well formed (e.g. bad commit object, ambigous ref name, etc.); there is an error worth reporting in this case. - show one that used to sit at the tip of the ref, if exists, and signal success with exit status 0; there of course is no error in this case. - if there is no such fork point found, signal failure with exit status 1; nothing is written to the standard output as there is no fork point to be shown, and nothing is written to the standard error. I do not think the code considers the last case as an error, i.e. it is just as natural not to have any fork point, as there is one. It might be OK to teach the command to say "no fork point found" to the standard error under "--verbose" mode in the last case, but since the command does not take --verbose or --quiet, I have a feeling that everything is working as designed.
Re: bug with git merge-base
On Wed, Sep 19, 2018 at 6:25 PM Alexander Mills wrote: > The following command sequence exits with 1, and no stderr > > base='remotes/origin/dev'; > fork_point="$(git merge-base --fork-point "$base")"; > > I cannot figure out why it's exiting with 1, but there is no stdout/stderr Unable to reproduce the problem. Perhaps you can provide more context.
bug with git merge-base
The following command sequence exits with 1, and no stderr base='remotes/origin/dev'; fork_point="$(git merge-base --fork-point "$base")"; I cannot figure out why it's exiting with 1, but there is no stdout/stderr -alex -- Alexander D. Mills ¡¡¡ New cell phone number: (415)730-1805 !!! alexander.d.mi...@gmail.com www.linkedin.com/pub/alexander-mills/b/7a5/418/
Re: Bug with git merge-base and a packed ref
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
Re: Bug with git merge-base and a packed ref
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
Bug with git merge-base and a packed ref
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
