Hi, On Thu, 19 Apr 2007, Steven Grimm wrote: > Johannes Schindelin wrote: > > > Let me pick up the ball here. Once you did your share of conflicting > > merges, you _will_ realize how much better it is to merge when you are > > at a relatively stable state, i.e. you can test things (if only to > > make sure that the merge did not introduce strange side effects). And > > guess what, at such a stage I would commit anyway. > > That's a great workflow if you're working on relatively discrete, > standalone changes. A lot of the time, when I'm working on an isolated > change, I do just that, and I merge when I'm stable just like you > describe. That's probably the vastly most common mode of operation for > distributed open-source projects, which obviously were git's initial > target audience. It is also possible (and I do that) when merging often. I use cherry-pick for that. At a later stage, I merge, and this mostly succeeds, since the merge is really a 3-way merge (with the obvious results). > And out of curiosity, are you using git for distributed, relatively > autonomous development, or for collaboration with a high level of > interdependency between developers? I use Git virtually everywhere it can be used: - backups - personal projects - configuration files - documents - collaboration with other people - tracking CVS - ... Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html