[Mono-dev] The new world of Git -- what else can we change :-)

[Avery Pennarun]

On Tue, Jul 27, 2010 at 3:11 PM, Raja R Harinath <harinath at hurrynot.org> wrote:
> * clean up the main repos
>
> The source trees at github.com/mono/ have a lot of junk^W branches left
> over from the SVN days.  However, we mostly work on two or three main
> branches.  For instance, in the mono/ tree, we work on the unstable
> "master", the stable "mono-2-6" and very occassionally on "mono-2-4".
> So, looking at the 111 branches in the mono/ tree is annoying.  At first
> blush, I guess its pleasing from an code archeology standpoint, and
> pleasing in the sense of a job well done with the SVN import.  But, 111
> branches are distracting to work with -- they are a cognitive overload,
> interfere with command-line completion, and are terrible on the Github
> UI.
>
> My proposal is to
>
>   (a) create a read-only set of fork/clones at github.com/historic-mono
>   (b) remove all inactive branches from the repos in github.com/mono
>
> This might also reduce the cost of a fresh clone by a few MB :-)

Removing stuff from the main repo is kind of a shame if you don't have
to do it.  On one project I was working on, we simply went through all
the dead branches and created tags under attic/ for each one, then
deleted the branches.  This leaves you with some cruddy tags, but tags
are much easier to ignore than branches because you're mostly not
looking at them.

> Git allows a very nice workflow that works well if the tips of the
> maintenance branches are ancestors of the tip of development branch.
> Now, to enable this workflow, I propose to perform the following
> commits -- these are one-time only, and enable the nice workflow.
>
>       git checkout mono-2-6
>       git merge -s ours mono-2-4
>
>       git checkout master
>       git merge -s ours mono-2-6
>
> The '-s ours' ensures that the contents are not merged, only the branch
> ancestry is fixed.

Be very careful when using '-s ours'.  Usually git-svn isn't too bad
about figuring out the branch history, so it *may* be possible to do a
merge without -s ours, then figure out the conflicts, then move on.

That said, in general this can be an okay idea if you really want to
be able to do future merges from the release branches into master.

> Basically, the workflow is to never[1] commit directly on a branch tracking
> an origin branch.
>
>  git checkout master
>  <start playing around with the code>
>  <realize you're actually fixing bug 555555>
>
>  git checkout -b fix-bug-555555  # future commits happen on new branch 'fix-bug-555555'
>  <continue working, your working tree is still intact>
>  git commit
>  <work>
>  git commit
>  ...

I've personally found this workflow to be a lot of extra work for
little gain, and certainly:

> [2] The idea is that you should never[1] have a merge message that reads
>
>        "Merge from git at github.com/mono/mono:master"
>
>    That's useless.  All merges should either be fast-forwards, or look like
>
>        "Merge from fix-bug-555555"
>
>    IOW, eminently readable

This doesn't really make any difference.  Eventually you learn to
mostly just ignore merge commits anyway.  The real value isn't in the
merge commit, but in the stuff that it merges, and that's visible in
'git log'.

The bravest (sometimes dumbest) among us use "git log --no-merges" and
never look back :)

Have fun,

Avery