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