On Mon, Oct 31, 2005 at 02:14:58PM -0800, Junio C Hamano wrote: > I think you read me wrong. Didn't I say "decompose and make > them into logical stepS", emphasis on plural "S"? > > Single big consolidated patch is not what I am advocating for. > It is impossible to review and evaluate. To be merged into a > public tree, such unhistoried commit is often unacceptable. No, you're reading me wrong, but I wasn't clear enough either. At the end of my message, I'm noting that I'm considering smaller changes here, not huge features. Basically, I'm not talking about merging with Linus. I'm talking about merging with myself. Let's assume we're all going with the clean-up-your-history model. It is quite clear that you and Linus agree on that model, and I wasn't so much arguing against it as querying everyone's opinion on it. So, I have a git repository that is my For-Linus repository. It's got a clean history. What's my workflow? 1) Clone the repo to a Work tree. 2) Create and test fix X, with perhaps some >1 number of commits. 3) Bring that fix back to the For-Linus repository. This is a small change. It's not something that needs stepS, as you put them. But my history in the Work tree is "dirty," so I cannot just pull from Work to For-Linus. As the tools currently stand, I need to hand-diff and patch my commits. Neither git nor cogito have a command to do this first-class "the way you should do it" common operation. It is, in my experience, a pain. Not as large a pain as some things, but certainly second class to much of the workflow git/cogito provide. If it is supposed to be a regular part of my workflow, what's wrong with making it a first-class operation? Obviously, large features should and do have logical steps. I'm never going to be against that. Joel -- Life's Little Instruction Book #15 "Own a great stereo system." Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Tue Nov 01 10:33:39 2005
This archive was generated by hypermail 2.1.8 : 2005-11-01 10:33:43 EST