threads / discuss / 39051

rebase --root conflicts with --committer-date-is-author-date

Subject: rebase --root conflicts with --committer-date-is-author-date

## tl;dr

3 messages between Apr 11, 2015 and Apr 16, 2015.

replies: 2people: 3as markdown or json

Elliot Wolk· Apr 11, 2015, 18:29 UTC · lore

============ version:

git version 2.1.4 Linux wolke-w520 3.19.3-towo.1-siduction-amd64 #1 SMP PREEMPT siduction 3.19-9 (2015-03-26) x86_64 GNU/Linux ============ summary:

if i do `git rebase --committer-date-is-author-date --root', the committer date is set to now, instead of set to the author date. when rebasing onto the first commit, it works perfectly well. ============ reproduce:

set -x cd mkdir test cd test git init echo line >> a; git add a; git commit -m 'jan1' --date '2015-01-01' echo line >> a; git add a; git commit -m 'jan2' --date '2015-01-02' echo line >> a; git add a; git commit -m 'jan3' --date '2015-01-03' git log --format=format:%s-%cD-%aD%n git rebase --committer-date-is-author-date HEAD^^ git log --format=format:%s-%cD-%aD%n git rebase --committer-date-is-author-date --root git log --format=format:%s-%cD-%aD%n git rebase --committer-date-is-author-date HEAD^^ git log --format=format:%s-%cD-%aD%n git rebase --committer-date-is-author-date --root git log --format=format:%s-%cD-%aD%n ============ expected:

jan3-Sat, 03 Jan 2015 13:28:06 -0500-Sat, 3 Jan 2015 13:28:06 -0500 jan2-Sat, 02 Jan 2015 13:28:06 -0500-Fri, 2 Jan 2015 13:28:06 -0500 jan1-Sat, 01 Jan 2015 13:28:06 -0500-Thu, 1 Jan 2015 13:28:06 -0500 ============ actual:

jan3-Sat, 11 Apr 2015 14:28:06 -0400-Sat, 3 Jan 2015 13:28:06 -0500 jan2-Sat, 11 Apr 2015 14:28:06 -0400-Fri, 2 Jan 2015 13:28:06 -0500 jan1-Sat, 11 Apr 2015 14:28:06 -0400-Thu, 1 Jan 2015 13:28:06 -0500

{full output: http://pastie.org/10086950} ============ sorry if dupe/wrong-venue/poorly-formatted/incomprehensible. i tried.

Junio C Hamano· Apr 12, 2015, 06:19 UTC · re: Elliot Wolk · lore

Re: rebase --root conflicts with --committer-date-is-author-date

I think that the reason for this behaviour is that "rebase --root" implicitly forces "rebase -i" to run (instead of the 'format-patch piped to am'), and --committer-date-is-author-date is not supported by the "rebase -i" codepath at all.

I see Thomas did "rebase --root" support in v1.6.2 era both in the normal and interactive rebase codepaths, but df5df20c (rebase -i: support --root without --onto, 2012-06-26) started forcing --root rebase to always use the "rebase -i" codepath.

Teaching "rebase -i" to support --committer-date-is-author-date like the normal rebase codepath is one thing, but I wonder why we force "rebase -i" on people who merely wanted to do "--root". The way df5df20c (rebase -i: support --root without --onto, 2012-06-26) explains it does not read like a valid justification, at least to me. It says:

    Implicitly use rebase -i for non-interactive rebase of --root
    without an --onto argument now that rebase -i can correctly do
    this.

which is "because we can", not "because it is a good thing to do for such and such reasons". This is an ancient change in v1.7.12 days.

Chris, do you remember if there was a reason why it was a bad idea to teach the normal rebase codepath to handle "--root"? I think we would have needed to allow "am" to apply a creation patch and start a new history on an unborn branch in order to do so, but I am not sure if there was a valid reason why such a change to "am" would have been a bad idea.

Thanks.
Elliot Wolk <elliot.wolk@gmail.com> writes:
Show 48 quoted lines
> ============
> version:
>
> git version 2.1.4
> Linux wolke-w520 3.19.3-towo.1-siduction-amd64 #1 SMP PREEMPT
> siduction 3.19-9 (2015-03-26) x86_64 GNU/Linux
> ============
> summary:
>
> if i do `git rebase --committer-date-is-author-date --root', the
> committer date is set to now, instead of set to the author date.
> when rebasing onto the first commit, it works perfectly well.
> ============
> reproduce:
>
> set -x
> cd
> mkdir test
> cd test
> git init
> echo line >> a; git add a; git commit -m 'jan1' --date '2015-01-01'
> echo line >> a; git add a; git commit -m 'jan2' --date '2015-01-02'
> echo line >> a; git add a; git commit -m 'jan3' --date '2015-01-03'
> git log --format=format:%s-%cD-%aD%n
> git rebase --committer-date-is-author-date HEAD^^
> git log --format=format:%s-%cD-%aD%n
> git rebase --committer-date-is-author-date --root
> git log --format=format:%s-%cD-%aD%n
> git rebase --committer-date-is-author-date HEAD^^
> git log --format=format:%s-%cD-%aD%n
> git rebase --committer-date-is-author-date --root
> git log --format=format:%s-%cD-%aD%n
> ============
> expected:
>
> jan3-Sat, 03 Jan 2015 13:28:06 -0500-Sat, 3 Jan 2015 13:28:06 -0500
> jan2-Sat, 02 Jan 2015 13:28:06 -0500-Fri, 2 Jan 2015 13:28:06 -0500
> jan1-Sat, 01 Jan 2015 13:28:06 -0500-Thu, 1 Jan 2015 13:28:06 -0500
> ============
> actual:
>
> jan3-Sat, 11 Apr 2015 14:28:06 -0400-Sat, 3 Jan 2015 13:28:06 -0500
> jan2-Sat, 11 Apr 2015 14:28:06 -0400-Fri, 2 Jan 2015 13:28:06 -0500
> jan1-Sat, 11 Apr 2015 14:28:06 -0400-Thu, 1 Jan 2015 13:28:06 -0500
>
> {full output: http://pastie.org/10086950}
> ============
> sorry if dupe/wrong-venue/poorly-formatted/incomprehensible. i tried.
Chris Webb· Apr 16, 2015, 22:15 UTC · re: Junio C Hamano · lore

Re: rebase --root conflicts with --committer-date-is-author-date

Junio C Hamano <gitster@pobox.com> wrote:
Show 6 quoted lines
> Chris, do you remember if there was a reason why it was a bad idea
> to teach the normal rebase codepath to handle "--root"?  I think we
> would have needed to allow "am" to apply a creation patch and start
> a new history on an unborn branch in order to do so, but I am not
> sure if there was a valid reason why such a change to "am" would
> have been a bad idea.

Hi. It's a long time ago, but I don't remember any reason and it feels sensible that am should be able to create an unborn branch in the same way interactive rebase can.

I suspect I had done the necessary work for rebase -i but not for am, and incorrectly assumed that interactive rebase was in any case a superset of non-interactive.

Best wishes,
Chris.

← back to recent threads