Highlights from Git 2.28(github.blog)
github.blog
Highlights from Git 2.28
https://github.blog/2020-07-27-highlights-from-git-2-28/
146 comments
git restore
+1 this.
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)
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)
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.
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.
As someone doing lots of merges in a big and active project, git rerere has saved me hours whenever I need to redo a complicated merge.
It's not at all new according to a quick grep of RelNotes, but I only recently discovered it, so it is new to me.
It's not at all new according to a quick grep of RelNotes, but I only recently discovered it, so it is new to me.
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.
git switch/git switch -c so much better than git checkout and the confusing switches.
Not for me.
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.
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.
well git checkout basically is confusing because it does two things at once.
git restore and git switch basically tries to seperate the functionality.
i.e. from: "git-checkout - Switch branches or restore working tree files"
to
- "git-switch - Switch branches"
- "git-restore - Restore working tree files"
tbf I found it really stupid from the beginning that it tries two things at once.
git restore and git switch basically tries to seperate the functionality.
i.e. from: "git-checkout - Switch branches or restore working tree files"
to
- "git-switch - Switch branches"
- "git-restore - Restore working tree files"
tbf I found it really stupid from the beginning that it tries two things at once.
git worktree.
Godsend if you regularly need to work on multiple branches simultaneously.
Godsend if you regularly need to work on multiple branches simultaneously.
What does worktree provide that a fresh local clone doesn't?
Reduced disk space usage for large repositories. And a convenient way to manage all your clones
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.
Yeah, it only stores the objects in the .git directory once.
If it's a multi-gigabyte repo that you are cloning over a slow VPN, it speeds things up quite a bit.
Maybe too obvious, but if you’re not pushing everything to the remote, local-only content is available in both worktrees.
“Let me share the Good News of git worktrees” is a thing I say often in our work Slack.
git range-diff
https://git-scm.com/docs/git-range-diff
git diff --color-moved
This makes git diff highlight reindented or moved lines differently.
I use it to get diffs similar to when you pass -w, but with a bit more context.
It takes a bit of experimenting to keep it from looking like a fruit salad, but sometimes you get interesting results.
https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...
This makes git diff highlight reindented or moved lines differently.
I use it to get diffs similar to when you pass -w, but with a bit more context.
It takes a bit of experimenting to keep it from looking like a fruit salad, but sometimes you get interesting results.
https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...
If you use git diffs frequently, I recommend setting up delta: https://github.com/dandavison/delta
And I am working on implementing color-moved support https://github.com/dandavison/delta/issues/72
Setting up watchman as a Git hook for fsmonitor.
It speeds up git status on large codebases
https://github.com/git/git/blob/master/templates/hooks--fsmo...
It speeds up git status on large codebases
https://github.com/git/git/blob/master/templates/hooks--fsmo...
Sparkle/partial checkout for big repo or legacy or people doing shit with git
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.
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`.
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`.
>Because the configuration may be different from machine to machine
This is the crux of the issue. I want something to ensure turn-key configuration in a secure and cross platform way.
Maybe github/gitlab could generate something like an installer script instead of just a clone url.
This is the crux of the issue. I want something to ensure turn-key configuration in a secure and cross platform way.
Maybe github/gitlab could generate something like an installer script instead of just a clone url.
Do you have a cross-platform package manager?
One such package manager can be npm (if you use Node anyway), it can install and run scripts.
But having to run a setup script once could be massively simpler, though less flexible.
One such package manager can be npm (if you use Node anyway), it can install and run scripts.
But having to run a setup script once could be massively simpler, though less flexible.
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.
Highly recommend this.
Highly recommend this.
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.
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.
Symlinked hook is nice but its not a clean cross platform solution. We're a Unity shop so we support Windows, Mac and Linux devs (or like to try).
I just can't help but feel like if this is the common pattern, then it should be built into one of these tools in a more consistent way.
I just can't help but feel like if this is the common pattern, then it should be built into one of these tools in a more consistent way.
Along the same vein, I’d love to be able to configure client-side hooks [1] automatically on clone.
[1]: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
[1]: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
Use a configuration management system or simply have a custom clone script that users can curl | sh.
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 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.
Nice to see efforts to reduce barriers to contributing.
Someone please give me the missing link here:
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.
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
[1] https://github.com/dandavison/delta
(Disclosure: I am the author of delta)
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
LESS="-R --pattern ^(commit|diff) " git log -p
[1] https://github.com/dandavison/delta
(Disclosure: I am the author of delta)
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!
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.
0: http://www.philandstuff.com/2014/02/09/git-pickaxe.html
0: http://www.philandstuff.com/2014/02/09/git-pickaxe.html
Wow, this looks incredible.
I currently use diff-so-fancy which is nice enough but as someone who looks at a lot of diffs a day this seems like a big upgrade.
I currently use diff-so-fancy which is nice enough but as someone who looks at a lot of diffs a day this seems like a big upgrade.
Hello, thanks for pointing out your tool. I use diff-so-fancy as a pager but I will most definitely try your tool.
By using a smarter tool.
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 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!
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.
Hope this helped!
$ 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.
Hope this helped!
If you use vim, you can do this within vim:
In that window run
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.
:r !git log
In that window run
:r !git show <ctrl-r ">
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
[1] https://github.com/Morantron/tmux-fingers
[2] https://github.com/fcsonline/tmux-thumbs
[1] https://github.com/Morantron/tmux-fingers
[2] https://github.com/fcsonline/tmux-thumbs
But that isn't a standard part of tmux, right?
It's not, but is really easy to setup with tmux-plugins
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.
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 )
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
The 15th commit down can be shown with
git show HEAD~14
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 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.
[1] https://github.com/lilyball/fzf-git.fish
[1] https://github.com/lilyball/fzf-git.fish
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:
https://github.com/junegunn/fzf/wiki/Examples#git
https://github.com/junegunn/fzf/wiki/Examples#git
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".
Have you tried graphical git clients?
Try the Eclipse git plugin.
For real!
It's the most intuitive tool to deal with git histories
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.
You can also do `git log -p`. It includes the diff inline. Takes more time to search a long history but omits the extra manual steps.
I can almost hear all the fragile tooling built around `master` branches in git screaming.
Most people will keep using the default anyway.
> [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.
Not sure I understand this note
Does this mean that:
Not sure I understand this note
Does this mean that:
git commit-graph write --reachable --changed-paths
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.
There is work in progress to fix that issue, hopefully in the next version: https://lore.kernel.org/git/f1e3a8516ebd58b283166a5374843f5c...
There is work in progress to fix that issue, hopefully in the next version: https://lore.kernel.org/git/f1e3a8516ebd58b283166a5374843f5c...
so, then if I want to run
git log -- /path/to/file
git commit-graph write --reachable --changed-paths
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.
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!
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!
I like that you can change `git init` to have a different default branch name.
At work we've renamed all `master` branches to `main`
At work we've renamed all `master` branches to `main`
Just curious - what reasons do people have for not using master?
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.
1. https://twitter.com/xpasky/status/1271477451756056577?s=20
2. https://bitbucket.org/blog/moving-away-from-master-as-the-de...
1. https://twitter.com/xpasky/status/1271477451756056577?s=20
2. https://bitbucket.org/blog/moving-away-from-master-as-the-de...
I feel like on the one hand my opinion is "this is stupid and doesn't matter", which makes me think the change was not needed.
But also my opinion is "this is stupid and doesn't matter", which makes me not really care that they did I guess.
But also my opinion is "this is stupid and doesn't matter", which makes me not really care that they did I guess.
This change isn't done because master is super offensive or racist in the context of git. It's done to show some kind of support to the movement.
Might not much very much, but I think showing you care is something.
If it breaks a bit of shitty tooling that relies on hardcoded values, then I think we can live through that.
Might not much very much, but I think showing you care is something.
If it breaks a bit of shitty tooling that relies on hardcoded values, then I think we can live through that.
I think that propaganda got the better of you. But I can live with that if you can.
"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"
Good for letting us know! You deserve to feel better about yourself already!
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".
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".
They still did not add support for a secure hash it seems.
I wonder about which primary branch naming convention they’ll arrive at. “primary” is my personal favorite ;)
Github has said the most popular one across all their repos is `main`, and that's what they'll be going with themselves.
(Source: https://github.com/github/renaming)
(Source: https://github.com/github/renaming)
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).
edit: I fixed the script to use branch [0] instead of branch master (using GitPython).
Maybe you can fork them and submit a patch with the changes fixing it. :)
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.
https://github.com/elementary-robotics/atom
https://github.com/elementary-robotics/atom
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 saw somebody on Twitter call theirs "canon", which I've really taken a liking to. It fits nicely in regular speech too :D
Is the most recent commit on this main branch called "HEADCANON"?
I use, and prefer "trunk" since I rarely use branches, but "canon" might change my mind.
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.
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.
I've also been debating just calling it "default" since we always refer to it as the default branch anyway.
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 think quaid would be good, you know because of Randy Quaid and also because of Total Recall
Canon is excellent, but I fear it wouldn't catch on due to its religious origins / connotations.
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".)
> 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
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...
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...
Yep
I made the same point here
https://news.ycombinator.com/item?id=23970140
I made the same point here
https://news.ycombinator.com/item?id=23970140
what are the religious origins/connotations? That various religions also have a canon and apocrypha?
As someone who learnt version control with Subversion, I'm hoping trunk will come back into fashion.
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).
That is why the single handed "fred" branch shall be the beacon of all truth.
Until it is accused of being sexist, or too western.
Until it is accused of being sexist, or too western.
Easily solved, keep it to the QWERTY home row and make it the "asdf" branch. Could even backronym it to something like All Saved Data Files, maybe.
As a lisp fan, I second this proposal.
https://common-lisp.net/project/asdf/
https://common-lisp.net/project/asdf/
How about just "fed"?
I renamed all mine to 'senpai'.
alias notice_me='git pull'
Wouldn't that be a better alias for `gh pr create`?
"Senpai" means senior/superior (e.g., "Senpai Dev"). A better honorific would be "dono".
I think most important thing is not which branch name we chose, it's that we all chose completely different ones. I'm going for "principal".
Probably the ubiquitous "master".
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.
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.
Not all Americans, just a very passionate, vocal subset of Americans
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).
> 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).
> bitkeeper
This was refuted by the person who named it- https://mobile.twitter.com/xpasky/status/1272280760280637441
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.
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.
> especially when part of the problem is systemic papercuts
I'm sorry for slavery in US, but slavery in US is hardly the only example of slavery in history.
master/slave describes more than just a hundred years of slavery in United States
It also describes thousands of years of religious beliefs, for example.
> the very point of questioning it is whether or not this "tradition" is worth the pain of systemic papercuts
Not to sound harsh, but 5 billion people are ok with it.
It's a linguistic problem for a small minority of the population that speaks English as a native language and super charge words meaning.
Take for example the word servomotor.
A servomotor is
> French servo-moteur, from Latin servus slave, servant + French -o- + moteur motor, from Latin motor one that moves
In Italian it is "servo motore", servo is the exact translation of slave.
Why is servomotor ok, why is "I'm a slave to Jesus" or "God is my master" ok, but master branch is not?
I'm simply curious of why some people can't let things go...
I'm sorry for slavery in US, but slavery in US is hardly the only example of slavery in history.
master/slave describes more than just a hundred years of slavery in United States
It also describes thousands of years of religious beliefs, for example.
> the very point of questioning it is whether or not this "tradition" is worth the pain of systemic papercuts
Not to sound harsh, but 5 billion people are ok with it.
It's a linguistic problem for a small minority of the population that speaks English as a native language and super charge words meaning.
Take for example the word servomotor.
A servomotor is
> French servo-moteur, from Latin servus slave, servant + French -o- + moteur motor, from Latin motor one that moves
In Italian it is "servo motore", servo is the exact translation of slave.
Why is servomotor ok, why is "I'm a slave to Jesus" or "God is my master" ok, but master branch is not?
I'm simply curious of why some people can't let things go...
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.
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.
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.)
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.
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.
What? Apartheid wasn't slavery. And since when do South Africans want to change the language to bury the past?
That’s not the type of master that’s it’s referring to. But I’m not sure etymology really matters I guess.
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.
[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 miss trunk.
I’ve migrated several repositories from mercurial, and didn’t bother to rename “default”. It works perfectly fine and no one is ever confused.
[deleted]
I've seen `main` being used quite often.
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?