In <[email protected]>, Oswald Buddenhagen wrote: >On Wed, Feb 09, 2011 at 02:27:31AM -0600, Boyd Stephen Smith Jr. wrote: >> I agree with your definition of a good history, but git does no favors by >> automatically committing merges. The merge is another state and needs to >> be tested before it is actually committed. > >you can amend a merge like any other commit.
You can also use the --no-commit option to git merge. Still, I'm pretty sure I prefer the bazaar behavior of requiring a explicit commit after a merge, even a clean/trivial one. >but i don't agree with the definition in 99% of the cases, because >rebasing is usually a trivial operation, and there is no reason to >believe the rebased commits would behave differently than the original >ones when the end result is still correct. While that's true in 99% of the cases, it's the cases where that's not true where rebase gets you in trouble. Same thing is true about trivial merge commits. Both ensure that the textual changes are consistent, but they don't say anything about the semantic changes that may have happened in either set of commits. >when the rebasing causes >non-trivial conflicts, you have a point. other than that, merges of >short branches are only useful as "markers" (which is utterly pointless >in the by far most cases, as the branches are just one or two commits >long after they have been properly reshaped). Having the correct branch points, even for branches that are one or two commits long, can be useful both for automated tools like git bisect and for users that may want to use "just enough development code" for a critical (to them) feature their stable software is missing. In both cases, it is only an incremental improvement, true. Using a merge-based workflow instead of a rebase-based workflow makes it easier to share changes. (Since SHA1s rarely change.) It is also good practice for when your branch suddenly becomes long-lived or contains sub- branches and rebase becomes troublesome or downright unworkable. If you want Git to behave like CVS or SVN, then by all means, rebase all the time. If you want to benefit from some of the features of distributed development, it is best to avoid rebase when possible. (It can be quite a good tool for rewriting bad commits.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. [email protected] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
