Thanks. That certainly puts some specifics on the table. On Wed, Feb 3, 2010 at 5:45 PM, Todd Zullinger <[email protected]> wrote: > Markus Roberts wrote: >> P.S. On a related subject: I'm close to advocating a total ban on >> merge commits as opposed to rebasing / cherry-picking. Merge >> commits in git are. IMHO, seriously broken (a significant fraction >> of the tools "ignore" them and many of the ones that don't simply >> act up when they encounter one). >> >> Can anyone give a cogent reason why they are a good thing, or show >> me the error of my ways? > > Well, if you use rebasing and cherry-picking you are creating new > commits rather than applying the existing commits as a merge would do. > This removes much of git's ability to track which commits have been > merged and which have not. > > In an ideal world, you would be able to use git 0.25.x...master which > would show you commits that only in either 0.25.x or master but not > both, which would illustrate things that needed to be merged. (Note > that three dots is different than two here.) > > Merges are preferable to cherry-picking¹ due to the ability it adds > for git to track. And rebasing is something that should only be used > on branches that are not public, generally. This might not be as true > for a testing branch, but it definitely holds for master and other > stable branches -- those should _never_ be rebased. :)
Our idea is to have the topic branches be rebased in succession onto testing (which is a mercurial/throwaway branch), producing a clean series of commits that can be tested and the prefix of which can be promoted to master once it is deemed worthy. While I see your point about the commits not having the same md5 hashes (and thus not being the same objects) I'm not sure I see the benefit of maintaining commit identity--I've never used any of the commit tracking techniques you mention. Still, all the other information is retained and the order of application seems sane/consistent, which is more than seems to be the case with merge. What I do do a lot of is history delving (logs, bisects, reversions, interactive rebasing on working branches, diff, etc.) and the merge commits seem to play havoc with these. Git rebase "ignores" them with sometimes disastrously confusing results. Diff (and related commands such as format-patch) will sometimes omit the conflict resolution changes they contain. And I'm not sure _what_ git bisect does when it hits one, but it doesn't seem useful. It is possible that I'm missing an epiphany here, and also possible that my use of git is aberrant, so anyone who's read this far and has an additional insight/perspective/use case or whatever should feel free to chime in. > Also worth a read (if you haven't stumbled across it already is the > "maintain-git" howto², which describes in some detail how git.git is > managed. As git.git generally has a large number of topics in flight > it may well serve as a good guide. The 'pu' and 'next' branches in > git.git sound a lot like what you're aiming for with a 'testing' > branch. I've glanced at it, and it may be a better model than the linux kernel lore we've been using, though they seem reasonably similar in spirit. > All that said, you don't want end users pushing merge commits to you, > as that is nothing but noise and confusion I believe. Folks > submitting patches or asking you to pull should provide a branch > rebased against whatever topic branch they want their work applied on. > If that's what you mean by banning merge commits, then that sounds > good. :) I definitely don't want contributors pushing merge commits; my thought is that they probably don't want us doing it to them either. > (I should of course note that I don't have any direct experience > managing a large git repository, so what I write is based on my > reading of the documentation and the git list. So keep that in mind > when weighing my opinions. ;) Nor do I, though I'm in the process of acquiring some by the standard painful process if trial and Ouch! -- Markus -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
