2

I have a library on github and about a year ago I did a complete rewrite of the app that is not backwards compatible. It is on a branch called 'structured'. Now most people who are installing the library are using that branch and I would like to make it the master and move the current master to 'legacy'.

I don't want people who were on the old master to be able to fast forward to the new master because it would break their apps for sure. Is it possible to divert them to the legacy branch, or at least throw an exception and display a message telling them to checkout the legacy branch?

sbaechler
  • 1,329
  • 14
  • 21
  • possible duplicate of [How to replace master branch in git, entirely, from another branch?](http://stackoverflow.com/questions/2862590/how-to-replace-master-branch-in-git-entirely-from-another-branch) – Greg Bacon Jun 06 '12 at 18:54
  • There is one important difference: The app in that post can fast forward while mine cannot. – sbaechler Jun 06 '12 at 19:17

3 Answers3

1

I don't think it's possible unless you implement a hook, but it may not be worth it.

I think i'd simply clone the repo on my server, leave the old repo as it is, pulling bugfixes if needed and create another repo for the new "structured" library.

KurzedMetal
  • 12,540
  • 6
  • 39
  • 65
0

There is no way to divert them, because Git branches are just labels: there is no way to tell that the new master branch is any different than the old one.

I think it's a bad idea for a client to clone from the master branch if they don't want it to break them. You should have release branches or tags for this purpose, and then people can clone from them and they'll know they have a stable branch that only might get backward-compatible updates (in case of a branch) or never change (in case of a tag).

As for a warning, it's not possible either because there is no hook you can put on the server to run when someone fetches from it (only for push you can). You'll have to just write it clearly on your GitHub page.

Another idea is to amend the last commit in master so that it's not a fast-forward of the old master anymore; and do it in a way that causes a conflict. This way, whenever someone with the old master pulls, they will get a conflict and have to check what's going on.

Daniel Hershcovich
  • 3,751
  • 2
  • 30
  • 35
  • Well, the project startet small and grew over time. At one point I decided that the app needed a major design change to be able to continue development. At that point I should probably have created a new repo instead of just a new branch. Becasue I knew I won't ever be able to merge the new branch to the old one. – sbaechler Jun 06 '12 at 19:16
  • @sbaechler: `At that point I should probably have created a new repo instead of just a new branch`: like i said in my answer, nothing stops you from doing it now, simply clone the repository to a new repository in your server, delete the old branch if you like, and you are done.. – KurzedMetal Jun 06 '12 at 19:39
0

As for the "divert" portion of your question, you could always do something like this as the first commit on the new master:

#ifndef IMPLEMENTED_STRUCTURED
#error "The master branch of project x has been completely rewritten and will break legacy applications.  If you are unable to update your application, switch to the legacy branch of this project and your code should continue working as before.  If you want to use the new structured code, simply add a preprocessor definition for IMPLEMENTED_STRUCTURED to get rid of this error message."
#endif

That will keep anyone's code from compiling successfully until they read the message and decide upon the course of action they want to take.

Hopefully if you're not using C/C++ your language has functionality which can enable a similar behavior.

wadesworld
  • 13,535
  • 14
  • 60
  • 93