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:
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.
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
$ 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.
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?
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.
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`.
I went looking, at it looks like the project has moved from msysgit to git-for-windows, and it is tracking git more closely. Just not ready for release yet I guess. There are release candidate builds available though if you're feeling adventurous.
One annoying thing with cygwin's git is that it (cygwin) handles file permissions differently from how windows applications handles them, meaning you easily get permission changes inadvertantly included in your changesets unless you explicitly undo those changes from cygwin before staging and committing.
It definitely makes using git fell less seamless than it can be.
You can always have Appveyor create a package for you. It looks like they currently are waiting to support Chocolatey, though that's kind of ridiculous. It seems like everything should work fine v1 bundled in a single zip until each component is split out.
Maybe not for you, but there are a number of things in here that could be relevant to people's workflows. For example:
> The index file can be taught with "update-index --untracked-cache" to optionally remember already seen untracked files, in order to speed up "git status" in a working tree with tons of cruft.
There are some companies out there that are using Git at such a scale that `git status` already takes as much as 20 or 30 seconds to complete. I'm not sure if this would speed up that particular issue, but it just goes to show that Git has a large range of use cases. Not all regular git users have the same needs.
I'm left to guess at what you mean by this exactly, but, .gitignore only helps with things that are agreed to be ignored by everyone. Files that are more specific to a particular developer or workflow don't always fit in there well.
But, I'm not sure that's what this new capability helps with anyway.
part of the --untracked-cache feature is to reduce the cost of applying .gitignore patterns. When you have tons of files to check against some patterns, even strcmp() accumulates up.
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-...