how to combine two clones in a collection

how to combine two clones in a collection

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

Dear list,

I am new to git but already quite sold on it. Especially git-svn
makes my heart jump.

I am now ready to move to using git for most of my everyday work,
but I am still unsure how to tackle one specific aspect of it, for
which I used svn:externals in the past. I know about git
subprojects, but these aren't what I want, really.

I am a Debian developer, and while the upstream trunk is usually
maintained in SVN by upstream him/herself, I maintain the ./debian
directory elsewhere.

With SVN, I would have a directory with two external entries:

  upstream.trunk svn+ssh://svn.upstream.org/path/to/trunk
  upstream.trunk/debian svn+ssh://svn.debian.org/svn/pkg/trunk/debian

I hope this makes what I mean obvious. GNU arch has a similar
concept called configs.

How can I do this with git? I am aware that maybe the best way would
be to use git-svn to track the upstream branch remotely and to add
./debian in a separate git branch (and to stop using SVN and switch
to git for ./debian), but I am not sure I want to mirror all
upstream projects in git repos published on svn.debian.org, and if
it's only for space reasons.

Do you know of other approaches, short of writing my own
config-manager?

Thanks,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
"never eat more than you can lift."
                                                       -- miss piggy

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: how to combine two clones in a collection

[Linus Torvalds]

On Tue, 10 Jul 2007, martin f krafft wrote:
> 
> I am now ready to move to using git for most of my everyday work,
> but I am still unsure how to tackle one specific aspect of it, for
> which I used svn:externals in the past. I know about git
> subprojects, but these aren't what I want, really.

I really _think_ that what you want is to just use separate branches, if I 
understand correctly. That makes it really easy to just have both lines of 
development (both the "trunk" and your "debian" one) in one git 
repository.

Of course, especially if you want to continue to work the way you probably 
worked with SVN (ie you are used to seeing those two branches as two 
separate directories), that means that while you can (and should) see it 
as a single git project, you'd normally end up just having two copies of 
that project: they'd _both_ have two branches, but they'd just en dup 
having different branches checked out.

Of course, after you get comfy enough with the setup, you might end up 
just deciding that you might as well just switch branches around in a 
single repository (which is what a lot of git users end up doing), but at 
least initially, it's probably easier from a conceptual standpoint to just 
have the two branches checked out in separate copies of the repos.

> With SVN, I would have a directory with two external entries:
> 
>   upstream.trunk svn+ssh://svn.upstream.org/path/to/trunk
>   upstream.trunk/debian svn+ssh://svn.debian.org/svn/pkg/trunk/debian

So in git, you'd have just one "project" with two branches - perhaps just 
called "upstream" and "debian".

Of course, with git, that single "project" can then exist in a distributed 
manner in many different places, and having two copies with different 
branches checked out would just happen to be the one that most closely 
resembles your current situation.

> How can I do this with git? I am aware that maybe the best way would
> be to use git-svn to track the upstream branch remotely and to add
> ./debian in a separate git branch (and to stop using SVN and switch
> to git for ./debian)

I don't think you'd have to stop using SVN. Just continue to track the 
"upstream" branch with git-svn, and then you can merge in the upstream 
into your "debian" branch that also has all the debian-specific stuff.

(And no, I don't know what the standard debian package management setup 
looks like, but I would hope that your extra stuff would be just a few 
files and package descriptions, and obviously any of the local debian 
changes to the project).

		Linus

Re: how to combine two clones in a collection

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 3998 bytes --]

Thanks, Linus, for your time in answering my questions. I have some
more comments and questions in reply. I hope I am coherent enough,
this subject matter doesn't exactly flow off my tongue with ease
yet...

also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.07.10.0435 +0200]:
> I really _think_ that what you want is to just use separate
> branches, if I understand correctly. That makes it really easy to
> just have both lines of development (both the "trunk" and your
> "debian" one) in one git repository.

