[systemd-devel] [ANNOUNCE] Git development moved to github

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jun 02, 2015 at 03:58:33PM +0100, Dimitri John Ledkov wrote:
> On 2 June 2015 at 15:49, Zbigniew Jędrzejewski-Szmek <zbyszek at in.waw.pl> wrote:
> > On Tue, Jun 02, 2015 at 04:34:03PM +0200, Martin Pitt wrote:
> >> David Herrmann [2015-06-02 13:06 +0200]:
> >> > Our preferred way to send future patches is "the github way". This
> >> > means sending pull-requests to the github repo. Furthermore, all
> >> > feature patches should go through pull-requests and should get
> >> > reviewed pre-commit. This applies to everyone. Exceptions are
> >> > non-controversial patches like typos and obvious bug-fixes.
> >>
> >> Makes sense. On the operational level, should we use the
> >> "automatically merge" feature of git hub once approving? On the plus
> >> side it's very convenient, but you'll get one "Merge" commit for every
> >> PR (which is often just one commit), so we'd almost double the entries
> >> in "git log". Or can github be told to not do that?
> >>
> >> Merging manually is quite a bit of work, as you have to add a new
> >> remote every time, fetch that, and pull from it. But it does keep a
> >> cleaner git log history.
> > I'd very much prefer to keep current look of the git tree, without
> > gratuitous merge commits. For bigger changes, which are composed of
> > a larger number of commits, merges are fine. But most patchsets to systmed
> > are either a single commit or two or three.
> 
> I disagree. Largely single patches apply fine, but because they are
> "merged" using $ git am, they are not actually merged, but rebased on
> to tip.
> 
> With actually pulling the pull requests, and merging properly, we will
> get a merge commit most of the time for most submissions, since the
> tree moves that quickly.
> 
> And I think this is _good_, because the submitter's commit ids will be
> preserved (together with the signed gpg commits) and the maintainers
> are discouraged to "fix-up" and/or "adjust" commits upon rebase /
> git-am. Instead fix-ups from reviewer should go as separate commits or
> as part of the merge commit.
It is normal, from what I have seen, to rebase and/or rewrite patches in
github pull requests based on feedback. So the submitters' commit ids
will be preserved, but just the latest version.

I don't think that fixes (not related to merge conflicts, just normal fixes)
in the merge commit are a good idea: anyone looking at the patches will be
confused. Even if one does remember to look at the merge commmit, it is
harder.

Also, I don't see ``dicouraging "fix-ups" and/or "adjusting" commits'' as
a good thing — sometimes such fixups cause problems, I'll grant that, but
most of the time such fixes are small things which don't warrant another
round of submissions (add link to bugzilla, fix some typos, etc.)

Zbyszek