Re: git versus CVS (versus bk)

Joel Becker <Joel.Becker@oracle.com> writes:

> 	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.

OK.  Consolidating two or more patches into one is something I
have done too, but I never felt need for tool support, so that's
probably why I misunderstood you.

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".

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.

I guess another way to do it without even first extracting them
as patches would be:

        $ git checkout -b mytopic master
        $ work work work, commit commit commit.
        $ git checkout master
        $ git-read-tree -m -u master mytopic
        $ git-commit -c <that-significant-commit-in-mytopic-branch>

If you want a tool support for this workflow, probably the last
two could be somewhat automated.  But what would the user input
for that be?  You need to tell what tree shape you want the
after-commit tree to be in, and where you would want the bulk of
your commit message to come from.

One possibility.

        $ git-squash-pick mytopic

would be something like this:

	#!/bin/sh
        #
        git-read-tree -m -u HEAD "$1"
        git log HEAD.."$1" >.tmp-commit
        git-commit -F .tmp-commit -e

Your commit-log edit buffer would start with the concatenation
of all the commit logs in that throwaway history, and hopefully
you would mostly need to delete lines and move some parts around
before committing.  I do not know how useful this kind of
specialized tool would be, though...

Splitting and merging patches into logical steps is something I
dream of to be automated, but I do not know how (nor even if it
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.")



	

-
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.html