Improving Git workflow

[Jannis Pohlmann]

On Wed, 9 Oct 2013 19:25:17 -0500
Felipe Contreras <felipe.contreras at gmail.com> wrote:

> This is not xfce-4.10..master, this is xfce-4.10...master, with three
> dots, which shows all the independent commits.

Oh, three dots. I've never used that before. Interesting.

I might be confusing things here but didn't your ... output still
include some commits that are actually in both branches, like the two
examples I gave at the bottom?

* 1965297 Use G_ENABLE_DEBUG to set fatal messages.
* 31f9236 Actions: Fix logic of session saving (bug #8857).

Did that output (below the "worrying me") come from a command that
shows more than just independent commits?

> To make it more clear, this is equivalent:
> 
> % gitk ^$(git merge-base xfce-4.10 master) xfce-4.10 master
> 
> >> Now it's clear what commits are translations, and what actual
> >> changes, but it doesn't end there.
> >
> > That's not too bad an idea. Or you could just do this:
> >
> >     git log --oneline xfce-4.10..master | grep -v l10n
> 
> That will miss some commits:

Fine, ok. 
 
> And you can't do that grep stuff with gitk.

Hmm, gitk is something I have never seriously used because the
command line tools provide all the information I personally need.
Anyway, this is not about gitk or my personal preferences. ;)

> >> If you do this, you would arrive at what actually was worrying me:
> >>
> >> * f4e7c27 Post release tag bump.
> >> * 48000a2 (tag: xfce4-panel-4.10.1) Updates for release.
> >> * ef18491 Bugfix in icon/pixbuf resizing code.
> >> * a51135e Fix icons not probably resizing when requested.
> >> * 4294d60 Autotools updates.
> >> * 217e17d Ignore GVarueArray compiler warning.
> >> * 1965297 Use G_ENABLE_DEBUG to set fatal messages.
> >> * eb60ba8 Fixed DnD markers with non-square small items.
> >> * 31f9236 Actions: Fix logic of session saving (bug #8857).
> >> * 6ef607c Panel: Emit save signal for plugins.
> >> * dd5c7fb Libxfce4-panel: Fix typo in the API docs.
> >> * bac9f33 Post release tag bump.
> >>
> >> It seems the stable branch is not properly maintained. There's a
> >> lot of good stuff in 'master' that should be backported, so the
> >> users don't have to wait years for the fixes and improvements. But
> >> it's really hard to cherry-pick the good stuff, if you cannot
> >> easily see it.
> >
> > I think you are missing what I mentioned initially. Most fixes are
> > probably in both branches. Here are two examples:
> >
> > master:
> >   20cf9e8 Use G_ENABLE_DEBUG to set fatal messages.
> >   17643fd Actions: Fix logic of session saving (bug #8857).
> >
> > xfce-4.10:
> >   1965297 Use G_ENABLE_DEBUG to set fatal messages.
> >   31f9236 Actions: Fix logic of session saving (bug #8857).
> >
> > Of course the commits are not 100% the same because the commits that
> > they were applied against differ (e.g. because master has moved on
> > since xfce-4.10 was branched).
> 
> How exactly did I miss that? I'm saying there should be more commits
> cherry-picked from master to the stable branch.

Your "worrying" output included those two commits and your mail was
suggesting that xfce-4.10 is "not properly maintained" because that
list of commits wasn't cherry-picked in xfce-4.10. I realise you
probably didn't mean it like that. Perhaps picking 1-2 example commits
from that list stating which haven't been cherry-picked would've made
things more clear.

> >> Secondly, you don't need tags named like xfce4-panel-4.10.0, we are
> >> already in xfce4-panel, there's no need to specify the name again.
> >> A good convention is what git.git does; v4.10.0. Similarly, you
> >> don't need an xfce-4.10 branch, it can be named 4.10.
> >
> > Both are equally good conventions. A convention is just a matter of
> > taste. Some projects do it this way, some do it differently.
> 
> Yes, but one convention makes sense, while the other has redundant
> information.

One thing that I personally don't like about branches "4.10" versus
tags "v4.10.0" is that their names are so similar and you can easily
confuse the two when checking out branches, tags etc.

With "xfce-x.y" (global Xfce branch name) and
"xfce4-panel-x.y.z" (component release tag) there's a very clear
separation of the two.

But... we're debating taste here, either way is fine in my view. As long
as there is a convention the world is ok.

> >> Third, you don't need personal branches like andrzejr/deskbar2,
> >> that's what personal repositories are for. See for example:
> >>
> >> http://cgit.freedesktop.org/~keithp
> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/

> > we might as well benefit from its
> > super lightweight and fast branching without having to set up
> > separate repositories for everyone.
> 
> If what bothers you is the setup of separate repositories, which can
> be done with literally one command, you can have a single repository:

Whether or not it takes just one command depends on your git server
infrastructure. But yes, I assume gitolite (which I believe we are
using) can be set up to create user repositories easily. And I agree,
it might help if anyone can spin up repositories for themselves.

> cruft/xfce4-panel, and there everybody could push as many personal
> branches as they want without polluting the main repository.
> 
> Every big project I've seen (whether it's Git, or Linux, or Xorg) that
> uses Git effectively avoids personal branches in the main repository.
> They do have temporal branches, like for example the xwayland branch
> in xserver, but those are not personal, the might be temporary, but
> for everyone.

I think we've occasionally worked on personal branches with multiple
people. GNOME / GTK / GLib is an example of a big project where there
numerous work-in-progress branches, some of which are personal (i.e.
have a username in them). I'm not following what they do closely this
days but that seems to work fine for them.

> > Personal branches are a perfectly fine way
> > to use Git. Easy merging, no fiddling with multiple remotes, no
> > admin overhead. You'll have to try very hard to convince me of the
> > downsides. ;)
> 
> Then why do big projects avoid them like the plague? These kinds of
> branches don't scale. I have 32 branches in my personal git.git
> repository, if I and everyone contributing to Git pushed their
> personal branches to the main repository, we would have hundreds of
> them, it would be a huge mess.

One thing to perhaps clarify is that Xfce is not a big project compared
to something like Git or Linux. With ~1-3 people maintaining most of
the core components being able to only work on a few things in
parallel, how many branches do you really expect?

I count 15 for xfce4-panel, one of the most actively maintained
components. Most components average around that number with about 2-3
different users having personal branches.

Even 50 branches in our repositories would scale fine. Git refs are so
lightweight, as you should know from working on Git. Would having 2-3
different repositories for each component make things simpler? I
personally doubt it.

> And what admin overhead? The admin doesn't have to move a finger, it's
> the user that creates those repositories, and it's extremely easy.
> Here are the instructions from freedesktop.org:
> 
> http://www.freedesktop.org/wiki/Infrastructure/git/RepositoryAdmin/

That's not how our servers are set up currently. It's why I said the
decision is up to those maintaining Xfce actively, i.e. those
who'd be in charge of adjusting the infrastructure.

  - Jannis