Git 2.13 | Hacker News Reader

Git 2.13

github.com

240 pointsedmorley76 comments

Hidden in the notes at the bottom is a pretty useful improvement to 'git stash':

> 'git stash save' now accepts pathspecs. You can use this to create a stash of part of your working tree, which is handy when picking apart changes to turn into clean commits.

I believe there may be a slight error in the GitHub blog post I quoted above: from what I can tell, it's actually the 'git stash push' command that now accepts pathspecs. But either way, still a neat new feature!

Oh awesome! Much better then commit everything else, stash, then reset

Yes, you're right. The `push` command was added because of backwards compatibility issues with `save` (and essentially replaces it).

What are the improvements of push over save? Does it allow incrementing a stash?

It's essentially the same except for the arguments. `save` took the whole command-line to be the stash message, which was confusingly unlike the rest of Git (and needed to be addressed before pathspec support could be added).

Was confused with the docs. Now it makes sense, the difference between save and push.

It's worth noting that "git stash -p" (aka "git stash --patch") already exists and allows you to commit individual files or hunks within a file. Though the cost is going through an interactive interface, so some users might prefer the new "git stash push". Still, if you can't upgrade, use "git stash -p".

Patch and interactive modes are the best thing next to sliced bread. I'll start with a feature and end up refactoring something and it's difficult to organize large sets of changes without them.

They're definitely prereqs to upper-level git wizardry

If you can upgrade you can use "git stash -p" with pathspecs as well, so you can stash some changes in a specific file without having to go through changes in other files.

Ooh, this might mean some vim-fugitive beauty is on the horizon :-)

The vim-fugitive Gdiff is a really nice interface (imo) and a stash equivalent would be amazing :-)

To me the most useful parts of fugitive, the only things that actually feel more useful than the command line equivalents, are fugitive-:Gdiff and fugitive-:Gblame.

:Gblame is particularly useful.

Did you try tig [1]? I prefer the command line solution to shoving complicated things and UI (which fugitive is -- I could barely remmeber all the features I had and like you, I only really ever used the :Gblame command the most) into vim. I prefer to have vim be lightweight and let other tools do their job (i.e the UNIX way).

I don't use fugitive now but I do make full use of tig. In my .vimrc I have:

    nnoremap <leader>gb :echo system("git rev-parse --abbrev-ref @ <bar> tr -d '\n'")<CR>
    nnoremap <leader>go :silent !tig<CR>:silent redraw!<CR>
    nnoremap <leader>gB :silent !tig blame % +<C-r>=expand(line('.'))<CR><CR>:silent redraw!<CR>

The above solution leaves vim purely for editing, and tig for doing the actual git presentation.

Asciinema demo of tig blame: https://asciinema.org/a/4as7ujt8cpnpyx0doyrervatl

Just like fugitive, I can travel back and forth through history. And if I hit q, I'm back in vim.

[1]: https://github.com/jonas/tig

I also sometimes find :Gstatus useful when resolving merges/rebases/cherry-picks. Makes it easier and faster to iterate through the affected files.

Oh I am really digging the change to allow directory level configs for config settings.

I have commited with my work credentials to open source projects more times than I can count

Not uncommon! This is why .gitignore is the first thing I explain to git newcomers.

I think you misread the parent comment. They didn't say "committed my work credentials", it was "committed with my work credentials". As in they have two different identities and used the wrong one when committing a change, so the commit author was incorrect.

Being able to set configs per directory provides a workaround.

Yeah I totally misread that...

Nevertheless, .gitignore should still be the first thing you learn about git :)

Indeed. My current workaround was simply not to put any email in ~/.gitconfig. Upon commiting for the first time in a new repo git would complain, then I could set the correct email for this particular repo using `git config user.email $email`.

I think this only works if you set `git config --global user.useconfigonly true`, otherwise git will try to guess your name/email.

It does, thank you for that tip! So far I'd just `git commit --amend --reset-author` after setting the email the first time.

> git branch, git tag, and git for-each-ref all learned the --no-contains option to match their existing --contains option. This can let you ask which tags or branches don't have a particular bug (or bugfix).

