{"thread":{"id":"5344","subject":"use case","startedAt":"2006-08-21T18:23:38Z","lastAt":"2006-08-24T00:37:36Z","messageCount":3,"participants":["Blu Corater","Johannes Schindelin","Blu"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"25702","messageId":"20060821182338.GA21395@daga.cl","threadId":"5344","inReplyTo":null,"subject":"use case","fromName":"Blu Corater","fromEmail":"blu@daga.cl","sentAt":"2006-08-21T18:23:38Z","receivedAt":"2006-08-21T18:23:38Z","isPatch":false,"sender":{"key":"blu@daga.cl","avatar":null},"body":"Hello all.\n\nI've just recently started to put my projects under git, and I have found\na, maybe unusual, use case in which I am not sure how to procede or even\nif git is the right tool. Advice from more seasoned users is welcome.\n\nThe picture is like this. I've just have to took over the maintenance of a\npiece of software which was not kept under scm. The previous developer\nused to just hack on the production systems and make a backup once in a\nwhile. No release policy or anything like that. The software runs on\nseveral machines and controls similar but not identical equipment. The\nmachines should be swapable, therefore the software running should be\nidentical in all of them and detect the working environment at runtime.\n\nIn top of all, my predecesor was fired a few months before I took control\nand, in the meantime, people have been doing random modifications to the\nsoftware on the production machines to satisfy new requirements, but not\nconsolidating them, so the present state is slightly divergent and\nincompatible versions of the software on each production machine and the\nmachines are not swapable any more.\n\nMy contingency plan, while I manage to refactor the code and establish\na more sane workflow, was to create a git repository on each production\nmachine, so I can track and audit changes made by random hackers (I have\nbeen unable to convince all of them to ask me to do it instead), and pull\nfrom all of them to a git repository on my develpment machine to produce a\nconsolidated version.\n\nI am keeping local branches on my devel repo corresponding to each\nproduction machine and pulling from them every time somebody makes a\nmodification (after commiting on the production machine of course).\n\nThe main problem I am facing now is that I have been unable to make an\noctopus merge from all the branches to consolidate them. When I do a\n\"git-pull . branch1 branch2...\" git tells me \"Unable to find common commit\nwith 5f83...\" where 5f83... is the sha1 of the head commit of the first\nbranch on the command line. I am merging every branch with my master\nbranch one by one now, but it is a very time consumming and error prone\nprocess. I would very much like to octopus merge the branches, with all\nthe conflicts, and then fix the master branch and release a consolidated\nversion.\n\nAny hints?\n\n-- \nBlu.\n"},{"id":"25711","messageId":"Pine.LNX.4.63.0608212231430.28360@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5344","inReplyTo":"20060821182338.GA21395@daga.cl","subject":"Re: use case","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-08-21T20:47:47Z","receivedAt":"2006-08-21T20:47:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 21 Aug 2006, Blu Corater wrote:\n\n> The main problem I am facing now is that I have been unable to make an\n> octopus merge from all the branches to consolidate them. When I do a\n> \"git-pull . branch1 branch2...\" git tells me \"Unable to find common commit\n> with 5f83...\" where 5f83... is the sha1 of the head commit of the first\n> branch on the command line.\n\nIdeally, you really would have a common revision to start from. Since you \ndo not have that yet, you have to go low-level for the first octopus.\n\nSuppose you have the last common version as tip of branch \"ancestor\", you \ncould do\n\n\tgit merge-octopus ancestor -- HEAD branch1 branch2 ...\n\nAfter this -- if everything went well -- you should have a committable \nstate in the index. Before you commit, you should do\n\n\tgit rev-parse branch1 > .git/MERGE_HEAD\n\tgit rev-parse branch2 >> .git/MERGE_HEAD\n\tgit rev-parse branch3 >> .git/MERGE_HEAD\n\t...\n\nto tell git that you want to commit an octopus merge. This will tell \ngit-commit what the parents of the merge are.\n\nThe next time you do an octopus, you _will_ have a common ancestor, so no \nneed to jump through hoops after the first octopus.\n\nHth,\nDscho\n"},{"id":"25828","messageId":"20060824003736.GJ14223@daga.cl","threadId":"5344","inReplyTo":"Pine.LNX.4.63.0608212231430.28360@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: use case","fromName":"Blu","fromEmail":"blu@daga.cl","sentAt":"2006-08-24T00:37:36Z","receivedAt":"2006-08-24T00:37:36Z","isPatch":false,"sender":{"key":"blu@daga.cl","avatar":null},"body":"On Mon, Aug 21, 2006 at 10:47:47PM +0200, Johannes Schindelin wrote:\n> Ideally, you really would have a common revision to start from. Since you \n> do not have that yet, you have to go low-level for the first octopus.\n> \n> Suppose you have the last common version as tip of branch \"ancestor\", you \n> could do\n> \n> \tgit merge-octopus ancestor -- HEAD branch1 branch2 ...\n\nThis one didn't work. It complains about not having common ancestors too.\nI did a manual merge anyway.\n\n> After this -- if everything went well -- you should have a committable \n> state in the index. Before you commit, you should do\n> \n> \tgit rev-parse branch1 > .git/MERGE_HEAD\n> \tgit rev-parse branch2 >> .git/MERGE_HEAD\n> \tgit rev-parse branch3 >> .git/MERGE_HEAD\n> \t...\n> \n> to tell git that you want to commit an octopus merge. This will tell \n> git-commit what the parents of the merge are.\n\nThis trick did it. Now I have a proper merge commit with common ancestors.\nThanks a lot.\n\n-- \nBlu.\n"}]}