* use case
@ 2006-08-21 18:23 Blu Corater
2006-08-21 20:47 ` Johannes Schindelin
0 siblings, 1 reply; 3+ messages in thread
From: Blu Corater @ 2006-08-21 18:23 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: use case
2006-08-21 18:23 use case Blu Corater
@ 2006-08-21 20:47 ` Johannes Schindelin
2006-08-24 0:37 ` Blu
0 siblings, 1 reply; 3+ messages in thread
From: Johannes Schindelin @ 2006-08-21 20:47 UTC (permalink / raw)
To: Blu Corater; +Cc: git
Hi,
On Mon, 21 Aug 2006, Blu Corater wrote:
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: use case
2006-08-21 20:47 ` Johannes Schindelin
@ 2006-08-24 0:37 ` Blu
0 siblings, 0 replies; 3+ messages in thread
From: Blu @ 2006-08-24 0:37 UTC (permalink / raw)
To: git
On Mon, Aug 21, 2006 at 10:47:47PM +0200, Johannes Schindelin wrote:
> 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.
> 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.
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2006-08-24 0:37 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-08-21 18:23 use case Blu Corater
2006-08-21 20:47 ` Johannes Schindelin
2006-08-24 0:37 ` Blu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).