I'm surprised that didn't exist already. Several years ago, I worked on a tool to scan SVN merge history and save in a graph database so one could ask this type of question, "Does this branch contain the fix?". Or the opposite, "Which branches do not contain this fix?".

It was a mess because there were 8 million commits in the repo and clients ranged from SVN 1.4 to SVN 1.8 (the server was upgraded too).

It would have made more sense to use git for something like that but it's hard to get thousands of devs to switch.

Pretty sure this already existed with different syntax.

Under those circumstances I'd probably use git svn, I always found git svn to be a better svn client than svn.

Does git svn build a local git repo out of the svn server or just act as a normal svn client?

I implemented that feature in the 2.13 release, glad to see interest in it, more details on how it works & can be used from the commit message[1]:

This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c725, the git version to revert to can be found with this hacky two-liner:

    (git tag -l 'v[0-9]*'; git tag -l --contains cf5c725 'v[0-9]*') |
        sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10

With this new --no-contains option the same can be achieved with:

    git tag -l --no-contains cf5c725 'v[0-9]*' | sort | tail -n 10

As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0:

    git branch --contains v2.8.0 --no-contains v2.10.0

1. https://github.com/git/git/commit/ac3f5a346860b824e083c5d305...

Very cool! Thanks for the examples and linking back to the commit :+1:

Anyone know what has happened to the OSX builds? The de-facto project 'git-osx-installer' doesn't have binaries after 2.10

https://sourceforge.net/projects/git-osx-installer/files/?so...

git-scm.com says:

"You are downloading version 2.10.1 of Git for the Mac platform. This is the most recent maintained build for this platform. It was released 7 months ago, on 2016-10-14."

https://git-scm.com/download/mac

Probably homebrew. `brew install git --HEAD` gives v2.12.0, and I'm apparently using v2.11.0. It installs bash and zsh completions too, which are nice.

Not everyone wants to use that travesty of a "package manager".

The person you replied to was asking specifically about the native macos packages linked from the git official website.

Why is it a travesty?

It has fundamental flaws in how it handles dependencies, particularly when dealing with binary packages.

installing user-owned global software is a terrible idea.

The maintainers of homebrew are aware of both issues and simply don't care: they are not going to fix either, because they won't even acknowledge that they're actual problems.

Possibly because many people use their software and are very happy with it without running into those issues and addressing them would be a tremendous amount of work.

They have put in work to actively prevent use as root, even with binary packages.

This isn't just "its going to take too long", this is "fuck you, we know better than every OS vendor on the planet"

Packages are often downloaded from third party sites, blindly running those with Sufi sounds like a terrible idea. Most developer Mac's are single user anyway.

It's not like apt, yum or WU where the updates come from a trusted source.

The "trusted" source in this case is Homebrew. The rest of your argument makes no sense, because homebrew is designed to be a trusted source - the recipes aren't just downloaded from any random URL.

Being single user doesn't make installing software user owned any less of a bad idea.

... the recepies then download code from random sources. Obviously vetted sources, but it's not a central repository with all of the packages that is controlled by Homebrew like the other package managers you list.

It's just a big git repository of recepies, which are exactly that. Instructions on how to combine things (source code, binaries, flags etc) from external sources.

Not random, specific source archives, listed in the recipe, along with a known hash of the file being downloaded.

Given that, it effectively is a central repo that is controlled by Homebrew.

> Being single user doesn't make installing software user owned any less of a bad idea.

Can you explain why you believe that?

Running `sudo make install` in order to install software on your own laptop is a terrible idea. I've used homebrew on a mac daily for 6 years and it has worked perfectly. If it has fundamental flaws why have they not affected me?

> Running `sudo make install` in order to install software on your own laptop is a terrible idea.

Why do you believe that requiring administrator rights to install global software is "a terrible idea" ?

Every single OS-vendor provided software install mechanism on computing devices in use today uses this concept.

Keep in mind that I'm talking about installing, not building. No one sane suggests `sudo make && sudo make install`. It's always `make && sudo make install`. Homebrew not just doesnt do this by default, it prevents this model of building & installing, and won't even allow pre-build binaries to be installed as root.

