threads / discuss / 5344

use case

Subject: use case

## tl;dr

3 messages between Aug 21, 2006 and Aug 24, 2006.

replies: 2people: 2as markdown or json

Blu Corater· Aug 21, 2006, 18:23 UTC · lore
Hello all.

I've just recently started to put my projects under git, and I have found a, maybe unusual, use case in which I am not sure how to procede or even if git is the right tool. Advice from more seasoned users is welcome.

The picture is like this. I've just have to took over the maintenance of a piece of software which was not kept under scm. The previous developer used to just hack on the production systems and make a backup once in a while. No release policy or anything like that. The software runs on several machines and controls similar but not identical equipment. The machines should be swapable, therefore the software running should be identical in all of them and detect the working environment at runtime.

In top of all, my predecesor was fired a few months before I took control and, in the meantime, people have been doing random modifications to the software on the production machines to satisfy new requirements, but not consolidating them, so the present state is slightly divergent and incompatible versions of the software on each production machine and the machines are not swapable any more.

My contingency plan, while I manage to refactor the code and establish a more sane workflow, was to create a git repository on each production machine, so I can track and audit changes made by random hackers (I have been unable to convince all of them to ask me to do it instead), and pull from all of them to a git repository on my develpment machine to produce a consolidated version.

I am keeping local branches on my devel repo corresponding to each production machine and pulling from them every time somebody makes a modification (after commiting on the production machine of course).

The main problem I am facing now is that I have been unable to make an octopus merge from all the branches to consolidate them. When I do a "git-pull . branch1 branch2..." git tells me "Unable to find common commit with 5f83..." where 5f83... is the sha1 of the head commit of the first branch on the command line. I am merging every branch with my master branch one by one now, but it is a very time consumming and error prone process. I would very much like to octopus merge the branches, with all the conflicts, and then fix the master branch and release a consolidated version.

Any hints?
-- 
Blu.
Johannes Schindelin· Aug 21, 2006, 20:47 UTC · re: Blu Corater · lore

Re: use case

Hi,
On Mon, 21 Aug 2006, Blu Corater wrote:
Show 5 quoted lines
> The main problem I am facing now is that I have been unable to make an
> octopus merge from all the branches to consolidate them. When I do a
> "git-pull . branch1 branch2..." git tells me "Unable to find common commit
> with 5f83..." where 5f83... is the sha1 of the head commit of the first
> branch on the command line.

Ideally, you really would have a common revision to start from. Since you do not have that yet, you have to go low-level for the first octopus.

Suppose you have the last common version as tip of branch "ancestor", you could do

	git merge-octopus ancestor -- HEAD branch1 branch2 ...

After this -- if everything went well -- you should have a committable state in the index. Before you commit, you should do

	git rev-parse branch1 > .git/MERGE_HEAD
	git rev-parse branch2 >> .git/MERGE_HEAD
	git rev-parse branch3 >> .git/MERGE_HEAD
	...

to tell git that you want to commit an octopus merge. This will tell git-commit what the parents of the merge are.

The next time you do an octopus, you _will_ have a common ancestor, so no need to jump through hoops after the first octopus.

Hth, Dscho

Blu· Aug 24, 2006, 00:37 UTC · re: Johannes Schindelin · lore

Re: use case

On Mon, Aug 21, 2006 at 10:47:47PM +0200, Johannes Schindelin wrote:
Show 7 quoted lines
> Ideally, you really would have a common revision to start from. Since you 
> do not have that yet, you have to go low-level for the first octopus.
> 
> Suppose you have the last common version as tip of branch "ancestor", you 
> could do
> 
> 	git merge-octopus ancestor -- HEAD branch1 branch2 ...

This one didn't work. It complains about not having common ancestors too. I did a manual merge anyway.

Show 10 quoted lines
> After this -- if everything went well -- you should have a committable 
> state in the index. Before you commit, you should do
> 
> 	git rev-parse branch1 > .git/MERGE_HEAD
> 	git rev-parse branch2 >> .git/MERGE_HEAD
> 	git rev-parse branch3 >> .git/MERGE_HEAD
> 	...
> 
> to tell git that you want to commit an octopus merge. This will tell 
> git-commit what the parents of the merge are.

This trick did it. Now I have a proper merge commit with common ancestors. Thanks a lot.

-- 
Blu.

← back to recent threads