It is tempting to do away with commit_graft altogether (in the long
haul), now that grafts are deprecated.
However, the shallow feature needs a couple of things that the replace
refs cannot fulfill. Let's point that out in the documentation.
Signed-off-by: Johannes Schindelin
On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov wrote:
> Johannes Schindelin writes:
>
>> Hi Phillip,
>>
>> On Fri, 13 Apr 2018, Phillip Wood wrote:
>>
>>> On 12/04/18 23:02, Johannes Schindelin wrote:
>>> >
>>> > [...]
>>> >
>>> > So: the order of
Now that grafts are deprecated, we should start to assume that readers
have no idea what grafts are. So it makes more sense to describe the
"shallow" feature in terms of replace refs.
Suggested-by: Eric Sunshine
Signed-off-by: Johannes Schindelin
The grafts feature was a convenient way to "stitch together" ancient
history to the fresh start of linux.git.
Its implementation is, however, not up to Git's standards, as there are
too many ways where it can lead to surprising and unwelcome behavior.
For example, when pushing from a repository
The graft file is deprecated now, so let's use replace refs in the example
in filter-branch's man page instead.
Suggested-by: Eric Sunshine
Signed-off-by: Johannes Schindelin
---
Documentation/git-filter-branch.txt | 2 +-
1 file changed, 1
Derrick Stolee writes:
> @@ -876,7 +886,7 @@ static struct commit_list *merge_bases_many(struct commit
> *one, int n, struct co
> return NULL;
> }
>
> - list = paint_down_to_common(one, n, twos);
> + list = paint_down_to_common(one,
Hi Stefan,
On Fri, 13 Apr 2018, Stefan Beller wrote:
> On Fri, Apr 13, 2018 at 3:35 PM, Johannes Schindelin
> wrote:
>
> >> I wonder if we want to offer a migration tool or just leave it at
> >> this hint.
> >
> > There is contrib/convert-grafts-to-replace-refs.sh.
On 18/04/18 19:15, Johannes Sixt wrote:
> Am 18.04.2018 um 19:47 schrieb Phillip Wood:
>> On 18/04/18 12:27, Ævar Arnfjörð Bjarmason wrote:
>>> On Wed, Apr 18 2018, Phillip Wood wrote:
From: Phillip Wood
as it is created by running an separate instance of
Hi Eric,
On Fri, 13 Apr 2018, Eric Sunshine wrote:
> On Fri, Apr 13, 2018 at 7:11 AM, Johannes Schindelin
> wrote:
> > The grafts feature was a convenient way to "stich together" ancient
> > history to the fresh start of linux.git.
> > [...]
> > The much younger
On Thu, Apr 19 2018, Junio C. Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> We have a -s ours, but not a -s theirs. This is a WIP patch to implement
>> that. It works, but I haven't dealt with this part of the internal API
>> before, comments most welcome.
>>
>> The
2018-04-05 0:41 GMT+03:00 Stefan Beller :
> On Wed, Apr 4, 2018 at 1:37 PM, Eddy Petrișor wrote:
>
>>> you plan to later submit as one patch including both the change as well as
>>> the test.
>>
>> Yes,
I did not forget about having a single patch.
It is fragile, as there is no way for the revision machinery to say "but
now I want to traverse the graph ignoring the graft file" e.g. when
pushing commits to a remote repository (which, as a consequence, can
miss commits).
And we already have a better solution with `git replace --graft
[...]`.
It is quite convenient to simply die() in builtins, in the absence of
proper exception handling, because it allows us to just go belly up
without having to implement error handling chains.
Of course, for reusable library functions, this is a big no-no, so we
(try to) restrict the usage of die()
This option is intended to help with the transition away from the
now-deprecated graft file.
Signed-off-by: Johannes Schindelin
---
Documentation/git-replace.txt | 11 +--
builtin/replace.c | 59 ++-
2 files changed, 66
The proof, as the saying goes, lies in the pudding. So here is a
regression test that not only demonstrates what the option is supposed to
accomplish, but also demonstrates that it does accomplish it.
Signed-off-by: Johannes Schindelin
---
t/t6050-replace.sh | 20
On 16/04/18 10:48, Phillip Wood wrote:
> On 14/04/18 14:11, Johannes Schindelin wrote:
>> Hi,
>>
>> On Sat, 14 Apr 2018, Phillip Wood wrote:
>>
>> FWIW I agree with Hannes' patch.
>>
>>> I think 'git am' probably gives all patches the same commit time as well
>>> if the commit date is cached
Derrick Stolee writes:
> If the commit-graph file becomes corrupt, we need a way to verify
> its contents match the object database. In the manner of 'git fsck'
> we will implement a 'git commit-graph check' subcommand to report
> all issues with the file.
Bikeshed:
On Mon, Apr 9, 2018 at 9:49 PM, Florian Gamböck wrote:
> On 2018-04-09 11:26, Stefan Beller wrote:
>> If Gits own completion script would be broken up by subcommand, would that
>> also deliver an improvement in performance?
>
>
> As it is now, the completion script is quite big. On
Hi Jacob,
Jacob Keller writes:
> On Wed, Apr 18, 2018 at 9:24 PM, Sergey Organov wrote:
>> Johannes Schindelin writes:
>>
>>> Hi Phillip,
>>>
>>> On Fri, 13 Apr 2018, Phillip Wood wrote:
>>>
On 12/04/18 23:02,
As pointed out in a review of the `--rebase-merges` patch series,
`rollback_lock_file()` clobbers errno. Therefore, we have to report the
error message that uses errno before calling said function.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 10 ++
1
Previously, we did a lot of arithmetic gymnastics to get at the line in
the todo list (as stored in todo_list.buf). This might have been fast,
but only in terms of execution speed, not in terms of developer time.
Let's refactor this to make it a lot easier to read, and hence to
reason about the
What happens:
When I create a new tag on the remote (changing nothing else)
"git pull origin master" produces the following:
From git.internal.company.com:team/testrepo
* branchmaster -> FETCH_HEAD
Already up-to-date.
If I instead do a "git pull" I get:
From
Jsem Ronald Bernstein, jsem úverový dustojník, dávám pujcky jednotlivcum a
firme pro obchodní a osobní úcely, kontaktujte me, pokud potrebujete jakýkoliv
druh pujcky. Poskytuji pujcky široké verejnosti s úrokovou sazbou 2%.
On Thu, Apr 19, 2018 at 10:52:47AM +0900, Junio C Hamano wrote:
> It turns out that prune silently goes away given a bad expiry
>
> $ git prune --expire=nyah ; echo $?
> 129
I noticed that git log --since/--after/--before/--until have a
similar behavior and ignore date parsing errors in
On Thu, Apr 19, 2018 at 10:17 AM, Johannes Schindelin
wrote:
> @@ -87,9 +88,13 @@ OPTIONS
> content as except that its parents will be
> [...] instead of 's parents. A replacement ref
> is then created to replace with the newly created
> -
Hello dear,
I am Miss Lisa. I have very important thing to discuss with you
please, this information is very vital. Contact me with my private
email so we can talk (lisajohnsonsalima...@hotmail.com )
Lisa.
Hi Phillip,
On Sat, 14 Apr 2018, Johannes Schindelin wrote:
> On Fri, 13 Apr 2018, Phillip Wood wrote:
>
> > On 13/04/18 11:12, Phillip Wood wrote:
> > > @@ -3030,7 +3029,8 @@ static int pick_commits(struct todo_list
> > > *todo_list, struct replay_opts *opts)
> > > return
Once upon a time, I dreamt of an interactive rebase that would not
flatten branch structure, but instead recreate the commit topology
faithfully.
My original attempt was --preserve-merges, but that design was so
limited that I did not even enable it in interactive mode.
Subsequently, it *was*
- On Apr 19, 2018, at 8:10 AM, Matthew Wilcox wi...@infradead.org wrote:
> On Thu, Apr 19, 2018 at 06:21:42AM +0900, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>> > But IMO this patch is really lacking a few things before being ready:
>> >
>> > 1. You have
Once upon a time, this here developer thought: wouldn't it be nice if,
say, Git for Windows' patches on top of core Git could be represented as
a thicket of branches, and be rebased on top of core Git in order to
maintain a cherry-pick'able set of patch series?
The original attempt to answer this
The sequencer just learned new commands intended to recreate branch
structure (similar in spirit to --preserve-merges, but with a
substantially less-broken design).
Let's allow the rebase--helper to generate todo lists making use of
these commands, triggered by the new --rebase-merges option. For
In the previous patches, we implemented the basic functionality of the
`git rebase -i --rebase-merges` command, in particular the `merge`
command to create merge commits in the sequencer.
The interactive rebase is a lot more these days, though, than a simple
cherry-pick in a loop. For example, it
From: Phillip Wood
If there are empty commits on the left hand side of $upstream...HEAD
then the empty commits on the right hand side that we want to keep are
being pruned.
Signed-off-by: Phillip Wood
---
This allows for rebases to be run in parallel in separate worktrees
(think: interrupted in the middle of one rebase, being asked to perform
a different rebase, adding a separate worktree just for that job).
Signed-off-by: Johannes Schindelin
---
refs.c
There are some commands that have to be skipped from rearranging by virtue
of not handling any commits.
However, the logic was not quite obvious: it skipped commands based on
their position in the enum todo_command.
Instead, let's make it explicit that we skip all commands that do not
handle any
Previously, we did that just magically, and potentially left some users
quite puzzled. Let's err on the safe side instead, telling the user what
is happening, and how they are supposed to continue.
Signed-off-by: Johannes Schindelin
---
sequencer.c | 16
The `git merge` command does not allow merging commits that are already
reachable from HEAD: `git merge HEAD^`, for example, will report that we
are already up to date and not change a thing.
In an interactive rebase, such a merge could occur previously, e.g. when
competing (or slightly modified)
Hello,
When running make -j$(nproc) with the current pu f9f8c1f765
(Merge branch 'hn/bisect-first-parent' into pu) I see the
following error:
GIT_VERSION = 2.17.0.732.gf9f8c1f765
* new build flags
* new prefix flags
GEN common-cmds.h
* new link flags
CC ident.o
CC hex.o
Junio C Hamano writes:
[...]
>
> * js/rebase-recreate-merge (2018-04-11) 15 commits
[...]
> "git rebase" learned "--rebase-merges" to transplant the whole
> topology of commit graph elsewhere.
>
> This looked more or less ready for 'next'. Please stop me if there
> are
On Thu, Apr 19, 2018 at 06:21:42AM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > But IMO this patch is really lacking a few things before being ready:
> >
> > 1. You have no tests for this. See t/t9001-send-email.sh for examples,
> > ...
> > 2. Just a few
From: Stefan Beller
Up to now each command took a commit as its first argument and ignored
the rest of the line (usually the subject of the commit)
Now that we are about to introduce commands that take different
arguments, clarify each command by giving the argument
The --rebase-merges mode is probably not half as intuitive to use as
its inventor hopes, so let's document it some.
Signed-off-by: Johannes Schindelin
---
Documentation/git-rebase.txt | 132 +++
1 file changed, 132 insertions(+)
diff
This one is a bit tricky to explain, so let's try with a diagram:
C
/ \
A - B - E - F
\ /
D
To illustrate what this new mode is all about, let's consider what
happens upon `git rebase -i --rebase-merges B`, in particular to
the commit `D`. So far, the new branch structure
Similar to the `preserve` mode simply passing the `--preserve-merges`
option to the `rebase` command, the `merges` mode simply passes the
`--rebase-merges` option.
This will allow users to conveniently rebase non-trivial commit
topologies when pulling new commits, without flattening them.
--
Greetings,
I wonder why you continue neglecting my emails. Please, acknowledge the
receipt of this message in reference to the subject above as I intend
to send to you the details of the project. Sometimes, try to check your
spam box because most of these correspondences fall out
From: "Duy Nguyen"
On Wed, Apr 18, 2018 at 12:47 AM, Philip Oakley
wrote:
> Is that something I should add to my todo to add a 'guide' category >
> etc.?
I added it too [1]. Not sure if you want anything more on top though.
What I've seen is
In the upcoming commits, we will teach the sequencer to rebase merges.
This will be done in a very different way from the unfortunate design of
`git rebase --preserve-merges` (which does not allow for reordering
commits, or changing the branch topology).
The main idea is to introduce new todo
sequencer: introduce the `merge` command
This patch is part of the effort to reimplement `--preserve-merges` with
a substantially improved design, a design that has been developed in the
Git for Windows project to maintain the dozens of Windows-specific patch
series on top of upstream Git.
The
Just like with regular `pick` commands, if we are trying to rebase a
merge commit, we now test whether the parents of said commit match HEAD
and the commits to be merged, and fast-forward if possible.
This is not only faster, but also avoids unnecessary proliferation of
new objects.
Elijah Newren writes:
> On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
>> This series is a reboot of the directory rename detection series that was
>> merged to master and then reverted due to the final patch having a buggy
>> can-skip-update check,
On Thu, Apr 19, 2018 at 8:20 AM, Johannes Schindelin
wrote:
> # This is a combination of 2 commits. # This is the 1st commit message:
Botched squash/fixup?
> sequencer: introduce the `merge` command
>
> This patch is part of the effort to reimplement
On 20 April 2018 at 00:48, Junio C Hamano wrote:
> Isaac Chou writes:
>
>> I inspected the source code (builtin/fast-export.c) for the
>> fast-export issue I encountered, and it looks like the merge
>> commit is discarded too early by the call to
On Fri, Apr 20, 2018 at 1:25 AM, Thomas Gummerer wrote:
> The 'save' subcommand in git stash has been deprecated in
> fd2ebf14db ("stash: mark "git stash save" deprecated in the man page",
> 2017-10-22).
>
> Stop showing it when the users enters 'git stash ' or 'git stash
>
Derrick Stolee writes:
> During a run of 'git commit-graph check', list the issues with the
> header information in the commit-graph file. Some of this information
> is inferred from the loaded 'struct commit_graph'.
>
> Signed-off-by: Derrick Stolee
On Thu, Apr 19, 2018 at 12:37 PM, Simon Ruderich wrote:
> When running make -j$(nproc) with the current pu f9f8c1f765
> (Merge branch 'hn/bisect-first-parent' into pu) I see the
> following error:
>
> GIT_VERSION = 2.17.0.732.gf9f8c1f765
> * new build flags
> * new
The description of the argument directs readers to "See the
URLS section below". When generating HTML this becomes a link to the
"GIT URLS" section. When reading the man page in a terminal, the
caption is slightly misleading. Use "GIT URLS" as the caption to avoid
any confusion.
Hi Eddy,
> I suspect that in the tests, because the "server side" repos are
> local, the git fetch-by-sha1/cloning by hash will be done correctly,
> without the need of a branch hint, but the problem will still exist
> for servers such as github which do not support fetch-by-sha1.
> In case I
If a file on one side of history was renamed, and merely modified on the
other side, then applying a directory rename to the modified side gives us
a rename/rename(1to2) conflict. We should only apply directory renames to
pairs representing either adds or renames.
Making this change means that a
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Reviewed-by: Stefan Beller
Signed-off-by:
Create a new function, get_diffpairs() to compute the diff_filepairs
between two trees. While these are currently only used in
get_renames(), I want them to be available to some new functions. No
actual logic changes yet.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah
On Thu, Apr 19, 2018 at 11:35 AM, Elijah Newren wrote:
> On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
>> This series is a reboot of the directory rename detection series that was
>> merged to master and then reverted due to the final patch having a
Add a testcase showing spurious rename/rename(1to2) conflicts occurring
due to directory rename detection.
Also add a pair of testcases dealing with moving directory hierarchies
around that were suggested by Stefan Beller as "food for thought" during
his review of an earlier patch series, but
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 367
1 file changed, 367 insertions(+)
diff --git
Before trying to apply directory renames to paths within the given
directories, we want to make sure that there aren't conflicts at the
file level either. If there aren't any, then get the new name from
any directory renames.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah
I came up with the testcases in the first eight sections before coding up
the implementation. The testcases in this section were mostly ones I
thought of while coding/debugging, and which I was too lazy to insert
into the previous sections because I didn't want to re-label with all the
testcase
The amount of logic in merge_trees() relative to renames was just a few
lines, but split it out into new handle_renames() and cleanup_renames()
functions to prepare for additional logic to be added to each. No code or
logic changes, just a new place to put stuff for when the rename detection
Add a long note about why we are not considering "partial directory
renames" for the current directory rename detection implementation.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 458
1 file changed, 458 insertions(+)
diff --git
get_renames() would look up stage data that already existed (populated
in get_unmerged(), taken from whatever unpack_trees() created), and if
it didn't exist, would call insert_stage_data() to create the necessary
entry for the given file. The insert_stage_data() fallback becomes
much more
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 442
1 file changed, 442 insertions(+)
create mode 100755
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 404
1 file changed, 404 insertions(+)
diff --git
In anticipation of more involved cleanup to come, make a helper function
for doing the cleanup at the end of handle_renames. Rename the already
existing cleanup_rename[s]() to final_cleanup_rename[s](), name the new
helper initial_cleanup_rename(), and leave the big comment in the code
about why
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 336
1 file changed, 336 insertions(+)
diff --git
Move this function so it can re-use some others (without either
moving all of them or adding an annoying split between function
declarations and definitions). Cheat slightly by adding a blank line
for readability, and in order to silence checkpatch.pl.
Reviewed-by: Stefan Beller
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 330
1 file changed, 330 insertions(+)
diff --git
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 153
1 file changed, 153 insertions(+)
diff --git
This populates a set of directory renames for us. The set of directory
renames is not yet used, but will be in subsequent commits.
Note that the use of a string_list for possible_new_dirs in the new
dir_rename_entry struct implies an O(n^2) algorithm; however, in practice
I expect the number of
This fixes an issue that existed before my directory rename detection
patches that affects both normal renames and renames implied by
directory rename detection. Additional codepaths that only affect
overwriting of dirty files that are involved in directory rename
detection will be added in a
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 143
1 file changed, 143 insertions(+)
diff --git
On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
> This series is a reboot of the directory rename detection series that was
> merged to master and then reverted due to the final patch having a buggy
> can-skip-update check, as noted at
>
Junio,
you may want to squash this into your merge commit of branch
ps/test-chmtime-get (today it is fa57c0871fc9)
-- Hannes
diff --git a/t/helper/test-chmtime.c b/t/helper/test-chmtime.c
index daeddc1cbc..aa22af48c2 100644
--- a/t/helper/test-chmtime.c
+++ b/t/helper/test-chmtime.c
@@ -25,7
get_renames() has always zero'ed out diff_queued_diff.nr while only
manually free'ing diff_filepairs that did not correspond to renames.
Further, it allocated struct renames that were tucked away in the
return string_list. Make sure all of these are deallocated when we
are done with them.
directory renaming and merging can cause one or more files to be moved to
where an existing file is, or to cause several files to all be moved to
the same (otherwise vacant) location. Add checking and reporting for such
cases, falling back to no-directory-rename handling for such paths.
If a cherry-pick or merge with a rename results in a skippable update
(due to the merged content matching what HEAD already had), but the
working directory is dirty, avoid trying to refresh the index as that
will fail.
Signed-off-by: Elijah Newren
---
merge-recursive.c
Previously, merge_content() would print "Auto-merging" whenever the final
content and mode aren't already available from HEAD. There are a few
problems with this:
1) There are other code paths doing merges that should probably have the
same message printed, in particular
This commit hooks together all the directory rename logic by making the
necessary changes to the rename struct, it's dst_entry, and the
diff_filepair under consideration.
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
Add several tests checking whether updates can be skipped in a merge.
Also add several similar testcases for where updates cannot be skipped in
a merge to make sure that we skip if and only if we should.
In particular:
* Testcase 1a (particularly 1a-check-L) would have pointed out the
The can-working-tree-updates-be-skipped check has had a long and blemished
history. The update can be skipped iff:
a) The merge is clean
b) The merge matches what was in HEAD (content, mode, pathname)
c) The target path is usable (i.e. not involved in D/F conflict)
Traditionally, we split
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
merge-recursive.c | 25 ++---
t/t6043-merge-rename-directories.sh | 8
2 files changed, 26
Before trying to apply directory renames to paths within the given
directories, we want to make sure that there aren't conflicts at the
directory level. There will be additional checks at the individual
file level too, which will be added later.
Reviewed-by: Stefan Beller
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
t/t6043-merge-rename-directories.sh | 396
1 file changed, 396 insertions(+)
diff --git
This series is a reboot of the directory rename detection series that was
merged to master and then reverted due to the final patch having a buggy
can-skip-update check, as noted at
https://public-inbox.org/git/xmqqmuya43cs@gitster-ct.c.googlers.com/
This series based on top of master.
This
Four closely related changes all with the purpose of fixing error handling
in this function:
- fix reported function name in add_cacheinfo error messages
- differentiate between the two error messages
- abort early when we hit the error (stop ignoring return code)
- mark a test which was
In commit aacb82de3ff8 ("merge-recursive: Split was_tracked() out of
would_lose_untracked()", 2011-08-11), was_tracked() was split out of
would_lose_untracked() with the intent to provide a function that could
answer whether a path was tracked in the index before the merge. Sadly,
it instead
Reviewed-by: Stefan Beller
Signed-off-by: Elijah Newren
Signed-off-by: Junio C Hamano
---
merge-recursive.c | 42 +++--
t/t6043-merge-rename-directories.sh | 6 ++---
2 files changed, 43
was_dirty() uses was_tracked(), which has been updated to use the original
index rather than the current one. However, was_dirty() also had a
separate call to cache_file_exists(), causing it to still implicitly use
the current index. Update that to instead use index_file_exists().
Also,
conflict_rename_normal() was doing some handling for dirty files that
more naturally belonged in merge_content. Move it, and rename a
parameter for clarity while at it.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 30 --
1 file changed, 12
Derrick Stolee writes:
> Before checking a commit-graph file against the object database, we
Actually there is quite a few checks more that can be done without
accessing the object database... I'll take a look at later commits why
this one is that relatively early in the
On 4/19/2018 2:41 PM, Stefan Beller wrote:
On Thu, Apr 19, 2018 at 11:35 AM, Elijah Newren wrote:
On Thu, Apr 19, 2018 at 10:57 AM, Elijah Newren wrote:
This series is a reboot of the directory rename detection series that was
merged to master and then
Just a couple of minor things:
> +###
> +# SECTION 1: Cases involving no renames (one side has subset of changes of
> +#the other side)
>
1 - 100 of 126 matches
Mail list logo