Dear Peff,
I have no problem working around this bug/feature.
I just happen to think that the current *default* behaviour
is not the default behaviour that users have a right to expect:
I believe that users have every right to expect `git format-patch`/`git am`
to preserve commit messages perfectl
On Wed, Dec 02, 2015 at 01:38:18PM +0100, huebbe wrote:
> As such, I would like to ask whether it would be possible/sensible
> to somehow escape square brackets, or mark the beginning
> of the original commit message in the `git format-patch` output?
> This would allow `git am` to reproduce the ex
On 12/02/2015 01:58 AM, Jeff King wrote:
> On Wed, Nov 25, 2015 at 04:59:35PM +0100, huebbe wrote:
>
>> Yes, it looks like the `--keep-non-patch` option works around this.
>>
>> However, shouldn't that be the default behaviour?
>> I mean, what is the point in stripping stuff that is not proven to
Stefan Beller writes:
> Do we as the Git community have a place where we take notes for version 3?
I do not think there is, I do think we might need one when a need
arises, and I do not think this topic is one that creates such a
need.
And I said "might" in the second one, based on the experien
Jeff King writes:
> The "[]" convention is a microformat used by Linux kernel folks. So it's
> not "whoops, we are stripping stuff not added by git". It is respecting
> a microformat used by the tool's authors.
>
> That being said, if we were choosing a default from scratch today, it
> might go t
On Tue, Dec 1, 2015 at 4:58 PM, Jeff King wrote:
> On Wed, Nov 25, 2015 at 04:59:35PM +0100, huebbe wrote:
>
>> Yes, it looks like the `--keep-non-patch` option works around this.
>>
>> However, shouldn't that be the default behaviour?
>> I mean, what is the point in stripping stuff that is not pr
On Wed, Nov 25, 2015 at 04:59:35PM +0100, huebbe wrote:
> Yes, it looks like the `--keep-non-patch` option works around this.
>
> However, shouldn't that be the default behaviour?
> I mean, what is the point in stripping stuff that is not proven to be
> inserted by `git` itself?
> That's not wha
Yes, it looks like the `--keep-non-patch` option works around this.
However, shouldn't that be the default behaviour?
I mean, what is the point in stripping stuff that is not proven to be inserted
by `git` itself?
That's not what I expect a tool to do which I trust.
Cheers,
Nathanael
On 11/25
Am 25.11.2015 um 16:29 schrieb huebbe:
> Description:
>
> When applying a patch created via `git format-patch` with `git am`,
> any prefix of the commit message that's within square brackets is stripped
> from the commit message.
As advertised in the man page of 'git am' (or 'git mailinfo' that
Description:
When applying a patch created via `git format-patch` with `git am`,
any prefix of the commit message that's within square brackets is stripped from
the commit message.
Reproduction:
$ git log --oneline --decorate --graph --all
* b41514b (HEAD) [baz] baz
| * 5e31740 (ma
10 matches
Mail list logo
