git conversion in progress

Jonathan Wakely jwakely.gcc@gmail.com
Tue Jan 14 16:08:00 GMT 2020


On Tue, 14 Jan 2020 at 14:28, Martin Jambor <mjambor@suse.cz> wrote:
>
> Hi,
>
> On Tue, Jan 14 2020, Andreas Schwab wrote:
> > On Jan 14 2020, Georg-Johann Lay wrote:
> >
> >> git clone --reference original-gcc ...
> >
> > Don't use --reference.  It is too easy to lose work if you don't know
> > what you are doing.
>
> What are the risks, assuming I won't delete the referenced repo which
> sits on the same partition of the same local disk as the new one?

If I understand correctly (and I don't use --reference so I might be
wrong), with --reference you need to do a git fetch in each separate
repo when you want to upate, because although they share objects they
each have their own "view" of the remotes.

If you do a git pull in a clone created with --reference it will fetch
new objects and store them locally, it won't update the referenced
repo. This means they can diverge over time and aren't sharing as much
as possible (I assume that can be resolved by repack or gc? I don't
know).

Also, anything committed to any worktree is instantly visible to the
others. I have worktrees for master, gcc-9 and gcc-8. After I backport
something to gcc-9 (but before I push it upstream) I can go to the
gcc-8 worktree and do 'git cherry-pick gcc-9' to apply the newest
commit from gcc-9 branch to the gcc-8 branch. There's no need to push
or pull anything between the worktrees, because they are all using the
same clone with the same local branches.

> I prefer it to worktree because I often just do have master checked out
> in multiple directories and worktree would be unhappy about that...

Sounds like a good use for branches :-)

> and
> the risk of accidentally deleting the base worktree are IMHO the same as
> the risk of deleting the referenced repo.

For me, there is zero chance that I'll ever think ~/src/gcc/gcc is an
old tree I don't use. It's also the one where I do work on 'master'
(or branches created from 'master') so I'm unlikely to ever think
that's an unwanted throwaway tree that I don't need. With worktrees
you'll only have 'master' checked out in one of your trees, so it
doesn't take a lot of discipline to know which one is the one
containing all the .git/objects and other repository metadata.

> Anything that I am missing?  (In other words, do I know what I am doing? :-)



More information about the Gcc mailing list