Re: Bug: rebase -i creates committer time inversions on 'reword'

2018-04-19 Thread Phillip Wood
On 16/04/18 10:48, Phillip Wood wrote: > On 14/04/18 14:11, Johannes Schindelin wrote: >> Hi, >> >> On Sat, 14 Apr 2018, Phillip Wood wrote: >> >> FWIW I agree with Hannes' patch. >> >>> I think 'git am' probably gives all patches the same commit time as well >>> if the commit date is cached

Re: Bug: rebase -i creates committer time inversions on 'reword'

2018-04-18 Thread Phillip Wood
On 16/04/18 06:56, Johannes Sixt wrote: > > Am 15.04.2018 um 23:35 schrieb Junio C Hamano: >> Ah, do you mean we have an internal sequence like this, when "rebase >> --continue" wants to conclude an edit/reword? > > Yes, it's only 'reword' that is affected, because then subsequent picks > are

Re: Bug: rebase -i creates committer time inversions on 'reword'

2018-04-16 Thread Junio C Hamano
Johannes Sixt writes: > Am 15.04.2018 um 23:35 schrieb Junio C Hamano: >> Ah, do you mean we have an internal sequence like this, when "rebase >> --continue" wants to conclude an edit/reword? > > Yes, it's only 'reword' that is affected, because then subsequent > picks are

Re: Bug: rebase -i creates committer time inversions on 'reword'

2018-04-16 Thread Phillip Wood
On 14/04/18 14:11, Johannes Schindelin wrote: > Hi, > > On Sat, 14 Apr 2018, Phillip Wood wrote: > >> On 13/04/18 17:52, Johannes Sixt wrote: >>> >>> I just noticed that all commits in a 70-commit branch have the same >>> committer timestamp. This is very unusual on Windows, where rebase -i of

Re: Bug: rebase -i creates committer time inversions on 'reword'

2018-04-15 Thread Johannes Sixt
Am 15.04.2018 um 23:35 schrieb Junio C Hamano: Ah, do you mean we have an internal sequence like this, when "rebase --continue" wants to conclude an edit/reword? Yes, it's only 'reword' that is affected, because then subsequent picks are processed by the original process. - we figure out

Re: Bug: rebase -i creates committer time inversions on 'reword'

2018-04-15 Thread Junio C Hamano
Johannes Sixt writes: > I just noticed that all commits in a 70-commit branch have the same > committer timestamp. This is very unusual on Windows, where rebase -i of > such a long branch takes more than one second (but not more than 3 or > so thanks to the builtin nature of the

Re: Bug: rebase -i creates committer time inversions on 'reword'

2018-04-14 Thread Johannes Schindelin
Hi, On Sat, 14 Apr 2018, Phillip Wood wrote: > On 13/04/18 17:52, Johannes Sixt wrote: > > > > I just noticed that all commits in a 70-commit branch have the same > > committer timestamp. This is very unusual on Windows, where rebase -i of > > such a long branch takes more than one second (but

Re: Bug: rebase -i creates committer time inversions on 'reword'

2018-04-14 Thread Phillip Wood
On 13/04/18 17:52, Johannes Sixt wrote: > > I just noticed that all commits in a 70-commit branch have the same > committer timestamp. This is very unusual on Windows, where rebase -i of > such a long branch takes more than one second (but not more than 3 or > so thanks to the builtin nature of

Bug: rebase -i creates committer time inversions on 'reword'

2018-04-13 Thread Johannes Sixt
I just noticed that all commits in a 70-commit branch have the same committer timestamp. This is very unusual on Windows, where rebase -i of such a long branch takes more than one second (but not more than 3 or so thanks to the builtin nature of the command!). And, in fact, if you mark some