On Sun, Jul 5, 2015 at 11:31 AM, Duncan <1i5t5.dun...@cox.net> wrote: > 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.
we are not talking about the same thing. I want to see the "diff" - not the graph. svn diff -r 1234 git show <hash> show me the "merge" commit in diff format > > 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. Your truth and my truth are are clearly not the same thing. You want to preserve (for some reason) the original commit+date+original parent. To me, development is not "done" at that point. It's just getting started. It's not done in my mind until it's ready to be pushed. For something simple it doesn't really matter does it? I do see your point - I just think in the gentoo model it's unlikely to be relevant WHY is the original parent so important? If someone is working in foo/ category of ebuilds and you're working in bar/ - the parent commit is in all probability in a different category. The original parent commit probably has no value.. (who cares!! honest question) > > 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? Huh? Git is "nice" because it's distributed. Using rebase doesn't take away any of the benefits to that. 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!)? This is a passionate reply, but it's not very accurate. nail gun vs screw driver? (really?) > > 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. Happiness is a state of mind - if this conflicts so strongly with a relgious view - sure I could see it being such a burden. Is doing git pull --rebase before you push really so bad? > > (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.) Again I don't see it as "lying" - (you're still working on stuff until you push.. development isn't done) The ability to do micro or incremental commits instead of the svn's forced wait approach is the benefit here. Hopefully you could share those scripts with others. Making this workflow easier on everyone is a great thing. I've seen people alias this and I think there's ways in git config to do this as well.
