I'm a somewhat advanced user of Git. My coworkers use me as a reference when they have a problem of a difficult merge to solve.
I don't follow each Git release, but I also didn't notice a great productivity enhancement for a long time. Sure it is a sign of a mature project, but I'd like to know:
What's the somewhat recent Git feature that you really improved your productivity?
For the past few years the performance work (e.g. commit graph) has made a huge difference for large/fast moving repos. They're big enough to be productivity enhancements for some people: when we merged our Android-like multi-repo setup into a proper mono-repo we required updating git because things like git status/git commit/git log could take minutes without the recent perf fixes.
It pays to follow the release notes because some of these features are opt-in (e.g. commit graph is still optional).
The sparse checkout stuff is great but still too low-level for us to use, but it's laying the groundwork for something good.
Conversely, I hit that years ago (long-running migration tarpit) and forgot about it until I setup a clean home directory on a system which didn’t have my dotfiles repo and thought I’d hit a major Git regression. It saves you time on exactly where you need it the most.
I guess it reduces duplicating the history? Large files are by far the bulk of what I personally deal with so it don't think there's a real difference for me but I could see it helping.
The `--reference` and `--dissociate` flags to `git clone` can be used to avoid the majority of the network transfer while still creating an independent local repository.
Those confusing switches are already ingrained in my memory (or hidden away behind aliases) and now I find it more confusing that git is recommending new and different commands to do things that I've been doing a fixed way for years.
`git restore <file>` instead of `git checkout -- <file>`is another one.
Well, I guess the good thing here is that they're not going to remove the old checkout behaviour. And these new commands are much easier to use and understand for a beginner.
It's not just better name for doing "git checkout -- path". "git checkout" has this stupid behavior of restoring files to worktree and index. "git restore" by default doesn't touch index (I wrote SO answer that explains this a bit more: https://stackoverflow.com/a/60855504/350384)
there is also "git switch" but I just kept using "git checkout" because there is nothing "git switch" can do that "git checkout" can (it's just a shorter name but I had aliased "checkout" to "ch" anyway, as many people do)
I just came back to git and gitlab from Perforce and while it's felt like coming home and some things are improving around submodules and LFS there's still a lot of rough edges I'd like to see smoothed over.
Its not easy to set up git config settings for a distributed team. I assume for security reasons a repo can't configure its own settings just from a pull but even still I want that functionality.
Why do I check in the name of the merge tool used for a file type in the .gitattributes but I can't check in what that name points to?
I work with less technical artists and they really don't want to think about git configs at all. They just want to save and push. As far as I know there's no solution to preconfigure a repo to pull submodules or set up custom merge drivers. Best thing I've found is to maintain repo setup scripts but its pretty cumbersome and you have to manually target the tools you want to support.
Is there a way to request this sort of stuff or a place to look at roadmaps without getting into the whole mailing list scene?
Maybe this sort of thing should be the responsibility of github/gitlab and not git itself?
> Its not easy to set up git config settings for a distributed team. I assume for security reasons a repo can't configure its own settings just from a pull but even still I want that functionality.
Git settings can do a lot, including running arbitrary commands. Having this set up automatically is a massive security issue. Put a script in your repo somewhere and instruct people to run the script after cloning.
> Why do I check in the name of the merge tool used for a file type in the .gitattributes but I can't check in what that name points to?
Because the configuration may be different from machine to machine. For example, one machine might have git-lfs installed in /usr/local/bin, another in $HOME/.nix-profile/bin/git-lfs. Similarly, the actual filters may be set up differently from machine to machine, e.g. one person might use `git lfs install` (to install globally) and another `git lfs install --skip-smudge --local` (to install locally to this repo, configured to skip fetching unknown objects on clone or pull).
> I work with less technical artists and they really don't want to think about git configs at all. They just want to save and push. As far as I know there's no solution to preconfigure a repo to pull submodules or set up custom merge drivers. Best thing I've found is to maintain repo setup scripts but its pretty cumbersome and you have to manually target the tools you want to support.
Skimming config right now, I do see a `submodule.recurse` flag which, if set, causes any command except `clone` that has --recurse-submodules to automatically recurse.
The aforementioned setup script could set this config flag and run `git submodule update --init -recursive` to clone the submodules too in case the user didn't pass --recurse-submodules to `git clone`.
You can add a small script to your project that you tell people to run the first time after cloning. Then with that script you can setup everything you want. Such as symlinks to git hooks also stored in the repo (so that they stay up to date), or set up the merge tool that you want.
Our team had started a practice of "devbox setup" scripts in each repo a few years ago. They're invaluable. Instead of following pages of instructions in various state of decay, running just one script puts you into the ready state in a few seconds. Any questions about why something is not working has only one answer: run the setup script.
I love having idempotent makefile tasks that can do this kind of thing.
And as far as "pages of instructions in various states of decay," couldn't agree more that those aren't a good solution. I usually observe those instructions containing lots of terminal commands. I'd rather have those in an executable format, with commenting if explanation is needed. Then it's (usually, hopefully) pretty obvious where something breaks, instead of rotting instructions nobody can say 100% what is or isn't current.
This is the sort of thing that a configuration management system like Ansible does. Consider deploying one to all managed devices.
Git itself is not the right place to have it because of the security issues with it, but if you can run Ansible or something similar then you have root on the system anyway.
Git now includes a GitHub Actions workflow which you can use to run Git’s own integration tests on a variety of platforms and compilers. There’s no extra effort required on your part: if you have a fork of git/git on GitHub, each push will be run through the array of tests necessary to validate your change.But wait: doesn’t Git use a mailing list for development? Yes, it does, but now you can use GitGitGadget on the git/git repository. This means that you can open a pull request, and have GitGitGadget send it to the mailing list on your behalf. So, if you’re more comfortable contributing to Git like that instead of composing emails manually, you can now contribute to Git from start to finish using GitHub.
Nice to see efforts to reduce barriers to contributing.
1. I do `git log` which helpfully pipes to `more` where I can use vim-stsyle search to find the commit I'm interested in.
2. I find the relevant commit.
3. Now I want to `git show` that commit.
Currently I double click on the human unreadable commit, copy it, quit `more` to get back to the command line, type `git show`, then paste the commit. Navigate, click-click, shortcut, 'q', type a command, paste. That's six pieces of business.
That seems very wrong and time-consuming.
How do I go gracefully from browsing git log to git show without retyping/pasting the human unreadable commit? Preferably with fewer than seven steps.
You could use `git log -p` instead of `git log` so that the diff is included.
To navigate efficiently between the commits, you could pre-seed less with a regex that matches commit (and file) lines, so that "n" and "N" jump from one commit (or file) to the next, something like this
Ooh, thanks. I think I can get away with git log -p to fetch the whole enchilada.
There are just so many things in the git CLI that are a single step away from being usable by default. For example, in Gitlab by default you see a tag to let you know if a branch has been merged. I can do the same in cli by exploring my flag options, but that time adds up for every little convenience that happens to be missing. (And as Gitlab shows, it's not impossible to choose a set of default conveniences that cover the bases for an enormous percentage of the users.)
I'll definitely look into that jumping pattern, too. Thanks for the hints!
The one issue I've seen with using `-p` here is that `git log -p` has worse performance when compared to plain `git log` because it needs to calculate diffs, and when searching in less ends up searching the diff contents (even when this is not desired)
If you know the specific string (or regex) you’re searching for in the commit messages, combining `-p` with one of the pickaxe [0] options might be a bit faster.
I personally use magit, which solves this problem across all of git, but it's tied to Emacs.
tig is a git log browser I've heard good things about that seems to handle this use case very nicely.
You may also be able to pervert less into making this easier, e.g. by using lesskey(1) to add a keybinding that runs `git show $(xclip -o)`. I don't know how wise that would be.
I have definitely used Magit in situations where it was the only use of Emacs, working on the version-controlled content itself in content-specific tools such as Xcode or even MS Word.
Yeah, tig is awesome and I use it exactly for this use case.
For what I see, magit is way ahead when it comes to the feature set, but tig has the killer feature of having a completely flat learning curve (and I say this as an Emacs user): 1) type tig 2) use arrows to move between commits and page up/down to move within diffs. That's all!
Just use vim, it even highlights the git log file:
$ git log | vim -
Inside vim search what you want with '/'
When you find the commit you want put the cursor everywhere over the commit ID and run this normal mode command:
<Esc>:!git show <Ctrl+R><Ctrl+W><Enter>
You will be shown the diff in your default text view program (normally it's 'more' but can also be vimdiff), press <Enter> when you finish and you will be sent directly to the place where you left off.
You can also remap this behaviour to any key/alias you want.
find the log entry you're interested in, move the cursor over the sha1 value, type yiw to yank it into vim's " register (by default). Then open a new window by pressing ctrl-w n.
In that window run
:r !git show <ctrl-r ">
where <ctrl-r "> will retrieve the sha1 value you yanked into the " register.
It's fewer steps, doesn't require using the mouse, and allows you to see both the git log output and git show output in different adjacent windows. You can always press u to undo the change in the new window, switch windows to get back to the git log output, find another sha1 and repeat the process.
If you are using Tmux, you can use thmux-fingers[1] or tmux-thumbs[2], both create Vimium like shortchuts for urls and git hashes that once pressed copy the link to clipboard or the tmux buffer. Then you can just `git show` and `Ctrl-shift-V` or `Ctrl-b ]`. There's a lot of resources that can be yanked with tmux-fingers, kubernetes resources, ips and others
First, the simple optimization for Linux systems: double-click on the commit hash, q, git show, middle-click to paste. That's a simpler copy-paste. I do that surprisingly often, when browsing repositories.
But for a repository I do regular development in, vim with the "fugitive" mode works very well. You can just use :Glog, and browse, hitting enter on a commit to show the full commit, or on a tree to show the tree, or on a file within a tree to show the file (at that version).
I also use :Gdiff to give a vimdiff of changes, to stage the changes I want to commit, and then :Gcommit to commit them.
>> First, the simple optimization for Linux systems: double-click on the commit hash, q, git show, middle-click to paste. That's a simpler copy-paste. I do that surprisingly often, when browsing repositories.
Yes, I also double-click on the commit hash and copy it. But I wish there was an incrementing index starting from the top of git log, such that say the 15th commit down, I could just say `git show 15` and see that diff, instead of having to copy and paste the commit ID ( and use my mouse )
> I wish there was an incrementing index starting from the top of git log, such that say the 15th commit down, I could just say `git show 15` and see that diff, instead of having to copy and paste the commit ID ( and use my mouse )
The 15th commit down can be shown with
git show HEAD~14
However, since the log itself does not show you the count this has limited utility since you’d have to either manually count or add some additional processing in order to insert counts into the output of git log.
If you want to navigate without using the mouse, I'd definitely suggest using vim-fugitive, or tig, or any number of git interfaces that let you browse with keyboard shortcuts.
Re: tig; That means I would need to use one command for viewing git logs, and the `git` command for everything else.
I guess if there was one git wrapper that I could use for everything, that would be better. But then I would be probably forget all the traditional git commands, and would be useless if I had to jump on another machine.
I have a series of keybindings[1] for fish that use fzf to select from various git objects. One keybinding selects from commits. So with this I can type `git show <ctrl-g c>` and then pick the commit I want from the fzf interface.
I use FZF for this. It lets me do an incremental search on fit commit messages and show the diff of the selected commit. It’s a slightly customised version of fshow_preview from this example:
Would `git log --grep='some pattern'` help? Or perhaps since you're searching, "git log -p" (or other flags) to have the log show the data you need inline rather then needing to separately run "git show".
Yes, but IntelliJ's "Show History for Selection" takes the cake. It opens up a timemachine-like view that shows just the changes/commits affecting that block and lets you scroll through them.
> [1] Note that since Bloom filters are not persisted automatically (that is, you have to pass --changed-paths explicitly on each subsequent write), it is a good idea to disable configuration that automatically generates commit-graphs, like fetch.writeCommitGraph and gc.writeCommitGraph.
The data is stored in your `commit-graph` file by this command, but those other ways to update the `commit-graph` file don't pay attention to the fact that the data exists in order to persist it.
first, if i've made any changes to the repo (e.g. commits), since the last time i've run it (unless I disable the configuration that automatically generates commit-graphs with fetch.writeCommitGraph and gc.writeCommitGraph) ?
If you don't disable fetch.writeCommitGraph and gc.writeCommitGraph there is a chance that those operations will overwrite your commit-graph and delete the changed-path filter data. (fetch.writeCommitGraph uses the --split option so it might not actually erase the data until you have accumulated enough "new" commits)
You don't need to rewrite the commit-graph file every time you want to run "git log". The "git log" command will parse the newer commits the old-fashioned way until you reach the commits encoded in the commit-graph file. If you do it once now, then you'll still be fast even if a few commits are added on top of your existing history.
If you update the commit-graph with that command once a week, then you'll stay fast even in a very large repository.
> The "git log" commit will parse the newer commits the old-fashioned way until you reach the commits encoded in the commit-graph file. If you do it once now, then you'll still be fast even if a few commits are added on top of your existing history.
Thanks, this is the context I was missing.
Just wanted to avoid a "dirty read" situation.
Thank you for providing the answers here- very helpful!
Though in the context of git, master is not intended to be a reference to master/slave [1], it is ostensibly widely mis-identified as such. The change therefore is being made by many as an attempt to be more inclusive. I pulled this [2] Bitbucket blog entry from the original article if you want to read what they have to say.
"ignorance is causing people to take offense when none was intended and instead of trying to educate people we can instead just make a greater effort to not offend them"
It's sad to see people complain about git for complication because people just jumped on the "It's made for kernel development by Linus, so it should work for me" bandwagon when he wasn't obviously targeting for the masses...
For sake, I was using bazaar back then as it looked to be aiming to be user friendly but I guess everyone jumping to git killed it.
Now every new git users are crying how it's not intuitive while every developer ecosystem is being built around git.
It's the price we pay for blindly following "coolness".
I personally hope this won't catch on because some third party library still expect master to be the default branch. When main is used, I have to monkeypatch some script I use to work aroud it.
edit: I fixed the script to use branch [0] instead of branch master (using GitPython).
At Elementary we've adopted `latest` as it tracks nicely with the bleeding-edge tag for Docker containers which we don't have control over. This way, when we build/deploy containers off of the `latest` branch there's an equivalent tag on our DockerHub repos.
Hmm, not sure about "latest", as almost always, the master/primary/whatever branch is not actually the latest code, but the latest "production ready" code.
I've been debating "mast" as it sort of evokes "trunk" in an amusing seafaring sort of way, and partly for the same reason a lot people like "main" because their muscle memory is "ma<TAB>". For several reasons my muscle memory at this point is "mast<TAB>", so "mast" is even a slight improvement over my muscle memory.
But I'm not sure I'd get that much interest from other people to use "mast", it might just be something in my own projects.
Useful to know: the linked GitLab documentation points out several flaws with "default" as the name for a branch, in particular the cognitive association with financial default (a negative circumstance), which would make internationalization hard and while not as terrible an association and history as "master" still a bad association that now I've thought about it I cannot stop thinking about.
I can appreciate that "canon" is used in religious contexts, but its meaning and origin go back further than that. Wiktionary (hardly the best source, I know) lists three secular meanings before the religious ones begin. The most relevant is this one:
> A group of literary works that are generally accepted as representing a field.
Also, the coinage "fanon" (as in derivative works by a fanbase) comes directly from the treatment of the source material as "canonical". (Frankly, "canonical" is the best argument I can make for "canon".)
> but its meaning and origin go back further than that
master/slave goes back to Mesopotamia, 4 thousands years ago and was used to describe the relationship between men and gods
> Man was believed to have been created to serve the gods, or perhaps wait on them: the god is lord or master (belu) and man is servant or slave (ardu)
I guess being that old is not good enough nowadays
But git doesn't use master/slave (noun). It uses master as an adjective ("master branch"). Think cassettes and vinyl records or "master boot record". It means being the definitive source of truth and has been used in that form for centuries [citation needed, but I don't remember where I read it].
This isn't just an instance of "not old enough", it's an instance of it not even being the same word, so I guess you just can't win this...
It's rather hard to type as it's switching hands a lot; both "master" and "main" are easier to type, and are also shorter (as least "main" would be an improvement in that sense; "primary" would be quite the regression IMO).
It's the ubiquitous "master" that everyone is trying to get rid of. There are details in several of the linked articles. TL/DR: The master/slave analogy is problematic and lots of projects have decided we don't need that terminology around any more, when we can pick less problematic names easily (easier now that there is a config option for it without needing to create a full git init template).
IMHO the only problem is what people wanna see in words.
master/slave has been with us since forever (https://news.ycombinator.com/item?id=23969906) and describes a relationship between two entities where one is the controller and the other is controlled, in many religions (including the most popular one) there is still a master God (or more than one) and believers are slave to God (with the capital G)
But in Git there is simply a "master" branch, there is no master/slave relationship, there is no hierarchy enforced, branches are just copies that diverged from the master copy, master as in master recording or "the source from which all copies will be produced"
I honestly have a hard time understanding what's problematic with it.
Americans have issues. A lot of issues to be honest. Add to the mix their fervor about what they think is right with their utter disregard about what the rest of the world has to say about it, and you will get an interesting recipe for neocolonialism.
Bitkeeper, which early git developers were familiar with, did use master in a master/slave relationship. While git does not enforce such "hierarchy", there remains an association (both in how we use the word outside of the context of git as well as historically in how the word was used by predecessor SCSes).
> master/slave has been with us since forever
"Tradition" or "we've always done it that way" is not a great excuse, especially when part of the problem is systemic papercuts. It's not surprising that systemic issues rely a lot on "tradition" to do their dirty work.
Whether or not you agree with the particular etymology/association being questioned, the very point of questioning it is whether or not this "tradition" is worth the pain of systemic papercuts. We've got a lot of other useful words, we don't have to keep using ones that cause papercuts just because of "tradition" (whether or not you personally suffer from those papercuts).
Paul Graham published an essay recently which describes these kind of people as "aggressively conventionally-minded": http://paulgraham.com/conformism.html
Essentially there are some people who will follow rules and trends without questioning them. Among those there are some who will actively seek to punish those who do not follow the rules.
This master/slave thing is a new rule born out of guilt and virtue signalling. This comes from the fact that some people see themselves as genuinely superior to others and this makes them uncomfortable. They virtue signal in an attempt to fight against this feeling, rather than just accepting what may be true, moving on, and continuing to be a good person. It's a phenomenon that has been observed in many contexts. The most vocal homophobes are often homosexual themselves. The most vocal religious devotees often have the strongest doubts.
This argument comes off as very condescending in a soft bigotry of low expectations-type of way, given there's nothing else within git that even hints to master being related to master-slave terminology.
In the rest of the world is not as problematic, as we associate master with teacher. But we are used to America forcing their culture down our throats. Like they did when tried to force down their hatred for the police on us. So, another one to the list. It would be nice if some day they tried to consider how the rest of the world sees things. For a change.
> In the rest of the world is not as problematic, as we associate master with teacher.
Every word has more than one association. The argument is not that every association for the word is negative, but that one association is extremely negative, and we have the ability to use words that have fewer negative associations, so why shouldn't we use words with fewer negative associations?
That extremely negative association certainly isn't unique to the American past either, and if you think you are immune you are likely ignoring your own past. It's maybe being promoted by Americans because Americans see it as a more recent part of their past, still are wary of scars left behind from it. (Though even that isn't uniquely American; South African Apartheid is another easy example of recent history.)
Ah, yes. The old “if you don’t think like me you are wrong.” We are also used to that condescending attitude. Very American. But, as surprising as may be, there are other cultures in this world. In mine, master is a word associated to teacher. You see the issue as more recent because it is happening right now. The scars are still bleeding. Maybe this is why you all overreact so much to simple words. To overcompensate.
I'm not claiming anyone is wrong, I did not say that anywhere, and I'm not forcing anything. I'm simply suggesting there are alternatives. It's not an American thing, and it isn't overcompensating for anything. I don't even feel that strongly about this. Clearly a lot of people do. It tells me a lot more about this thread in the way it was downvoted where I was simply trying to explain the issue, it's history, and the options available and a lot of people apparently brought emotions to the discussion that I do not understand where they came from.
Do whatever you like. I'm not telling you what to do. I'm not telling anyone what to do. I was merely explaining the controversy. I give up. I do not understand what all this hate is about. I'm just the messenger, but I guess I can take all the shots.
There's a lot of back and forth on the discussion, and summaries are included in the tops of almost all of the linked articles. In general, the name "master" branch was commonly used in proprietary git predecessor BitKeeper which almost all of the early git developers were familiar with [1] and it did use master in a master/slave meaning. (It had a concept of "slave repositories".) While git has never had a concept of "slave branches" and the meaning may very well have meant to evoke one of the other etymologies, the word was "in the air" because of BitKeeper, which did intend it in a master/slave relationship, so git is guilty by association if not guilty by intent. Which is fine, no one is suggesting git is guilty by intent, they are simply suggesting it is time now to do what early git developers failed to do and question the association (both associations, using the word simply because it was a word commonly thrown around in tech up to that point, and in the association of master with chattel slavery).
[1] Bitkeeper was the SCS that the Linux kernel had been using up to that point, and whose dropping of free licenses to open source projects like the Linux kernel was the immediate cause of the creation of both git and Mercurial.
I don't follow each Git release, but I also didn't notice a great productivity enhancement for a long time. Sure it is a sign of a mature project, but I'd like to know:
What's the somewhat recent Git feature that you really improved your productivity?