1. Because installing (frivolous) user utilities should not have the ability to write to critical system files, by default at least.

2. Because there's no make uninstall.

I've had this argument with others who get similarly worked up about homebrew as you seem to. I think the problem may be that you're thinking about installing core system utilities, whereas we're talking about installing all our frivolous user-domain software. So whatever package we happen to have read about and thought "oh I'll try that out". Prior to using OS X for the last 6 years my personal laptop ran Linux for the 10 years prior to that. Not everything was available via apt-get, and I know from far too much first-hand experience the dangers of installing software with root permissions, and not being able to reverse the process, so there's really no question in my mind that you're wrong; I suspect we must be answering subtly different questions as I said above.

Can you explain why you're emphasizing global software? You sound like you're talking about being a sys admin for a shared computing resource. We are just talking about our laptops.

Very occasionally we put on the hat of "administrator" of our laptop, but mostly we have on the hat of "the single user".

Now, how about my question: if it's as bad as people like you say, then why does it work so well for so many people?

> Because installing (frivolous) user utilities should not have the ability to write to critical system files, by default at least.

This is why there was a thing like `$PREFIX`. I have a ~/.local folder, the user-specific equivalent of the system /usr/ folder. All the frivolous software I install for my-unix-account local needs go in there and my OS remains pristine. I currently have my $GOPATH, user npm packages, and even some .desktop applications in there.

Are you referring to the `--prefix` option that `configure` takes in the traditional unix `configure && make install` process?

(EDIT: I didn't mean to sound like I was correcting you. In fact I'm sure you know this stuff better than me. I now see that there's both a commonly-honored environment variable "PREFIX" and the command-line option to configure I mentioned, and I'm going to claim that the fact that there's two degrees of freedom and I'd forgotten about one of them kind of backs up my points!)

If so, while I agree that that serves the purpose and avoids use of `sudo`, I would think that the following two drawbacks are severe:

1. It's a lot (really, too much?) to ask of the community of laptop users who wish to use command line utilities -- we don't want to make using the command line the province of real unix experts only; everyone is a beginner at some point after all.

2. Not all software will offer this option.

The reasons you supply are partly why I said "there was a thing". It isn't as much of a thing in these `curl ... | sh` and `docker run` and Electron apps days.

But the first reason you cited can be handled gracefully by package managers at least (including Homebrew), if only they took the effort.

But homebrew does use `make install` in many, many formulae doesn't it?

  homebrew-core/Formula$ grep 'system.*make.*install' * | wc -l
  2774

I don't think I quite understand the complaints that the unix traditionalists have against homebrew. I don't mean to imply that there are no valid ones; I'd like to understand.

Preface: I don't argue either in favour or against homebrew here.

From the limited number of times I had to set up homebrew, I noticed the official method tells the user to take over /usr/local/ (via a `sudo chown ...`). They could have made the process use ~/.local, but don't. And because of the official position on using /usr/local/, lots of homebrew formulae assume and depend on /usr/local/.

Without taking the side of the "unix traditionalists" you speak of, I can understand their point. Homebrew doesn't have to take over a system location for user-account specific software, but it does.

If they're frivolous, install them in $HOME/bin, and you don't need root.

I'm not suggesting make as an alternative to a package manager, I'm saying that nowhere else is it considered OK to install global programs without requiring admin/root permissions.

I'm emphasising "global" software because homebrew installs to /usr/local/ by default, which is a machine global directory.

The issue with permissions is about security, and like most security problems, being bad/terrible has no correlation on userbase. How many people use {android,Windows,Wordpress,...} despite a terrible security record.

Can you explain why it's so bad to have user-owned files in /usr/local on a single-user mac laptop?

What exactly goes wrong with dependencies? Are macports any better in that regard?

Dependencies become hardcoded at build time, so any binary 'bottle' whose source package has dependencies that are satisfied by 1+ packages will become hardcoded to just one of those dependencies.

https://github.com/Homebrew/legacy-homebrew/pull/41595#issue...

Note that the maintainers response was: fuck it, the users can just re-complile this package every time they install it.

