Theodore Tso <tytso@mit.edu> writes:

quoted text
> 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?

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