On Sun, May 24, 2020 at 09:15:33AM -0700, Junio C Hamano wrote:
> René Scharfe <l.s.r@xxxxxx> writes:
>
> > OK, but stepping back a bit and trying to forget what I know about the
> > option --track and pretending to see it for the first time, I have to
> > ask: Why doesn't it take an argument? If I check out a raw commit, it
> > cannot guess the upstream branch anyway. So I'd assume this to work:
> >
> > git checkout -b new-branch --track=upstream start-point
>
> Assuming that --track option is marked with PARSE_OPT_OPTARG and
> when the option is given, we internally do a rev-parse of both
> upstream and start-point and make sure the tip of the "track" is an
> ancestor of the "start-point", I think it makes sense. That would
> catch cases like this:
>
> git checkout --detach origin/master
> ... work work work ...
> git checkout -b new-branch --track=origin/master HEAD
>
> On the other hand, some use case might want to go the other way, e.g.
>
> git checkout --detach origin/master~12
> ... work to fix an older bug ...
> git checkout -b new-branch --track=origin/master HEAD
>
> in which case the start-point and the current tip of the tracking
> branch has no relation other than they share a common ancestor.
Trying to think back on times I might have used a feature like this,
most of them are like the first case (though I admit I was always
content with "git branch --set-upstream-to" after the fact).
I do hit the other case, too, with something like:
git checkout next
... hack hack hack ...
# oops, I meant to do this on top of master
git checkout -b new-branch --track=origin/master HEAD
git rebase --onto=origin/master HEAD~2
though given the rebase trickery, I tend to instead just do now:
git checkout -b new-branch origin
git cherry-pick -2 HEAD@{1}
I don't know if that really goes to show anything. I'm mostly just
thinking out loud.
> So, should we allow a random upstream & start-point combination? It
> appears to me that as long as they share _some_ common ancestory, it
> may make sense.
But wouldn't just about any two tips in a repository share some common
ancestry? There are obviously funny exceptions like rewriting history,
or storing unrelated branches, but for the most part you'd find _some_
merge base, even if it's a root commit. So it seems like that check is
unlikely to help prevent accidents, would possibly be an impediment to
something clever the user is doing (albeit quite rarely), and makes the
feature slightly harder to describe. That doesn't seem worth it.
-Peff
