Junio C Hamano <gitster@xxxxxxxxx> writes:
> Rubén Justo <rjusto@xxxxxxxxx> writes:
>
>> I pointed out in the first mail of this thread, there is already a patch in
>> 'seen' that touches builtin/branch.c [1]. I would like to keep the patches
>> separated, but I don't know how to proceed: make the change from 'seen', keep
>> it from 'master'... Maybe you can give me some guidance in this.
>
> I do not see much problem in keeping them separated. My trial merge
> of the result of applying this patch on top of 'master', with the
> other topic that has the "branch description for nth prior checkout"
> patch does show a minor textual conflict, but the resolution does
> not look too bad.
>
> Check near the topic branch of 'seen' after I push out today's
> integration result in a few hours and see if they look reasonable.
>
> Thanks.
Ah, I forgot to mention. As to the error messages that begin with a
capital letter, to be consistent with violating messages that are
already there in builtin/branch.c, let's keep them as they are in
your patch. We can and should clean them up later, perhaps soon
after the patch under discussion matures, but I agree with you that
it can be left outside the scope of this patch.
But stepping back a bit, in the longer term, we might want to change
the behaviour of "git branch --edit-description", at least when no
branch is specified on the command line and we are on an unborn
branch. It is merely the matter of setting a variable in the
configuration file, so there may not be a strong reason to forbid
$ git init trash
$ cd trash
$ git branch --edit-description
$ git commit --allow-empty -m initial
while allowing the same sequence with the last two commands reversed.
After all, renaming a branch with "branch -m" does not to require an
existing ref that points at a commit, i.e.
$ git init -b master trash
$ cd trash
$ git config branch.master.description "describes master"
$ git branch -m master main
does work fine and you end up with branch.main.description at the
end.
