[HN Gopher] Highlights from Git 2.28
___________________________________________________________________
Highlights from Git 2.28
Author : programeris
Score : 104 points
Date : 2020-07-27 16:59 UTC (6 hours ago)
(HTM) web link (github.blog)
(TXT) w3m dump (github.blog)
| yboris wrote:
| 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`
| nisuni wrote:
| Enslaved people will be so happy to hear these news!
| chrisshroba wrote:
| Just curious - what reasons do people have for not using
| master?
| deadbunny wrote:
| I can almost hear all the fragile tooling built around `master`
| branches in git screaming.
| jayd16 wrote:
| 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?
| divbzero wrote:
| 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
| JelteF wrote:
| 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 wrote:
| 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.
| sixstringtheory wrote:
| 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.
| lilyball wrote:
| > _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`.
| jayd16 wrote:
| >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.
| damnyou wrote:
| 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.
| jancsika wrote:
| 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.
| augusto-moura wrote:
| 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
| jancsika wrote:
| But that isn't a standard part of tmux, right?
| nyanpasu64 wrote:
| I use a text-mode UI like tig or gitui.
| ramses0 wrote:
| Seconding `tig`
| magikarpsalesmn wrote:
| 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!
| duckerude wrote:
| 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 wrote:
| 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.
| ratorx wrote:
| 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
| Myrmornis wrote:
| 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)
| jancsika wrote:
| 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 wrote:
| 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.
| codys wrote:
| 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)
| adz5a wrote:
| Hello, thanks for pointing out your tool. I use diff-so-fancy
| as a pager but I will most definitely try your tool.
| wyldfire wrote:
| 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.
| lilyball wrote:
| 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
| kemitche wrote:
| 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".
| u801e wrote:
| 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.
| platz wrote:
| > [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?
| stolee wrote:
| 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...
| platz wrote:
| 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) ?
| stolee wrote:
| 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.
| platz wrote:
| > 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!
| pojntfx wrote:
| I wonder about which primary branch naming convention they'll
| arrive at. "primary" is my personal favorite ;)
| oweiler wrote:
| I've seen `main` being used quite often.
| IshKebab wrote:
| 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".
| dpipemazo wrote:
| 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
| TheChaplain wrote:
| I renamed all mine to 'senpai'.
| augusto-moura wrote:
| alias notice_me='git pull'
| WorldMaker wrote:
| Wouldn't that be a better alias for `gh pr create`?
| Seirdy wrote:
| "Senpai" means senior/superior (e.g., "Senpai Dev"). A better
| honorific would be "dono".
| Twisol wrote:
| I saw somebody on Twitter call theirs "canon", which I've
| really taken a liking to. It fits nicely in regular speech too
| :D
| jrockway wrote:
| Is the most recent commit on this main branch called
| "HEADCANON"?
| solatic wrote:
| Canon is excellent, but I fear it wouldn't catch on due to
| its religious origins / connotations.
| palsir wrote:
| what are the religious origins/connotations? That various
| religions also have a canon and apocrypha?
| Twisol wrote:
| 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".)
| romanoderoma wrote:
| > 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
| stephenhandley wrote:
| I think quaid would be good, you know because of Randy Quaid
| and also because of Total Recall
| jamesponddotco wrote:
| I use, and prefer "trunk" since I rarely use branches, but
| "canon" might change my mind.
| WorldMaker wrote:
| 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.
| WorldMaker wrote:
| I've also been debating just calling it "default" since
| we always refer to it as the default branch anyway.
| WorldMaker wrote:
| 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.
| x87678r wrote:
| I miss trunk.
| globular-toast wrote:
| Probably the ubiquitous "master".
| WorldMaker wrote:
| 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).
| bengale wrote:
| That's not the type of master that's it's referring to. But
| I'm not sure etymology really matters I guess.
| WorldMaker wrote:
| 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.
| romanoderoma wrote:
| 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.
| WorldMaker wrote:
| 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).
| sildur wrote:
| 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.
| sildur wrote:
| 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.
| WorldMaker wrote:
| > 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.)
| petepete wrote:
| As someone who learnt version control with Subversion, I'm
| hoping trunk will come back into fashion.
| apetresc wrote:
| 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 wrote:
| 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).
| joshmanders wrote:
| Maybe you can fork them and submit a patch with the changes
| fixing it. :)
| daigoba66 wrote:
| I've migrated several repositories from mercurial, and didn't
| bother to rename "default". It works perfectly fine and no one
| is ever confused.
| arp242 wrote:
| 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 wrote:
| 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.
| marvy wrote:
| How about just "fed"?
| WorldMaker wrote:
| 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.
| dcgudeman wrote:
| _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.
| neves wrote:
| 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 wrote:
| git restore
| jacobparker wrote:
| 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.
___________________________________________________________________
(page generated 2020-07-27 23:00 UTC)