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.
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`.
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!
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).
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.
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.
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.
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:
> 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.
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:
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:
"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."
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.
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.
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.
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.
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.
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.
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.
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
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.
- 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.
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.
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.
I have commited with my work credentials to open source projects more times than I can count
reply