Stop the git abuse

Simo Sorce simo at redhat.com
Fri May 18 18:35:00 UTC 2012


On Fri, 2012-05-18 at 18:35 +0200, Stanislav Ochotnicky wrote:
> I've been seeing this ugliness more and more to the point where I just
> can't keep writing individual emails. Repeat after me: git is not CVS.
> 
> When you have 2 branches with identical content and history (typically
> right after branching or when the maintainer is updating all releases
> together) then DO NOT manually redo fix for every branch. Do not even
> use cherry-pick! Just *merge* for the love of whatever is holy to you.
> 
> $ git checkout master (or fedpkg switch-branch)
> ... do a fix, test, commit, build etc...
> $ git checkout f17 
> $ git merge master
> $ git/fedpkg push && fedpkg build
> DONE

This is really a personal preference.
For example I really *hate* merges, they clutter everything.

> If the branches are in sync you just saved yourself few minutes. More
> importantly you have saved other people like me heap of time because I
> will not have to wonder what is different in each branch suddenly. Hint:
> in 99% cases nothing. It could still nice linear history. And then there
> are those gems where while doing manual fixes you introduce typos and
> bugs (yes, it happenes).

git diff is all you need to check if there are differences, merges tell
you nothing about that, and merges canj *hide* changes you were supposed
*not to* bring from one branch to the other.
So really this is pretty much personal preference, and each maintainer
should be allowed to use the scheme they prefer.

(and co-maintainers or proven packages should be careful of keeping the
same style IMO)

> Example: http://sochotni.fedorapeople.org/ugly-git-history.png
> F16, F17 and rawhide could be the same commmit and just few commits
> ahead of F15. But the way it was done, it's not obvious that F17 has a
> typo causing problems.

cherry-picking should have been used in this case.

> So please. Merge as long as it makes sense (i.e. unless something needs
> to be changed specifically in one branch).

About this I wonder if we should have the preference stated somewehere
in the git tree for each package so that it is clear what is the
maintainer style.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York



More information about the devel mailing list