A couple of rebase --autosquash proposals

Hi,

I am using Git 1.8.4.3 compiled by me on OEL6.  I'd like to be able to
use rebase --autosquash like this:

======================
# git log

commit b94f970cd869dfbf5254b19867fa7200df732d4f
Author: Me [off-list ref]
Date:   Mon Dec 9 17:02:32 2013 -0800

    fixup!
    This is a second fixup.

commit 64e516c8b26b7e0531a1e8b2fc8dfa21de259b85
Author: Me [off-list ref]
Date:   Sun Dec 8 17:02:32 2013 -0800

    fixup!
    This is a meaningful commit-log message, on a new line, that will
be discarded later during rebase --autosquash.

commit f21cd48d5eeac92130dc0617252c6ee6989c0252
Author: Me [off-list ref]
Date:   Tue Dec 3 21:47:52 2013 -0800

    This is the commit that will be fixed-up.

commit 259c0eb41ef16ac94868ee3c9253ba938ed24c9f
Author: Me [off-list ref]
Date:   Mon Dec 2 21:47:52 2013 -0800

    This commit is origin/master.
======================

then

# git rebase -i --autosquash 259c0eb41ef16ac94868ee3c9253ba938ed24c9f

The differences here are:

* fixup! or squash! on it's own would default to fixing-up the
previous commit (or result of previous step of rebase if that was a
squash/fixup).  Interestingly using HEAD~1 or HEAD^1 works, but it
only works for a single fixup/squash.  Is there another treeish that
would work?
* Allow real commit-log text, perhaps only on lines other than the
first line (the one containing the fixup).

The motivations are:

* I can default a fixup to apply to the previous commit (a common
wish) without explicitly stating it's treeish or commit-message.
* I can easily apply multiple fixups.
* I can retain a meaningful WIP commit-log prior to the rebase - I can
still see what each commit does, without needing to forgo the future
autosquash capability - just put the !fixup or !squash on the first
line on its own, and put the real changes on line 2 and onwards.  In
the case of squash! instead of fixup!, this means I could retain some
valuable text to be squashed into the original commit.

Thoughts on these two ideas?

Thanks
Brett

Am 12/9/2013 3:23, schrieb Brett Randall:

* fixup! or squash! on it's own would default to fixing-up the
previous commit (or result of previous step of rebase if that was a
squash/fixup).

Why would you want that? To fixup the previous commit, just use 'git
commit --amend'. What am I missing?

-- Hannes

On 09/12/13 19:51, Johannes Sixt wrote:

Am 12/9/2013 3:23, schrieb Brett Randall:

quoted

* fixup! or squash! on it's own would default to fixing-up the
previous commit (or result of previous step of rebase if that was a
squash/fixup).

Why would you want that? To fixup the previous commit, just use 'git
commit --amend'. What am I missing?

In the past I've used this kind of approach when doing merging/porting
work with 3rd party code (or just large integrations). The first (and
eventually final) commit introduces the new code. The subsequent fixups
address build issues which are either errors in the 3rd party code
(which I will want to submit bug reports for later and carry in my tree
as real commits) or errors in my merging (which I want to squash into
the merge commit). When faced with a screen full of compilation errors
I'm not sure which of these 2 categories are applicable at the time so I
tend to have lots of little fixups that I need to juggle around with git
rebase once I've got the code compiling and passing some tests.

All that being said I think allowing multiple "fixup!\n" stack up on
each other might be a bit dangerous. There are cases where
fixup!-fixup!-real might be useful but those would be hard to
distinguish those from cases where someone absent mindedly forgot to put
something after "fixup!".

quoted

quoted

* fixup! or squash! on it's own would default to fixing-up the
previous commit (or result of previous step of rebase if that was a
squash/fixup).

Why would you want that? To fixup the previous commit, just use 'git
commit --amend'. What am I missing?

In the past I've used this kind of approach when doing merging/porting
work with 3rd party code (or just large integrations). The first (and
eventually final) commit introduces the new code. The subsequent fixups
address build issues which are either errors in the 3rd party code
(which I will want to submit bug reports for later and carry in my tree
as real commits) or errors in my merging (which I want to squash into
the merge commit). When faced with a screen full of compilation errors
I'm not sure which of these 2 categories are applicable at the time so I
tend to have lots of little fixups that I need to juggle around with git
rebase once I've got the code compiling and passing some tests.

All that being said I think allowing multiple "fixup!\n" stack up on
each other might be a bit dangerous. There are cases where
fixup!-fixup!-real might be useful but those would be hard to
distinguish those from cases where someone absent mindedly forgot to put
something after "fixup!".

You guys probably already know about it, but there is `git commit
--fixup SHA1` to create !fixup commits intended for a particular
commit. I think using this feature solves all the problem the OP has?

Philippe

This aims to support code-review workflows of teams that prefer rebase
over merge, when committing a new peer-reviewed feature.

* Developer starts with commit OM, commits A.
* During testing, the developer may make further changes, either
through --amend or new commits, but either way, all work is rebased to
a single new commit for review, OM -> A' .
* A' is pushed as a new branch to origin for team review.  The review
system facilitates the review of the change, and review comments are
made.
* The developer responds to the review comments by making changes in
commits B and C, and pushes OM -> A' -> B -> C.  Reviewers can
understand the feedback that has been addressed in the changes with
through the commit-log in B and C.
* Code passes review.  Because the team prefers rebased commits, A'..C
is rebased onto the current OM (which may now be OM+10) and committed.

If the commit-log entries for B and C allow simultaneous
fixup!/squash! syntax together with and free-text log-text, they can
serve both purposes: 1) they communicate that the change is a
feedback-generated fix (rather than a new feature), and describe which
parts of the feedback each commit addresses, and 2) they pre-empt and
support the eventual rebase-before-origin-push, through --autosquash
annotation.

Brett

On 9 December 2013 20:26, Chris Packham [off-list ref] wrote:

On 09/12/13 19:51, Johannes Sixt wrote:

quoted

Am 12/9/2013 3:23, schrieb Brett Randall:

quoted

* fixup! or squash! on it's own would default to fixing-up the
previous commit (or result of previous step of rebase if that was a
squash/fixup).

Why would you want that? To fixup the previous commit, just use 'git
commit --amend'. What am I missing?

In the past I've used this kind of approach when doing merging/porting
work with 3rd party code (or just large integrations). The first (and
eventually final) commit introduces the new code. The subsequent fixups
address build issues which are either errors in the 3rd party code
(which I will want to submit bug reports for later and carry in my tree
as real commits) or errors in my merging (which I want to squash into
the merge commit). When faced with a screen full of compilation errors
I'm not sure which of these 2 categories are applicable at the time so I
tend to have lots of little fixups that I need to juggle around with git
rebase once I've got the code compiling and passing some tests.

All that being said I think allowing multiple "fixup!\n" stack up on
each other might be a bit dangerous. There are cases where
fixup!-fixup!-real might be useful but those would be hard to
distinguish those from cases where someone absent mindedly forgot to put
something after "fixup!".