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. 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.
