On Mon, Oct 31, 2005 at 04:20:51PM -0800, Junio C Hamano wrote: > After extracting a sequence of the dirty commits using > git-format-patch, I would say: > for i in 0*.txt; do git-apply --index $i; done > to bring my tree up to date, and then just say "git commit". Yeah, but this is a lot of by-hand (as you note below). > Typically when I do this, I have one "significant" commit among > them, usually early in the series, which is followed by smaller > "fix this, fix that, oops fix that too" commits. So I edit the > log message using the log of the significant commit, and add > some missing bits. When I work, regardless of SCM, I generally have many checkpoints along the way. It might be a particular subfeature is complete (and probably deserves a split-out patch of its own when I do the "clean" merge), but it could also just be "I changed a lot today, and I'd really like to save that off." So, while somtimes it looks just like your "significant commit + fixes" model, it might also be "1/4 the work", "compile fix on other platform, "1/2 the work", "fix", "the rest of the work", all over the course of two days. > $ git-read-tree -m -u master mytopic > $ git-commit -c <that-significant-commit-in-mytopic-branch> Replace <that-...> with <overall-concept-of-the-change> and you have the workflow I'm talking about. You know, this is a simpler command set than I am using. I've been using Cogito, because it makes many of the 5-step git operations a single step, more like some other tools. But I know no way to tell Cogito to merge all the changes of the branch into the master without also pulling in the commit history. That's the thing here. Petr, do you have a way of doing this that I don't know about? What I mean is, for the "naive" Cogito workflow: cg-clone repo working cd working hack hack hack, commit commit commit cd mainline cg-pull working the cg-pull command merges the changes back, but it also includes the full commit history. Not what we want. Compare the "identical" workflow: cg-clone repo working cd working hack hack hack, commit commit commit cg-diff mainline working > patch cd mainline cg-apply < patch cg-commit My basic premise is that I shouldn't have to deal with diff/patch as an external step, especially since git knows more about the tree than diff/patch do. It's a useless hoop to jump through. Maybe Cogito contains something like what you describe above, a way to get all the file changes without actually pulling in the commit history. I don't care that the read-tree and the commit are separate stages. I just have to type them. > is possible) offhand. Sometimes, when you want truly logical > steps, you would end up needing intermediate steps that never > existed in your true history (i.e. "in the hindsight, my > development should have progressed in these steps.") Yes, I always do. But I'm not talking about that sort of large feature add or whatever. I'm talking about merely doing something on a small scale, but in a temporary repository. Joel -- Life's Little Instruction Book #510 "Count your blessings." 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 11:43:45 2005
This archive was generated by hypermail 2.1.8 : 2005-11-01 11:43:50 EST