On Wed, 30 Jul 2008 19:03:37 -0400, Brian Gernhardt
<benji@xxxxxxxxxxxxxxxxxx> wrote:
> This message got eaten by a syntax error somewhere. This is a re-send, sorry for any duplicate messages.
>
> On Jul 30, 2008, at 12:26 PM, H.Merijn Brand wrote:
>
> > On Wed, 30 Jul 2008 11:15:55 -0400, Brian Gernhardt
> > <benji@xxxxxxxxxxxxxxxxxx> wrote:
> >
> > > Then you do something like:
> > >
> > > rm -rf module_{a,b,c}/.git # Do this in a test repository, obviously...
> > > git add module_a module_b module_c
> > > git commit # Needed because '-s ours' uses current HEAD, not index
> >
> > So far so good.
> >
> > > git merge --no-commit -s ours module_a/master module_b/master module_c/master
> >
> > $ git merge --no-commit -s ours fnc/master i00f000/master
> > i99f000/master include/master l00m000/master l01f000/master
> > l02f000/master l03f000/master l06f000/master l90z000/master
> > leerpl/master mutbev/master prtabel/master rpt/master tabellen/master
> > zoomen/master Automatic merge went well; stopped before committing as
> > requested
> >
> > > git commit --amend
> >
> > $ git commit --amend
> > fatal: You are in the middle of a merge -- cannot amend.
>
> Hm. I did mention this was completely untested, yes? The problem comes
> from the fact that '-s ours' wants to use HEAD, not the index. But you
> can't amend a normal commit into a merge, apparently. And I don't think
> you want a commit that adds the files and a commit that "does the merge"
> as two separate steps.
>
> Well, I don't know how to make the porcelain do this then. But the
> plumbing can definitely do it. Hopefully someone more used to doing
> strange things like this can give a simpler recipe, but this should
> work.
>
> # First reset to the commit you made with all the modules added.
> vim commit-message # Create a merge message
> commit=$(git commit-tree HEAD: -p HEAD^ -p module_a/master -p
^^^^^^^^
had to remove that part
> module_b/master -p module_c/master < commit-message)
> git update-ref HEAD $commit # Update your current ref
Some history
---
I'm aware I started at the wrong end of being a git user. I had to move
from SCCS to `something better', and at that point only git, svn, and
hq seemed to be likely candidates.
hq being python, and our company not using python, but perl, made that
an easy drop. I gave up compiling svn on HP-UX in 64bit mode after
about a week, mainly because it depended on way too many things, and
the new VCS has to run on this platform, as it is our main development
system. I got git up and running in two days (compile in less than two
hours, but then I got to chase HP-UX and 64bit oddities).
By the I knew a lot about the git source code, make files, and test
scripts, but still had no idea about the whole plumbing/porcelain
approach. The plan was to make that someone else's job.
Once it was up and running, I had to create a way to convert all our
SCCS repo's to git, so we could get started and test if it met our
needs. That part went smooth, and with a little help from Sam Villain
to get some speed into the conversions using git-fast-import, it is now
available to the public on CPAN as VCS::SCCS, with git2sccs in the
examples folder.
Using git-gui and gitk my users were enthousiastic, and they saw all
the advantages of using git over SCCS. Of course, with every change
there are a few (serious) drawbacks, but we have to live with those.
Being a perl5 porter/maintainer, I was used to p4v (perforce) and still
wonder why there are two GUI's instead of just one, and why they don't
offer the functionality I love in p4v. Not that I think perforce is
better than git, but their GUI certainly is.
---
So, back to this merging issue. Now you might understand why I have all
those `silly' questions and have (still) no good idea of what all these
commands do. (The person that were to do all that never came into the
picture). I'm learning.
I'm VERY happy and thankful for the help I get from you here, and I get
the impression that my feedback on getting git running in our somewhat
different environment to you is also appreciated.
I had to cut down my number of modules to merge, as I got an error that
the maximum number of merges was 16. I had 18.
I will now be playing with the results a bit. I have attached the
script, in case you might want to use it in documentation or examples.
For now, all the mods are hardcoded. No arguments and so on.
Again, Thanks!
$ bash git-merge-mods.sh
Re-initialize GIT repo
Initialized empty Git repository in /work/lep/4gl/.git/
Recovering original module repo's
Fetching for i00f000
remote: Counting objects: 24, done.
remote: Compressing objects: 100% (14/14), done.
remote: Total 24 (delta 9), reused 24 (delta 9)
Unpacking objects: 100% (24/24), done.
From i00f000
* [new branch] master -> i00f000/master
Fetching for i99f000
:
:
Receiving objects: 100% (356/356), 139.05 KiB, done.
Resolving deltas: 100% (180/180), done.
From rpt
* [new branch] master -> rpt/master
Removing module repo's
Adding modules
Commit
Merge
Automatic merge went well; stopped before committing as requested
Commit
=========
53229f046c5d85d11bbd500cf04b468fd3f62c08
=========
Update
$
--
H.Merijn Brand Amsterdam Perl Mongers http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Attachment:
git-merge-mods.sh
Description: application/shellscript
