Re: why is git destructive by default? (i suggest it not be!)

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 24, 2008, 23:07 UTC
Message-ID: <7vod5qa0tu.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080624225442.GA20361@mit.edu>

Theodore Tso <tytso@mit.edu> writes:

Show 27 quoted lines

> The main reason that I find for reusing a branch name is for my
> integration branch.  I have a script which basically does:
>
> git checkout integration
> git reset --hard origin
> git merge branch-A
> git merge branch-B
> git merge branch-C
> git merge branch-D
>
> I suppose I could have avoided the use of git reset with something
> like this:
>
> git update-index --refresh --unmerged > /dev/null
> if git diff-index --name-only HEAD | read dummy; then
> 	echo "There are local changes; refusing to build integration branch!"
> 	exit 1
> fi
> git update-ref refs/heads/integration origin
> git checkout integration
> git merge branch-A
> git merge branch-B
> git merge branch-C
> git merge branch-D
>
> Instead, I've just learned to be careful and my use of git reset
> --hard is mainly for historical reasons.

This makes it sound as if avoiding "reset --hard" is a good thing, but I do not understand why.

The reason you have the diff-index check in the second sequence is because update-ref does not have the "local changes" check either. You could have used the same diff-index check in front of "reset --hard".

Moreover, in your original sequence above, doesn't "git checkout integration" list your local changes when you have any, and wouldn't that be a clue enough that the next "reset --hard origin" would discard them?

Show 5 quoted lines

> ...  But the point is, I can very
> easily think of workflows where it makes sense to reuse a branch name,
> most of them having to do with creating integration branches which are
> basically throwaways after I am done testing or building that combined
> tree.

Absolutely.