multiple checked out branches

multiple checked out branches

[Domenico Andreoli]

Hi again,

  I would like to contemporaneously work with multiple branches out of
the same git repository. This does not work out of the box.

So I prepare multiple copies of the same repository, every one will have
its own checked out branch but I want to share most of their .git subdir.

I surely want to share the object db, the local and remote refs.
This way it is enough to make a round of fetches/merges/pushes to have
all the shared-repositories up to date.

I expect to do the trick with some symlinks but I am not an expert of
git internals. Which traps are waiting me? Any hint? Thank you.

Regards,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: multiple checked out branches

[Julian Phillips]

On Thu, 2 Aug 2007, Domenico Andreoli wrote:

> Hi again,
>
>  I would like to contemporaneously work with multiple branches out of
> the same git repository. This does not work out of the box.

Depends on how you define "the box" ...

There is a script to do this in contrib called git-new-workdir.  It allows 
you to have multiple working directories from the same repository for 
exactly this purpose.

> So I prepare multiple copies of the same repository, every one will have
> its own checked out branch but I want to share most of their .git subdir.
>
> I surely want to share the object db, the local and remote refs.
> This way it is enough to make a round of fetches/merges/pushes to have
> all the shared-repositories up to date.
>
> I expect to do the trick with some symlinks but I am not an expert of
> git internals. Which traps are waiting me? Any hint? Thank you.

Symlinks are exactly what is used by new-workdir to link the workdirs back 
to the original repository.

The biggest issue with doing this is that you have no protection against 
making changes on the same branch in more than one place - something you 
really don't want to be dealing with.  Basically you need to be careful 
about updating refs that you have checkedout in workdirs.

-- 
Julian

  ---
...when fits of creativity run strong, more than one programmer or writer has
been known to abandon the desktop for the more spacious floor.
- Fred Brooks, Jr.

Re: multiple checked out branches

[Domenico Andreoli]

On Wed, Aug 01, 2007 at 11:19:25PM +0100, Julian Phillips wrote:
>
> The biggest issue with doing this is that you have no protection against 
> making changes on the same branch in more than one place - something you 
> really don't want to be dealing with.  Basically you need to be careful 
> about updating refs that you have checkedout in workdirs.

Yes, I figured out this would have been a problem after thinking at it
a bit more. I surely do not want to be careful about acting on the same
branch in two working repositories at the same place.

The actual problem is that switching form a branch to another makes
my autotools fuck and I have to rebuild stuff all the time. My box is
still a faint-hearted single core...

cheers,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

Re: multiple checked out branches

[Guilhem Bonnefille]

On 8/2/07, Domenico Andreoli <cavokz@gmail.com> wrote:
> On Wed, Aug 01, 2007 at 11:19:25PM +0100, Julian Phillips wrote:
> The actual problem is that switching form a branch to another makes
> my autotools fuck and I have to rebuild stuff all the time. My box is
> still a faint-hearted single core...

I encounter same problem. Actually, I did full rebuild every time
(which is counter-productive). But, reading at your mail, I have an
other idea: what about the "remote" compilation offered by autotools?

Normally, autotools are design in such way that you can share the same
source for different configuration. To do this, simply create one
"build" directory per branch, go to this directory and do:
../configure && make

I'm unable to try it now, so I express now all my "confuses" if it was
a bad idea.
-- 
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/

Re: multiple checked out branches

[Alex Riesen]

Domenico Andreoli, Thu, Aug 02, 2007 00:04:35 +0200:
> Hi again,
> 
>   I would like to contemporaneously work with multiple branches out of
> the same git repository. This does not work out of the box.
> 
> So I prepare multiple copies of the same repository, every one will have
> its own checked out branch but I want to share most of their .git subdir.
> 
> I surely want to share the object db, the local and remote refs.
> This way it is enough to make a round of fetches/merges/pushes to have
> all the shared-repositories up to date.
> 
> I expect to do the trick with some symlinks but I am not an expert of
> git internals. Which traps are waiting me? Any hint? Thank you.
> 

No traps. Supported. See for "git clone -s" and "git clone -l"

Re: multiple checked out branches

[Johannes Schindelin]

Hi,

On Thu, 2 Aug 2007, Alex Riesen wrote:

> Domenico Andreoli, Thu, Aug 02, 2007 00:04:35 +0200:
> > 
> >   I would like to contemporaneously work with multiple branches out of
> > the same git repository. This does not work out of the box.
> > 
> > So I prepare multiple copies of the same repository, every one will have
> > its own checked out branch but I want to share most of their .git subdir.
> > 
> > I surely want to share the object db, the local and remote refs.
> > This way it is enough to make a round of fetches/merges/pushes to have
> > all the shared-repositories up to date.
> > 
> > I expect to do the trick with some symlinks but I am not an expert of
> > git internals. Which traps are waiting me? Any hint? Thank you.
> > 
> 
> No traps. Supported. See for "git clone -s" and "git clone -l"

That is not completely what is wanted, AFAIU:  "git clone -s" and "git 
clone -l" allow for unsynchronised branches.  For example, when you 
committed to branch "foo" in the cloned repo, branch "foo" in the original 
repo will be older until you push.

Ciao,
Dscho