I only meant that Homebrew is so popular that I wouldn't be surprised if it was the reason why the OS X builds on the official website fell into disrepair.

I see. Thats frankly a poor state of affairs if it's the case.

The linked builds from git-scm.com are built by https://github.com/timcharper/git_osx_installer (but hosted on sourceforge for some bizarre reason), however that repo seems a little inactive lately, bar issues from users.

Another thing to love about Mercurial: the project handles packaging, rather than relying on third parties to do their job for them: https://www.mercurial-scm.org/downloads

I too can randomly insult things and attribute obscenities to people I disagree with.

But that doesn't substitute for making an actual argument, which I notice you have failed to do in any of your replies to other people in this thread.

> randomly

What is random about what I've said? I have very specific issues with Homebrew, and I'm pretty consistent in my complaints about it:

https://hn.algolia.com/?sort=byDate&prefix&page=0&dateRange=...

> which I notice you have failed to do

Perhaps need to notice what I actually write then, because I have made very specific complaints about the policies and actions of the Homebrew project/maintainers.

You can check where they're being pulled from easily; someone will need to update the git package for homebrew.

https://www.kernel.org/pub/software/scm/git/

I have failed in my job as an unpaid volunteer maintainer. I should recruit others to be able to do this, and enable them.

The "includeIf" thing based on filesystem paths for setting the user.email gitconfig seems useful!

On git moving away from SHA1: it's about time.

- There shouldn't be too many nor too few hash algos. Too many: paradox of choice, user confusion and interop overhead. Too few: security monoculture risks being broken by well-funded state actors

- Sane, future-ready default: SHA3-512

Also, git GPG signing should change to signing content, in addition to or instead of, hashes.

Isn't signing a hash the standard procedure for signatures?

The thing is, you are signing hash of a hash of data instead of simply hash of data.

What would be the benefit of signing content instead of hashes?

The benefit would be to trust the content, and not the hash of the content. Esp. with SHA1 being the only hash so far.

Release notes:

https://git.kernel.org/pub/scm/git/git.git/tree/Documentatio...

Anyone know where to get clean git builds for Windows without any extra crap like the "git for Windows" builds have?

- Windows comes with bash

- Microsoft have an excellent openssh implementation on their github

- I don't want some dude's cool $PS1 and shortcuts and icons.

I just want git.

The GitHub page seems to have `MinGit` releases : https://github.com/git-for-windows/git/releases/latest

MinGit-2.13.0-64-bit.zip\usr\bin still includes an entire copy of openssh and much more besides.

> Windows comes with bash

That's an extremely charitable way of phrasing it. 64-bit Windows 10 in developer mode has bash as an optionally installable component. AFAIK, bash is not installed by default and it's unavailable on 32-bit or in older Windows versions.

If you want to allow a wide range of users, including those with corporate- or government-IT issued machines, to run your build, you need to support older Windows versions down to at least 7. Which means that you cannot assume native bash.

Nobody is discussing assuming anything. It's simply preferable to have optional components for legacy systems than to add a second copy of bash and ssh to every machine.

It is certainly preferable to you and others in a similar situation. It is, I suspect, somewhat less preferable to git maintainers, who would need to build and test an additional binary package using a different toolchain for every release, and deal with bug reports from confused users mixing up git-with-bash and git-without-bash.

Not related to this but please github choose a better font to render code in android browsers, the current one's unreadable!

Looks fine to me. What version are you on?

Chrome 58 on android 6.0.1 and the device is nexus 7 2013

Borrowed someones nexus [praise Duarte?] to check this... Text looks good, code snippets looks kinda crap. Not unreadable but not great either.

Same page looks great on firefox so this is chrome shenanigans.

I thought GitHub used system fonts?

https://news.ycombinator.com/item?id=12075623

They try, but there is not really predictable and simple way to select those fonts in CSS. I've had times when Courier was used on Linux because the MS fonts we installed.

I would prefer they just do font-family: monospace

Is this the problem where it appears almost double spaced? That's what I get on Chrome 58.0.3029.83. And the scrolling performance is horrible, I assume it's some js stuff happening.

Reply on news.ycombinator.com