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
