Re: [PATCH 2/2] format-patch: introduce format.defaultTo

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 6, 2014, 20:06 UTC
Message-ID: <xmqqa9f8j2n8.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CALkWK0kZn44x98td9YXNT5VfhVs=ueeSty9M7Vh08bdoGjGQYg@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 6 quoted lines

> Junio C Hamano wrote:
>>  - why is a single branch name sufficient?
>
> It does accept a <revision>, so any form is allowed; but why would
> anyone want that in a format.defaultTo? I'm not sure we want to impose
> an artificial restriction on the configuration variable though.

I meant "a single branch" as opposed to "depending on what branch you are sending out, you may have to use a different upstream starting point", and a single "format.defaultTo" that does not read what your HEAD currently points at may not be enough.

Unless you set @{u} to this new configuration, in which case the choice becomes dynamic depending on the current branch, but

 - if that is the only sane choice based on the current branch, why
   not use that as the default without having to set the
   configuration?

 - Or if that is still insufficient, don't we need branch.*.forkedFrom
   that is different from branch.*.merge, so that different branches
   you want to show "format-patch" output can have different
   reference points?

After all, "format-patch" to send things out to upstream is like asking the other side to do a "rebase" you would do in your repository, so whatever "git rebase" that were too lazy to specify what the fork point was when applying may be a reasonable type-saver default. Yes, sometimes people need to rebase onto somewhere they did not fork from, but that is why they can give explicit $upstream and $onto to the command---I do not think it is any different for "format-patch".