Improving Git workflow

[Felipe Contreras]

On Wed, Oct 9, 2013 at 6:18 PM, Jannis Pohlmann <jannis at xfce.org> wrote:
> Hi,
>
> On Wed, 9 Oct 2013 17:04:14 -0500
> Felipe Contreras <felipe.contreras at gmail.com> wrote:
>
>> To visualize the changes in these two branches and nothing else, I run
>> this command:
>>
>> % gitk xfce-4.10...master
>
> I'm not sure this makes a lot of sense. xfce-4.10 and master have a
> common root (the commit at which the xfce-4.10 branch was created) but
> after that they no longer necessarily share history; e.g. commits that
> have been cherry-picked from master into xfce-4.10 may have a different
> SHA1 and thus may show up in the xfce-4.10..master comparison even
> though they are actually present in both branches.

This is not xfce-4.10..master, this is xfce-4.10...master, with three
dots, which shows all the 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:

@@ -1,71 +1,25 @@
-I18n: Update translation is (86%).
-I18n: Update translation zh_TW (100%).
-I18n: Add new translation zh_HK (100%).
-I18n: Update translation it (100%).
-I18n: Update translation de (100%).
-I18n: Update translation bg (100%).
-I18n: Update translation is (83%).
-I18n: Update translation es (83%).
-I18n: Update translation nl (100%).
-I18n: Update translation tr (100%).
-I18n: Update translation es (76%).
-I18n: Update translation tr (93%).
-I18n: Add new translation hr (58%).
-I18n: Update translation zh_CN (100%).
-I18n: Update translation ar (100%).
-I18n: Add new translation uk (100%).
-I18n: Update translation hu (100%).
-I18n: Update translation pt (100%).
-I18n: Update translation en_GB (100%).
-I18n: Update translation th (100%).
-I18n: Update translation pl (99%).
-I18n: Update translation ru (100%).
-I18n: Add new translation th (51%).
-I18n: Update translation kk (100%).
-I18n: Update translation es (73%).
-I18n: Update translation it (99%).
-I18n: Update translation es (69%).
-I18n: Update translation id (100%).
-I18n: Update translation es (65%).
-I18n: Update translation tr (93%).
-I18n: Update translation he (100%).
-I18n: Update translation fr (100%).
+Merge branch 'l10n'
 Use new GarconGtkMenu.
-I18n: Update translation nl (100%).
-I18n: Update translation ko (100%).
-I18n: Update translation es (65%).
-I18n: Update translation ug (100%).
-I18n: Update translation ru (99%).
-I18n: Update translation pt_BR (100%).
-I18n: Update translation fr (100%).
-I18n: Update translation es (60%).
-I18n: Update translation en_AU (100%).
-I18n: Update translation bg (100%).
+Merge branch 'l10n'
 Bump all glade gtk versions to 2.24.
 Tasklist: Make middle-click action configurable.
-I18n: Update translation es (59%).
-I18n: Add new translation en_AU (100%).
+Merge branch 'l10n'
 Directorymenu: Pass path to argument (bug #10270).
-I18n: Update translation zh_CN (100%).
-I18n: Add new translation es (56%).
-I18n: Update translation da (99%).
-I18n: Update translation en_GB (100%).
-I18n: Update translation ug (100%).
-I18n: Update translation zh_CN (99%).
-I18n: Update translation bg (100%).
-I18n: Update translation zh_TW (100%).
-I18n: Add new translation nn (99%).
-I18n: Add new translation it (99%).
-I18n: Remove broken / unsupported translations.
+Merge branch 'l10n'
 Tasklist: Pushed a patch for #8096 (close a window on middle click)
+Merge branch 'l10n'
 ApplicationsMenu: support for non-square icons and layout fixes
 ApplicationsMenu: Update the icon in the config dialog
 Bugfix in icon/pixbuf resizing code.
 Install XfcePanelPlugin properties at once.
+Merge branch 'l10n'
 Only use names from the /posix directory.
 Add completion for zoneinfo names.
+Merge branch 'l10n'
 Clock: Improve tooltips, plug leaks and fix glade layout.
+Merge branch 'l10n'
 Clock plugin: removed a warning message.
+Merge branch 'l10n'
 Clock plugin: make the calendar popup modal again.
 Clock plugin: fix double-click behavior when a command is set.
 Clock plugin, updated information in tooltips.
@@ -79,7 +33,9 @@
 Clock plugin: added a simple timezone selection UI.
 Clock plugin: proper timezone support and refactoring.
 Added a timezone property to the clock plugin.
+Merge branch 'l10n'
 Merge branch 'andrzejr/clock'
+Merge branch 'l10n'
 Removed "show-frame" property.
 Removed frame object and all references to it.
 Adding a possibility to close the calendar popup with "Esc"
@@ -87,15 +43,23 @@
 Revert "Hide calendar window on <Esc> or mouse press outside the popup."
 Fix icons not probably resizing when requested.
 Hide calendar window on <Esc> or mouse press outside the popup.
+Merge branch 'l10n'
 Autotools updates.
-Remove unmaintained translations.
+Merge branch 'l10n'
 Put each window in a new window group.
 Ignore GVarueArray compiler warning.
+Merge branch 'l10n'
 Use G_ENABLE_DEBUG to set fatal messages.
+Merge branch 'l10n'
 Fixed DnD markers with non-square small items.
+Merge branch 'l10n'
 Tasklist: Remove binding for blinking buttons, no UI for this.
+Merge branch 'l10n'
 Tasklist: Show urgent windows from other workspaces (bug #5167).
 Clock: Add calendar popup to clock plugin (bug #9034).
 Actions: Fix logic of session saving (bug #8857).
+Merge branch 'l10n'
 Panel: Emit save signal for plugins.
+Merge branch 'l10n'
 Libxfce4-panel: Fix typo in the API docs.
+Merge branch 'l10n'

And you can't do that grep stuff with gitk.

>> 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.

>> 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.

>> 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're using Git here, not bzr (where, I believe every branch is
> essentially a separate repository?),

I do believe the git.git project uses Git as well, and they don't have
personal branches lying around either. And for a good reason.

> 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:
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.

> 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.

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/

But those are outdated, and you don't have HTTP links, plus it can be
cleaned up too:

git init --bare repo-name.git
cd repo-name.git
touch git-daemon-export-ok
vim description

Of course you don't *need* to write a description, and if you used the
smart HTTP protocol, you wouldn't even need the git-daemon, so it
would require a single command.

If the setup is what worries you, what exactly is the problem with
running one single command?

You also don't need to fiddle with multiple remotes and it's easy to
merge those branches. This is how I merge a branch from another guy's
repository:

% git pull gh:otherdude/project feature-a

Done.

>> This is not some random rant. I'm willing to help you guys in the
>> transition if you are interested, and even provide scripts if needed.
>> Also, I can provide the patches for the automatic version bumps.
>>
>> What do you think?
>
> Thanks for your feedback. I can see how merging translations in might
> make things a bit cleaner. The decision is up to Nick and the other
> active contributors though. I'm just throwing my opinion in for the fun
> of it. ;)

Thanks for your feedback, I'm throwing my feedback on your feedback :)

-- 
Felipe Contreras