Git convention to indicate throw away branches

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 开发者_StackOverflow社区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?

---

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.

---

Merging hell begins as C's branch no longer have a common ancestor with his merge target.

Surely A's master branch has an ancestor (in its history) to the deleted branch.

C can push the branch to github where A can pull it again. What's wrong with that? or, C can do the merging/rebase in a new branch (on top of A's master) and, again, let A pull from him.

update (response to comments).

Deleting a branch doesn't actually rewrite history, at least not in a bad way that prevents merging.

I'm assuming person A had this kind of history:

a--b--c--d--e--f--g    master
      |
      x--y--z   experiment

So after deleting the branch, he still has the commits from a to c, probably it looks more like:

a--b--c--d--e--f--g--h--i--j--k    master

Person C presumably has:

a--b--c--d--e--f--g    master
      |
      x--y--z--w--v--q   experiment

This is a perfectly reasonable scenario where merging shouldn't be that bad.

For example, person C can pull from A's master and merge experiment into it.

---

Each maintainer has responsible about his own fork. You can't assume that another committer has commit or not something great.

You can see information if the committer and Author is not the same person.

If you don't want some patch you can revert it in your own fork.