On Mon, 01 Jul 2019 12:48:16 +, Bryan Turner wrote:
...
> In other words, when I locally do:
> git checkout --no-track -b bturner-some-bugfix origin/release/5.16
>
> release/5.16 is the "parent branch" of my bugfix branch and, when I
> push my branch and try to open a pull request, release/5.1
On Mon, Jul 01, 2019 at 12:02:45PM -0500, Taylor Blau wrote:
> One thing that I didn't catch in my initial review that I am seeing now
> is the ".alternate" marker. Why did you choose this? I was thinking that
> ".have" would make more sense since it's consistent with what's shown in
> the ref adv
On Mon, Jul 01, 2019 at 03:28:45PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > - replace eval formatting magic with "%s" printf formatters (safer and
> > gets rid of quoting issues in the callers).
>
> This one actually made me think twice about safety, as we'd be using
> end-u
On Mon, Jul 01, 2019 at 03:24:35PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Here's a re-roll of just the first patch of this series, since that was
> > the one that got all the comments (and the others are textually
> > independent).
>
> OK, will replace and then queue an adjustme
The bash completion script knows some options to "git log" and
"git show" only in the positive form, (e.g. "--abbrev-commit"), but not
in their negative form (e.g. "--no-abbrev-commit"). Add them.
Also, the bash completion script is missing some other options to
"git diff", and "git show" (and thu
Teach transport-helper how to notice if skipping a ref during push would
violate atomicity on the client side. We notice that a ref would be
rejected, and choose not to send it, but don't notice that if the client
has asked for --atomic we are violating atomicity if all the other
pushes we are send
Anton Ermolenko wrote:
> My understanding is that recursive merge here won't consider that situation to
> be a merge conflict as the changes have been introduced in different spots in
> the file.
Yes, that seems right to me.
Do you have more details about the context? What do these files look
l
Hello folks,
I'm writing on behalf of a customer and I wonder if you could help me to clarify
if the following test case should be considered a bug or if it is expected
behavior.
# create repository
git init
# add initial content
cat << EOF > example.txt
--- START ---
LINE 1
LINE 2
On Mon, Jul 1, 2019 at 8:32 AM Derrick Stolee via GitGitGadget
wrote:
>
> To centralize these config options and properly set the defaults,
> create a repo_settings that contains chars for each config variable.
> Use -1 as "unset", with 0 for false and 1 for true.
minor nitpick that hopefully Jun
Jeff King writes:
> - replace eval formatting magic with "%s" printf formatters (safer and
> gets rid of quoting issues in the callers).
This one actually made me think twice about safety, as we'd be using
end-user supplied formatting string without any inspection. I think
it is fine as i
Jeff King writes:
> Here's a re-roll of just the first patch of this series, since that was
> the one that got all the comments (and the others are textually
> independent).
OK, will replace and then queue an adjustment for 6200 which used to
use \$n but now must use %s instead. Let's see if pe
Ævar Arnfjörð Bjarmason writes:
> This v3 has a new patch (3/10) that I believe fixes the regression on
> MinGW Johannes noted in
> https://public-inbox.org/git/nycvar.qro.7.76.6.1907011515150...@tvgsbejvaqbjf.bet/
>
> As noted in the updated commit message in 10/10 I believe just
> skipping thi
On Mon, Jul 01 2019, Johannes Schindelin wrote:
> Hi Junio & Ævar,
>
> On Fri, 28 Jun 2019, Junio C Hamano wrote:
>
>> * ab/no-kwset (2019-06-28) 9 commits
>> - grep: use PCRE v2 for optimized fixed-string search
>> - grep: remove the kwset optimization
>> - grep: drop support for \0 in --fix
Change "-f " to not support patterns with a NUL-byte in them
under --fixed-strings. We'll now only support these under
"--perl-regexp" with PCRE v2.
A previous change to grep's documentation changed the description of
"-f " to be vague enough as to not promise that this would work.
By dropping sup
Bring back optimized fixed-string search for "grep", this time with
PCRE v2 as an optional backend. As noted in [1] with kwset we were
slower than PCRE v1 and v2 JIT with the kwset backend, so that
optimization was counterproductive.
This brings back the optimization for "--fixed-strings", without
A later change will replace this optimization with optimistic use of
PCRE v2. I'm completely removing it as an intermediate step, as
opposed to replacing it with PCRE v2, to demonstrate that no grep
semantics depend on this (or any other) optimization for the fixed
backend anymore.
For now this is
In 5212f91deb ("t4210: skip command-line encoding tests on mingw",
2014-07-17) the positive tests in this file were skipped. That left
the negative tests that don't produce a match.
An upcoming change to migrate the "fixed" backend of grep to PCRE v2
will cause these "log" commands to produce an e
Since e944d9d932 ("grep: rewrite an if/else condition to avoid
duplicate expression", 2016-06-25) the "ascii_only" variable has only
been used once in compile_regexp(), let's just inline it there.
This makes the code easier to read, and might make it marginally
faster depending on compiler optimiz
Improve the tests added in 04deccda11 ("log: re-encode commit messages
before grepping", 2013-02-11) to test the regex backends. Those tests
never worked as advertised, due to the is_fixed() optimization in
grep.c (which was in place at the time), and the needle in the tests
being a fixed string.
Fix a bug introduced in 18547aacf5 ("grep/pcre: support utf-8",
2016-06-25) that was missed due to a blindspot in our tests, as
discussed in the previous commit. I then blindly copied the same bug
in 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) when
adding the PCRE v2 code.
We should n
Move the "grep binary" test case added in aca20dd558 ("grep: add test
script for binary file handling", 2010-05-22) so that it lives
alongside the rest of the "grep" tests in t781*. This would have left
a gap in the t/700* namespace, so move a "filter-branch" test down,
leaving the "t7010-setup.sh"
The behavior of "grep" when patterns contained a NUL-byte has always
been haphazard, and has served the vagaries of the implementation more
than anything else. A pattern containing a NUL-byte can only be
provided via "-f ". Since pickaxe (log search) has no such flag
the NUL-byte in patterns has on
Move the tests for "-f " where "" contains a NUL byte
pattern into their own file. I added most of these tests in
966be95549 ("grep: add tests to fix blind spots with \0 patterns",
2017-05-20).
Whether a regex engine supports matching binary content is very
different from whether it matches binary
This v3 has a new patch (3/10) that I believe fixes the regression on
MinGW Johannes noted in
https://public-inbox.org/git/nycvar.qro.7.76.6.1907011515150...@tvgsbejvaqbjf.bet/
As noted in the updated commit message in 10/10 I believe just
skipping this test & documenting this in a commit message
> > You can right now give meta data of your choice with --push-option to
> > the push command. The Gerrit system makes use of that already. However,
> > this would not be intrinsic to Git, but the serve needs to react on
> > those options. And it should be in good company with suitable client
> >
"Phillip Wood via GitGitGadget" writes:
> progress output before comparing it to the expected output. We do this
> by removing everything before the final "\r" on each line as we don't
> care about the progress indicator, but we do care about what is printed
> immediately after it.
As long as se
> > [Overly long lines are not appreciated around here.]
Thanks for the feedback, is there an email client or tool
that can format the lines correctly?
> >
> > > We would like to track parent branches so that creating pull
> > > requests can automatically determine the correct branch to merge
> >
On Mon, Jul 1, 2019 at 12:51 PM Junio C Hamano wrote:
>
>
> That part is understandable, but is "rebase-and-squash" a tool
> intended to be used by the contributor to respond to that request?
>
> Wouldn't the developer just do
>
> git checkout topic
> git fetch
> git rebase
On Mon, Jul 01, 2019 at 12:48:16PM -0700, Bryan Turner wrote:
> Since branches are ephemeral names and have no intrinsic metadata of
> their own (unlike, say, annotated tags or commits), I suspect
> implementing something like this may be more complicated than it might
> initially appear, especiall
Demonstrate how filter specs can be used when performing a revision walk
of all object types. In this case, tree depth is used. Contributors who
are following the revision walking tutorial will be encouraged to run
the revision walk with and without the filter in order to compare the
number of obje
In order to demonstrate how to create grep filters for revision walks,
filter the walk performed by cmd_walken() to print only commits which
are authored by someone with a gmail address.
This commit demonstrates how to append a grep pattern to a
rev_info.grep_filter, to teach new contributors how
`struct rev_info` is what's used by the walk itself.
`repo_init_revisions()` initializes the struct; then we need to set it
up for the walk we want to perform, which is done in
`final_rev_info_setup()`.
The most important step here is adding the first object we want to walk
to the pending array. H
Add the final steps needed and implement the walk loop itself. We add a
method walken_commit_walk() which performs the final setup to revision.c
and then iterates over commits from get_revision().
This basic walk only prints the subject line of each commit in the
history. It is nearly equivalent t
It may be illuminating to see which objects were not included within a
given filter. This also demonstrates, since filter-spec "tree:1" is
used, that the 'omitted' list contains all objects which are omitted,
not just the first objects which were omitted - that is, it continues to
dereference omitt
For now, we have no configuration options we want to set up for
ourselves, but in the future we may need to. At the very least, we
should invoke git_default_config() for each config option; we will do so
inside of a skeleton config callback so that we know where to add
configuration handling later
Demonstrate that just like commit walks, object walks can have their
order reversed. Additionally, add verbose logging of objects encountered
in order to let contributors prove to themselves that the walk has
actually been reversed. With this commit, `git walken` becomes extremely
chatty - it's rec
The final installment in the tutorial about sorting revision walk
outputs. This commit reverses the commit list, so that we see newer
commits last (handy since we aren't using a pager).
Signed-off-by: Emily Shaffer
---
builtin/walken.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/built
Provide a demonstration of a revision walk which traverses all types of
object, not just commits. This type of revision walk is used for
operations such as creating packfiles and performing fetches or clones,
so it's useful to teach new developers how it works. For starters, only
demonstrate the un
Since v2, mostly reworded comments, plus fixed the issues mentioned in
the tutorial itself. Thanks Eric for the review.
Emily Shaffer (13):
walken: add infrastructure for revwalk demo
walken: add usage to enable -h
walken: add placeholder to initialize defaults
walken: add handler to git_c
Begin to add scaffolding for `git walken`, a toy command which we will
teach to perform a number of revision walks, in order to demonstrate the
mechanics of revision walking for developers new to the Git project.
This commit is the beginning of an educational series which correspond
to the tutoria
Eventually, we will want a good place to initialize default variables
for use during our revision walk(s) in `git walken`. For now, there's
nothing to do here, but let's add the scaffolding so that it's easy to
tell where to put the setup later on.
Signed-off-by: Emily Shaffer
---
builtin/walken
It's expected that Git commands support '-h' in order to provide a
consistent user experience (and this expectation is enforced by the
test suite). '-h' is captured by parse_options() by default; in order to
support this flag, we add a short usage text to walken.c and invoke
parse_options().
With
Order the revision walk by author or commit dates to demonstrate how to
apply topo_sort to a revision walk.
While following the tutorial, new contributors are guided to run a walk
with each sort and compare the results.
Signed-off-by: Emily Shaffer
Change-Id: I7ce2f3e8a77c42001293637ae209087afec
Existing documentation on revision walks seems to be primarily intended
as a reference for those already familiar with the procedure. This
tutorial attempts to give an entry-level guide to a couple of bare-bones
revision walks so that new Git contributors can learn the concepts
without having to wa
On July 1, 2019 3:48 PM, Bryan Turner wrote:
On Mon, Jul 1, 2019 at 12:35 PM Junio C Hamano wrote:
>
> Eric Kulcyk writes:
>
> [Overly long lines are not appreciated around here.]
>
> > We would like to track parent branches so that creating pull
> > requests can automatically determine the corr
On Mon, Jul 1, 2019 at 12:35 PM Junio C Hamano wrote:
>
> Eric Kulcyk writes:
>
> [Overly long lines are not appreciated around here.]
>
> > We would like to track parent branches so that creating pull
> > requests can automatically determine the correct branch to merge
> > against. I understand
Eric Kulcyk writes:
[Overly long lines are not appreciated around here.]
> We would like to track parent branches so that creating pull
> requests can automatically determine the correct branch to merge
> against. I understand that this would require tracking more
> information than is currentl
Andreas Schwab writes:
> On Jun 30 2019, Johannes Sixt wrote:
>
>> diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh
>> index 79bfaeafa9..4b4d06a1c8 100755
>> --- a/t/t5319-multi-pack-index.sh
>> +++ b/t/t5319-multi-pack-index.sh
>> @@ -443,7 +443,7 @@ test_expect_success 'r
On Thu, Jun 27, 2019 at 08:48:31PM -0400, Eric Sunshine wrote:
> On Thu, Jun 27, 2019 at 6:31 PM Emily Shaffer wrote:
> > On Thu, Jun 27, 2019 at 01:37:58AM -0400, Eric Sunshine wrote:
> > > Don't localize the die() message via _() here or in the preceding
> > > OBJ_COMMIT case.
> >
> > I'm a litt
Edmundo Carmona Antoranz writes:
> Hmm... I as a gatekeeper would rather get either a straight line of
> revisions for a feature with no merges (even if a final merge takes
> care of solving conflicts with the upstream branch) or a single
> revision (if I thought that the change is not worth havi
Hello,
We would like to track parent branches so that creating pull requests can
automatically determine the correct branch to merge against. I understand that
this would require tracking more information than is currently available right
now in git. Also, it seems that if some cases, it is n
On 7/1/2019 2:22 PM, Johannes Sixt wrote:
> Am 01.07.19 um 14:30 schrieb Derrick Stolee:
>> On 7/1/2019 8:11 AM, Johannes Schindelin wrote:
>>> Or we stop introducing new Perl calls, and use the perfectly fine
>>> `test-tool path-utils file-size` command:
>>>
>>> https://github.com/git/git/blob/v2.
Jeff King writes:
>> First, we create a (temporary) merge commit of both branches (M3)
>>
>>
>> R1---R2---R3---R4---R5---R6---R7---M3
>> \ \ \ /
>>F1---F2---M1---F3---F4---M2---F5
>>
>>
>> At this point, all differences bet
Am 01.07.19 um 14:30 schrieb Derrick Stolee:
> On 7/1/2019 8:11 AM, Johannes Schindelin wrote:
>> Or we stop introducing new Perl calls, and use the perfectly fine
>> `test-tool path-utils file-size` command:
>>
>> https://github.com/git/git/blob/v2.22.0/t/helper/test-path-utils.c#L302-L312
>>
>> T
Eric Wong writes:
> Ævar Arnfjörð Bjarmason wrote:
>> I have the feedback I posted before this patch in
>> https://public-inbox.org/git/874l4f8h4c@evledraar.gmail.com/
>>
>> In particular "b" there since "a" is clearly more work. I.e. shouldn't
>> we at least in interactive mode on a "gc" p
On Sun, Jun 30, 2019 at 8:01 AM Lars Schneider wrote:
> > On Jun 24, 2019, at 5:33 AM, Elijah Newren wrote:
> >
> > On Mon, Jun 24, 2019 at 5:05 AM Lars Schneider
> > wrote:
> >>
> >> Hi folks,
> >>
> >> Is my understanding correct, that `git fast-export | git fast-import`
> >> should not modif
On 7/1/19 12:29 PM, Junio C Hamano wrote:
Barret Rhoden writes:
On 6/28/19 2:24 AM, Jeff King wrote:
On Wed, Jun 26, 2019 at 03:29:29PM -0700, Junio C Hamano wrote:
* br/blame-ignore (2019-06-20) 9 commits
- blame: add a test to cover blame_coalesce()
- blame: use the fingerprint heur
On Sun, Jun 30, 2019 at 12:28 PM Johannes Sixt wrote:
>
> Am 30.06.19 um 15:05 schrieb Lars Schneider:
> >> On Jun 24, 2019, at 11:58 AM, Jeff King wrote:
> >> You'd have to split the renames into separate delete/adds, since they
> >> can have a circular dependency. E.g. renaming "foo" to "bar" a
SZEDER Gábor writes:
>> I recall the discussion around the meaning of `-C ""` when that
>> command line option was introduced. The conclusion was that the
>> zero-length argument should mean "this directory" since that's how `cd
>> ""` behaves. However, I don't think that behavior ever got docum
On Jun 30 2019, Johannes Sixt wrote:
> diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh
> index 79bfaeafa9..4b4d06a1c8 100755
> --- a/t/t5319-multi-pack-index.sh
> +++ b/t/t5319-multi-pack-index.sh
> @@ -443,7 +443,7 @@ test_expect_success 'repack with minimum size does not
Hi Peff,
On Mon, Jul 01, 2019 at 09:17:13AM -0400, Jeff King wrote:
> On Mon, Jul 01, 2019 at 08:59:45AM -0400, Jeff King wrote:
>
> > Yes, this is weakening the ties of the feature to the transport code.
> > Traditionally transport-oriented code was the only user, but it also
> > used the upload-
Johannes Schindelin writes:
> Hi Junio & Ævar,
>
> On Fri, 28 Jun 2019, Junio C Hamano wrote:
>
>> * ab/no-kwset (2019-06-28) 9 commits
>> - grep: use PCRE v2 for optimized fixed-string search
>> - grep: remove the kwset optimization
>> - grep: drop support for \0 in --fixed-strings
>> - gre
Barret Rhoden writes:
> On 6/28/19 2:24 AM, Jeff King wrote:
>> On Wed, Jun 26, 2019 at 03:29:29PM -0700, Junio C Hamano wrote:
>>
>>> * br/blame-ignore (2019-06-20) 9 commits
>>> - blame: add a test to cover blame_coalesce()
>>> - blame: use the fingerprint heuristic to match ignored lines
>
Taylor Blau writes:
> Hi Junio,
>
> On Fri, Jun 28, 2019 at 03:17:42PM -0700, Junio C Hamano wrote:
>> * tb/ref-filter-multiple-patterns (2019-06-27) 1 commit
>> - ref-filter.c: find disjoint pattern prefixes
>>
>> "git for-each-ref" with multiple patterns have been optimized.
>>
>> Will merge
Rohit Ashiwal writes:
> On Fri, 28 Jun 2019 15:17:42 -0700 Junio C Hamano wrote:
>>
>> [...]
>> * ra/cherry-pick-revert-skip (2019-06-24) 6 commits
>> - cherry-pick/revert: advise using --skip
>> - cherry-pick/revert: add --skip option
>> - sequencer: use argv_array in reset_merge
>> - seque
On Fri, Jun 28, 2019 at 03:17:42PM -0700, Junio C Hamano wrote:
> * jk/check-connected-with-alternates (2019-06-28) 1 commit
> - check_connected: assume alternate ref tips are valid
>
> The tips of refs from the alternate object store can be used as
> starting point for reachability computation
Hi Junio,
On Fri, Jun 28, 2019 at 03:17:42PM -0700, Junio C Hamano wrote:
> * tb/ref-filter-multiple-patterns (2019-06-27) 1 commit
> - ref-filter.c: find disjoint pattern prefixes
>
> "git for-each-ref" with multiple patterns have been optimized.
>
> Will merge to 'next'.
Thanks for queueing
Hi Junio
On Fri, 28 Jun 2019 15:17:42 -0700 Junio C Hamano wrote:
>
> [...]
> * ra/cherry-pick-revert-skip (2019-06-24) 6 commits
> - cherry-pick/revert: advise using --skip
> - cherry-pick/revert: add --skip option
> - sequencer: use argv_array in reset_merge
> - sequencer: rename reset_for_
Hi Jacob,
On Thu, Jun 27, 2019 at 04:21:57PM -0700, Jacob Keller wrote:
> On Wed, Jun 26, 2019 at 3:44 PM Taylor Blau wrote:
> >
>
> Ok, now I've got some time to look at the code itself.
>
> > ref-filter.c| 89 +
> > t/t6300-for-each-ref.sh |
This commit integrates the fuzzy fingerprint heuristic into
guess_line_blames().
We actually make two passes. The first pass uses the fuzzy algorithm to
find a match within the current diff chunk. If that fails, the second
pass searches the entire parent file for the best match.
For an example
Signed-off-by: Barret Rhoden
---
t/t8003-blame-corner-cases.sh | 36 +++
1 file changed, 36 insertions(+)
diff --git a/t/t8003-blame-corner-cases.sh b/t/t8003-blame-corner-cases.sh
index c92a47b6d5b1..1c5fb1d1f8c9 100755
--- a/t/t8003-blame-corner-cases.sh
+++ b/t
fill_blame_origin() is a convenient place to store data that we will use
throughout the lifetime of a blame_origin. Some heuristics for
ignoring commits during a blame session can make use of this storage.
In particular, we will calculate a fingerprint for each line of a file
for blame_origins inv
From: Michael Platings
This algorithm will replace the heuristic used to identify lines from
ignored commits with one that finds likely candidate lines in the
parent's version of the file. The actual replacement occurs in an
upcoming commit.
The old heuristic simply assigned lines in the target
When ignoring commits, the commit that is blamed might not be
responsible for the change, due to the inaccuracy of our heuristic.
Users might want to know when a particular line has a potentially
inaccurate blame.
Furthermore, guess_line_blames() may fail to find any parent commit for
a given line
Commits that make formatting changes or function renames are often not
interesting when blaming a file. A user may deem such a commit as 'not
interesting' and want to ignore and its changes it when assigning blame.
For example, say a file has the following git history / rev-list:
---O---A---X---
The same code for splitting a blame_entry at a particular line was used
twice in blame_chunk(), and I'll use the helper again in an upcoming
patch.
Signed-off-by: Barret Rhoden
---
blame.c | 44
1 file changed, 28 insertions(+), 16 deletions(-)
diff
Signed-off-by: Barret Rhoden
---
fsck.c | 35 ---
oidset.c | 35 +++
oidset.h | 8
3 files changed, 43 insertions(+), 35 deletions(-)
diff --git a/fsck.c b/fsck.c
index a28cba6b05dd..58ff3c4de992 100644
--- a/fsck.c
+++
init_skiplist() took a file consisting of SHA-1s and comments and added
the objects to an oidset. This functionality is useful for other
commands and will be moved to oidset.c in a future commit.
In preparation for that move, this commit renames it to
oidset_parse_file() to reflect its more gener
This patch set adds the ability to ignore a set of commits and their
changes when blaming. This can be used to ignore a commit deemed 'not
interesting,' such as reformatting.
v9 -> v10
v9: https://public-inbox.org/git/20190620163820.231316-1-b...@google.com
- Fixed left-over unused variables
- Re
On 26/06/2019 09:57, Phillip Wood wrote:
On 25/06/2019 21:44, Junio C Hamano wrote:
"Phillip Wood via GitGitGadget" writes:
From: Phillip Wood
commit 4a72486de9 ("fix cherry-pick/revert status after commit",
2019-04-16) used parse_insn_line() to parse the first line of the todo
list to chec
Hi Jacob,
On Wed, Jun 26, 2019 at 05:37:42PM -0700, Jacob Keller wrote:
> [ ... ]
>
> > Instead, we want to partition the patterns into disjoint sets, where we
> > know that no ref will be matched by any two patterns in different sets.
> > In the above, these are:
> >
> > - {'refs/heads/a/*', 'r
Here is a second run at this RFC, which aims to create a "meta" config
setting that automatically turns on other settings according to a user's
willingness to trade new Git behavior or new feature risk for performance
benefits. The new name for the setting is "core.featureAdoptionRate" and is
an in
From: Derrick Stolee
If a repo is large, it likely has many paths in its working directory.
This means the index could be compressed using version 4. Set this as
a default when core.featureAdoptionRate is at least three.
Since the index version is written to a file, this is an excellent
opportun
From: Derrick Stolee
Several advanced config settings are highly recommended for clients
using large repositories. Power users learn these one-by-one and
enable them as they see fit. This could be made simpler, to allow
more users to have access to these almost-always beneficial features
(and mor
From: Derrick Stolee
If a repo is large, then it probably has a very large working
directory. In this case, a typical developer's edits usually impact
many fewer paths than the full path set. The sparse treewalk
algorithm is optimized for this case, speeding up 'git push' calls.
Use pack.useSpar
From: Phillip Wood
If the user commits or resets a conflict resolution in the middle of a
sequence of cherry-picks or reverts then CHERRY_PICK_HEAD/REVERT_HEAD
will be removed and so in the absence of those files we need to check
.git/sequencer/todo to see if there is a cherry-pick or revert in
p
Fix the detection of in-progress cherry-picks and reverts when the user
commits or resets a conflict resolution in the middle of a sequence of
picks/reverts.
Phillip Wood (1):
git-prompt: improve cherry-pick/revert detection
contrib/completion/git-prompt.sh | 37 ---
I'll squash this fix in for v10.
On 6/30/19 2:17 PM, mich...@platin.gs wrote:
From: Michael Platings
Signed-off-by: Michael Platings
---
t/t8014-blame-ignore-fuzzy.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t8014-blame-ignore-fuzzy.sh b/t/t8014-bl
On 6/28/19 2:24 AM, Jeff King wrote:
On Wed, Jun 26, 2019 at 03:29:29PM -0700, Junio C Hamano wrote:
* br/blame-ignore (2019-06-20) 9 commits
- blame: add a test to cover blame_coalesce()
- blame: use the fingerprint heuristic to match ignored lines
- blame: add a fingerprint heuristic to
On 7/1/2019 9:17 AM, Jeff King wrote:
> There's nothing inherently transport-related about enumerating the
> alternate ref tips. The code has lived in transport.[ch] because the
> only use so far had been advertising available tips during transport.
> But it could be used for more, and a future pat
When we receive a remote ref update to sha1 "X", we want to check that
we have all of the objects needed by "X". We can assume that our
repository is not currently corrupted, and therefore if we have a ref
pointing at "Y", we have all of its objects. So we can stop our
traversal from "X" as soon as
There's nothing inherently transport-related about enumerating the
alternate ref tips. The code has lived in transport.[ch] because the
only use so far had been advertising available tips during transport.
But it could be used for more, and a future patch will teach rev-list to
access these refs.
On Mon, Jul 01, 2019 at 08:59:45AM -0400, Jeff King wrote:
> Yes, this is weakening the ties of the feature to the transport code.
> Traditionally transport-oriented code was the only user, but it also
> used the upload-pack transport under the hood to access the alternate
> (that was changed a wh
Thanks to Johannes Sixt for reporting this bug and Dscho for presenting the
correct test-tool to use.
This applies on ds/midx-expire-repack. If we instead want to squash this
into that branch, the two hunks will need to be squashed into these commits:
THIRD_SMALLEST_SIZE applies to ce1e4a105b4 (m
From: Derrick Stolee
Using 'ls -l' and parsing the columns to find file sizes is
problematic when the platform could report the owner as a name
with spaces. Instead, use the 'test-tool path-utils file-size'
command to list only the sizes.
Reported-by: Johannes Sixt
Helped-by: Johannes Schindeli
Hi Junio & Ævar,
On Fri, 28 Jun 2019, Junio C Hamano wrote:
> * ab/no-kwset (2019-06-28) 9 commits
> - grep: use PCRE v2 for optimized fixed-string search
> - grep: remove the kwset optimization
> - grep: drop support for \0 in --fixed-strings
> - grep: make the behavior for NUL-byte in patt
From: Phillip Wood
Some of the tests check the output of rebase is what we expect. These
were added after a regression that added unwanted stash output when
using --autostash. They are useful as they prevent unintended changes to
the output of the various rebase commands. However they also includ
Remove ugliness in the tests that check the output of git rebase
Based-On: sg/rebase-progress Cc: SZEDER Gábor szeder@gmail.com
[szeder@gmail.com]
Phillip Wood (1):
t3420: remove progress lines before comparing output
t/t3420-rebase-autostash.sh | 16 +---
1 file changed,
On Mon, Jul 01, 2019 at 08:25:09AM -0400, Derrick Stolee wrote:
> > I'm not sure what you have in mind, exactly. If you are asking whether
> > there are more places that alternate refs could be used, I can't think
> > of any. If you are asking whether this is in the wrong place, no, I
> > think it
On Mon, Jul 01, 2019 at 02:11:43PM +0200, Johannes Schindelin wrote:
> Or we stop introducing new Perl calls, and use the perfectly fine
> `test-tool path-utils file-size` command:
>
> https://github.com/git/git/blob/v2.22.0/t/helper/test-path-utils.c#L302-L312
Ah, thanks, I missed that we had a
1 - 100 of 118 matches
Mail list logo
