Re: [PATCH, 4th version] git-branch: register where to merge from, when branching off a remote branch
Show 8 quoted lines
> I have a feeling that "git checkout -b" and "git checkout -B"
> should be taught to explicitly use "git branch --no-track" and
> "git branch --track" to create a new branch (currently it does
> not even use "git branch" as far as I can tell). With your
> patch, I suspect that you have to say "git branch topic
> origin/topic" and then "git checkout topic", which means you
> made the three-step process into two steps, but you could have
> made it into one step.
Well, yes, the next part would have been to patch git-checkout. But this one is already proving to be complicated enough. :-)
> I'll send out an untested patch to
> git-checkout so that you can try it out in a separate message.
I saw it. I tested your patch and it seems to work.
> - (micronit) Is it true that both strlen() tests are about long
> *branch* names?
If you consider something like "origin/next" to be a branch name, yes.
Show 8 quoted lines
> - (moderately serious) The code blindly trusts that
> "refs/remotes/foo/bar" tracks "refs/heads/bar" from remote
> named "foo", which is a bit disturbing. With the default
> configuration git-clone and git-remote creates, it always is
> the case, but I suspect you might want to at least verify
> that assumption (the user can have different settings in the
> config), if not figuring them out by reading the existing
> configuration yourself.
Ouch. Absolutely right, but this means I will prepare the patch later then.
>> + else if (dwim_ref(start_name, strlen(start_name), sha1, &real_ref))
>> + remote = !prefixcmp(real_ref, "refs/remotes/");
>
> - (pure question) What happens if dwim_ref() returns more than one?
Then, real_ref is the one matching sha1.
Considering your other objection about the naming of the variable, what about enabling/disabling the tracking using remote.REMOTENAME.tracklocalsubbranches?
Paolo
Paolo Bonzini <paolo.bonzini@gmail.com>