Highlights from Git 2.28

https://github.blog/2020-07-27-highlights-from-git-2-28/

by programeris • 6 years ago

201 143 6 years ago

pojntfx• 6 years ago

I wonder about which primary branch naming convention they’ll arrive at. “primary” is my personal favorite ;)

Twisol2• 6 years ago

I saw somebody on Twitter call theirs "canon", which I've really taken a liking to. It fits nicely in regular speech too :D

jamesponddotco• 6 years ago

I use, and prefer "trunk" since I rarely use branches, but "canon" might change my mind.

solatic• 6 years ago

Canon is excellent, but I fear it wouldn't catch on due to its religious origins / connotations.

jrockway• 6 years ago

Is the most recent commit on this main branch called "HEADCANON"?

stephenhandley• 6 years ago

I think quaid would be good, you know because of Randy Quaid and also because of Total Recall

apetresc• 6 years ago

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)

eclipseo76• 6 years ago

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).

oweiler• 6 years ago

I've seen `main` being used quite often.

TheChaplain• 6 years ago

I renamed all mine to 'senpai'.

augusto-moura3• 6 years ago

alias notice_me='git pull'

Seirdy• 6 years ago

"Senpai" means senior/superior (e.g., "Senpai Dev"). A better honorific would be "dono".

x87678r• 6 years ago

I miss trunk.

petepete• 6 years ago

As someone who learnt version control with Subversion, I'm hoping trunk will come back into fashion.

dpipemazo• 6 years ago

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

GordonS• 6 years ago

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.

arp242• 6 years ago

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).

Normal_gaussian• 6 years ago

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.

globular-toast3• 6 years ago

Probably the ubiquitous "master".

WorldMaker10• 6 years ago

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).

IshKebab• 6 years ago

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".

daigoba66• 6 years ago

I’ve migrated several repositories from mercurial, and didn’t bother to rename “default”. It works perfectly fine and no one is ever confused.

jancsika3• 6 years ago

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.

nyanpasu64• 6 years ago

I use a text-mode UI like tig or gitui.

ramses0• 6 years ago

Seconding `tig`

duckerude• 6 years ago

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.

owl57• 6 years ago

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.

Arkanosis• 6 years ago

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!

augusto-moura3• 6 years ago

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

jancsika3• 6 years ago

But that isn't a standard part of tmux, right?

ratorx• 6 years ago

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

Myrmornis2• 6 years ago

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

  LESS="-R --pattern ^(commit|diff) " git log -p

Delta[1] makes this convenient: delta --navigate.

[1] https://github.com/dandavison/delta

(Disclosure: I am the author of delta)

jancsika3• 6 years ago

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!

noir_lord• 6 years ago

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.

adz5a• 6 years ago

Hello, thanks for pointing out your tool. I use diff-so-fancy as a pager but I will most definitely try your tool.

codys• 6 years ago

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)

wyldfire• 6 years ago

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.

kemitche• 6 years ago

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".

magikarpsalesmn• 6 years ago

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:

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!

lilyball2• 6 years ago

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

u801e• 6 years ago

If you use vim, you can do this within vim:

  :r !git log

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.

JoshTriplett2• 6 years ago

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.

Naac2• 6 years ago

> 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 )

_ZeD_2• 6 years ago

Have you tried graphical git clients? Try the Eclipse git plugin. For real! It's the most intuitive tool to deal with git histories

jmiserez2• 6 years ago

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.

platz3• 6 years ago

[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:

    git commit-graph write --reachable --changed-paths

is not a persistent setting, or it is a persistent setting?

stolee2• 6 years ago

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...

platz3• 6 years ago

so, then if I want to run

    git log -- /path/to/file

I should always execute

     git commit-graph write --reachable --changed-paths

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) ?

yboris• 6 years ago

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`

chrisshroba• 6 years ago

Just curious - what reasons do people have for not using master?

DangitBobby• 6 years ago

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...

crististm2• 6 years ago

Good for letting us know! You deserve to feel better about yourself already!

jayd166• 6 years ago

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?

JelteF• 6 years ago

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.

jimbobimbo• 6 years ago

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.

jayd166• 6 years ago

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.

divbzero• 6 years ago

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

damnyou2• 6 years ago

Use a configuration management system or simply have a custom clone script that users can curl | sh.

lilyball2• 6 years ago

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`.

jayd166• 6 years ago

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.

damnyou2• 6 years ago

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.

dcgudeman• 6 years ago

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.

deadbunny• 6 years ago

I can almost hear all the fragile tooling built around `master` branches in git screaming.

young_unixer• 6 years ago

Most people will keep using the default anyway.

neves• 6 years ago

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?

UkiahSmith• 6 years ago

git restore

mpawelski• 6 years ago

+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)

jacobparker• 6 years ago

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.

mbakke• 6 years ago

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.

acdha• 6 years ago

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.

merb2• 6 years ago

git switch/git switch -c so much better than git checkout and the confusing switches.

imron• 6 years ago

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.

setpatchaddress• 6 years ago

git worktree.

Godsend if you regularly need to work on multiple branches simultaneously.

jayd166• 6 years ago

What does worktree provide that a fresh local clone doesn't?

monocularvision• 6 years ago

“Let me share the Good News of git worktrees” is a thing I say often in our work Slack.

mklein9942• 6 years ago

  git range-diff

Very useful to get an overview of what changed after a rebase.

https://git-scm.com/docs/git-range-diff

nitemice2• 6 years ago

Thank you for mentioning this. I wrote my own bash script to do something similar ages ago, but I'm betting this will be much less janky.

lzutao• 6 years ago

Really nice. I hope GitHub use this option soon.

Or maybe not: I guess it's kinda slow and heavy on computation.

mklein9942• 6 years ago

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...

square_usual• 6 years ago

If you use git diffs frequently, I recommend setting up delta: https://github.com/dandavison/delta

SomaticPirate• 6 years ago

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...

kakawait• 6 years ago

Sparkle/partial checkout for big repo or legacy or people doing shit with git

m0zg2• 6 years ago

Wish they'd bake in some sort of a solution for managing huge files. A lot of people have this problem.

moonchild• 6 years ago

LFS?

m0zg2• 6 years ago

Not baked in. Also, unreliable and slow.

dependenttypes• 6 years ago

They still did not add support for a secure hash it seems.

mekster• 6 years ago

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".

Highlights from Git 2.28

Related Stories