- Регистрация
- 09.02.2010
- Сообщения
- 270
- Реакции
- 41
- Баллы
- 28
- Native language | Родной язык
- English
The open source Git project just
We last caught up with you on the latest in Git
That’s just a sample of changes from the latest release. For more, check out the release notes for
You do not have permission to view link please Вход or Регистрация
with features and bug fixes from over 88 contributors, 30 of them new.We last caught up with you on the latest in Git
You do not have permission to view link please Вход or Регистрация
. To celebrate this most recent release, here’s GitHub’s look at some of the most interesting features and changes introduced since last time.- Longtime readers will recall our coverage of
git jump
from way back in ourYou do not have permission to view link please Вход or Регистрацияpost. If you’re new around here, don’t worry: here’s a brief refresher.
[URL='https://github.com/git/git/tree/v2.40.0/contrib/git-jump']git jump[/URL]
is an optional tool that ships with Git in its[URL='https://github.com/git/git/tree/v2.40.0/contrib']contrib directory[/URL]
.git jump
wraps other Git commands, likegit grep
and feeds their results into Vim’sYou do not have permission to view link please Вход or Регистрацияlist. This makes it possible to write something likegit jump grep foo
and have Vim be able to quickly navigate between all matches of “foo” in your project.
git jump
also works withdiff
andmerge
. When invoked indiff
mode, the quickfix list is populated with the beginning of each changed hunk in your repository, allowing you to quickly scan your changes in your editor before committing them.git jump merge
, on the other hand, opens Vim to the list of merge conflicts.
In Git 2.40,git jump
now supports Emacs in addition to Vim, allowing you to usegit jump
to populate a list of locations to your Emacs client. If you’re an Emacs user, you can try outgit jump
by running:
M-x grepgit jump --stdout grep foo
[You do not have permission to view link please Вход or Регистрация]
If you’ve ever scripted around a Git repository, you may be familiar with Git’scat-file
tool, which can be used to print out the contents of arbitrary objects.
Back when v2.38.0You do not have permission to view link please Вход or Регистрация, we talked about howcat-file
gained support to apply Git’sYou do not have permission to view link please Вход or Регистрацияrules when printing out the contents of a commit. To summarize, Git allows rewriting name and email pairs according to a repository’s mailmap. In v2.38.0,git cat-file
learned how to apply those transformations before printing out object contents with the new--use-mailmap
option.
But what if you don’t care about the contents of a particular object, and instead want to know the size? For that, you might turn to something like--batch-check=%(objectsize)
, or-s
if you’re just checking a single object.
But you’d be mistaken! In previous versions of Git, both the--batch-check
and-s
options togit cat-file
ignored the presence of--use-mailmap
, leading to potentially incorrect results when the name/email pairs on either side of a mailmap rewrite were different lengths.
In Git 2.40, this has been corrected, andgit cat-file -s
and--batch-check
with will faithfully report the object size as if it had been written using the replacement identities when invoked with--use-mailmap
.
[You do not have permission to view link please Вход or Регистрация]
While we’re talking about scripting, here’s a lesser-known Git command that you might not have used:[URL='https://git-scm.com/docs/git-check-attr/2.40.0']git check-attr[/URL]
.check-attr
is used to determine which[URL='https://git-scm.com/docs/gitattributes/2.40.0']gitattributes[/URL]
are set for a given path.
These attributes are defined and set by one or more.gitattributes
file(s) in your repository. For simple examples, it’s easy enough to read them off from a.gitattributes
file, like this:
Код:$ head -n 2 .gitattributes * whitespace=!indent,trail,space *.[ch] whitespace=indent,trail,space diff=cpp
Here, it’s relatively easy to see that any file ending in*.c
or*.h
will have the attributes set above. But what happens when there are more complex rules at play, or your project is using multiple.gitattributes
files? For those tasks, we can usecheck-attr
:
Код:$ git check-attr -a git.c git.c: diff: cpp git.c: whitespace: indent,trail,space
In the past, one crucial limitation ofcheck-attr
is that it required anYou do not have permission to view link please Вход or Регистрация, meaning that if you wanted to usecheck-attr
in aYou do not have permission to view link please Вход or Регистрация, you had to resort to temporarily reading in the index, like so:
Код:TEMP_INDEX="$(mktemp ...)" git read-tree --index-output="$TEMP_INDEX" HEAD GIT_INDEX_FILE="$TEMP_INDEX" git check-attr ...
This kind of workaround is no longer required in Git 2.40 and newer. In Git 2.40,check-attr
supports a new--source=
to scan for.gitattributes
in, meaning that the following will work as an alternative to the above, even in a bare repository:
Код:$ git check-attr -a --source=HEAD^{tree} git.c git.c: diff: cpp git.c: whitespace: indent,trail,space
[You do not have permission to view link please Вход or Регистрация]
Over the years, there has been a long-running effort to rewrite old parts of Git from their original Perl or Shell implementations into more modern C equivalents. Aside from being able to use Git’s own APIs natively, consolidating Git commands into a single process means that they are able to run much more quickly on platforms that have a high process start-up cost, such as Windows.
On that front, there are a couple of highlights worth mentioning in this release:
In Git 2.40,git bisect
is now fully implemented in C as a native builtin. This is the result of years of effort from many Git contributors, including a large handful of Google Summer of Code students.
Similarly, Git 2.40 retired the legacy implementation ofgit add --interactive
, which also began as a Shell script and was re-introduced as a native builtin back in version 2.26, supporting both the new and old implementation behind an experimentaladd.interactive.useBuiltin
configuration.
Since that default has been “true” since version 2.37, the Git project has decided that it is time to get rid of the now-legacy implementation entirely, marking the end of another years-long effort to improve Git’s performance and reduce the footprint of legacy scripts.
[You do not have permission to view link please Вход or Регистрация,You do not have permission to view link please Вход or Регистрация]
Last but not least, there are a few under-the-hood improvements to Git’s CI infrastructure. Git has a handful of long-running Windows-specific CI builds that have been disabled in this release (outside of thegit-for-windows
repository). If you’re a Git developer, this means that your CI runs should complete more quickly, and consume fewer resources per push.
On a similar front, you can now configure whether or not pushes to branches that already have active CI jobs running should cancel those jobs or not. This may be useful when pushing to the same branch multiple times while working on a topic.
This can be configured using Git’sci-config
mechanism, by adding a special script calledskip-concurrent
to a branch calledci-config
. If your fork of Git has that branch then Git will consult the relevant scripts there to determine whether CI should be run concurrently or not based on which branch you’re working on.
[You do not have permission to view link please Вход or Регистрация,You do not have permission to view link please Вход or Регистрация]
The rest of the iceberg
That’s just a sample of changes from the latest release. For more, check out the release notes for
You do not have permission to view link please Вход or Регистрация
, or
You do not have permission to view link please Вход or Регистрация
in the Git repository.