

Git 2.5.0 - tomkwok
https://github.com/git/git/blob/master/Documentation/RelNotes/2.5.0.txt

======
saidajigumi
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-...](http://stackoverflow.com/questions/6270193/multiple-working-
directories-with-git/30185564#30185564)

~~~
jacquesm
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
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-s...](http://jasonkarns.com/blog/subdirectory-checkouts-with-git-sparse-
checkout/)

edit: fixed a couple of confusing typos.

------
Ruud-v-A
Will Git for Windows ever be updated? It has been at 1.9.5 for quite a while
now …

~~~
e40
Cygwin's git is updated regularly.

~~~
josteink
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.

------
perlgeek
This sounds not exiting at all.

There's nothing wrong with releasing a bunch of small improvements, I just
don't see why it's worth a HN front page entry, even as a regular git user.

~~~
chimeracoder
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.

~~~
cdelsolar
.gitignore

~~~
verbatim
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.

So, please elaborate.

~~~
hyperchase
> Files that are more specific to a particular developer or workflow don't
> always fit in there well.

git config --global core.excludesfile ~/.gitignore

