Hi, Matthias!

On Thu, 2005-04-21 at 23:31 +1000, Matthias Urlichs wrote:
> "git cancel" may not be named correctly for this job, but it does almost
> everything you'd need for switching between one branch and another
> within a repository, so...

This functionality is badly needed, but "git cancel" should probably
remain what it is.

> +if [ "$1" ] ; then
> +     test -f .git/heads/$1 || cp .git/HEAD .git/heads/$1
> +     ln -sf "heads/$1" .git/HEAD
> +fi

Considering that the patch is essentially just this block of code, it
could be (in the first approximation) a separate command, e.g. "git
switch", that would call "git cancel" if needed.

But let's consider the fact that "git cancel" removes all local changes.
That's quite a serious side effect.  I don't always want to remove local
changes when I switch between branches in CVS.  Many users would prefer
git to do a merge.

I think that "git track" needs to be redesigned.  There are at least
three properties of the working directory (related to branch tracking)
that users may want to change:

1) Where new revisions are pulled from.  It could be more than one
branch (ideal implementation - with several copies of rsync run

2) What branch is "checked out" to the working directory, i.e. what
branch would "git cancel" restore.

3) Whether new changes are merged automatically.

I suggest following syntax:

git track -b WORKING-BRANCH [--cancel] [--active|--passive]

--cancel would cancel changes rather than merge when the current branch

--active enables automerge, --passive disables it

Empty list of branches to track should not disable tracking.  Only
--notrack should do it.

Then your "git cancel BRANCH" would become:
git track -b BRANCH --cancel

Pavel Roskin

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to