Re: [PATCH v3 01/20] linear-assignment: a function to solve least-cost assignment problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Junio,

On Sat, 7 Jul 2018, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> >> Does the "gitgitgadget" thing lie on the Date: e-mail header?
> >
> > No, GitGitGadget takes the literal output from `git format-patch`, as far
> > as I can tell. So if at all, it is `format-patch` that is lying.
> 
> format-patch faithfully records the fact about the commit that is
> made into the patch.  How pieces of information should (or should
> not) be used depends on the purpose of the application that uses
> its output.

I guess this is one of the fallouts for abusing the `format-patch|am`
dance for `rebase--am`.

> I'd suggest to match what send-email does, which is to notice but
> use the current date when adding a Date: header.  An option to lie
> to SMTP servers may be OK but I do not think we want to encourage
> such a behaviour by making it the default.

I opened a PR to add a TODO:

	https://github.com/gitgitgadget/gitgitgadget/pull/15

> What is missing in the core-git tools is an ability to tell
> send-email to optionaly add an in-body header to record the author
> date of the original.  We add an in-body header that records the
> real author when it is different from the sender automatically, and
> it is OK to have an option to allow doing so (but not encouraged
> around here---it is easier to reason about the resulting history for
> everybody, perhaps other than the original author, to record the
> first time you show the change to the public as the author time).

Pull Request-based workflows keep the original author date all the time.
If that is not desired, we need to do more than paper over it by adjusting
`send-email`.

Ciao,
Dscho



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux