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.
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.
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
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.
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.
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".
> [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.
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".
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.
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).
[+] [-] neves|5 years ago|reply
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?
[+] [-] jacobparker|5 years ago|reply
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.
[+] [-] mklein994|5 years ago|reply
https://git-scm.com/docs/git-range-diff
[+] [-] mbakke|5 years ago|reply
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.
[+] [-] mklein994|5 years ago|reply
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...
[+] [-] setpatchaddress|5 years ago|reply
Godsend if you regularly need to work on multiple branches simultaneously.
[+] [-] merb|5 years ago|reply
[+] [-] SomaticPirate|5 years ago|reply
It speeds up git status on large codebases
https://github.com/git/git/blob/master/templates/hooks--fsmo...
[+] [-] kakawait|5 years ago|reply
[+] [-] UkiahSmith|5 years ago|reply
[+] [-] jayd16|5 years ago|reply
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?
[+] [-] lilyball|5 years ago|reply
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`.
[+] [-] JelteF|5 years ago|reply
[+] [-] divbzero|5 years ago|reply
[1]: https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks
[+] [-] damnyou|5 years ago|reply
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|5 years ago|reply
Nice to see efforts to reduce barriers to contributing.
[+] [-] jancsika|5 years ago|reply
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.
[+] [-] Myrmornis|5 years ago|reply
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
Delta[1] makes this convenient: delta --navigate.[1] https://github.com/dandavison/delta
(Disclosure: I am the author of delta)
[+] [-] duckerude|5 years ago|reply
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.
[+] [-] magikarpsalesmn|5 years ago|reply
$ 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!
[+] [-] u801e|5 years ago|reply
In that window run
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.
[+] [-] augusto-moura|5 years ago|reply
[1] https://github.com/Morantron/tmux-fingers
[2] https://github.com/fcsonline/tmux-thumbs
[+] [-] nyanpasu64|5 years ago|reply
[+] [-] JoshTriplett|5 years ago|reply
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.
[+] [-] lilyball|5 years ago|reply
[1] https://github.com/lilyball/fzf-git.fish
[+] [-] ratorx|5 years ago|reply
https://github.com/junegunn/fzf/wiki/Examples#git
[+] [-] kemitche|5 years ago|reply
[+] [-] _ZeD_|5 years ago|reply
[+] [-] wyldfire|5 years ago|reply
[+] [-] deadbunny|5 years ago|reply
[+] [-] young_unixer|5 years ago|reply
[+] [-] platz|5 years ago|reply
Not sure I understand this note
Does this mean that:
is not a persistent setting, or it is a persistent setting?[+] [-] stolee|5 years ago|reply
There is work in progress to fix that issue, hopefully in the next version: https://lore.kernel.org/git/f1e3a8516ebd58b283166a5374843f5c...
[+] [-] yboris|5 years ago|reply
At work we've renamed all `master` branches to `main`
[+] [-] chrisshroba|5 years ago|reply
[+] [-] crististm|5 years ago|reply
[+] [-] nisuni|5 years ago|reply
[deleted]
[+] [-] mekster|5 years ago|reply
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".
[+] [-] dependenttypes|5 years ago|reply
[+] [-] pojntfx|5 years ago|reply
[+] [-] apetresc|5 years ago|reply
(Source: https://github.com/github/renaming)
[+] [-] dpipemazo|5 years ago|reply
https://github.com/elementary-robotics/atom
[+] [-] Twisol|5 years ago|reply
[+] [-] petepete|5 years ago|reply
[+] [-] arp242|5 years ago|reply
[+] [-] TheChaplain|5 years ago|reply
[+] [-] m0zg|5 years ago|reply