8 ms·

Git 2.5.0

113 points by tomkwok 11y ago

Ruud-v-A 11y ago
Will Git for Windows ever be updated? It has been at 1.9.5 for quite a while now …
- e40 11y ago
  Cygwin's git is updated regularly.
  - josteink 11y ago
    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.
- cool-RR 11y ago
  https://github.com/git-for-windows/git/releases https://github.com/git-for-windows/git/releases I use Git 2.4.3 on Windows. (Using Msysgit.)
- papercrane 11y ago
  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. https://github.com/msysgit/ https://github.com/msysgit/ https://github.com/git-for-windows/ https://github.com/git-for-windows/ https://github.com/git-for-windows/git/releases https://github.com/git-for-windows/git/releases
- james-skemp 11y ago
  I'm using Chocolatey to keep Git up-to-date, as at some point it was a recommendation. Unfortunately it appears the new Git for Windows project isn't one of the packages, but we do have https://chocolatey.org/packages/git https://chocolatey.org/packages/git Does anyone have any insight on whether Chocolately is still a recommendation, and if so, where we might find a 2.x package?
  - electricEmu 11y ago
    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. https://github.com/git-for-windows/git/issues/15 https://github.com/git-for-windows/git/issues/15
    - james-skemp 11y ago
      Hmmm. Good find; thank you.
- joshka 11y ago
  Also see https://github.com/git-for-windows/git/issues/244 https://github.com/git-for-windows/git/issues/244 for a bit more on their release / reasoning.
perlgeek 11y ago
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 11y ago
  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 11y ago
    .gitignore
    - bicolao 11y ago
      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.
    - verbatim 11y ago
      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.
      - jrodl3r 11y ago
        obviously, you're not a golfer.
saidajigumi 11y ago
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.

Git 2.5.0

113 points by tomkwok 11y ago

Ruud-v-A 11y ago

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

e40 11y ago
Cygwin's git is updated regularly.
- josteink 11y ago
  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.
cool-RR 11y ago
https://github.com/git-for-windows/git/releases https://github.com/git-for-windows/git/releases I use Git 2.4.3 on Windows. (Using Msysgit.)
papercrane 11y ago
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. https://github.com/msysgit/ https://github.com/msysgit/ https://github.com/git-for-windows/ https://github.com/git-for-windows/ https://github.com/git-for-windows/git/releases https://github.com/git-for-windows/git/releases
james-skemp 11y ago
I'm using Chocolatey to keep Git up-to-date, as at some point it was a recommendation. Unfortunately it appears the new Git for Windows project isn't one of the packages, but we do have https://chocolatey.org/packages/git https://chocolatey.org/packages/git Does anyone have any insight on whether Chocolately is still a recommendation, and if so, where we might find a 2.x package?
- electricEmu 11y ago
  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. https://github.com/git-for-windows/git/issues/15 https://github.com/git-for-windows/git/issues/15
  - james-skemp 11y ago
    Hmmm. Good find; thank you.
joshka 11y ago
Also see https://github.com/git-for-windows/git/issues/244 https://github.com/git-for-windows/git/issues/244 for a bit more on their release / reasoning.

perlgeek 11y ago

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 11y ago
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 11y ago
  .gitignore
  - bicolao 11y ago
    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.
  - verbatim 11y ago
    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.
    - jrodl3r 11y ago
      obviously, you're not a golfer.

saidajigumi 11y ago

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.