On Mon, Aug 13, 2018 at 7:46 PM, Stefan Beller wrote:
> On Mon, Aug 13, 2018 at 9:31 AM Jeff King wrote:
>>
>> For the past several years, we've held a Git Contributor Summit as part
>> of the Git Merge conference. I'd like to get opinions from the community
>> to help plan future installments.
On Mon, Aug 13, 2018 at 09:58:42PM -0400, Jeff King wrote:
> > builtin/cat-file.c | 93 +++---
> > 1 file changed, 88 insertions(+), 5 deletions(-)
>
> By the way, your patch seemed damaged (wouldn't apply, and "am -3"
> complained of hand-editing). It
On Mon, Aug 13, 2018 at 07:15:19PM +0200, René Scharfe wrote:
> Getting sidetracked here, but the following patch helps both sides a bit:
>
> -- >8 --
> Subject: [PATCH] cat-file: reuse strbuf in batch_object_write()
>
> Avoid allocating and then releasing memory for constructing the output
>
On Mon, Aug 13, 2018 at 07:15:23PM +0200, René Scharfe wrote:
> Am 11.08.2018 um 22:59 schrieb René Scharfe:
> > If the current oidset implementation is so bad, why not replace it with
> > one based on oid_array? ;-)
> >
> > Intuitively I'd try a hashmap with no payload and open addressing via
>
The 'expect'ed outcome has been taken by running the 'range-diff | decode'.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
t/t3206-range-diff.sh | 39 +++
1 file changed, 39 insertions(+)
diff --git a/t/t3206-range-diff.sh
The order shall be all colors first, then the content, flags at the end.
The colors are in the order of occurrence, i.e. first the color for the
sign and then the color for the rest of the line.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 12 ++--
1 file
Due to the previous condition we know "set_sign != NULL" at that point.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
diff.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index ae131495216..f6df18af913 100644
--- a/diff.c
+++ b/diff.c
@@
As the previous patch made sure we only call emit_line_0 once per line,
we do not need the work around introduced in f7c3b4e2d8c (diff: add an
internal option to dual-color diffs of diffs, 2018-08-13) that would ensure
we'd emit 'diff_line_prefix(o)' just once per line.
By having just one call of
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
t/test-lib-functions.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index 2b2181dca09..be8244c47b5 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@
Rewrite emit_line_0 to have fewer (nested) conditions.
The change in 'emit_line' makes sure that 'first' is never user data,
but always under our control, a sign or special character in the
beginning of the line (or 0, in which case we ignore it).
So from now on, let's pass only a diff marker or
All lines that use emit_line_0 multiple times per line, are combined
into a single call to emit_line_0, making use of the 'set' argument.
We gain a little efficiency here, as we can omit emission of color and
accompanying reset if 'len == 0'.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C
Split the meaning of the `set` parameter that is passed to
emit_line_0()` to separate between the color of the "sign" (i.e.
the diff marker '+', '-' or ' ' that is passed in as the `first`
parameter) and the color of the rest of the line.
This changes the meaning of the `set` parameter to no
This is also avaliable as
git fetch https://github.com/stefanbeller/git sb/range-diff-colors
This applies on top of js/range-diff (a7be92acd9600), this version
* resolves a semantic conflict in the test
(Did range-diff change its output slightly?)
* addressed Johannes feedback, such as
->
On Mon, Aug 13, 2018 at 9:38 AM Jeff Hostetler wrote:
>
>
>
> On 8/10/2018 7:06 PM, Matthew DeVore wrote:
> > Teach list-objects the "tree:none" filter which allows for filtering
> > out all tree and blob objects (unless other objects are explicitly
> > specified by the user). The purpose of this
On Mon, Aug 13, 2018 at 11:29 AM Jonathan Tan wrote:
>
> > - case LOFS_BEGIN_TREE:
> > - assert(obj->type == OBJ_TREE);
> > - /* always include all tree objects */
> > - return LOFR_MARK_SEEN | LOFR_DO_SHOW;
> > -
> > case LOFS_END_TREE:
> >
On Mon, 13 Aug 2018, Junio C Hamano wrote:
> > command. ATM there is no non-interactive (via --patch/--interactive I
> > think it is possible) way to commit selected subset of staged files not
> > from the worktree (as it is done with "git commit file(s)") but from the
> > index.
> Hmph, so
>
Resending this in plain-text mode so that git@vger.kernel.org won't
bounce it. Sorry for those of you receiving this twice.
On Mon, Aug 13, 2018 at 11:20 AM Jonathan Tan wrote:
>
> > In list-objects.c we no longer print a message to stderr if a tree
> > object is missing (quiet_on_missing is
On Mon, Aug 13, 2018 at 5:15 AM Johannes Schindelin
wrote:
>
> Hi Stefan,
>
> On Fri, 10 Aug 2018, Stefan Beller wrote:
>
> > For now just change the signature, we'll reason about the actual
> > change in a follow up patch.
> >
> > Pass 'set_sign' (which is output before the sign) and 'set' which
On Fri, Aug 10, 2018 at 3:34 PM Stefan Beller wrote:
>
> This is also avaliable as
> git fetch https://github.com/stefanbeller/git sb/range-diff-colors
>
> and is a resend of sb/range-diff-colors.
I thought about this series a bit, and I think we would want to break
it up into 2:
* the actual
Am 13.08.2018 um 23:07 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> the mailing list [1], nor on the web interface [2]. The latter shows
>> extra spaces on the context lines of the first hunk, though, which I
>> can't see anywhere else. All the lines look fine in the citation of
>>
e98317508c0 (submodule: ensure core.worktree is set after update,
2018-06-18) was overly aggressive in calling connect_work_tree_and_git_dir
as that ensures both the 'core.worktree' configuration is set as well as
setting up correct gitlink file pointing at the git directory.
We do not need to
This chews off a bit of the shell part of the update command in
git-submodule.sh. When writing the C code, keep in mind that the
submodule--helper part will go away eventually and we want to have
a C function that is able to determine the submodule update strategy,
it as a nicety, make
In a later patch we'll find this method handy.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
builtin/submodule--helper.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
index
The information that is printed for update_submodules in
'submodule--helper update-clone' and consumed by 'git submodule update'
is stored as a string per submodule. This made sense at the time of
48308681b07 (git submodule update: have a dedicated helper for cloning,
2016-02-29), but as we want
The 'mode' variable is not used in cmd_update for its original purpose,
rename it to 'dummy' as it only serves the purpose to abort quickly
documenting this knowledge.
The variable 'stage' is also not used any more in cmd_update, so remove it.
This went unnoticed as first each function used the
Separate the command line parsing from the actual execution of the command
within the repository. For now there is not a lot of execution as
most of it is still in git-submodule.sh.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
builtin/submodule--helper.c | 59
Thanks Brandon for pointing out to use repo_git_path instead of
manually constructing the path.
That is the only change in this resend.
Thanks,
Stefan
Stefan Beller (7):
git-submodule.sh: align error reporting for update mode to use path
git-submodule.sh: rename unused variables
All other error messages in cmd_update are reporting the submodule based
on its path, so let's do that for invalid update modes, too.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Jeff King writes:
> I can buy the argument that it's nice to have some form of profiling
> that works everywhere, even if it's lowest-common-denominator. I just
> wonder if we could be investing effort into tooling around existing
> solutions that will end up more powerful and flexible in the
On Mon, Aug 13, 2018 at 11:22:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > O_APPEND is POSIX and means race-free append. If you mark some call
> > sites with O_APPEND, then that must be the ones that need race-free
> > append. Hence, you would have to go the other route: Mark those call
> >
Ævar Arnfjörð Bjarmason writes:
> O_APPEND in POSIX is race-free only up to PIPE_MAX bytes written at a
> time, which is e.g. 2^12 by default on linux, after that all bets are
> off and the kernel is free to interleave different write calls.
We are only interested in the use of race-safe append
On Mon, Aug 13, 2018 at 02:19:07PM -0700, Stefan Beller wrote:
> However the mailing list participation numbers there doesn't really
> help me:
>
> ~/git-ml$ git shortlog --since 2017 -sne
> 3721 Junio C Hamano
> 2166 Stefan Beller
> 2071 Jeff King
>
> and I certainly do not provide
On Mon, Aug 13, 2018 at 09:52:41PM +0200, Duy Nguyen wrote:
> I don't think I have really fully mastered 'perf'. In this case for
> example, I don't think the default event 'cycles' is the right one
> because we are hit hard by I/O as well. I think at least I now have an
> excuse to try that
Yaroslav Halchenko writes:
> command. ATM there is no non-interactive (via --patch/--interactive I
> think it is possible) way to commit selected subset of staged files not
> from the worktree (as it is done with "git commit file(s)") but from the
> index.
Hmph, so
edit A B C
Commit 88e2f9ed8e ("introduce fetch-object: fetch one promisor object",
2017-12-05) introduced new command-line arguments without documenting
them. Add documentation for these arguments.
Signed-off-by: Jonathan Tan
---
This is a follow-up to [1] in which Junio noticed some arguments lacking
Brandon Williams writes:
> On 08/13, Nguyễn Thái Ngọc Duy wrote:
>> This is the third part of killing the_index (at least outside
>> builtin/). Part 1 [1] is dropped. Part 2 is nd/no-extern on 'pu'. This
>> part is built on top of nd/no-extern.
>>
>> This series would actually break 'pu'
On Mon, Aug 13 2018, Johannes Sixt wrote:
> Am 13.08.2018 um 22:20 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>
>>> The Windows CRT implements O_APPEND "manually": on write() calls, the
>>> file pointer is set to EOF before the data is written. Clearly, this is
>>> not atomic. And in
Hello,
I have updated to the latest master and trying to build git plus its
Info manuals.
I am on RHEL 6.8. It does not have docbook2x-texi, but I was able to
install docbook2texi from https://sourceforge.net/p/docbook2x.
The whole git build goes fine except when it reaches the "make info"
Nguyễn Thái Ngọc Duy writes:
> Make the convert API take an index_state instead of assuming the_index
> in convert.c. All external call sites are converted blindly to keep
> the patch simple and retain current behavior. Individual call sites
> may receive further updates to use the right index
On Mon, Aug 13, 2018 at 2:06 PM Jeff King wrote:
>
> On Mon, Aug 13, 2018 at 01:41:51PM -0700, Stefan Beller wrote:
>
> > > Oh, using "git shortlog" might be also simpler ;-)
> >
> > I guess you'd need to memorize a different set of flags for that
> > as without -s it would be harder to parse
Nguyễn Thái Ngọc Duy writes:
> This puts update_main_cache_tree() and write_cache_as_tree() in the
> same group of "index compat" functions that assume the_index
> implicitly, which should only be used within builtin/ or t/helper.
>
> sequencer.c is also updated to not use these functions. As
René Scharfe writes:
> the mailing list [1], nor on the web interface [2]. The latter shows
> extra spaces on the context lines of the first hunk, though, which I
> can't see anywhere else. All the lines look fine in the citation of
> Ramsay's reply [3]. So I don't know where these extra
On Mon, Aug 13, 2018 at 01:41:51PM -0700, Stefan Beller wrote:
> > Oh, using "git shortlog" might be also simpler ;-)
>
> I guess you'd need to memorize a different set of flags for that
> as without -s it would be harder to parse than the oneliner above.
I frequently using "git shortlog -ns"
Am 13.08.2018 um 22:20 schrieb Junio C Hamano:
Johannes Sixt writes:
The Windows CRT implements O_APPEND "manually": on write() calls, the
file pointer is set to EOF before the data is written. Clearly, this is
not atomic. And in fact, this is the root cause of failures observed in
On 08/13, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 13 Aug 2018, Johannes Schindelin via GitGitGadget wrote:
>
> > The incredibly useful git-tbdiff [https://github.com/trast/tbdiff] tool to
> > compare patch series (say, to see what changed between two iterations sent
> > to the Git mailing
Hi Duy,
Le 13/08/2018 à 18:06, Duy Nguyen a écrit :
> On Fri, Aug 10, 2018 at 6:54 PM Alban Gruin wrote:
> > This patch series rewrite the interactive rebase from shell to C.
>
> I was running some tests on 'pu' and ran git-rebase--interactive
> without arguments because a test failed and I was
On Mon, Aug 13, 2018 at 1:36 PM Junio C Hamano wrote:
>
> Ævar Arnfjörð Bjarmason writes:
>
> >Or would those companies be OK with trusting that some 20-ish of us
> >can hold our tongues for one day and not ruin the surprise?
> >
> >There's also overlap with the remote A/V concerns
Ævar Arnfjörð Bjarmason writes:
>Or would those companies be OK with trusting that some 20-ish of us
>can hold our tongues for one day and not ruin the surprise?
>
>There's also overlap with the remote A/V concerns there. I.e. an
>acceptable compromise for those companies might
On Mon, Aug 13 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> This is unchanged from what's been cooking in pu for months now, so
>> hopefully it can be merged down faster than most, and then I can later
>> submit the actual meat of this series once I fix the (mostly doc)
Ævar Arnfjörð Bjarmason writes:
> This is unchanged from what's been cooking in pu for months now, so
> hopefully it can be merged down faster than most, and then I can later
> submit the actual meat of this series once I fix the (mostly doc)
> issues with it.
They have been held in 'pu' only
On Tue, Aug 7, 2018 at 6:49 PM Elijah Newren wrote:
> Since folks like to notice other problems with t7406 while reading my
> patches, here's a challenge:
>
> Find something *else* wrong with t7406 that neither I nor any of the
> reviewers so far have caught that could be fixed.
Well, I'd
Am 13.08.2018 um 20:43 schrieb Junio C Hamano:
René Scharfe writes:
@@ -182,19 +181,10 @@ static int fsck_msg_type(enum fsck_msg_id msg_id,
static void init_skiplist(struct fsck_options *options, const char
*path)
{
- static struct oid_array skiplist = OID_ARRAY_INIT;
- int
Johannes Sixt writes:
> The Windows CRT implements O_APPEND "manually": on write() calls, the
> file pointer is set to EOF before the data is written. Clearly, this is
> not atomic. And in fact, this is the root cause of failures observed in
> t5552-skipping-fetch-negotiator.sh and
On Mon, Aug 13, 2018 at 3:27 PM Junio C Hamano wrote:
> Eric Sunshine writes:
>
> > A here-doc tag can be quoted ('EOF') or escaped (\EOF) to suppress
> > interpolation within the body. Although, chainlint recognizes escaped
> > tags, it does not know about quoted tags. For completeness, teach
On 8/13/2018 3:36 PM, Stefan Beller wrote:
On Mon, Aug 13, 2018 at 12:25 PM Jeff King wrote:
I can buy the argument that it's nice to have some form of profiling
that works everywhere, even if it's lowest-common-denominator. I just
wonder if we could be investing effort into tooling around
On Mon, Aug 13, 2018 at 9:25 PM Jeff King wrote:
> Am I the only one who feels a little funny about us sprinkling these
> performance probes through the code base?
>
> On Linux, "perf" already does a great job of this without having to
> modify the source, and there are tools like:
>
>
On Mon, Aug 13, 2018 at 08:49:33PM +0200, Ævar Arnfjörð Bjarmason wrote:
> * I think we should tread carefully when it comes to say some form of
>remote A/V participation open to the Internet.
>
>It was fine to have Dscho on a chair, but it would be quite different
>if this were say
On Mon, Aug 13, 2018 at 12:25 PM Jeff King wrote:
> I can buy the argument that it's nice to have some form of profiling
> that works everywhere, even if it's lowest-common-denominator. I just
> wonder if we could be investing effort into tooling around existing
> solutions that will end up more
Eric Sunshine writes:
> A here-doc tag can be quoted ('EOF') or escaped (\EOF) to suppress
> interpolation within the body. Although, chainlint recognizes escaped
> tags, it does not know about quoted tags. For completeness, teach it to
> recognize quoted tags, as well.
Is this step merely
On Sun, Aug 12, 2018 at 10:15:48AM +0200, Nguyễn Thái Ngọc Duy wrote:
> We're going to optimize unpack_trees() a bit in the following
> patches. Let's add some tracing to measure how long it takes before
> and after. This is the baseline ("git checkout -" on webkit.git, 275k
> files on worktree)
Change the test that asserts that lightweight tags can only be
clobbered by a force-push to check do the same tests for annotated
tags.
There used to be less exhaustive tests for this with the code added in
40eff17999 ("push: require force for annotated tags", 2012-11-29), but
Junio removed them
Calling the test tag "Tag" will make for confusing reading later in
this series when making use of the "git push tag "
feature. Let's call the tag testTag instead.
Changes code initially added in dbfeddb12e ("push: require force for
refs under refs/tags/", 2012-11-29).
Signed-off-by: Ævar
Correct a comment referring to the removal of just the branch to also
refer to the tag. This should have been changed in my
ca3065e7e7 ("fetch tests: add a tag to be deleted to the pruning
tests", 2018-02-09) when the tag deletion was added, but I missed it
at the time.
Signed-off-by: Ævar
It should be "is not an empty string" not "is not empty string". This
fixes wording originally introduced in ab9b31386b ("Documentation:
multi-head fetch.", 2005-08-24).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/pull-fetch-param.txt | 2 +-
1 file changed, 1 insertion(+), 1
Improve the tests added in dbfeddb12e ("push: require force for refs
under refs/tags/", 2012-11-29) to assert that the same behavior
applies various other combinations of command-line option and
refspecs.
Supplying either "+" in refspec or "--force" is sufficient to clobber
the reference. With
Remove an invocation of 'git push' that's exactly the same as the one
on the preceding line. This was seemingly added by mistake in
dbfeddb12e ("push: require force for refs under refs/tags/",
2012-11-29) and doesn't affect the result of the test, the second
"push" was a no-op as there was nothing
Fix a logic error that's been here since this test was added in
dbfeddb12e ("push: require force for refs under refs/tags/",
2012-11-29).
The intent of this test is to force-create a new tag pointing to
HEAD~, and then assert that pushing it doesn't work without --force.
Instead, the code was
I have not had time to re-submit a v2 of my patch series to make "+"
meaningful in refspecs when it comes to tags, see v2 here:
https://public-inbox.org/git/20180731130718.25222-1-ava...@gmail.com/
Given where we're at with the 2.19 release I'd like to propose this
shortened version for inclusion
Samuel Maftoul writes:
> I'm still missing tests and docs, but if agreed the feature is useful,
> I will write them.
I personally think branch.sort would have about the same value as
the existing tag.sort, so if a patch is done well, it is likely that
users would find it valuable, but let's
Nicholas Guriev writes:
> This eliminates an unnecessary prompt to continue after failed merger.
> The patch uses positional parameters to count files in the list. If only
> one iteration is remained, the prompt_after_failed_merge function is not
s/is remained/remains/, I think.
Other than
SZEDER Gábor writes:
> - echo $(git -C repo log --pretty="%ct" -1) \
> - $(git -C repo rev-parse one) >expect &&
> + {
> + git -C repo log --pretty=format:"%ct " -1 &&
> + git -C repo rev-parse one
> + } >expect &&
Heh, "format:"%ct " to make the
The Windows CRT implements O_APPEND "manually": on write() calls, the
file pointer is set to EOF before the data is written. Clearly, this is
not atomic. And in fact, this is the root cause of failures observed in
t5552-skipping-fetch-negotiator.sh and t5503-tagfollow.sh, where
different processes
Nguyễn Thái Ngọc Duy writes:
> v4 has a bunch of changes
>
> - 1/5 is a new one to show indented tracing. This way it's less
> misleading to read nested time measurements
> - 3/5 now has the switch/restore cache_bottom logic. Junio suggested a
> check instead in his final note, but I think
On Mon, Aug 13, 2018 at 5:26 AM Johannes Schindelin
wrote:
>
> Hi,
>
>
> On Fri, 10 Aug 2018, Stefan Beller wrote:
>
> > Signed-off-by: Stefan Beller
> > Signed-off-by: Junio C Hamano
>
> Well, my rationale for having the explicit `reverse` parameter is: this
> code is complex enough,
On Mon, Aug 13, 2018 at 05:33:59AM +0200, Christian Couder wrote:
> >> + memcpy(_core, oid->hash, sizeof(uint64_t));
> >> + rl->hash += sha_core;
> >
> > Hmm, so the first 64-bits of the oid of each ref that is part of
> > this island is added together as a 'hash' for the island. And this
On 8/12/2018 4:15 AM, Nguyễn Thái Ngọc Duy wrote:
In order to merge one or many trees with the index, unpack-trees code
walks multiple trees in parallel with the index and performs n-way
merge. If we find out at start of a directory that all trees are the
same (by comparing OID) and
On Mon, Aug 13, 2018 at 5:42 AM Johannes Schindelin
wrote:
>
> Hi Stefan,
>
> On Fri, 10 Aug 2018, Stefan Beller wrote:
>
> > emit_line_0 has no nested conditions, but puts out all its arguments
> > (if set) in order.
>
> Well, currently `emit_line_0()` *has* nested conditions: `first == '\n'`
>
Thomas Adam writes:
> On Sun, 12 Aug 2018 at 09:19, Nguyễn Thái Ngọc Duy wrote:
>
> Hi,
>
>> + trace_performance_leave("cache_tree_update");
>
> I would suggest trace_performance_leave() calls use __func__ instead.
> That way, there's no ambiguity if the function name ever changes.
On Mon, Aug 13 2018, Jeff King wrote:
> For the past several years, we've held a Git Contributor Summit as part
> of the Git Merge conference. I'd like to get opinions from the community
> to help plan future installments. Any feedback or opinion is welcome,
> but some obvious things to think
> [1/7]: for_each_*_object: store flag definitions in a single location
> [2/7]: for_each_*_object: take flag arguments as enum
> [3/7]: for_each_*_object: give more comprehensive docstrings
> [4/7]: for_each_packed_object: support iterating in pack-order
> [5/7]: t1006: test cat-file
On 8/12/2018 4:15 AM, Nguyễn Thái Ngọc Duy wrote:
We're going to optimize unpack_trees() a bit in the following
patches. Let's add some tracing to measure how long it takes before
and after. This is the baseline ("git checkout -" on webkit.git, 275k
files on worktree)
performance:
René Scharfe writes:
> @@ -182,19 +181,10 @@ static int fsck_msg_type(enum fsck_msg_id msg_id,
> static void init_skiplist(struct fsck_options *options, const char
> *path)
> {
> - static struct oid_array skiplist = OID_ARRAY_INIT;
> - int sorted;
> FILE *fp;
> struct
On Mon, Aug 13, 2018 at 7:17 PM Brandon Williams wrote:
> I'm just sorry I made it this messy :/
Take it with pride! I think all core devs can say "oh yes I've made
big contributions. See there? I made that mess!" :D
--
Duy
On 8/12/2018 4:15 AM, Nguyễn Thái Ngọc Duy wrote:
Performance measurements are listed right now as a flat list, which is
fine when we measure big blocks. But when we start adding more and
more measurements, some of them could be just part of a bigger
measurement and a flat list gives a wrong
> > The later lines that indicate a change to the Makefile will be treated as
> > context both in the outer and inner diff, such that those lines stay
> > regular color.
>
> While I am a fan of having those lines colored correctly, I have to admit
> that I am not exactly enthusiastic about that
On 08/13, Thomas Rast via GitGitGadget wrote:
> From: Thomas Rast
>
> These are essentially lifted from https://github.com/trast/tbdiff, with
> light touch-ups to account for the command now being named `git
> range-diff`.
>
> Apart from renaming `tbdiff` to `range-diff`, only one test case
On Mon, Aug 13, 2018 at 5:05 AM Johannes Schindelin
wrote:
>
> Hi Stefan,
>
> On Fri, 10 Aug 2018, Stefan Beller wrote:
>
> > +test_expect_success 'dual-coloring' '
> > + sed -e "s|^:||" >expect <<-\EOF &&
> > + :1: a4b = 1: f686024 s/5/A/
> > + :2: f51d370 ! 2:
> > 4ab067d
> - case LOFS_BEGIN_TREE:
> - assert(obj->type == OBJ_TREE);
> - /* always include all tree objects */
> - return LOFR_MARK_SEEN | LOFR_DO_SHOW;
> -
> case LOFS_END_TREE:
> assert(obj->type == OBJ_TREE);
> return LOFR_ZERO;
> > strbuf_addbuf(, );
> > + }
>
> My preliminary reading (I sadly lack the time to pull your branch and play
> with it) suggests that this works, although I have to admit that X/Y/Z
> would confuse me in 6 months from now, as they do not really read like
> diff
Jeff King writes:
> The rule in Git has always been that your very first include must
> always be "git-compat-util.h" or an equivalent header that includes it
> first (like "cache.h"). This is mentioned in CodingGuidelines.
Glad to see that you already have written the above so I don't have
to
On Mon, Aug 13, 2018 at 4:47 AM Johannes Schindelin
wrote:
>
> Hi Steafn,
>
> On Fri, 10 Aug 2018, Stefan Beller wrote:
>
> > This will prove useful in range-diff in a later patch as we will be able to
> > differentiate between adding a new file (that line is starting with +++
> > and then the
> In list-objects.c we no longer print a message to stderr if a tree
> object is missing (quiet_on_missing is always true). I couldn't find
> any place where this would matter, or where the caller of
> traverse_commit_list would need to be fixed to show the error. However,
> in the future it would
On Mon, Aug 13, 2018 at 4:42 AM Johannes Schindelin
wrote:
> > +/*
> > + * Emits
> > + * LF
> > + * if they are present. 'first' is a NULL terminated string,
> > + * 'second' is a buffer of length 'len'.
> > + */
>
> That does not make it clear what the role of `first` or `second` is.
frede...@ofb.net writes:
> Hi Jonathan and Git developers,
>
> I poked around today and figured out how to reorder the command
> listings in the manual page, they are taken from git/command-list.txt
> so I just reorder the lines in that file (after disabling sorting in
>
Currently, list-objects.c incorrectly treats all root trees of commits
as USER_GIVEN. Also, it would be easier to mark objects that are
non-user-given instead of user-given, since the places in the code
where we access an object through a reference are more obvious than
the places where we access
Teach list-objects the "tree:0" filter which allows for filtering
out all tree and blob objects (unless other objects are explicitly
specified by the user). The purpose of this patch is to allow smaller
partial clones.
The name of this filter - tree:0 - does not explicitly specify that
it also
Previously, we assumed only blob objects could be missing. This patch
makes rev-list handle missing trees like missing blobs. A missing tree
will cause an error if --missing indicates an error should be caused,
and the hash is printed even if the tree is missing.
In list-objects.c we no longer
This will be used in a follow-up patch to reduce indentation needed when
invoking the logic conditionally. i.e. rather than:
if (foo) {
while (...) {
/* this is very indented */
}
}
we will have:
if (foo)
process_tree_contents(...);
Signed-off-by:
This will make utility functions easier to create, as done by the next
patch.
Signed-off-by: Matthew DeVore
---
list-objects.c | 158 +++--
1 file changed, 74 insertions(+), 84 deletions(-)
diff --git a/list-objects.c b/list-objects.c
index
Applied the following changes suggested by g...@jeffhostetler.com:
- Change the filter name from tree:none to tree:0 to make room for
future improvements which allow filtering based on depth.
- Made a separate filter logic function and filter data struct for
tree:0 rather than share it
1 - 100 of 212 matches
Mail list logo
