Commit graph

61259 commits

Author SHA1 Message Date
Elijah Newren
350410f6b1 diffcore-rename: remove unnecessary duplicate entry checks
Commit 25d5ea410f ("[PATCH] Redo rename/copy detection logic.",
2005-05-24) added a duplicate entry check on rename_src in order to
avoid segfaults; the code at the time was prone to double free()s and an
easy way to avoid it was just to turn off rename detection for any
duplicate entries.  Note that the form of the check was modified two
commits ago in this series.

Similarly, commit 4d6be03b95 ("diffcore-rename: avoid processing
duplicate destinations", 2015-02-26) added a duplicate entry check
on rename_dst for the exact same reason -- the code was prone to double
free()s, and an easy way to avoid it was just to turn off rename
detection entirely.  Note that the form of the check was modified in the
commit just before this one.

In the original code in both places, the code was dealing with
individual diff_filespecs and trying to match things up, instead of just
keeping the original diff_filepairs around as we do now.  The
intervening change in structure has fixed the accounting problems and
the associated double free()s that used to occur, and thus we already
have a better fix.  As such, we can remove the band-aid checks for
duplicate entries.

Due to the last two patches, the diffcore_rename() setup is no longer a
sizeable chunk of overall runtime.  Thus, in a large rebase of many
commits with lots of renames and several optimizations to inexact rename
detection, this patch only speeds up the overall code by about half a
percent or so and is pretty close to the run-to-run variability making
it hard to get an exact measurement.  However, with some trace2 regions
around the setup code in diffcore_rename() so that I can focus on just
it, I measure that this patch consistently saves almost a third of the
remaining time spent in diffcore_rename() setup.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-04 12:59:34 -08:00
Elijah Newren
9db2ac5616 diffcore-rename: accelerate rename_dst setup
register_rename_src() simply references the passed pair inside
rename_src.  In contrast, add_rename_dst() did something entirely
different for rename_dst.  Instead of copying the passed pair, it made a
copy of the second diff_filespec from the passed pair, referenced it,
and then set the diff_rename_dst.pair field to NULL.  Later, when a
pairing is found, record_rename_pair() allocated a full diff_filepair
via diff_queue() and pointed its src and dst fields at the appropriate
diff_filespecs.  This contrast between register_rename_src() for the
rename_src data structure and add_rename_dst() for the rename_dst data
structure is oddly inconsistent and requires more memory and work than
necessary.  Let's just reference the original diff_filepair in
rename_dst as-is, just as we do with rename_src.  Add a new
rename_dst.is_rename field, since the rename_dst.p field is never NULL
unlike the old rename_dst.pair field.

Taking advantage of this change and the fact that same-named paths will
be adjacent, we can get rid of the sorting of the array and most of the
lookups on it, allowing us to instead just append as we go.  However,
there is one remaining reason to still keep locate_rename_dst():
handling broken pairs (i.e. when break detection is on).  Those are
somewhat rare, but we can set up a simple strintmap to get the map
between the source and the index.  Doing that allows us to still have a
fast lookup without sorting the rename_dst array.  Since the sorting had
been done in a weakly quadratic manner, when many renames are involved
this time could add up.

There is still a strcmp() in add_rename_dst() that I have left in place
to make it easier to verify that the algorithm has the same results.
This strcmp() is there to check for duplicate destination entries (which
was the easiest way at the time to avoid segfaults in the
diffcore-rename code when trees had multiple entries at a given path).
The underlying double free()s are no longer an issue with the new
algorithm, but that can be addressed in a subsequent commit.

This patch is being submitted in a different order than its original
development, but in a large rebase of many commits with lots of renames
and with several optimizations to inexact rename detection, both setup
time and write back to output queue time from diffcore_rename() were
sizeable chunks of overall runtime.  This patch accelerated the setup
time by about 65%, and final write back to the output queue time by
about 50%, resulting in an overall drop of 3.5% on the execution time of
rebasing a few dozen patches.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-14 09:34:50 -08:00
Elijah Newren
b970b4ef62 diffcore-rename: simplify and accelerate register_rename_src()
register_rename_src() took pains to create an array in rename_src which
was sorted by pathname of the contained diff_filepair.  The sorting was
entirely unnecessary since callers pass filepairs to us in sorted
order.  We can simply append to the end of the rename_src array,
speeding up diffcore_rename() setup time.

Also, note that I dropped the return type on the function since it was
unconditionally discarded anyway.

This patch is being submitted in a different order than its original
development, but in a large rebase of many commits with lots of renames
and with several optimizations to inexact rename detection,
diffcore_rename() setup time was a sizeable chunk of overall runtime.
This patch dropped execution time of rebasing 35 commits with lots of
renames by 2% overall.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-14 09:34:50 -08:00
Elijah Newren
ac14de13b2 t4058: explore duplicate tree entry handling in a bit more detail
While creating the last commit, I found a number of other cases where
git would segfault when faced with trees that have duplicate entries.
None of these segfaults are in the diffcore-rename code (they all occur
in cache-tree and unpack-trees).  Further, to my knowledge, no one has
ever been adversely affected by these bugs, and given that it has been
15 years and folks have fixed a few other issues with historical
duplicate entries (as noted in the last commit), I am not sure we will
ever run into anyone having problems with these.  So I am not sure these
are worth fixing, but it doesn't hurt to at least document these
failures in the same test file that is concerned with duplicate tree
entries.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-14 09:34:50 -08:00
Elijah Newren
5c72261c66 t4058: add more tests and documentation for duplicate tree entry handling
Commit 4d6be03b95 ("diffcore-rename: avoid processing duplicate
destinations", 2015-02-26) added t4058 to demonstrate that a workaround
it added to avoid double frees (namely to just turn off rename detection
when trees had duplicate entries) would indeed avoid segfaults.  The
tests, though, give the impression that the expected diffs are "correct"
when in reality they are just "don't segfault, and do something
semi-reasonable under the circumstances".  Add some notes to make this
clearer.

Also, commit 25d5ea410f ("[PATCH] Redo rename/copy detection logic.",
2005-05-24) added a similar workaround to avoid segfaults, but for
rename_src rather than rename_dst.  I do not see any tests in the
testsuite to cover the collision detection of entries limited to the
source side, so add a couple.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-14 09:34:50 -08:00
Elijah Newren
81c4bf0296 diffcore-rename: reduce jumpiness in progress counters
Inexact rename detection works by comparing all sources to all
destinations, computing similarities, and then finding the best matches
among those that are sufficiently similar.

However, it is preceded by exact rename detection that works by
checking if there are files with identical hashes.  If exact renames are
found, we can exclude some files from inexact rename detection.

The inexact rename detection loops over the full set of files, but
immediately skips those for which rename_dst[i].is_rename is true and
thus doesn't compare any sources to that destination.  As such, these
paths shouldn't be included in the progress counter.

For the eagle eyed, this change hints at an actual optimization -- the
first one I presented at Git Merge 2020.  I'll be submitting that
optimization later, once the basic merge-ort algorithm has merged.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-14 09:34:50 -08:00
Elijah Newren
ad8a1be529 diffcore-rename: simplify limit check
diffcore-rename had two different checks of the form

    if ((a < limit || b < limit) &&
        a * b <= limit * limit)

This can be simplified to

    if (st_mult(a, b) <= st_mult(limit, limit))

which makes it clearer how we are checking for overflow, and makes it
much easier to parse given the drop from 8 to 4 variable appearances.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-14 09:34:50 -08:00
Elijah Newren
00b8cccdd8 diffcore-rename: avoid usage of global in too_many_rename_candidates()
too_many_rename_candidates() got the number of rename destinations via
an argument to the function, but the number of rename sources via a
global variable.  That felt rather inconsistent.  Pass in the number of
rename sources as an argument as well.

While we are at it... We had a local variable, num_src, that served two
purposes.  Initially it was set to the global value, but later was used
for counting a subset of the number of sources.  Since we now have a
function argument for the former usage, introduce a clearer variable
name for the latter usage.

This patch has no behavioral changes; it's just renaming and passing an
argument instead of grabbing it from the global namespace.  (You may
find it easier to view the patch using git diff's --color-words option.)

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-14 09:34:50 -08:00
Elijah Newren
26a66a6b1c diffcore-rename: rename num_create to num_destinations
Our main data structures are rename_src and rename_dst.  For counters of
these data structures, num_sources and num_destinations seem natural;
definitely more so than using num_create for the latter.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-14 09:34:50 -08:00
Junio C Hamano
3a0b884cab Tenth batch
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-03 00:18:07 -08:00
Junio C Hamano
f3e5dcd660 Merge branch 'pk/subsub-fetch-fix'
An earlier attempt to fix "git fetch --recurse-submodules" broke
another use case; revert it until a better fix is found.

* pk/subsub-fetch-fix:
  Revert "submodules: fix of regression on fetching of non-init subsub-repo"
2020-12-03 00:18:07 -08:00
Junio C Hamano
f3a112a75e Merge branch 'jk/stop-pack-objects-when-fetch-is-killed'
"git fetch" that is killed may leave a pack-objects process behind,
still computing to find a good compression, wasting cycles.  This
has been corrected.

* jk/stop-pack-objects-when-fetch-is-killed:
  upload-pack: kill pack-objects helper on signal or exit
2020-12-03 00:18:07 -08:00
Junio C Hamano
adae5df5d2 Merge branch 'jk/stop-pack-objects-when-push-is-killed'
"git push" that is killed may leave a pack-objects process behind,
still computing to find a good compression, wasting cycles.  This
has been corrected.

* jk/stop-pack-objects-when-push-is-killed:
  send-pack: kill pack-objects helper on signal or exit
2020-12-03 00:18:06 -08:00
Junio C Hamano
39d38a5c5f Merge branch 'tb/repack-simplify'
Simplify the logic to deal with a repack operation that ended up
creating the same packfile.

* tb/repack-simplify:
  builtin/repack.c: don't move existing packs out of the way
  builtin/repack.c: keep track of what pack-objects wrote
  repack: make "exts" array available outside cmd_repack()
2020-12-03 00:18:06 -08:00
Junio C Hamano
c692e1b673 Merge branch 'pb/pull-rebase-recurse-submodules'
"git pull --rebase --recurse-submodules" checked for local changes
in a wrong range and failed to run correctly when it should.

* pb/pull-rebase-recurse-submodules:
  pull: check for local submodule modifications with the right range
  t5572: describe '--rebase' tests a little more
  t5572: add notes on a peculiar test
  pull --rebase: compute rebase arguments in separate function
2020-12-03 00:18:06 -08:00
Junio C Hamano
e89ecfbb13 Merge branch 'ab/retire-parse-remote'
"git-parse-remote" shell script library outlived its usefulness.

* ab/retire-parse-remote:
  submodule: fix fetch_in_submodule logic
  parse-remote: remove this now-unused library
  submodule: remove sh function in favor of helper
  submodule: use "fetch" logic instead of custom remote discovery
2020-12-03 00:18:06 -08:00
Junio C Hamano
7091499bc0 Revert "submodules: fix of regression on fetching of non-init subsub-repo"
This reverts commit 1b7ac4e6d4d490b224f5206af7418ed74e490608; in
<CAN0XMOLiS_8JZKF_wW70BvRRxkDHyUoa=Z3ODtB_Bd6f5Y=7JQ@mail.gmail.com>,
Ralf Thielow reports that "git fetch" with submodule.recurse set can
result in a bogus and infinitely recursive fetching of the same
submodule.
2020-12-02 15:07:14 -08:00
Jeff King
309a4028e7 upload-pack: kill pack-objects helper on signal or exit
We spawn an external pack-objects process to actually send objects to
the remote side. If we are killed by a signal during this process, then
pack-objects may continue to run. As soon as it starts producing output
for the pack, it will see a failure writing to upload-pack and exit
itself. But before then, it may do significant work traversing the
object graph, compressing deltas, etc, which will all be pointless. So
let's make sure to kill as soon as we know that the caller will not read
the result.

There's no test here, since it's inherently racy, but here's an easy
reproduction is on a large-ish repo like linux.git:

  - make sure you don't have pack bitmaps (since they make the enumerating
    phase go quickly). For linux.git it takes ~30s or so to walk the
    whole graph on my machine.

  - run "git clone --no-local -q . dst"; the "-q" is important because
    if pack-objects is writing progress to upload-pack (to get
    multiplexed over the sideband to the client), then it will notice
    pretty quickly the failure to write to stderr

  - kill the client-side clone process in another terminal (don't use
    ^C, as that will send SIGINT to all of the processes)

  - run "ps au | grep git" or similar to observe upload-pack dying
    within 5 seconds (it will send a keepalive that will notice the
    client has gone away)

  - but you'll still see pack-objects consuming 100% CPU (and 1GB+ of
    RAM) during the traversal and delta compression phases. It will exit
    as soon as it starts to write the pack (when it will notice that
    upload-pack went away).

With this patch, pack-objects exits as soon as upload-pack does.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-01 12:05:58 -08:00
Junio C Hamano
72ffeb997e Ninth batch
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-30 14:49:45 -08:00
Junio C Hamano
3d8f81f21b Merge branch 'sa/credential-store-timeout'
Multiple "credential-store" backends can race to lock the same
file, causing everybody else but one to fail---reattempt locking
with some timeout to reduce the rate of the failure.

* sa/credential-store-timeout:
  crendential-store: use timeout when locking file
2020-11-30 14:49:45 -08:00
Junio C Hamano
fa27e2d103 Merge branch 'km/stash-error-message-fix'
Error message fix.

* km/stash-error-message-fix:
  stash: add missing space to an error message
2020-11-30 14:49:45 -08:00
Junio C Hamano
43c1c79f1f Merge branch 'hn/sleep-millisec-decl'
Move a definition of compatibility wrapper from cache.h to
git-compat-util.h

* hn/sleep-millisec-decl:
  move sleep_millisec to git-compat-util.h
2020-11-30 14:49:44 -08:00
Junio C Hamano
9f41d09888 Merge branch 'js/t3404-master-to-primary'
A test script got cleaned up and then made not to depend on the
value of init.defaultBranch.

* js/t3404-master-to-primary:
  t3404: do not depend on any specific default branch name
2020-11-30 14:49:44 -08:00
Junio C Hamano
e082a85708 Merge branch 'na/notes-displayref-is-not-boolean'
Config parser fix for "git notes".

* na/notes-displayref-is-not-boolean:
  t3301: test proper exit response to no-value notes.displayRef.
  notes.c: fix a segfault in notes_display_config()
2020-11-30 14:49:44 -08:00
Junio C Hamano
b94b1f9af8 Merge branch 'jc/do-not-just-explain-but-update-your-patch'
Expectation for the original contributor after responding to a
review comment to use the explanation in a patch update has been
described.

* jc/do-not-just-explain-but-update-your-patch:
  MyFirstContribition: answering questions is not the end of the story
2020-11-30 14:49:43 -08:00
Junio C Hamano
f73ee0c6be Merge branch 'mt/worktree-error-message-fix'
Fix formulation of an error message with two placeholders in "git
worktree add" subcommand.

* mt/worktree-error-message-fix:
  worktree: fix order of arguments in error message
2020-11-30 14:49:43 -08:00
Junio C Hamano
1c04cdd424 Merge branch 'ab/gc-keep-base-option'
Fix an option name in "gc" documentation.

* ab/gc-keep-base-option:
  gc: rename keep_base_pack variable for --keep-largest-pack
  gc docs: change --keep-base-pack to --keep-largest-pack
2020-11-30 14:49:43 -08:00
Junio C Hamano
124250108f Merge branch 'js/t1309-master-to-topic'
Test preparation.

* js/t1309-master-to-topic:
  t1309: use a neutral branch name in the `onbranch` test cases
2020-11-30 14:49:42 -08:00
Junio C Hamano
290c94085b Merge branch 'js/pull-rebase-use-advise'
UI improvement.

* js/pull-rebase-use-advise:
  pull: colorize the hint about setting `pull.rebase`
2020-11-30 14:49:42 -08:00
Junio C Hamano
376b4cc420 Merge branch 'js/t4015-wo-master'
A test script got cleaned up not to depend on the value of
init.defaultBranch.

* js/t4015-wo-master:
  t4015: let the test pass with any default branch name
2020-11-30 14:49:41 -08:00
Junio C Hamano
26d0286103 Merge branch 'js/t3040-cleanup'
Cleanup.

* js/t3040-cleanup:
  t3040: remove stale note
2020-11-30 14:49:41 -08:00
Junio C Hamano
39f95df236 Merge branch 'js/t2106-cleanup'
A test script got cleaned up and then made not to depend on the
value of init.defaultBranch.

* js/t2106-cleanup:
  t2106: ensure that the checkout fails for the expected reason
  t2106: make test independent of the current main branch name
  t2106: adjust style to the current conventions
2020-11-30 14:49:41 -08:00
Junio C Hamano
e67fbf927d Eighth batch
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25 15:24:54 -08:00
Junio C Hamano
7bd645e21d Merge branch 'sg/tests-prereq'
A lazily defined test prerequisite can now be defined in terms of
another lazily defined test prerequisite.

* sg/tests-prereq:
  tests: fix description of 'test_set_prereq'
  tests: make sure nested lazy prereqs work reliably
2020-11-25 15:24:54 -08:00
Junio C Hamano
ca065523c6 Merge branch 'rs/plug-diff-cache-leak'
Memleak fix.

* rs/plug-diff-cache-leak:
  diff-lib: plug minor memory leaks in do_diff_cache()
2020-11-25 15:24:53 -08:00
Junio C Hamano
2ba70a330b Merge branch 'rs/gc-sort-func-cast-fix'
Fix broken sorting of maintenance tasks.

* rs/gc-sort-func-cast-fix:
  gc: fix cast in compare_tasks_by_selection()
2020-11-25 15:24:53 -08:00
Junio C Hamano
57228d3189 Merge branch 'jc/ci-github-set-env'
Another CI adjustment.

* jc/ci-github-set-env:
  ci: avoid `set-env` construct in print-test-failures.sh
2020-11-25 15:24:53 -08:00
Junio C Hamano
d302170046 Merge branch 'sg/t5310-jgit-wants-sha1'
Since jgit does not yet work with SHA-256 repositories, mark the
tests that uses it not to run unless we are testing with ShA-1
repositories.

* sg/t5310-jgit-wants-sha1:
  t5310-pack-bitmaps: skip JGit tests with SHA256
2020-11-25 15:24:53 -08:00
Junio C Hamano
3eebb3e044 Merge branch 'rs/archive-plug-leak-refname'
Memleak fix.

* rs/archive-plug-leak-refname:
  archive: release refname after use
2020-11-25 15:24:53 -08:00
Junio C Hamano
b5b71cbd5d Merge branch 'ma/list-object-filter-opt-msgfix'
Error message fix.

* ma/list-object-filter-opt-msgfix:
  list-objects-filter-options: fix function name in BUG
2020-11-25 15:24:53 -08:00
Junio C Hamano
d627bf6039 Merge branch 'pk/subsub-fetch-fix'
"git fetch" did not work correctly with nested submodules where the
innermost submodule that is not of interest got updated in the
upstream, which has been corrected.

* pk/subsub-fetch-fix:
  submodules: fix of regression on fetching of non-init subsub-repo
2020-11-25 15:24:52 -08:00
Junio C Hamano
fcf26ef53a Merge branch 'jk/4gb-idx'
The code was not prepared to deal with pack .idx file that is
larger than 4GB.

* jk/4gb-idx:
  packfile: detect overflow in .idx file size checks
  block-sha1: take a size_t length parameter
  fsck: correctly compute checksums on idx files larger than 4GB
  use size_t to store pack .idx byte offsets
  compute pack .idx byte offsets using size_t
2020-11-25 15:24:52 -08:00
Junio C Hamano
8f8f10ac09 Merge branch 'jx/t5411-flake-fix'
The exchange between receive-pack and proc-receive hook did not
carefully check for errors.

* jx/t5411-flake-fix:
  receive-pack: use default version 0 for proc-receive
  receive-pack: gently write messages to proc-receive
  t5411: new helper filter_out_user_friendly_and_stable_output
2020-11-25 15:24:52 -08:00
Junio C Hamano
455e8d18f8 Merge branch 'rs/hashwrite-be64'
Code simplification.

* rs/hashwrite-be64:
  pack-write: use hashwrite_be64()
  midx: use hashwrite_be64()
  csum-file: add hashwrite_be64()
2020-11-25 15:24:52 -08:00
Junio C Hamano
2557c1183a Merge branch 'sg/bisect-approximately-halfway'
"git bisect start/next" in a large span of history spends a lot of
time trying to come up with exactly the half-way point; this can be
optimized by stopping when we see a commit that is close enough to
the half-way point.

* sg/bisect-approximately-halfway:
  bisect: loosen halfway() check for a large number of commits
2020-11-25 15:24:52 -08:00
Junio C Hamano
fd6445a0b8 Merge branch 'fc/bash-completion-alias-of-alias'
The command line completion script (in contrib/) learned to expand
commands that are alias of alias.

* fc/bash-completion-alias-of-alias:
  completion: bash: improve alias loop detection
  completion: bash: check for alias loop
  completion: bash: support recursive aliases
2020-11-25 15:24:51 -08:00
Simão Afonso
df7f915fb6 crendential-store: use timeout when locking file
When holding the lock for rewriting the credential file, use a timeout
to avoid race conditions when the credentials file needs to be updated
in parallel.

An example would be doing `fetch --all` on a repository with several
remotes that need credentials, using parallel fetching.

The timeout can be configured using "credentialStore.lockTimeoutMS",
defaulting to 1 second.

Signed-off-by: Simão Afonso <simao.afonso@powertools-tech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25 12:30:18 -08:00
Han-Wen Nienhuys
a76b138daa move sleep_millisec to git-compat-util.h
The sleep function is defined in wrapper.c, so it makes more sense to be a in
system compatibility header.

Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-24 17:40:16 -08:00
Junio C Hamano
a6d8d11036 MyFirstContribition: answering questions is not the end of the story
A review exchange may begin with a reviewer asking "what did you
mean by this phrase in your log message (or here in the doc)?", the
author answering what was meant, and then the reviewer saying "ah,
that is what you meant---then the flow of the logic makes sense".

But that is not the happy end of the story.  New contributors often
forget that the material that has been reviewed in the above exchange
is still unclear in the same way to the next person who reads it,
until it gets updated.

While we are in the vicinity, rephrase the verb "request" used to
refer to comments by reviewers to "suggest"---this matches the
contrast between "original" and "suggested" that appears later in
the same paragraph, and more importantly makes it clearer that it is
not like authors are to please reviewers' wishes but rather
reviewers are merely helping authors to polish their commits.

Reviewed-by: Emily Shaffer <emilyshaffer@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-24 14:11:17 -08:00
Johannes Schindelin
9c8509a4e3 t3404: do not depend on any specific default branch name
Now that we can override the default branch name in the tests via
`GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME`, we should avoid expecting a
particular hard-coded name.

So let's rename the initial branch immediately to `primary` and work
with that.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-24 13:17:06 -08:00