Subject: Re: [PATCH] branch: description for non-existent branch errors

From: Junio C Hamano <[email-masked]>
Date: Wed, 28 Sep 2022 10:41:08 -0700

Junio C Hamano <[email-masked]> writes:

> Rubén Justo <[email-masked]> 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.