Theodore Tso <tytso@xxxxxxx> writes: > 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? > ... 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
