
Highlights from Git 2.28 - programeris
https://github.blog/2020-07-27-highlights-from-git-2-28/
======
neves
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?

~~~
mklein994

      git range-diff
    

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

[https://git-scm.com/docs/git-range-diff](https://git-scm.com/docs/git-range-
diff)

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

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

~~~
voltagex_
How do you make sure your makefile tasks are idempotent?

~~~
isaachier
A simple way is to use output files to indicate if a command has been run.

Example:

git-setup.out: touch $@

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

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

~~~
Myrmornis
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](https://github.com/dandavison/delta)

(Disclosure: I am the author of delta)

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

~~~
paxswill
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](http://www.philandstuff.com/2014/02/09/git-pickaxe.html)

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

~~~
young_unixer
Most people will keep using the default anyway.

------
platz
> [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
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...](https://lore.kernel.org/git/f1e3a8516ebd58b283166a5374843f5cb3332d08.1593610050.git.gitgitgadget@gmail.com/)

~~~
platz
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
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
> 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!

------
yboris
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
Just curious - what reasons do people have for not using master?

~~~
DangitBobby
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](https://twitter.com/xpasky/status/1271477451756056577?s=20)

2\. [https://bitbucket.org/blog/moving-away-from-master-as-the-
de...](https://bitbucket.org/blog/moving-away-from-master-as-the-default-name-
for-branches-in-git)

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

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

~~~
crististm
I think that propaganda got the better of you. But I can live with that if you
can.

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

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

~~~
moonchild
LFS?

~~~
m0zg
Not baked in. Also, unreliable and slow.

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

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

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

~~~
Twisol
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
> 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

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

~~~
romanoderoma
Yep

I made the same point here

[https://news.ycombinator.com/item?id=23970140](https://news.ycombinator.com/item?id=23970140)

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

