Hi Philip,
On Tue, 6 Sep 2016, Philip Oakley wrote:
> From: "Johannes Schindelin" <Johannes.Schindelin@xxxxxx>
> >
> > On Sun, 4 Sep 2016, Philip Oakley wrote:
> >
> > > I suspect that some use cases have intermediate repositories that
> > > contain a 'master' branch (it's just a name ;-) that isn't blessed
> > > and golden, e.g. at the team review repo level. In such cases it is
> > > possible for a fixup! to be passed up as part of the review, though
> > > it's not the current norm/expectation.
> >
> > In such a case (which can totally arise when criss-crossing Pull
> > Requests on GitHub, for example, where a Pull Request's purpose may be
> > to fix up commits in another Pull Request before the latter is
> > merged), the most appropriate course of action is... to not reorder
> > the fixup!s prematurely.
>
> We just need to be careful about that plural just there.
>
> If it is multiple fixup!s for the same commit, then I believe they should be
> grouped together at the same point as the first fixup! commit (in their
> original order).
We should they be grouped together? In the final rebase (the one that
actually also includes the commit that is to be rewritten), they will be
grouped together anyway.
And it is not like users cannot regroup manually if they choose to perform
an intermediate rebase. In that case, the user will also choose whether
she wants to simply regroup the fixups, or squash them into a single
fixup, too.
> > > > In short, I am opposed to this change.
> > >
> > > It's not like G4W doesn't need fixup!s on the side branches e.g.
> > > 5eaffe9 ("fixup! Handle new t1501 test case properly with MinGW",
> > > 2016-07-12)
>
> I note that you don't have two fixup!s for that commit
Not for that one, no. But there have been cases where I had to add two or
more fixups for the same commit, in preparation for the next merging
rebase.
> > Yeah, well, Git for Windows' `master` branch is special, in that it is
> > constantly rebased (as "merging rebases", to keep
> > fast-forwardability). I would not necessarily use Git for Windows as a
> > role model in this respect.
>
> I don't see GfW as 'special', rather as being a representative of a
> broader realpolitik where some of the rugged individualism of open
> source is moderated in some way or another.
Sure, it is an example of a project that needs to solve the problem where
patch series are accumulated, to be submitted to an upstream project, and
so we have to keep fast-forwardability at the same time as we have to
rebase.
But Git for Windows is special in the way it solves the problem. I am not
aware of anybody else performing merging rebases.
Ciao,
Dscho