Is it acceptable to delete a public git fork and replace it with a different fork?

views:

answers:

+1 Q:

Is it acceptable to delete a public git fork and replace it with a different fork?

If you delete a public git repository, and then replace it with a different one, can that cause complications?

Background: A while ago, I branched a project and made a few commits, which have either been pulled in or have become irrelevant (but the latest commit of my fork isn't an ancestor of the main repository). I'd like to delete my fork so that I don't get any irrelevant pull requests on github.

The concern I have is that if I delete my fork, and then create a new fork based on the main repository, could that cause the same kinds of problems as doing a git rebase on a public repository?

+1 A:

The complications will indeed be similar to those with rebasing a public branch. The new master branch will point to a commit which does not have the old one as an ancestor, so everyone will be unable to pull. (Branches will probably also appear or disappear, but that's not as big a deal.)

So, I'd say there are two main options:

Clobber your branch with a merge. Short version: use --strategy=ours to merge your (old) master into the main repo's master. Long version: see here or here. This gets you the content of the main repo's master, but keeps your history moving forward in the normal way. The main reason you wouldn't do this is if you really don't want those commits in the history (perhaps because they make the repo a lot larger) - if that's the case, move on to option two...
If it really needs to happen, suck it up and do it. Notify people what's going on, get past it, and all will be good.

Jefromi 2010-05-13 13:06:22

I tried reading the links, but it seems a little strange to me that it uses "ours" rather than "theirs" (which isn't an available strategy), but that's probably just one of life's paradoxes. Anyway, would the full command be (while you're in your own master branch) `git merge blessed master --strategy=ours`?

Andrew Grimm 2010-05-13 23:37:12

It'd be `git merge --strategy=ours blessed`. Merge always merges the named commit into the current branch, and options come before arguments. I think the reason there's no "theirs" is that it's not really consistent with most merge philosophies - when you merge, you're thinking about incorporating something else into your branch, then continuing with development on your branch. If you're wiping out the current contents, you're probably not developing on that branch anymore.

Jefromi 2010-05-14 03:13:19

I'm new to Git as well, but from what I've seen/used of it, it is very frowned upon to completely "delete" a repo like that. It could potentially cause a LOT of issues if others want to merge back into it, etc.

It's hard to tell based upon the information you've provided, but if it is at risk that others will be using the repo, I would recommend avoiding a full delete.

Again, this is amateur advice--Jefromi seems to have a bit better input but I thought I should weigh in with my opinion, as well.

Matt D 2010-05-13 15:25:41

You're pretty much right here, though my reading of the question is that "fork" may mean "branch", and the OP's talking about blowing away his master branch in favor of the main repo's master. I say this because he says "replace the repository with a different one", which means since one was a fork of the other, they will share some history but not all of it, so it's effectively like resetting master to old-origin/master.

Jefromi 2010-05-13 15:42:33

Good clarification, Jefromi. I somewhat misunderstood the problem, and I believe you are right about the situation.

Matt D 2010-05-13 16:37:42

The git.git repo and the linux.git repo both have branches that are constantly being rebased and rewritten. I think that although people constantly say that you shouldn't do this they are wrong. I think people should be doing a git pull --rebase anyways, unless they know better. Which won't cause problems if the upstream rebases something. Just put a notice up that you're doing it, and while you at it make a branch that you tell people will be unstable and prone to rebasing.

xenoterracide 2010-05-13 15:33:40

Ayyyyy. No one says don't do it. We say don't do it unless you really need to, and make it very clear what's happening if you do. The git.git branches are well-known to be rebased frequently. Any one-off must be well-publicized, because it *will* cause others some grief. So, by all means, rebase a public branch if it's the right thing to do. But if you can avoid it (for example with a `--strategy=ours` merge), then do so. I don't think anyone in the git community would say that I'm *wrong* for saying that.

Jefromi 2010-05-13 15:41:46

ansaurus

tags:

views:

answers:

Is it acceptable to delete a public git fork and replace it with a different fork?

related questions