3 ms·

From the notes, this has landed: A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs sa

From the notes, this has landed: A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. Consider this as still an experimental feature; its UI is still likely to change. Let me play this up a bit: This is first-class support for multiple working trees per repository. There was a contrib script that could handle this to some extent, but had its warts. This SO post provides a bit more color on the new feature, the `git worktree` command: http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git/30185564#30185564 http://stackoverflow.com/questions/6270193/multiple-working-...

jacquesm 11y ago
This interests me quite a bit because I've been - forever - busy migrating a huge svn repo to git and the one thing that I keep running into is that 'subrepositories' doesn't quite cut it. Historically my svn is my datastore and I never bothered to set up multiple repositories. Github might very well be financially impacted if repositories that are now separate for technical reasons will be merged to become subtrees of one larger repository.
- saidajigumi 11y ago
  IIUC, your use case is commonly known as subdirectory checkouts. These can be done with git's sparse checkout facility[1], but you still have to make a full repository clone to create a sparse checkout. To clarify, multiple worktree support creates multiple checkout trees for one (local) .git repo directory. I.e. instead of the old two-clone way of having two working trees: $ git clone <URL>/foo.git foo1 $ git clone <URL>/foo.git foo2 Now it's possible to do this: $ git clone <URL>/foo.git foo1 $ cd foo1 $ git worktree add ../foo2 Enter ../foo2 (identifier foo2) Switched to a new branch 'foo2' N.B.: with multiple worktree support, a given branch name can only be checked out to one worktree at a time. E.g. following from the above example: $ cd ../foo2 $ git co master fatal: 'master' is already checked out at '/path/to/foo1/.git' Of course, in this workflow the new "foo2" branch will also be pointing at HEAD of origin/master. It's just that the local repo can only have one worktree pointing at a local branch at a time, otherwise git would have to automatically juggle some ugly and off-topic file synchronization stuff. [1] http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/ http://jasonkarns.com/blog/subdirectory-checkouts-with-git-s... edit: fixed a couple of confusing typos.
- smcgivern 11y ago
  The worktrees in this case are git branches, though. While this is convenient in some cases, it doesn't seem practical to me to have all of a group's code in one repo, but in different branches - it feels like it's fighting the git data model. (And to your closing point, it certainly feels like it's fighting the GitHub UI.) This might be me misunderstanding how your large svn repo was arranged, though. Could you describe that further?
Cymen 11y ago
That is exciting to me -- I was doing it the KISS way which was clone two copies of the repo when I wanted two working directories. That gets real old after a while -- I didn't need it often though so optimizing it didn't make much sense. But now git is going to make it easier for me.
- saidajigumi 11y ago
  Agreed. I often have second clones lying around, a main working clone and an "archaeological dig clone". I expect to get a ton of use out of `git worktree`.

jacquesm 11y ago

This interests me quite a bit because I've been - forever - busy migrating a huge svn repo to git and the one thing that I keep running into is that 'subrepositories' doesn't quite cut it. Historically my svn is my datastore and I never bothered to set up multiple repositories. Github might very well be financially impacted if repositories that are now separate for technical reasons will be merged to become subtrees of one larger repository.

saidajigumi 11y ago
IIUC, your use case is commonly known as subdirectory checkouts. These can be done with git's sparse checkout facility[1], but you still have to make a full repository clone to create a sparse checkout. To clarify, multiple worktree support creates multiple checkout trees for one (local) .git repo directory. I.e. instead of the old two-clone way of having two working trees: $ git clone <URL>/foo.git foo1 $ git clone <URL>/foo.git foo2 Now it's possible to do this: $ git clone <URL>/foo.git foo1 $ cd foo1 $ git worktree add ../foo2 Enter ../foo2 (identifier foo2) Switched to a new branch 'foo2' N.B.: with multiple worktree support, a given branch name can only be checked out to one worktree at a time. E.g. following from the above example: $ cd ../foo2 $ git co master fatal: 'master' is already checked out at '/path/to/foo1/.git' Of course, in this workflow the new "foo2" branch will also be pointing at HEAD of origin/master. It's just that the local repo can only have one worktree pointing at a local branch at a time, otherwise git would have to automatically juggle some ugly and off-topic file synchronization stuff. [1] http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-checkout/ http://jasonkarns.com/blog/subdirectory-checkouts-with-git-s... edit: fixed a couple of confusing typos.
smcgivern 11y ago
The worktrees in this case are git branches, though. While this is convenient in some cases, it doesn't seem practical to me to have all of a group's code in one repo, but in different branches - it feels like it's fighting the git data model. (And to your closing point, it certainly feels like it's fighting the GitHub UI.) This might be me misunderstanding how your large svn repo was arranged, though. Could you describe that further?

Cymen 11y ago

That is exciting to me -- I was doing it the KISS way which was clone two copies of the repo when I wanted two working directories. That gets real old after a while -- I didn't need it often though so optimizing it didn't make much sense. But now git is going to make it easier for me.

saidajigumi 11y ago
Agreed. I often have second clones lying around, a main working clone and an "archaeological dig clone". I expect to get a ton of use out of `git worktree`.