It does mean, however, that I duplicate the upstream into my repo,
and thus into the published repo at git.debian.org, because I cannot
just publish a single branch ('debian') in such a way that people
could clone it and still be able to build the package against
upstream (which they'd have to obtain for themselves), right?

> Of course, especially if you want to continue to work the way you
> probably worked with SVN (ie you are used to seeing those two
> branches as two separate directories), that means that while you
> can (and should) see it as a single git project, you'd normally
> end up just having two copies of that project: they'd _both_ have
> two branches, but they'd just en dup having different branches
> checked out.

The way I tend to think about a pair of branches is that one depends
on the other, or rather, one stems from the other. Thus, I'd
probably branch the 'debian' branch off 'upstream', and add the
./debian directory, and then either rebase the debian branch onto
new upstream heads, or merge upstream into the debian branch on new
versions.

This makes perfect sense and I have been experimenting with such
a workflow before:
http://albatross.madduck.net/pipermail/vcs-pkg/2007-June/000001.html

So if I made changes to the debian branch, I'd check it out first,
then return to the upstream branch when done.

Your suggestion to checkout the same repo twice with different
branches does sound a lot like the way I used to do things in SVN.
However, I guess what I am trying to prevent is having to manually
set up this hierarchy on each machine I choose to work on. Instead,
I'd rather be able to clone a repository and be ready to work.

In your scenario, would I make two branches and then import upstream
into one, the ./debian directory into the other, and never ever
merge back and forth again, thus treating them as separate
directories?

> Of course, after you get comfy enough with the setup, you might
> end up just deciding that you might as well just switch branches
> around in a single repository (which is what a lot of git users
> end up doing), but at least initially, it's probably easier from
> a conceptual standpoint to just have the two branches checked out
> in separate copies of the repos.

Okay, this is beginning to make sense. However, the debian branch
tracks changes mostly to ./debian/*. To check it out separately,
I need a directory. If usptream is checked out to ., then if I'd
check out the debian branch do ./debian, I'd end up with
./debian/debian. Do you suggest the use of a symlink then?

> > How can I do this with git? I am aware that maybe the best way
> > would be to use git-svn to track the upstream branch remotely
> > and to add ./debian in a separate git branch (and to stop using
> > SVN and switch to git for ./debian)
> 
> I don't think you'd have to stop using SVN.

I think I would want to. :)

> (And no, I don't know what the standard debian package management
> setup looks like, but I would hope that your extra stuff would be
> just a few files and package descriptions, and obviously any of
> the local debian changes to the project).

Your hopes seem to be quite close to reality. :)

Thanks,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
http://www.vcnet.com/bms/

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: how to combine two clones in a collection

[Junio C Hamano]

martin f krafft <madduck@madduck.net> writes:

> Thanks, Linus, for your time in answering my questions. I have some
> more comments and questions in reply. I hope I am coherent enough,
> this subject matter doesn't exactly flow off my tongue with ease
> yet...
>
> also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.07.10.0435 +0200]:
>> I really _think_ that what you want is to just use separate
>> branches, if I understand correctly. That makes it really easy to
>> just have both lines of development (both the "trunk" and your
>> "debian" one) in one git repository.
>
> It does mean, however, that I duplicate the upstream into my repo,
> and thus into the published repo at git.debian.org, because I cannot
> just publish a single branch ('debian') in such a way that people
> could clone it and still be able to build the package against
> upstream (which they'd have to obtain for themselves), right?

I've seen two kinds of debianized source tree.  One kind has
changes already applied to the pristine source outside debian/
subdirectory, and debian/rules does the debian specific
customized build, install and packaging.  The other kind does
not have _any_ change to the pristine except it has debian/
subdirectory and the first thing debian/rules does is to apply
patches to pristine from patch files kept in debian/
subdirectory.  The answer largely depends on which arrangement
you have in mind for your package.

For the former kind, It is unavoidable for people to get your
(slightly modified) upstream source from you --- there is
nowhere else that stores what you changed.  Extracting the
vanilla pristine and debian/ separately would not cut it.  For
such an arrangement, "upstream" (or "pristine") branch would
contain everything you get from your upstream tarball (or SVN)
without any of Debianization changes (you can still have generic
"fixes and enhancements" of your own there to be fed upstream).
Your "master" (you could call it "debianization") branch will
fork off of that branch, and the first commit on that branch
would add debian/ subdirectory.  All the debianization
modification to the upstream, if needed, also go to this branch.
Your users will clone and pull from your "master" and do
"fakeroot debian/rules binary" or whatever, and all is good.

For the latter, since the changes from upstream is isolated to
your additional debian/ subdirectory, you could arrange your
repository like this, even without using the subproject support:

	.git/
        .gitignore (perhaps untracked)
        Makefile (upstream)
        foo.c (upstream)
        ...
        debian/.git
        debian/rules (yours)
        debian/control (yours)
        ...

Then, have the top-level .git/ repository control pristine
upstream sources from SVN (you may want to add .gitignore to
ignore debian/ subdirectory).  In debian/, you create another
independent repository, and maintain _ONLY_ debianization.  You
could even publish only that repository to your users without
publishing the upstream sources, if they know which version of
upstream source to use.

I tend to prefer the former, from the end user's point of view.

Re: how to combine two clones in a collection

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

also sprach Junio C Hamano <gitster@pobox.com> [2007.07.10.0917 +0200]:
> For the former kind, It is unavoidable for people to get your
> (slightly modified) upstream source from you --- there is
> nowhere else that stores what you changed.

This is pretty similar to a method developed by Manoj Srivastava adn
described here: http://arch.debian.org/arch/private/srivasta/ and
it's very promising, albeit a little complex for newcomers, in my
experience. As linked previously, I presented a similar workflow
with git[0] at DebConf7[1].

0. http://albatross.madduck.net/pipermail/vcs-pkg/2007-June/000001.html
1. https://penta.debconf.org/~joerg/events/53.en.html

I actually knew the answers to my questions, I guess, but I was way
too confused to get the picture straight. Thanks to both of you for
your time in helping me understand.

I shall spend some time experimenting and will then blog about my
experience of converting the various types of Debian source packages
to the suggested style of maintenance. I shall post the URL to this
thread too.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
"for art to exist, for any sort of aesthetic activity or perception to
 exist, a certain physiological precondition is indispensable:
 intoxication."
                                                -- friedrich nietzsche

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: how to combine two clones in a collection

[Martin Langhoff]

On 7/10/07, martin f krafft <madduck@madduck.net> wrote:
> It does mean, however, that I duplicate the upstream into my repo,
> and thus into the published repo at git.debian.org, because I cannot
> just publish a single branch ('debian') in such a way that people
> could clone it and still be able to build the package against
> upstream (which they'd have to obtain for themselves), right?

Yes. But is that a problem? In most cases, the complete history of the
project is fairly small if your repo is well packed. Often not much
bigger than a tarball of one source snapshot.

What does the following say?

   git repack -a -d
   du -sh .git/objects/pack

cheers,


martni

Re: how to combine two clones in a collection

[Linus Torvalds]

On Tue, 10 Jul 2007, martin f krafft wrote:
> 
> also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.07.10.0435 +0200]:
> > I really _think_ that what you want is to just use separate
> > branches, if I understand correctly. That makes it really easy to
> > just have both lines of development (both the "trunk" and your
> > "debian" one) in one git repository.
> 
> It does mean, however, that I duplicate the upstream into my repo,
> and thus into the published repo at git.debian.org, because I cannot
> just publish a single branch ('debian') in such a way that people
> could clone it and still be able to build the package against
> upstream (which they'd have to obtain for themselves), right?

Well, I think you have two cases:

 - the git users

   These would get both branches (including all of the upstream, of 
   course), but that's ok, since git will share all the common objects 
   *anyway*, so there is no "duplication". You can have a hundred 
   branches, and they won't use one whit more memory of bandwidth (apart 
   from the branch refs themselves being sent over, of course), and only 
   the actual *differences* between branches will take up space.

 - the non-git users

   Here, I don't really know how the debian package management is supposed 
   to work, but since they obviously aren't using git, they must be using 
   something else. A tar-ball or just a series of patches? Both would be 
   trivial to implement as just an "export" from your git tree. Or you'd 
   export the "debian" branch as a separate SVN repo (I've not used the 
   "export back into a SVN" thing, so I don't know how well that works).

In particular, if all your "debian-specific" stuff is almost all in the 
"debian" subdirectory, then you can trivially make a tar-file by just 
using

	git archive --prefix=upstream- HEAD debian > upstream-debian.tar

and git will literally generate the tar-file of that directory for you.

> The way I tend to think about a pair of branches is that one depends
> on the other, or rather, one stems from the other.

.. and no, that's not really how git works from a technical angle: in the 
the git model, all branches are technically 100% equal, and no branch 
"depends" on anything else, they are all equally first-class citizens.

But while *technically* all branches are equal in git, at the same time 
there's no reason not to _think_ of branches as having a hierarchy if you 
want to. In particular:

 - it's how people tend to use git anyway (ie the "origin" branch is 
   what you're tracking, and you have your own changes in your local 
   branches)

 - and git will never duplicate information for branches that have a 
   common history or contents anyway. So while git branches are totally 
   "independent" in the technical sense, the data structures are all 
   designed so that they will share everything that they can possibly 
   share (in fact, thanks to the "delta-against-anything" model, different 
   branches will share much more than in something like CVS/SVN)

> So if I made changes to the debian branch, I'd check it out first,
> then return to the upstream branch when done.

It sounds like you would actually be fairly comfy with the git "switch 
branches within one repository" model, and you might not even need to make 
it look like two different trees.

> Okay, this is beginning to make sense. However, the debian branch
> tracks changes mostly to ./debian/*. To check it out separately,
> I need a directory. If usptream is checked out to ., then if I'd
> check out the debian branch do ./debian, I'd end up with
> ./debian/debian. Do you suggest the use of a symlink then?

No, I'm suggesting that you have the upstream thing checked out in ".", 
and you have the "debian" branch IN THE SAME PLACE. So when you do

	git checkout debian

it will just check out all the debian stuff in the same directory, so now 
you'll get a ./debian/ directory with all your debian stuff.

When you do

	git checkout upstream

the files in that directory just go away, because it doesn't exist in 
the "upstream" branch

But I don't want to fool you - I do think you'll have to change *some* of 
how you work. But it sounds like your workflow is *fairly* close to a very 
natural git flow.

		Linus

Re: how to combine two clones in a collection

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 4097 bytes --]

also sprach Linus Torvalds <torvalds@linux-foundation.org> [2007.07.10.1905 +0200]:
>    These would get both branches (including all of the upstream,
>    of course), but that's ok, since git will share all the common
>    objects *anyway*, so there is no "duplication". You can have
>    a hundred branches, and they won't use one whit more memory of
>    bandwidth (apart from the branch refs themselves being sent
>    over, of course), and only the actual *differences* between
>    branches will take up space.

The duplication I meant was when upstream uses SVN or a tarball,
which I then have to track/import into my git repo. But it's just
space and that's cheap these days.

>    Here, I don't really know how the debian package management is
>    supposed to work, but since they obviously aren't using git,
>    they must be using something else. A tar-ball or just a series
>    of patches? Both would be trivial to implement as just an
>    "export" from your git tree. Or you'd export the "debian"
>    branch as a separate SVN repo (I've not used the "export back
>    into a SVN" thing, so I don't know how well that works).

Just in case you're interested, otherwise the following two
paragraphs can be safely skipped:

  There is no standard for Debian packaging. In general, it's the
  upstream tarball and a diff to be applied for debianisation. Some
  people just use one giant diff, others use the diff to add patches
  as separate files to the unpacked contents of the tarball, which
  are then applied.

  I guess my final goal is to use git and branches, one to track
  upstream, one for every feature/patch I add, and then to create
  a source package from that by packaging the upstream branch into
  a tarball (or reusing an existing one), turning each branch into
  a single-file patch and then create the overall diff to add these
  single-files, including some glue to apply them automatically on
  unpacking/building.

> > The way I tend to think about a pair of branches is that one
> > depends on the other, or rather, one stems from the other.
> 
> .. and no, that's not really how git works from a technical angle:
> in the the git model, all branches are technically 100% equal, and
> no branch "depends" on anything else, they are all equally
> first-class citizens.

Right, I knew that. What I meant is more that a branch derives off
another, meaning that before and including the branching commit,
they have shared ancestry.

I wonder how to create a project with two completely independent
branches which have no common ancestry. I don't think it's possible.
One needs a throwaway branch to create the first commit, then branch
each of the two branches off that, then delete the throwaya branch
(or keep it around).

But this is getting academic now...

> > So if I made changes to the debian branch, I'd check it out
> > first, then return to the upstream branch when done.
> 
> It sounds like you would actually be fairly comfy with the git
> "switch branches within one repository" model, and you might not
> even need to make it look like two different trees.

Definitely.

As a Debian maintainer who really wants to use git for Debian
packaging though, I also need to worry about all the other people
who obtain my source package and need to be comfortable with it.
I may well understand what my 123 branches are for and how they are
interlinked, but that doesn't help Jane Schmoo fixing
a release-critical bug while I'm backpacking in Southeast Asia.

> But I don't want to fool you - I do think you'll have to change
> *some* of how you work. But it sounds like your workflow is
> *fairly* close to a very natural git flow.

Thanks for the encouragement!

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
it is better to have loft and lost
than to never have loft at all.
                                                       -- groucho marx

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: how to combine two clones in a collection

[Brian Gernhardt]

On Jul 10, 2007, at 1:45 PM, martin f krafft wrote:
> I wonder how to create a project with two completely independent
> branches which have no common ancestry. I don't think it's possible.
> One needs a throwaway branch to create the first commit, then branch
> each of the two branches off that, then delete the throwaya branch
> (or keep it around).
>
> But this is getting academic now...

But interesting.

What you describe won't create two independent branches.  They'll  
share the root commit.  I think what you have do is create the first  
branch as normal, then clear out the working copy (be sure not to  
delete .git) and do the commit manually.  I believe it goes something  
like this:

   git init
   # Create files for master
   git add .
   git commit
   rm -rf * .git/index
   # Create files for second branch
   git add .
   tree=$(git write-tree)
   # Edit commit message into some file (commit-msg here)
   commit=$(git commit-tree $tree < commit-msg)
   git update-ref refs/branches/independent $commit

The important bits are to be sure to remove the index so you don't  
commit the wrong files and the last four lines that do the heavy  
lifting.  You could also create the branch in a second repository and  
pull it from there into the first (probably simpler), or perhaps  
trick git-commit into thinking there isn't any commits yet (remove  
the index and HEAD perhaps?).

~~ Brian

Re: how to combine two clones in a collection

[Kalle Pokki]

Brian Gernhardt <benji@silverinsanity.com> writes:

> What you describe won't create two independent branches.  They'll
> share the root commit.  I think what you have do is create the first
> branch as normal, then clear out the working copy (be sure not to
> delete .git) and do the commit manually.  I believe it goes something
> like this:

You can also just create two different git repositories and start making
the commits in the master (or any other) branch. Then combine the
repositories by fetching

        cd repo1
        git fetch ../repo2 master:repo2

This way the branches don't share anything, do they?

Re: how to combine two clones in a collection

[Brian Gernhardt]

On Jul 10, 2007, at 3:27 PM, Kalle Pokki wrote:

> You can also just create two different git repositories and start  
> making
> the commits in the master (or any other) branch. Then combine the
> repositories by fetching
>
>         cd repo1
>         git fetch ../repo2 master:repo2
>
> This way the branches don't share anything, do they?

Yes, that's what I was referring to at the end when I wrote:

> You could also create the branch in a second repository and pull it  
> from there into the first (probably simpler),

But it seemed too simple.  ;-)  And that is exactly how I'd do it...   
Assuming I thought of it before using write-tree, commit-tree, and  
update-ref.  (Which is what happened.  I thought of the complicated  
method and wrote it up before thinking "duh, just use a second repo.")

~~ Brian

Re: how to combine two clones in a collection

[Robin Rosenberg]

tisdag 10 juli 2007 skrev Brian Gernhardt:
> 
> On Jul 10, 2007, at 3:27 PM, Kalle Pokki wrote:
> 
> > You can also just create two different git repositories and start  
> > making
> > the commits in the master (or any other) branch. Then combine the
> > repositories by fetching
> >
> >         cd repo1
> >         git fetch ../repo2 master:repo2
> >
> > This way the branches don't share anything, do they?
> 
> Yes, that's what I was referring to at the end when I wrote:
> 
> > You could also create the branch in a second repository and pull it  
> > from there into the first (probably simpler),
> 
> But it seemed too simple.  ;-)  And that is exactly how I'd do it...   
> Assuming I thought of it before using write-tree, commit-tree, and  
> update-ref.  (Which is what happened.  I thought of the complicated  
> method and wrote it up before thinking "duh, just use a second repo.")

And the simplest way to create an new indpendent branch:

echo ref: refs/heads/newbranch >.git/HEAD
Then prepare the content and commit like you used to do.

-- robin

Re: how to combine two clones in a collection

[Jakub Narebski]

martin f krafft wrote:

> I wonder how to create a project with two completely independent
> branches which have no common ancestry. I don't think it's possible.
> One needs a throwaway branch to create the first commit, then branch
> each of the two branches off that, then delete the throwaya branch
> (or keep it around).

Git repository itself  has a few completely independent branches, some of
them visible. One of them, the 'todo' branch is actually from independent
repository, two other, 'man' and 'html' are generated automatically by the
build script.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: how to combine two clones in a collection

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]

also sprach robin:
> And the simplest way to create an new indpendent branch:

> echo ref: refs/heads/newbranch >.git/HEAD
> Then prepare the content and commit like you used to do.

Hi Robin, thanks for this nice suggestion, which doesn't only
createa a new, independent branch, it also teaches me yet a bit
more about git.

I am a little uneasy about touching files in .git with non-git
tools, but everyone seems to be doing it, so I guess it's okay, and
it make git a lot more powerful too.

Anyway, I tried your method and there is one small problem:

  piper:~> git init-db
  Initialized empty Git repository in .git/
  piper:~> date > date; git add date; git commit -m.
  Created initial commit 2dd8d6f: .
  1 files changed, 1 insertions(+), 0 deletions(-)
  create mode 100644 date
  piper:~> echo ref: refs/heads/newbranch >| .git/HEAD
  piper:~> git status
  # On branch newbranch
  #
  # Initial commit
  #
  # Changes to be committed:
  #   (use "git rm --cached <file>..." to unstage)
  #
  #       new file: date
  #

If I were to run commit now, the file 'date' would become part of
the first commit to newbranch. But it's already in the master
branch.

Is there anyway I can prevent this and start a new branch from
scratch without having to unstage all previous additions?

Thanks,

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
"anyone who is capable of getting themselves made president
 should on no account be allowed to do the job"
                                                      -- douglas adams

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: how to combine two clones in a collection

[Johannes Schindelin]

Hi,

On Wed, 11 Jul 2007, martin f krafft wrote:

> also sprach robin:
> > And the simplest way to create an new indpendent branch:
> 
> > echo ref: refs/heads/newbranch >.git/HEAD
> > Then prepare the content and commit like you used to do.
> 
> I am a little uneasy about touching files in .git with non-git
> tools, but everyone seems to be doing it, so I guess it's okay, and
> it make git a lot more powerful too.

You can achieve the same with

	git symbolic-ref HEAD refs/heads/newbranch

There.  No editing in .git/.

>   piper:~> echo ref: refs/heads/newbranch >| .git/HEAD
>   piper:~> git status
>   # On branch newbranch
>   #
>   # Initial commit
>   #
>   # Changes to be committed:
>   #   (use "git rm --cached <file>..." to unstage)
>   #
>   #       new file: date
>   #

However, this is much easier without Git commands:

	rm .git/index

Of course, you can remove all files one by one, but that is certainly not 
easier:

	git ls-files --cached -z | xargs -0 git rm --cached

But then, you really can learn from both examples: .git/index contains 
references to the objects which are staged (in Git speak: "in the index").  
Git plays nicely when that file is missing, and assumes the index to be 
empty.

With "git ls-files --cached", you can list the files which are in the 
index, and with "git rm --cached", you remove the file _only_ from the 
index, but keep it in the working tree (if it is there).  The options "-z" 
and "-0" are only to separate the names by NUL instead of newlines, to 
allow funny file names, too.

If a few more people ask for that feature, we could enhance the semantics 
of "git branch" and "git checkout" to interpret the empty string 
similar to "git push <repo> :<name>".

Ciao,
Dscho

Re: how to combine two clones in a collection

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]

Thanks, Johannes, for this explanation. I actually had to prod him
on IRC a bit more until I understood, but the result is now
available on my blog:

  http://blog.madduck.net/vcs/2007.07.11_creating-a-git-branch-without-ancestry

  [...]
  Update: Johannes Schindelin taught me how to do the same without
  touching files in .git/:

  $ git symbolic-ref HEAD refs/heads/newbranch
  [...]

  and also addressed the issue which would have all files already
  committed to the "master" branch now appear in the git status
  output as staged.

  This is because the index contains the full copy of a revision of
  a file, as it would be if committed at any point. git status shows
  the differences between what has been committed, what would be
  committed, and what is available in the working tree. Since we
  pointed HEAD to nowhere ("newbranch" does not yet exist), the
  index and what has been committed (nothing in this case) diverge,
  the files are still staged, and thus are scheduled to be part of
  the impending commit.

  The way to fix this is to remove the index:

    $ rm .git/index

  This may seem weird, but it works, because git recreates the index
  whenever you switch branches:

    piper:~> git init-db
    Initialized empty Git repository in .git/
    piper:~> echo 1 > a; git add a; git commit -m.
    Created initial commit e774324: .
    1 files changed, 1 insertions(+), 0 deletions(-)
    create mode 100644 a
    piper:~> git symbolic-ref HEAD refs/heads/newbranch
    piper:~> rm .git/index
    piper:~> git status
    # On branch newbranch
    #
    # Initial commit
    #
    # Untracked files:
    #   (use "git add <file>..." to include in what will be committed)
    #
    #       a
    nothing added to commit but untracked files present (use "git add" to track)
    piper:~> echo 2 > b; git add b; git commit -m.
    Created initial commit 54ff342: .
    1 files changed, 1 insertions(+), 0 deletions(-)
    create mode 100644 b
    piper:~> git branch
      master
    * newbranch
    piper:~> git checkout master
    fatal: Untracked working tree file 'a' would be overwritten by merge.
    piper:~> git checkout -f master

    Switched to branch "master"
    piper:~> git status
    # On branch master
    nothing to commit (working directory clean)
    piper:~> ls
    a
    piper:~> git checkout newbranch
    Switched to branch "newbranch"
    piper:~> git status
    # On branch newbranch
    nothing to commit (working directory clean)
    piper:~> ls
    b

  As you can see, the creation of the branch is a bit complex, but
  once you (forcefully) switched back to master, you can then
  freely switch between and commit to them.

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
"when women love us, they forgive us everything, even our crimes;
 when they do not love us, they give us credit for nothing,
 not even our virtues."
                                                   -- honoré de balzac

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]