Re: git versus CVS (versus bk)

[Joel Becker <Joel.Becker@oracle.com>]

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