[gentoo-dev] Re: Git workflow

[Duncan]

C Bergström posted on Sun, 05 Jul 2015 01:17:41 +0700 as excerpted:

> I super don't like "merge" workflows.
> 1) "merge commits" are confusing at best and normal tools don't display
> and work with them as you'd always expect

git log --graph, as others have mentioned.

Works fine, at the console, is clear enough to follow, and is part of git 
itself and commonly used, so is definitely a "normal" tool for those 
using git.

FWIW, to follow kernel developments during the merge window, I'll  
actually run git log showing merges-only (generally confined to author 
linus, as well, which pretty effectively limits me to only the master 
merges).  The merge comments give me a summary of what was committed in 
that merge, and I can both skip entire merge categories after reading 
only the title or merged tree name, where they're not of interest, and 
drill down into merges if I find something covered there of particular 
interest.

> 2) merge commits lead to multiple parents, which breaks a clean and
> simple to follow linear history ---------

Ugh!  Development isn't linear if there's more than one person working on 
a shared tree and making commits to their respective local trees to be 
pushed later, at once, and making it appear linear is, plainly stated, a 
lie.  It's not clean and simple.  It's a lie, and maintaining a lie 
arguably always ends up more complex than simply stating the truth.

If you're not using one of the biggest and best features of git, its 
ability to accurately and clearly portray parallel development and where 
branches actually branched and merged, why are you using git in the first 
place?  Simply because it's used 'most everywhere else and thus people 
tend to have some familiarity with it?  That's not an invalid reason, of 
course, but if you have ten thousand nails to nail, and a nail gun 
plugged in and ready, why are you insisting on using a screwdriver to 
pound them in, instead?  If you're going to use a screwdriver, why not 
use screws and a screw gun (svn, I guess, its commits are even 
sequentially numbered, which ought to be heaven, by your definition!)?

To be clear, since the policy states rebase if possible, I'd do it, but 
I'd be internally grousing about it every single time, and that's not 
very conducive to remaining happy at one's job over a period of any 
significant length, absolutely critical if that job's a volunteer job.

(I'd probably deal with it by scripting it to the extent possible and do 
my best to forget about the horrible misuse of perfectly good tool 
resources, tho I'd be cursing every time I went to use git log and 
couldn't use it properly due to all the lying going on.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman