8 ms·

Git 2.8.0 released

278 points by jjuhl 11y ago

bjackman 11y ago
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.
- ioquatix 11y ago
  What is the notes functionality?
  - deleted 11y ago
    [deleted]
  - masklinn 11y ago
    The ability to associate metadata to a commit without editing the commit itself.
- d0lph 11y ago
  Had not heard of these, interesting ... "A typical use of notes is to supplement a commit message without changing the commit itself. Notes can be shown by git log along with the original commit message. To distinguish these notes from the message stored in the commit object, the notes are indented like the message, after an unindented line saying "Notes (<refname>):" (or "Notes:" for refs/notes/commits)." (https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes)
- radarsat1 11y ago
  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 11y ago
    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
  - bjackman 11y ago
    Yeah pretty much nobody uses them because they're half-baked from a UI perspective. This looks like progress (getting rid of the arbitrary restriction to refs/notes), but there may be other things lacking still.
- notatoad 11y ago
  it would be really amazing if web services like GitHub and Bitbucket could implement their commit comment features as git-notes so you could see team members' comments offline after a pull, just using git-log rather than having to sign into the website.
tomlong 11y ago
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.
- quarterto 11y ago
  The answer seems to be "install it from the Ubuntu Precise repository": https://berezovskiy.me/2015/02/update-git-on-debian/ https://berezovskiy.me/2015/02/update-git-on-debian/
  - 0x0 11y ago
    Installing libc6 from testing is scary advice. Then you're basically halfways to running testing overall. That may have security implications (there's been several DSAs for glibc), and traditionally it's also been a source of incompatibilities.
  - martey 11y ago
    The instructions in that blog post look like a good way to break your system: https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank...
- mbrock 11y ago
  The latest 2.8.0 release candidate is in testing, so you can try installing that with pinning.
  - avar 11y ago
    This doesn't work with a lot of packages because they depend on some newer C library that would have to upgrade pretty much all of your installation from stable, but I've just tested this now and pinning "git git-svn git-email git-man" to testing/unstable on an otherwise stable distro works.
- deleted 11y ago
  [deleted]
avar 11y ago
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.
- deleted 11y ago
  [deleted]
- nicky0 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        >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.
rplnt 11y ago
> 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 11y ago
  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 11y ago
A new week, a new git security fuckup.
- lfx 11y ago
  Care to elaborate?
skybrian 11y ago
"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 11y ago
  From the very first section (Backward compatibility note): The rsync:// transport has been removed.
beagle3 11y ago
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.
funkaster 11y ago
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 :)

278 points by jjuhl 11y ago

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.

ioquatix 11y ago
What is the notes functionality?
- deleted 11y ago
  [deleted]
- masklinn 11y ago
  The ability to associate metadata to a commit without editing the commit itself.
d0lph 11y ago
Had not heard of these, interesting ... "A typical use of notes is to supplement a commit message without changing the commit itself. Notes can be shown by git log along with the original commit message. To distinguish these notes from the message stored in the commit object, the notes are indented like the message, after an unindented line saying "Notes (<refname>):" (or "Notes:" for refs/notes/commits)." (https://git-scm.com/docs/git-notes https://git-scm.com/docs/git-notes)
radarsat1 11y ago
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 11y ago
  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
- bjackman 11y ago
  Yeah pretty much nobody uses them because they're half-baked from a UI perspective. This looks like progress (getting rid of the arbitrary restriction to refs/notes), but there may be other things lacking still.
notatoad 11y ago
it would be really amazing if web services like GitHub and Bitbucket could implement their commit comment features as git-notes so you could see team members' comments offline after a pull, just using git-log rather than having to sign into the website.

tomlong 11y ago

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.

quarterto 11y ago
The answer seems to be "install it from the Ubuntu Precise repository": https://berezovskiy.me/2015/02/update-git-on-debian/ https://berezovskiy.me/2015/02/update-git-on-debian/
- 0x0 11y ago
  Installing libc6 from testing is scary advice. Then you're basically halfways to running testing overall. That may have security implications (there's been several DSAs for glibc), and traditionally it's also been a source of incompatibilities.
- martey 11y ago
  The instructions in that blog post look like a good way to break your system: https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank...
mbrock 11y ago
The latest 2.8.0 release candidate is in testing, so you can try installing that with pinning.
- avar 11y ago
  This doesn't work with a lot of packages because they depend on some newer C library that would have to upgrade pretty much all of your installation from stable, but I've just tested this now and pinning "git git-svn git-email git-man" to testing/unstable on an otherwise stable distro works.
deleted 11y ago
[deleted]

avar 11y ago

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.

deleted 11y ago
[deleted]
nicky0 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      >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.

rplnt 11y ago

> 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 11y ago
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 11y ago

A new week, a new git security fuckup.

lfx 11y ago
Care to elaborate?

skybrian 11y ago

"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 11y ago
From the very first section (Backward compatibility note): The rsync:// transport has been removed.

beagle3 11y ago

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.

funkaster 11y ago

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 :)