Re: howto to run git without a master branch
On 03/09/2014 07:46 AM, Torsten Bögershausen wrote: After creating a local repository with these two branches, and a server repository with git init --bare, and pushing the two branches: git remote add originfoo@bar:~/path/test.git git push origin master-g git push origin master-x everything seems fine, but cloning: git clonefoo@bar:~/path/test.git terminates with a warning: remote HEAD refers to nonexistent ref, unable to checkout. This is because Git is trying to be nice: When you clone, it tries to checkout a branch for you. What happens when you only have 1 branch, lets say master-x? If I clone the bare repo here, with only 1 branch, this branch is automatically checked out (tested on 1.8.5.2) What happens when you have 2 branches on the server? Git really can not make a decision which one is the right one to check out for you, so if you have 2 branched like master and develop, it checks out the master branch for you. But if you have master-x and master-g then Git has no clue, which one could be you favorite one (and neither have I) The problem is on the server repo, the cloned repo is just a consequence. After initializing the server repo and pushing two branches master-g and master-x there is no master branch. Therefore the HEAD file should not point to a master branch that does not exist: ref: refs/heads/master It could point to master-g (the first branch to be pushed) or master-x (the last branch to be pushed), depending of the criterion used by git, but pointing to something that does not exist seems weird and is the cause of the further complaints when the whole repository is cloned... I forgot to say that the git version is 1.7.2.5 in both the initial repo and the server repo (probably this issue was fixed in newer versions?) As I said, editing directly the HEAD text file on the server, and replacing master by master-g (or master-x) seems to solve the problem. My question is: is that enough? or shall I expect further issues down the road? Thank you very much, Carlos What does git branch say? (I think nothing) What does git branch -r say? (I think origin/master-g and origin/master-x) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: howto to run git without a master branch
There is a git remote set-head to manipulate HEAD in a remote repository. Thanks, that is useful (like git symbolic-ref HEAD master-x suggested by Kevin, much better than editing the text file) I agree that this might be viewed as a user experience issue. But I can not come up with a possible solution. Can you? The branch where the user was when he/she pushed the repo to the server? it would be his/her responsibility to checkout the proper branch before pushing... if that was not good enough than he/she could always use git remote set-head... my point is: pointing to a bad branch that exists seems better than pointing to a branch that does not exist... Anyway I agree this is not important, as we can easily change HEAD. I do not think there should be any issues. Thank you very much for your answers, Carlos -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
howto to run git without a master branch
Hi, git newbie here. I would like to work with two main branches: master-g and master-x, instead of the usual master, and apparently git does not like this. After creating a local repository with these two branches, and a server repository with git init --bare, and pushing the two branches: git remote add origin foo@bar:~/path/test.git git push origin master-g git push origin master-x everything seems fine, but cloning: git clone foo@bar:~/path/test.git terminates with a warning: remote HEAD refers to nonexistent ref, unable to checkout. On the original local repository, I have: cat HEAD ref: refs/heads/master-x But on the server repository or the clone repository, HEAD points to master branch, that does not exist: cat HEAD ref: refs/heads/master Replacing in the HEAD file, master by master-g (on the server before cloning, or on the clone after cloning) seems to solve the problem. Shall I worry about this? does my fix (editing directly HEAD on the server) fixes really the problem? what would be the correct procedure to avoid this? Thank you! Carlos Pereira, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git best strategy for two version development
On 02/08/2014 03:56 AM, brian m. carlson wrote: On Sat, Feb 08, 2014 at 02:06:41AM +, Carlos Pereira wrote: Hello, I am a git and CVS newbie, I bought and red most of the excellent Pro Git book by Scott Chacon, but I still have a doubt. I have a package that I distribute in two versions differing only in one library: version_A uses this library, version_B uses my own code to replace it. For strategic reasons I want to keep it this way for the time being. Both versions have the same documentation, the same data files, and 99% of the source code is the same (a few makefile changes, two additional files in version_B and some minor changes: a diff -r has only 170 lines). The question is what is the best strategy to manage a situation like this with git? Shall I maintain two different repositories? I don't think so... Apparently the best solution would be to maintain two long term branches, say mater_A and master_B, and merge all later developments in both branches, keeping the initial difference... Specifically: 1) do some new work in branch master_A, commit, etc. 2) checkout master_B and merge the new work in master_B, without merging the initial diff between the two versions. What is the better way to do that? That's pretty much the way to do it. If you check in master-A, then create the master-B branch off of that, copying in the code from B and checking it in, then when you merge from master-A to master-B, git will basically do the right thing. Changes you make on master-A that are specific to that version will probably conflict, but they should be easy to fix up. You are right! git does not try to merge everything, only changes commited on the other branch (branch-A), after creating branch-B... otherwise it would be reverting the work done on the current branch, which does not make much sense... Thank you very much... C I basically do this for a consulting project for a client: there's generic code in master, and a special branch for the client. Since most changes don't touch the modified code, conflicts are infrequent, and I can fix them up when they occur. I also do it for my dotfiles, which vary slightly between home and work. You could also make the changes to master-B as a set of commits on top of master-A, and always rebase master-B on master-A, but this isn't a good solution if other people are going to be using your code. It has the benefits of keeping the history free of frequent merges, which may or may not be important to you; it doesn't really bother me very much. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git best strategy for two version development
Hello, I am a git and CVS newbie, I bought and red most of the excellent Pro Git book by Scott Chacon, but I still have a doubt. I have a package that I distribute in two versions differing only in one library: version_A uses this library, version_B uses my own code to replace it. For strategic reasons I want to keep it this way for the time being. Both versions have the same documentation, the same data files, and 99% of the source code is the same (a few makefile changes, two additional files in version_B and some minor changes: a diff -r has only 170 lines). The question is what is the best strategy to manage a situation like this with git? Shall I maintain two different repositories? I don't think so... Apparently the best solution would be to maintain two long term branches, say mater_A and master_B, and merge all later developments in both branches, keeping the initial difference... Specifically: 1) do some new work in branch master_A, commit, etc. 2) checkout master_B and merge the new work in master_B, without merging the initial diff between the two versions. What is the better way to do that? I suppose this is a fairly common situation, for example, some standalone code distributed with two different GUI toolkits. I could carefully choose which commits should be merged in both branches (the changes in standalone code) and which should not (the changes in GUI code), but that is error-prone and seems to miss the whole point of using a managment system... How shall I handle this? Thanks for your help! Regards, Carlos Pereira, http://www.gamgi.org/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
