C Bergström wrote: > To start.... I hate git.. I have used it for years now and the > multitude of ways that are possible to accomplish nearly the same > thing are *annoying* at best..
I'd be interested to hear a couple of examples of what you mean, perhaps in a private mail. Tack på förhand. :) > I super don't like "merge" workflows. I personally also prefer to rebase, but merge also has strong merits. > 1) "merge commits" are confusing at best and normal tools don't > display and work with them as you'd always expect I'm sure you are absolutely right about the tools. I never bother with anything but the command line git client though, and I think it does a good job of dealing with merges. git log --graph > 2) merge commits lead to multiple parents, which breaks a clean and > simple to follow linear history This is either a bug or a feature depending on whether development was actually linear. Sometimes it is, but sometimes it isn't. The benefit of merge commits being so easy is that it allows a correct historical representation of what development happened when, based on what previous commit. > What I personally prefer is a rebase workflow. Yes, I too like rebasing. But if there is high enough activity in a repository it actually becomes impractical. > The downsides > 1) Requires to you rebase before pushing. Which can be slightly more > work than just a lazy resolution of the conflicting "merge commit" > (depending on if you flatten your commits) Please be more aware of what you're doing. Rebase actually comes with pretty large implications, you are changing the base upon which your work applies. Sometimes this is unproblematic. In those cases, git pull --rebase is just more work than git pull. (But there's git config branch.$name.rebase) The thing about requiring rebase is that things in the base may shift without you knowing it. You really have to do a very careful review of what has happened between the old and new base commit, to know for sure that your stack of commits is still correct at all. This can be a very heavy operation and it pretty much must be manual! Sometimes it's really easy to do this manually. The thing is, rebase does incur this extra manual operation, and it is non-negotiable. A history with merges has much richer information about what happened when, and actually makes it easier to figure out difficult problems. > 2) May not be the most popular git work-flow. > 3) Due to #2 from above - may have detractors and or less people > who are familiar with it. I consider it a much more powerful sword, which thus must be wielded much more carefully. > I'm of the mindset that if you're going to keep something under > revision - the history should be clear and clean. I agree that this is ideal, but it's also very easy to think of real world situations where it is just not practical, and would either result in stalling other developers or increasing the local workload before commit/push is possible, neither of which is desirable. I agree that tools can be a big issue. I would not suggest using anything other than the git command line program. //Peter
