Git convention to indicate throw away branches

Question

Scenario:

Person A creates an experimental branch to solve a problem. Person B gets interested and wants to check the code, due to laziness person A pushes to his github rather than configuring his workstation to let person B pull directly from him.

A and B is hacking away, person C sees the activity on github and clones, eager to check out whats going on. Meanwhile A and B concludes its a horribly solution and deletes the branch. But person C manages to turn the idea into something great and wants to share. Merging hell begins as C's branch no longer have a common ancestor with his merge target.

---

Im curios to see how this scenario should have been handled.

• Is there an accepted naming convention for branches to indicate that - even though pushed - this branch may very well be completely oblitered. A way for person A to indicate that "if you pull from this, I cannot guarantee continued happiness".
• Or is there even a way (command) in git that lets me sort of tag branches as throw away?
• Is it simply never, regardless of circumstances, accepted to alter a git history if someone could have pulled from it?
• Should person A have taken the time to properly configure his workstation to let person B pull directly from him? Thus going in the dark, not letting anyone else know what they are working on.
• Maybe the only viable solution is good old fashioned communication; just talk to you peers.

And if all else fails, what is the proper strategy for person C in this case? How can the changes be properly applied when your work is done in a disconnected graph?

Answer 1

There is no formal convention yet.

One good example of throw-away branch (mentioned in this article on Git rebase from March 2010) is branch pu of git.git.

The Git FAQ details:

The "pu" branch often won't fast forward because some commits have been completely deleted in it since the last time you pulled.

If you want to track it, add a plus (+) sign to the proper line in your .git/config file, like this:

[remote "origin"]
        fetch = +refs/heads/pu:refs/remotes/origin/pu

Which tells git to deal with the problem for you by simply skip the fast forward check (overwriting your old ref with the new one).
Or you can just delete that line completely if you don't want to track the pu branch at all.

It is conceivable that in future versions of git we might want to be able to mark some branches "this is expected to be rewound" explicitly and make the clone operation to take notice, to give you the plus sign automatically.

So one idea is to actively prevents (through hooks) any push to those throw-away branches making them:

• read-only
• only updated by one administrator.