David Macek wrote:
First, there's the option of cloning the repository locally, which will result
in two working copies you can work on independently. Maybe too independently,
as each working copy has its own repo. If you want to see some structure there,
you can keep one clone as a bare repo and consider it primary. Git should use
hard links for local cloning, so the operation shouldn't be slower than with
Fossil.
While this is the intended solution (it's why "git clone" uses hardlinks
for the parts of the repository that can be safely shared when cloning
locally), it is inherently more limited in that you can't reference
branches in the other clones, can't diff/merge/etc. against a remote
branch that wasn't part of the original clone without first bringing it
in via "git fetch". This is not a problem that Fossil, Monotone,
Mercurial (with "hg share"), or Bazaar have (let alone any centralized
system). Ultimately, the standard Git workflow is designed around one
checkout per repository and doing something else generally requires you
to jump through some hoops.
Second, there's git-new-workdir. I have not used it, but it seems to exist exactly
for this use
case.<https://github.com/git/git/blob/master/contrib/workdir/git-new-workdir>
Note that git-new-workdir is not safe and can lose you data. The reason
is that the HEAD revision is local to the directory containing the
checkout when you use git-new-workdir. Thus, if you have multiple HEAD
revisions in different directories, only one will be traced by the
garbage collector. Because reflogs are checkout-local, too, the only
safety against data loss that remains is the two week grace period built
into the GC. I.e., you can get stuff like this:
[behrends@Hilbert /tmp/g2]$ git gc --prune=all
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (6/6), done.
Total 6 (delta 0), reused 6 (delta 0)
[behrends@Hilbert /tmp/g2]$ cd ../g
[behrends@Hilbert /tmp/g]$ git log --all
fatal: bad object HEAD
There's a reason why it's in contrib and not a first-class Git command.
In short: Don't use it unless you know exactly what you are doing.
Note: Git could relatively easily be fixed to support multiple
checkouts, but that would require deeper changes.
Reimer Behrends
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
