importing two different trees into a fresh git repo

importing two different trees into a fresh git repo

[Constantine A. Murenin]

Hi,

I have two distinct trees that were not managed by any RCS, and I'd
like to import them into a single repository into two separate orphan
branches, then make sense of what's in there, merge, and unify into
'master'.

(To give some context, it's /etc/nginx config files from nginx/1.0.12
on Debian 6 and nginx/1.2.2 on OpenBSD 5.2.)

I've encountered two problems so far:

0. After initialising the repository, I was unable to `git checkout
--orphan Debian-6.0.4-nginx-1.0.12` -- presumably it doesn't work when
the repo is empty?  This sounds like a bug or an artefact of
implementation.  I presume this can be worked around by committing
into master instead, and then doing `git checkout -b
Debian-6.0.4-nginx-1.0.12`, and then force-fixing the master somehow
later on.

1. After making a mistake on my first commit (my first commit into
OpenBSD-5.2-nginx-1.2.2 orphan branch ended up including a directory
from master by mistake), I am now unable to rebase and "fixup" the
changes -- `git rebase --interactive HEAD~2` doesn't work, which, from
one perspective, makes perfect sense (indeed there's no prior
revision), but, from another, it's not immediately obvious how to
quickly work around it.

Any suggestions?

It would seem like making some kind of a dummy first commit into
master would be the best workaround for both of these problems.  Is
that basically the suggested approach?

Best regards,
Constantine.

Re: importing two different trees into a fresh git repo

[Junio C Hamano]

"Constantine A. Murenin" <mureninc@gmail.com> writes:

> I have two distinct trees that were not managed by any RCS, and I'd
> like to import them into a single repository into two separate orphan
> branches, then make sense of what's in there, merge, and unify into
> 'master'.
>
> (To give some context, it's /etc/nginx config files from nginx/1.0.12
> on Debian 6 and nginx/1.2.2 on OpenBSD 5.2.)

As these come from two totally separate sources, I'd find it more
natural to do two repositories, deb-nginx-conf and obsd-nginx-conf,
each with one commit and then pull one into the other (or pull both
to master-nginx-conf if you really wanted to), to me.

Re: importing two different trees into a fresh git repo

[Constantine A. Murenin]

On 5 February 2013 14:29, Junio C Hamano <gitster@pobox.com> wrote:
> "Constantine A. Murenin" <mureninc@gmail.com> writes:
>
>> I have two distinct trees that were not managed by any RCS, and I'd
>> like to import them into a single repository into two separate orphan
>> branches, then make sense of what's in there, merge, and unify into
>> 'master'.
>>
>> (To give some context, it's /etc/nginx config files from nginx/1.0.12
>> on Debian 6 and nginx/1.2.2 on OpenBSD 5.2.)
>
> As these come from two totally separate sources, I'd find it more
> natural to do two repositories, deb-nginx-conf and obsd-nginx-conf,
> each with one commit and then pull one into the other (or pull both
> to master-nginx-conf if you really wanted to), to me.

Yeah, I guess it might be more of a git-style to have two/three
separate repositories here.  (The sources are just a couple of files,
so I think my specific example still calls for merely two orphan
branches.)

Still, is it really expected that you can't create an orphan branch in
an empty repository?  On the outside, this sounds like a rather benign
bug.

C.

Re: importing two different trees into a fresh git repo

[Jeff King]

On Tue, Feb 05, 2013 at 01:46:09PM -0800, Constantine A. Murenin wrote:

> I've encountered two problems so far:
> 
> 0. After initialising the repository, I was unable to `git checkout
> --orphan Debian-6.0.4-nginx-1.0.12` -- presumably it doesn't work when
> the repo is empty?  This sounds like a bug or an artefact of
> implementation.  I presume this can be worked around by committing
> into master instead, and then doing `git checkout -b
> Debian-6.0.4-nginx-1.0.12`, and then force-fixing the master somehow
> later on.

What version of git are you using? Using both "-b" and "--orphan" from a
non-existing branch used to be broken, but was fixed by abe1998 (git
checkout -b: allow switching out of an unborn branch, 2012-01-30), which
first appeared in git v1.7.9.2.

> 1. After making a mistake on my first commit (my first commit into
> OpenBSD-5.2-nginx-1.2.2 orphan branch ended up including a directory
> from master by mistake), I am now unable to rebase and "fixup" the
> changes -- `git rebase --interactive HEAD~2` doesn't work, which, from
> one perspective, makes perfect sense (indeed there's no prior
> revision), but, from another, it's not immediately obvious how to
> quickly work around it.

You cannot ask to rebase onto HEAD~2 because it does not exist (I'm assuming
from your description that HEAD~1 is the root of your repository). But
you can use the "--root" flag to ask git to rebase all the way down to
the roots, like:

  git rebase -i --root

However, note that older versions of git do not support using "--root"
with "-i". The first usable version is v1.7.12.

-Peff