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

[Raja R Harinath]

Hi,

Avery Pennarun <apenwarr at gmail.com> writes:

> On Tue, Jul 27, 2010 at 3:11 PM, Raja R Harinath <harinath at hurrynot.org> wrote:
>> * clean up the main repos
[snip]
>> 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.

I think we mostly have the tags in place.  So, deleting the branches
should be OK.

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

Yep.  That's why I said "one-time only".

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

True.  Even now, it's "possible", but such a merge will show a lot more
conflicts since we have 100s of commits on the maintenance branches
since they forked off.

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

Exactly, it makes it easier on future merges.  Right now, if things are
as-is, we leave the burden to the first person who comes along and tries
the nice possibility.  The 100 commit merge conflict will teach the
wrong lesson, by scaring them away from using git the right way.

>> Basically, the workflow is to never[1] commit directly on a branch tracking
>> an origin branch.
[snip commands]
>
> I've personally found this workflow to be a lot of extra work for
> little gain, and certainly:

We've already seen issues with unintended (but safe) merges causing
confusion -- the confusion is exacerbated by the GitHub UI showing 'git
diff --first-parent' on merge commits, rather than something more symmetric.

There were also questions like: how to easily backport of the top three
_new_ commits on "master" to "mono-2-6", etc.  Having the top three
commits on a branch instead of directly on master would've made it
easier to guess at the right answer

       git rebase --onto mono-2-6 master fix

So, the "throwaway branch"-oriented workflow is useful in itself, even
without other workflow changes.

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

That's why this is an aside ;-)  But, your comment highlights again the
main good thing about the "fix on maint, merge to master" workflow.

- Hari