
Git 2.8.0 released - jjuhl
https://lkml.org/lkml/2016/3/28/436
======
avar
One of the relatively cryptic parts of the release notes is:

    
    
        * Update the untracked cache subsystem and change its primary UI from
          "git update-index" to "git config".
    

This is a feature we worked on, it means that you can do this:

    
    
        $ sudo git config --system core.untrackedCache true
    

And have [core] untrackedCache = true written to /etc/gitconfig. This'll speed
up "git status" and similar index operations significantly.

I've seen "git status" times go from ~400ms to ~200ms and from ~140ms to ~60ms
simply by setting this.

It could be set via "git update-index" in previous Git versions on a per-repo
basis, but not on a system-wide basis, this makes it easier to e.g. puppetize
it.

~~~
nicky0
Can you explain more about this feature? If it is such an improvement, why
would it not be enabled by default - are there any drawbacks to enabling it?

~~~
bicolao
Because it relies on filesystem changing directory's mtime every time a
file/dir is added or deleted in that directory. Not every filesystem supports
that.

~~~
amelius
Can't git just check whether the filesystem does this?

It would be a pity if an ignorant user copied a repository to another
filesystem only to find out that certain operations suddenly break.

Perhaps the option should include the filesystem UUID for which the option
should apply (to prevent these kinds of surprises).

~~~
pilif
_> Can't git just check whether the filesystem does this?_

it can by using `git update-index --test-untracked-cache` but it takes a long
time to check this, so I guess they don't want to incur that penalty on every
run.

OTOH,

 _> It would be a pity if an ignorant user copied a repository to another
filesystem only to find out that certain operations suddenly break._

yes. I agree. The way this is handled at the moment is dangerous to the point
of this not being worth it at all.

~~~
amelius
> it can by using `git update-index --test-untracked-cache` but it takes a
> long time to check this

How about just writing a file to a scratch directory, and see if the mtime of
the directory was changed?

~~~
dilap
or how about just turning it on automatically for known-supporting systems,
and leaving it as a system-wide config option for unknown systems?

~~~
Guvante
The underlying file system determines compatibility so there is no OS level
switch to check.

~~~
setpatchaddress
Seems like a flaw in POSIX -- there should be a bit in statfs (?) for
something like this.

~~~
telotortium
There is in struct statfs, which can be obtained for an open file descriptor
using the fstatfs(2) system call, if you (a) want to make this autodetection
OS-specific (statfs is Linux-specific, but I'm sure there's equivalents on
other OSs) and (b) maintain your own list of compatible file system types.

------
bjackman
Looks like the "notes" functionality is turning into something quite useful,
will be interesting to see if people start to use it in the future.

~~~
radarsat1
Cool, I didn't know about it. Does github (or another UI) integrate this
somehow? Could be very useful. In particular being able to take notes about
the purpose/goals of a branch strikes me as useful, something I wanted a long
time ago.

~~~
sanqui
Looks like GitHub used to support Notes, but they removed the functionality in
2014.

[https://github.com/blog/707-git-notes-
display](https://github.com/blog/707-git-notes-display)

------
tomlong
Does anyone maintain a relatively up to date Debian repo? I seem to be on
2.1.4.

I'm a relatively light user and it's not a huge concern, but searching for
'debian git repo' yields more or less exactly what you would expect.

~~~
caf
The easiest way is probably just to build it from source in your home
directory rather than installing it system-wide.

~~~
dmm
This is the way to do it. Run "apt-get build-dep git" to install the build
dependencies and the set "\--prefix=$HOME/opt" or whatever on the configure
script to control where it's installed.

Installing parts of testing or ubuntu can serious mess up your system and have
security consequences.

~~~
icebraining
You can also backport the package, it's usually rather easy; you should just
need to add a deb-src line for the testing repository to sources.list and then
run:

    
    
      apt-get update
      apt-get install build-essential fakeroot devscripts
      apt-get build-dep git
      apt-get -b source git
    

The last line will download the source package and immediately compile it,
generating a .deb file which you can then install:

    
    
      dpkg -i [package].deb

~~~
voltagex_
It looks like git 2.8.0-rc3 is the newest in the Debian archives.
[https://tracker.debian.org/pkg/git](https://tracker.debian.org/pkg/git) will
show when it's uploaded.

It corresponds to

commit 312e98e283ed7f62d72bb7ac07318285f1454c78

Author: Jonathan Nieder <jrn@google.com>

Date: Wed Mar 16 18:28:22 2016 -0700

    
    
        debian: new upstream release candidate
    
    
    

Sidenote: I wonder how far I'd get simplifying the `devscripts`
package/dependencies - your instructions will download 200+ megabytes of
packages `--no-install-recommends` will do 160.

Side sidenote:
[https://repo.or.cz/r/git/debian.git/](https://repo.or.cz/r/git/debian.git/)
is listed as Debian's upstream source for git, yet it doesn't use a valid SSL
certificate...

------
funkaster
This is very much welcomed:

    
    
      * You can now set http.[<url>.]pinnedpubkey to specify the pinned
      public key when building with recent enough versions of libcURL.
    

https is good, but if you can pin your certs, even better :)

------
skybrian
"It turns out "git clone" over rsync transport has been broken when the source
repository has packed references for a long time, and nobody noticed nor
complained about it."

So did they fix it or remove it?

~~~
peff
From the very first section (Backward compatibility note):

    
    
        The rsync:// transport has been removed.

------
beagle3
There was work to abstract git's hashids from being SHA1 (or at the very
least, uint8_t[20]) - does anyone know what's going on with that?

SHA1 is still useful against preimage attacks (which is mostly what git is
about), but freestart collisions are already known, and standard collisions
are expected within the next two months - so git is no longer secure against a
malicious committer.

------
rplnt
> The latest feature release Git v2.8.0 is now available at the usual places.

Out of curiosity, what exactly happened during 2.0 release that delayed
Windows version by several months?

~~~
taspeotis
The msysgit guys did a bunch of work on their build system or something or
other. If you look through their Google Group you'll find lots of info.

------
rhabarba
A new week, a new git security fuckup.

~~~
lfx
Care to elaborate?

