Am 24.12.20 um 01:13 schrieb Mike McLean:
> I agree that "realism and frequency of use case" is a critical metric :D
>
> For me it's very much the 2nd case you described and there are 2
> scenarios that it comes up in most frequently:
>
> [...]
> 2) Interactive rebases
> I make heavy use of interactive rebases, in order to make committing
> be a REALLY low effort task. If I don't have to clean up my commits
> when I make them, then I can commit really easily, which means I
> commit frequently, which is a good thing :D But then I have a messy
> git history. Especially if I'm juggling a bunch of small fixes at
> once, and I end up with bits of one fix/refactor in a commit that was
> mostly about another thing.
>
> Not a problem: Interactive rebase to the rescue!
>
> I use `edit` mode to split stuff apart and then squash mode to push
> the relevant bits back together again.
> But a downside of this is that frequently I end up with the commit
> with the good message being *after* the scrappy bit that's just been
> split off from another commit.
> Sometimes I can just pull that scrappy bit past the main commit and
> then `fixup` that bit, but often that would cause merge conflicts, so
> it'd be easier to have a fixdown that does exactly what I'm going to
> do with `squash`.
>
> =-=-=-=-=-=-=-=-=-=-=
>
> I recognise that these might be very niche or non-standard usages, and
> if you don't think there would be much demand for such functionality
> then I'm fine with that :D
I would not say that your workflow is exceptional; quite the contrary: I
do exactly like you explained. And I guess that many others do as well
(interactive rebase was invented for uses cases like yours).
I don't mind using 'squash' to consolidate commits where the meat of the
change and the commit message is not in the first one.
But consider a situation like this, which I find myself in regularly:
$ work
$ git commit -m "WIP begin feature"
$ work -- ah, this can be done independently:
$ git commit -m "refactor stuff"
$ do the real feature (takes time, many commits)
# finally:
$ git commit -m "the real feature"
Here I wish that the final commit carries an author date that should be
after the "refactor" commit to be realistic. But 'squash' takes
authorship including the date from the first commit (the "WIP" commit in
this example). That is where the suggested feature could help. I admit,
though, that it's not a huge deal.
-- Hannes
