I like the new diff improvements
I should definitely learn more about extending git!
> For convenience, the recommended installation is via NPM. If you'd prefer, you may choose to do a manual installation instead.
(highlighting by me)
It is written in Perl.
Color me perplexed.
It also features word-level change highlights and other common flares.
Diffs in Git are purely a presentation format for human consumption.
git format-patch says hi. Obviously the diff engine changes won't apply to already generated text diffs.
cat foo.diff | diff-so-fancy
Oh yes, it seems to work. It doesn't do colors when I try it, but that's probably a misconfiguration on my side. It's how this is intended to be used.
git config −−global commit.verbose true
In the Git-hooks project we have been using the init.templatedir which this replaces (as it is better), but for those that can't upgrade to 2.9 you can use init.templatedir and some variation of what Git-Hooks does to obtain similar results.
This makes it easier to not have broken commits (e.g. ones that don't build) in master, which in turn makes git bisect more useful.
The new diff script (https://github.com/git/git/blob/master/contrib/diff-highligh...) is juicy indeed.
It is written in Perl. The Perl interpreter is available on most UNIX systems, so that's handy. I wonder if there is any Lisp-like language that is as common, that you can write scripts and expect them to run on most systems. Would be nice since Lisp languages have very few concepts to learn...
It's just a little complicated because of the way it interacts with existing internal diff features (in particular the whitespace-error highlighting).
The huge upside of perl is not necessarily that it's available, but that it's available by default.
So, if i originally have
then adding x a n on top of it, it will become
Edit: My bad, didn't see this https://news.ycombinator.com/item?id=11915351. It has been explained there.
I have a big, monolithic repository which I'm looking to break up in a migration to Git.
If I run;
git submodule split -P <path_to_sm> -b <name_of_branch> --jobs=4
That said, I won't be using git submodules again on another project, it was a bit cumbersome for my taste.
Just curious, were there any changes to sparse-checkout? It had abysmal performance in pre-2.x if you threw more elaborate paths at it, or more paths in general.
The benefits oftentimes overshadow the issues with them, but there are drawbacks to using them.
My own positive experience with submodules involves dependencies that only occasionally change; I can always point to a specific tag that should be used.
One should avoid to extract a component from the repo as a submodule too early, i.e when the interface of the component is not mostly stabilized.
If each commit in your "main" module is paired with a commit in your submodules, then you might be missing the point of module separation.
Git is not a package manager, don't make the mistake of trying to use it as one.