Re: [gentoo-dev] Re: Git workflow
William Hubbs wrote: I think I understand what he's asking for... I think he is asking the question, What changed in commit hash. If you use the hash of a merge commit with git show, you get nothing, so the merge commit is useless in terms of following changes. I have explained why merge commits are often empty and what you need to ask the Git data model for in order to view each of the changes that lead up to the merge commit. There is even a shorthand for it; the ^ suffix: git show mergecommit^1 shows the last commit on the first branch, git show mergecommit^2 shows the last commit on the second branch, etc. Understanding the Git data model is critical in order to wrap head around the fact that a merge commit ideally does *not* contain any modifications. Modifications (patches if you will) come before the merge commit, on the respective merged branches. C Bergström wrote: I have responded to every point - 1 by 1, but the passionate people (most polite term I can find) Nice one! I knew you too could do subtle insults. haven't addressed most of the problems or why commit reordering is a particular problem in gentoo's typical case. Me and others have actually explained the problems exhaustively. I don't know why you don't understand the explanations and you don't say why, so we arrive at a halt. That's fine, the thread is just treading water anyway. :) Kind regards //Peter
Re: [gentoo-dev] Re: Git workflow
On 7 July 2015 at 01:48, Peter Stuge pe...@stuge.se wrote: fact that a merge commit ideally does *not* contain any modifications. That's not /entirely/ true. The merge commit will have a new TREE object which is a composite TREE object of both of its PARENT TREE objects ( But all BLOBs in the resulting TREE will have existed on one of the parents as-is ) But as I mentioned in another reply, there's no way to view only the treewise diffs in a format suitable for diff, because diffs pertain to file contents, not SHA1s of BLOBs and SHA1s of TREEs. And yes, Ideally is where it gets messy. Non-Ideal commits have *new* BLOB objects that don't exist on either parent, and these can be hard to deal with. There's additionally lots of git tools that use the merge infrastructure to create non-merge commits with multiple parents. ( Git subtree for instance ), and some of them may inject *files* into the tree that don't exist in either parent, or entirely re-order the structure of one of the parents before applying it to master. The problem with those merge commits is those commits contain a significant amount of state in the merge itself, such that you cannot trivially recreate the merge commit from either of its parents alone. You can additionally turn any existing commit into one with two parents without changing the commits own changes, simply by abusing the model and git grafts and telling git This commit now has two parents. Git goes Sure, I'll put that SHA1 there and make no other changes. -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: Git workflow
On 5 July 2015 at 17:03, C Bergström cbergst...@pathscale.com wrote:
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.
Generally its better to structure the tree in the order it *should*
happen, not the order it *did* happen.
[intentional sillyness: ] If we were to order the tree in the way it
*did* happen, we'd have to work out when which person thought about
which idea first and what they were looking at when they thought of
that, and re-arrange commits to suit that order. {/instentional
sillyness]
Obviously that would be silly.
Generally however that does suggest, that where it is possible to, and
where it is logical to do so, commit squashing and commit re-ordering
is valueable.
For instance, if you commit something locally, and then you realise
you made a trivial mistake 3 commits later, it is better to create the
fix, and move that fix back to when the commit it pertained to. Nobody
wants to wade through dedicated commits where you fix up your mistakes
in minor syntax errors if you can actually avoid that in the first
place.
This also lends its hand to commit oriented testing, as it allows the
pushed trees to always be pristine, and have clean lines of history
that each commit on a given line can be expected to be used
independently, and be expected to be sane, instead of the commit
walker having to isolate the good commits and the bad commits that get
fixed 3 commits later.
The trick is not to be dogmatic about it, and identify the cases where
different things work out to be best, and use your judgement to work
out which one works best.
Rebases and merges were designed to be used in the same repository for
the most part, the only caveat being that any place you perform a
merge, performing a subsequent rebase of that merge gets tricky.
Merges are also convenient for merge reversals if they prove to be
neccessary, because you can just create HEAD with HEAD~3's tree and
you've reverted the whole merge, instead of having to work our where
the massive rebase line started and ended before it was applied
nuclearly and needing reversion ( somehow ). Granted this use case is
expected to be incredibly rare, but its just a demonstration of how
merge can be a help more than a hinderance in specific cases.
Oh, and as for merge commits and not needing patches ... that's
viable. Git is not really patch oriented. Patches are more a view
of the data than the state of the data.
A clean merge just creates a new tree object by duplicating the tree
of HEAD^ where a child leaf is replaced with child leaves from HEAD^^
in a recursive fashion, and any patch as such would be garbage
simply showing a list of SHA1's with +/- on the front of them which
you couldn't directly use.
You could attempt to format that as a patch, but it would be basically
`git diff HEAD^ HEAD^^` with some special rules ( It really doesn't
map directly to diff, there's 3-way-diff format as well, but ... yeah
).
And non-clean merges are a bit of a dogs breakfast and can be a right
pain in the arse if somebody hits them in a rebase. I've just tried to
avoid those because they're too hard, and prefer to find a way to
resolve them in either HEAD^ or HEAD^^ first before merging to make
sure the merge is clean.
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: Git workflow
On Sun, Jul 05, 2015 at 12:03:29PM +0700, C Bergström wrote: 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 So this isn't a good comparison. You are asking for a merge commit in git and a normal commit in svn. Svn can branch but it is so complicated that no one ever does it. If you were similarly to never ever make branches in git its not a huge deal. (There are not *that* many pushes to the tree, if you look at #gentoo-commits there is plenty of time between commits.) While I personally rebase almost all of my stuff, merges are important when taking contributions. A good example would be the main linux kernel tree, if Linus were to merge everything it would be incredibly difficult to figure anything out. -- Jason
Re: [gentoo-dev] Re: Git workflow
On Sun, Jul 05, 2015 at 07:17:26PM +0400, Jason Zaman wrote: On Sun, Jul 05, 2015 at 12:03:29PM +0700, C Bergström wrote: 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 So this isn't a good comparison. You are asking for a merge commit in git and a normal commit in svn. Svn can branch but it is so complicated that no one ever does it. If you were similarly to never ever make branches in git its not a huge deal. (There are not *that* many pushes to the tree, if you look at #gentoo-commits there is plenty of time between commits.) While I personally rebase almost all of my stuff, merges are important when taking contributions. A good example would be the main linux kernel tree, if Linus were to merge everything it would be incredibly difficult to figure anything out. I'm with Duncan on this. I think I understand what he's asking for... I think he is asking the question, What changed in commit hash. If you use the hash of a merge commit with git show, you get nothing, so the merge commit is useless in terms of following changes. William signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Git workflow
On Mon, Jul 6, 2015 at 2:15 AM, William Hubbs willi...@gentoo.org wrote: On Sun, Jul 05, 2015 at 07:17:26PM +0400, Jason Zaman wrote: On Sun, Jul 05, 2015 at 12:03:29PM +0700, C Bergström wrote: 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 So this isn't a good comparison. You are asking for a merge commit in git and a normal commit in svn. Svn can branch but it is so complicated that no one ever does it. If you were similarly to never ever make branches in git its not a huge deal. (There are not *that* many pushes to the tree, if you look at #gentoo-commits there is plenty of time between commits.) While I personally rebase almost all of my stuff, merges are important when taking contributions. A good example would be the main linux kernel tree, if Linus were to merge everything it would be incredibly difficult to figure anything out. I'm with Duncan on this. I think I understand what he's asking for... I think he is asking the question, What changed in commit hash. If you use the hash of a merge commit with git show, you get nothing, so the merge commit is useless in terms of following changes. That comment was from me (not Duncan) I have responded to every point - 1 by 1, but the passionate people (most polite term I can find) haven't addressed most of the problems or why commit reordering is a particular problem in gentoo's typical case. To avoid the ire of the bystanders - I'm out of this thread and maybe those with more tact and tolerance carry this forward.
Re: [gentoo-dev] Re: Git workflow
On 6 July 2015 at 07:15, William Hubbs willi...@gentoo.org wrote: If you use the hash of a merge commit with git show, you get nothing, so the merge commit is useless in terms of following changes. git show SHA1 -m -- Kent KENTNL - https://metacpan.org/author/KENTNL
Re: [gentoo-dev] Re: Git workflow
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.
