Manoj Srivastava wrote: >> This is all very interesting; I don't think anyone should doubt that >> conflicts arise. I think this sub-thread started with the desire to >> have a moving merge commit that got re-written. With git you could >> > I have no idea what you just said; so I couldn't possibly have > been participating in a discussion about that. >
I'm referring to this: > The problem I see with temoprary merge branches is that it would > seem that any conflicts between topic branches would have to be > resolved every single time we have a new upstream; I would find that an > unacceptable burden. All I was pointing out was that the method with which you produce the merged tree doesn't have to correspond to how it is recorded in the history. It's not that complicated, really. > What intermediate merge commits? My current workflow is somewhat > like ยง5.4 on the page: > http://www.golden-gryphon.com/software/misc/packaging.html > except that I never to the rebase bit until I am ready to submit the > patch upstream. > > Does that explain the use case? > I'm referring to the problem you describe in slide 5.1. In a sense, you throw away the merge commits before applying the new change, but keep the tree. So, you end up with a single merge commit for each topic branch without having to rebase all the time, reducing the (subjectively described) "clutter". You're doing some things vaguely like this in your slide 5.3, if a little haphazardly. I'm sorry if these terms make little sense, if they don't I suggest chapter 7 of the Git User Manual that describes the object database. It's a good half hour investment of learning that will make working with git feel much less mystifying. It probably makes sense to make sure that TopGit can deal with the use cases you describe; it possibly is most of the way there already... Martin? Sam. _______________________________________________ vcs-pkg-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
