* Re: [PATCH v7 1/3] push: add reflog check for "--force-if-includes"
@ 2020-09-27 12:27 6% ` Srinidhi Kaushik
0 siblings, 0 replies; 200+ results
From: Srinidhi Kaushik @ 2020-09-27 12:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
On 09/26/2020 16:42, Junio C Hamano wrote:
> Srinidhi Kaushik <shrinidhi.kaushik@gmail.com> writes:
>
> > @@ -2252,11 +2263,11 @@ int is_empty_cas(const struct push_cas_option *cas)
> > /*
> > * Look at remote.fetch refspec and see if we have a remote
> > * tracking branch for the refname there. Fill its current
> > - * value in sha1[].
> > + * value in sha1[], and as a string.
>
> I think the array being referred to was renamed to oid[] sometime
> ago. "and as a string" makes it sound as if sha1[] gets the value
> as 40-hex object name text, but that is not what is being done.
>
> Fill the name of the remote-tracking branch in *dst_refname,
> and the name of the commit object at tis tip in oid[].
>
> perhaps?
Of course, that sounds better; will update.
> > + * The struct "reflog_commit_list" and related helper functions
> > + * for list manipulation are used for collecting commits into a
> > + * list during reflog traversals in "if_exists_or_grab_until()".
>
> Has the name of that function changed since this comment was
> written?
Heh, it sure has. It should have been "check_and_collect_until()".
> > + */
> > +struct reflog_commit_list {
> > + struct commit **items;
>
> Name an array in singular when its primary use is to work on an
> element at a time---that will let you say item[4] to call the 4-th
> item, instead of items[4] that smells awkward.
>
> An array that is used mostly to pass around a collection as a whole
> is easier to think about when given a plural name, though.
Yup.
> > +
> > +/* Get the timestamp of the latest entry. */
> > +static int peek_reflog(struct object_id *o_oid, struct object_id *n_oid,
> > + const char *ident, timestamp_t timestamp,
> > + int tz, const char *message, void *cb_data)
> > +{
> > + timestamp_t *ts = cb_data;
> > + *ts = timestamp;
> > + return 1;
> > +}
>
> The idea is to use a callback that immediately says "no more" to
> grab the data from the first item in the iteration. It feels
> somewhat awkward but because there is no "give us the Nth entry" API
> function, it is the cleanest way we can do this.
I considered using "grab_1st_entry_timestamp()" briefy, but
"peek_reflog" is shorter compared to that.
> > + /* Look-up the commit and append it to the list. */
> > + if ((commit = lookup_commit_reference(the_repository, n_oid)))
> > + add_commit(cb->local_commits, commit);
>
> This is merely a minor naming thing, but if you rename add_commit()
> to append_commit(), you probably do not even need the comment before
> this statement.
Will do.
> > return 0;
> > }
> >
> > +#define MERGE_BASES_BATCH_SIZE 8
>
> Hmph. Do we still need batching?
>
> > +/*
> > + * Iterate through the reflog of the local ref to check if there is an entry
> > + * for the given remote-tracking ref; runs until the timestamp of an entry is
> > + * older than latest timestamp of remote-tracking ref's reflog. Any commits
> > + * are that seen along the way are collected into a list to check if the
> > + * remote-tracking ref is reachable from any of them.
> > + */
> > +static int is_reachable_in_reflog(const char *local, const struct ref *remote)
> > +{
> > + timestamp_t date;
> > + struct commit *commit;
> > + struct commit **chunk;
> > + struct check_and_collect_until_cb_data cb;
> > + struct reflog_commit_list list = { NULL, 0, 0 };
> > + size_t count = 0, batch_size = 0;
> > + int ret = 0;
> > +
> > + commit = lookup_commit_reference(the_repository, &remote->old_oid);
> > + if (!commit)
> > + goto cleanup_return;
> > +
> > + /*
> > + * Get the timestamp from the latest entry
> > + * of the remote-tracking ref's reflog.
> > + */
> > + for_each_reflog_ent_reverse(remote->tracking_ref, peek_reflog, &date);
> > +
> > + cb.remote_commit = commit;
> > + cb.local_commits = &list;
> > + cb.remote_reflog_timestamp = date;
> > + ret = for_each_reflog_ent_reverse(local, check_and_collect_until, &cb);
> > +
> > + /* We found an entry in the reflog. */
> > + if (ret > 0)
> > + goto cleanup_return;
>
> Good. So '1' from the callback is "we found one, no need to look
> further and no need to do merge-base", and '-1' from the callback is
> "we looked at all entries that are young enough to matter and we
> didn't find exact match". Makes sense.
>
> > + /*
> > + * Check if the remote commit is reachable from any
> > + * of the commits in the collected list, in batches.
> > + */
>
> I do not know if batching would help (have you measured it?), but if
> we were to batch, it is more common to arrange the loop like this:
>
> for (chunk = list.items;
> chunk < list.items + list.nr;
> chunk += size) {
> size = list.items + list.nr - chunk;
> if (MERGE_BASES_BATCH_SIZE < size)
> size = MERGE_BASES_BATCH_SIZE;
> ... use chunk[0..size] ...
> chunk += size;
> }
>
> That is, assume that we can grab everything during this round, and
> if that bites off too many, clamp it to the maximum value. If you
> are not comfortable with pointer arithmetic, it is also fine to use
> an auxiliary variable 'count', but ...
Actually, the "for" version looks much cleaner and avoids the use
of "count". However, I think ...
> chunk += size;
... should be skipped because "for ( ... ; chunk += size)" is already
doing it for us; otherwise we would offset 16 entries instead of 8
per iteration, no?
> > + chunk = list.items;
> > + while (count < list.nr) {
> > + batch_size = MERGE_BASES_BATCH_SIZE;
> > +
> > + /* For any leftover entries. */
> > + if ((count + MERGE_BASES_BATCH_SIZE) > list.nr)
> > + batch_size = list.nr - count;
> > +
> > + if ((ret = in_merge_bases_many(commit, batch_size, chunk)))
> > + break;
> > +
> > + chunk += batch_size;
> > + count += MERGE_BASES_BATCH_SIZE;
>
> ... you are risking chunk and count to go out of sync here.
>
> It does not matter within this loop (count will point beyond the end
> of list.item[] while chunk will never go past the array), but future
> developers can be confused into thinking that they can use chunk and
> count interchangeably after this loop exits, and at that point the
> discrepancy may start to matter.
I agree, it should have been "count += batch_size;". But, I think the
"for" version looks cleaner; I will change it to that the next set.
> But all of the above matters if it is a good idea to batch. Does it
> make a difference?
>
> ... goes and looks at in_merge_bases_many() ...
>
> Ah, it probably would.
>
> I thought in_merge_bases_many() would stop early as soon as any of
> the traversal from chunk[] reaches commit, but it uses a rather more
> generic paint_down_to_common() so extra items in chunk[] that are
> topologically older than commit would result in additional traversal
> from commit down to them, which would not contribute much to the end
> result. It may be a good #leftovebit idea for future improvement to
> teach in_merge_bases_many() to use a custom replacement for
> paint_down_to_common() that stops early as soon as we find the
> answer is true.
If we consider the amount of time it takes when "in_merge_bases_many()"
has to be run for all the entries, there isn't much of a difference in
performance between batching and non-batching -- they took about the
same. But, as you said if the remote is reachable in the first few
entries, batching would help with returning early if a descendant is
found.
Making the function stop early when a descendent is found
does sound like a good #leftoverbits idea. :)
Thanks again, for a detailed review.
--
Srinidhi Kaushik
^ permalink raw reply [relevance 6%]
* Re: [PATCH v6 03/22] cat-file tests: test for missing object with -t and -s
@ 2021-09-16 22:52 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2021-09-16 22:52 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, Junio C Hamano, Jeff King, Jonathan Tan, Andrei Rybak
On Thu, Sep 16 2021, Taylor Blau wrote:
> On Tue, Sep 07, 2021 at 12:57:58PM +0200, Ævar Arnfjörð Bjarmason wrote:
>> Test for what happens when the -t and -s flags are asked to operate on
>> a missing object, this extends tests added in 3e370f9faf0 (t1006: add
>> tests for git cat-file --allow-unknown-type, 2015-05-03). The -t and
>> -s flags are the only ones that can be combined with
>> --allow-unknown-type, so let's test with and without that flag.
>
> I'm a little skeptical to have tests for all four pairs of `-t` or `-s`
> and "with `--allow-unknown-type` and without `--allow-unknown-type`".
>
> Testing both the presence and absence of `--allow-unknown-type` seems
> useful to me, but I'm not sure what testing `-t` and `-s` separately
> buys us.
>
> (If you really feel the need test both, I'd encourage looping like:
Thanks, I'll try to simplify it.
> for arg in -t -s
> do
> test_must_fail git cat-file $arg $missing_oid >out 2>err &&
> test_must_be_empty out &&
> test_cmp expect.err err &&
>
> test_must_fail git cat-file $arg --allow-unknown-type $missing_oid >out 2>err &&
> test_must_be_empty out &&
> test_cmp expect.err err
> done &&
>
> but I would be equally or perhaps even happier to just have one of the
> two tests).
A loop like that can be further simplified as just (just inlining
arg=-s):
test_must_fail git cat-file -s $missing_oid >out 2>err &&
test_must_be_empty out &&
test_cmp expect.err err &&
test_must_fail git cat-file -s --allow-unknown-type $missing_oid >out 2>err &&
test_must_be_empty out &&
test_cmp expect.err err
:)
I.e. unless you end &&-chains in loops in the test framework with an ||
return 1 you're only testing your last iteration. Aside from whatever
I'm doing here I generally prefer to either just spell it out twice (if
small enough), or:
for arg in -t -s
do
test_expect_success '...' "[... use $arg ...]"
done
Which both nicely get around the issue of that easy-to-make mistake.
We've got some in-tree tests that are broken this way, well, at least
4cf67869b2a (list-objects.c: don't segfault for missing cmdline objects,
2018-12-05). But I think I'll leave that for a #leftoverbits submission
given my outstanding patch queue..., oh there's another one in
t1010-mktree.sh ... :)
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/8] ssh test: make copy_ssh_wrapper_as clean up after itself
@ 2017-11-21 1:24 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-11-21 1:24 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Brandon Williams, Stefan Beller, Jonathan Tan, Segev Finer,
Johannes Schindelin
Jonathan Nieder <jrnieder@gmail.com> writes:
> +test_expect_success 'set up ssh wrapper' '
> + cp "$GIT_BUILD_DIR/t/helper/test-fake-ssh$X" \
> + "$TRASH_DIRECTORY/ssh$X" &&
> + GIT_SSH="$TRASH_DIRECTORY/ssh$X" &&
> + export GIT_SSH &&
> + export TRASH_DIRECTORY &&
> + >"$TRASH_DIRECTORY"/ssh-output
> +'
>
> copy_ssh_wrapper_as () {
> cp "$TRASH_DIRECTORY/ssh$X" "${1%$X}$X" &&
> + test_when_finished "rm -f ${1%$X}$X" &&
> GIT_SSH="${1%$X}$X" &&
As we can clearly see in the context, this is not a new issue, but I
find the users of this helper that benefit from the "${1%$X}$X"
magic somewhat iffy.
There are callers of this helper that pass "somedir/plink" and
"somedir/plink.exe", but behind these callers that _think_ they are
testing the variant with and without the trailing ".exe", the helper
always add ".exe" (after stripping an existing one) on $X=.exe
platforms, ending up in testing the same thing twice. On platforms
with $X='', testing two different command names may have "some"
value, but I wonder if it is cleaner to use a much less magical
"$1$X" here, and skip the test with a caller that gives ".exe"
variant using a test prerequisite on $X=.exe platforms to avoid
redundant tests?
This is totally outside the scope of this series; I mention this
only because this may be a possible #leftoverbits.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 1/3] Move init_skiplist() outside of fsck
@ 2019-01-22 9:46 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2019-01-22 9:46 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, Junio C Hamano, Barret Rhoden, git,
David Kastrup, Jeff Smith, René Scharfe, Stefan Beller
On Tue, Jan 22 2019, Jeff King wrote:
> On Fri, Jan 18, 2019 at 11:26:29PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> I stand corrected, I thought these still needed to be updated to parse
>> anything that wasn't 40 chars, since I hadn't seen anything about these
>> formats in the hash transition document.
>>
>> So fair enough, let's change that while we're at it, but this seems like
>> something that needs to be planned for in more detail / documented in
>> the hash transition doc.
>>
>> I.e. many (e.g. me) maintain some system-wide skiplist for strict fsck
>> cloning of legacy repos. So I can see there being some need for a
>> SHA1<->SHA256 map in this case, but since these files might stretch
>> across repo boundaries and not be checked into the repo itself this is a
>> new use-case that needs thinking about.
>
> My assumption had been that changing your local repository would be a
> (local) flag day, and you'd update any ancillary files like skiplists,
> mailmap.blob, etc at the same time. I'm not opposed to making those
> features more clever, though.
>
>> But now that I think about it this sort of thing would be a good
>> use-case for just fixing these various historical fsck issues while
>> we're at it when possible, e.g. "missing space before email" (probably
>> not all could be unambiguously fixed). So instead of sha256<->sha1
>> fn(sha256)<->fn(sha1)[1]?
>
> That is a very tempting thing to do, but I think it comes with its own
> complications. We do not want to do fn(sha1), I don't think; the reason
> we care about sha1 at all is that those hashes are already set in stone.
>
> There could be a "clean up the data as we convert to sha256" operation,
> but:
>
> - it needs to be set in stone from day 1, I'd think. The last thing we
> want is to modify it after conversions are in the wild
>
> - I think we need to be bi-directional. So it must be a mapping that
> can be undone to retrieve the original bytes, so we can compute
> their "real" sha1.
It needing to be bidirectional is a very good point, and I think that
makes my suggestion a non-starter. Thanks.
> At which point, I think it might be simpler to just make git more
> permissive with respect to those minor data errors (and in fact, we are
> already pretty permissive for the most part in non-fsck operations).
Yeah it's probably better to make some of these "errors" softer
warnings.
The X-Y issue I have is that I turned on transfer.fsckObjects, so then I
can't clone repos with various minor historical issues in commit headers
etc., so I maintain a big skip list. But what I was actually after was
fsck checks like the .gitmodules security check.
Of course I could chase them all down and turn them into
warn/error/ignore individually, but it would be better if we e.g. had
some way to say "serious things error, minor things warn", maybe with
the option of only having the looser version on fetch but not recieve
with the principle that we should be loose in what we accept from
existing data but strict with new data #leftoverbits
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 22/22] t7700: stop losing return codes of git commands
@ 2019-11-23 1:49 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2019-11-23 1:49 UTC (permalink / raw)
To: Denton Liu; +Cc: Git Mailing List, Eric Sunshine, Jeff King
Denton Liu <liu.denton@gmail.com> writes:
> - objsha1=$(git verify-pack -v pack-$packsha1.idx | head -n 1 |
> - sed -e "s/^\([0-9a-f]\{40\}\).*/\1/") &&
> + git verify-pack -v pack-$packsha1.idx >packlist &&
> + objsha1=$(head -n 1 packlist | sed -e "s/^\([0-9a-f]\{40\}\).*/\1/") &&
We probably should lose reference to SHA-1 and use $OID_REGEX; this
is obviously a #leftoverbits material that is outside the scope of
this series.
> @@ -91,7 +93,8 @@ test_expect_success 'loose objects in alternate ODB are not repacked' '
> git prune-packed &&
> for p in .git/objects/pack/*.idx
> do
> - if git verify-pack -v $p | egrep "^$objsha1"
> + git verify-pack -v $p >packlist || return $?
> + if egrep "^$objsha1" packlist
> then
> found_duplicate_object=1
> echo "DUPLICATE OBJECT FOUND"
These egrep that try to match lines that begin with an object name
can be a simple grep instead (again, outside the scope of this
series).
> @@ -109,15 +112,18 @@ test_expect_success 'packed obs in alt ODB are repacked even when local repo is
> test_path_is_file "$myidx" &&
> for p in alt_objects/pack/*.idx
> do
> - git verify-pack -v $p | sed -n -e "/^[0-9a-f]\{40\}/p"
> - done | while read sha1 rest
> + git verify-pack -v $p >packlist || return $?
> + sed -n -e "/^[0-9a-f]\{40\}/p"
> + done >packs &&
A misleading filename? The lines in this file are not pack files;
rather the file has a list of objects in various packs.
> + git verify-pack -v $myidx >mypacklist &&
> + while read sha1 rest
> do
> - if ! ( git verify-pack -v $myidx | grep "^$sha1" )
> + if ! grep "^$sha1" mypacklist
> then
> echo "Missing object in local pack: $sha1"
> return 1
> fi
> - done
> + done <packs
> '
Again outside the scope of this series, but this looks O(n^2)
to me.
If I were writing this today, I would prepare a sorted list of all
object names (and nothing else on each line) in alt_objects/pack/ in
one file (call it 'orig'), and prepare another file with a sorted
list of all object names described in $myidx (call it 'dest'), and
then run "comm -23 orig dest" and see if there is anything that is
unique in the 'orig' file (i.e. something in 'orig' is missing from
'dest').
> @@ -132,15 +138,18 @@ test_expect_success 'packed obs in alt ODB are repacked when local repo has pack
> test_path_is_file "$myidx" &&
> for p in alt_objects/pack/*.idx
> do
> - git verify-pack -v $p | sed -n -e "/^[0-9a-f]\{40\}/p"
> - done | while read sha1 rest
> + git verify-pack -v $p >packlist || return $?
> + sed -n -e "/^[0-9a-f]\{40\}/p" packlist
> + done >packs &&
> + git verify-pack -v $myidx >mypacklist &&
> + while read sha1 rest
> do
> - if ! ( git verify-pack -v $myidx | grep "^$sha1" )
> + if ! grep "^$sha1" mypacklist
> then
> echo "Missing object in local pack: $sha1"
> return 1
> fi
> - done
> + done <packs
> '
Likewise.
> @@ -160,15 +169,18 @@ test_expect_success 'packed obs in alternate ODB kept pack are repacked' '
> test_path_is_file "$myidx" &&
> for p in alt_objects/pack/*.idx
> do
> - git verify-pack -v $p | sed -n -e "/^[0-9a-f]\{40\}/p"
> - done | while read sha1 rest
> + git verify-pack -v $p >packlist || return $?
> + sed -n -e "/^[0-9a-f]\{40\}/p" packlist
> + done >packs &&
> + git verify-pack -v $myidx >mypacklist &&
> + while read sha1 rest
> do
> - if ! ( git verify-pack -v $myidx | grep "^$sha1" )
> + if ! grep "^$sha1" mypacklist
> then
> echo "Missing object in local pack: $sha1"
> return 1
> fi
> - done
> + done <packs
> '
Likewise.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 2/2] tests: add tests for grep --max-count
@ 2022-06-22 18:10 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-06-22 18:10 UTC (permalink / raw)
To: Carlos López via GitGitGadget
Cc: git, Martin Ågren [ ], Paul Eggert [ ], Carlos L.
"Carlos López via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: =?UTF-8?q?Carlos=20L=C3=B3pez?= <00xc@protonmail.com>
>
> Add tests for grep's -m / --max-count to check if the option correctly
> outputs limited results, and that it interacts properly with other flags
> that could likely be used in conjunction.
>
> Signed-off-by: Carlos López 00xc@protonmail.com
> ---
> t/t7810-grep.sh | 83 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
This is better done as part of the previous patch. The new tests
protect the new code from future breakage.
> diff --git a/t/t7810-grep.sh b/t/t7810-grep.sh
> index 69356011713..7b1b8a3cd93 100755
> --- a/t/t7810-grep.sh
> +++ b/t/t7810-grep.sh
> @@ -77,6 +77,7 @@ test_expect_success setup '
> # Say hello.
> function hello() {
> echo "Hello world."
> + echo "Hello again."
> } # hello
>
> # Still a no-op.
> @@ -595,6 +596,88 @@ test_expect_success 'grep --files-without-match --quiet' '
> test_must_be_empty actual
> '
>
> +cat >expected <<EOF &&
> +EOF
> +
> +test_expect_success 'grep --max-count 0 (must exit with non-zero)' '
> + test_must_fail git grep --max-count 0 foo >actual &&
> + test_cmp expected actual
> +'
For this particular one, "test_must_be_empty actual" would suffice,
without comparing with the expected output.
> +cat >expected <<EOF &&
> +file:foo mmap bar
> +EOF
> +
> +test_expect_success 'grep --max-count 1' '
> + git grep --max-count 1 foo >actual &&
> + test_cmp expected actual
> +'
Writing expected output outside test_expect_success that uses it is
a quite old style but that is because this test script is pretty
much ancient, so mimicking it is OK. We'd need to come back later
when the tree is quiescent to clean them up, though (#leftoverbits).
> ...
> + test_cmp expected actual
> +'
The new tests seem to give us a reasonable test coverage. We could
discard one of the "-m1" vs "-m3" in the early ones, as they do not
give much extra test coverage over the other, to reduce repetition.
We do not test a case where we pick up-to N matches each from
multiple files, though. Perhaps
git grep -m1 -e o -- hello.\*
may stop after hitting "No-op." in hello.ps1 and "stdio" in hello.c,
which may make a good test, perhaps?
Thanks.
^ permalink raw reply [relevance 6%]
* Re: Re*: [PATCH v3] fetch: replace string-list used as a look-up table with a hashmap
@ 2018-10-31 14:50 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2018-10-31 14:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Stefan Beller, Ramsay Jones
Hi Junio,
On Sat, 27 Oct 2018, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Just one thing^W^Wa couple of things:
> >
> > It would probably make more sense to `hashmap_get_from_hash()` and
> > `strhash()` here (and `strhash()` should probably be used everywhere
> > instead of `memhash(str, strlen(str))`).
>
> hashmap_get_from_hash() certainly is much better suited for simpler
> usage pattern like these callsites, and the ones in sequencer.c. It
> is a shame that a more complex variant takes the shorter-and-sweeter
> name hashmap_get().
I agree, at least in part.
From what I understand, hashmap_get_from_hash() needs a little assistance
from the comparison function with which the hashmap is configured, see
e.g. this function in the sequencer:
static int labels_cmp(const void *fndata, const struct labels_entry *a,
const struct labels_entry *b, const void *key)
{
return key ? strcmp(a->label, key) : strcmp(a->label, b->label);
}
See how that first tests whether `key` is non-`NULL`, and then takes a
shortcut, not even looking at `b`? This is important, because `b` does not
refer to a complete `labels_entry` when we call `hashmap_get_from_hash()`.
It only refers to a `hashmap_entry`. Looking at `b->label` would access
some random memory, and do most certainly the wrong thing.
> I wish we named the latter hashmap_get_fullblown_feature_rich() and
> called the _from_hash() thing a simple hashmap_get() from day one,
> but it is way too late.
>
> I looked briefly the users of the _get() variant, and some of their
> uses are legitimately not-simple and cannot be reduced to use the
> simpler _get_from_hash variant, it seems. But others like those in
> builtin/difftool.c should be straight-forward to convert to use the
> simpler get_from_hash variant. It could be a low-hanging fruit left
> for later clean-up, perhaps.
Right. #leftoverbits
> >> @@ -271,10 +319,10 @@ static void find_non_local_tags(const struct ref *refs,
> >> !has_object_file_with_flags(&ref->old_oid,
> >> OBJECT_INFO_QUICK) &&
> >> !will_fetch(head, ref->old_oid.hash) &&
> >> - !has_sha1_file_with_flags(item->util,
> >> + !has_sha1_file_with_flags(item->oid.hash,
> >
> > I am not sure that we need to test for null OIDs here, given that...
> > ...
> > Of course, `has_sha1_file_with_flags()` is supposed to return `false` for
> > null OIDs, I guess.
>
> Yup. An alternative is to make item->oid a pointer to oid, not an
> oid object itself, so that we can express "no OID for this ref" in a
> more explicit way, but is_null_oid() is already used as "no OID" in
> many other codepaths, so...
Right, and it would complicate the code. So I am fine with your version of
it.
> >> + for_each_string_list_item(remote_ref_item, &remote_refs_list) {
> >> + const char *refname = remote_ref_item->string;
> >> + struct hashmap_entry key;
> >> +
> >> + hashmap_entry_init(&key, memhash(refname, strlen(refname)));
> >> + item = hashmap_get(&remote_refs, &key, refname);
> >> + if (!item)
> >> + continue; /* can this happen??? */
> >
> > This would indicate a BUG, no?
>
> Possibly. Alternatively, we can just use item without checking and
> let the runtime segfault.
Hahaha! Yep. We could also cause a crash. I do prefer the BUG() call.
> Here is an incremental on top that can be squashed in to turn v3
> into v4.
Nice.
Thanks!
Dscho
>
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 0f8e333022..aee1d9bf21 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -259,7 +259,7 @@ static struct refname_hash_entry *refname_hash_add(struct hashmap *map,
> size_t len = strlen(refname);
>
> FLEX_ALLOC_MEM(ent, refname, refname, len);
> - hashmap_entry_init(ent, memhash(refname, len));
> + hashmap_entry_init(ent, strhash(refname));
> oidcpy(&ent->oid, oid);
> hashmap_add(map, ent);
> return ent;
> @@ -282,11 +282,7 @@ static void refname_hash_init(struct hashmap *map)
>
> static int refname_hash_exists(struct hashmap *map, const char *refname)
> {
> - struct hashmap_entry key;
> - size_t len = strlen(refname);
> - hashmap_entry_init(&key, memhash(refname, len));
> -
> - return !!hashmap_get(map, &key, refname);
> + return !!hashmap_get_from_hash(map, strhash(refname), refname);
> }
>
> static void find_non_local_tags(const struct ref *refs,
> @@ -365,12 +361,10 @@ static void find_non_local_tags(const struct ref *refs,
> */
> for_each_string_list_item(remote_ref_item, &remote_refs_list) {
> const char *refname = remote_ref_item->string;
> - struct hashmap_entry key;
>
> - hashmap_entry_init(&key, memhash(refname, strlen(refname)));
> - item = hashmap_get(&remote_refs, &key, refname);
> + item = hashmap_get_from_hash(&remote_refs, strhash(refname), refname);
> if (!item)
> - continue; /* can this happen??? */
> + BUG("unseen remote ref?");
>
> /* Unless we have already decided to ignore this item... */
> if (!is_null_oid(&item->oid)) {
> @@ -497,12 +491,12 @@ static struct ref *get_ref_map(struct remote *remote,
>
> for (rm = ref_map; rm; rm = rm->next) {
> if (rm->peer_ref) {
> - struct hashmap_entry key;
> const char *refname = rm->peer_ref->name;
> struct refname_hash_entry *peer_item;
>
> - hashmap_entry_init(&key, memhash(refname, strlen(refname)));
> - peer_item = hashmap_get(&existing_refs, &key, refname);
> + peer_item = hashmap_get_from_hash(&existing_refs,
> + strhash(refname),
> + refname);
> if (peer_item) {
> struct object_id *old_oid = &peer_item->oid;
> oidcpy(&rm->peer_ref->old_oid, old_oid);
>
^ permalink raw reply [relevance 6%]
* Re: [RFC PATCH 1/1] Documentation/git-sparse-checkout.txt: add an OPTIONS section
@ 2022-03-11 20:56 6% ` Derrick Stolee
0 siblings, 0 replies; 200+ results
From: Derrick Stolee @ 2022-03-11 20:56 UTC (permalink / raw)
To: Shaoxuan Yuan, git; +Cc: vdye, newren, bagasdotme
On 3/11/2022 8:21 AM, Shaoxuan Yuan wrote:
> Add an OPTIONS section to the manual and move the descriptions about
> these options from COMMANDS to the section.
This is a good goal.
> +OPTIONS
> +-------
However, there are a few issues with the current approach. First, I
believe it would be better to start with COMMANDS, then OPTIONS.
To be fair, we are not consistent here. These commands use OPTIONS
and then COMMANDS:
* git-commit-graph.txt
* git-remote.txt
* git-revert.txt
These use [SUB]COMMANDS and then OPTIONS:
* git-maintenance.txt
* git-notes.txt
* git-p4.txt
* git-stash.txt
* git-submodule.txt
* git-worktree.txt
My preference would be OPTIONS second (and we can clean up the
other docs as #leftoverbits). In particular, I noticed that
the SYNOPSIS for git-maintenance.txt is out of date.
> +'--[no-]cone'::
> + Use with ['set'|'reapply'].
> + Specify using cone mode or not. The default is to use cone mode.
> +
> By default, the input list is considered a list of directories, matching
> the output of `git ls-tree -d --name-only`. This includes interpreting
The other issue is that this context is detailing information about
the 'set' command and the input it takes. You'll want to make sure
the information is properly grouped.
> @@ -78,6 +59,11 @@ with the `--sparse-index` option, and will likely be incompatible with
> other new features as they are added. See the "Non-cone Problems"
> section below and the "Sparse Checkout" section of
> linkgit:git-read-tree[1] for more details.
> +
> +'--[no-]sparse-index'::
> + Use with ['set'|'reapply'].
I do like these clear indicators of which commands allow this
option. I wonder if it should instead be
Use with the `set` and `reapply` commands.
Thanks,
-Stolee
^ permalink raw reply [relevance 6%]
* Re: Git multiple remotes push stop at first failed connection
@ 2020-06-02 16:26 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-06-02 16:26 UTC (permalink / raw)
To: Jeff King; +Cc: John Siu, git
Jeff King <peff@peff.net> writes:
> There's really no benefit to doing it all in a single Git process, as
> we'd connect to each independently, run a separate independent
> pack-objects for each, etc.
>
> I'd even suggest that Git implement such a loop itself, as we did for
> "git fetch --all", but sadly "push --all" is already taken for a
> different meaning (but it might still be worth doing under a different
> option name).
I wonder if it is possible to update the implementation to do so
without changing the UI at all, though.
The presence of the "--all" option in "fetch" command is tied
closely to the fact that it makes no sense to have multiple URLs
that are used to download from at the same time under a single
remote name (e.g. what should "remotes/origin/master" point at if
two URLs say different things if such an arrangement were allowed?).
On the other hand, the pushURL for a single remote can be multiple
places for redundancy (a possible #leftoverbits here is that we
should probably disable the "pretend that we immediately turned
around and fetched from them after pushing" optimization when
pushing to a remote that has multiple pushURLs defined) does not
need an extra option. If the way we currently push is suboptimal
and it is better to spawn a separate "git push" instance via the
run_command() API, that can safely be done as a bugfix without
affecting any UI elements, no?
^ permalink raw reply [relevance 6%]
* Re: [PATCH] git-remote.txt: fix typo
@ 2024-02-21 18:18 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-02-21 18:18 UTC (permalink / raw)
To: Jakub Wilk; +Cc: git, Abhradeep Chakraborty
Jakub Wilk <jwilk@jwilk.net> writes:
> Signed-off-by: Jakub Wilk <jwilk@jwilk.net>
> ---
> Documentation/git-remote.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
> index 1dec314834..932a5c3ea4 100644
> --- a/Documentation/git-remote.txt
> +++ b/Documentation/git-remote.txt
> @@ -35,7 +35,7 @@ OPTIONS
> -v::
> --verbose::
> Be a little more verbose and show remote url after name.
> - For promisor remotes, also show which filter (`blob:none` etc.)
> + For promisor remotes, also show which filters (`blob:none` etc.)
> are configured.
> NOTE: This must be placed between `remote` and subcommand.
When you give more than one filters to "git clone", they are used to
create a single "combined" filter, so strictly speaking, "also show
which filter is configured" is a grammatically valid that might be
more technically correct. E.g. the user may see
$ git clone --filter=blob:none --filter=tree:2 $there sample-repo
$ git -C sample-repo remote -v show
origin ... (fetch) [combine:blob:none+tree:2]
origin ... (push)
in the output. It may not be a bad idea to update the code to show
the filter information in a way that is more clear that we are
seeing a list of filters (perhaps showing the above as "[blob:none
tree:2]" might be a good starting point, as a totally separate topic
(#leftoverbits).
After taking your patch as-is, that is. In user's mind, they
consider they gave two filters, and making a single combined filter
is something Git did without being asked for its own convenience,
so "which filters are configured" is, while it may be technically
less correct, much closer to what the end-user perceives.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 11/15] find multi-byte comment chars in unterminated buffers
@ 2024-03-14 19:37 6% ` René Scharfe
0 siblings, 0 replies; 200+ results
From: René Scharfe @ 2024-03-14 19:37 UTC (permalink / raw)
To: Jeff King
Cc: git, Junio C Hamano, Dragan Simic, Kristoffer Haugsbakk,
Manlio Perillo
Am 12.03.24 um 09:05 schrieb Jeff King:
> On Thu, Mar 07, 2024 at 08:42:22PM +0100, René Scharfe wrote:
>
>>> @@ -2562,7 +2562,7 @@ static int parse_insn_line(struct repository *r, struct todo_item *item,
>>> /* left-trim */
>>> bol += strspn(bol, " \t");
>>>
>>> - if (bol == eol || *bol == '\r' || *bol == comment_line_char) {
>>> + if (bol == eol || *bol == '\r' || starts_with_mem(bol, eol - bol, comment_line_str)) {
>>
>> If the strspn() call is safe (which it is, as the caller expects the
>> string to be NUL-terminated) then you could use starts_with() here and
>> avoid the length calculation. But that would also match
>> comment_line_str values that contain LF, which the _mem version does not
>> and that's better.
>
> I try not to read too much into the use of string functions on what
> otherwise appears to be an unterminated buffer. While in Git it is quite
> often terminated at allocation time (coming from a strbuf, etc) I feel
> like I've fixed a number of out-of-bounds reads simply due to sloppy
> practices. And even if something is correct today, it is easy for it to
> change, since the assumption is made far away from allocation.
>
> So I dunno. Like you said, fewer computations is fewer opportunity to
> mess things up. I don't like the idea of introducing a new hand-grenade
> that might blow up later, but maybe if it's right next to a strspn()
> call that's already a problem, it's not materially making anything
> worse.
Yeah, and my logic was flawed: If the caller somehow guarantees that a
space or tab occurs before eol then the strspn() call is safe. Its
presence doesn't guarantee NUL termination. parse_insn_line() would
not be safe to use without that prerequisite, but that's a different
matter..
>>> @@ -882,7 +882,7 @@ static size_t find_trailer_block_start(const char *buf, size_t len)
>>>
>>> /* The first paragraph is the title and cannot be trailers */
>>> for (s = buf; s < buf + len; s = next_line(s)) {
>>> - if (s[0] == comment_line_char)
>>> + if (starts_with_mem(s, buf + len - s, comment_line_str))
>>> continue;
>>> if (is_blank_line(s))
>>
>> Another case where starts_with() would be safe to use, as
>> is_blank_line() expects (and gets) a NUL-terminated string, but it would
>> allow matching comment_line_str values that contain LF.
>
> Hmm. Yes, it is a NUL-terminated string always, but the caller has told
> us not to look past end_of_log_message(). I suspect that if there is no
> newline in comment_line_str() it's probably impossible to go past "len"
> (just because the end of the log surely ends with either a NUL or a
> newline). But it feels iffy to me. I dunno.
Same flawed thinking on my part: As long as we're guaranteed a blank
line in the buffer we won't walk past its end. That doesn't mean we can
assume a NUL is present. But that's fragile. The code should use
memchr() instead of strchrnul().
That's not the problem you set out to solve in your series, though, and
you avoid making it worse by respecting the length limit in the code
you change. #leftoverbits
Keeping track of the remaining length increases code size and adds
opportunities for mistakes. Not sure how to avoid it, however. Using
eol instead of len at least avoids subtractions.
tl;dr: Good patch (in v2).
René
^ permalink raw reply [relevance 6%]
* Re: -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect
@ 2017-09-26 2:39 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-09-26 2:39 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: git@vger.kernel.org
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I do not recall people talking about symbolic links but the case of
>> binary files has been on the wishlist for a long time, and I do not
>> know of anybody who is working on (or is planning to work on) it.
>
> Ah, I misremembered.
>
> We've addressed the "binary files" case back in 2012 with a944af1d
> ("merge: teach -Xours/-Xtheirs to binary ll-merge driver",
> 2012-09-08). I do not know offhand if it is just as easy to plumb
> the MERGE_FAVOR_{OURS,THEIRS} bits thru the symbolic link codepath,
> like that patch did to the binary file codepath.
Perhaps the attached (totally untested) patch might be a good
starting point. I do not know if you are interested in hacking on
Git, and I do not feel offended if you are not, but perhaps somebody
else might get interested in seeing if this #leftoverbits is a good
direction to go in, and finishing it with docs and tests if it is
;-)
merge-recursive.c | 17 +++++++++++++----
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 1d3f8f0d22..3605275ca3 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1026,10 +1026,19 @@ static int merge_file_1(struct merge_options *o,
&b->oid,
!o->call_depth);
} else if (S_ISLNK(a->mode)) {
- oidcpy(&result->oid, &a->oid);
-
- if (!oid_eq(&a->oid, &b->oid))
- result->clean = 0;
+ switch (o->recursive_variant) {
+ case MERGE_RECURSIVE_NORMAL:
+ oidcpy(&result->oid, &a->oid);
+ if (!oid_eq(&a->oid, &b->oid))
+ result->clean = 0;
+ break;
+ case MERGE_RECURSIVE_OURS:
+ oidcpy(&result->oid, &a->oid);
+ break;
+ case MERGE_RECURSIVE_THEIRS:
+ oidcpy(&result->oid, &b->oid);
+ break;
+ }
} else
die("BUG: unsupported object type in the tree");
}
^ permalink raw reply related [relevance 6%]
* Re: [PATCH] describe: confirm that blobs actually exist
@ 2018-02-12 17:29 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2018-02-12 17:29 UTC (permalink / raw)
To: git; +Cc: Michael Haggerty, Stefan Beller
On Mon, Feb 12, 2018 at 12:23:06PM -0500, Jeff King wrote:
> We can fix this by replacing the lookup_blob() call with a
> check of the true type via sha1_object_info(). This is not
> quite as efficient as we could possibly make this check. We
> know in most cases that the object was already parsed in the
> earlier commit lookup, so we could call lookup_object(),
> which does auto-create, and check the resulting struct's
> type (or NULL). However it's not worth the fragility nor
> code complexity to save a single object lookup.
By the way, I did notice one other inefficiency here: we always call
lookup_commit_reference_gently() first, which will call parse_object().
So if you were to "git describe" an enormous blob, we'd load the whole
thing into memory for no purpose. We could structure this as:
type = sha1_object_info(oid.hash, NULL);
if (type == OBJ_BLOB)
describe_blob(&oid);
else if (lookup_commit_reference_gently(&oid, 1))
describe_commit(&oid);
else
describe("neither commit nor blob");
That incurs an extra object lookup for the commit case, but potentially
saves reading the blob. We could have our cake and eat it, too, if
sha1_file.c had a function like "parse this object unless it's a blob,
in which case just fill in the type info".
Arguably that should be the default when parse_object() is called on a
blob, but I suspect some older code may rely on parse_object() to check
that the object is present and consistent.
Anyway, I don't know that it's really worth caring about too much, but
just something I noticed.
Maybe a #leftoverbits if somebody cares.
-Peff
^ permalink raw reply [relevance 6%]
* [PATCH 0/3] hash-object doc: small fixes
@ 2019-05-20 21:53 6% Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2019-05-20 21:53 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Jeff King, Adam Roben, Bryan Larsen,
Matthias Urlichs, Eric Sunshine,
Ævar Arnfjörð Bjarmason
Small doc fixes. Maybe trivial enough to land in 2.22, but there's no
rush.
A pair of #leftoverbits I noticed is that we've implemented the
"--stdin-paths" option via unquote_c_style() from day one, so our
current docs lie (and still do with this series) about wanting
\n-delimited files, you can't hash a file called '"foo"' as you'd
expect, you need to pass '"\"foo\""'.
I wonder if we should document this at this point, or just change it
and add a "-z" option. None of our tests fail if I remove this
unquote_c_style() codepath, and it's never been documented, but
someone in the wild may have organically depended on it.
Ævar Arnfjörð Bjarmason (3):
hash-object doc: stop mentioning git-cvsimport
hash-object doc: elaborate on -w and --literally promises
hash-object doc: point to ls-files and rev-parse
Documentation/git-hash-object.txt | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--
2.21.0.1020.gf2820cf01a
^ permalink raw reply [relevance 6%]
* [PATCH 0/3] doc: unify config info on some cmds
@ 2022-07-14 17:44 6% Matheus Tavares
0 siblings, 0 replies; 200+ results
From: Matheus Tavares @ 2022-07-14 17:44 UTC (permalink / raw)
To: git
These three patches attempt to remove duplication between some
config/*.txt and git-*.txt files, to facilitate maintenance and fix any
divergences.
This series targets the most straightforward conversions, but there are
also other commands whose config documentation could possibly be unified
(maybe #leftoverbits):
- git-log.txt and config/log.txt have some duplications, but with
different wordings, which could probably be standardized.
- git-send-email.txt has some config definitions "inlined" with the
descriptions about the CLI options (e.g. sendemail.xmailer). Not sure
if it is worth unifying the configs in this case.
- Some cmds like format-patch, status, and branch have some config variables
defined at config/*, but not at git-*.txt. Maybe the latter could
mention something like "See the full list of available <cmd>.*
configuration variables at git-config(1)."
Matheus Tavares (3):
doc: grep: unify configuration variables definitions
doc: apply: unify configuration variables definitions
doc: notes: unify configuration variables definitions
Documentation/config/apply.txt | 7 +++-
Documentation/config/grep.txt | 10 ++++--
Documentation/config/notes.txt | 62 ++++++++++++++++------------------
Documentation/git-apply.txt | 9 ++---
Documentation/git-grep.txt | 37 ++++----------------
Documentation/git-notes.txt | 54 ++---------------------------
6 files changed, 53 insertions(+), 126 deletions(-)
--
2.37.0
^ permalink raw reply [relevance 6%]
* Re: [PATCH] imap-send: increase command size limit
@ 2024-04-16 16:08 6% ` René Scharfe
0 siblings, 0 replies; 200+ results
From: René Scharfe @ 2024-04-16 16:08 UTC (permalink / raw)
To: Jeff King; +Cc: Git List
Am 15.04.24 um 20:55 schrieb Jeff King:
> On Sun, Apr 14, 2024 at 06:47:52PM +0200, René Scharfe wrote:
>
>> While 1KB is plenty for user names, passwords and mailbox names,
>> there's no point in limiting our commands like that. Call xstrvfmt()
>> instead of open-coding it and use strbuf to format the command to
>> send, as we need its length. Fail hard if it exceeds INT_MAX, because
>> socket_write() can't take more than that.
>
> Hmm. I applaud your attention to detail, but this INT_MAX thing is ugly. ;)
It is. I thought about using cast_size_t_to_int() instead, but decided
to preserve the original error message.
> Shouldn't socket_write() just use size_t / ssize_t?
Probably size_t.
> In particular, this made me wonder what we would do for larger items.
> Like, say, the actual message to be uploaded. And indeed, we use a
> strbuf to read in the messages and pass the whole buffer for each to
> socket_write(). So we'd possibly quietly truncate such a message.
Hmm, perhaps we should at least sprinkle in some more overflow checks?
> Fixing it is a little more complicated than switching to size_t, because
> the underlying SSL_write() uses an int. So we'd probably need some
> looping, similar to xwrite().
Or SSL_write_ex(), which takes and returns size_t. It was added in
OpenSSL 1.1.1, which reached its end of life half a year ago.
https://www.openssl.org/docs/man1.1.1/man3/SSL_write.html
https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
> In practice I doubt this is ever an issue. 2GB emails are not likely to
> be usable in general.
Tough. Who likes to get multi-GB patches in their inbox? Heard of
people exchanging CD images by email decades ago, though, so I
wouldn't rule this out totally. Perhaps that's the last puzzle piece
to convert game studios to perform email reviews of asset-heavy
binary diffs? ;-)
> And I kind of doubt that this is a reasonable
> vector for attacks, since the inputs to imap-send would generally come
> from the user themselves (and certainly truncating the attack message is
> probably not that interesting, though I imagine one could convince
> write_in_full() to do an out-of-bounds read as a size_t becomes a
> negative int which becomes a large size_t again).
Right. If you can get a user to upload more than 2GB of hostile data to
their mail server then you don't need to bother crafting an integer
overflow exploit.
Still, checking for overflow instead of truncating silently seems like a
good idea even for half-dead low-impact code. #leftoverbits
René
^ permalink raw reply [relevance 6%]
* [PATCH 0/2] test-lib.sh: add BAIL_OUT function, use it for SANITIZE=leak
@ 2021-10-14 0:47 6% Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2021-10-14 0:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Ævar Arnfjörð Bjarmason
This series adds a BAIL_OUT function, and uses it when the new
GIT_TEST_PASSING_SANITIZE_LEAK=true mode is misused.
Once we have this function we'll be able to use it for any other error
that's a cause for aborting the entire test run.
I experimented with making BUG() and error() always be a "BAIL_OUT". I
think that's worth pursuing, but e.g. for the error about missing
"&&-chains" we'd need to support emitting multi-line messages.
TAP consumers only understand what follows the "Bail out!" message up
to the first "\n", so we can't quote the entire "test_expect_success",
as the "&&-chain" error does. I think emitting them with "say_error()"
beforehand (piped with ">&7" in the case of "BUG()") should work, but
let's leave those #leftoverbits for later.
Ævar Arnfjörð Bjarmason (2):
test-lib.sh: de-duplicate error() teardown code
test-lib.sh: use "Bail out!" syntax on bad SANITIZE=leak use
t/test-lib.sh | 28 +++++++++++++++++++++-------
1 file changed, 21 insertions(+), 7 deletions(-)
--
2.33.1.1346.g48288c3c089
^ permalink raw reply [relevance 6%]
* Re: [Outreachy] Introduce myself
@ 2018-09-30 16:57 6% ` Christian Couder
0 siblings, 0 replies; 200+ results
From: Christian Couder @ 2018-09-30 16:57 UTC (permalink / raw)
To: ananyakittu1997; +Cc: git, Johannes Schindelin
Hi Ananya,
On Sun, Sep 30, 2018 at 5:53 PM Ananya Krishna Maram
<ananyakittu1997@gmail.com> wrote:
>
> Hi Git Community, Christian and Johannes,
>
> My initial Outreachy got accepted.
Great! Welcome to the Git community!
[...]
> Having done a lot of assignment in C and
> bash scripting and keen interest to learn about working of git
> internals, I choose to contribute to this project. So I started
> observing the patches sent to git mailing list.
About possible projects I updated https://git.github.io/Outreachy-17/
but only the `git bisect` has been officially proposed as an Outreachy
project. I hope Dscho (Johannes) will be ok to submit one of the 2
others soon and to register himself as a mentor or co-mentor on some
of the projects.
> I am currently looking for first patch opportunities to git. I came
> across[1] and I will try to put maximum effort towards my goal and if
> I need some clarification of the problem statement I guess you guys or
> Outreachy mentors will be here to help me.
The micro-project page you found is not up-to-date, so some
micro-projects we propose might have already been taken by GSoC
students last winter/spring. Sorry we didn't update the page or create
another one. Anyway there are some micro-projects there like "Add more
builtin patterns for userdiff" that are still valid and still good
small tasks to get started working on Git. And there are explanations
about how you can search for micro-projects (especially how to search
for #leftoverbits on the mailing list archive).
Thank you for your interest in contributing to Git,
Christian.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v5 04/12] merge-tree: implement real merges
@ 2022-02-22 2:28 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2022-02-22 2:28 UTC (permalink / raw)
To: René Scharfe
Cc: Elijah Newren via GitGitGadget, Git Mailing List,
Christian Couder, Taylor Blau, Johannes Altmanninger,
Ramsay Jones, Johannes Schindelin, Christian Couder,
Ævar Arnfjörð Bjarmason, Johannes Sixt,
Josh Steadmon, Emily Shaffer
On Sun, Feb 20, 2022 at 1:03 AM René Scharfe <l.s.r@web.de> wrote:
>
> Am 20.02.22 um 07:54 schrieb Elijah Newren via GitGitGadget:
[...]
> > + /*
> > + * Get the merge bases, in reverse order; see comment above
> > + * merge_incore_recursive in merge-ort.h
> > + */
> > + common = get_merge_bases(parent1, parent2);
> > + if (!common)
> > + die(_("refusing to merge unrelated histories"));
> > + for (j = common; j; j = j->next)
> > + commit_list_insert(j->item, &merge_bases);
>
> This loop creates a reversed copy of "common". You could use
> reverse_commit_list() instead to do it in-place and avoid the
> allocations. Only the copy, "merge_bases", is used below.
Oh, good catch. I probably should have been aware of this since
someone requested I move the reverse_commit_list() function from
merge-recursive.c to commit.c as part of my merge-ort work, but looks
like I forgot about it and copied this command snippet from
builtin/merge.c instead. I have no excuse.
However, I wonder if that means we could also apply this
simplification to the code snippets in builtin/merge.c and sequencer.c
that you can find with
git grep commit_list_insert.*reversed
? Maybe #leftoverbits for that part?
^ permalink raw reply [relevance 6%]
* Re: [PATCH v5 1/1] mergetool: add automerge configuration
@ 2020-12-24 0:32 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-12-24 0:32 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, David Aguilar, Johannes Sixt, Seth House
Felipe Contreras <felipe.contreras@gmail.com> writes:
>> Ah, I forgot about that one. I think "the number of conflicts" was
>> a UI mistake (the original that it mimics is "merge" from RCS suite,
>> which uses 1 and 2 for "conflicts" and "trouble") but we know we
>> will get conflicts, so it is wrong to expect success from the
>> command. Deliberately ignoring the return status is the right thing
>> to do.
>
> I agree. My bet is that nobody is checking the return status of "git
> merge-file" to find out the number of conflicts. Plus, how can you check
> the difference between 255 conflicts and error -1?
Yup, I already mentioned UI mistake so you do not have to repeat it
to consume more bandwidth. We're in agreement already.
> We could do something like --marker-size=13 to minimize the chances of
> that happening.
>
> In that case I would prefer '/^<\{13\} /' (to avoid too many
> characters). I see those regexes used elsewhere in git, but I don't know
> how portable that is.
If it is used elsewhere with "sed", then that would be OK, but if it
is not with "sed" but with "grep", that's quite a different story.
> So, do we want those three things?
>
> 1. A non-standard marker-size
> 2. Check beforehand the existence of those markers and disable
> automerge
> 3. Check afterwards the existence of those markers and disable
> automerge
I do not think 3 is needed if we do 2 and I do not think 1 would
particularly be useful *UNLESS* the code consults with the attribute
system to see what marker size the path uses to avoid crashing with
the non-standard marker-size the path already uses.
So the easiest would be not to do anything for now, with a note
about known limitations in the doc. The second easiest would be to
do 2. alone. We could do 1. to be more complete but I tend to think
that it is better to leave it as #leftoverbits.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] git: extend --no-lazy-fetch to work across subprocesses
2024-02-27 6:04 6% ` Junio C Hamano
@ 2024-02-27 7:49 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2024-02-27 7:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Christian Couder
On Mon, Feb 26, 2024 at 10:04:54PM -0800, Junio C Hamano wrote:
> ----- >8 --------- >8 --------- >8 --------- >8 -----
> Subject: [PATCH v2 3/3] git: extend --no-lazy-fetch to work across subprocesses
> [...]
This looks pretty reasonable to me, and the lines you drew for
#leftoverbits all seemed liked good spots.
The only thing I noticed in the patch was this (which I think is not
even new in this round):
> diff --git a/environment.c b/environment.c
> index 9e37bf58c0..afad78a3f8 100644
> --- a/environment.c
> +++ b/environment.c
> @@ -136,6 +136,7 @@ const char * const local_repo_env[] = {
> GRAFT_ENVIRONMENT,
> INDEX_ENVIRONMENT,
> NO_REPLACE_OBJECTS_ENVIRONMENT,
> + NO_LAZY_FETCH_ENVIRONMENT,
> GIT_REPLACE_REF_BASE_ENVIRONMENT,
> GIT_PREFIX_ENVIRONMENT,
> GIT_SHALLOW_FILE_ENVIRONMENT,
This will clear the environment variable when we move between
repositories. I can see an argument for it, and certainly that's how
GIT_NO_REPLACE_OBJECTS works.
But I can also see an argument that this is not a property of the
_repository_, but of the request. For example, if I run "git
--no-lazy-fetch log" and we cross into a submodule to do a diff, should
that submodule also avoid lazy-fetching? I'd think so, but I think your
patch would restore the defaults when we "enter" the submodule repo.
There's some prior art there, I think, in how GIT_CEILING_DIRECTORIES
works, or even something like "git --literal-pathspecs", neither of
which appear in local_repo_env.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH 2/2] fetch, push: keep separate lists of submodules and gitlinks
@ 2017-10-23 18:05 6% ` Stefan Beller
0 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2017-10-23 18:05 UTC (permalink / raw)
To: Heiko Voigt
Cc: Junio C Hamano, Jens Lehmann, Brandon Williams,
git@vger.kernel.org, Jonathan Nieder
On Mon, Oct 23, 2017 at 7:12 AM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> On Thu, Oct 19, 2017 at 11:11:09AM -0700, Stefan Beller wrote:
>> Currently when fetching we collect the names of submodules to be fetched
>> in a list. As we also want to support fetching 'gitlinks, that happen to
>> have a repo checked out at the right place', we'll just pretend that these
>> are submodules. We do that by assuming their path is their name. This in
>> turn can yield collisions between the name-namespace and the
>> path-namespace. (See the previous test for a demonstration.)
>>
>> This patch rewrites the code such that we treat the 'real submodule' case
>> differently from the 'gitlink, but ok' case. This introduces a bit
>> of code duplication, but gets rid of the confusing mapping between names
>> and paths.
>>
>> The test is incomplete as the long term vision is not achieved yet.
>> (which would be fetching both the renamed submodule as well as
>> the gitlink thing, putting them in place via e.g. git-pull)
>>
>> Signed-off-by: Stefan Beller <sbeller@google.com>
>> ---
>>
>> Heiko,
>> Junio,
>>
>> I assumed the code would ease up a lot more, but now I am undecided if
>> I want to keep arguing as the code is not stopping to be ugly. :)
>
> So we are basically coming to the same conclusion? :) My previous
> fallback approach basically did the same but with the old architecture
> (without parallel fetch, ...) and was already ugly.
It depends on the conclusion you drew. ;)
Here is my conclusion:
* It would really be nice to have this fallback separated out.
* However for the current state the ugliness of such code trumps the
more maintainable, long term oriented thing with path/names not
clashing. I could not spend more time polishing these patches,
so I could not ask you to do it either
-> I think your patches are fine as is for inclusion
-> We may have #leftoverbits here to clear up the confusion around
path/names, as well as making the code more pleasant to read.
> With the fallback on submodule default names approach we can keep most
> of the old functionality and keep the code that handles that minimal.
>
> Since there is only a small (IMO quite unlikely) cornercase that could
> break peoples expectations I would like to have a look whether anyone
> even notices the behavioral change on next or master. If there are
> complaints we can still extend and add the two lists.
That sounds good to me.
>
>> The idea is to treat submodule and gitlinks separately, with submodules
>> supporting renames, and gitlinks as a historic artefact.
>>
>> Sorry for the noise about code ugliness.
>
> Why sorry? For me it is actually interesting to see you basically coming
> to the same conclusions.
I thought I might come off awkwardly criticizing code for ugliness without
having a better alternative to show.
Thanks for working on this,
Stefan
>
> Cheers Heiko
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/2] xdiff-interface: export comparing and hashing strings
@ 2017-10-27 17:15 6% ` Stefan Beller
0 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2017-10-27 17:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: René Scharfe, git, Jonathan Nieder, Jeff King
On Fri, Oct 27, 2017 at 12:12 AM, Junio C Hamano <gitster@pobox.com> wrote:
> René Scharfe <l.s.r@web.de> writes:
>
>> Am 25.10.2017 um 20:49 schrieb Stefan Beller:
>>> +/*
>>> + * Compare the strings l1 with l2 which are of size s1 and s2 respectively.
>>> + * Returns 1 if the strings are deemed equal, 0 otherwise.
>>> + * The `flags` given as XDF_WHITESPACE_FLAGS determine how white spaces
>>> + * are treated for the comparision.
>>> + */
>>> +extern int xdiff_compare_lines(const char *l1, long s1,
>>> + const char *l2, long s2, long flags);
>>
>> With the added comment it's OK here.
>>
>> Still, I find the tendency in libxdiff to use the shortest possible
>> variable names to be hard on the eyes. That math-like notation may have
>> its place in that external library, but I think we should be careful
>> lest it spreads.
>
> Yeah, I tend to agree. The xdiff-interface is at the (surprise!)
> interface layer, so we could make it follow the style of either one,
> but we seem to have picked up the convention of the lower layer,
> so...
>
> By the way, I was looking at the code around this area while
> reviewing the cr-at-eol thing, and noticed a couple of things:
>
>
> * combine-diff.c special cases only IGNORE_WHITESPACE and
> IGNORE_WHITESPACE_CHANGE but no other IGNORE_WHITESPACE things; I
> have a suspicion that this is not because IGNORE_WHITESPACE_AT_EOL
> does not have to special cased by the codepath, but only because
> the combine-diff.c refactoring predates the introduction of
> ws-at-eol thing?
I wonder how much overlap between the IGNORE_WHITESPACE_AT_EOL
and CRLF-AT-EOL is (maybe these can be combined, as per the root of
this discussion)
> The machinery uses its own match_string_spaces() helper; it may
> make sense to use the same xdiff_compare_lines() in its callers
> and get rid of this helper function.
Speaking of xdiff_compare_lines, it serves the special purpose of the
move detection as well as its internal use cases, but we may need to
change its interface/implementation in the future, to align it with strcmp,
currently the compare function only returns equality, not an order.
> * diff_setup_done() sets DIFF_FROM_CONTENTS when any of the
> IGNORE_WHITESPACE bits is true, to allow "git diff -q
> --ignore-something" would do the right thing. We do not however
> give a similar special case to XDF_IGNORE_BLANK_LINES.
>
> $ echo >>Makefile && git diff $option --ignore-blank-lines Makefile
>
> exits with 1 when option=--exit-code and it exits with 0 when
> option=-q
>
>
> For now I'll leve these as #leftoverbits, but I may come back to the
> latter soonish. I won't come back to the former until Stefan's
> refactor hits 'master', though.
which is presumably after the 2.15 release.
To tack on the #leftoverbits: The --color-moved detection doesn't
pay attention to XDF_IGNORE_BLANK_LINES (which is tricky as
it is on the per-line layer. If we want to ignore spurious blank lines,
we'd have to check for this flag in diff.c in mark_color_as_moved(..)
in the block
/* Check any potential block runs, advance each or nullify */
Thanks,
Stefan
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 4/4] builtin/rebase: support running "git rebase <upstream>"
2018-07-07 6:45 6% ` Christian Couder
@ 2018-07-07 16:24 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-07-07 16:24 UTC (permalink / raw)
To: Christian Couder
Cc: Pratik Karki, git, Johannes Schindelin, Stefan Beller,
Alban Gruin
Christian Couder <christian.couder@gmail.com> writes:
>> + default:
>> + BUG("Unhandled rebase type %d", opts->type);
>> + break;
>
> Nit: I think the "break;" line could be removed as the BUG() should always exit.
>
> A quick grep shows that there are other places where there is a
> "break;" line after a BUG() though. Maybe one of the #leftoverbits
> could be about removing those "break;" lines.
I do not see the above as nit, though. "could" is often quite a
different thing from "should", and in this case (and all the other
cases you incorrectly mark with %leftoverbits) removal of these
lines does not improve readability. In fact, if there were another
case arm after this one, having "break" there would help those who
scan the code, as the person who wants to ensure what that next case
arm does is correct is given a strong hint by "break;" immediately
before it that nothing in the previous case arm matters and does not
have to even be looked at. By removing it you force such a reader
to notice BUG() and reason that it does not matter because it does
not return control to us (hence no fallthru).
^ permalink raw reply [relevance 6%]
* Re: [PATCH v5 11/14] replay: use standard revision ranges
@ 2023-10-19 19:49 6% ` Linus Arver
0 siblings, 0 replies; 200+ results
From: Linus Arver @ 2023-10-19 19:49 UTC (permalink / raw)
To: Christian Couder, git
Cc: Junio C Hamano, Patrick Steinhardt, Johannes Schindelin,
Elijah Newren, John Cai, Derrick Stolee, Phillip Wood, Calvin Wan,
Toon Claes, Dragan Simic, Christian Couder
This patch's documentation bits LGTM. The comments I have below are all
nits and I don't think they are enough to require a re-roll. If v5 is
accepted as-is, then this stuff could be #leftoverbits for a future
(minor) cleanup.
Thanks!
Christian Couder <christian.couder@gmail.com> writes:
> From: Elijah Newren <newren@gmail.com>
>
> +DESCRIPTION
> +-----------
> +
> +Takes a range of commits and replays them onto a new location. Leaves
> +the working tree and the index untouched, and updates no
> +references.
Nit: in v4 you had
Does
+not touch the working tree or index, and does not update any
+references.
and the "does not update any references" sounds more natural than
"updates no references".
> The output of this command is meant to be used as input to
> +`git update-ref --stdin`, which would update the relevant branches
> +(see the OUTPUT section below).
> +
> +THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE.
Nit: add "IN THE FUTURE" at the end.
> +EXAMPLES
> +--------
> +
> +To simply rebase `mybranch` onto `target`:
Nit: s/To simply rebase/Rebase
or, remove "simply" because it doesn't add much value.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2] read-cache: write all indexes with the same permissions
@ 2018-11-17 13:05 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-11-17 13:05 UTC (permalink / raw)
To: Christian Couder
Cc: git, Jeff King, Nguyen Thai Ngoc Duy, Michael Haggerty,
Ævar Arnfjörð Bjarmason, Christian Couder
Christian Couder <christian.couder@gmail.com> writes:
> "However, as noted in those commits we'd still create the file as
> 0600, and would just re-chmod it only if core.sharedRepository is set
> to "true" or "all". If core.sharedRepository is unset or set to
> "false", then the file mode will not be changed, so without
> core.splitIndex a system with e.g. the umask set to group writeability
> would work for a group member, but not with core.splitIndex set, as
> group members would not be able to access the shared index file.
That is irrelevant. The repository needs to be configured properly
if it wanted to be used by the members of the group, period.
> It is unfortunately not short lived when core.sharedrepository is
> unset for example as adjust_shared_perm() starts with:
>
> int adjust_shared_perm(const char *path)
> {
> int old_mode, new_mode;
>
> if (!get_shared_repository())
> return 0;
>
> but get_shared_repository() will return PERM_UMASK which is 0 when
> git_config_get_value("core.sharedrepository", ...) returns a non zero
> value which happens when "core.sharedrepository" is unset.
Which is to say, you get an unwanted result when your repository is
not configured properly. It is not a news, and I have no sympathy.
Just configure your repository properly and you'll be fine.
>> > Ideally we'd split up the adjust_shared_perm() function to one that
>> > can give us the mode we want so we could just call open() instead of
>> > open() followed by chmod(), but that's an unrelated cleanup.
>>
>> I would drop this paragraph, as I think this is totally incorrect.
>> Imagine your umask is tighter than the target permission. You ask
>> such a helper function and get "you want 0660". Doing open(0660)
>> would not help you an iota---you'd need chmod() or fchmod() to
>> adjust the result anyway, which already is done by
>> adjust-shared-perm.
>
> It seems to me that it is not done when "core.sharedrepository" is unset.
So? You are assuming that the repository is misconfigured and it is
not set to widen the perm bit in the first place, no?
>> > We already have that minor issue with the "index" file
>> > #leftoverbits.
>>
>> The above "Ideally", which I suspect is totally bogus, would show up
>> whey people look for that keyword in the list archive. This is one
>> of the reasons why I try to write it after at least one person
>> sanity checks that an idea floated is worth remembering.
>
> It was in Ævar's commit message and I thought it might be better to
> keep it so that people looking for that keyword could find the above
> as well as the previous RFC patch.
So do you agree that open(0660) does not guarantee the result will
be group writable, the above "Ideally" is misguided nonsense, and
giving the #leftoverbits label to it will clutter the search result
and harm readers? That's good.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 03/24] format-patch: don't leak "extra_headers" or "ref_message_ids"
@ 2022-03-09 20:34 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2022-03-09 20:34 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Martin Ågren, Elijah Newren,
Derrick Stolee
On Wed, Mar 09, 2022 at 02:16:33PM +0100, Ævar Arnfjörð Bjarmason wrote:
> @@ -1946,7 +1947,8 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> strbuf_addch(&buf, '\n');
> }
>
> - rev.extra_headers = strbuf_detach(&buf, NULL);
> + extra_headers = strbuf_detach(&buf, NULL);
> + rev.extra_headers = extra_headers;
Small nit, these two assignments could be combined on the same line
without wrapping. But obviously not a big deal.
> @@ -2173,8 +2175,10 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> prepare_bases(&bases, base, list, nr);
> }
>
> - if (in_reply_to || thread || cover_letter)
> - rev.ref_message_ids = xcalloc(1, sizeof(struct string_list));
> + if (in_reply_to || thread || cover_letter) {
> + rev.ref_message_ids = xmalloc(sizeof(*rev.ref_message_ids));
> + string_list_init_nodup(rev.ref_message_ids);
> + }
OK, and this is the "while we're at it..." part of your commit message.
I did find this a little confusing to read at first, so wouldn't have
minded to see this and the rest of the change split across two patches,
but I think this is fine, too.
> @@ -2281,6 +2285,11 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> strbuf_release(&rdiff1);
> strbuf_release(&rdiff2);
> strbuf_release(&rdiff_title);
> + free(extra_headers);
> + if (rev.ref_message_ids) {
> + string_list_clear(rev.ref_message_ids, 0);
I was surprised to learn that string_list_clear() is not a noop when its
first argument is NULL.
Looking around, it probably wouldn't help that much. E.g., running
something like:
git grep -B1 'string_list_clear(' | grep if -A1
doesn't turn up many results like the above. So maybe some good
#leftoverbits there, although maybe not.
> + free(rev.ref_message_ids);
This could go in or out of the if-statement.
Thanks,
Taylor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] apply: avoid out-of-bounds access in fuzzy_matchlines()
@ 2017-11-12 4:45 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-11-12 4:45 UTC (permalink / raw)
To: René Scharfe; +Cc: mqudsi, git, Giuseppe Bilotta
René Scharfe <l.s.r@web.de> writes:
> fuzzy_matchlines() uses a pointers to the first and last characters of
> two lines to keep track while matching them. This makes it impossible
> to deal with empty strings. It accesses characters before the start of
> empty lines. It can also access characters after the end when checking
> for trailing whitespace in the main loop.
>
> Avoid that by using pointers to the first character and the one *after*
> the last one. This is well-defined as long as the latter is not
> dereferenced. Basically rewrite the function based on that premise; it
> becomes much simpler as a result. There is no need to check for
> leading whitespace outside of the main loop anymore.
I recall vaguely that we were bitten by a bug or two due to another
instance of <begin,end> that deviates from the usual "close on the
left end, open on the right end" convention somewhere in the system
recently?
I think the fix of the function is correct, but at the same time, we
would want to clean it up after this fix lands by replacing the
function with the line comparison function we already have in the
xdiff/ layer, so that we can (1) reduce the code duplication and (2)
more importantly, do not have to be constrained by the (mistakenly
narrow) policy decision we currently seem to have to support only
"ignore-whitespace-change" and nothing else. Of course, that should
not be done as part of this fix. It is strictly a #leftoverbits item.
Thanks.
> Reported-by: Mahmoud Al-Qudsi <mqudsi@neosmart.net>
> Signed-off-by: Rene Scharfe <l.s.r@web.de>
> ---
> apply.c | 59 ++++++++++++++++++++---------------------------------------
> 1 file changed, 20 insertions(+), 39 deletions(-)
>
> diff --git a/apply.c b/apply.c
> index d676debd59..b8087bd29c 100644
> --- a/apply.c
> +++ b/apply.c
> @@ -300,52 +300,33 @@ static uint32_t hash_line(const char *cp, size_t len)
> static int fuzzy_matchlines(const char *s1, size_t n1,
> const char *s2, size_t n2)
> {
> - const char *last1 = s1 + n1 - 1;
> - const char *last2 = s2 + n2 - 1;
> - int result = 0;
> + const char *end1 = s1 + n1;
> + const char *end2 = s2 + n2;
>
> /* ignore line endings */
> - while ((*last1 == '\r') || (*last1 == '\n'))
> - last1--;
> - while ((*last2 == '\r') || (*last2 == '\n'))
> - last2--;
> -
> - /* skip leading whitespaces, if both begin with whitespace */
> - if (s1 <= last1 && s2 <= last2 && isspace(*s1) && isspace(*s2)) {
> - while (isspace(*s1) && (s1 <= last1))
> - s1++;
> - while (isspace(*s2) && (s2 <= last2))
> - s2++;
> - }
> - /* early return if both lines are empty */
> - if ((s1 > last1) && (s2 > last2))
> - return 1;
> - while (!result) {
> - result = *s1++ - *s2++;
> - /*
> - * Skip whitespace inside. We check for whitespace on
> - * both buffers because we don't want "a b" to match
> - * "ab"
> - */
> - if (isspace(*s1) && isspace(*s2)) {
> - while (isspace(*s1) && s1 <= last1)
> + while (s1 < end1 && (end1[-1] == '\r' || end1[-1] == '\n'))
> + end1--;
> + while (s2 < end2 && (end2[-1] == '\r' || end2[-1] == '\n'))
> + end2--;
> +
> + while (s1 < end1 && s2 < end2) {
> + if (isspace(*s1)) {
> + /*
> + * Skip whitespace. We check on both buffers
> + * because we don't want "a b" to match "ab".
> + */
> + if (!isspace(*s2))
> + return 0;
> + while (s1 < end1 && isspace(*s1))
> s1++;
> - while (isspace(*s2) && s2 <= last2)
> + while (s2 < end2 && isspace(*s2))
> s2++;
> - }
> - /*
> - * If we reached the end on one side only,
> - * lines don't match
> - */
> - if (
> - ((s2 > last2) && (s1 <= last1)) ||
> - ((s1 > last1) && (s2 <= last2)))
> + } else if (*s1++ != *s2++)
> return 0;
> - if ((s1 > last1) && (s2 > last2))
> - break;
> }
>
> - return !result;
> + /* If we reached the end on one side only, lines don't match. */
> + return s1 == end1 && s2 == end2;
> }
>
> static void add_line_info(struct image *img, const char *bol, size_t len, unsigned flag)
^ permalink raw reply [relevance 6%]
* Re: [PATCH 3/3] branch: forbid refs/heads/HEAD
@ 2017-10-13 13:15 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2017-10-13 13:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Fri, Oct 13, 2017 at 02:11:32PM +0900, Junio C Hamano wrote:
> strbuf_check_branch_ref() is the central place where many codepaths
> see if a proposed name is suitable for the name of a branch. It was
> designed to allow us to get stricter than the check_refname_format()
> check used for refnames in general, and we already use it to reject
> a branch whose name begins with a '-'.
>
> Use it to also reject "HEAD" as a branch name.
Heh, I just pointed somebody to this a day or two ago as #leftoverbit. I
guess it's taken now. :)
Related to this: should we do a better job of confirming that the
refname is available for use?
If you do:
git branch foo
git checkout -b foo/bar
then "foo/bar" is not available. And for "checkout -b", we'd notice when
we tried to create the ref. But for:
git checkout --orphan foo/bar
we'd update HEAD with a non-viable name, and only find out later during
"git commit". That's not the end of the world, but it might be nice to
complain when writing the symlink.
Largely orthogonal to the problem you're solving here, but I suspect it
may touch the same code, so it might be worth thinking about while we're
here.
> diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
> index e88349c8a0..3ecb2eab0c 100755
> --- a/t/t1430-bad-ref-name.sh
> +++ b/t/t1430-bad-ref-name.sh
> @@ -331,4 +331,12 @@ test_expect_success 'update-ref --stdin -z fails delete with bad ref name' '
> grep "fatal: invalid ref format: ~a" err
> '
>
> +test_expect_success 'branch rejects HEAD as a branch name' '
> + test_must_fail git branch HEAD HEAD^
> +'
> +
> +test_expect_success 'checkout -b rejects HEAD as a branch name' '
> + test_must_fail git checkout -B HEAD HEAD^
> +'
Should we test that:
git update-ref refs/heads/HEAD HEAD^
continues to work?
-Peff
^ permalink raw reply [relevance 6%]
* Re: [BUG] url schemes should be case-insensitive
2018-06-24 8:56 6% [BUG] url schemes should be case-insensitive Jeff King
@ 2018-06-25 18:19 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-06-25 18:19 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> We seem to match url schemes case-sensitively:
>
> $ git clone SSH://example.com/repo.git
> Cloning into 'repo'...
> fatal: Unable to find remote helper for 'SSH'
>
> whereas rfc3986 is clear that the scheme portion is case-insensitive.
> We probably ought to match at least our internal ones with strcasecmp.
That may break if somebody at DevToolGroup@$BIGCOMPANY got cute and
named their custom remote helper SSH:// that builds on top of the
normal ssh:// protocol with something extra and gave it to their
developers (and they named the http counterpart that has the same
extra HTTP://, of course). If we probe for git-remote-SSH first and
then fall back to git-remote-ssh, then we won't break these people,
though. I agree that it may be a good bite-sized #leftoverbit
material.
> Possibly we should also normalize external helpers (so "FOO://bar" would
> always call git-remote-foo, never git-remote-FOO).
> We could probably also give an advise() message in the above output,
> suggesting that the problem is likely one of:
>
> 1. They misspelled the scheme.
>
> 2. They need to install the appropriate helper.
>
> This may be a good topic for somebody looking for low-hanging fruit to
> get involved in development (I'd maybe call it a #leftoverbits, but
> since I didn't start on it, I'm not sure if it counts as "left over" ;)).
Well, noticing an issue, analysing and discussing potential
improvements and their ramifications is already half the work, so it
does count as left-over, I would say.
It may probably be a good idea to do an advice, but I'd think
"Untable to find remote helper for 'SSH'" may be clear enough. If
anything, perhaps saying "remote helper for 'SSH' protocol" would
make it even clear? I dunno.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 05/11] merge-ort: let renormalization change modify/delete into clean delete
@ 2021-03-08 12:55 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2021-03-08 12:55 UTC (permalink / raw)
To: Elijah Newren via GitGitGadget
Cc: git, Jonathan Nieder, Derrick Stolee, Junio C Hamano,
Elijah Newren
On Fri, Mar 05 2021, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
>
> When we have a modify/delete conflict, but the only change to the
> modification is e.g. change of line endings, then if renormalization is
> requested then we should be able to recognize such a case as a
> not-modified/delete and resolve the conflict automatically.
>
> This fixes t6418.10 under GIT_TEST_MERGE_ALGORITHM=ort.
>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
> merge-ort.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 61 insertions(+), 2 deletions(-)
>
> diff --git a/merge-ort.c b/merge-ort.c
> index 87c553c0882c..c4bd88b9d3db 100644
> --- a/merge-ort.c
> +++ b/merge-ort.c
> @@ -2416,6 +2416,60 @@ static int string_list_df_name_compare(const char *one, const char *two)
> return onelen - twolen;
> }
>
> +static int read_oid_strbuf(struct merge_options *opt,
> + const struct object_id *oid,
> + struct strbuf *dst)
> +{
> + void *buf;
> + enum object_type type;
> + unsigned long size;
> + buf = read_object_file(oid, &type, &size);
> + if (!buf)
> + return err(opt, _("cannot read object %s"), oid_to_hex(oid));
> + if (type != OBJ_BLOB) {
> + free(buf);
> + return err(opt, _("object %s is not a blob"), oid_to_hex(oid));
As an aside I've got another series I'll submit soon which refactors all
these "object is not xyz" calls to a utility function, so in this case
we'd also say what it was other than a blob.
Fine to keep this here, just a #leftoverbits note to myself to
eventually migrate this.
> + }
> + strbuf_attach(dst, buf, size, size + 1);
> + return 0;
> +}
> +
> +static int blob_unchanged(struct merge_options *opt,
> + const struct version_info *base,
> + const struct version_info *side,
> + const char *path)
> +{
> + struct strbuf basebuf = STRBUF_INIT;
> + struct strbuf sidebuf = STRBUF_INIT;
> + int ret = 0; /* assume changed for safety */
> + const struct index_state *idx = &opt->priv->attr_index;
> +
> + initialize_attr_index(opt);
> +
> + if (base->mode != side->mode)
> + return 0;
> + if (oideq(&base->oid, &side->oid))
> + return 1;
> +
> + if (read_oid_strbuf(opt, &base->oid, &basebuf) ||
> + read_oid_strbuf(opt, &side->oid, &sidebuf))
> + goto error_return;
> + /*
> + * Note: binary | is used so that both renormalizations are
> + * performed. Comparison can be skipped if both files are
> + * unchanged since their sha1s have already been compared.
> + */
> + if (renormalize_buffer(idx, path, basebuf.buf, basebuf.len, &basebuf) |
> + renormalize_buffer(idx, path, sidebuf.buf, sidebuf.len, &sidebuf))
> + ret = (basebuf.len == sidebuf.len &&
> + !memcmp(basebuf.buf, sidebuf.buf, basebuf.len));
> +
> +error_return:
> + strbuf_release(&basebuf);
> + strbuf_release(&sidebuf);
> + return ret;
> +}
> +
>
> struct directory_versions {
> /*
> * versions: list of (basename -> version_info)
> @@ -3003,8 +3057,13 @@ static void process_entry(struct merge_options *opt,
> modify_branch = (side == 1) ? opt->branch1 : opt->branch2;
> delete_branch = (side == 1) ? opt->branch2 : opt->branch1;
>
> - if (ci->path_conflict &&
> - oideq(&ci->stages[0].oid, &ci->stages[side].oid)) {
> + if (opt->renormalize &&
> + blob_unchanged(opt, &ci->stages[0], &ci->stages[side],
> + path)) {
> + ci->merged.is_null = 1;
> + ci->merged.clean = 1;
> + } else if (ci->path_conflict &&
> + oideq(&ci->stages[0].oid, &ci->stages[side].oid)) {
Small note (no need for re-roll or whatever) on having read a bit of
merge-ort.c code recently: I'd find this thing a bit easier on the eyes
if ci->stages[0] and ci->stages[side] were split into a variable before
the if/else, i.e. used as "side_0.oid and side_n.oid" and "side_0 and
side_n" in this case..
That would also avoid the wrapping of at least one argument list here.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v5 3/3] ls-files.c: add --deduplicate option
@ 2021-01-21 11:00 6% ` 胡哲宁
0 siblings, 0 replies; 200+ results
From: 胡哲宁 @ 2021-01-21 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: ZheNing Hu via GitGitGadget, Git List, Eric Sunshine
Junio C Hamano <gitster@pobox.com> 于2021年1月21日周四 上午5:26写道：
>
> "ZheNing Hu via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
> > @@ -321,30 +324,46 @@ static void show_files(struct repository *repo, struct dir_struct *dir)
> >
> > construct_fullname(&fullname, repo, ce);
> >
> > + if (skipping_duplicates && last_shown_ce &&
> > + !strcmp(last_shown_ce->name,ce->name))
> > + continue;
>
> Style. Missing SP after comma.
Get it.
>
> > if ((dir->flags & DIR_SHOW_IGNORED) &&
> > !ce_excluded(dir, repo->index, fullname.buf, ce))
> > continue;
> > if (ce->ce_flags & CE_UPDATE)
> > continue;
> > if (show_cached || show_stage) {
> > + if (skipping_duplicates && last_shown_ce &&
> > + !strcmp(last_shown_ce->name,ce->name))
> > + continue;
>
> OK. When show_stage is set, skipping_duplicates is automatically
> turned off (and show_unmerged is automatically covered as it turns
> show_stage on automatically). So this feature has really become
> "are we showing only names, and if so, did we show an entry of the
> same name before?".
Yeah,showing only names,so I yesterday ask such question :)
>
> > if (!show_unmerged || ce_stage(ce))
> > show_ce(repo, dir, ce, fullname.buf,
> > ce_stage(ce) ? tag_unmerged :
> > (ce_skip_worktree(ce) ? tag_skip_worktree :
> > tag_cached));
> > + if (show_cached && skipping_duplicates)
> > + last_shown_ce = ce;
>
> The code that calls show_ce() belonging to a totally separate if()
> statement makes my stomach hurt---how are we going to guarantee that
> "last shown" really will keep track of what was shown last?
>
> Shouldn't the above be more like this?
>
> - if (!show_unmerged || ce_stage(ce))
> + if (!show_unmerged || ce_stage(ce)) {
> show_ce(repo, dir, ce, fullname.buf,
> ce_stage(ce) ? tag_unmerged :
> (ce_skip_worktree(ce) ? tag_skip_worktree :
> tag_cached));
> + last_shown_ce = ce;
> + }
>
well,I am also thinking about this question :"last_shown_ce" is not true
last shown ce,but may be If "last_shown_ce" truly seen every last shown
ce ,We may need more cumbersome logic to make the program correct.
I have tried the processing method of your above code before, but found
that some errors may have occurred.
> It does maintain last_shown_ce even when skipping_duplicates is not
> set, but I think that is overall win. Assigning unconditionally
> would be cheaper than making a conditional jump on the variable and
> make assignment (or not).
>
> > }
> > if (ce_skip_worktree(ce))
> > continue;
> > + if (skipping_duplicates && last_shown_ce &&
> > + !strcmp(last_shown_ce->name,ce->name))
> > + continue;
>
> Style. Missing SP after comma.
>
> OK, if we've shown an entry of the same name under skip-duplicates
> mode, and the code that follows will show the same entry (if they
> decide to show it), so we can go to the next entry early.
>
> > err = lstat(fullname.buf, &st);
> > if (err) {
> > - if (errno != ENOENT && errno != ENOTDIR)
> > - error_errno("cannot lstat '%s'", fullname.buf);
> > - if (show_deleted)
> > + if (skipping_duplicates && show_deleted && show_modified)
> > show_ce(repo, dir, ce, fullname.buf, tag_removed);
> > - if (show_modified)
> > - show_ce(repo, dir, ce, fullname.buf, tag_modified);
> > + else {
> > + if (errno != ENOENT && errno != ENOTDIR)
> > + error_errno("cannot lstat '%s'", fullname.buf);
> > + if (show_deleted)
> > + show_ce(repo, dir, ce, fullname.buf, tag_removed);
> > + if (show_modified)
> > + show_ce(repo, dir, ce, fullname.buf, tag_modified);
> > + }
> > } else if (show_modified && ie_modified(repo->index, ce, &st, 0))
> > show_ce(repo, dir, ce, fullname.buf, tag_modified);
>
> This part will change shape quite a bit when we follow the
> suggestion I made on 1/3, so I won't analyze how correct this
> version is.
>
Fine...
> > + last_shown_ce = ce;
> > }
> >
> > strbuf_release(&fullname);
> > @@ -571,6 +590,7 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
> > N_("pretend that paths removed since <tree-ish> are still present")),
> > OPT__ABBREV(&abbrev),
> > OPT_BOOL(0, "debug", &debug_mode, N_("show debugging data")),
> > + OPT_BOOL(0,"deduplicate",&skipping_duplicates,N_("suppress duplicate entries")),
> > OPT_END()
> > };
> >
> > @@ -610,6 +630,8 @@ int cmd_ls_files(int argc, const char **argv, const char *cmd_prefix)
> > * you also show the stage information.
> > */
> > show_stage = 1;
> > + if (show_tag || show_stage)
> > + skipping_duplicates = 0;
>
> OK.
>
> > if (dir.exclude_per_dir)
> > exc_given = 1;
> >
>
> Thanks.
Thanks,Junio,I find my PR in gitgitgadget have been accepted.
By the way,
I found the problem "leftoverbit" and "good first issue" on gitgitgadget
It may not have been updated for a long time, and most of the above
may have been resolved.
Should it do an update?
Then we can happily be a "bounty hunter" in the git community, haha!
^ permalink raw reply [relevance 6%]
* Re: [PATCH] maintenance: compare output of pthread functions for inequality with 0
@ 2022-12-02 18:10 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2022-12-02 18:10 UTC (permalink / raw)
To: Rose via GitGitGadget; +Cc: git, Seija
On Fri, Dec 02 2022, Rose via GitGitGadget wrote:
> From: Seija <doremylover123@gmail.com>
>
> The documentation for pthread_create and pthread_sigmask state that:
>
> "On success, pthread_create() returns 0;
> on error, it returns an error number"
>
> As such, we ought to check for an error
> by seeing if the output is not 0.
>
> Checking for "less than" is a mistake
> as the error code numbers can be greater than 0.
>
> Signed-off-by: Seija <doremylover123@gmail.com>
> ---
> maintenance: compare output of pthread functions for inequality with 0
>
> The documentation for pthread_create and pthread_sigmask state that "On
> success, pthread_create() returns 0; on error, it returns an error
> number, and the contents of *thread are undefined."
>
> As such, we ought to check for an error by seeing if the output is not
> 0, rather than being less than 0, since nothing stops these functions
> from returning a positive number.
>
> Signed-off by: Seija doremylover123@gmail.com
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1389%2FAtariDreams%2Faddress-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1389/AtariDreams/address-v1
> Pull-Request: https://github.com/git/git/pull/1389
>
> builtin/fsmonitor--daemon.c | 4 ++--
> run-command.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/fsmonitor--daemon.c b/builtin/fsmonitor--daemon.c
> index 6f30a4f93a7..52a08bb3b57 100644
> --- a/builtin/fsmonitor--daemon.c
> +++ b/builtin/fsmonitor--daemon.c
> @@ -1209,7 +1209,7 @@ static int fsmonitor_run_daemon_1(struct fsmonitor_daemon_state *state)
> * events.
> */
> if (pthread_create(&state->listener_thread, NULL,
> - fsm_listen__thread_proc, state) < 0) {
> + fsm_listen__thread_proc, state)) {
> ipc_server_stop_async(state->ipc_server_data);
> err = error(_("could not start fsmonitor listener thread"));
> goto cleanup;
> @@ -1220,7 +1220,7 @@ static int fsmonitor_run_daemon_1(struct fsmonitor_daemon_state *state)
> * Start the health thread to watch over our process.
> */
> if (pthread_create(&state->health_thread, NULL,
> - fsm_health__thread_proc, state) < 0) {
> + fsm_health__thread_proc, state)) {
> ipc_server_stop_async(state->ipc_server_data);
> err = error(_("could not start fsmonitor health thread"));
> goto cleanup;
> diff --git a/run-command.c b/run-command.c
> index 48b9ba6d6f0..756f1839aab 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -1019,7 +1019,7 @@ static void *run_thread(void *data)
> sigset_t mask;
> sigemptyset(&mask);
> sigaddset(&mask, SIGPIPE);
> - if (pthread_sigmask(SIG_BLOCK, &mask, NULL) < 0) {
> + if (pthread_sigmask(SIG_BLOCK, &mask, NULL)) {
> ret = error("unable to block SIGPIPE in async thread");
> return (void *)ret;
> }
>
> base-commit: 805265fcf7a737664a8321aaf4a0587b78435184
This looks good to me, and skimming through the rest of the
pthread_create() it seems the rest of the code in-tree is correct.
But (and especially if you're interested) we really should follow-up
here and fix the "error()" etc. part of this. After this we have cases
in-tree where we on failure:
* Call die_errno() (good)
* Call die(), error() etc., but with a manual strerror() argument,
these should just use the *_errno() helper.
* Don't report on the errno at all, e.g. in this case shown here.
It seems to me that all of these should be using die_errno(),
error_errno() etc.
Or maybe it's the other way around, and we should not rely on the global
"errno", but always capture the return value, and give that to
strerror() (or set "errno = ret", and call {die,error,warning}_errno()).
In any case, some low-hanging #leftoverbits there...
^ permalink raw reply [relevance 6%]
* Re: [PATCH v4 1/7] refs: accept symref values in `ref_transaction[_add]_update`
@ 2024-04-26 19:31 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-04-26 19:31 UTC (permalink / raw)
To: Karthik Nayak; +Cc: christian.couder, git, ps
Karthik Nayak <karthik.188@gmail.com> writes:
> From: Karthik Nayak <karthik.188@gmail.com>
> Subject: Re: [PATCH v4 1/7] refs: accept symref values in `ref_transaction[_add]_update`
>
> The `ref_transaction[_add]_update` functions obtain ref information and
> flags to create a `ref_update` and add it to the transaction at hand.
Just a very minor irritation, but ref_transaction_add_update() is a
function used internally in the ref subsystem and is exported only
because its visibility needs to cross file boundaries between refs.c
and refs/*backend.c files.
It would be better to only mention ref_transaction_update() in the
title, and talk about the need to make matching adjustment to
ref_transaction_add_update(), which is an internal function, in the
body of the log message.
This is an unrelated #leftoverbits tangent, but while trying to find
out the reason why "[_add]" in the title looked irritating to me, I
noticed that builtin/show-ref.c includes <refs/refs-internal.h>. I
do not know what it uses from the "internal" implementation detail,
but the API may have to be cleaned up so that a random "client"
caller do not have to do so.
The patch itself looked good. Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 01/39] pack: make packed_git_mru global a value instead of a pointer
@ 2017-08-30 19:44 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2017-08-30 19:44 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Stefan Beller, brian m. carlson
On Tue, Aug 29, 2017 at 11:48:27PM -0700, Jonathan Nieder wrote:
> The MRU cache that keeps track of recently used packs is represented
> using two global variables:
>
> struct mru packed_git_mru_storage;
> struct mru *packed_git_mru = &packed_git_mru_storage;
>
> Callers never assign to the packed_git_mru pointer, though, so we can
> simplify by eliminating it and using &packed_git_mru_storage (renamed
> to &packed_git_mru) directly. This variable is only used by the
> packfile subsystem, making this a relatively uninvasive change (and
> any new unadapted callers would trigger a compile error).
>
> Noticed while moving these globals to the object_store struct.
Sounds reasonable. I think I had originally wanted to hide the
implementation and make the MRU more opaque, hence exposing only the
pointer. But since I ended up just letting people directly walk over the
struct pointers to do iteration, it needs to expose the struct internals
anyway, and this layer of indirection isn't useful.
> ---
> builtin/pack-objects.c | 4 ++--
> cache.h | 4 ++--
> packfile.c | 12 +++++-------
> 3 files changed, 9 insertions(+), 11 deletions(-)
The patch looks good to me.
As an aside, the mru code could probably be simplified a bit by reusing
the list implementation from list.h (both were added around the same
time, and it wasn't worth creating a dependency then, but I think list.h
is useful and here to stay at this point).
It's definitely not critical to put that into this already-large series,
though. Maybe we can use Junio's #leftoverbits tag. :)
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH 3/9] t3905: move all commands into test cases
@ 2021-02-02 21:41 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2021-02-02 21:41 UTC (permalink / raw)
To: Denton Liu; +Cc: Git Mailing List
Denton Liu <liu.denton@gmail.com> writes:
> test_expect_success 'stash save --include-untracked stashed the untracked files' '
> + tracked=$(git rev-parse --short $(echo 1 | git hash-object --stdin)) &&
> + untracked=$(git rev-parse --short $(echo untracked | git hash-object --stdin)) &&
Not a new issue introduced by this patch, but
* these will fail if blobs that record "1\n" and "untracked\n" do
not exist in the repository already, because the hash-object
command lacks the "-w" option.
* the reason why they do not fail is because there are these blobs
already; grabbing them using extended SHA-1 expression may be
simpler to read, e.g.
tracked=$(git rev-parse --short HEAD:file)
* even if it is not trivial to get to such a blob object, it
probably is easier to read the test if a file that has the
desired contents in it is used, not an "echo", e.g.
untracked=$(git rev-parse --short $(git hash-object -w untracked/untracked))
We may want to clean these up someday, but it does not have to be
part of this topic (#leftoverbits).
> + cat >expect.diff <<-EOF &&
> + diff --git a/HEAD b/HEAD
> + new file mode 100644
> + index 0000000..$tracked
> + --- /dev/null
> + +++ b/HEAD
> + @@ -0,0 +1 @@
> + +1
> + diff --git a/file2 b/file2
> + new file mode 100644
> + index 0000000..$tracked
> + --- /dev/null
> + +++ b/file2
> + @@ -0,0 +1 @@
> + +1
> + diff --git a/untracked/untracked b/untracked/untracked
> + new file mode 100644
> + index 0000000..$untracked
> + --- /dev/null
> + +++ b/untracked/untracked
> + @@ -0,0 +1 @@
> + +untracked
> + EOF
^ permalink raw reply [relevance 6%]
* Re: [PATCH 00/12] Fix all leaks in tests t0002-t0099: Part 2
@ 2021-06-21 21:54 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2021-06-21 21:54 UTC (permalink / raw)
To: Andrzej Hunt; +Cc: Git Mailing List, Christian Couder
On Sun, Jun 20, 2021 at 8:14 AM <andrzej@ahunt.org> wrote:
>
> From: Andrzej Hunt <andrzej@ahunt.org>
>
> This series plugs more of the leaks that were found while running
> t0002-t0099 with LSAN.
>
> See also the first series (already merged) at [1]. I'm currently
> expecting at least another 2 series before t0002-t0099 run leak free.
> I'm not being particularly systematic about the order of patches -
> although I am trying to send out "real" (if mostly small) leaks first,
> before sending out the more boring patches that add free()/UNLEAK() to
> cmd_* and direct helpers thereof.
I've read over the series. It provides some good clear fixes. I
noted on patches 2, 6, and 12 that a some greps suggested that leaks
similar to the ones being fixed likely also affect other places of the
codebase. Those other places don't need to be fixed as part of this
series, but they might be good items for #leftoverbits or GSoC early
tasks (cc: Christian in case he wants to record those somewhere).
I cc'ed Stolee on patch 4 because he suggested he wanted to read it in
an earlier discussion.
Phillip noted some issues with patch 11, and I added a couple more.
The ownership of opts->strategy appears to be pretty messy and in need
of cleanup.
All the patches other than 11 look good to me.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 2/3] for-each-ref: let upstream/push optionally report merge name.
@ 2017-10-05 9:14 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-10-05 9:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, J Wyman
Junio C Hamano <gitster@pobox.com> writes:
> I think the remaining points from my reviews are:
>
> - It would be better to compute precomputable stuff when used atoms
> are parsed, instead of running starts_with() in these functions;
After reading the original (before these three patches) code for
populate_value(), I think reverting this mess back to how the thing
was originally envisioned to be would be outside the scope of this
addition. It was way too messy before your series than I expected.
So, unless you or your collaborator feel like helping us to clean up
the codebase for better future, let's forget about that point, and
leave the cleaning up for now.
For those who want to help with the #leftoverbits, the first step of
cleaning up would be to introduce an enum field that sits next to
used_atom[i].name, and have the if/else if/... cascades use that
instead of these starts_with(name) to choose what value to grab from
the given ref.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 2/4] remote: handle broken symrefs
@ 2017-10-19 17:53 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2017-10-19 17:53 UTC (permalink / raw)
To: Andrey Okoshkin
Cc: gitster, git, pclouds, l.s.r, avarab, krh, rctay89,
Ivan Arishchenko, Mikhail Labiuk
On Thu, Oct 19, 2017 at 01:47:30PM -0400, Jeff King wrote:
> This is hard to trigger in practice, since this function is
> used as a callback to for_each_ref(), which will skip broken
> refs in the first place (so it would have to be broken
> racily, or for us to see a transient filesystem error).
>
> If we see such a racy broken outcome let's treat it as "not
> a symref". This is exactly the same thing that would happen
> in the non-racy case (our function would not be called at
> all, as for_each_ref would skip the broken symref).
The fact that we have to re-resolve the ref here to find the symref
points to a short-coming in the for_each_ref() interface. It resolved
the ref already to get us the oid, so it should (or at least could) know
the symref details already. But it doesn't record them or make them
available to callers.
Ditto for patch 3. It doesn't use for_each_ref(), but I suspect it could
be recording the value of HEAD more carefully from the prior lookup,
avoiding the re-resolution completely.
Refactoring for_each_ref() is probably a bit big for a #leftoverbits,
but looking into the case in patch 3 might not be.
-Peff
^ permalink raw reply [relevance 6%]
* Re: Which macOS versions does Git support?
@ 2023-05-20 7:36 6% ` M Hickford
0 siblings, 0 replies; 200+ results
From: M Hickford @ 2023-05-20 7:36 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belón
Cc: Jeff King, M Hickford, Taylor Blau, Git Mailing List
On Sat, 20 May 2023 at 01:37, Carlo Marcelo Arenas Belón
<carenas@gmail.com> wrote:
>
> On Fri, May 19, 2023 at 05:09:17AM -0400, Jeff King wrote:
> >
> > I'd guess that anything older than 2009 is probably not worth worrying
> > about.
Thanks Jeff, Jeff and Carlo for your replies.
>
> FWIW Mac OS X 10.5 (Leopard) was last updated in 2009 and also happens to
> be the last one that can run in PowerPC, so sadly there is a non zero
> number of users for it (MacPorts uses a minimum of 10.4 for that reason)
Interesting! https://ports.macports.org/port/git/details/ It looks
like the most recent build is from 2021
https://ports.macports.org/port/git/builds/?builder_name__name=10.5_ppc_legacy
. https://ports.macports.org/port/git/stats/?days=365&days_ago=0
shows 10 total PowerPC downloads in the past year between versions
10.4, 10.5 and 10.6
>
> Carlo
I don't have the equipment or expertise to develop on macOS, so I'll
leave the API migration as a potential future #leftoverbits
Reading the keychain docs more carefully, the new API only supports a
fixed set of attribute keys such as 'kSecAttrComment', so discount my
original "further motivation"
https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute_keys_and_values?language=objc
^ permalink raw reply [relevance 6%]
* Re: [PATCH v4 8/8] rebase: cleanup action handling
@ 2022-10-21 17:54 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-10-21 17:54 UTC (permalink / raw)
To: Phillip Wood via GitGitGadget
Cc: git, Phillip Wood, Christian Couder, Elijah Newren,
Ævar Arnfjörð Bjarmason, Calvin Wan, Emily Shaffer,
Glen Choo, Victoria Dye, Phillip Wood
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> Treating the action as a string is a hang over from the scripted
> rebase. The last commit removed the only remaining use of the action
> that required a string so lets convert the other action users to use
> the existing action enum instead. If we ever need the action name as a
> string in the future the action_names array exists exactly for that
> purpose.
Nice.
#leftoverbit
Perhaps a clean-up worth making after the dust settles from this
series would be to use designated initialisers to avoid names and
their string values going out of sync, perhaps like
static const char *action_names[] = {
[ACTION_NONE] = "undefined",
[ACTION_CONTINUE] = "continue",
...
[ACTION_SHOW_CURRENT_PATCH] = "show_current_patch",
};
Unless the final element is something that must stay at the end even
when adding new member to a collection, it is a good idea to keep a
(seemingly unnecessary) comma at the end. That would make it easier
to add a new member without unnecessary patch noise.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 3/4] gitfaq: shallow cloning a repository
@ 2020-04-22 4:00 6% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2020-04-22 4:00 UTC (permalink / raw)
To: Derrick Stolee
Cc: Randall S. Becker, 'Junio C Hamano',
'Shourya Shukla', git, sandals, 'Derrick Stolee',
'Elijah Newren', 'Christian Couder'
Derrick Stolee wrote:
> Of course, with the speedups from reachability bitmaps, it is sometimes
> _faster_ to do a partial clone than a shallow clone. (It definitely takes
> less time in the "counting objects" phase, and the cost of downloading
> all commits and trees might be small enough on top of the necessary blob
> data to keep the total cost under a shallow clone. Your mileage may vary.)
> Because the cost of a partial clone is "comparable" to shallow clone, I
> would almost recommend partial clone over shallow clones 95% of the time,
> even in scenarios like automated builds on cloud-hosted VMs.
By the way, an idea for the interested (#leftoverbits?):
It would be possible to emulate the shallow clone experience making
use of the partial clone protocol. That is, fetch a full history
without blobs but record the "shallows" somewhere and make user-facing
traversals like "git log" stop there (similar to the effect "git
replace" has on user-facing traversals). Then later fetches would be
able to take advantage of the full commit history, but scripts and
muscle memory (e.g., the assumption that most commands will never
contact the remote) that assume a shallow clone would continue to
work.
Would that be useful or interesting to people?
Thanks,
Jonathan
^ permalink raw reply [relevance 6%]
* [PATCH 0/2] git-compat-util: move convert_slashes from compat/mingw.h and rename it
@ 2024-03-18 12:47 6% Mohit Marathe via GitGitGadget
0 siblings, 0 replies; 200+ results
From: Mohit Marathe via GitGitGadget @ 2024-03-18 12:47 UTC (permalink / raw)
To: git; +Cc: Mohit Marathe
Hi all,
This series aims to complete a #leftoverbits: https://lore.kernel.org/
git/xmqqzfw43xad.fsf@gitster.g/ by moving convert_slashes() to
git-compat-util.h and renaming it to change_path_separators().
I appreciate your review and feedback on this patch series.
Best regards, Mohit Marathe
Mohit Marathe (2):
git-compat-util: migrate `convert_slashes()` from compat/mingw.h
test-lib: replace repeated code logic with an existing helper
abspath.c | 4 ++--
compat/mingw.c | 4 ++--
compat/mingw.h | 6 ------
git-compat-util.h | 7 +++++++
path.c | 2 +-
t/unit-tests/test-lib.c | 9 +++------
6 files changed, 15 insertions(+), 17 deletions(-)
base-commit: 2953d95d402b6bff1a59c4712f4d46f1b9ea137f
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1699%2Fmohit-marathe%2Fconvert-slashes-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1699/mohit-marathe/convert-slashes-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1699
--
gitgitgadget
^ permalink raw reply [relevance 6%]
* Re: Git in Outreachy Dec-Mar?
@ 2018-09-06 19:31 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2018-09-06 19:31 UTC (permalink / raw)
To: Christian Couder; +Cc: Johannes Schindelin, git
On Thu, Sep 06, 2018 at 11:51:49AM +0200, Christian Couder wrote:
> > Thanks. I signed us up as a community (making me the "coordinator" in
> > their terminology). I think the procedure is a little different this
> > year, and we actually propose projects to mentor through their system.
>
> Yeah, I think the https://git.github.io/Outreachy-17/ is not actually necessary.
I think it still may be helpful for explaining in further detail things
like #leftoverbits (though I see you put some of that in your project
description).
> > So anybody interested in mentoring should go here:
> >
> > https://www.outreachy.org/communities/cfp/git/
> >
> > (and you'll need to create a login if you don't have one from last
> > year). You should be able to click through "Submit a Project Proposal",
> > after which the fields are pretty self-explanatory.
>
> I did that for the "Improve `git bisect`" project. As the
> "coordinator", you will need to approve that project.
Thanks. I approved it, though a few of the descriptions are a little
funny. For instance, the text says "we use an issue tracker", which then
links to public-inbox. I assume this is because you filled in a field
for "issue tracker" and then the system generated the text. I don't know
if there's a way go into more detail there.
> I think the person who submits a project becomes some kind of primary
> mentor for the project. So Dscho, if you want to be such a mentor for
> one or both of the other projects on the Outreachy-17 page, please
> submit the project(s) otherwise please tell me and I will submit them.
> You are free of course to change things in these projects when you
> submit them or to submit other completely different projects.
Yes, I think the point is make sure the mentors are invested in the
individual projects. I imagine a kind of "oh, one of us will probably
mentor it" attitude has led to problems in other projects in the past.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH 10/11] merge-ort: write $GIT_DIR/AUTO_MERGE whenever we hit a conflict
@ 2021-03-08 21:51 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2021-03-08 21:51 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Elijah Newren via GitGitGadget, Git Mailing List, Jonathan Nieder,
Derrick Stolee, Junio C Hamano
On Mon, Mar 8, 2021 at 5:11 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> On Fri, Mar 05 2021, Elijah Newren via GitGitGadget wrote:
>
> > From: Elijah Newren <newren@gmail.com>
> >
> > There are a variety of questions users might ask while resolving
> > conflicts:
> > * What changes have been made since the previous (first) parent?
> > * What changes are staged?
> > * What is still unstaged? (or what is still conflicted?)
> > * What changes did I make to resolve conflicts so far?
> > The first three of these have simple answers:
> > * git diff HEAD
> > * git diff --cached
> > * git diff
> > There was no way to answer the final question previously. Adding one
> > is trivial in merge-ort, since it works by creating a tree representing
> > what should be written to the working copy complete with conflict
> > markers. Simply write that tree to .git/AUTO_MERGE, allowing users to
> > answer the fourth question with
> > * git diff AUTO_MERGE
> >
> > I avoided using a name like "MERGE_AUTO", because that would be
> > merge-specific (much like MERGE_HEAD, REBASE_HEAD, REVERT_HEAD,
> > CHERRY_PICK_HEAD) and I wanted a name that didn't change depending on
> > which type of operation the merge was part of.
>
> That's a really cool feature. I'm starting to like this "ort" thing :)
>
> (After knowing almost nothing about it until a few days ago...)
>
> > Ensure that paths which clean out other temporary operation-specific
> > files (e.g. CHERRY_PICK_HEAD, MERGE_MSG, rebase-merge/ state directory)
> > also clean out this AUTO_MERGE file.
> >
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> > branch.c | 1 +
> > builtin/rebase.c | 1 +
> > merge-ort.c | 10 ++++++++++
> > path.c | 1 +
> > path.h | 2 ++
> > sequencer.c | 5 +++++
> > 6 files changed, 20 insertions(+)
> >
> > diff --git a/branch.c b/branch.c
> > index 9c9dae1eae32..b71a2de29dbe 100644
> > --- a/branch.c
> > +++ b/branch.c
> > @@ -344,6 +344,7 @@ void remove_merge_branch_state(struct repository *r)
> > unlink(git_path_merge_rr(r));
> > unlink(git_path_merge_msg(r));
> > unlink(git_path_merge_mode(r));
> > + unlink(git_path_auto_merge(r));
> > save_autostash(git_path_merge_autostash(r));
> > }
> >
> > diff --git a/builtin/rebase.c b/builtin/rebase.c
> > index de400f9a1973..7d9afe118fd4 100644
> > --- a/builtin/rebase.c
> > +++ b/builtin/rebase.c
> > @@ -739,6 +739,7 @@ static int finish_rebase(struct rebase_options *opts)
> > int ret = 0;
> >
> > delete_ref(NULL, "REBASE_HEAD", NULL, REF_NO_DEREF);
> > + unlink(git_path_auto_merge(the_repository));
> > apply_autostash(state_dir_path("autostash", opts));
> > close_object_store(the_repository->objects);
> > /*
> > diff --git a/merge-ort.c b/merge-ort.c
> > index 37b69cbe0f9a..cf927cd160e1 100644
> > --- a/merge-ort.c
> > +++ b/merge-ort.c
> > @@ -3362,6 +3362,9 @@ void merge_switch_to_result(struct merge_options *opt,
> > {
> > assert(opt->priv == NULL);
> > if (result->clean >= 0 && update_worktree_and_index) {
> > + const char *filename;
> > + FILE *fp;
> > +
> > trace2_region_enter("merge", "checkout", opt->repo);
> > if (checkout(opt, head, result->tree)) {
> > /* failure to function */
> > @@ -3380,6 +3383,13 @@ void merge_switch_to_result(struct merge_options *opt,
> > }
> > opt->priv = NULL;
> > trace2_region_leave("merge", "record_conflicted", opt->repo);
> > +
> > + trace2_region_enter("merge", "write_auto_merge", opt->repo);
> > + filename = git_path_auto_merge(opt->repo);
> > + fp = xfopen(filename, "w");
> > + fprintf(fp, "%s\n", oid_to_hex(&result->tree->object.oid));
> > + fclose(fp);
> > + trace2_region_leave("merge", "write_auto_merge", opt->repo);
>
> This isn't a new problem since you're just folling an existing pattern,
> but here you (rightly) do xopen()< and the:n
Looks like your comment got garbled/truncated. Do you remember the
rest of what you were going to say here?
> > }
> >
> > if (display_update_msgs) {
> > diff --git a/path.c b/path.c
> > index 7b385e5eb282..9e883eb52446 100644
> > --- a/path.c
> > +++ b/path.c
> > @@ -1534,5 +1534,6 @@ REPO_GIT_PATH_FUNC(merge_rr, "MERGE_RR")
> > REPO_GIT_PATH_FUNC(merge_mode, "MERGE_MODE")
> > REPO_GIT_PATH_FUNC(merge_head, "MERGE_HEAD")
> > REPO_GIT_PATH_FUNC(merge_autostash, "MERGE_AUTOSTASH")
> > +REPO_GIT_PATH_FUNC(auto_merge, "AUTO_MERGE")
> > REPO_GIT_PATH_FUNC(fetch_head, "FETCH_HEAD")
> > REPO_GIT_PATH_FUNC(shallow, "shallow")
> > diff --git a/path.h b/path.h
> > index e7e77da6aaa5..251c78d98000 100644
> > --- a/path.h
> > +++ b/path.h
> > @@ -176,6 +176,7 @@ struct path_cache {
> > const char *merge_mode;
> > const char *merge_head;
> > const char *merge_autostash;
> > + const char *auto_merge;
> > const char *fetch_head;
> > const char *shallow;
> > };
> > @@ -191,6 +192,7 @@ const char *git_path_merge_rr(struct repository *r);
> > const char *git_path_merge_mode(struct repository *r);
> > const char *git_path_merge_head(struct repository *r);
> > const char *git_path_merge_autostash(struct repository *r);
> > +const char *git_path_auto_merge(struct repository *r);
> > const char *git_path_fetch_head(struct repository *r);
> > const char *git_path_shallow(struct repository *r);
> >
> > diff --git a/sequencer.c b/sequencer.c
> > index d2332d3e1787..472cdd8c620d 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -2096,6 +2096,7 @@ static int do_pick_commit(struct repository *r,
> > refs_delete_ref(get_main_ref_store(r), "", "CHERRY_PICK_HEAD",
> > NULL, 0);
> > unlink(git_path_merge_msg(r));
> > + unlink(git_path_auto_merge(r));
>
> Shouldn't this & the rest ideally be at least unlink_or_warn()?
Perhaps, but I think that should be a follow-on series or
#leftoverbits. I'm having enough trouble getting reviews (I think I'm
burning Stolee out after the last half year) without making my series
longer for tangential cleanups. :-)
I'm starting to worry that despite having all the remaining patches
ready (and most have been ready for months), that we won't be able to
get merge-ort done before git-2.32 -- the -rc0 for it is now just
under three months away.
> > fprintf(stderr,
> > _("dropping %s %s -- patch contents already upstream\n"),
> > oid_to_hex(&commit->object.oid), msg.subject);
> > @@ -2451,6 +2452,8 @@ void sequencer_post_commit_cleanup(struct repository *r, int verbose)
> > need_cleanup = 1;
> > }
> >
> > + unlink(git_path_auto_merge(r));
> > +
> > if (!need_cleanup)
> > return;
> >
> > @@ -4111,6 +4114,7 @@ static int pick_commits(struct repository *r,
> > unlink(rebase_path_stopped_sha());
> > unlink(rebase_path_amend());
> > unlink(git_path_merge_head(r));
> > + unlink(git_path_auto_merge(r));
> > delete_ref(NULL, "REBASE_HEAD", NULL, REF_NO_DEREF);
> >
> > if (item->command == TODO_BREAK) {
> > @@ -4505,6 +4509,7 @@ static int commit_staged_changes(struct repository *r,
> > return error(_("could not commit staged changes."));
> > unlink(rebase_path_amend());
> > unlink(git_path_merge_head(r));
> > + unlink(git_path_auto_merge(r));
> > if (final_fixup) {
> > unlink(rebase_path_fixup_msg());
> > unlink(rebase_path_squash_msg());
^ permalink raw reply [relevance 6%]
* [PATCH 0/2] Do not call cmd_*() as a subroutine
2017-09-05 10:03 6% ` Junio C Hamano
@ 2017-10-10 4:06 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-10-10 4:06 UTC (permalink / raw)
To: git
These two patches are for a recent #leftoverbits topic.
https://public-inbox.org/git/xmqqr2vlbgyk.fsf@gitster.mtv.corp.google.com/
The cmd_foo() function is a moral equivalent of 'main' for a Git
subcommand 'git foo', and as such, it is allowed to do many things
that make it unsuitable to be called as a subroutine, including
- call exit(3) to terminate the process;
- allocate resource held and used throughout its lifetime, without
releasing it upon return/exit;
- rely on global variables being initialized at program startup,
and update them as needed, making another clean invocation of the
function impossible.
Correcting two callers by using helper API calls is not so hard.
Junio C Hamano (2):
describe: do not use cmd_*() as a subroutine
merge-ours: do not use cmd_*() as a subroutine
builtin/describe.c | 15 +++++++++++----
builtin/merge-ours.c | 16 +++++++---------
2 files changed, 18 insertions(+), 13 deletions(-)
--
2.15.0-rc0-203-g4c8d0e28b1
^ permalink raw reply [relevance 6%]
* Re: Enhancement request: git-push: Allow (configurable) default push-option
@ 2017-10-03 16:53 6% ` Stefan Beller
0 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2017-10-03 16:53 UTC (permalink / raw)
To: Marius Paliga; +Cc: git@vger.kernel.org
On Tue, Oct 3, 2017 at 3:15 AM, Marius Paliga <marius.paliga@gmail.com> wrote:
> There is a need to pass predefined push-option during "git push"
> without need to specify it explicitly.
>
> In another words we need to have a new "git config" variable to
> specify string that will be automatically passed as "--push-option"
> when pushing to remote.
>
> Something like the following:
>
> git config push.optionDefault AllowMultipleCommits
>
> and then command
> git push
> would silently run
> git push --push-option "AllowMultipleCommits"
We would need to
* design this feature (seems like you already have a good idea what you need)
* implement it (see builtin/push.c):
- move "struct string_list push_options = STRING_LIST_INIT_DUP;"
to be a file-static variable, such that we have access to it outside
of cmd_push.
- In git_push_config in builtin/push.c that parses the config, we'd
need to check
for "push.optionDefault" and add these to the push_options (I assume multiple
are allowed)
* document it (Documentation/git-push.txt)
* add a test for it ? (t/t5545-push-options.sh)
Care to write a patch? Otherwise I'd mark it up as part of
#leftoverbits for now,
as it seems like a good starter project.
Thanks,
Stefan
^ permalink raw reply [relevance 6%]
* Re: Should rerere auto-update a merge resolution?
@ 2017-08-25 17:08 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-08-25 17:08 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Martin Langhoff <martin.langhoff@gmail.com> writes:
>>
>>> - when I tell it to forget, won't it forget the pre-resolution state?
>>
>> I do not recall the details of what I did ;-) so I played around a
>> bit. Here is what I did:
>> ...
>> After git rerere forget, I observe (check subdirectories in
>> .git/rr-cache/ whose timestamps are recent) that postimage gets
>> removed but preimage and thisimage stay.
>
> Having said that, I suspect that it may be a bug if this procedure
> kept the original preimage. It should either remove it, or update
> it to record the state before the ealier resolution was applied
> (i.e. make the updated preimage identical to thisimage, so that a
> corrected resolution can be taken from the working tree to pair with
> it).
I just made a cursory scan of rerere.c again, and it seems we are
doing the right thing. The details are in rerere_forget_one_path()
where we unlink postimage, we recreate the conflicted state from the
stages in the index and update preimage.
It seems that code gives up if you already declared that you'd take
the previous resolution by adding the result to the index. It may
probably be a good idea to unmerge such a merged index entry instead
of giving up. #leftoverbits
So, yes, it will forget both preimage and postimage, and it should
update the preimage with the conflict you got during _this_ merge,
so that the resolution you make _this_ time will become usable as
the corresponding postimage for the next time.
^ permalink raw reply [relevance 6%]
* Re: [PATCHv3 0/5] Simple fixes to t7406
@ 2018-08-18 20:52 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2018-08-18 20:52 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Git Mailing List, Junio C Hamano, Eric Sunshine,
Martin Ågren
Hi,
On Mon, Aug 13, 2018 at 1:28 PM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> On Tue, Aug 7, 2018 at 6:49 PM Elijah Newren <newren@gmail.com> 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 hate to be that guy... but since those who already
> commented on previous rounds are not explicitly excluded from the
> challenge, let's see.
>
> - There are still a few command substitutions running git commands,
> where the exit status of that command is ignored; just look for the
> '[^=]$(' pattern in the test script.
>
> (Is not noticing those cases considered as "flubbing"?)
Hmm, borderline.
> - The 'compare_head' helper function defined in this test script looks
> very similar to the generally available 'test_cmp_rev' function,
> which has the benefit to provide some visible output on failure
> (though, IMO, not a particularly useful output, because the diff of
> two OIDs is not very informative, but at least it's something as
> opposed to the silence of 'test $this = $that").
>
> Now, since 'compare_head' always compares the same two revisions,
> namely 'master' and HEAD, replacing 'compare_head' with an
> appropriate 'test_cmp_rev' call would result in repeating 'master'
> and 'HEAD' arguments all over the test script. I'm not sure whether
> that's good or bad. Anyway, I think that 'compare_head' could be
> turned into a wrapper around 'test_cmp_rev'.
Ooh, that does sound better.
> > - You get bonus points if that thing is in the context region for
> > one of my five patches.
> > - Extra bonus points if the thing needing fixing was on a line I
> > changed.
> > - You win outright if it's something big enough that I give up and
> > request to just have my series merged as-is and punt your
> > suggested fixes down the road to someone else.
>
> Well, there's always the indentation of the commands run in subshells,
> which doesn't conform to our coding style...
>
> Gah, now you made me that guy ;)
I read this on Monday and got a really good laugh. I meant to fix it
up, but fell asleep too soon the first couple nights...and now this
series is in next anyway and there are a couple other git things that
have my attention. You have pointed out a couple additional nice
fixups, like you always do, but I think at this point I'm just going
to declare you the winner and label these as #leftoverbits.
Thanks for always thoroughly looking over the testcase patches and
your constant work to improve the testsuite.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2] receive-pack: purge temporary data if no command is ready to run
@ 2022-02-04 1:17 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-02-04 1:17 UTC (permalink / raw)
To: Chen BoJun
Cc: git, Chen Bojun, Ævar Arnfjörð Bjarmason,
Jiang Xin, Teng Long
Chen BoJun <bojun.cbj@gmail.com> writes:
> + /*
> + * If there is no command ready to run, should return directly to destroy
> + * temporary data in the quarantine area.
> + */
> + for (cmd = commands; cmd && cmd->error_string; cmd = cmd->next)
> + ; /* nothing */
> + if (!cmd)
> + return;
> +
> /*
> * Now we'll start writing out refs, which means the objects need
> * to be in their final positions so that other processes can see them.
One thing I notice is that the first thing we do, after making the
new objects available to us, is to check if we are making any
conflicting update, e.g.
git push origin master:master next:master
would try to update the same ref with different objects, and will be
rejected.
This check can _almost_ be doable without being able to access the
new objects, and as a follow-on work, it might not be a bad little
project to see how we can move the call to check_aliased_updates()
before this loop we are adding in this patch (#leftoverbits).
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/4] rebase -i: demonstrate obscure loose object cache bug
@ 2019-03-13 22:27 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2019-03-13 22:27 UTC (permalink / raw)
To: Jeff King
Cc: Ævar Arnfjörð Bjarmason,
Johannes Schindelin via GitGitGadget, git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]
Hi Ævar & Peff,
On Wed, 13 Mar 2019, Jeff King wrote:
> On Wed, Mar 13, 2019 at 05:11:44PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> > > And this is where the loose object cache interferes with this
> > > feature: if *some* loose object was read whose hash shares the same
> > > first two digits with a commit that was not yet created when that
> > > loose object was created, then we fail to find that new commit by
> > > its short name in `get_oid()`, and the interactive rebase fails with
> > > an obscure error message like:
> > >
> > > error: invalid line 1: pick 6568fef
> > > error: please fix this using 'git rebase --edit-todo'.
>
> Are we 100% sure this part is necessary? From my understanding of the
> problem, even without any ambiguity get_oid() could fail due to just
> plain not finding the object in question.
Indeed. It could be a typo, for example. Which is why that error message
is so helpful.
> > As a further improvement, is there a good reason for why we wouldn't
> > pass something down to the oid machinery to say "we're only interested
> > in commits". I have a WIP series somewhere to generalize that more, but
> > e.g. here locally:
>
> We have get_oid_commit() and get_oid_committish() already. Should rebase
> just be using those? (I think we probably want "commit()", because we do
> not expect a "pick" line to have a tag, for example.
I did think about this while developing this patch series, and decided
against conflating concerns.
And I was totally right to do so! Because I do have an internal ticket
that talks about allowing `reset v2.20.1`, which is a tag, not a commit.
Granted, it is easy to work around: just use `reset v2.20.1^0`, but it is
quite annoying that we do not allow this at the moment: even if we do
allow `get_oid()` to resolve the tag, we don't peel it to the commit.
#leftoverbits
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* [BUG] url schemes should be case-insensitive
@ 2018-06-24 8:56 6% Jeff King
2018-06-25 18:19 6% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Jeff King @ 2018-06-24 8:56 UTC (permalink / raw)
To: git
We seem to match url schemes case-sensitively:
$ git clone SSH://example.com/repo.git
Cloning into 'repo'...
fatal: Unable to find remote helper for 'SSH'
whereas rfc3986 is clear that the scheme portion is case-insensitive.
We probably ought to match at least our internal ones with strcasecmp.
Possibly we should also normalize external helpers (so "FOO://bar" would
always call git-remote-foo, never git-remote-FOO).
We could probably also give an advise() message in the above output,
suggesting that the problem is likely one of:
1. They misspelled the scheme.
2. They need to install the appropriate helper.
This may be a good topic for somebody looking for low-hanging fruit to
get involved in development (I'd maybe call it a #leftoverbits, but
since I didn't start on it, I'm not sure if it counts as "left over" ;)).
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option
@ 2017-10-12 2:41 6% ` Christian Couder
0 siblings, 1 reply; 200+ results
From: Christian Couder @ 2017-10-12 2:41 UTC (permalink / raw)
To: Junio C Hamano, Thais D. Braz
Cc: marius.paliga, git, Stefan Beller, Jeff King
On Thu, Oct 12, 2017 at 3:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Thais D. Braz" <thais.dinizbraz@gmail.com> writes:
>
>> ---
>> Documentation/git-push.txt | 3 +++
>> builtin/push.c | 9 ++++++++-
>> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> Can somebody explain what is going on?
>
> I am guessing that Thais and marius are different people (judging by
> the fact that one CC's a message to the other). Are you two
> collaborating on this change, or something?
I guess that Thais decided to work on this, because we ask Outreachy
applicants to search for #leftoverbits mentions in the mailing list
archive to find small tasks they could work on.
In this case it looks like Marius sent a patch a few hours before
Thais also sent one.
Thais, I am sorry, but as Marius sent a patch first, I think it is
better if you search for another different small task to work on.
Also please keep Peff and me in cc.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [RFC PATCH 0/1] commit-graph.c: handle corrupt commit trees
@ 2019-09-04 21:21 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2019-09-04 21:21 UTC (permalink / raw)
To: Garima Singh; +Cc: Taylor Blau, stolee, git, peff
Hi Garima,
On Wed, Sep 04, 2019 at 02:25:55PM -0400, Garima Singh wrote:
>
> On 9/3/2019 10:22 PM, Taylor Blau wrote:
> > Hi,
> >
> > I was running some of the new 'git commit-graph' commands, and noticed
> > that I could consistently get 'git commit-graph write --reachable' to
> > segfault when a commit's root tree is corrupt.
> >
> > I have an extremely-unfinished fix attached as an RFC PATCH below, but I
> > wanted to get a few thoughts on this before sending it out as a non-RFC.
> >
> > In my patch, I simply 'die()' when a commit isn't able to be parsed
> > (i.e., when 'parse_commit_no_graph' returns a non-zero code), but I
> > wanted to see if others thought that this was an OK approach. Some
> > thoughts:
>
> I like the idea of completely bailing if the commit can't be parsed too.
> Only question: Is there a reason you chose to die() instead of BUG() like
> the other two places in that function? What is the criteria of choosing one
> over the other?
I did not call 'BUG' here because 'BUG' is traditionally used to
indicate an internal bug, e.g., an unexpected state or some such. On the
other side of that coin, 'BUG' is _not_ used to indicate repository
corruption, since that is not an issue in the Git codebase, rather in
the user's repository.
Though, to be honest, I've never seen that rule written out explicitly
(maybe if it were to be written somewhere, it could be stored in
Documentation/CodingGuidelines?). I think that this is some good
#leftoverbits material.
> >
> > * It seems like we could write a commit-graph by placing a "filler"
> > entry where the broken commit would have gone. I don't see any place
> > where this is implemented currently, but this seems like a viable
> > alternative to not writing _any_ commits into the commit-graph.
>
> I would rather we didn't do this cause it will probably kick open the can of
> always watching for that filler when we are working with the commit-graph.
> Or do we already do that today? Maybe @stolee can chime in on what we do in
> cases of shallow clones and other potential gaps in the walk
Yeah, I think that the consensus is that it makes sense to just die
here, which is fine by me.
> -Garima
Thanks,
Taylor
^ permalink raw reply [relevance 6%]
* Re: [PATCH v5 4/7] refs: add support for transactional symref updates
@ 2024-05-02 7:47 6% ` Patrick Steinhardt
0 siblings, 0 replies; 200+ results
From: Patrick Steinhardt @ 2024-05-02 7:47 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Junio C Hamano, christian.couder, git
[-- Attachment #1: Type: text/plain, Size: 2947 bytes --]
On Thu, May 02, 2024 at 05:50:47AM +0000, Karthik Nayak wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> > Karthik Nayak <karthik.188@gmail.com> writes:
> >> From: Karthik Nayak <karthik.188@gmail.com>
> >> We do not add reflog for dangling symref updates, because currently
> >> 'git-symbolic-ref' doesn't add reflog for dangling symref updates and it
> >> would be best to keep this behavior consistent as we would move it to
> >> start using transaction based updates in the following commit.
> >
> > If we are not changing the behaviour, does it deserve a four-line
> > paragraph? It is not like we describe every no changes (i.e. "we
> > could break the behaviour by introducing this and that bugs, but we
> > did not" is not something we usually say in proposed log messages).
> >
> > At most, if you want to highlight that behaviour, I would expect a
> > brief mention like:
> >
> > Note that a dangling symref update does not record a new reflog
> > entry, which is unchanged before and after this commit.
> >
> > As a reflog entry records name of the object that is pointed by the
> > ref (either directly or indirectly) before and after an operation,
> > an operation that involve a dangling reflog that does not point at
> > any object cannot be expressed in a reflog, no? It is way too late
> > to change this, but it would have been interesting if the design of
> > reflog had a room to log the change of symbolic ref target as well
> > as object names. It would have allowed us to say "HEAD at time T
> > pointed at refs/heads/main (which did not exist)", "HEAD at time T+1
> > directly pointed at commit X (detached)", "HEAD at time T+2 pointed
> > at refs/heads/next", etc. and allowed us to much more cleanly
> > support "previous branch".
> >
>
> While I agree that four lines may seem excessive, I think it is indeed
> an important point to note. Mostly because this shows that when doing
> dangling symref updates, there is no record of this update. The best
> situation would be like you mentioned, to record the symref target
> changes. But even with the current design, it would have been nice to at
> least acknowledge that there was some update done to the symref. By
> having zero-oid for the new and old value in the reflog. But seems like
> we can't do that either.
I wouldn't say we can't do that. We already do log when symrefs become
dangling when updating references via HEAD by logging a zero OID as new
OID. That is, if we have "HEAD -> refs/heads/foo" and you delete the
latter, then we create a new reflog message for "HEAD" with zero OID as
new OID.
I would claim that the current behaviour where we don't create a reflog
entry when updating a ref to become dangling is a mere bug. I think it's
fair to declare this a #leftoverbit and handle it in a follow-up patch
series. But it would be nice to say so in an in-code comment.
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [relevance 6%]
* Re: [PATCH] is_promisor_object(): fix use-after-free of tree buffer
@ 2022-08-15 22:53 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2022-08-15 22:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrew Olsen, Jonathan Tan, git
On Sun, Aug 14, 2022 at 10:32:12PM -0700, Junio C Hamano wrote:
> > We're in the middle of walking through the entries of a tree object via
> > process_tree_contents(). We see a blob (or it could even be another tree
> > entry) that we don't have, so we call is_promisor_object() to check it.
> > That function loops over all of the objects in the promisor packfile,
> > including the tree we're currently walking.
>
> I forgot that the above "loops over" happens only once to populate
> the oidset hashtable, and briefly wondered if we are being grossly
> inefficient by scanning pack .idx file each time we encounter a
> missing object. "Upon first call, that function loops over
> ... walking, to prepare a hashtable to answer if any object id is
> referred to by an object in promisor packs" would have helped ;-).
Right. When you have worked in an area, sometimes it is easy to forget
which things are common knowledge and which are not. :) I don't mind at
all if you want to amend the commit message as you apply.
> > It may also be a good direction for this function in general, as there
> > are other possible optimizations that rely on doing some analysis before
> > parsing:
> >
> > - we could detect blobs and avoid reading their contents; they can't
> > link to other objects, but parse_object() doesn't know that we don't
> > care about checking their hashes.
> >
> > - we could avoid allocating object structs entirely for most objects
> > (since we really only need them in the oidset), which would save
> > some memory.
> >
> > - promisor commits could use the commit-graph rather than loading the
> > object from disk
> >
> > This commit doesn't do any of those optimizations, but I think it argues
> > that this direction is reasonable, rather than relying on parse_object()
> > and trying to teach it to give us more information about whether it
> > parsed.
>
> Yeah, all of the future bits sound sensible.
I very intentionally didn't work on those things yet, because I wanted
to make sure we got a simple fix in as quickly as possible. That said, I
don't have immediate plans for them. They are perhaps not quite small
enough for #leftoverbits, but I think they might also be nice bite-sized
chunks for somebody wanting to get their feet wet in that part of the
code.
-Peff
^ permalink raw reply [relevance 6%]
* [PATCH] branch: reset instead of release a strbuf
@ 2017-10-03 21:14 6% Stefan Beller
0 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2017-10-03 21:14 UTC (permalink / raw)
To: git; +Cc: Stefan Beller
Our documentation advises to not re-use a strbuf, after strbuf_release
has been called on it. Use the proper reset instead.
Signed-off-by: Stefan Beller <sbeller@google.com>
---
Maybe one of the #leftoverbits is to remove the re-init call in release
and see what breaks? (And then fixing up more of such cases as presented
in this patch)
Thanks,
Stefan
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index b998e16d0c..9758012390 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -217,7 +217,7 @@ static int delete_branches(int argc, const char **argv, int force, int kinds,
if (!head_rev)
die(_("Couldn't look up commit object for HEAD"));
}
- for (i = 0; i < argc; i++, strbuf_release(&bname)) {
+ for (i = 0; i < argc; i++, strbuf_reset(&bname)) {
char *target = NULL;
int flags = 0;
--
2.14.0.rc0.3.g6c2e499285
^ permalink raw reply related [relevance 6%]
* Re: [PATCH 1/2] update-ref: Allow creation of multiple transactions
@ 2020-11-06 19:30 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-11-06 19:30 UTC (permalink / raw)
To: Jeff King; +Cc: Patrick Steinhardt, git
Jeff King <peff@peff.net> writes:
> On Thu, Nov 05, 2020 at 01:34:20PM -0800, Junio C Hamano wrote:
>
>> > The tests all look quite reasonable to me. Touching .git/refs like this
>> > is a bit gross (and something we may have to deal with if we introduce
>> > reftables, etc). But it's pretty pervasive in this file, so matching
>> > the existing style is the best option for now.
>> ...
> Yeah, I agree completely that we could be using rev-parse in this
> instance. But it's definitely not alone there:
> ...
Yup, this morning I was reviewing what we said in the previous day's
exchanges and noticed that you weren't advocating but merely saying
it is not making things worse, and I agree with the assessment.
Perhaps two #leftoverbits are to
(1) clean up this test to create refs using "update-ref", and
verify refs using "show-ref --verify".
(2) If (1) had to leave some direct filesystem access due to the
built-in safety that cannot be circumvented, decide which is
more appropirate between a test-update-ref test helper only to
be used in tests, or a "--force" option usable to corrupt
repositories with "update-ref", implement it, and use it to
finish cleaning up tests.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/2] show-ref --verify: accept pseudorefs
@ 2024-02-07 17:12 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-02-07 17:12 UTC (permalink / raw)
To: Phillip Wood via GitGitGadget; +Cc: git, Patrick Steinhardt, Phillip Wood
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> ... when CHERRY_PICK_HEAD exists. By calling refname_is_safe() instead
> of comparing the refname to "HEAD" we can accept all one-level refs that
> contain only uppercase ascii letters and underscores.
Geez. We have at least three implementations to determine if a ref
is a valid name?
> diff --git a/builtin/show-ref.c b/builtin/show-ref.c
> index 79955c2856e..1c15421e600 100644
> --- a/builtin/show-ref.c
> +++ b/builtin/show-ref.c
> @@ -172,7 +172,7 @@ static int cmd_show_ref__verify(const struct show_one_options *show_one_opts,
> while (*refs) {
> struct object_id oid;
>
> - if ((starts_with(*refs, "refs/") || !strcmp(*refs, "HEAD")) &&
> + if ((starts_with(*refs, "refs/") || refname_is_safe(*refs)) &&
I think the helper you picked is the most sensible one, modulo a few
nits.
- We would want to teach refname_is_safe() to honor is_pseudoref()
from Karthik's series to make rules more consistent.
- The refname_is_safe() helper is not just about the stuff at the
root level. While starts_with("refs/") is overly lenient, it
rejects nonsense like "refs/../trash". We would want to lose
"starts_with() ||" part of the condition from here.
These are minor non-blocking nits that we should keep in mind only
for longer term maintenance, #leftoverbits after the dust settles.
Will queue.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option
2017-10-17 3:47 10% ` [PATCH] patch reply Thais Diniz
@ 2017-10-17 3:58 6% ` thais braz
1 sibling, 0 replies; 200+ results
From: thais braz @ 2017-10-17 3:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, marius.paliga, git, Stefan Beller, Jeff King
Just to clarify I did not see Marius patch.
Did see Marius' comment saying he would look it in the leftoverbits list,
but since i didn't see any patch i thought i could work on it and did
so based on Stephan's comment
(which i suppose Mario also did and that is why the code resulted to
be similar).
And sorry send this email as patch. Didn't know how to use git
send-email just as reply
On Thu, Oct 12, 2017 at 12:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>>> Can somebody explain what is going on?
>>>
>>> I am guessing that Thais and marius are different people (judging by
>>> the fact that one CC's a message to the other). Are you two
>>> collaborating on this change, or something?
>>
>> I guess that Thais decided to work on this, because we ask Outreachy
>> applicants to search for #leftoverbits mentions in the mailing list
>> archive to find small tasks they could work on.
>>
>> In this case it looks like Marius sent a patch a few hours before
>> Thais also sent one.
>
> ... after seeing Marius's already working on it, I think.
>
>> Thais, I am sorry, but as Marius sent a patch first, I think it is
>> better if you search for another different small task to work on.
>
> In general, I do not mind seeing people working together well, and
> it is one of the more important skills necessary in the open source
> community. I however tend to agree with you that this is a bit too
> small a topic for multiple people to be working on.
>
>> Also please keep Peff and me in cc.
>
> Yup, that is always a good idea.
>
--
Atenciosamente Thais Diniz Braz
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 0/3] replace test [-f|-d] with more verbose functions
@ 2022-02-23 22:59 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-02-23 22:59 UTC (permalink / raw)
To: COGONI Guillaume
Cc: avarab, git.jonathan.bressat, git, guillaume.cogoni, matthieu.moy
COGONI Guillaume <cogoni.guillaume@gmail.com> writes:
> Make the code more readable in t/t3903-stash.sh and give more
> friendly error message by replacing test [-f|-d] by the right
> test_path_is_* functions.
> Add new functions like test_path_is_* to cover more specifics
> cases like symbolic link or file that we explicitly refuse
> to be symbolic link.
All three look good to me.
Will queue.
As a possible #leftoverbits material, I suspect that we would
eventually want to be able to say
test_path_is_file ! "$error_if_I_am_a_file"
test_path_is_dir ! "$error_if_I_am_a_dir"
test_path_is_symlink ! "$error_if_I_am_a_symlink"
so that we do not have to have the two ugly-looking special-case
combination "test_path_is_X_not_symlink" but just express what we
want with
test_path_is_file "$path" && test_path_is_symlink ! "$path"
Once that happens, the two helpers introduced with 2/3 of this
series would become
test_path_is_file_not_symlink () {
test $# = 1 || BUG "1 param"
test_path_is_file "$1" &&
test_path_is_symlink ! "$1"
}
But I do not want to see that as part of this series. Let's
conclude this series and declare a success.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] CodingGuidelines: quote assigned value with "local" and "export"
@ 2024-04-05 16:21 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-04-05 16:21 UTC (permalink / raw)
To: git; +Cc: Patrick Steinhardt, Eric Sunshine, René Scharfe
Somebody may want to inspect the output from
$ git grep -E -i -e '^ *(local|export) [a-z0-9_]*=\$'
and fix those that can be used with dash. I made a cursory scan and
removed obviously safe ones whose RHS will never have $IFS whitespaces,
and the following are remainders. #leftoverbits
t/t0610-reftable-basics.sh: local actual=$(ls -l "$file") &&
t/test-lib-functions.sh: local file=${2:-"$1.t"} &&
t/test-lib-functions.sh: local basename=${1#??}
t/test-lib-functions.sh: local var=$1 port
t/test-lib-functions.sh: local expr=$(printf '"%s",' "$@")
t/test-lib-functions.sh: local inc=${2:-0} &&
t/test-lib-functions.sh: local inc=${2:-0} &&
t/test-lib-functions.sh: local ret=$?
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 13/13] format-patch: learn --infer-cover-subject option
@ 2019-08-23 18:46 6% ` Philip Oakley
0 siblings, 0 replies; 200+ results
From: Philip Oakley @ 2019-08-23 18:46 UTC (permalink / raw)
To: Denton Liu, Junio C Hamano
Cc: Git Mailing List, Ævar Arnfjörð Bjarmason,
Eric Sunshine
On 23/08/2019 19:15, Denton Liu wrote:
>> Having said that, I suspect that in the longer term, people would
>> want to see this new behaviour with a bit of tweak become the new
>> default.
>>
>> The "tweak" I suspect is needed is to behave sensibly when "the
>> first line" ends up to be too long a subject. Whether we make this
>> the new default or keep this optional, the issue exists either way.
> The reason why I chose to make this an "opt-in" option was because there
> currently doesn't exist a standard on how to write branch descriptions
> like there does for commit messages (i.e. subject then body, subject
> less than x characters). However, against best practices, some
> developers like to have really long subjects. As a result, there's no
> "real" way of telling whether the first paragraph is a long subject or a
> short paragraph.
>
> As a result, we should allow the cover subject to be read from the
> branch description only if the developer explicitly chooses this (either
> with `--infer-cover-subject` the config option). This way, we won't have
> to deal with the ambiguity of deciding whether or not the first
> paragraph is truly a subject and stepping on users' toes if we end up
> deciding wrong.
>
> Thoughts?
Perhaps the `--infer-cover-subject` the config option needs to be
multi-valued to include:
"subject" (always expect short first lines) or
"message" (always the long paragraph description, still use
***Subject Here***),
with the "true" being used when expecting both as previously
described.
--
Philip
As an aside, for format-patch to learn a --branch-version option that
creates a branch with the '-vN' suffix to the current branch when the
-vN option is used would be a useful addition (as long as the formatted
refs are first parent to the current branch). #todo list #leftoverbits
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 04/24] Documentation: build 'technical/bitmap-format' by default
@ 2021-07-21 17:23 6% ` Taylor Blau
0 siblings, 1 reply; 200+ results
From: Taylor Blau @ 2021-07-21 17:23 UTC (permalink / raw)
To: Jeff King; +Cc: git, dstolee, gitster, jonathantanmy
On Wed, Jul 21, 2021 at 06:08:18AM -0400, Jeff King wrote:
> On Wed, Jul 21, 2021 at 05:58:41AM -0400, Jeff King wrote:
>
> > On Mon, Jun 21, 2021 at 06:25:07PM -0400, Taylor Blau wrote:
> >
> > > Even though the 'TECH_DOCS' variable was introduced all the way back in
> > > 5e00439f0a (Documentation: build html for all files in technical and
> > > howto, 2012-10-23), the 'bitmap-format' document was never added to that
> > > list when it was created.
> > >
> > > Prepare for changes to this file by including it in the list of
> > > technical documentation that 'make doc' will build by default.
> >
> > OK. I don't care that much about being able to format this as html, but
> > I agree it's good to be consistent with the other stuff in technical/.
> >
> > The big question is whether it looks OK rendered by asciidoc, and the
> > answer seems to be "yes" (from a cursory look I gave it).
>
> Actually, I take it back. After looking more carefully, it renders quite
> poorly. There's a lot of structural indentation that ends up being
> confused as code blocks.
>
> I don't know if it's better to have a poorly-formatted HTML file, or
> none at all. :)
>
> Personally, I would just read the source. And I have a slight concern
> that if we start "cleaning it up" to render as asciidoc, the source
> might end up a lot less readable (though I'd reserve judgement until
> actually seeing it).
Yeah, the actual source is pretty readable (and it's what I had been
looking at, although it is sometimes convenient to have a version I can
read in my web browser). But it's definitely not good Asciidoc.
I briefly considered cleaning it up, but decided against it. Usually I
would opt to clean it up, but this series is already so large that I
figured it would make a negative impact on the reviewer experience to
read a clean-up patch here.
I wouldn't be opposed to coming back to it in the future, once the dust
settles. I guess we can consider this #leftoverbits until then.
Thanks,
Taylor
^ permalink raw reply [relevance 6%]
* Re: git-log: documenting pathspec usage
@ 2020-11-16 12:37 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2020-11-16 12:37 UTC (permalink / raw)
To: Adam Spiers; +Cc: git mailing list
On Mon, Nov 16 2020, Adam Spiers wrote:
> Hi all,
>
> I just noticed that git-log.txt has:
>
> SYNOPSIS
> --------
> [verse]
> 'git log' [<options>] [<revision range>] [[--] <path>...]
>
> and builtin/log.c has:
>
> static const char * const builtin_log_usage[] = {
> N_("git log [<options>] [<revision-range>] [[--] <path>...]"),
>
> IIUC, the references to <path> should actually be <pathspec> instead,
> as seen with other pathspec-supporting commands such as git add/rm
> whose man pages are extra helpful in explicitly calling out how
> pathspecs can be used, e.g.:
>
> OPTIONS
> -------
> <pathspec>...::
> Files to add content from. Fileglobs (e.g. `*.c`) can
> be given to add all matching files. Also a
> leading directory name (e.g. `dir` to add `dir/file1`
> and `dir/file2`) can be given to update the index to
> match the current state of the directory as a whole (e.g.
> specifying `dir` will record not just a file `dir/file1`
> modified in the working tree, a file `dir/file2` added to
> the working tree, but also a file `dir/file3` removed from
> the working tree). Note that older versions of Git used
> to ignore removed files; use `--no-all` option if you want
> to add modified or new files but ignore removed ones.
> +
> For more details about the <pathspec> syntax, see the 'pathspec' entry
> in linkgit:gitglossary[7].
>
> Would it be fair to say the git-log usage syntax and man page should
> be updated to match? If so perhaps I can volunteer for that.
It seems like a good idea to make these consistent, if you're feeling
more ambitious than just git-log's manpage then:
$ git grep '<pathspec>' -- Documentation/git-*.txt|wc -l
54
$ git grep '<path>' -- Documentation/git-*.txt|wc -l
161
Most/all of these should probably be changed to one or the other.
I've also long wanted (but haven't come up with a patch for) that part
of gitglossary to be ripped out into its own manual page,
e.g. "gitpathspec(5)". And if possible for "PATTERN FORMAT" in
"gitignore" to be unified with that/other docs that describe how our
wildmatch.c works.
There's also the "Conditional includes" section in git-config(1) that
repeats some of that, and probably other stuff I'm forgetting
#leftoverbits.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] revision: mark blobs needed for resolve-undo as reachable
@ 2022-06-15 20:47 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2022-06-15 20:47 UTC (permalink / raw)
To: Jeff King
Cc: Taylor Blau, Derrick Stolee,
Ævar Arnfjörð Bjarmason, Junio C Hamano, git
On Tue, Jun 14, 2022 at 11:48:20PM -0400, Jeff King wrote:
> On Tue, Jun 14, 2022 at 10:02:32PM -0400, Taylor Blau wrote:
>
> > --- >8 ---
> >
> > diff --git a/string-list.h b/string-list.h
> > index d5a744e143..425abc55f4 100644
> > --- a/string-list.h
> > +++ b/string-list.h
> > @@ -143,7 +143,7 @@ int for_each_string_list(struct string_list *list,
> >
> > /** Iterate over each item, as a macro. */
> > #define for_each_string_list_item(item,list) \
> > - for (item = (list)->items; \
> > + for (item = (list) ? (list)->items : NULL; \
> > item && item < (list)->items + (list)->nr; \
> > ++item)
> >
> > --- 8< ---
> >
> > > but even with your suggestion, I get this compiler error:
> >
> > ...so did I. Though I'm not sure I understand the compiler's warning
> > here. Surely the thing being passed as list in the macro expansion
> > _won't_ always evaluate to non-NULL, will it?
>
> In the general case, no, but in this specific expansion of the macro, it
> is passing the address of a local variable (&cpath), which will never be
> NULL. The compiler is overeager here; the check is indeed pointless in
> this expansion, but warning on useless macro-expanded code isn't
> helpful, since other macro users need it.
Ah, that makes sense. The compiler is warning us that the macro-expanded
version of for_each_string_list_item() has a ternary expression that
will never evaluate its right-hand side in cases where it can prove the
second argument to the macro is non-NULL.
> Hiding it in a function seems to work, even with -O2 inlining, like:
>
> diff --git a/string-list.h b/string-list.h
> index d5a744e143..b28b135e11 100644
> --- a/string-list.h
> +++ b/string-list.h
> @@ -141,9 +141,14 @@ void string_list_clear_func(struct string_list *list, string_list_clear_func_t c
> int for_each_string_list(struct string_list *list,
> string_list_each_func_t func, void *cb_data);
>
> +static inline struct string_list_item *string_list_first_item(const struct string_list *list)
> +{
> + return list ? list->items : NULL;
> +}
> +
> /** Iterate over each item, as a macro. */
> #define for_each_string_list_item(item,list) \
> - for (item = (list)->items; \
> + for (item = string_list_first_item(list); \
> item && item < (list)->items + (list)->nr; \
> ++item)
That works, nice. I don't really want to mess up the tree too much this
close to a release, but this sort of clean-up seems good to do. I know
Stolee identified a handful of spots that would benefit from it. Some
good #leftoverbits, I guess :-).
Thanks,
Taylor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] diff.c: offer config option to control ws handling in move detection
@ 2018-07-19 17:29 6% ` Stefan Beller
0 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2018-07-19 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Thu, Jul 19, 2018 at 9:29 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Stefan Beller <sbeller@google.com> writes:
>
> > On Wed, Jul 18, 2018 at 10:45 AM Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> Stefan Beller <sbeller@google.com> writes:
> >>
> >> > diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> >> > index 143acd9417e..8da7fed4e22 100644
> >> > --- a/Documentation/diff-options.txt
> >> > +++ b/Documentation/diff-options.txt
> >> > @@ -294,8 +294,11 @@ dimmed_zebra::
> >> >
> >> > --color-moved-ws=<modes>::
> >> > This configures how white spaces are ignored when performing the
> >> > - move detection for `--color-moved`. These modes can be given
> >> > - as a comma separated list:
> >> > + move detection for `--color-moved`.
> >> > +ifdef::git-diff[]
> >> > + It can be set by the `diff.colorMovedWS` configuration setting.
> >> > +endif::git-diff[]
> >>
> >> The patch to diff.c::git_diff_ui_config() we see below does not seem
> >> to make any effort to make sure that this new configuration applies
> >> only to "git diff" and that other commands like "git log" that call
> >> git_diff_ui_config() are not affected.
> >
> > That is as intended. (We want to have it in git-log)
>
> Ah, I think what is going on here, and I think I asked a wrong
> question.
>
> * diff-options.txt is used by the family of diff plumbing commands
> (which actively do not want to participate in the coloring game
> and do not call git_diff_ui_config()) as well as log family of
> commands (which do pay attention to the config).
>
> * "git grep '^:git-diff:'" hits only Documentation/git-diff.txt.
>
> What the system currently does (which may not match what it should
> do) is that Porcelain "diff", "log", etc. pay attention to the
> configuration while plumbing "diff-{files,index,tree}" don't, and
> use of ifdef/endif achieves only half of that (i.e. excludes the
> sentence from plumbing manual pages). It excludes too much and does
> not say "log", "show", etc. also honor the configuration.
>
> I think the set of asciidoc attrs diff-options.txt files uses need
> some serious clean-up. For example, it defines :git-diff-core: that
> is only used once, whose intent seems to be "we are describing diff
> plumbing". However, the way it does so is by excluding known
> Porcelain; if we ever add new diff porcelain (e.g. "range-diff"),
> that way of 'definition by exclusion' would break. The scheme is
> already broken by forcing git-show.txt to define 'git-log' just like
> git-log.txt does, meaning that it is not possible to make "show" to
> be described differently from "log". But let's leave that outside
> this topic.
Then let's call this #leftoverbits ?
> Back to a more on-topic tangent.
>
> How does this patch (and all the recent "color" options you added
> recently) avoid spending unnecessary cycles and contaminating "git
> format-patch" output, by the way? builtin/log.c::cmd_format_patch()
> seems to eventually call into git_log_config() that ends with a call
> to diff_ui_config().
The color options are only using CPU cycles when we actually need to
color things (if no-color is set, then the move detection is off).
"git format-patch HEAD^ --color" produces red/green output
(like git log would), so I do not see why --color-moved should impact
format-patch differently. (i.e. if the user requests format-patch with
color-moved we can do it, otherwise, when colors are off, we do not
spend cycles to compute the moves)
Maybe I did not understand the gist of your question, still?
Stefan
^ permalink raw reply [relevance 6%]
* Re: [PATCHv3 1/6] Add missing includes and forward declares
@ 2018-08-15 6:51 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2018-08-15 6:51 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git Mailing List, Ævar Arnfjörð, Jeff King,
Ramsay Jones
On Tue, Aug 14, 2018 at 11:13 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Elijah Newren wrote:
>
> > I didn't want to repeat that description in all 6 patches, since all
> > six came from that, so I put it in the cover letter. Since patch #1
> > has most that changes though, I guess it makes sense to include it at
> > least in that one?
>
> Yes, that sounds sensible to me.
Will do.
> [...]
> >> enums are of unknown size, so forward declarations don't work for
> >> them. See bb/pedantic for some examples.
> >
> > structs are also of unknown size; the size is irrelevant when the
> > function signature merely uses a pointer to the struct or enum. The
> > enum forward declaration fixes a compilation bug.
>
> My rationale may miss the point but the standard and some real compilers
> don't like this, unfortunately.
>
> For structs, having an incomplete type is fine, but for enums we need
> the full definition. E.g. C99 sayeth (in section 6.7.2.3 "tags")
>
> A type specifier of the form
>
> enum identifier
>
> without an enumerator list shall only appear after the type it
> specifies is complete.
What about a type specifier of the form
enum identifier *
? Can that kind of type specifier appear before the full definition
of the enum? (Or, alternatively, if the standard doesn't say, are
there any compilers that have a problem with that?)
If so, we can include cache.h instead. We'll probably also have to
fix up packfile.h for the exact same issue (even the same enum name)
if that's the case.
> [...]
> >>> --- a/commit-graph.h
> >>> +++ b/commit-graph.h
> >>> @@ -4,6 +4,7 @@
> >>> #include "git-compat-util.h"
> >>> #include "repository.h"
> >>> #include "string-list.h"
> >>> +#include "cache.h"
> >>
> >> We can skip the #include of git-compat-util.h since all .c files
> >> include it.
> >
> > Good point. Should I go through and remove all the inclusions of
> > git-compat-util.h in header files?
>
> It's orthogonal to this series but might be a good change.
I think I'll leave it as #leftoverbits for someone else interested. :-)
> [...]
> >>> --- a/pathspec.h
> >>> +++ b/pathspec.h
> >>> @@ -1,6 +1,11 @@
> >>> #ifndef PATHSPEC_H
> >>> #define PATHSPEC_H
> >>>
> >>> +#include "string.h"
> >>> +#include "strings.h"
> >>
> >> What are these headers?
> >
> > The original patch[1] had explanations of why I added them:
> >
> > +#include "string.h" /* For str[n]cmp */
> > +#include "strings.h" /* For str[n]casecmp */
>
> Ah. Please remove these #includes: they're part of the standard
> library that we get implicitly via git-compat-util.h.
>
> I was tripped up because they were in quotes instead of angle
> brackets.
Indeed; will do.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom
@ 2017-10-02 5:03 6% ` Jeff King
2017-10-02 5:12 6% ` Taylor Blau
0 siblings, 1 reply; 200+ results
From: Jeff King @ 2017-10-02 5:03 UTC (permalink / raw)
To: Taylor Blau; +Cc: git, gitster
On Sun, Oct 01, 2017 at 05:33:04PM -0700, Taylor Blau wrote:
> The %(contents) atom takes a contents "field" as its argument. Since
> "trailers" is one of those fields, extend contents_atom_parser to parse
> "trailers"'s arguments when used through "%(contents)", like:
>
> %(contents:trailers:unfold,only)
>
> A caveat: trailers_atom_parser expects NULL when no arguments are given
> (see: `parse_ref_filter_atom`). This is because string_list_split (given
> a maxsplit of -1) returns a 1-ary string_list* containing the given
> string if the delimiter could not be found using `strchr`.
>
> To simulate this behavior without teaching trailers_atom_parser to
> accept strings with length zero, conditionally pass NULL to
> trailers_atom_parser if the arguments portion of the argument to
> %(contents) is empty.
Doh, that string_list behavior is what I was missing in my earlier
comments. I agree this is probably the best way of doing it. I'm tempted
to say that parse_ref_filter_atom() should do a similar thing. Right now
we've got:
$ git for-each-ref --format='%(refname)' | wc
2206 2206 79929
$ git for-each-ref --format='%(refname:short)' | wc
2206 2206 53622
$ git for-each-ref --format='%(refname:)' | wc
fatal: unrecognized %(refname:) argument:
0 0 0
which seems a bit unfriendly. As we're on v6 here, I don't want to
suggest it as part of this series. But maybe a #leftoverbits candidate,
if others agree it's a good direction.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH] pkt-line: re-'static'-ify buffer in packet_write_fmt_1()
@ 2017-09-05 10:03 6% ` Junio C Hamano
2017-10-10 4:06 6% ` [PATCH 0/2] Do not call cmd_*() as a subroutine Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2017-09-05 10:03 UTC (permalink / raw)
To: Jeff King; +Cc: Martin Ågren, Lars Schneider, Git Users
Jeff King <peff@peff.net> writes:
> Overall I suspect that running our cmd_*() functions multiple times in a
> single process is already going to cause chaos, because they often are
> touching static globals, etc. So it's probably not that big a deal in
> practice to add one more variable to the list, and declare that calling
> cmd_ls_files() anywhere except as the main function of ls-files is
> forbidden.
IIRC there were a few existing violators of this rule around "merge"
implementation. It may be a reasonably low hanging fruit to find
and fix them.
#leftoverbits
^ permalink raw reply [relevance 6%]
* Re: "git shortlog -sn --follow -- <path>" counts all commits to entire repo
@ 2017-09-09 6:52 6% ` Jeff King
2017-09-10 7:36 6% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Jeff King @ 2017-09-09 6:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stefan Beller,
Валентин,
git@vger.kernel.org
On Sat, Sep 09, 2017 at 02:37:20AM +0900, Junio C Hamano wrote:
> > That said, I don't think we can go wrong by making shortlog's traversal
> > more like log's. Any changes we make to --follow will be aimed at and
> > tested with git-log, so the more code they share the more likely it is
> > that shortlog won't bitrot.
>
> Both true.
>
> Using log-tree traversal machinery instead of just get_revision()
> would probably mean we would slow it down quite a bit unless we are
> careful, but at the same time, things like "git shortlog -G<string>"
> would suddenly start working, so this is not just helping the
> "--follow" hack.
I didn't notice that, but I'm not surprised that there are more options
that shortlog doesn't quite work with.
I don't plan on working on this myself any time soon, so maybe it's a
good #leftoverbits candidate (though it's perhaps a little more involved
than some).
-Peff
^ permalink raw reply [relevance 6%]
* Re: "git shortlog -sn --follow -- <path>" counts all commits to entire repo
2017-09-09 6:52 6% ` Jeff King
@ 2017-09-10 7:36 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-09-10 7:36 UTC (permalink / raw)
To: Jeff King
Cc: Stefan Beller,
Валентин,
git@vger.kernel.org
Jeff King <peff@peff.net> writes:
> On Sat, Sep 09, 2017 at 02:37:20AM +0900, Junio C Hamano wrote:
>
>> Using log-tree traversal machinery instead of just get_revision()
>> would probably mean we would slow it down quite a bit unless we are
>> careful, but at the same time, things like "git shortlog -G<string>"
>> would suddenly start working, so this is not just helping the
>> "--follow" hack.
>
> I didn't notice that, but I'm not surprised that there are more options
> that shortlog doesn't quite work with.
>
> I don't plan on working on this myself any time soon, so maybe it's a
> good #leftoverbits candidate (though it's perhaps a little more involved
> than some).
I agree that I do not mind seeing those who haven't really touched
the inner core of the system to try this change, so marking this
discussion with #leftoverbits may be a good idea, but I have this
gut feeling that "a little more involved" might be a bit of an
understatement ;-)
But still I think it is a very good suggestion to allow log-tree to
filter things more so that "shortlog $args" can become a more
faithful imitation of "log $args | shortlog".
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 4/4] imap-send: use curl by default
@ 2017-09-12 6:46 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-09-12 6:46 UTC (permalink / raw)
To: Nicolas Morey-Chaisemartin, Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> On Mon, Aug 07, 2017 at 04:04:05PM +0200, Nicolas Morey-Chaisemartin wrote:
>
>> Signed-off-by: Nicolas Morey-Chaisemartin <nicolas@morey-chaisemartin.com>
>
> Thanks for moving forward with this.
>
> Can you please flesh out your commit messages with some of the reasoning
> and related discussion? I know from a nearby thread why we want to flip
> the default, but people reading `git log` much later will not have that
> context.
> ...
I was sweeping my mailbox to collect loose ends that haven't been
tied down, and noticed that this topic does not seem to reach a
conclusion. Do we want to reboot the effort? Or should we just
throw it in the #leftoverbits bin for now?
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option
@ 2017-09-12 6:49 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-09-12 6:49 UTC (permalink / raw)
To: Kaartic Sivaraam; +Cc: git, martin.agren
Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:
> On Wed, 2017-08-16 at 12:09 -0700, Junio C Hamano wrote:
>> You said that "checkout" does not do a necessary check that is done
>> in "branch", so presumably "branch" already has a code to do so that
>> is not called by the current "checkout", right? Then you would add
>> a new caller in "checkout" to trigger the same check that is already
>> done in "branch", but the code "branch" uses _might_ be too specific
>> to the kind of data the current implementation of "branch" uses and
>> it _may_ not be easy to call it directly from "checkout" (I didn't
>> check if that is the case). If so, then the check implemented in
>> the current "branch" may need to be refactored before it can easily
>> be called from the new caller you would be adding to "checkout".
>>
>>
> Thanks. Now I get it. What about doing that check in
> branch.c::create_branch or branch.c::validate_new_branchname? I guess
> creating a branch named HEAD isn't that good an idea in any case. Doing
> the check there might prevent a similar situation in future, I guess.
> Further "branch" and "checkout" do call branch.c::create_branch which
> in turn calls branch.c::validate_new_branchname.
The above analysis sounds sensible, so it appears that you already
found a function that is shared in the two codepaths, and have a
good plan to make them consistent?
I was sweeping my mailbox to collect loose ends that haven't been
tied down, and noticed that this topic does not seem to reach a
conclusion. Do we want to reboot the effort? Or should we just
throw it in the #leftoverbits bin for now?
Thanks.
^ permalink raw reply [relevance 6%]
* Re: Suggestion: better error message when an ambiguous checkout is executed
@ 2017-09-12 6:53 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-09-12 6:53 UTC (permalink / raw)
To: Mahmoud Al-Qudsi; +Cc: git
Junio C Hamano <gitster@pobox.com> writes:
> Mahmoud Al-Qudsi <mqudsi@neosmart.net> writes:
>
>> The default git behavior when attempting to `git checkout xxx` for
>> some value of "xxx" that cannot be resolved to a single, unique
>> file/path/branch/tag/commit/etc is to display the following:
> ...
> So a possible implementation approach would be
>
> - to let the current code do what it is doing
>
> - except that you add new code immediately before the code that
> issues 'xxx' did not match (i.e. the code already checked that
> 'xxx' taken as a pathspec does not match anything, and about to
> give the error message but hasn't done so just yet).
>
> - your new code
>
> . checks if 'xxx' could be an attempt to refer to a rev but
> insufficiently spelled out (e.g. both origin[12]/xxx exists, or
> for a bonus point, a similarly named origin/xxy exists and
> could be a typo).
>
> . if the above check found something, then you report it and
> terminate without complaining "pathspec 'xxx' did not
> match..."
>
> . on the other hand, if the above check did not find anything,
> then you let the current code issue the same error message as
> before.
I was sweeping my mailbox to collect loose ends that haven't been
tied down, and noticed that this topic does not seem to have reached
a conclusion. Do we want to reboot the effort? Or should we just
throw it in the #leftoverbits bin for now?
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [OUTREACHY] pack: make packed_git_mru global a value instead of a pointer
@ 2017-09-19 5:20 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2017-09-19 5:20 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: phionah bugosi, git
On Mon, Sep 18, 2017 at 04:17:24PM -0700, Jonathan Nieder wrote:
> phionah bugosi wrote:
>
> > Just to reecho a previous change requested before in one of the mail
> > threads, we currently have two global variables declared:
> >
> > struct mru packed_git_mru_storage;
> > struct mru *packed_git_mru = &packed_git_mru_storage;
> >
> > We normally use pointers in C to point or refer to the same location
> > or space in memory from multiple places. That means in situations
> > where we will have the pointer be assigned to in many places in our
> > code. But in this case, we do not have any other logic refering or
> > assigning to the pointer packed_git_mru. In simple words we actually
> > dont need a pointer in this case.
> >
> > Therefore this patch makes packed_git_mru global a value instead of
> > a pointer and makes use of list.h
> >
> > Signed-off-by: phionah bugosi <bugosip@gmail.com>
> > ---
> > builtin/pack-objects.c | 5 +++--
> > cache.h | 7 -------
> > list.h | 6 ++++++
> > packfile.c | 12 ++++++------
> > 4 files changed, 15 insertions(+), 15 deletions(-)
>
> *puzzled* This appears to already be in "pu", with a different author.
> Did you independently make the same change? Or are you asking for a
> progress report on that change, and just phrasing it in a confusing
> way?
I pointed Phionah at your #leftoverbits comment in:
https://public-inbox.org/git/20170912172839.GB144745@aiede.mtv.corp.google.com/
about moving packed_git_mru to list.h. But I'm afraid I wasn't very
clear in giving further guidance.
The goal is to build on _top_ of the patch in that message, and convert
the doubly-linked list implementation used in "struct mru" to use the
shared code in list.h. That should mostly involve touching mru.c and
mru.h, though I think we'd need to tweak the name of the "next" pointer
during the traversal, too.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/3] validate_headref: NUL-terminate HEAD buffer
@ 2017-09-27 7:06 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-09-27 7:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> diff --git a/path.c b/path.c
> index b533ec938d..3e4d7505ef 100644
> --- a/path.c
> +++ b/path.c
> @@ -662,6 +662,10 @@ int validate_headref(const char *path)
> len = read_in_full(fd, buffer, sizeof(buffer)-1);
> close(fd);
>
> + if (len < 0)
> + return -1;
> + buffer[len] = '\0';
> +
> /*
> * Is it a symbolic ref?
> */
A few tangents I noticed:
- the result of readlink should be checked with starts_with() in
the modern codebase (#leftoverbits).
- buffer[256] would mean that we cannot have a branch whose name is
more than a couple of hundred bytes long; as you said, we may be
better off using strbuf_read to read the whole thing.
Neither should be touched by this patch, of course.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom
2017-10-02 5:03 6% ` Jeff King
@ 2017-10-02 5:12 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2017-10-02 5:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
On Mon, Oct 02, 2017 at 01:03:51AM -0400, Jeff King wrote:
> On Sun, Oct 01, 2017 at 05:33:04PM -0700, Taylor Blau wrote:
>
> > The %(contents) atom takes a contents "field" as its argument. Since
> > "trailers" is one of those fields, extend contents_atom_parser to parse
> > "trailers"'s arguments when used through "%(contents)", like:
> >
> > %(contents:trailers:unfold,only)
> >
> > A caveat: trailers_atom_parser expects NULL when no arguments are given
> > (see: `parse_ref_filter_atom`). This is because string_list_split (given
> > a maxsplit of -1) returns a 1-ary string_list* containing the given
> > string if the delimiter could not be found using `strchr`.
> >
> > To simulate this behavior without teaching trailers_atom_parser to
> > accept strings with length zero, conditionally pass NULL to
> > trailers_atom_parser if the arguments portion of the argument to
> > %(contents) is empty.
>
> Doh, that string_list behavior is what I was missing in my earlier
> comments. I agree this is probably the best way of doing it. I'm tempted
> to say that parse_ref_filter_atom() should do a similar thing. Right now
> we've got:
>
> $ git for-each-ref --format='%(refname)' | wc
> 2206 2206 79929
> $ git for-each-ref --format='%(refname:short)' | wc
> 2206 2206 53622
> $ git for-each-ref --format='%(refname:)' | wc
> fatal: unrecognized %(refname:) argument:
> 0 0 0
>
> which seems a bit unfriendly. As we're on v6 here, I don't want to
> suggest it as part of this series. But maybe a #leftoverbits candidate,
> if others agree it's a good direction.
I think #leftoverbits is fine here, but I think addressing this before
2.15 is reasonable. I can take a look at this in a future patch series.
--
- Taylor
^ permalink raw reply [relevance 6%]
* Re: What means "git config bla ~/"?
@ 2017-10-04 4:01 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2017-10-04 4:01 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Jonathan Nieder, rpjday, Git Mailing List
Matthieu Moy <git@matthieu-moy.fr> writes:
> "Junio C Hamano" <gitster@pobox.com> writes:
>
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>>> what's with that "git config bla ~/"? is this some config keyword
>>>> or something?
>>> ...
>> git config section.var ~/some/thing
>> ...
>
> I prefer your "section.var" proposal above. I think people who really understand shell quoting do not need the explanations, and others probably need the example.
>
> While we're there, the formatting is also wrong ('' quoting, while we normally use `` quoting for shell commands).
>
> Sounds like a nice microproject for my students :-). A patch should follow soon.
OK, thanks. Lest we forget, this is #leftoverbits for now.
^ permalink raw reply [relevance 6%]
* Re: [PATCH V4] config: add --expiry-date
@ 2017-11-18 3:37 6% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2017-11-18 3:37 UTC (permalink / raw)
To: hsed; +Cc: git, Heiko Voigt, Jeff King
hsed@unimetic.com writes:
> diff --git a/config.c b/config.c
> index 903abf953..64f8aa42b 100644
> --- a/config.c
> +++ b/config.c
> @@ -990,6 +990,16 @@ int git_config_pathname(const char **dest, const char *var, const char *value)
> return 0;
> }
>
> +int git_config_expiry_date(timestamp_t *timestamp, const char *var, const char *value)
> +{
> + if (!value)
> + return config_error_nonbool(var);
> + if (parse_expiry_date(value, timestamp))
> + return error(_("'%s' for '%s' is not a valid timestamp"),
> + value, var);
> + return 0;
> +}
> +
I think this is more correct even within the context of this
function than dying, which suggests the need for a slightly related
(which is not within the scope of this change) clean-up within this
file as a #leftoverbits task. I think dying in these value parsers
goes against the point of having die_on_error bit in the
config-source structure; Heiko and Peff CC'ed for b2dc0945 ("do not
die when error in config parsing of buf occurs", 2013-07-12).
Thanks; will queue.
^ permalink raw reply [relevance 6%]
* Re: [PATCH V4] config: add --expiry-date
@ 2017-11-20 20:28 6% ` Stefan Beller
0 siblings, 0 replies; 200+ results
From: Stefan Beller @ 2017-11-20 20:28 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, hsed, git, Heiko Voigt
On Mon, Nov 20, 2017 at 9:04 AM, Jeff King <peff@peff.net> wrote:
> On Sat, Nov 18, 2017 at 12:37:03PM +0900, Junio C Hamano wrote:
>
>> > +int git_config_expiry_date(timestamp_t *timestamp, const char *var, const char *value)
>> > +{
>> > + if (!value)
>> > + return config_error_nonbool(var);
>> > + if (parse_expiry_date(value, timestamp))
>> > + return error(_("'%s' for '%s' is not a valid timestamp"),
>> > + value, var);
>> > + return 0;
>> > +}
>> > +
>>
>> I think this is more correct even within the context of this
>> function than dying, which suggests the need for a slightly related
>> (which is not within the scope of this change) clean-up within this
>> file as a #leftoverbits task. I think dying in these value parsers
>> goes against the point of having die_on_error bit in the
>> config-source structure; Heiko and Peff CC'ed for b2dc0945 ("do not
>> die when error in config parsing of buf occurs", 2013-07-12).
>
> Yes, I agree that ideally the value parsers should avoid dying.
> Unfortunately I think it will involve some heavy refactoring, since
> git_config_bool(), for instance, does not even have a spot in its
> interface to return an error.
>
> Of course we can leave those other helpers in place and add a "gently"
> form for each. It is really only submodule-config.c that wants to be
> careful in its callback, so we could just port that. Skimming it over,
> it looks like there are a few git_config_bool() and straight-up die()
> calls that could be more forgiving.
>
> +cc Stefan, who added the die(). It may be that we don't care that much
> these days about recovering from broken .gitmodules files.
By that you mean commits like 37f52e9344 (submodule-config:
keep shallow recommendation around, 2016-05-26) for example?
That adds a git_config_bool to the submodule config machinery.
I agree that we'd want to be more careful, but for now I'd put it to the
#leftoverbits.
Thanks,
Stefan
^ permalink raw reply [relevance 6%]
* Re: [RFC PATCH v2] builtin/worktree: enhance worktree removal
@ 2017-11-28 16:46 6% ` Kaartic Sivaraam
0 siblings, 0 replies; 200+ results
From: Kaartic Sivaraam @ 2017-11-28 16:46 UTC (permalink / raw)
To: Junio C Hamano, Eric Sunshine
Cc: Nguyễn Thái Ngọc Duy, Git Mailing List
On Tuesday 28 November 2017 09:34 AM, Junio C Hamano wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
>
>> With this approach, validate_worktree() will print an error message
>> saying that the worktree directory is missing before the control info
>> is actually removed. Kaartic's original patch silenced the message
>> (and _all_ error messages from validate_worktree()) by passing 1 as
>> the second argument. That seemed heavy-handed, so I suggested keeping
>> the validate_worktree() call as-is but doing the directory-missing
>> check first as a special case.
>>
>> But perhaps that special case isn't necessary.
>
> I do not think the user minds to see "there is no such directory
> there"; actually that would be beneficial, even.
>
> But you are right; validate_worktree() would need to become aware of
> the possibility that it can be passed such a "corrupt" worktree to
> handle if that approach is followed.
>
> The case we are discussing, i.e. the user removed the directory
> without telling Git to give it a chance to remove control
> information, may be common enough that it becomes a worthwhile
> addition to make the "quiet" boolean that occupies a whole int to an
> unsigned that is a collection of bits, and pass "missing_ok" bit in
> that flag word to the validate_worktree() to tell that the caller
> can tolerate the "user removed it while we were looking the other
> way" case and can handle it gracefully. But that would be a lot
> larger change, and "the caller checks before calling validate" as
> done with this [RFC v2] may be a good way to add the feature with
> the least impact to the codebase.
>
>> I had envisioned a simple 'goto remove_control_info' rather than extra
>> nesting or refactoring, but that's a minor point.
>
> Yes, use of goto is also a good way to avoid having to worry about
> the future evolution of the codeflow in this function.
>
> So perhaps
>
> if (the directory is no longer there)
> goto cleanup;
> if (the worktree does not validate)
> return -1;
> ... the original code to (carefully) remove the
> ... worktree itself
>
> cleanup:
>
> ... remove control info
> ... free resources held in variables
> ... return from the function
>
> is what we want?
>
Probably but I'm not interested in going for a v3 that does that as I
just wanted to show that worktree remove could be enhanced in this
aspect and show how it could be done. So, I'll leave this in the
#leftoverbits for the person who would be re-rolling nd/worktree-move.
---
Kaartic
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 1/7] git-compat-util: introduce skip_to_optional_arg()
@ 2017-12-11 5:56 6% ` Christian Couder
0 siblings, 0 replies; 200+ results
From: Christian Couder @ 2017-12-11 5:56 UTC (permalink / raw)
To: Jeff King
Cc: git, Junio C Hamano, Donald R Laster Jr, Jacob Keller,
Christian Couder
On Sun, Dec 10, 2017 at 3:39 PM, Jeff King <peff@peff.net> wrote:
> On Sun, Dec 10, 2017 at 09:31:18AM -0500, Jeff King wrote:
>
>> On Sat, Dec 09, 2017 at 09:40:07PM +0100, Christian Couder wrote:
>>
>> > The changes compared to v2 are:
>> >
>> > - s/_val/_arg/ in the name of the functions
>> > - s/val/arg/ in the name of the third argument of the functions
>> > - works with NULL as third argument of the functions
>>
>> This whole series looks OK to me, but this third point made me wonder:
>> what would be the use of allowing NULL for the "arg" parameter?
>>
>> I didn't see any use of this in the series, and I'm having trouble
>> figuring out how it would be useful. E.g., if I do:
>>
>> if (skip_to_optional_arg(arg, "--foo", NULL))
>> ...
>>
>> what can I do in "..."? I know we matched _some_ type of "--foo", but I
>> cannot know whether it was "--foo" or "--foo=bar", nor what "bar" is. It
>> could only be used by some kind of vague validator to say "well, at
>> least this looks like an option that I _could_ parse if I wanted to".
>>
>> So I guess I don't mind it, as it does the most reasonable thing it can
>> when passed NULL, but I would be surprised if we ever actually exercise
>> the code path.
>
> And of course as soon as I sent this, I went back and double-checked.
> And indeed I totally missed this call:
>
> + else if (starts_with(arg, "-B") ||
> + skip_to_optional_arg(arg, "--break-rewrites", NULL)) {
> if ((options->break_opt = diff_scoreopt_parse(arg)) == -1)
Yeah, calls like this were discussed in:
https://public-inbox.org/git/xmqqh8t6o9me.fsf@gitster.mtv.corp.google.com/
> So that's kind-of weird, because we are parsing "-B", etc, and then
> expecting it to be _reparsed_ by diff_scoreopt_parse. So the two
> callsites must always match. IMHO this ought to do either:
>
> - we should just ask diff_scoreopt_parser to tell us if this was a
> valid option that it understood
>
> or
>
> - parse up to the "=", and then ask the scoreopt parser to parse the
> remainder. This would require us passing 'B'/'C'/'M' to the
> function ourselves, I think that's a better pattern. It means we
> could reuse the parser for things like config values if we wanted to
> (our current diff.renames is a bool, but it would not be
> unreasonable for it to take a score).
>
> None of that is a mess of your creation, though, so I'm OK punting on it
> for now.
Yeah, this could be part of the #leftoverbits.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 05/27] upload-pack: factor out processing lines
@ 2018-01-31 14:08 6% ` Derrick Stolee
0 siblings, 0 replies; 200+ results
From: Derrick Stolee @ 2018-01-31 14:08 UTC (permalink / raw)
To: Brandon Williams, Stefan Beller
Cc: git, Junio C Hamano, Jeff King, Philip Oakley, Jonathan Nieder
On 1/26/2018 4:33 PM, Brandon Williams wrote:
> On 01/26, Stefan Beller wrote:
>> On Thu, Jan 25, 2018 at 3:58 PM, Brandon Williams <bmwill@google.com> wrote:
>>> Factor out the logic for processing shallow, deepen, deepen_since, and
>>> deepen_not lines into their own functions to simplify the
>>> 'receive_needs()' function in addition to making it easier to reuse some
>>> of this logic when implementing protocol_v2.
>>>
>>> Signed-off-by: Brandon Williams <bmwill@google.com>
>>> ---
>>> upload-pack.c | 113 ++++++++++++++++++++++++++++++++++++++--------------------
>>> 1 file changed, 74 insertions(+), 39 deletions(-)
>>>
>>> diff --git a/upload-pack.c b/upload-pack.c
>>> index 2ad73a98b..42d83d5b1 100644
>>> --- a/upload-pack.c
>>> +++ b/upload-pack.c
>>> @@ -724,6 +724,75 @@ static void deepen_by_rev_list(int ac, const char **av,
>>> packet_flush(1);
>>> }
>>>
>>> +static int process_shallow(const char *line, struct object_array *shallows)
>>> +{
>>> + const char *arg;
>>> + if (skip_prefix(line, "shallow ", &arg)) {
>> stylistic nit:
>>
>> You could invert the condition in each of the process_* functions
>> to just have
>>
>> if (!skip_prefix...))
>> return 0
>>
>> /* less indented code goes here */
>>
>> return 1;
>>
>> That way we have less indentation as well as easier code.
>> (The reader doesn't need to keep in mind what the else
>> part is about; it is a rather local decision to bail out instead
>> of having the return at the end of the function.)
> I was trying to move the existing code into helper functions so
> rewriting them in transit may make it less reviewable?
I think the way you kept to the existing code as much as possible is
good and easier to review. Perhaps a style pass after the patch lands is
good for #leftoverbits.
>>
>>> + struct object_id oid;
>>> + struct object *object;
>>> + if (get_oid_hex(arg, &oid))
>>> + die("invalid shallow line: %s", line);
>>> + object = parse_object(&oid);
>>> + if (!object)
>>> + return 1;
>>> + if (object->type != OBJ_COMMIT)
>>> + die("invalid shallow object %s", oid_to_hex(&oid));
>>> + if (!(object->flags & CLIENT_SHALLOW)) {
>>> + object->flags |= CLIENT_SHALLOW;
>>> + add_object_array(object, NULL, shallows);
>>> + }
>>> + return 1;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int process_deepen(const char *line, int *depth)
>>> +{
>>> + const char *arg;
>>> + if (skip_prefix(line, "deepen ", &arg)) {
>>> + char *end = NULL;
>>> + *depth = (int) strtol(arg, &end, 0);
nit: space between (int) and strtol?
>>> + if (!end || *end || *depth <= 0)
>>> + die("Invalid deepen: %s", line);
>>> + return 1;
>>> + }
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int process_deepen_since(const char *line, timestamp_t *deepen_since, int *deepen_rev_list)
>>> +{
>>> + const char *arg;
>>> + if (skip_prefix(line, "deepen-since ", &arg)) {
>>> + char *end = NULL;
>>> + *deepen_since = parse_timestamp(arg, &end, 0);
>>> + if (!end || *end || !deepen_since ||
>>> + /* revisions.c's max_age -1 is special */
>>> + *deepen_since == -1)
>>> + die("Invalid deepen-since: %s", line);
>>> + *deepen_rev_list = 1;
>>> + return 1;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> +static int process_deepen_not(const char *line, struct string_list *deepen_not, int *deepen_rev_list)
>>> +{
>>> + const char *arg;
>>> + if (skip_prefix(line, "deepen-not ", &arg)) {
>>> + char *ref = NULL;
>>> + struct object_id oid;
>>> + if (expand_ref(arg, strlen(arg), &oid, &ref) != 1)
>>> + die("git upload-pack: ambiguous deepen-not: %s", line);
>>> + string_list_append(deepen_not, ref);
>>> + free(ref);
>>> + *deepen_rev_list = 1;
>>> + return 1;
>>> + }
>>> + return 0;
>>> +}
>>> +
>>> static void receive_needs(void)
>>> {
>>> struct object_array shallows = OBJECT_ARRAY_INIT;
>>> @@ -745,49 +814,15 @@ static void receive_needs(void)
>>> if (!line)
>>> break;
>>>
>>> - if (skip_prefix(line, "shallow ", &arg)) {
>>> - struct object_id oid;
>>> - struct object *object;
>>> - if (get_oid_hex(arg, &oid))
>>> - die("invalid shallow line: %s", line);
>>> - object = parse_object(&oid);
>>> - if (!object)
>>> - continue;
>>> - if (object->type != OBJ_COMMIT)
>>> - die("invalid shallow object %s", oid_to_hex(&oid));
>>> - if (!(object->flags & CLIENT_SHALLOW)) {
>>> - object->flags |= CLIENT_SHALLOW;
>>> - add_object_array(object, NULL, &shallows);
>>> - }
>>> + if (process_shallow(line, &shallows))
>>> continue;
>>> - }
>>> - if (skip_prefix(line, "deepen ", &arg)) {
>>> - char *end = NULL;
>>> - depth = strtol(arg, &end, 0);
>>> - if (!end || *end || depth <= 0)
>>> - die("Invalid deepen: %s", line);
>>> + if (process_deepen(line, &depth))
>>> continue;
>>> - }
>>> - if (skip_prefix(line, "deepen-since ", &arg)) {
>>> - char *end = NULL;
>>> - deepen_since = parse_timestamp(arg, &end, 0);
>>> - if (!end || *end || !deepen_since ||
>>> - /* revisions.c's max_age -1 is special */
>>> - deepen_since == -1)
>>> - die("Invalid deepen-since: %s", line);
>>> - deepen_rev_list = 1;
>>> + if (process_deepen_since(line, &deepen_since, &deepen_rev_list))
>>> continue;
>>> - }
>>> - if (skip_prefix(line, "deepen-not ", &arg)) {
>>> - char *ref = NULL;
>>> - struct object_id oid;
>>> - if (expand_ref(arg, strlen(arg), &oid, &ref) != 1)
>>> - die("git upload-pack: ambiguous deepen-not: %s", line);
>>> - string_list_append(&deepen_not, ref);
>>> - free(ref);
>>> - deepen_rev_list = 1;
>>> + if (process_deepen_not(line, &deepen_not, &deepen_rev_list))
>>> continue;
>>> - }
>>> +
>>> if (!skip_prefix(line, "want ", &arg) ||
>>> get_oid_hex(arg, &oid_buf))
>>> die("git upload-pack: protocol error, "
>>> --
>>> 2.16.0.rc1.238.g530d649a79-goog
>>>
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 14/35] connect: request remote refs using v2
@ 2018-02-27 6:21 6% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2018-02-27 6:21 UTC (permalink / raw)
To: Jonathan Tan
Cc: Jeff King, Brandon Williams, git, sbeller, gitster, stolee, git,
pclouds
Jonathan Tan wrote:
> On Thu, 22 Feb 2018 13:26:58 -0500
> Jeff King <peff@peff.net> wrote:
>> I agree that it shouldn't matter much here. But if the name argv_array
>> is standing in the way of using it, I think we should consider giving it
>> a more general name. I picked that not to evoke "this must be arguments"
>> but "this is terminated by a single NULL".
[...]
> This sounds reasonable - I withdraw my comment about using struct
> string_list.
Marking with #leftoverbits as a reminder to think about what such a
more general name would be (or what kind of docs to put in
argv-array.h) and make it so the next time I do a search for that
keyword.
Thanks,
Jonathan
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 4/4] builtin/rebase: support running "git rebase <upstream>"
@ 2018-07-07 6:45 6% ` Christian Couder
2018-07-07 16:24 6% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Christian Couder @ 2018-07-07 6:45 UTC (permalink / raw)
To: Pratik Karki
Cc: git, Johannes Schindelin, Stefan Beller, Alban Gruin,
Junio C Hamano
On Fri, Jul 6, 2018 at 2:08 PM, Pratik Karki <predatoramigo@gmail.com> wrote:
> + switch (opts->type) {
> + case REBASE_AM:
> + backend = "git-rebase--am";
> + backend_func = "git_rebase__am";
> + break;
> + case REBASE_INTERACTIVE:
> + backend = "git-rebase--interactive";
> + backend_func = "git_rebase__interactive";
> + break;
> + case REBASE_MERGE:
> + backend = "git-rebase--merge";
> + backend_func = "git_rebase__merge";
> + break;
> + case REBASE_PRESERVE_MERGES:
> + backend = "git-rebase--preserve-merges";
> + backend_func = "git_rebase__preserve_merges";
> + break;
> + default:
> + BUG("Unhandled rebase type %d", opts->type);
> + break;
Nit: I think the "break;" line could be removed as the BUG() should always exit.
A quick grep shows that there are other places where there is a
"break;" line after a BUG() though. Maybe one of the #leftoverbits
could be about removing those "break;" lines.
> + }
^ permalink raw reply [relevance 6%]
* Re: [PATCH 4/8] gpg-interface: introduce an abstraction for multiple gpg formats
@ 2018-07-10 15:51 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-07-10 15:51 UTC (permalink / raw)
To: Jeff King
Cc: Martin Ågren, Henning Schild, Git Mailing List, Ben Toews,
Taylor Blau, brian m . carlson, Eric Sunshine
Jeff King <peff@peff.net> writes:
> On Fri, Jul 06, 2018 at 10:24:58AM -0700, Junio C Hamano wrote:
>
>> What we've been avoiding was the comma after the last element in the
>> enum (in other words, if PGP_FMT had ',' after it in the above
>> quoted addition, that would have been violation of that rule), as
>> having such a trailing comma used to be ANSI C violation as well. I
>> do not recall offhand if we loosened that deliberately.
>>
>> 4b05548f ("enums: omit trailing comma for portability", 2010-05-14),
>> c9b6782a ("enums: omit trailing comma for portability", 2011-03-16)
>
> I think we accidentally did a weather-balloon in e1327023ea (grep:
> refactor the concept of "grep source" into an object, 2012-02-02).
> It's still there and nobody has complained about it yet.
>
> So I think we can consider that requirement loosened at this point.
#leftoverbits: update CodingGuidelines and refer to these three
commits.
Takers?
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 02/23] archive-tar.c: mark more strings for translation
@ 2018-07-19 18:21 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-07-19 18:21 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Elijah Newren, Derrick Stolee
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> @@ -256,7 +256,7 @@ static int write_tar_entry(struct archiver_args *args,
> *header.typeflag = TYPEFLAG_REG;
> mode = (mode | ((mode & 0100) ? 0777 : 0666)) & ~tar_umask;
> } else {
> - return error("unsupported file mode: 0%o (SHA1: %s)",
> + return error(_("unsupported file mode: 0%o (SHA1: %s)"),
> mode, oid_to_hex(oid));
This is no longer sha1_to_hex(); the "SHA1" in the message should
probably have been updated when it happened.
Cleaning it up is outside the scope of this patch.
#leftoverbits
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 03/23] archive-zip.c: mark more strings for translation
@ 2018-07-19 18:26 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-07-19 18:26 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Elijah Newren, Derrick Stolee
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> - return error("path too long (%d chars, SHA1: %s): %s",
> + return error(_("path too long (%d chars, SHA1: %s): %s"),
> - return error("unsupported file mode: 0%o (SHA1: %s)", mode,
> + return error(_("unsupported file mode: 0%o (SHA1: %s)"), mode,
The same #leftoverbits comment as 02/23 applies here.
> @@ -601,7 +601,7 @@ static void dos_time(timestamp_t *timestamp, int *dos_date, int *dos_time)
> struct tm *t;
>
> if (date_overflows(*timestamp))
> - die("timestamp too large for this system: %"PRItime,
> + die(_("timestamp too large for this system: %"PRItime),
> *timestamp);
I suspect that this won't do the right "cross-platform" thing. For
built-in PRItype formats gettext tool knows about, *.po files let
translators translate original with "%<PRItype>" into localized text
with the same "%<PRItype>" left, and the runtime does the right
thing, but for a custom format like PRItime there is no such
support.
^ permalink raw reply [relevance 6%]
* Re: [PATCHv4 6/6] Remove forward declaration of an enum
@ 2018-08-15 20:40 6% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2018-08-15 20:40 UTC (permalink / raw)
To: Elijah Newren; +Cc: git, avarab, peff, ramsay
Elijah Newren wrote:
> According to http://c-faq.com/null/machexamp.html, sizeof(char*) !=
> sizeof(int*) on some platforms. Since an enum could be a char or int
> (or long or...), knowing the size of the enum thus is important to
> knowing the size of a pointer to an enum, so we cannot just forward
> declare an enum the way we can a struct. (Also, modern C++ compilers
> apparently define forward declarations of an enum to either be useless
> because the enum was defined, or require an explicit size specifier, or
> be a compilation error.)
Beyond the effect on some obscure platforms, this also makes it
possible to build with gcc -pedantic (which can be useful for finding
some other problems). Thanks for fixing it.
[...]
> --- a/packfile.h
> +++ b/packfile.h
> @@ -1,12 +1,12 @@
> #ifndef PACKFILE_H
> #define PACKFILE_H
>
> +#include "cache.h"
> #include "oidset.h"
>
> /* in object-store.h */
> struct packed_git;
> struct object_info;
Not about this patch: comments like the above are likely to go stale,
since nothing verifies they continue to be true. So we should remove
them. #leftoverbits
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply [relevance 6%]
* Re: Trivial enhancement: All commands which require an author should accept --author
@ 2018-08-29 19:09 6% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2018-08-29 19:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ulrich Gemkow, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The `stash` command only incidentally requires that the author is set, as
> it calls `git commit` internally (which records the author). As stashes
> are intended to be local only, that author information was never meant to
> be a vital part of the `stash`.
>
> I could imagine that an even better enhancement request would ask for `git
> stash` to work even if `user.name` is not configured.
This would make a good bite-sized microproject, worth marking it as
#leftoverbits unless somebody is already working on it ;-)
^ permalink raw reply [relevance 6%]
* Re: Trivial enhancement: All commands which require an author should accept --author
@ 2018-08-30 12:29 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 2 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-08-30 12:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Ulrich Gemkow, git
On Thu, Aug 30 2018, Johannes Schindelin wrote:
> Hi Junio,
>
> On Wed, 29 Aug 2018, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > The `stash` command only incidentally requires that the author is set, as
>> > it calls `git commit` internally (which records the author). As stashes
>> > are intended to be local only, that author information was never meant to
>> > be a vital part of the `stash`.
>> >
>> > I could imagine that an even better enhancement request would ask for `git
>> > stash` to work even if `user.name` is not configured.
>>
>> This would make a good bite-sized microproject, worth marking it as
>> #leftoverbits unless somebody is already working on it ;-)
>
> Right.
>
> What is our currently-favored approach to this, again? Do we have a
> favorite wiki page to list those, or do we have a bug tracker for such
> mini-projects?
>
> Once I know, I will add this, with enough information to get anybody
> interested started.
I believe the "official" way, such as it is, is you just put
#leftoverbits in your E-Mail, then search the list archives,
e.g. https://public-inbox.org/git/?q=%23leftoverbits
So e.g. I've taken to putting this in my own E-Mails where I spot
something I'd like to note as a TODO that I (or someone else) could work
on later:
https://public-inbox.org/git/?q=%23leftoverbits+f%3Aavarab%40gmail.com
^ permalink raw reply [relevance 6%]
* Re: Trivial enhancement: All commands which require an author should accept --author
@ 2018-09-04 17:18 6% ` Jonathan Nieder
0 siblings, 0 replies; 200+ results
From: Jonathan Nieder @ 2018-09-04 17:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Johannes Schindelin,
Ulrich Gemkow, git
Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>> I believe the "official" way, such as it is, is you just put
>> #leftoverbits in your E-Mail, then search the list archives,
>> e.g. https://public-inbox.org/git/?q=%23leftoverbits
>
> I think that technique has been around long enough to be called a
> recognised way, but I do not think it is "the" official way. It is
> one of the efforts to allow us remember what we might want to work
> on, and focuses on not wasting too much efforts in curating.
> Another effort to allow us remember is http://crbug.com/git that is
> run by Jonathan Nieder.
>
> Anybody can participate in curating the latter.
Yes, exactly.
Ævar, if you would like to keep better track of #leftoverbits, please
feel free to make use of https://crbug.com/git/new. It even has a
"leftover bit" template you can use.
Thanks and hope that helps,
Jonathan
^ permalink raw reply [relevance 6%]
* Re: Git in Outreachy Dec-Mar?
@ 2018-09-06 1:14 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2018-09-06 1:14 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin
On Wed, Sep 05, 2018 at 09:20:23AM +0200, Christian Couder wrote:
> >> Thanks. I think sooner is better for this (for you or anybody else who's
> >> interested in mentoring). The application period opens on September
> >> 10th, but I think the (still growing) list of projects is already being
> >> looked at by potential candidates.
>
> Do you know where is this list? On
> https://www.outreachy.org/apply/project-selection/ they say
> "Information about projects are unavailable until applications open".
This was the list I was looking at (scroll down below the timeline):
https://www.outreachy.org/communities/cfp/
But yeah, most of the "current projects" lists just say "not available
yet", so I think we're actually OK until the 10th.
> > So here is a landing page for the next Outreachy round:
> >
> > https://git.github.io/Outreachy-17/
> >
> > about the microprojects I am not sure which page I should create or improve.
>
> Any idea about this? Also any idea about new microprojects would be nice.
I think #leftoverbits is your best bet for micro-projects. Last year I
think we had interns actually hunt for them via the list archive. That's
a little unfriendly for total newcomers, I think, but it also does give
a chance to demonstrate some skills. Perhaps it would be help to create
a curated list of such bits.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH] [Outreachy] git/userdiff.c fix regex pattern error
@ 2018-10-04 19:42 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2018-10-04 19:42 UTC (permalink / raw)
To: Ananya Krishna Maram; +Cc: Christian Couder, git
Hi Ananya,
On Thu, 4 Oct 2018, Ananya Krishna Maram wrote:
> On Thu, 4 Oct 2018 at 20:56, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > [... talking about the reason why a slash does not need to be escaped
> > in a C string specifying a regular expression...]
> >
> > But it does not need to be escaped, when you specify the regular
> > expression the way we do. And the way we specified it is really the
> > standard when specifying regular expressions in C code, i.e. *without* the
> > suggested backslash.
>
> Aha!. this makes total sense. I was thinking from a general regular expression
> point of view. But I should be thinking from C point of view and how C
> might interpret this newly submitted string.
> This explanation is very clear. Thanks for taking time to reply to my
> patch. From next time on, I will try to think from
> git project's point of view.
Of course! Thank you for taking the time to contribute this patch.
Maybe you have another idea for a micro-project? Maybe there is something
in Git that you wish was more convenient? Or maybe
https://public-inbox.org/git/?q=leftoverbits has something that you would
like to implement?
Ciao,
Johannes
>
> Thanks,
> Ananya.
>
> > Ciao,
> > Johannes
> >
> > >
> > > Thanks,
> > > Ananya.
> > >
> > > > Thanks,
> > > > Johannes
> > > >
> > > > > ---
> > > > > userdiff.c | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/userdiff.c b/userdiff.c
> > > > > index f565f6731..f4ff9b9e5 100644
> > > > > --- a/userdiff.c
> > > > > +++ b/userdiff.c
> > > > > @@ -123,7 +123,7 @@ PATTERNS("python", "^[ \t]*((class|def)[ \t].*)$",
> > > > > /* -- */
> > > > > "[a-zA-Z_][a-zA-Z0-9_]*"
> > > > > "|[-+0-9.e]+[jJlL]?|0[xX]?[0-9a-fA-F]+[lL]?"
> > > > > - "|[-+*/<>%&^|=!]=|//=?|<<=?|>>=?|\\*\\*=?"),
> > > > > + "|[-+*\/<>%&^|=!]=|\/\/=?|<<=?|>>=?|\\*\\*=?"),
> > > > > /* -- */
> > > > > PATTERNS("ruby", "^[ \t]*((class|module|def)[ \t].*)$",
> > > > > /* -- */
> > > > > --
> > > > > 2.17.1
> > > > >
> > > > >
> > >
>
^ permalink raw reply [relevance 6%]
* Re: [PATCH 9/9] fetch-pack: drop custom loose object cache
@ 2018-11-12 19:25 6% ` René Scharfe
0 siblings, 0 replies; 200+ results
From: René Scharfe @ 2018-11-12 19:25 UTC (permalink / raw)
To: Jeff King, Geert Jansen
Cc: Ævar Arnfjörð Bjarmason, Junio C Hamano,
git@vger.kernel.org, Takuto Ikuta
Am 12.11.2018 um 15:55 schrieb Jeff King:
> Commit 024aa4696c (fetch-pack.c: use oidset to check existence of loose
> object, 2018-03-14) added a cache to avoid calling stat() for a bunch of
> loose objects we don't have.
>
> Now that OBJECT_INFO_QUICK handles this caching itself, we can drop the
> custom solution.
>
> Note that this might perform slightly differently, as the original code
> stopped calling readdir() when we saw more loose objects than there were
> refs. So:
>
> 1. The old code might have spent work on readdir() to fill the cache,
> but then decided there were too many loose objects, wasting that
> effort.
>
> 2. The new code might spend a lot of time on readdir() if you have a
> lot of loose objects, even though there are very few objects to
> ask about.
Plus the old code used an oidset while the new one uses an oid_array.
> In practice it probably won't matter either way; see the previous commit
> for some discussion of the tradeoff.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> fetch-pack.c | 39 ++-------------------------------------
> 1 file changed, 2 insertions(+), 37 deletions(-)
>
> diff --git a/fetch-pack.c b/fetch-pack.c
> index b3ed7121bc..25a88f4eb2 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -636,23 +636,6 @@ struct loose_object_iter {
> struct ref *refs;
> };
>
> -/*
> - * If the number of refs is not larger than the number of loose objects,
> - * this function stops inserting.
> - */
> -static int add_loose_objects_to_set(const struct object_id *oid,
> - const char *path,
> - void *data)
> -{
> - struct loose_object_iter *iter = data;
> - oidset_insert(iter->loose_object_set, oid);
> - if (iter->refs == NULL)
> - return 1;
> -
> - iter->refs = iter->refs->next;
> - return 0;
> -}
> -
> /*
> * Mark recent commits available locally and reachable from a local ref as
> * COMPLETE. If args->no_dependents is false, also mark COMPLETE remote refs as
> @@ -670,30 +653,14 @@ static void mark_complete_and_common_ref(struct fetch_negotiator *negotiator,
> struct ref *ref;
> int old_save_commit_buffer = save_commit_buffer;
> timestamp_t cutoff = 0;
> - struct oidset loose_oid_set = OIDSET_INIT;
> - int use_oidset = 0;
> - struct loose_object_iter iter = {&loose_oid_set, *refs};
> -
> - /* Enumerate all loose objects or know refs are not so many. */
> - use_oidset = !for_each_loose_object(add_loose_objects_to_set,
> - &iter, 0);
>
> save_commit_buffer = 0;
>
> for (ref = *refs; ref; ref = ref->next) {
> struct object *o;
> - unsigned int flags = OBJECT_INFO_QUICK;
>
> - if (use_oidset &&
> - !oidset_contains(&loose_oid_set, &ref->old_oid)) {
> - /*
> - * I know this does not exist in the loose form,
> - * so check if it exists in a non-loose form.
> - */
> - flags |= OBJECT_INFO_IGNORE_LOOSE;
This removes the only user of OBJECT_INFO_IGNORE_LOOSE. #leftoverbits
> - }
> -
> - if (!has_object_file_with_flags(&ref->old_oid, flags))
> + if (!has_object_file_with_flags(&ref->old_oid,
> + OBJECT_INFO_QUICK))
> continue;
> o = parse_object(the_repository, &ref->old_oid);
> if (!o)
> @@ -710,8 +677,6 @@ static void mark_complete_and_common_ref(struct fetch_negotiator *negotiator,
> }
> }
>
> - oidset_clear(&loose_oid_set);
> -
> if (!args->deepen) {
> for_each_ref(mark_complete_oid, NULL);
> for_each_cached_alternate(NULL, mark_alternate_complete);
>
^ permalink raw reply [relevance 6%]
* Re: Students projects: looking for small and medium project ideas
@ 2019-01-14 23:04 6% ` Ævar Arnfjörð Bjarmason
1 sibling, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2019-01-14 23:04 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
On Mon, Jan 14 2019, Matthieu Moy wrote:
> I haven't been active for a while on this list, but for those who don't
> know me, I'm a CS teacher and I'm regularly offering my students to
> contribute to open-source projects as part of their school projects. A
> few nice features like "git rebase -i --exec" or many of the hints in
> "git status" were implemented as part of these projects.
>
> I'm starting another instance of such project next week.
Good to hear!
> Part of the work of students is to choose which feature they want to
> work on, but I try to prepare this for them. I'm keeping a list of ideas
> here:
>
> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
>
> (At some point, I should probably migrate this to git.github.io, since
> the wiki only seems half-alive these days).
>
> I'm looking for small to medium size projects (typically, a GSoC project
> is far too big in comparison, but we may expect more than just
> microprojects).
>
> You may suggest ideas by editting the wiki page, or just by replying to
> this email (I'll point my students to the thread). Don't hesitate to
> remove entries (or ask me to do so) on the wiki page if you think they
> are not relevant anymore.
Some #leftoverbits I've noted on-list before would qualify, some of
these (e.g. grep --only-matching) have been implemented, but others not:
https://public-inbox.org/git/87in9ucsbb.fsf@evledraar.gmail.com/
https://public-inbox.org/git/87bmcyfh67.fsf@evledraar.gmail.com/
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2] merge-options.txt: correct wording of --no-commit option
@ 2019-02-19 22:31 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2019-02-19 22:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Ulrich Windl
On Tue, Feb 19, 2019 at 11:32 AM Junio C Hamano <gitster@pobox.com> wrote:
> Elijah Newren <newren@gmail.com> writes:
>
> > +With --no-commit perform the merge and stop just before creating
> > +a merge commit, to give the user a chance to inspect and further
> > +tweak the merge result before committing.
> > ++
> > +Note that fast-forward updates do not need to create a merge
> > +commit and therefore there is no way to stop those merges with
> > +--no-commit. Thus, if you want to ensure your branch is not
> > +changed or updated by the merge command, use --no-ff with
> > +--no-commit.
>
> While the above is an improvement (so I'll queue it on 'pu' not to
> lose sight of it), I find the use of "do not need to" above somewhat
> misleading. It solicits a reaction "ok, we know it does not need
> to, but it could prepare to create one to allow us to further muck
> with it, no?".
>
> IOW, a fast-forward by definition does not create a merge by itself,
> so there is nowhere to stop during a creation of a merge. So at
> least:
>
> s/do not need to/do not/
Yes, I agree that's a good change. I'll wait a few days for other
feedback and resend with that and any other changes.
> It also may be a good idea to consider detecting this case and be a
> bit more helpful, perhaps with end-user experience looking like...
>
> $ git checkout master^0
> $ git merge --no-commit next
> Updating 0d0ac3826a..ee538a81fe
> Fast-forward
> ...diffstat follows here...
> hint: merge completed without creating a commit.
> hint: if you wanted to prepare for a manually tweaked merge,
> hint: do "git reset --keep ORIG_HEAD" followed by
> hint: "git merge --no-ff --no-commit next".
>
> or even
>
> $ git checkout master^0
> $ git merge --no-commit next
> warning: defaulting to --no-ff, given a --no-commit request
> Automatic merge went well; stopped before committing as requested
> hint: if you'd rather have a fast-forward without creating a commit,
> hint: do "git reset --keep next" now.
Good points. I thought of this last one before sending, though
without pre- and post- warnings/hints; without such text it definitely
seemed too magical and possibly leading to unexpected surprises in a
different direction, so I dismissed it without further thought. But
the warnings/hints help.
> I do not have a strong preference among three (the third option
> being not doing anything), but if pressed, I'd say that the last one
> might be the most user-friendly, even though it feels a bit too
> magical and trying to be smarter than its own good.
I also lack a strong preference. Maybe mark it #leftoverbits for
someone that does?
> In any case, the hint for the "recovery" procedure needs to be
> carefully written.
Yes.
^ permalink raw reply [relevance 6%]
* Re: does "git clean" deliberately ignore "core.excludesFile"?
@ 2019-02-24 14:15 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2019-02-24 14:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robert P. J. Day, Git Mailing list
Hi,
On Sat, 23 Feb 2019, Junio C Hamano wrote:
> "Robert P. J. Day" <rpjday@crashcourse.ca> writes:
>
> > On Sat, 23 Feb 2019, Johannes Schindelin wrote:
> >
> >> Robert, care to come up with an example demonstrating where it does not?
> >
> > sorry i wasn't clear, all i was pointing out was that "man
> > git-clean" *explicitly* mentioned two locations related to cleaning:
> > ...
> > without additionally *explicitly* mentioning core.excludesFile.
>
> OK, so together with the homework Dscho did for you and what I wrote
> earlier, I think you have enough information to answer the question
> yourself.
>
> That is, the code does *not* ignore, and the doc was trying to be
> (overly) exhaustive but because it predates core.excludesFile, after
> the introduction of that configuration, it no longer is exhaustigve
> and has become stale.
>
> Which would leave a small, easy and low-hanging fruit, I guess ;-).
#leftoverbits
;-)
Thanks,
Dscho
> Thanks.
>
^ permalink raw reply [relevance 6%]
* Re: [BUG] All files in folder are moved when cherry-picking commit that moves fewer files
@ 2019-02-27 17:31 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2019-02-27 17:31 UTC (permalink / raw)
To: Jeff King; +Cc: Phillip Wood, Linus Nilsson, git@vger.kernel.org
On Wed, Feb 27, 2019 at 8:40 AM Jeff King <peff@peff.net> wrote:
>
> On Wed, Feb 27, 2019 at 08:02:35AM -0800, Elijah Newren wrote:
>
> > > > I have found what I suspect to be a bug, or at least not desirable
> > > > behavior in my case. In one branch, I have moved all files in a
> > > > directory to another directory. The first directory is now empty
> > > > in this branch (I haven't tested whether this is significant).
> > >
> > > I suspect that because you've moved all the files git thinks the
> > > directory has been renamed and that's why it moves a/file2 when fix is
> > > cherry-picked in the example below. I've cc'd Elijah as he knows more
> > > about how the directory rename detection works.
> >
> > Yes, Phillip is correct. If the branch you were
> > merging/cherry-picking still had any files at all in the original
> > directory, then no directory rename would be detected. You can read
> > up more details about how it works at
> > https://git.kernel.org/pub/scm/git/git.git/tree/Documentation/technical/directory-rename-detection.txt
>
> Is there a way to disable it (either by config, or for a single run)? I
> know there's merge.renames, but it's plausible somebody might want
> file-level renames but not directory-level ones.
>
> -Peff
Not yet. Adding such an option, similar in nature to the flags for
turning off renaming detection entirely (merge.renames, diff.renames,
-Xno-renames) would probably make sense (I don't see an analogy to
-Xrename-threshold=, though). It might make sense as just an
alternate setting of merge.renames or diff.renames, though it's
possible that could get confusing with "copy" being an option.
#leftoverbits for someone that wants to figure out what the option
names and values should be?
^ permalink raw reply [relevance 6%]
* Re: Feature request: Add --no-edit to git tag command
@ 2019-04-04 1:57 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2019-04-04 1:57 UTC (permalink / raw)
To: Robert Dailey; +Cc: Git
On Wed, Apr 03, 2019 at 09:38:02AM -0500, Robert Dailey wrote:
> Similar to git commit, it would be nice to have a --no-edit option for
> git tag. Use case is when I force-recreate a tag:
>
> $ git tag -af 1.0 123abc
>
> An editor will be prompted with the previous annotated tag message. I
> would like to add --no-edit to instruct it to use any previously
> provided message and without prompting the editor:
>
> $ git tag --no-edit -af 1.0 123abc
Yeah, that sounds like a good idea. I think it wouldn't be very hard to
implement, either. Maybe a good starter project or #leftoverbits for
somebody.
-Peff
^ permalink raw reply [relevance 6%]
* Re: Resolving deltas dominates clone time
@ 2019-04-30 18:48 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2019-04-30 18:48 UTC (permalink / raw)
To: Jeff King; +Cc: Duy Nguyen, Martin Fick, Git Mailing List
On Tue, Apr 30 2019, Jeff King wrote:
> On Tue, Apr 23, 2019 at 05:08:40PM +0700, Duy Nguyen wrote:
>
>> On Tue, Apr 23, 2019 at 11:45 AM Jeff King <peff@peff.net> wrote:
>> >
>> > On Mon, Apr 22, 2019 at 09:55:38PM -0400, Jeff King wrote:
>> >
>> > > Here are my p5302 numbers on linux.git, by the way.
>> > >
>> > > Test jk/p5302-repeat-fix
>> > > ------------------------------------------------------------------
>> > > 5302.2: index-pack 0 threads 307.04(303.74+3.30)
>> > > 5302.3: index-pack 1 thread 309.74(306.13+3.56)
>> > > 5302.4: index-pack 2 threads 177.89(313.73+3.60)
>> > > 5302.5: index-pack 4 threads 117.14(344.07+4.29)
>> > > 5302.6: index-pack 8 threads 112.40(607.12+5.80)
>> > > 5302.7: index-pack default number of threads 135.00(322.03+3.74)
>> > >
>> > > which still imply that "4" is a win over "3" ("8" is slightly better
>> > > still in wall-clock time, but the total CPU rises dramatically; that's
>> > > probably because this is a quad-core with hyperthreading, so by that
>> > > point we're just throttling down the CPUs).
>> >
>> > And here's a similar test run on a 20-core Xeon w/ hyperthreading (I
>> > tweaked the test to keep going after eight threads):
>> >
>> > Test HEAD
>> > ----------------------------------------------------
>> > 5302.2: index-pack 1 threads 376.88(364.50+11.52)
>> > 5302.3: index-pack 2 threads 228.13(371.21+17.86)
>> > 5302.4: index-pack 4 threads 151.41(387.06+21.12)
>> > 5302.5: index-pack 8 threads 113.68(413.40+25.80)
>> > 5302.6: index-pack 16 threads 100.60(511.85+37.53)
>> > 5302.7: index-pack 32 threads 94.43(623.82+45.70)
>> > 5302.8: index-pack 40 threads 93.64(702.88+47.61)
>> >
>> > I don't think any of this is _particularly_ relevant to your case, but
>> > it really seems to me that the default of capping at 3 threads is too
>> > low.
>>
>> Looking back at the multithread commit, I think the trend was the same
>> and I capped it because the gain was not proportional to the number of
>> cores we threw at index-pack anymore. I would not be opposed to
>> raising the cap though (or maybe just remove it)
>
> I'm not sure what the right cap would be. I don't think it's static;
> we'd want ~4 threads on the top case, and 10-20 on the bottom one.
>
> It does seem like there's an inflection point in the graph at N/2
> threads. But then maybe that's just because these are hyper-threaded
> machines, so "N/2" is the actual number of physical cores, and the
> inflated CPU times above that are just because we can't turbo-boost
> then, so we're actually clocking slower. Multi-threaded profiling and
> measurement is such a mess. :)
>
> So I'd say the right answer is probably either online_cpus() or half
> that. The latter would be more appropriate for the machines I have, but
> I'd worry that it would leave performance on the table for non-intel
> machines.
It would be a nice #leftoverbits project to do this dynamically at
runtime, i.e. hook up the throughput code in progress.c to some new
utility functions where the current code using pthreads would
occasionally stop and try to find some (local) maximum throughput given
N threads.
You could then dynamically save that optimum for next time, or adjust
threading at runtime every X seconds, e.g. on a server with N=24 cores
you might want 24 threads if you have one index-pack, but if you have 24
index-packs you probably don't want each with 24 threads, for a total of
576.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/2] t5616: refactor packfile replacement
@ 2019-05-15 18:22 6% ` Jonathan Tan
0 siblings, 0 replies; 200+ results
From: Jonathan Tan @ 2019-05-15 18:22 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: jonathantanmy, git
> > +# Converts bytes into their hexadecimal representation. For example,
> > +# "printf 'ab\r\n' | hex_unpack" results in '61620d0a'.
> > +hex_unpack () {
> > + perl -e '$/ = undef; $input = <>; print unpack("H2" x length($input), $input)'
> > +}
> > +
> > +# Inserts $1 at the start of the string and every 2 characters thereafter.
> > +intersperse () {
> > + sed 's/\(..\)/'$1'\1/g'
> > +}
> > +
> > +# Create a one-time-sed command to replace the existing packfile with $1.
> > +replace_packfile () {
> > + # The protocol requires that the packfile be sent in sideband 1, hence
> > + # the extra \x01 byte at the beginning.
> > + printf "1,/packfile/!c %04x\\\\x01%s0000" \
> > + "$(($(wc -c <$1) + 5))" \
> > + "$(hex_unpack <$1 | intersperse '\\x')" \
> > + >"$HTTPD_ROOT_PATH/one-time-sed"
> > }
>
> Urgh. This is not a problem *this* patch introduces, but why on Earth do
> we have to do complicated computations in shell code using an unholy mix
> of complex sed and Perl invocations, making things fragile and slow? We do
> have such a nice facility is the t/test-tool helper...
This might be a good #leftoverbits. I'm not sure which part you think
needs to be replaced - maybe the thing that goes into one-time-sed?
> The refactoring itself looks correct to me, of course.
Thanks, and thanks for taking a look at this.
^ permalink raw reply [relevance 6%]
* Re: [2.22.0] difftool no longer passes through to git diff if diff.tool is unset
@ 2019-06-26 18:08 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2019-06-26 18:08 UTC (permalink / raw)
To: Pugh, Logan; +Cc: git@vger.kernel.org, liu.denton@gmail.com
On Tue, Jun 25, 2019 at 11:09:08PM +0000, Pugh, Logan wrote:
> > Or in your case I suppose even better would just be an
> > option like "--if-not-configured-just-use-regular-diff". Then it would
> > do what you want, without impacting users who do want the interactive
> > setup.
>
> If such an option was considered I would be in favor of it. Maybe call
> it "--no-tutorial" or perhaps "--diff-fallback".
>
> But having fixed my app, I'm content with the status quo too, now.
Yeah, those are definitely better names. :)
I think we're on the same page about a good path forward, then. I don't
plan to work on this myself, but maybe it would be a good #leftoverbits
candidate for somebody wanting to get started on modifying Git.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 20/23] .gitignore: touch up the entries regarding Visual Studio
@ 2019-08-28 11:34 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2019-08-28 11:34 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Philip Oakley, Philip Oakley via GitGitGadget, git,
Junio C Hamano, Cesar Eduardo Barros
[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]
Hi Gábor,
On Mon, 26 Aug 2019, SZEDER Gábor wrote:
> On Sun, Aug 25, 2019 at 11:21:23PM +0100, Philip Oakley wrote:
> > >>>>diff --git a/.gitignore b/.gitignore
> > >>>>index e096e0a51c..e7bb15d301 100644
> > >>>>--- a/.gitignore
> > >>>>+++ b/.gitignore
> > >>>>@@ -230,6 +230,7 @@
> > >>>> *.ipdb
> > >>>> *.dll
> > >>>> .vs/
> > >>>>-/Debug/
> > >>>>-/Release/
> > >>>>+*.manifest
> > >>>This new line ignores the tracked file 'compat/win32/git.manifest'
> > >>>that was added fairly recently in fe90397604 (mingw: embed a manifest
> > >>>to trick UAC into Doing The Right Thing, 2019-06-27).
> > >>>
> > >>>I wonder whether that's intentional or accidental.
> > >>>
> > >>>I'm inclined to think that it's merely accidental, because, as far as
> > >>>I understand, this is an old-ish patch from times when there wasn't
> > >>>any 'git.manifest' file in tree, and simply noone noticed that in the
> > >>>meantime we got one. But I have no idea about how a Git build with
> > >>>Visual Studio is supposed to work, so it doesn't really matter what
> > >>>I'm inclined to think :)
> > >>>
> > >>At the time, it was just one of the many non-source files that were
> > >>generated by Visual Studio that cluttered the status list and also could
> > >>accidentally added to the tracked files.
> > >>
> > >>The newly added .manifest file does appear to be there to 'trick' the
> > >>Windows User Access Control (UAC) which otherwise can be an annoyance to
> > >>'regular' users.
> > >Sorry, I'm not sure how to interpret your reply, and can't decide
> > >whether it tries to justify why that tracked file should be ignored,
> > >or explains that ignoring it was accidental.
> > >
> > >Anyway, ignoring that tracked file apparently triggered a nested
> > >worktree-related bug in 'git clean', which can lead to data loss:
> > >
> > >https://public-inbox.org/git/20190825185918.3909-1-szeder.dev@gmail.com/
> > >
> > Basically manifests are a build artefact from Visual Studio [1], so it was
> > just another file to be ignored, from a _source_ control control viewpoint.
>
> I understand that manifest files, in general, are build artifacts.
> But does Visual Studio overwrite the existing
> 'compat/win32/git.manifest' file in particular? Yes or no? :)
No.
The reason this entry was there: at least _some_ Visual Studio versions
(IIRC), auto-generates `.manifest` files when the project does not have
any. But now we do. So this line's gotta go.
#leftoverbits ?
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* Re: [PATCH] t: use LF variable defined in the test harness
@ 2019-09-05 18:47 6% ` Jeff King
2019-09-05 19:34 6% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Jeff King @ 2019-09-05 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Taylor Blau, git
On Thu, Sep 05, 2019 at 11:17:57AM -0700, Junio C Hamano wrote:
> Somebody may want to go clean-up the use of various $sq and $SQ
> locally defined by giving a unified $SQ in test-lib.sh, by the way.
Maybe good #leftoverbits material, since we may have Outreachy
applications coming up soon.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH] t: use LF variable defined in the test harness
2019-09-05 18:47 6% ` Jeff King
@ 2019-09-05 19:34 6% ` Junio C Hamano
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2019-09-05 19:34 UTC (permalink / raw)
To: Jeff King; +Cc: Taylor Blau, git
Jeff King <peff@peff.net> writes:
> On Thu, Sep 05, 2019 at 11:17:57AM -0700, Junio C Hamano wrote:
>
>> Somebody may want to go clean-up the use of various $sq and $SQ
>> locally defined by giving a unified $SQ in test-lib.sh, by the way.
>
> Maybe good #leftoverbits material, since we may have Outreachy
> applications coming up soon.
OK, then I'd refrain from doing it as a lunchtime hack myself ;-)
* Find sq=, $sq and ${sq} case insensitively in t/. If there is
any use of $SQ that does not want a single quote in it, abort
the whole thing. Otherwise proceed.
* Introduce an assignment SQ=\' in t/test-lib.sh, next to where LF
is assigned to. Replace all uses you found in #1 with reference
to $SQ.
#leftoverbits.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] t: use common $SQ variable
@ 2019-09-05 22:25 6% ` Taylor Blau
2019-09-05 22:27 6% ` Taylor Blau
0 siblings, 1 reply; 200+ results
From: Taylor Blau @ 2019-09-05 22:25 UTC (permalink / raw)
To: Denton Liu; +Cc: Git Mailing List, Junio C Hamano, Jeff King, Taylor Blau
On Thu, Sep 05, 2019 at 03:10:05PM -0700, Denton Liu wrote:
> In many test scripts, there are bespoke definitions of the single quote
> that are some variation of this:
>
> SQ="'"
>
> Define a common $SQ variable in test-lib.sh and replace all usages of
> these bespoke variables with the common one.
>
> This change was done by running `git grep =\"\'\" t/` and
> `git grep =\\\\\'` and manually changing the resulting definitions and
> corresponding usages.
> Signed-off-by: Denton Liu <liu.denton@gmail.com>
> ---
>
> [whoops, forgot to include the mailing list in the last email]
>
> Sorry, I wrote this patch up before I saw the email about leaving this
> as #leftoverbits. No point in letting it go to waste, though.
Thanks for doing this. I marked it as '#leftoverbits' in case anybody
hosting an Outreachy intern might be interested in having something
small for a newcomer to dip their toes into sending to the mailing list.
But, there's no shortage of other such tasks, I'd assume, so it's good
that you cleaned these up.
Both of your 'git grep' invocations look correct to me, so the patch
below looks like an obviously-correct result. Thanks.
-Taylor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] t: use common $SQ variable
2019-09-05 22:25 6% ` Taylor Blau
@ 2019-09-05 22:27 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2019-09-05 22:27 UTC (permalink / raw)
To: Taylor Blau; +Cc: Denton Liu, Git Mailing List, Junio C Hamano, Jeff King
On Thu, Sep 05, 2019 at 06:25:26PM -0400, Taylor Blau wrote:
> On Thu, Sep 05, 2019 at 03:10:05PM -0700, Denton Liu wrote:
> > In many test scripts, there are bespoke definitions of the single quote
> > that are some variation of this:
> >
> > SQ="'"
> >
> > Define a common $SQ variable in test-lib.sh and replace all usages of
> > these bespoke variables with the common one.
> >
> > This change was done by running `git grep =\"\'\" t/` and
> > `git grep =\\\\\'` and manually changing the resulting definitions and
> > corresponding usages.
> > Signed-off-by: Denton Liu <liu.denton@gmail.com>
> > ---
> >
> > [whoops, forgot to include the mailing list in the last email]
> >
> > Sorry, I wrote this patch up before I saw the email about leaving this
> > as #leftoverbits. No point in letting it go to waste, though.
>
> Thanks for doing this. I marked it as '#leftoverbits' in case anybody
> hosting an Outreachy intern might be interested in having something
> small for a newcomer to dip their toes into sending to the mailing list.
Oh, how silly of me. I was thinking about [1], which I said would be
good #leftoverbits material. This thread was tagged by Junio, not me.
The rest of my point stands, though ;).
> But, there's no shortage of other such tasks, I'd assume, so it's good
> that you cleaned these up.
>
> Both of your 'git grep' invocations look correct to me, so the patch
> below looks like an obviously-correct result. Thanks.
>
> -Taylor
Thanks,
Taylor
[1]: https://public-inbox.org/git/20190904212121.GB20904@syl.local/
^ permalink raw reply [relevance 6%]
* Re: [RFC PATCH v2 12/12] clean: fix theoretical path corruption
@ 2019-09-07 0:34 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2019-09-07 0:34 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Git Mailing List, Jeff King, Rafael Ascensão, Samuel Lijin
On Thu, Sep 5, 2019 at 12:27 PM SZEDER Gábor <szeder.dev@gmail.com> wrote:
>
> On Thu, Sep 05, 2019 at 08:47:35AM -0700, Elijah Newren wrote:
> > cmd_clean() had the following code structure:
> >
> > struct strbuf abs_path = STRBUF_INIT;
> > for_each_string_list_item(item, &del_list) {
> > strbuf_addstr(&abs_path, prefix);
> > strbuf_addstr(&abs_path, item->string);
> > PROCESS(&abs_path);
> > strbuf_reset(&abs_path);
> > }
> >
> > where I've elided a bunch of unnecessary details and PROCESS(&abs_path)
> > represents a big chunk of code rather than an actual function call. One
> > piece of PROCESS was:
> >
> > if (lstat(abs_path.buf, &st))
> > continue;
> >
> > which would cause the strbuf_reset() to be missed -- meaning that the
> > next path to be handled would have two paths concatenated. This path
> > used to use die_errno() instead of continue prior to commit 396049e5fb62
> > ("git-clean: refactor git-clean into two phases", 2013-06-25), but my
> > understanding of how correct_untracked_entries() works is that it will
> > prevent both dir/ and dir/file from being in the list to clean so this
> > should be dead code and the die_errno() should be safe. But I hesitate
> > to remove it since I am not certain. Instead, just fix it to avoid path
> > corruption in case it is possible to reach this continue statement.
> >
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> > builtin/clean.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/builtin/clean.c b/builtin/clean.c
> > index 6030842f3a..ccb6e23f0b 100644
> > --- a/builtin/clean.c
> > +++ b/builtin/clean.c
> > @@ -1028,8 +1028,10 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
> > * recursive directory removal, so lstat() here could
> > * fail with ENOENT.
> > */
> > - if (lstat(abs_path.buf, &st))
> > + if (lstat(abs_path.buf, &st)) {
> > + strbuf_reset(&abs_path);
> > continue;
> > + }
>
> I wonder whether it would be safer to call strbuf_reset() at the start
> of each loop iteration instead of before 'continue'. That way we
> wouldn't have to worry about another 'continue' statements forgetting
> about it.
>
> It probably doesn't really matter in this particular case (considering
> that it's potentially dead code to begin with), but have a look at
> e.g. diff.c:show_stats() and its several strbuf_reset(&out) calls
> preceeding continue statements.
Ooh, I like that idea. I think I'll apply that here. I'll probably
leave diff.c:show_stats() as #leftoverbits for someone else, though I
really like the idea of fixing up other issues like this as you
suggest.
^ permalink raw reply [relevance 6%]
* Re: Git in Outreachy December 2019?
@ 2019-09-26 11:42 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2019-09-26 11:42 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Jeff King, git, Olga Telezhnaya, Christian Couder, Elijah Newren,
Thomas Gummerer, Matheus Tavares Bernardino
[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]
Hi,
On Mon, 23 Sep 2019, SZEDER Gábor wrote:
> On Wed, Sep 04, 2019 at 03:41:15PM -0400, Jeff King wrote:
> > The project page has a section to point people in the right direction
> > for first-time contributions. I've left it blank for now, but I think it
> > makes sense to point one (or both) of:
> >
> > - https://git-scm.com/docs/MyFirstContribution
> >
> > - https://matheustavares.gitlab.io/posts/first-steps-contributing-to-git
> >
> > as well as a list of micro-projects (or at least instructions on how to
> > find #leftoverbits, though we'd definitely have to step up our labeling,
> > as I do not recall having seen one for a while).
>
> And we should make sure that all microprojects are indeed micro in
> size. Matheus sent v8 of a 10 patch series in July that started out
> as a microproject back in February...
Indeed.
> Here is one more idea for microprojects:
>
> Find a group of related preprocessor constants and turn them into an
> enum. Also find where those constants are stored in variables and
> in structs and passed around as function parameters, and change the
> type of those variables, fields and parameters to the new enum.
I agree that this is a good suggestion, and turned this #leftoverbits
into https://github.com/gitgitgadget/git/issues/357.
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 1/2] sequencer: move check_todo_list_from_file() to rebase-interactive.c
@ 2019-12-06 14:38 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2019-12-06 14:38 UTC (permalink / raw)
To: Alban Gruin; +Cc: git, Phillip Wood, Junio C Hamano
Hi Alban,
On Tue, 3 Dec 2019, Alban Gruin wrote:
> The message contained in `edit_todo_list_advice' (sequencer.c) is
> printed after the initial edit of the todo list if it can't be parsed or
> if commits were dropped. This is done either in complete_action() for
> `rebase -i', or in check_todo_list_from_file() for `rebase -p'.
>
> Since we want to add this check when editing the list, we also want to
> use this message from edit_todo_list() (rebase-interactive.c). To this
> end, check_todo_list_from_file() is moved to rebase-interactive.c, and
> `edit_todo_list_advice' is copied there. In the next commit,
> complete_action() will stop using it, and `edit_todo_list_advice' will
> be removed from sequencer.c.
Makes sense to me.
> diff --git a/rebase-interactive.c b/rebase-interactive.c
> index aa18ae82b7..ad5dd49c31 100644
> --- a/rebase-interactive.c
> +++ b/rebase-interactive.c
> @@ -187,3 +193,32 @@ int todo_list_check(struct todo_list *old_todo, struct todo_list *new_todo)
> clear_commit_seen(&commit_seen);
> return res;
> }
> +
> +int check_todo_list_from_file(struct repository *r)
> +{
> + struct todo_list old_todo = TODO_LIST_INIT, new_todo = TODO_LIST_INIT;
> + int res = 0;
> +
> + if (strbuf_read_file(&new_todo.buf, rebase_path_todo(), 0) < 0) {
> + res = error(_("could not read '%s'."), rebase_path_todo());
> + goto out;
> + }
> +
> + if (strbuf_read_file(&old_todo.buf, rebase_path_todo_backup(), 0) < 0) {
> + res = error(_("could not read '%s'."), rebase_path_todo_backup());
> + goto out;
> + }
> +
> + res = todo_list_parse_insn_buffer(r, old_todo.buf.buf, &old_todo);
> + if (!res)
> + res = todo_list_parse_insn_buffer(r, new_todo.buf.buf, &new_todo);
> + if (!res)
> + res = todo_list_check(&old_todo, &new_todo);
> + if (res)
> + fprintf(stderr, _(edit_todo_list_advice));
> +out:
> + todo_list_release(&old_todo);
> + todo_list_release(&new_todo);
> +
> + return res;
> +}
No need to address the following concern in this patch series, but I do
think that a #leftoverbits project could be to simplify this to
if (strbuf_read_file(&new_todo.buf, rebase_path_todo(), 0) < 0)
res = error(_("could not read '%s'."), rebase_path_todo());
else if (strbuf_read_file(&old_todo.buf, rebase_path_todo_backup(), 0) < 0)
res = error(_("could not read '%s'."), rebase_path_todo_backup());
else if ((res = todo_list_parse_insn_buffer(r, old_todo.buf.buf, &old_todo)) ||
(res = todo_list_parse_insn_buffer(r, new_todo.buf.buf, &new_todo)) ||
(res = todo_list_check(&old_todo, &new_todo)))
fprintf(stderr, _(edit_todo_list_advice));
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 1/1] gpg-interface: add minTrustLevel as a configuration option
@ 2019-12-27 22:21 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2019-12-27 22:21 UTC (permalink / raw)
To: Hans Jerry Illikainen; +Cc: git
Hans Jerry Illikainen <hji@dyntopia.com> writes:
>> I wonder if the code becomes less misleading if we either (1)
>> renamed 'next' to a name that hints more strongly that it is not the
>> 'next' line but the end of the current token we are interested in,
>> or (2) get rid of the pointer and instead counted size of the
>> current token we are interested in, or perhaps both?
>
> Yeah the name 'next' does seem a bit counter-intuitive when used in
> relation to 'line'. Looking through the function it seems that both (1)
> and (2) would work.
Thanks for thinking the code a bit more than necessary for the
purpose of this topic. Let's leave such a clean-up outside the
scope of this topic, but perhaps a #leftoverbits marker may help us
remember it as something we could do when we have nothing else
better to do ;-)
^ permalink raw reply [relevance 6%]
* Re: [RFC][GSOC] Microproject Suggestion
@ 2020-02-14 8:49 6% ` Denton Liu
0 siblings, 0 replies; 200+ results
From: Denton Liu @ 2020-02-14 8:49 UTC (permalink / raw)
To: Robear Selwans; +Cc: Junio C Hamano, git
Hi Robear,
On Fri, Feb 14, 2020 at 09:29:33AM +0200, Robear Selwans wrote:
> That was actually the only idea that I could come up with till now. I
> am open to suggestions, though. I don't really mind if it is too big,
> as I am also interested in contributing to git.
Even though Git doesn't have an offical issue tracker, one good place to
look is GitGitGadget's issue[1]. It's pretty well-curated and has a lot
of tiny cleanup issues that you could get started on.
Another thing you could do to find inspiration is to search for
#leftoverbits on your Git mailing list archive of choice (most people
seem to use lore.kernel.org/git).
Hope that helps,
Denton
[1]: https://github.com/gitgitgadget/git/issues
^ permalink raw reply [relevance 6%]
* Re: [PATCH] commit-graph: fix buggy --expire-time option
@ 2020-04-01 20:33 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-04-01 20:33 UTC (permalink / raw)
To: Jeff King; +Cc: Derrick Stolee via GitGitGadget, git, me, Derrick Stolee
Jeff King <peff@peff.net> writes:
> On Wed, Apr 01, 2020 at 12:49:25PM -0700, Junio C Hamano wrote:
>
>> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>
>> > diff --git a/t/t5324-split-commit-graph.sh b/t/t5324-split-commit-graph.sh
>> > index 53b2e6b4555..4e4efcaff22 100755
>> > --- a/t/t5324-split-commit-graph.sh
>> > +++ b/t/t5324-split-commit-graph.sh
>> > @@ -210,8 +210,10 @@ test_expect_success 'test merge stragety constants' '
>> > git config core.commitGraph true &&
>> > test_line_count = 2 $graphdir/commit-graph-chain &&
>> > test_commit 15 &&
>> > - git commit-graph write --reachable --split --size-multiple=10 --expire-time=1980-01-01 &&
>> > + touch -m -t 201801010000.00 $graphdir/extra.graph &&
>>
>> We have "test-tool chmtime" since 17e48368 (Add test-chmtime: a
>> utility to change mtime on files, 2007-02-24) and refrained from
>> using "touch -t" anywhere in our tests. Can we use it here, too?
>
> There are a couple new ones added last year in t5319. Nobody has
> complained yet, but I wonder if it's a matter of time.
Indeed. We should fix them (#leftoverbits).
^ permalink raw reply [relevance 6%]
* Re: [PATCH] checkout -p: handle new files correctly
@ 2020-05-27 19:51 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2020-05-27 19:51 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin via GitGitGadget, git, Merlin Büge
Hi Peff,
On Wed, 27 May 2020, Jeff King wrote:
> On Wed, May 27, 2020 at 09:09:06PM +0000, Johannes Schindelin via GitGitGadget wrote:
>
> > However, since the same machinery was used for `git checkout -p` &
> > friends, we can see new files.
> >
> > Handle this case specifically, adding a new prompt for it that is
> > modeled after the `deleted file` case.
>
> Thanks! I was planning to dig further into this topic today, and here it
> is all wrapped up with a bow. :)
:-)
>
> > add-patch.c | 30 +++++++++++++++++++++++-------
> > git-add--interactive.perl | 21 +++++++++++++++++++--
>
> Ooh, you even fixed the perl version, too. I was just going to leave it
> in the dust and add a test that set GIT_TEST_ADD_I_USE_BUILTIN.
As long as there is an escape hatch, I try to keep it working.
> Both versions look good, and are similar to what I expected from looking
> at it last night.
Thank you!
> > The original patch selection code was written for `git add -p`, and the
> > fundamental unit on which it works is a hunk.
> >
> > We hacked around that to handle deletions back in 24ab81ae4d
> > (add-interactive: handle deletion of empty files, 2009-10-27). But `git
> > add -p` would never see a new file, since we only consider the set of
> > tracked files in the index.
>
> I lied a little with "would never see a new file". There _is_ a related
> case with "add -p" that might be worth thinking about: intent-to-add
> files.
Indeed. Maybe I can leave that as #leftoverbits?
Ciao,
Dscho
>
> $ git init
> $ >empty
> $ echo content >not-empty
> $ git add -N .
> $ git add -p
> diff --git a/not-empty b/not-empty
> index e69de29..d95f3ad 100644
> --- a/not-empty
> +++ b/not-empty
> @@ -0,0 +1 @@
> +content
> (1/1) Stage this hunk [y,n,q,a,d,e,?]? n
>
> [no mention of empty file!]
>
> I think the culprit here is diff-files, though, which doesn't show a
> patch for intent-to-add:
>
> $ git diff-files
> :100644 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0000000000000000000000000000000000000000 M empty
> :100644 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0000000000000000000000000000000000000000 M not-empty
>
> $ git diff-files -p
> diff --git a/not-empty b/not-empty
> index e69de29..d95f3ad 100644
> --- a/not-empty
> +++ b/not-empty
> @@ -0,0 +1 @@
> +content
>
> I don't think this really intersects with the patch here at all, because
> diff-files is not producing "new file" lines for these entries (even for
> the non-empty one).
>
> The solution _might_ be to convince diff-files to treat i-t-a entries as
> creations. And then with your patch here, we'd naturally do the right
> thing. So I don't think this needs to hold up your patch in any way, nor
> do we necessarily need to deal with i-t-a now. I was mostly curious how
> they worked, since we don't support added files. The answer is just that
> they don't always. ;)
>
> -Peff
>
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/3] docs: adjust for the recent rename of `pu` to `seen`
@ 2020-06-23 21:32 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2020-06-23 21:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Đoàn Trần Công Danh,
Johannes Schindelin via GitGitGadget, git
[-- Attachment #1: Type: text/plain, Size: 2958 bytes --]
Hi Junio & Danh,
On Tue, 23 Jun 2020, Junio C Hamano wrote:
> Đoàn Trần Công Danh <congdanhqx@gmail.com> writes:
>
> > On 2020-06-23 15:04:13+0000, Johannes Schindelin via GitGitGadget <gitgitgadget@gmail.com> wrote:
> >> diff --git a/Documentation/git-ls-remote.txt b/Documentation/git-ls-remote.txt
> >> index 0a5c8b7d493..492e573856f 100644
> >> --- a/Documentation/git-ls-remote.txt
> >> +++ b/Documentation/git-ls-remote.txt
> >> @@ -101,9 +101,9 @@ f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
> >> 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
> >> c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
> >> 0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub
> >> -$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
> >> +$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
> >
> > rc is not with us anymore.
> >
> > Should we replace it with next, too?
>
> I do not think so. I think we never had 'rc'.
Indeed, and the context given in the patch demonstrates that no `rc` is
shown, so I assumed the same things as Junio explained here:
> I think what the above example is demonstrating is this.
>
> SYNOPSIS calls the last command line arguments <refs>; they are
> actually mere patterns (which is how these command line
> arguments are described in the documentation). It is *not* an
> error if no refs match a particular pattern.
>
> And because we have no refs that match the pattern "rc", we only see
> "master" and "pu" (now "seen") from the command.
Precisely.
> I see a couple of possible improvements here:
>
> - The "<refs>...::" documentation should explain what kind of
> pattern match is performed here. I recall these originally were
> just tail matches, but the rule might have been made more
> flexible over time.
>
> - The example should first explain the setting. The first sample
> depends on the current (./.) repository having these tags or it
> would not work (showing the sample upfront and explaining the
> outcome shown in the sample would work well in this case,
> e.g. "we can see that in the current repository, there are tags
> X, Y and Z"). The second one at least needs to say two things:
> the sample repository does not have a branch called 'rc' and that
> is why it is not shown, and it is not an error for patterns to
> produce no match.
Those sound like wonderful #leftoverbits to me.
Thank you,
Dscho
>
> Thanks.
>
> >
> >> 5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master
> >> -c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/pu
> >> +c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/seen
> >> $ git remote add korg http://www.kernel.org/pub/scm/git/git.git
> >> $ git ls-remote --tags korg v\*
> >> d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
>
^ permalink raw reply [relevance 6%]
* Re: [PATCH v7 0/5] cleanup ra/rebase-i-more-options
@ 2020-07-16 17:39 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-07-16 17:39 UTC (permalink / raw)
To: Phillip Wood
Cc: Johannes Schindelin, Elijah Newren, Rohit Ashiwal,
Đoàn Trần Công Danh, Alban Gruin,
Git Mailing List, Phillip Wood
Phillip Wood <phillip.wood123@gmail.com> writes:
> format-patch and am could do with having their similar messages
> updated in the future
That's a good #leftoverbits topic.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2] rebase -i: Fix possibly wrong onto hash in todo
@ 2020-08-13 10:41 6% ` Alban Gruin
0 siblings, 0 replies; 200+ results
From: Alban Gruin @ 2020-08-13 10:41 UTC (permalink / raw)
To: Antti Keränen, git
Cc: Taylor Blau, Jussi Keränen, Junio C Hamano, Phillip Wood,
Johannes Schindelin
Hi Antti,
Le 12/08/2020 à 20:33, Antti Keränen a écrit :
> 'todo_list_write_to_file' may overwrite the static buffer, originating
> from 'find_unique_abbrev', that was used to store the short commit hash
> 'c' for "# Rebase a..b onto c" message in the todo editor. This is
> because the buffer that is returned from 'find_unique_abbrev' is valid
> until 4 more calls to `find_unique_abbrev` are made.
>
> As 'todo_list_write_to_file' calls 'find_unique_abbrev' for each rebased
> commit, the hash for 'c' is overwritten if there are 4 or more commits
> in the rebase. This behavior has been broken since its introduction.
>
> Fix by storing the short onto commit hash in a different buffer that
> remains valid, before calling 'todo_list_write_to_file'.
>
> Found-by: Jussi Keränen <jussike@gmail.com>
> Signed-off-by: Antti Keränen <detegr@rbx.email>
> ---
> sequencer.c | 5 +++--
> t/t3404-rebase-interactive.sh | 6 ++++++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index fd7701c88a..e2007dbb8c 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -5178,13 +5178,14 @@ int complete_action(struct repository *r, struct replay_opts *opts, unsigned fla
> struct string_list *commands, unsigned autosquash,
> struct todo_list *todo_list)
> {
> - const char *shortonto, *todo_file = rebase_path_todo();
> + char shortonto[GIT_MAX_HEXSZ + 1];
> + const char *todo_file = rebase_path_todo();
> struct todo_list new_todo = TODO_LIST_INIT;
> struct strbuf *buf = &todo_list->buf, buf2 = STRBUF_INIT;
> struct object_id oid = onto->object.oid;
> int res;
>
> - shortonto = find_unique_abbrev(&oid, DEFAULT_ABBREV);
> + find_unique_abbrev_r(shortonto, &oid, DEFAULT_ABBREV);
>
> if (buf->len == 0) {
> struct todo_item *item = append_new_todo(todo_list);
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index 4a7d21f898..1b4fa0843e 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -1760,6 +1760,12 @@ test_expect_success 'correct error message for commit --amend after empty pick'
> test_i18ngrep "middle of a rebase -- cannot amend." err
> '
>
> +test_expect_success 'todo has correct onto hash' '
> + GIT_SEQUENCE_EDITOR=cat git rebase -i no-conflict-branch~4 no-conflict-branch >actual &&
> + onto=$(git rev-parse --short HEAD~4) &&
> + test_i18ngrep "^# Rebase ..* onto $onto" actual
> +'
> +
> # This must be the last test in this file
> test_expect_success '$EDITOR and friends are unchanged' '
> test_editor_unchanged
>
Looks good to me.
Acked-by: Alban Gruin <alban.gruin@gmail.com>
This makes me wonder if it's worth to do the same change in
todo_list_to_strbuf(). #leftoverbits, perhaps?
Cheers,
Alban
^ permalink raw reply [relevance 6%]
* Re: [PATCH] clone: add remote.cloneDefault config option
@ 2020-08-26 19:59 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-08-26 19:59 UTC (permalink / raw)
To: Derrick Stolee; +Cc: Sean Barag via GitGitGadget, git, Sean Barag
Derrick Stolee <stolee@gmail.com> writes:
> On 8/26/2020 2:46 PM, Junio C Hamano wrote:
>> "Sean Barag via GitGitGadget" <gitgitgadget@gmail.com> writes:
>>> This commit implements
>>> `remote.cloneDefault` as a parallel to `remote.pushDefault`,
>>> with prioritized name resolution:
>>
>> I highly doubt that .cloneDefault is a good name. After reading
>> only the title of the patch e-mail, i.e. when the only available
>> information on the change available to me was the name of the
>> configuration variable and the fact that it pertains to the command
>> "git clone", I thought it is to specify a URL, from which "git
>> clone" without the URL would clone from that single repository.
>>
>> And the name will cause the same misunderstanding to normal users,
>> not just to reviewers of your patch, after this change hits a future
>> Git release.
>>
>> Taking a parallel from init.defaultBranchName, I would probably call
>> it clone.defaultUpstreamName if I were writing this feature.
>
> I was thinking "clone.defaultRemoteName" makes it clear we are naming
> the remote for the provided <url> in the command.
I 100% agree that defaultremotename is much better.
>> ... For example
>>
>> git -c remote.cloneDefault="bad.../...name" clone parent
>>
>> should fail, no?
>
> This is an important suggestion.
To be fair, the current code does not handle the "--origin" command
line option not so carefully.
Back when the command was scripted, e.g. 47874d6d (revamp git-clone
(take #2)., 2006-03-21), had both ref-format check and */*
multi-level check, and these checks been retained throughout its
life until 8434c2f1 (Build in clone, 2008-04-27) rewrote the whole
thing while discarding these checks for --origin=bad.../...name
It would make an excellent #leftoverbits or #microproject.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] run_command: teach API users to use embedded 'args' more
@ 2020-08-27 4:30 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-08-27 4:30 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> I've actually considered dropping child_process.argv entirely. Having
> two separate ways to do the same thing gives the potential for
> confusion. But I never dug into whether any existing callers would be
> made worse for it (I kind of doubt it, though; worst case they can use
> strvec_pushv). There are still several left after this patch, it seems.
>
> Likewise for child_process.env_array.
Yup, conversion similar to what I did in this patch may be too
trivial for #microproject, but would nevertheless be a good
#leftoverbits task. The removal of .argv/.env is not entirely
trivial but a good candidate for #microproject.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: Git in Outreachy?
@ 2020-08-31 17:41 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-08-31 17:41 UTC (permalink / raw)
To: Jeff King; +Cc: git, Christian Couder, Johannes Schindelin
Jeff King <peff@peff.net> writes:
> Are we interested in participating in the December 2020 round of
> Outreachy? The community application period is now open.
>
> I can look into lining up funding, but we'd also need:
>
> - volunteers to act as mentors
>
> - updates to our applicant materials (proposed projects, but also
> microproject / patch suggestions)
>
> -Peff
FWIW, I am interested in seeing this project participating. As
usual, I won't be able to mentor to avoid biases, though.
As to microprojects, I think we saw #leftoverbits and #micrproject
sprinkled in a handful of messages in recent discussions, so with
the help of list archive, we may come up with new ones.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2] gitweb: map names/emails with mailmap
@ 2020-09-07 22:10 6% ` Emma Brooks
0 siblings, 0 replies; 200+ results
From: Emma Brooks @ 2020-09-07 22:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jakub Narębski
On 2020-09-04 20:26:11-0700, Junio C Hamano wrote:
> Emma Brooks <me@pluvano.com> writes:
>
> > However, I couldn't find a way to get "rev-list --format" to separate
> > commits with NULs.
>
> A workaround would be "git rev-list --format='%s%x00'", iow,
> manually insert NUL
>
> I would have expected "-z" to replace LF with NUL, but that does not
> appear to work X-<.
Thanks. I'll need to ignore the extra LF when parsing then. Later, "-z"
support could be added/fixed in rev-list (#leftoverbits?) and gitweb
could be updated to use that instead.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v4] diff: make diff_free_filespec_data accept NULL
@ 2020-11-11 16:28 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2020-11-11 16:28 UTC (permalink / raw)
To: Jinoh Kang; +Cc: Junio C Hamano, git
Hi Jinoh,
On Wed, 11 Nov 2020, Jinoh Kang wrote:
> On 11/10/20 3:38 PM, Johannes Schindelin wrote:
> >
> >> + git checkout -B conflict-a &&
> >> + git checkout -B conflict-b &&
> >> + git checkout conflict-a &&
> >> + echo conflict-a >>file &&
> >> + git add file &&
> >> + git commit -m conflict-a &&
> >> + git checkout conflict-b &&
> >> + echo conflict-b >>file &&
> >> + git add file &&
> >> + git commit -m conflict-b &&
> >> + git checkout master &&
> >> + git merge conflict-a &&
> >> + test_must_fail git merge conflict-b &&
> >> + : >expect &&
> >> + git difftool --cached --no-prompt >actual &&
> >> + test_cmp expect actual
> >
> > Shouldn't this use the `test_must_be_empty` function instead?
> >
> > How about writing the test case this way:
> >
> > test_expect_success 'difftool --cached with unmerged files' '
> > test_when_finished git reset --hard &&
> >
> > test_commit conflicting &&
> > test_commit conflict-a a conflicting.t &&
> > git reset --hard conflicting &&
> > test_commit conflict-b b conflicting.t &&
> > test_must_fail git merge conflict-a &&
> >
> > git difftool --cached --no-prompt >out &&
> > test_must_be_empty out
> > '
>
> The original test code was copied from the "difftool --dir-diff with
> unmerged files" case above.
>
> It might be worth cleaning it up too, but let's leave it for another
> time.
Indeed. #leftoverbits
Thanks,
Dscho
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3] usage: add trace2 entry upon warning()
@ 2020-11-24 22:15 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-11-24 22:15 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
Jonathan Tan <jonathantanmy@google.com> writes:
> Emit a trace2 error event whenever warning() is called, just like when
> die(), error(), or usage() is called.
>
> This helps debugging issues that would trigger warnings but not errors.
> In particular, this might have helped debugging an issue I encountered
> with commit graphs at $DAYJOB [1].
>
> There is a tradeoff between including potentially relevant messages and
> cluttering up the trace output produced. I think that warning() messages
> should be included in traces, because by its nature, Git is used over
> multiple invocations of the Git tool, and a failure (currently traced)
> in a Git invocation might be caused by an unexpected interaction in a
> previous Git invocation that only has a warning (currently untraced) as
> a symptom - as is the case in [1].
>
> [1] https://lore.kernel.org/git/20200629220744.1054093-1-jonathantanmy@google.com/
>
> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
> ---
> Thanks, Junio. That comment looks good. Here is the version with Junio's
> suggested comment included, for everyone's reference.
Heh, I meant it as more of a #leftoverbit, not directly applicable to
this particular patch, but would be a good follow-up topic, as I would
have expected that die/warn/error should lose their own comments where
they call trace2_cmd_error_va() in the same patch that adds the comment
for callers near the function.
Let's use v2 if the difference between v2 and v3 is only the
addition of the comment before trace2_cmd_error_va() function decl
to help the callers.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/2] pack-format.txt: define "varint" format
@ 2020-12-29 22:41 6% ` Martin Ågren
0 siblings, 0 replies; 200+ results
From: Martin Ågren @ 2020-12-29 22:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ross Light, Git Mailing List
On Mon, 21 Dec 2020 at 22:40, Junio C Hamano <gitster@pobox.com> wrote:
>
> Martin Ågren <martin.agren@gmail.com> writes:
>
> > We define our varint format pretty much on the fly as we describe a pack
> > file entry. In preparation for referring to it in more places in this
> > document, define "varint" and refer to it.
> We need to be careful when using a generic "varint" to mean the
> older variant as it would confuse readers of OFS_DELTA section.
>
> ... goes and looks ...
>
> The phrase "offset encoding" is used in the document to talk about
> OFS_DELTA offset. It is actually what the rest of the code thinks
> is the canonical varint defined in varint.[ch]).
>
> A way to avoid confusion would be to refrain from using "varint" as
> the primary way to describe this size field; instead explain it as
> the "size encoding", to match "offset encoding" used for OFS_DELTA.
Thank you very much for these comments. I will post a v2 soon, which
will do exactly this: avoid "varint" in favor of "size encoding".
> It may also help if we added to the description of "offset encoding"
> that it is what other parts of the system consider the canonical
> "varint" encoding.
I will leave this as #leftoverbits, though. I'll "only" fix the omission
reported by Ross.
Martin
^ permalink raw reply [relevance 6%]
* Re: [PATCH 08/11] merge-ort: implement CE_SKIP_WORKTREE handling with conflicted entries
@ 2021-03-08 20:54 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2021-03-08 20:54 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: Elijah Newren via GitGitGadget, Git Mailing List, Jonathan Nieder,
Derrick Stolee, Junio C Hamano
On Mon, Mar 8, 2021 at 5:06 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>
>
> On Fri, Mar 05 2021, Elijah Newren via GitGitGadget wrote:
>
> > From: Elijah Newren <newren@gmail.com>
> >
> > When merge conflicts occur in paths removed by a sparse-checkout, we
> > need to unsparsify those paths (clear the SKIP_WORKTREE bit), and write
> > out the conflicted file to the working copy. In the very unlikely case
> > that someone manually put a file into the working copy at the location
> > of the SKIP_WORKTREE file, we need to avoid overwriting whatever edits
> > they have made and move that file to a different location first.
> >
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> > merge-ort.c | 43 +++++++++++++++++++++----------
> > t/t6428-merge-conflicts-sparse.sh | 4 +--
> > 2 files changed, 32 insertions(+), 15 deletions(-)
> >
> > diff --git a/merge-ort.c b/merge-ort.c
> > index a998f843a1da..37b69cbe0f9a 100644
> > --- a/merge-ort.c
> > +++ b/merge-ort.c
> > @@ -3235,23 +3235,27 @@ static int checkout(struct merge_options *opt,
> > return ret;
> > }
> >
> > -static int record_conflicted_index_entries(struct merge_options *opt,
> > - struct index_state *index,
> > - struct strmap *paths,
> > - struct strmap *conflicted)
> > +static int record_conflicted_index_entries(struct merge_options *opt)
> > {
> > struct hashmap_iter iter;
> > struct strmap_entry *e;
> > + struct index_state *index = opt->repo->index;
> > + struct checkout state = CHECKOUT_INIT;
> > int errs = 0;
> > int original_cache_nr;
> >
> > - if (strmap_empty(conflicted))
> > + if (strmap_empty(&opt->priv->conflicted))
> > return 0;
> >
> > + /* If any entries have skip_worktree set, we'll have to check 'em out */
> > + state.force = 1;
> > + state.quiet = 1;
> > + state.refresh_cache = 1;
> > + state.istate = index;
> > original_cache_nr = index->cache_nr;
> >
> > /* Put every entry from paths into plist, then sort */
> > - strmap_for_each_entry(conflicted, &iter, e) {
> > + strmap_for_each_entry(&opt->priv->conflicted, &iter, e) {
> > const char *path = e->key;
> > struct conflict_info *ci = e->value;
> > int pos;
> > @@ -3292,9 +3296,23 @@ static int record_conflicted_index_entries(struct merge_options *opt,
> > * the higher order stages. Thus, we need override
> > * the CE_SKIP_WORKTREE bit and manually write those
> > * files to the working disk here.
> > - *
> > - * TODO: Implement this CE_SKIP_WORKTREE fixup.
> > */
> > + if (ce_skip_worktree(ce)) {
> > + struct stat st;
> > +
> > + if (!lstat(path, &st)) {
> > + char *new_name = unique_path(&opt->priv->paths,
> > + path,
> > + "cruft");
> > +
> > + path_msg(opt, path, 1,
> > + _("Note: %s not up to date and in way of checking out conflicted version; old copy renamed to %s"),
> > + path, new_name);
>
> I see this follows existing uses in merge-ort.c, but I wonder if this
> won't be quite unreadable on long paths, i.e.:
>
> <long x> renamed to <long x.new>
>
> As opposed to:
>
> We had to rename your thing:
> from: <long x>
> to: <long x.new>
Makes sense, but it seems like something we'd want to do to a lot of
messages rather than just this one. For now, especially given that I
expect this particular message to be *very* rare, I think I'll leave
this one as-is for now but we can address this idea in a subsequent
series or as #leftoverbits.
^ permalink raw reply [relevance 6%]
* Re: Regarding GSoC Project 2021
@ 2021-03-14 1:26 6% ` ZheNing Hu
0 siblings, 0 replies; 200+ results
From: ZheNing Hu @ 2021-03-14 1:26 UTC (permalink / raw)
To: Shubham Verma; +Cc: Git List, Christian Couder, Hariom verma
Hi, Shubhum Verma,
Shubham Verma <shubhunic@gmail.com> 于2021年3月14日周日 上午2:41写道：
>
> Hello Everyone,
>
> I am interested in working on the project "Use ref-filter formats in
> git cat-file" this summer as a GSoC student.
>
> But I saw ZheNing Hu already started contributing to this project. So,
> it is possible that more than one student can work on the same project
> or I have to choose another project?
>
> Otherwise, I will start working on the project "Finish convert git
> submodule script to builtin".
>
> Thank You! & Regards,
> Shubham
I haven't started sending relevant patches for `git cat-file`.
Now I'm still focused on solving some GGG issues, or
Add small options for subcommands that might be fun or useful,
And so you can still choose `git cat-file` to apply for.
But I recommend that you think about and complete a micro project
before applying for "git cat-file"or "git submodule", usually in
https://github.com/gitgitgadget/git/labels/leftoverbits or
https://github.com/gitgitgadget/git/labels/good first issue
Thanks.
--
ZheNing Hu
^ permalink raw reply [relevance 6%]
* Re: [PATCH] transport: respect verbosity when setting upstream
@ 2021-04-16 18:48 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2021-04-16 18:48 UTC (permalink / raw)
To: Øystein Walle; +Cc: Eric Sunshine, Git List
Øystein Walle <oystwa@gmail.com> writes:
> On Thu, 15 Apr 2021 at 17:29, Eric Sunshine <sunshine@sunshineco.com> wrote:
>
>> I wondered why you used `tee` here since it adds no value (as far as I
>> can tell), but I see that you copied it from the test preceding this
>> one. So... [intentionally left blank]
>
> Indeed, I wondered about that too; it seems a plain redirection will do
> the trick. But a mix of laziness and not second-guessing others' work made
> me leave it as it is.
Let's agree to mark it as #leftoverbits then?
Thanks for a fix, additional tests, and a good review.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 1/1] repack: avoid loosening promisor objects in partial clones
@ 2021-04-19 23:09 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2021-04-19 23:09 UTC (permalink / raw)
To: Rafael Silva; +Cc: git, Jeff King, Jonathan Tan, SZEDER Gábor
Rafael Silva <rafaeloliveira.cs@gmail.com> writes:
> When `git repack -A -d` is run in a partial clone, `pack-objects`
> is invoked twice: once to repack all promisor objects, and once to
> repack all non-promisor objects. The latter `pack-objects` invocation
> is with --exclude-promisor-objects and --unpack-unreachable, which
> loosens all unused objects. Unfortunately, this includes promisor
> objects.
>
> Because the -d argument to `git repack` subsequently deletes all loose
> objects also in packs, these just-loosened promisor objects will be
> immediately deleted. However, this extra disk churn is unnecessary in
> the first place. For example, a newly-clone partial repo that filters
"in a newly-cloned partial repo", I'd think.
> For testing, we need to validate whether any object was loosened.
> However, the "evidence" (loosened objects) is deleted during the
> process which prevents us from inspecting the object directory.
> Instead, let's teach `pack-objects` to count loosened objects and
> emit via trace2 thus allowing inspecting the debug events after the
> process is finished. This new event is used on the added regression
> test.
Nicely designed.
> + uint32_t loosened_objects_nr = 0;
> struct object_id oid;
>
> for (p = get_all_packs(the_repository); p; p = p->next) {
> @@ -3492,11 +3493,16 @@ static void loosen_unused_packed_objects(void)
> nth_packed_object_id(&oid, p, i);
> if (!packlist_find(&to_pack, &oid) &&
> !has_sha1_pack_kept_or_nonlocal(&oid) &&
> - !loosened_object_can_be_discarded(&oid, p->mtime))
> + !loosened_object_can_be_discarded(&oid, p->mtime)) {
> if (force_object_loose(&oid, p->mtime))
> die(_("unable to force loose object"));
> + loosened_objects_nr++;
> + }
> }
> }
> +
> + trace2_data_intmax("pack-objects", the_repository,
> + "loosen_unused_packed_objects/loosened", loosened_objects_nr);
> }
OK, so this is just the "stats".
> diff --git a/builtin/repack.c b/builtin/repack.c
> index 2847fdfbab..5f9bc74adc 100644
> --- a/builtin/repack.c
> +++ b/builtin/repack.c
> @@ -20,7 +20,7 @@ static int delta_base_offset = 1;
> static int pack_kept_objects = -1;
> static int write_bitmaps = -1;
> static int use_delta_islands;
> -static char *packdir, *packtmp;
> +static char *packdir, *packtmp_name, *packtmp;
>
> static const char *const git_repack_usage[] = {
> N_("git repack [<options>]"),
> @@ -530,7 +530,8 @@ int cmd_repack(int argc, const char **argv, const char *prefix)
> }
>
> packdir = mkpathdup("%s/pack", get_object_directory());
> - packtmp = mkpathdup("%s/.tmp-%d-pack", packdir, (int)getpid());
> + packtmp_name = xstrfmt(".tmp-%d-pack", (int)getpid());
> + packtmp = mkpathdup("%s/%s", packdir, packtmp_name);
Just a mental note, but we should move away from ".tmp-$$" that is a
remnant from the days back when this was a shell script, and use the
tempfile.h API (#leftoverbits). Such a change must not be part of
this topic, of course.
Thanks. Will queue and see what others say.
^ permalink raw reply [relevance 6%]
* Re: git-sh-prompt: bash: GIT_PS1_COMPRESSSPARSESTATE: unbound variable
@ 2021-05-20 0:09 6% ` Elijah Newren
0 siblings, 0 replies; 200+ results
From: Elijah Newren @ 2021-05-20 0:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christoph Anton Mitterer, Git Mailing List, ville.skytta
On Wed, May 19, 2021 at 4:29 PM Junio C Hamano <gitster@pobox.com> wrote:
>
> Christoph Anton Mitterer <calestyo@scientia.net> writes:
>
> > Hey there.
> >
> > I think I found another case of an unbound variable:
> >
> > Completing e.g.:
> > git commit --[press TAB]
> >
> > gives:
> > $ git commit --bash: GIT_COMPLETION_SHOW_ALL: unbound variable
That particular case was fixed by Ville Skyttä in commit c5c0548d793e
(completion: audit and guard $GIT_* against unset use, 2021-04-08).
> It seems that OMIT_SPARSESTATE would have the same issue.
>
> if [ -z "${GIT_PS1_COMPRESSSPARSESTATE}" ] &&
> [ -z "${GIT_PS1_OMITSPARSESTATE}" ] &&
>
> all coming from afda36db (git-prompt: include sparsity state as
> well, 2020-06-21).
>
> But I think we have already seen the fix in 5c0cbdb1 (git-prompt:
> work under set -u, 2021-05-13), which may or may not appear in the
> upcoming release.
Yeah, I fixed the ones I introduced in git-prompt.sh --
GIT_PS1_COMPRESSSPARSESTATE and GIT_PS1_OMITSPARSESTATE.
> There still are unprotected mentions of GIT_PS1_SHOWUPSTREAM even
> with that fix, though.
Yeah, neither my fix (which was only trying to fix the problems I
introduced in git-prompt.sh) nor Ville's fix (which was focused on
git-completion.bash) caught that one.
Do you want to make a patch for that, Christoph? If not, #leftoverbits?
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 04/24] Documentation: build 'technical/bitmap-format' by default
@ 2021-07-26 18:49 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2021-07-26 18:49 UTC (permalink / raw)
To: Jeff King; +Cc: git, dstolee, gitster, jonathantanmy
On Fri, Jul 23, 2021 at 03:39:25AM -0400, Jeff King wrote:
> The question here is: should we continue to omit it from the html build,
> since it does not render well (i.e., should we simply drop this patch).
I think that's a nice way of putting it. Since the HTML rendering is
terrible, let's just drop this patch and leave cleaning it up as
#leftoverbits.
Thanks,
Taylor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] Provide config option to expect files outside sparse patterns
@ 2022-02-22 12:11 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2022-02-22 12:11 UTC (permalink / raw)
To: Elijah Newren
Cc: Elijah Newren via GitGitGadget, Git Mailing List, Jonathan Nieder,
Jonathan Tan, Jose Lopes, Jeff Hostetler
Hi Elijah,
On Mon, 21 Feb 2022, Elijah Newren wrote:
> On Mon, Feb 21, 2022 at 12:34 PM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > In addition to Stolee's feedback...
> >
> > On Sun, 20 Feb 2022, Elijah Newren via GitGitGadget wrote:
> >
> > > diff --git a/config.c b/config.c
> > > index 2bffa8d4a01..68e877a1d80 100644
> > > --- a/config.c
> > > +++ b/config.c
> > > @@ -1520,6 +1520,11 @@ static int git_default_core_config(const char *var, const char *value, void *cb)
> > > return 0;
> > > }
> > >
> > > + if (!strcmp(var, "core.expectfilesoutsidesparsepatterns")) {
> > > + core_expect_files_outside_sparse_patterns = git_config_bool(var, value);
> > > + return 0;
> > > + }
> >
> > The `core` section is already quite crowded (for which I am partially
> > responsible, of course).
> >
> > Maybe it would be a good idea to introduce the `sparse` section, using
> > `sparse.allowFilesMatchingPatterns` or `sparse.applyPatternsToWorktree =
> > false`?
>
> That's a fair point. At one point Stolee wanted to change from
> core.sparse* to sparse.* -- but by that point we already had users and
> would have had to deal with a bit of a migration story (and wondering
> what to do if people had both old and new config variables set
> inconsistently).
Right, migration is always hard.
And it's outside of the scope of this here patch series, of course.
> I'm not sure if it's optimal to try to keep the sparse settings
> together (thus put new ones under core), or try to avoid filling core.
> I guess if we moved towards sparse.* now, it might be an easier
> migration story if we only have two options to move. And besides,
> we're already split between multiple sections with
> extensions.worktreeConfig, core.sparseCheckout{,Cone}, and
> index.sparse already...so maybe adding one more section would be par
> for the course. ;-)
FWIW as a potential #leftoverbits, we could migrate those to `sparse.*`
where `sparse.*` would take precendence over `core.sparse*` and the usual
deprecation notice would be shown via the `advice` mechanism.
> So, I'm leaning towards sparse.expectFilesOutsideOfPatterns, but I'd
> like to hear Stolee's thoughts too.
Indeed, his opinion weighs more than mine on this matter.
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* Re: When rebase.autoStash=true is used, 'git pull' merge process still complains when incoming changes are in a different place of the file than local changes
@ 2022-02-23 21:23 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-02-23 21:23 UTC (permalink / raw)
To: Phillip Wood; +Cc: Yuri, Git Mailing List
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 17/02/2022 20:50, Yuri wrote:
>> I have a file "x" that has one local change and some incoming pulled
>> changes.
>> Pulled changes are contextually very far away, so it should be
>> possible to merge them without user interaction.
>> But git still complains:
>> $ git pull
>> Updating 91bfe02..522ccf2
>> error: Your local changes to the following files would be
>> overwritten by merge:
>> x
>
> pull only uses rebase.autoStash if you ask it to rebase, if it is
> trying to merge then you need to pass --autostash on the command line
> or set merge.autoStash (assuming you want merge to always use
> --autostash).
I wonder if it would make a good #leftoverbit starter project to
introduce pull.autoStash so that those who want autostash only when
running "git pull" (but not "git merge" or "git rebase") can set it,
ignoring the settings of merge/rebase.autoStash variables.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 1/3] t7519: avoid file to index mtime race for untracked cache
@ 2022-02-25 19:07 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-02-25 19:07 UTC (permalink / raw)
To: Tao Klerks via GitGitGadget; +Cc: git, Tao Klerks
"Tao Klerks via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Tao Klerks <tao@klerks.biz>
>
> In t7519 there is a test that writes files to disk, and immediately
> writes the untracked index. Because of mtime-comparison logic that
"untracked cache", I think.
> uses a 1-second resolution, this means the cached entries are not
> trusted/used under some circumstances
> (see read-cache.c#is_racy_stat()).
>
> Untracked cache tests in t7063 use a 1-second delay to avoid this
> issue, but we don't want to introduce arbitrary slowdowns, so instead
> use test-tool chmtime to backdate the files slightly.
Good approach. Perhaps fixing 7063 can be marked as #leftoverbit?
> This change doesn't actually affect the outcome of the test, but does
> enhance its validity, and becomes relevant after later changes.
>
> Signed-off-by: Tao Klerks <tao@klerks.biz>
> ---
> t/t7519-status-fsmonitor.sh | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/t/t7519-status-fsmonitor.sh b/t/t7519-status-fsmonitor.sh
> index a6308acf006..3f984136ea9 100755
> --- a/t/t7519-status-fsmonitor.sh
> +++ b/t/t7519-status-fsmonitor.sh
> @@ -324,13 +324,19 @@ test_expect_success UNTRACKED_CACHE 'ignore .git changes when invalidating UNTR'
> cd dot-git &&
> mkdir -p .git/hooks &&
> : >tracked &&
> + test-tool chmtime =-60 tracked &&
> : >modified &&
> + test-tool chmtime =-60 modified &&
> mkdir dir1 &&
> : >dir1/tracked &&
> + test-tool chmtime =-60 dir1/tracked &&
> : >dir1/modified &&
> + test-tool chmtime =-60 dir1/modified &&
> mkdir dir2 &&
> : >dir2/tracked &&
> + test-tool chmtime =-60 dir2/tracked &&
> : >dir2/modified &&
> + test-tool chmtime =-60 dir2/modified &&
> write_integration_script &&
> git config core.fsmonitor .git/hooks/fsmonitor-test &&
> git update-index --untracked-cache &&
^ permalink raw reply [relevance 6%]
* Re: [PATCH 1/3] checkout: document bug where delayed checkout counts entries twice
@ 2022-07-13 17:57 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-07-13 17:57 UTC (permalink / raw)
To: Matheus Tavares; +Cc: git
Matheus Tavares <matheus.bernardino@usp.br> writes:
> At the end of a `git checkout <pathspec>` operation, git reports how
> many paths were checked out with a message like "Updated N paths from
> the index". However, entries that end up on the delayed checkout queue
> (as requested by a long-running process filter) get counted twice,
> producing a wrong number in the final report. We will fix this bug in an
> upcoming commit. For now, only document/demonstrate it with a
> test_expect_failure.
>
> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>
> ---
> t/t0021-conversion.sh | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
> index bad37abad2..00df9b5c18 100755
> --- a/t/t0021-conversion.sh
> +++ b/t/t0021-conversion.sh
> @@ -1132,4 +1132,26 @@ do
> '
> done
>
> +test_expect_failure PERL 'delayed checkout correctly reports the number of updated entries' '
It is unfortunate that we depend on Perl only to run rot13-filter;
I'll leave a #leftoverbit label here to remind us to write a
"test-tool rot13-filter" someday. No need to do so in this series.
> + rm -rf repo &&
> + git init repo &&
> + (
> + cd repo &&
> + git config filter.delay.process "../rot13-filter.pl delayed.log clean smudge delay" &&
> + git config filter.delay.required true &&
> +
> + echo "*.a filter=delay" >.gitattributes &&
> + echo a >test-delay10.a &&
> + echo a >test-delay11.a &&
> + git add . &&
> + git commit -m files &&
> +
> + rm *.a &&
> + git checkout . 2>err &&
> + grep "IN: smudge test-delay10.a .* \\[DELAYED\\]" delayed.log &&
> + grep "IN: smudge test-delay11.a .* \\[DELAYED\\]" delayed.log &&
> + grep "Updated 2 paths from the index" err
> + )
> +'
> +
> test_done
^ permalink raw reply [relevance 6%]
* Re: [PATCH v4 12/12] sequencer: notify user of --update-refs activity
@ 2022-07-19 16:09 6% ` Derrick Stolee
0 siblings, 0 replies; 200+ results
From: Derrick Stolee @ 2022-07-19 16:09 UTC (permalink / raw)
To: Elijah Newren, Derrick Stolee via GitGitGadget
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin,
Taylor Blau, Jeff Hostetler, Phillip Wood
On 7/16/2022 6:09 PM, Elijah Newren wrote:
> On Tue, Jul 12, 2022 at 6:07 AM Derrick Stolee via GitGitGadget
> <gitgitgadget@gmail.com> wrote:
>>
>> From: Derrick Stolee <derrickstolee@github.com>
>>
>> When the user runs 'git rebase -i --update-refs', the end message still
>> says only
>>
>> Successfully rebased and updated <HEAD-ref>.
>>
>> Update the sequencer to collect the successful (and unsuccessful) ref
>> updates due to the --update-refs option, so the end message now says
>>
>> Successfully rebased and updated <HEAD-ref>.
>> Updated the following refs with --update-refs:
>> refs/heads/first
>> refs/heads/third
>
> This seems good.
>
>> Failed to update the following refs with --update-refs:
>> refs/heads/second
>
> This is good, but I think it could be improved. Could we also include
> the commit to which rebase would have updated the branch to? That
> would allow the user to manually update it if they want, or at least
> see a range-diff between what we would have updated it to and what it
> now has. Without that information, the user might have difficulty
> correcting that branch.
Would you mind if I left this as something for #leftoverbits? I
expect that a follow-up series will be necessary once we have more
user feedback. This isn't the only item delayed until after more
feedback.
Thanks,
-Stolee
^ permalink raw reply [relevance 6%]
* Re: [PATCH] mingw: include the Python parts in the build
@ 2022-08-10 9:29 6% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2022-08-10 9:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin via GitGitGadget, git
Hi Hannes,
On Fri, 29 Jul 2022, Johannes Sixt wrote:
> Am 29.07.22 um 16:29 schrieb Johannes Schindelin:
> > Now, I vaguely remember that j6t said that they switched to MSYS2 some
> > time ago, but all I found on the Git mailing list was
> > https://lore.kernel.org/git/6c2bbca7-7a8f-d3d8-04b6-31494a3e1b43@kdbg.org/
> > which says that in 2017, MSys1 was still used by the person who apart from
> > myself did the most crucial work to support Git on Windows (and that
> > counts a lot in my book, so in this instance I am willing to bear a bit
> > more maintenance burden than I otherwise would for a single person, even
> > if the Windows-specific part of `config.mak.uname` is quite messy, I
> > admit).
> >
> > Hannes, do you still build with MSys1?
>
> Thank you for keeping me in the loop. No, I have long since switched to
> the Git for Windows tool set, i.e., MSYS2 + MinGW64. I don't know if
> anybody is still using MSys1 + MinGW. There's likely no reason to keep
> the MSys1 config section.
Excellent. I've added a #leftoverbits ticket here:
https://github.com/gitgitgadget/git/issues/1319
Ciao,
Dscho
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 1/3] maintenance: add 'unregister --force'
@ 2022-09-26 20:49 6% ` Derrick Stolee
0 siblings, 0 replies; 200+ results
From: Derrick Stolee @ 2022-09-26 20:49 UTC (permalink / raw)
To: Junio C Hamano, Derrick Stolee via GitGitGadget
Cc: git, vdye, SZEDER Gábor,
Ævar Arnfjörð Bjarmason
On 9/26/2022 3:23 PM, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> @@ -11,7 +11,7 @@ SYNOPSIS
>> [verse]
>> 'git maintenance' run [<options>]
>> 'git maintenance' start [--scheduler=<scheduler>]
>> -'git maintenance' (stop|register|unregister)
>> +'git maintenance' (stop|register|unregister) [<options>]
>
> An unrelated tangent, but should register complain when given in a
> repository that is already registered as well? Just being curious.
Let's leave that as a #leftoverbits and perhaps as something to
consider next to something like 'git maintenance list' to list the
currently-registered repositories.
Thanks,
-Stolee
^ permalink raw reply [relevance 6%]
* Re: [PATCH] builtin/gc.c: fix use-after-free in maintenance_unregister()
@ 2022-11-16 15:14 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2022-11-16 15:14 UTC (permalink / raw)
To: Derrick Stolee; +Cc: Taylor Blau, git, Johannes Schindelin, Ronan Pigott
On Wed, Nov 16 2022, Derrick Stolee wrote:
> On 11/15/22 2:54 PM, Taylor Blau wrote:
>> On Tue, Nov 15, 2022 at 08:41:44PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>>> @@ -1543,6 +1543,7 @@ static int maintenance_unregister(int argc, const char **argv, const char *prefi
>>>> int found = 0;
>>>> struct string_list_item *item;
>>>> const struct string_list *list;
>>>> + struct config_set cs = { { 0 } };
>>>
>>> Just "{ 0 }" here instead? I see it may have been copied from some older
>>> pre-image though, and they'll do the same in either case, so it's not
>>> important...
>>
>> Copying from other zero-initializations of `struct config_set`:
>>
>> $ git grep -oh 'struct config_set.*= {.*' | sort | uniq -c
>> 3 struct config_set cs = { { 0 } };
>
> Yes, without the double braces the compiler will complain on
> macOS, I believe.
Ah, that was sorted in 54795d37d9e (config.mak.dev: disable suggest
braces error on old clang versions, 2022-10-10).
It's fine here, we can follow-up for the #leftoverbits of changing those
some other time.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2] send-email: relay '-v N' to format-patch
@ 2022-11-28 12:34 6% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2022-11-28 12:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kyle Meyer, git
On Sun, Nov 27 2022, Junio C Hamano wrote:
> Kyle Meyer <kyle@kyleam.com> writes:
>
>> Here's a patch handling the -v case. I don't plan on working on a more
>> complete fix for the other cases (as I mentioned before, I don't use
>> send-email to drive format-patch), but in my opinion the -v fix by
>> itself is still valuable.
>
> Yup, I think it is a good place to stop for the first patch. Other
> people can add more when they discover the need, and anything more
> complex [*] is probably not worth the effort, I would think.
>
> Side note: [*] we could imagine running "git format-patch -h"
> (or a new variant of it), parse its output and populate the
> %options dynamically, for example.
>
> Will queue. Thanks.
This is just a comment on the #leftoverbits: I've looked at this option
parsing in "git-send-email" before, and IMO the right long-term fix is
to split out the *.perl code into a "git send-email--helper", and do the
option parsing in C using our parse_options().
Some of it will be a bit of a hassle, but it should be much easier after
8de2e2e41b2 (Merge branch 'ab/send-email-optim', 2021-07-22) (and the
subsquent regression fix).
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 3/7] rebase: remove --allow-empty-message from incompatible opts
@ 2023-01-21 15:09 6% ` Phillip Wood
0 siblings, 0 replies; 200+ results
From: Phillip Wood @ 2023-01-21 15:09 UTC (permalink / raw)
To: Elijah Newren via GitGitGadget, git
Cc: Derrick Stolee, Elijah Newren, Eric Sunshine, Martin Ågren,
Phillip Wood
Hi Elijah
On 21/01/2023 01:55, Elijah Newren via GitGitGadget wrote:
> From: Elijah Newren <newren@gmail.com>
>
> --allow-empty-message was turned into a no-op and even documented
> as such; the flag is simply ignored. Since the flag is ignored, it
> shouldn't be documented as being incompatible with other flags.
The patch looks fine. Just to note that
#leftoverbits - I notice there is some code in builtin/rebase.c,
builtin/revert.c and sequencer.[ch] related to this option that could be
removed. The setting seems to be completely ignored by the sequencer and
so could be removed from struct replay_opts.
Best Wishes
Phillip
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
> Documentation/git-rebase.txt | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 00d21d7287d..3929535c0cd 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -640,7 +640,6 @@ are incompatible with the following options:
> * --merge
> * --strategy
> * --strategy-option
> - * --allow-empty-message
> * --[no-]autosquash
> * --rebase-merges
> * --interactive
^ permalink raw reply [relevance 6%]
* Re: [PATCH] cache-tree: fix strbuf growth in prime_cache_tree_rec()
@ 2023-02-11 2:15 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2023-02-11 2:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: René Scharfe, Ævar Arnfjörð Bjarmason,
Git List, Victoria Dye
On Fri, Feb 10, 2023 at 12:33:00PM -0800, Junio C Hamano wrote:
> > strbuf_setlen() truncates the string to the directory name. strbuf_grow() then
> > makes enough room to add that directory name again (that's what I mean with
> > "double") plus the entry path. We don't add the directory name a second time,
> > so we don't need to make room for it.
>
> Yeah, I think I made the same mistake number of years ago, thinking
> that strbuf_grow() was to grow the buffer to the given size, but in
> reality it is to grow the buffer by the given size, which felt a bit
> unnatural, at least to me. I do not feel it too strongly but we
> might want to rename _grow() to _grow_by() and make _grow() call it
> while giving deprecation warning X-<.
Having been confused by that myself, I would be happy to see such a
name change.
> There are ~45 calls to strbuf_grow() in C files other than strbuf.c;
> I suspect probably a half or more of them can and should be removed
> to reduce the resulting code size without hurting anything.
My gut feeling is that your suspicion is giving strbuf_grow() users too
much credit. ;) And having looked at the first 7 grep hits, every single
one of them seemed pointless to me.
I wonder if these would make a good #leftoverbits / micro-project
candidate.
-Peff
^ permalink raw reply [relevance 6%]
* Re: How to find places where I can contribute?
@ 2023-02-20 21:31 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2023-02-20 21:31 UTC (permalink / raw)
To: Christian Couder; +Cc: Divyanshu Agrawal, git@vger.kernel.org
Christian Couder <christian.couder@gmail.com> writes:
>> 1. What is the equivalent for the Git project? How can I find issues/features
>> that I can work on?
>>
>> 2. Is there a way I can find bugs/issues that are likely easy for a new
>> contributor to pick up? Similar to a "good-first-issue" label on GitHub?
>
> We have the following documentation:
>
> https://git.github.io/General-Microproject-Information/
>
> There is also the microproject idea page from last year's GSoC:
>
> https://git.github.io/SoC-2022-Microprojects/
While these are good for GSoC applicants before they do a real
project, I didn't read the "where I can contribute?" as such---it
asks for something more real, not a toy "dip my toes" practice.
Perhaps looking for #leftoverbits in the list archive may be another
approach that would give readers a problem with real upsides?
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 06/15] builtin/for-each-ref.c: add `--exclude` option
@ 2023-05-09 20:22 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2023-05-09 20:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Derrick Stolee
On Mon, May 08, 2023 at 04:22:08PM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
> > index c01fa6fefe..449da61e11 100644
> > --- a/builtin/for-each-ref.c
> > +++ b/builtin/for-each-ref.c
> > @@ -14,6 +14,7 @@ static char const * const for_each_ref_usage[] = {
> > N_("git for-each-ref [--points-at <object>]"),
> > N_("git for-each-ref [--merged [<commit>]] [--no-merged [<commit>]]"),
> > N_("git for-each-ref [--contains [<commit>]] [--no-contains [<commit>]]"),
> > + N_("git for-each-ref [--exclude=<pattern> ...]"),
> > NULL
> > };
>
> I think the original is already wrong, but the easiest thing we can
> do in order to avoid making it worse is to drop this hunk, as the
> existing usage is this:
>
> static char const * const for_each_ref_usage[] = {
> N_("git for-each-ref [<options>] [<pattern>]"),
> N_("git for-each-ref [--points-at <object>]"),
> N_("git for-each-ref [--merged [<commit>]] [--no-merged [<commit>]]"),
> N_("git for-each-ref [--contains [<commit>]] [--no-contains [<commit>]]"),
> NULL
> };
>
> and this series merely adds a new "--exclude=<pattern>" as one of
> the "<options>".
>
> As we can see from the fact that for example
>
> $ git for-each-ref --no-merged next refs/heads/\?\?/\*
>
> works just fine, exactly the same thing can be said about the other
> --points-at/--merged/--no-merged/--contains/--no-contains options.
>
> The SYNOPSIS section of the manual page is fine.
Good point, will tweak; thanks.
> > @@ -2169,6 +2169,15 @@ static int filter_pattern_match(struct ref_filter *filter, const char *refname)
> > return match_pattern(filter, filter->name_patterns, refname);
> > }
> >
> > +static int filter_exclude_match(struct ref_filter *filter, const char *refname)
> > +{
> > + if (!filter->exclude.nr)
> > + return 0;
> > + if (filter->match_as_path)
> > + return match_name_as_path(filter, filter->exclude.v, refname);
> > + return match_pattern(filter, filter->exclude.v, refname);
> > +}
>
> Earlier I made a comment about .name_patterns member becoming
> unnecessary, but I think what should need to happen is instead
> match_pattern() and match_name_as_path() to lose the "filter"
> parameter, and take a boolean "ignore_case" instead.
Agreed.
> > +cat >expected <<\EOF
> > +refs/tags/bar
> > +refs/tags/baz
> > +refs/tags/foo/one
> > +refs/tags/testtag
> > +EOF
> > +
> > +test_expect_success 'exercise patterns with pattern exclusions' '
> > + for tag in foo/one foo/two foo/three bar baz
> > + do
> > + git tag "$tag" || return 1
> > + done &&
> > + test_when_finished "git tag -d foo/one foo/two foo/three bar baz" &&
> > + git for-each-ref --format="%(refname)" \
> > + refs/tags/ --exclude="refs/tags/foo/t*" >actual &&
> > + test_cmp expected actual
> > +'
>
> These are doing as Romans do, so I won't comment on the outdated
> pattern of preparing the expectation outside the test script. After
> the dust settles, somebody needs to go in and clean it up.
Yeah, I figured that this series was already getting pretty long, but
that it would be expedient to propagate forward this pattern. But it
should be cleaned up. Let's tag it with #leftoverbits accordingly.
Thanks,
Taylor
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 05/10] parse-options: prefer opt->value to globals in callbacks
@ 2023-09-02 7:34 6% ` René Scharfe
0 siblings, 0 replies; 200+ results
From: René Scharfe @ 2023-09-02 7:34 UTC (permalink / raw)
To: Jeff King, git; +Cc: Junio C Hamano
Am 31.08.23 um 23:21 schrieb Jeff King:
> We have several parse-options callbacks that ignore their "opt"
> parameters entirely. This is a little unusual, as we'd normally put the
> result of the parsing into opt->value. In the case of these callbacks,
> though, they directly manipulate global variables instead (and in
> most cases the caller sets opt->value to NULL in the OPT_CALLBACK
> declaration).
>
> The immediate symptom we'd like to deal with is that the unused "opt"
> variables trigger -Wunused-parameter. But how to fix that is debatable.
> One option is to annotate them with UNUSED. But another is to have the
> caller pass in the appropriate variable via opt->value, and use it. That
> has the benefit of making the callbacks reusable (in theory at least),
> and makes it clear from the OPT_CALLBACK declaration which variables
> will be affected (doubly so for the cases in builtin/fast-export.c,
> where we do set opt->value, but it is completely ignored!).
Which allows turning global variables into local ones later, so unlocks
more cleanup potential.
> The slight downside is that we lose type safety, since they're now
> passing through void pointers.
>
> I went with the "just use them" approach here. The loss of type safety
> is unfortunate, but that is already an issue with most of the other
> callbacks. If we want to try to address that, we should do so more
> consistently (and this patch would prepare these callbacks for whatever
> we choose to do there).
Makes sense. The types used below look OK to me.
> Note that in the cases in builtin/fast-export.c, we are passing
> anonymous enums. We'll have to give them names so that we can declare
> the appropriate pointer type within the callbacks.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> builtin/checkout-index.c | 8 +++++---
> builtin/describe.c | 6 ++++--
> builtin/fast-export.c | 36 +++++++++++++++++++++---------------
> builtin/fetch.c | 4 ++--
> builtin/interpret-trailers.c | 12 ++++++------
> builtin/pack-objects.c | 21 ++++++++++++---------
> 6 files changed, 50 insertions(+), 37 deletions(-)
>
> diff --git a/builtin/checkout-index.c b/builtin/checkout-index.c
> index 6687a495ff..6ef6ac4c2e 100644
> --- a/builtin/checkout-index.c
> +++ b/builtin/checkout-index.c
> @@ -193,14 +193,16 @@ static const char * const builtin_checkout_index_usage[] = {
> static int option_parse_stage(const struct option *opt,
> const char *arg, int unset)
> {
> + int *stage = opt->value;
> +
> BUG_ON_OPT_NEG(unset);
>
> if (!strcmp(arg, "all")) {
> - checkout_stage = CHECKOUT_ALL;
> + *stage = CHECKOUT_ALL;
> } else {
> int ch = arg[0];
> if ('1' <= ch && ch <= '3')
> - checkout_stage = arg[0] - '0';
> + *stage = arg[0] - '0';
> else
> die(_("stage should be between 1 and 3 or all"));
> }
> @@ -238,7 +240,7 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
> N_("write the content to temporary files")),
> OPT_STRING(0, "prefix", &state.base_dir, N_("string"),
> N_("when creating files, prepend <string>")),
> - OPT_CALLBACK_F(0, "stage", NULL, "(1|2|3|all)",
> + OPT_CALLBACK_F(0, "stage", &checkout_stage, "(1|2|3|all)",
> N_("copy out the files from named stage"),
> PARSE_OPT_NONEG, option_parse_stage),
> OPT_END()
> diff --git a/builtin/describe.c b/builtin/describe.c
> index b28a4a1f82..718b5c3073 100644
> --- a/builtin/describe.c
> +++ b/builtin/describe.c
> @@ -561,9 +561,11 @@ static void describe(const char *arg, int last_one)
> static int option_parse_exact_match(const struct option *opt, const char *arg,
> int unset)
> {
> + int *val = opt->value;
> +
> BUG_ON_OPT_ARG(arg);
>
> - max_candidates = unset ? DEFAULT_CANDIDATES : 0;
> + *val = unset ? DEFAULT_CANDIDATES : 0;
> return 0;
> }
>
> @@ -578,7 +580,7 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
> OPT_BOOL(0, "long", &longformat, N_("always use long format")),
> OPT_BOOL(0, "first-parent", &first_parent, N_("only follow first parent")),
> OPT__ABBREV(&abbrev),
> - OPT_CALLBACK_F(0, "exact-match", NULL, NULL,
> + OPT_CALLBACK_F(0, "exact-match", &max_candidates, NULL,
> N_("only output exact matches"),
> PARSE_OPT_NOARG, option_parse_exact_match),
> OPT_INTEGER(0, "candidates", &max_candidates,
> diff --git a/builtin/fast-export.c b/builtin/fast-export.c
> index 56dc69fac1..70aff515ac 100644
> --- a/builtin/fast-export.c
> +++ b/builtin/fast-export.c
> @@ -33,9 +33,9 @@ static const char *fast_export_usage[] = {
> };
>
> static int progress;
> -static enum { SIGNED_TAG_ABORT, VERBATIM, WARN, WARN_STRIP, STRIP } signed_tag_mode = SIGNED_TAG_ABORT;
> -static enum { TAG_FILTERING_ABORT, DROP, REWRITE } tag_of_filtered_mode = TAG_FILTERING_ABORT;
> -static enum { REENCODE_ABORT, REENCODE_YES, REENCODE_NO } reencode_mode = REENCODE_ABORT;
> +static enum signed_tag_mode { SIGNED_TAG_ABORT, VERBATIM, WARN, WARN_STRIP, STRIP } signed_tag_mode = SIGNED_TAG_ABORT;
> +static enum tag_of_filtered_mode { TAG_FILTERING_ABORT, DROP, REWRITE } tag_of_filtered_mode = TAG_FILTERING_ABORT;
> +static enum reencode_mode { REENCODE_ABORT, REENCODE_YES, REENCODE_NO } reencode_mode = REENCODE_ABORT;
> static int fake_missing_tagger;
> static int use_done_feature;
> static int no_data;
> @@ -53,16 +53,18 @@ static struct revision_sources revision_sources;
> static int parse_opt_signed_tag_mode(const struct option *opt,
> const char *arg, int unset)
> {
> + enum signed_tag_mode *val = opt->value;
> +
> if (unset || !strcmp(arg, "abort"))
> - signed_tag_mode = SIGNED_TAG_ABORT;
> + *val = SIGNED_TAG_ABORT;
> else if (!strcmp(arg, "verbatim") || !strcmp(arg, "ignore"))
> - signed_tag_mode = VERBATIM;
> + *val = VERBATIM;
> else if (!strcmp(arg, "warn"))
> - signed_tag_mode = WARN;
> + *val = WARN;
> else if (!strcmp(arg, "warn-strip"))
> - signed_tag_mode = WARN_STRIP;
> + *val = WARN_STRIP;
> else if (!strcmp(arg, "strip"))
> - signed_tag_mode = STRIP;
> + *val = STRIP;
> else
> return error("Unknown signed-tags mode: %s", arg);
> return 0;
> @@ -71,12 +73,14 @@ static int parse_opt_signed_tag_mode(const struct option *opt,
> static int parse_opt_tag_of_filtered_mode(const struct option *opt,
> const char *arg, int unset)
> {
> + enum tag_of_filtered_mode *val = opt->value;
> +
> if (unset || !strcmp(arg, "abort"))
> - tag_of_filtered_mode = TAG_FILTERING_ABORT;
> + *val = TAG_FILTERING_ABORT;
> else if (!strcmp(arg, "drop"))
> - tag_of_filtered_mode = DROP;
> + *val = DROP;
> else if (!strcmp(arg, "rewrite"))
> - tag_of_filtered_mode = REWRITE;
> + *val = REWRITE;
> else
> return error("Unknown tag-of-filtered mode: %s", arg);
> return 0;
> @@ -85,21 +89,23 @@ static int parse_opt_tag_of_filtered_mode(const struct option *opt,
> static int parse_opt_reencode_mode(const struct option *opt,
> const char *arg, int unset)
> {
> + enum reencode_mode *val = opt->value;
> +
> if (unset) {
> - reencode_mode = REENCODE_ABORT;
> + *val = REENCODE_ABORT;
> return 0;
> }
>
> switch (git_parse_maybe_bool(arg)) {
> case 0:
> - reencode_mode = REENCODE_NO;
> + *val = REENCODE_NO;
> break;
> case 1:
> - reencode_mode = REENCODE_YES;
> + *val = REENCODE_YES;
> break;
> default:
> if (!strcasecmp(arg, "abort"))
> - reencode_mode = REENCODE_ABORT;
> + *val = REENCODE_ABORT;
> else
> return error("Unknown reencoding mode: %s", arg);
> }
> diff --git a/builtin/fetch.c b/builtin/fetch.c
> index 8f93529505..fd134ba74d 100644
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -176,7 +176,7 @@ static int parse_refmap_arg(const struct option *opt, const char *arg, int unset
> * "git fetch --refmap='' origin foo"
> * can be used to tell the command not to store anywhere
> */
> - refspec_append(&refmap, arg);
> + refspec_append(opt->value, arg);
>
> return 0;
> }
> @@ -2204,7 +2204,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
> PARSE_OPT_HIDDEN, option_fetch_parse_recurse_submodules),
> OPT_BOOL(0, "update-shallow", &update_shallow,
> N_("accept refs that update .git/shallow")),
> - OPT_CALLBACK_F(0, "refmap", NULL, N_("refmap"),
> + OPT_CALLBACK_F(0, "refmap", &refmap, N_("refmap"),
> N_("specify fetch refmap"), PARSE_OPT_NONEG, parse_refmap_arg),
> OPT_STRING_LIST('o', "server-option", &server_options, N_("server-specific"), N_("option to transmit")),
> OPT_IPVERSION(&family),
> diff --git a/builtin/interpret-trailers.c b/builtin/interpret-trailers.c
> index c5e8345265..6aadce6a1e 100644
> --- a/builtin/interpret-trailers.c
> +++ b/builtin/interpret-trailers.c
> @@ -26,19 +26,19 @@ static enum trailer_if_missing if_missing;
> static int option_parse_where(const struct option *opt,
> const char *arg, int unset)
> {
> - return trailer_set_where(&where, arg);
> + return trailer_set_where(opt->value, arg);
> }
>
> static int option_parse_if_exists(const struct option *opt,
> const char *arg, int unset)
> {
> - return trailer_set_if_exists(&if_exists, arg);
> + return trailer_set_if_exists(opt->value, arg);
> }
>
> static int option_parse_if_missing(const struct option *opt,
> const char *arg, int unset)
> {
> - return trailer_set_if_missing(&if_missing, arg);
> + return trailer_set_if_missing(opt->value, arg);
> }
Not your fault, but these all silently exit if "arg" contains an
unrecognized value. Reporting the error would be better.
> static void new_trailers_clear(struct list_head *trailers)
> @@ -97,11 +97,11 @@ int cmd_interpret_trailers(int argc, const char **argv, const char *prefix)
> OPT_BOOL(0, "in-place", &opts.in_place, N_("edit files in place")),
> OPT_BOOL(0, "trim-empty", &opts.trim_empty, N_("trim empty trailers")),
>
> - OPT_CALLBACK(0, "where", NULL, N_("action"),
> + OPT_CALLBACK(0, "where", &where, N_("action"),
> N_("where to place the new trailer"), option_parse_where),
> - OPT_CALLBACK(0, "if-exists", NULL, N_("action"),
> + OPT_CALLBACK(0, "if-exists", &if_exists, N_("action"),
> N_("action if trailer already exists"), option_parse_if_exists),
> - OPT_CALLBACK(0, "if-missing", NULL, N_("action"),
> + OPT_CALLBACK(0, "if-missing", &if_missing, N_("action"),
> N_("action if trailer is missing"), option_parse_if_missing),
And I wonder if "action" should be replaced by "(after|before|end|start)",
"(addIfDifferent|addIfDifferentNeighbor|add|replace|doNothing)" and
"(doNothing|add)", respectively. Gets a bit long in the middle, but would
be more helpful. #leftoverbits
> OPT_BOOL(0, "only-trailers", &opts.only_trailers, N_("output only the trailers")),
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index d2a162d528..492372ee5d 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -4120,29 +4120,32 @@ static void add_extra_kept_packs(const struct string_list *names)
> static int option_parse_quiet(const struct option *opt, const char *arg,
> int unset)
> {
> + int *val = opt->value;
> +
> BUG_ON_OPT_ARG(arg);
>
> if (!unset)
> - progress = 0;
> - else if (!progress)
> - progress = 1;
> + *val = 0;
> + else if (!*val)
> + *val = 1;
> return 0;
> }
>
> static int option_parse_index_version(const struct option *opt,
> const char *arg, int unset)
> {
> + struct pack_idx_option *popts = opt->value;
> char *c;
> const char *val = arg;
>
> BUG_ON_OPT_NEG(unset);
>
> - pack_idx_opts.version = strtoul(val, &c, 10);
> - if (pack_idx_opts.version > 2)
> + popts->version = strtoul(val, &c, 10);
> + if (popts->version > 2)
> die(_("unsupported index version %s"), val);
> if (*c == ',' && c[1])
> - pack_idx_opts.off32_limit = strtoul(c+1, &c, 0);
> - if (*c || pack_idx_opts.off32_limit & 0x80000000)
> + popts->off32_limit = strtoul(c+1, &c, 0);
> + if (*c || popts->off32_limit & 0x80000000)
> die(_("bad index version '%s'"), val);
> return 0;
> }
> @@ -4190,7 +4193,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> LIST_OBJECTS_FILTER_INIT;
>
> struct option pack_objects_options[] = {
> - OPT_CALLBACK_F('q', "quiet", NULL, NULL,
> + OPT_CALLBACK_F('q', "quiet", &progress, NULL,
> N_("do not show progress meter"),
> PARSE_OPT_NOARG, option_parse_quiet),
> OPT_SET_INT(0, "progress", &progress,
> @@ -4200,7 +4203,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> OPT_BOOL(0, "all-progress-implied",
> &all_progress_implied,
> N_("similar to --all-progress when progress meter is shown")),
> - OPT_CALLBACK_F(0, "index-version", NULL, N_("<version>[,<offset>]"),
> + OPT_CALLBACK_F(0, "index-version", &pack_idx_opts, N_("<version>[,<offset>]"),
> N_("write the pack index file in the specified idx format version"),
> PARSE_OPT_NONEG, option_parse_index_version),
> OPT_MAGNITUDE(0, "max-pack-size", &pack_size_limit,
^ permalink raw reply [relevance 6%]
* Re: [PATCH] diff --stat: add config option to limit filename width
@ 2023-09-12 17:11 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2023-09-12 17:11 UTC (permalink / raw)
To: Dragan Simic; +Cc: git
Dragan Simic <dsimic@manjaro.org> writes:
>> Someday, as a follow-up after the dust from this topic settles, we
>> would probably want to look at how these rev.diffopt.* members are
>> initialized and refactor the common code out to a helper. It would
>> allow us to instead of doing this ...
>
> Another good point. If you agree, I'd prefer to have my patch
> accepted and merged as-is, ...
That is exactly what I meant by "follow-up after the dust settles".
All of the "we should probably do this and that in the future" are
called #leftoverbits comments. Food for thought, something people
can use to find inspiration for areas they may want to work on, that
has no impact to how "complete" the current patch being discussed
is.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 08/10] commit-graph: free write-context entries before overwriting
@ 2023-10-05 17:51 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2023-10-05 17:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
On Tue, Oct 03, 2023 at 04:30:55PM -0400, Jeff King wrote:
> diff --git a/commit-graph.c b/commit-graph.c
> index 4aa2f294f1..744b7eb1a3 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -2065,9 +2065,11 @@ static int write_commit_graph_file(struct write_commit_graph_context *ctx)
> free(graph_name);
> }
>
> + free(ctx->commit_graph_hash_after[ctx->num_commit_graphs_after - 1]);
> ctx->commit_graph_hash_after[ctx->num_commit_graphs_after - 1] = xstrdup(hash_to_hex(file_hash));
> final_graph_name = get_split_graph_filename(ctx->odb,
> ctx->commit_graph_hash_after[ctx->num_commit_graphs_after - 1]);
> + free(ctx->commit_graph_filenames_after[ctx->num_commit_graphs_after - 1]);
> ctx->commit_graph_filenames_after[ctx->num_commit_graphs_after - 1] = final_graph_name;
>
> result = rename(ctx->graph_name, final_graph_name);
This hunk makes sense. It might be nice in the future to do something
like:
--- 8< ---
diff --git a/commit-graph.c b/commit-graph.c
index 5e8a3a5085..cadccbe276 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -59,7 +59,7 @@ void git_test_write_commit_graph_or_die(void)
#define GRAPH_EXTRA_EDGES_NEEDED 0x80000000
#define GRAPH_EDGE_LAST_MASK 0x7fffffff
-#define GRAPH_PARENT_NONE 0x70000000
+tdefine GRAPH_PARENT_NONE 0x70000000
#define GRAPH_LAST_EDGE 0x80000000
@@ -1033,11 +1033,11 @@ struct write_commit_graph_context {
uint64_t progress_cnt;
char *base_graph_name;
- int num_commit_graphs_before;
- int num_commit_graphs_after;
- char **commit_graph_filenames_before;
- char **commit_graph_filenames_after;
- char **commit_graph_hash_after;
+ struct {
+ size_t nr;
+ char **fname;
+ char **hash;
+ } graphs_before, graphs_after;
uint32_t new_num_commits_in_base;
struct commit_graph *new_base_graph;
--- >8 ---
...making the corresponding changes throughout the rest of the file. But
that is definitely out of scope here, and could easily be left for
another day.
#leftoverbits
Thanks,
Taylor
^ permalink raw reply related [relevance 6%]
* Re: [PATCH 06/20] commit-graph: check consistency of fanout table
@ 2023-10-11 14:45 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2023-10-11 14:45 UTC (permalink / raw)
To: Jeff King; +Cc: git
On Mon, Oct 09, 2023 at 05:04:58PM -0400, Jeff King wrote:
> We use bsearch_hash() to look up items in the oid index of a
> commit-graph. It also has a fanout table to reduce the initial range in
> which we'll search. But since the fanout comes from the on-disk file, a
> corrupted or malicious file can cause us to look outside of the
> allocated index memory.
This is all very well written and explained. The patch LGTM.
> ---
> So I actually implemented the bsearch_hash() bounds checks and wrote
> tests for midx and idx files before realizing how they handle this. ;)
> Which makes sense, because the usual outcome for a corrupted idx file is
> for it to say "non-monotonic index", which I have seen lead to user
> confusion. Arguably we should have it say something about "hey, your idx
> file seems to be corrupted, because...". But that can be its own topic.
Yeah, I definitely agree that that is out of scope here, and can be left
as #leftoverbits.
Thanks,
Taylor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] revision: parse integer arguments to --max-count, --skip, etc., more carefully
@ 2023-12-12 22:05 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2023-12-12 22:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Britton Kerin
On Tue, Dec 12, 2023 at 07:09:02AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > This all looks pretty reasonable to me.
> >
> > I couldn't help but think, though, that surely we have some helpers for
> > this already? But the closest seems to be git_parse_int(), which also
> > allows unit factors. I'm not sure if allowing "-n 1k" would be a feature
> > or a bug. ;)
>
> The change in question is meant to be a pure fix to replace a careless
> use of atoi(). I do not mind to see a separate patch to add such a
> feature later on top.
Oh, I mostly meant that I would have turned to git_parse_int() as that
already-existing helper, but it is not suitable because of the extra
unit-handling. I think your patch draws the line in the right place.
> > I wonder if there are more spots that could benefit.
>
> "git grep -e 'atoi('" would give somebody motivated a decent set of
> #microproject ideas, but many hits are not suited for strtol_i(),
> which is designed to parse an integer at the end of a string. Some
> places use atoi() immediately followed by strspn() to skip over
> digits, which means they are parsing an integer and want to continue
> reading after the integer, which is incompatible with what
> strtol_i() wants to do. They need either a separate helper or an
> updated strtol_i() that optionally allows you to parse the prefix
> and report where the integer ended, e.g., something like:
Yeah, I agree this might be a good microproject (or leftoverbits) area,
and the semantics for the helper you propose make sense to me.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH] git-p4: stop reaching into the refdb
@ 2024-01-11 21:20 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-01-11 21:20 UTC (permalink / raw)
To: Patrick Steinhardt; +Cc: git
Patrick Steinhardt <ps@pks.im> writes:
> The git-p4 tool creates a bunch of temporary branches that share a
> common prefix "refs/git-p4-tmp/". These branches get cleaned up via
> git-update-ref(1) after the import has finished. Once done, we try to
> manually remove the now supposedly-empty ".git/refs/git-p4-tmp/"
> directory.
>
> This last step can fail in case there still are any temporary branches
> around that we failed to delete because `os.rmdir()` refuses to delete a
> non-empty directory. It can thus be seen as kind of a sanity check to
> verify that we really did delete all temporary branches.
Wow, thanks for being very careful. I would just have said "there
is no need for such rmdir---what's a single empty unused directory
between friends, which will be reused later when you run 'git p4'
again?" without thinking things through.
> This is a modification in behaviour for the "files" backend because the
> empty directory does not get deleted anymore. But arguably we should not
> care about such implementation details of the ref backend anyway, and
> this should not cause any user-visible change in behaviour.
Independently, it would be sensible to improve the files backend so
that it removes a subdirectory outside the hierarchies that are
created by refs/files-backend.c:files_init_db() when it becomes
empty (#leftoverbits).
And such a change would also have triggered the error from
os.rmdir(), so this patch is doubly welcomed.
Thanks.
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
> git-p4.py | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index 0eb3bb4c47..3ea1c405e5 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -4251,7 +4251,8 @@ def run(self, args):
> if self.tempBranches != []:
> for branch in self.tempBranches:
> read_pipe(["git", "update-ref", "-d", branch])
> - os.rmdir(os.path.join(os.environ.get("GIT_DIR", ".git"), self.tempBranchLocation))
> + if len(read_pipe(["git", "for-each-ref", self.tempBranchLocation])) > 0:
> + die("There are unexpected temporary branches")
>
> # Create a symbolic ref p4/HEAD pointing to p4/<branch> to allow
> # a convenient shortcut refname "p4".
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 3/4] config: factor out global config file retrieval
@ 2024-01-19 23:04 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-01-19 23:04 UTC (permalink / raw)
To: Patrick Steinhardt
Cc: Kristoffer Haugsbakk, git, stolee, Eric Sunshine, Taylor Blau
Patrick Steinhardt <ps@pks.im> writes:
> Yeah, you're right that `git_system_config()` is bad in the same way. In
> fact I think it's worse here because we have both `git_config_system()`
> and `git_system_config()`, which has certainly confused me multiple
> times in the past. So I'd be happy to see it renamed, as well, either
> now or in a follow-up patch series.
OK, let's make a note #leftoverbits here and merge the topic down to
'next'. By the time it graduates to 'master', we may have a clean-up
patch to rename them.
Thanks, all.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 0/2] index-pack: fsck honor checks
@ 2024-02-01 16:44 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-02-01 16:44 UTC (permalink / raw)
To: John Cai; +Cc: Jonathan Tan, John Cai via GitGitGadget, git
John Cai <johncai86@gmail.com> writes:
>>> Thanks for clarifying! Would you mind providing a patch to revise the wording
>>> here to make it clearer? I would try but I feel like I might get the wording
>>> wrong.
>>
>> I think the wording there is already mostly correct, except maybe make
>> everything plural (a tree -> trees, a .gitmodules blob -> .gitmodules
>> blobs, hash of that blob -> hashes of those blobs). We might also need
>> to modify a test to show that the current code indeed handles the plural
>> situation correctly. I don't have time right now to get to this, so
>> hopefully someone could pick this up.
>
> Thanks! It sounds like we may want to tackle this as part of another patch.
Yeah, the existing documentation has been with our users for some
time, and it is not ultra urgent to fix it in that sense. I'd say
that it can even wait until JTan gets bored with what he's doing and
needs some distraction himself ;-)
As long as our collective mind remembers it as #leftoverbits it
would be sufficient.
Thanks, both.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2] prune: mark rebase autostash and orig-head as reachable
@ 2024-02-09 18:04 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-02-09 18:04 UTC (permalink / raw)
To: Phillip Wood via GitGitGadget
Cc: git, Orgad Shaneh, Eric Sunshine, Phillip Wood
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> +static void add_rebase_files(struct rev_info *revs)
> +{
> + struct strbuf buf = STRBUF_INIT;
> + size_t len;
> + const char *path[] = {
> + "rebase-apply/autostash",
> + "rebase-apply/orig-head",
> + "rebase-merge/autostash",
> + "rebase-merge/orig-head",
> + };
Yuck.
Having this table here makes the sequencer subsystem even less
maintainable than it already is. I wonder if we can at least
somehow share some of these? #leftoverbits.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2] unit-tests: do show relative file paths on non-Windows, too
@ 2024-02-13 20:48 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-02-13 20:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Phillip Wood, git, Randall S. Becker
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> + /*
>> + * The path could be relative (t/unit-tests/test-lib.c)
>> + * or full (/home/user/git/t/unit-tests/test-lib.c).
>> + * Check the slash between "t" and "unit-tests".
>> + */
>> + prefix_len = len - needle_len;
>> + if (prefix[prefix_len + 1] == '/') {
>> + /* Oh, we're not Windows */
>> + for (size_t i = 0; i < needle_len; i++)
>> + if (needle[i] == '\\')
>> + needle[i] = '/';
>
> This looks very similar to the `convert_slashes()` function that is
> defined in `compat/mingw.h`.
I lifted it from your later loop in the function, but given that
many of the things that needed on Windows came from you, it is not
surprising if you have another copy there ;-)
> It might be a good opportunity to rename that
> function and move it to `git-compat-util.h`, then use it here and once
> more below at the end of `make_relative()`.
Right. But not as part of the -rc fix. Let's leave it as
#leftoverbits.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] rebase: make warning less passive aggressive
@ 2024-02-20 17:29 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-02-20 17:29 UTC (permalink / raw)
To: Harmen Stoppels via GitGitGadget; +Cc: git, Harmen Stoppels
"Harmen Stoppels via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Harmen Stoppels <me@harmenstoppels.nl>
>
> When you run `git rebase --continue` when no rebase is in progress, git
> outputs `fatal: no rebase in progress?` which is not a question but a
> statement. This commit makes it appear as a statement.
"This commit makes it appear" -> "Make it appear" (see
SubmittingPatches).
> builtin/rebase.c | 2 +-
This change is very good, but a commit that touches code should not
touch po/ localizations in this project. They are updated to match
the code change by respective language teams.
> po/bg.po | 2 +-
> po/ca.po | 2 +-
> po/de.po | 2 +-
> po/el.po | 2 +-
> po/es.po | 2 +-
> po/fr.po | 2 +-
> po/id.po | 2 +-
> po/it.po | 2 +-
> po/ko.po | 2 +-
> po/pl.po | 2 +-
> po/pt_PT.po | 2 +-
> po/ru.po | 2 +-
> po/sv.po | 2 +-
> po/tr.po | 2 +-
> po/uk.po | 2 +-
> po/vi.po | 2 +-
> po/zh_CN.po | 2 +-
> po/zh_TW.po | 2 +-
> 19 files changed, 19 insertions(+), 19 deletions(-)
>
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index 5b086f651a6..415783c4a21 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> @@ -1254,7 +1254,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)
> die(_("options '%s' and '%s' cannot be used together"), "--root", "--fork-point");
>
> if (options.action != ACTION_NONE && !in_progress)
> - die(_("No rebase in progress?"));
> + die(_("No rebase in progress"));
>
> if (options.action == ACTION_EDIT_TODO && !is_merge(&options))
> die(_("The --edit-todo action can only be used during "
Interestingly this change does not break any test in t/ directory,
which means we have a gap in test coverage. It should not be any
part of this patch, but we may want to add a test to exercise this
codepath (#leftoverbits).
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v3 1/5] merge-tree: fail with a non-zero exit code on missing tree objects
@ 2024-02-22 17:13 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-02-22 17:13 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget
Cc: git, Patrick Steinhardt, Eric Sunshine, Johannes Schindelin
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> - parse_tree(merge_base);
> - parse_tree(side1);
> - parse_tree(side2);
> + if (parse_tree(merge_base) < 0 ||
> + parse_tree(side1) < 0 ||
> + parse_tree(side2) < 0)
> + return -1;
Obviously good.
> diff --git a/t/t4301-merge-tree-write-tree.sh b/t/t4301-merge-tree-write-tree.sh
> index 7d0fa74da74..908c9b540c8 100755
> --- a/t/t4301-merge-tree-write-tree.sh
> +++ b/t/t4301-merge-tree-write-tree.sh
> @@ -951,4 +951,15 @@ test_expect_success '--merge-base with tree OIDs' '
> test_cmp with-commits with-trees
> '
>
> +test_expect_success 'error out on missing tree objects' '
> + git init --bare missing-tree.git &&
> + git rev-list side3 >list &&
> + git rev-parse side3^: >>list &&
> + git pack-objects missing-tree.git/objects/pack/side3-tree-is-missing <list &&
> + side3=$(git rev-parse side3) &&
> + test_must_fail git --git-dir=missing-tree.git merge-tree $side3^ $side3 >actual 2>err &&
> + test_grep "Could not read $(git rev-parse $side3:)" err &&
> + test_must_be_empty actual
> +'
I very much like the way this test emulates an operation in a
repository that lack certaion objects so cleanly, and wish we
had used this pattern instead of poking at loose object files
in hundreds of existing tests (#leftoverbits obviously).
It also justifies why a silent "return -1" in the patch is
sufficient ;-)
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 01/22] doc: avoid redundant use of cat
@ 2024-03-05 22:24 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-03-05 22:24 UTC (permalink / raw)
To: Beat Bolli; +Cc: git, Beat Bolli
"Beat Bolli" <bb@drbeat.li> writes:
> The update-hook-example.txt script uses this anti-pattern twice. Call grep
> with the input file name directy. While at it, merge the two consecutive
> grep calls.
OK.
While at it, we could also place $allowed_users_file inside a pair
of double quotes, as the "test -f" before the part we are touching
is prepared to have $IFS whitespace in it (perhaps inside $GIT_DIR),
but I am OK to leave it as a #leftoverbit outside this topic.
> Signed-off-by: Beat Bolli <dev+git@drbeat.li>
> ---
> Documentation/howto/update-hook-example.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/howto/update-hook-example.txt b/Documentation/howto/update-hook-example.txt
> index 151ee84cebce..4e727deedd21 100644
> --- a/Documentation/howto/update-hook-example.txt
> +++ b/Documentation/howto/update-hook-example.txt
> @@ -100,7 +100,7 @@ info "The user is: '$username'"
>
> if test -f "$allowed_users_file"
> then
> - rc=$(cat $allowed_users_file | grep -v '^#' | grep -v '^$' |
> + rc=$(grep -Ev '^(#|$)' $allowed_users_file |
> while read heads user_patterns
> do
> # does this rule apply to us?
> @@ -138,7 +138,7 @@ info "'$groups'"
>
> if test -f "$allowed_groups_file"
> then
> - rc=$(cat $allowed_groups_file | grep -v '^#' | grep -v '^$' |
> + rc=$(grep -Ev '^(#|$)' $allowed_groups_file |
> while read heads group_patterns
> do
> # does this rule apply to us?
^ permalink raw reply [relevance 6%]
* Re: [PATCH] git: --no-lazy-fetch option
@ 2024-03-09 1:57 6% ` Linus Arver
0 siblings, 0 replies; 200+ results
From: Linus Arver @ 2024-03-09 1:57 UTC (permalink / raw)
To: Jeff King, Junio C Hamano; +Cc: git, Christian Couder
Jeff King <peff@peff.net> writes:
> On Fri, Feb 16, 2024 at 09:22:20AM -0800, Junio C Hamano wrote:
>
> [...]
>> Add documentation and note that for this variable, unlike many
>> boolean-looking environment variables, only the presence matters,
>> not what value it is set to.
>
> Yuck. IMHO depending on GIT_NO_REPLACE_OBJECTS=0 is somewhat crazy, and
> we could consider the current behavior a bug. It's probably not _that_
> big a deal either way (because I would not expect anybody to set it that
> way in the first place). But I wonder if being consistent across
> variables trumps retaining weird historical compatibility for such a
> far-fetched case. I dunno. I guess this is https://xkcd.com/1172/. :)
I totally agree with your take on this. Would such cleanup patches
(e.g., changing the behavior of GIT_NO_REPLACE_OBJECTS=0 to be "false"
instead of "true") be acceptable as #leftoverbits?
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 1/5] xdiff-interface: refactor parsing of merge.conflictstyle
@ 2024-03-14 17:19 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-03-14 17:19 UTC (permalink / raw)
To: Phillip Wood via GitGitGadget; +Cc: git, Elijah Newren, Phillip Wood
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> Factor out the code that parses of conflict style name so it can be
> reused in a later commit that wants to parse the name given on the
> command line.
>
> Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk>
> ---
> xdiff-interface.c | 29 ++++++++++++++++++-----------
> xdiff-interface.h | 1 +
> 2 files changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/xdiff-interface.c b/xdiff-interface.c
> index 3162f517434..16ed8ac4928 100644
> --- a/xdiff-interface.c
> +++ b/xdiff-interface.c
> @@ -305,6 +305,22 @@ int xdiff_compare_lines(const char *l1, long s1,
> return xdl_recmatch(l1, s1, l2, s2, flags);
> }
>
> +int parse_conflict_style_name(const char *value)
> +{
> + if (!strcmp(value, "diff3"))
> + return XDL_MERGE_DIFF3;
> + else if (!strcmp(value, "zdiff3"))
> + return XDL_MERGE_ZEALOUS_DIFF3;
> + else if (!strcmp(value, "merge"))
> + return 0;
> + /*
> + * Please update _git_checkout() in git-completion.bash when
> + * you add new merge config
> + */
> + else
> + return -1;
> +}
As these symbols are now more public, it is tempting to leave a
#leftoverbits mark to remind us to clean them up by adding
XDL_MERGE_MERGE (instead of 0) and XDL_MERGE_UNKNOWN (instead of -1)
after the dust settles. That would have made reading later patches
in the series a little less puzzling.
But within the scope of this series, the above is perfect, faithful
refactoring of the original.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v2 09/22] t/t4*: avoid redundant uses of cat
@ 2024-03-16 1:34 6% ` Taylor Blau
0 siblings, 0 replies; 200+ results
From: Taylor Blau @ 2024-03-16 1:34 UTC (permalink / raw)
To: Beat Bolli; +Cc: git, Junio C Hamano, Beat Bolli
On Fri, Mar 15, 2024 at 08:46:06PM +0100, Beat Bolli wrote:
> diff --git a/t/t4301-merge-tree-write-tree.sh b/t/t4301-merge-tree-write-tree.sh
> index 12ac43687366..578641467753 100755
> --- a/t/t4301-merge-tree-write-tree.sh
> +++ b/t/t4301-merge-tree-write-tree.sh
> @@ -313,7 +313,7 @@ test_expect_success 'rename/add handling' '
> # First, check that the bar that appears at stage 3 does not
> # correspond to an individual blob anywhere in history
> #
> - hash=$(cat out | tr "\0" "\n" | head -n 3 | grep 3.bar | cut -f 2 -d " ") &&
> + hash=$(tr "\0" "\n" <out | head -n 3 | grep 3.bar | cut -f 2 -d " ") &&
> git rev-list --objects --all >all_blobs &&
> ! grep $hash all_blobs &&
This and the two similar transformations below it look good to me. This
obviously isn't the fault of your patch (nor should it necessarily be
its aim to fix), but I wonder if it would be worthwhile to extract the
tr "\0" "\n" <out | head -n 3 | grep 3.bar | cut -f 2 -d " "
pattern into a helper function, since it's used in a few places in this
test script.
That's just a suggestion, and shouldn't hold up this patch/series. Maybe
just some #leftoverbits :-).
Thanks,
Taylor
^ permalink raw reply [relevance 6%]
* Re: [PATCH] contrib: drop hg-to-git script
@ 2024-03-23 18:49 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-03-23 18:49 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Matthew Rollings, Stelian Pop, git
Jeff King <peff@peff.net> writes:
> Anyway, the important takeaway to me is that searches are not likely to
> end up at contrib/hg-to-git, with people wondering where it went. They
> will point directly to the alternatives.
And what is most attractive is that the list of alternatives they
will see in there searches will be updated as new and better ones
appear, unlike contrib/hg-to-git/README that we would need to
conciously maintain, which we are unlikely to do.
We might want to see if there are other contrib/ ones with only
tombstone READMEs and remove them as a part of spring (in the
northern hemisphere) cleaning, #leftoverbits, citing what we
discussed in this thread as the rationale.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH] pretty: find pretty formats case-insensitively
@ 2024-03-25 18:12 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-03-25 18:12 UTC (permalink / raw)
To: Jeff King; +Cc: Brian Lyles, git
Jeff King <peff@peff.net> writes:
> The mention of "recursive" in the function we call made me what wonder
> if we'd need more normalization. And I think we do. Try this
> modification to your test:
>
> diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
> index 321e305979..be549b1d4b 100755
> --- a/t/t4205-log-pretty-formats.sh
> +++ b/t/t4205-log-pretty-formats.sh
> @@ -61,8 +61,9 @@ test_expect_success 'alias user-defined format' '
>
> test_expect_success 'alias user-defined format is matched case-insensitively' '
> git log --pretty="format:%h" >expected &&
> - git config pretty.testalias "format:%h" &&
> - git log --pretty=testAlias >actual &&
> + git config pretty.testone "format:%h" &&
> + git config pretty.testtwo testOne &&
> + git log --pretty=testTwo >actual &&
> test_cmp expected actual
> '
Very good thinking. I totally missed the short-cut to another
short-cut while reading the patch.
>> +test_expect_success 'alias user-defined format is matched case-insensitively' '
>> + git log --pretty="format:%h" >expected &&
>> + git config pretty.testalias "format:%h" &&
>> + git log --pretty=testAlias >actual &&
>> + test_cmp expected actual
>> +'
>
> Modern style would be to use "test_config" here (or just "git -c"), but
> I see the surrounding tests are too old to do so. So I'd be OK with
> matching them (but cleaning up all of the surrounding ones would be
> nice, too).
Yup. I do not mind seeing it done either way, as a preliminary
clean-up before the main fix, just a fix with more modern style
while leaving the clean-up as #leftoverbits to be done after the
dust settles.
> PS The matching rules in find_commit_format_recursive() seem weird
> to me. We do a prefix match, and then return the entry whose name is
> the shortest? And break ties based on which came first? So:
>
> git -c pretty.abcd=format:one \
> -c pretty.abc=format:two \
> -c pretty.abd=format:three \
> log -1 --format=ab
>
> quietly chooses "two". I guess the "shortest wins" is meant to allow
> "foo" to be chosen over "foobar" if you specify the whole name. But
> the fact that we don't flag an ambiguity between "abc" and "abd"
> seems strange.
> That is all orthogonal to your patch, of course, but just a
> head-scratcher I noticed while looking at the code.
I think it is not just strange but outright wrong. I agree that it
is orthogonal to this fix.
Thanks, both.
^ permalink raw reply [relevance 6%]
* Re: [GSoC] Microproject help
@ 2024-03-25 20:51 6% ` Eric Sunshine
0 siblings, 0 replies; 200+ results
From: Eric Sunshine @ 2024-03-25 20:51 UTC (permalink / raw)
To: vk; +Cc: git
On Mon, Mar 25, 2024 at 11:40 AM vk <g@vkabc.me> wrote:
> For the microproject, I have looked into the lists for 2024 and it seems
> that all the projects have been taken except for `Replace a
> run_command*() call by direct calls to C functions`. However, it seems
> that the issue has been solved. The command I ran to search throughout
> the repo is `git grep 'run_command*('` and the search result returns
> run_command functions which I assume are essential.
>
> If there is any low hanging fruits that you can suggest to me for the
> microproject, that will be great. I will also be searching throughout
> the mailing list to see if there are any potential microproject to work
> on.
Searching the mailing list for "#leftoverbits"[1] can be a good way to
discover little tasks which may be suitable for a GSoC microproject.
[1]: https://lore.kernel.org/git/?q=%23leftoverbits
^ permalink raw reply [relevance 6%]
* Re: [PATCH 2/2] maintenance: running maintenance should not stop on errors
@ 2024-04-17 15:41 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-04-17 15:41 UTC (permalink / raw)
To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:
> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> In https://github.com/microsoft/git/issues/623, it was reported that
> maintenance stops on a missing repository, omitting the remaining
> repositories that were scheduled for maintenance.
>
> This is undesirable, as it should be a best effort type of operation.
>
> It should still fail due to the missing repository, of course, but not
> leave the non-missing repositories in unmaintained shapes.
>
> Let's use `for-each-repo`'s shiny new `--keep-going` option that we just
> introduced for that very purpose.
>
> This change will be picked up when running `git maintenance start`,
> which is run implicitly by `scalar reconfigure`.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> builtin/gc.c | 7 ++++---
> t/t7900-maintenance.sh | 6 +++---
> 2 files changed, 7 insertions(+), 6 deletions(-)
Other than the N_("") thing Eric noticed, I didn't find anything
glaringly wrong in these two patches. Nicely done.
We may want to fold overly long lines we see in the patch, but I'd
prefer to see it done as a post-cleanup task (#leftoverbits), as the
lines in the preimage of the patch are already overly long.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: [PATCH 3/3] color: add support for 12-bit RGB colors
@ 2024-04-30 17:31 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-04-30 17:31 UTC (permalink / raw)
To: Jeff King; +Cc: Beat Bolli, git, Beat Bolli
Jeff King <peff@peff.net> writes:
> On Mon, Apr 29, 2024 at 06:48:49PM +0200, Beat Bolli wrote:
>
>> -test_expect_success '24-bit colors' '
>> - color "#ff00ff black" "[38;2;255;0;255;40m"
>> +test_expect_success 'RGB colors' '
>> + color "#ff00ff #0f0" "[38;2;255;0;255;48;2;0;255;0m"
>> '
>
> Heh, I would still think of it as a shorthand for 24-bit color, but I
> guess you could argue it is now 12-bit color. :)
>
> (Only observing, I think the new name is fine).
>
>> test_expect_success '"default" foreground' '
>> @@ -146,7 +146,10 @@ test_expect_success 'non-hex character in RGB color' '
>> invalid_color "#12x456" &&
>> invalid_color "#123x56" &&
>> invalid_color "#1234x6" &&
>> - invalid_color "#12345x"
>> + invalid_color "#12345x" &&
>> + invalid_color "#x23" &&
>> + invalid_color "#1x3" &&
>> + invalid_color "#12x"
>> '
>
> This made me wonder what we'd do with "#1", "#12", "#1234", etc. Looking
> at the code change, I think we'd continue to reject them. I wonder if it
> is worth covering here.
Worth covering in this test, yes, but I am perfectly OK with leaving
it outside the series as a #leftoverbit clean-up.
^ permalink raw reply [relevance 6%]
* Re: [PATCH v4 1/3] doc: clean up usage documentation for --no-* opts
@ 2024-05-03 17:30 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-05-03 17:30 UTC (permalink / raw)
To: James Liu; +Cc: git
James Liu <james@jamesliu.io> writes:
> We'll be adding another option to the --no-* class of options soon.
>
> Clean up the existing options by grouping them together in the OPTIONS
> section, and adding missing ones to the SYNOPSIS.
Nice.
> diff --git a/Documentation/git.txt b/Documentation/git.txt
> index 7a1b112a3e..7fa75350b2 100644
> --- a/Documentation/git.txt
> +++ b/Documentation/git.txt
> @@ -11,9 +11,9 @@ SYNOPSIS
> [verse]
> 'git' [-v | --version] [-h | --help] [-C <path>] [-c <name>=<value>]
> [--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
> - [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--bare]
> - [--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
> - [--config-env=<name>=<envvar>] <command> [<args>]
> + [-p|--paginate|-P|--no-pager] [--no-replace-objects] [--no-lazy-fetch]
> + [--no-optional-locks] [--bare] [--git-dir=<path>] [--work-tree=<path>]
> + [--namespace=<name>] [--config-env=<name>=<envvar>] <command> [<args>]
Looks sensible.
There still are a few options (like noglob-pathspecs) missing, but
cleaning them up from this part of the documentation is totally
outside the scope of this topic (#leftoverbits -- we either make
this exhaustive, or make it clear that this is not exhaustive).
Thanks.
^ permalink raw reply [relevance 6%]
* [GSoC] Some #leftoverbits for anyone looking for little projects
@ 2018-03-17 21:20 6% Ævar Arnfjörð Bjarmason
2019-05-29 9:38 8% ` Johannes Schindelin
0 siblings, 2 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-03-17 21:20 UTC (permalink / raw)
To: Git Mailing List
In lieu of sending a PR to https://git.github.io/SoC-2018-Microprojects/
I thought I'd list a few more suggestions, and hopefully others will
chime in.
This is all TODO stuff I've been meaning to do myself, but wouldn't mind
at all if someone else tackled.
I'm not interested in mentoring GSoC, but these are all small enough to
need to special help from me (or anyone in particular), and if nobody
picks them up I can refer back to this mail for my own use.
* Having grep support the -o option like GNU grep et al.
We have most of the code for this already in the form of our color
hi-lighting, it would mostly just be a matter of "just print out the
stuff you'd have colored", with the small exception that if you have
more than one match on a line they should be printed out on their own
lines.
* Give "rebase -i" some option so when you "reword" the patch is
included in the message.
I keep going to the shell because I have no idea what change I'm
describing.
* Add more config IncludeIf conditions.
Recently there was a mention on git-users to excend the includeIf
statement to read config:
https://groups.google.com/forum/?fromgroups#!searchin/git-users/includeif%7Csort:date/git-users/SHd506snwSk/UdVCsCILBwAJ
Now that seems like a nasty circular dependency but there's other
low-hanging fruit there, like make it match a given env name to a
value (or glob?).
* Add another set of GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} with lower
priorities.
There is a script at work which I have to manually blacklist which
sets git author names & e-mails via LDAP for all logged in users via
/etc/profile (and gets my name wrong)[1].
It would be nice if git supported a way to do this that didn't either
involve overriding everything (as the current env vars do) or munging
the user's ~ config (ew!). I.e. the priority of these new env vars
would come after reading from the config, not overriding the config
as the current ones do. So it could be used to make a suggestion if
no other value was found.
* Write git-unpack-{refs,objects}
I don't know if this is small enough (maybe the refs part?). This
would give you purely loose objects & refs. This is a terrible idea
for any "real" use, but very useful for testing.
Now when I'm testing repack I need to keep an old copy of the repo
around, because there's no easy way (that I know of) to pack things
and then get back to loose object state. Ditto for packing refs.
* I had a previous TODO list of "small" things at
https://public-inbox.org/git/CACBZZX5wdnA-96e11edE7xRnAHo19RFTrZmqFQj-0ogLOJTncQ@mail.gmail.com/
1. At work like in so many companies LDAP is synced everywhere, but of
course that means catering to the lowest common denominator. Last I
heard attempts to give me a non-ASCII name (in the GEOS field) had
failed because some phone or printer somewhere refused to accept it.
^ permalink raw reply [relevance 6%]
* Re: Git Open Source Weekend London 11th/12th November
@ 2017-11-04 9:28 6% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2017-11-04 9:28 UTC (permalink / raw)
To: Thomas Gummerer; +Cc: Git Mailing List, hkleynhans
On Wed, Nov 01, 2017 at 04:36:24PM +0000, Thomas Gummerer wrote:
> Normally attendees work in small groups on a specific task to
> prevent anyone from getting stuck. Per usual, Bloomberg will
> provide the venue, mentors, snacks and drinks. Bring your
> enthusiasm (and your laptop!) and come share in the fun! The
> event is also open to everyone, so feel free to pass on the
> invite!
I think it will help if the experienced members of the community (both
those who will be at the event and not) can come up with some possible
topics to work on (though of course I'd be glad for participants to come
with their own itch to scratch).
We've started using the #leftoverbits tag to allow searching in the
archive:
https://public-inbox.org/git/?q=leftoverbits
Some of those have since been completed, but others are left open.
There's not really a master list, but it's a potential source for
digging for gold (well, if you want to call leftover bugs gold :) ).
I started a list over the summer of larger items that people might want
to pick up. Here it is in no particular order:
- the pager.<cmd> config is mis-designed, because our config keys
cannot represent all possible command names (e.g., case folding and
illegal characters). This should be pager.<cmd>.enable or similar.
Some discussion in (this message and the surrounding thread):
https://public-inbox.org/git/20170711101942.h2uwxtgzvgguzivu@sigill.intra.peff.net/
But I think you could find more by searching the archive.
- ditto for alias.* config, which has the same syntax problems.
- auto-gc is sometimes over-anxious to run if you have a lot of
unreachable loose objects. We should pack unreachables into a single
pack. That solves the --auto problem, and is also way more efficient.
The catch is expiration. Some discussion here (and especially
down-thread):
https://public-inbox.org/git/20170711101942.h2uwxtgzvgguzivu@sigill.intra.peff.net/
- git-config's "--get-color" is unlike all the other types in that it
takes a "default" value if the config key isn't set. This makes it annoyingly
inconsistent, but there's also no way to ask Git to interpret other
values (e.g., you might want it to expand "--path" or an "--int"). It
would be nice to have a general "--default" option so you could do:
# same as git config --get-color color.diff.old red
git config --default red --color color.diff.old
or
# not currently possible to ask git to interpret "10k"
git config --default 10k --int some.integer.key
- git's internal config can parse expiration dates (see
parse_expiry_date()), but you can't do so from git-config. It should
probably have a type for "--expiry-date" (which would of course be
more useful with the --default option above).
- there's no efficient way to ask git-config for several keys with a
specific type (or even multiple different types). You can use
"--list" to get their strings, but you can't get any interpretation
(like colors, integers, etc). Invoking git-config many times can have
a noticeable speed impact for a script. There should probably be a
"--stdin" mode (or maybe "--get-stdin" if we would one day want to
have a "--set-stdin") that takes a list of keys, optional types, and
optional defaults (that "--default" again!) and outputs them to
stdout.
Those were just sitting on my ideas list. I'm happy to go into more
detail if anybody's interested in discussing any of them. Some of them
may be half-baked.
And of course I'd be happy if people wanted to contribute more items to
the list.
-Peff
^ permalink raw reply [relevance 6%]
* Re: [PATCH] git: extend --no-lazy-fetch to work across subprocesses
@ 2024-02-27 6:04 6% ` Junio C Hamano
2024-02-27 7:49 6% ` Jeff King
0 siblings, 1 reply; 200+ results
From: Junio C Hamano @ 2024-02-27 6:04 UTC (permalink / raw)
To: Jeff King; +Cc: git, Christian Couder
Jeff King <peff@peff.net> writes:
>> diff --git a/Documentation/git.txt b/Documentation/git.txt
>> index 2f1cb3ef4e..be2829003d 100644
>> --- a/Documentation/git.txt
>> +++ b/Documentation/git.txt
>> @@ -183,6 +183,8 @@ If you just want to run git as if it was started in `<path>` then use
>> Do not fetch missing objects from the promisor remote on
>> demand. Useful together with `git cat-file -e <object>` to
>> see if the object is locally available.
>> + This is equivalent to setting the `GIT_NO_LAZY_FETCH`
>> + environment variable to `1`.
>
> As with the other patch, I'd suggest adding an entry to the list of
> environment variables later in the manpage.
Thanks, done.
We'll have to make a separate patch to add GIT_NO_REPLACE_OBJECTS to
the list, by the way (#leftoverbits), which I used as a model to
find what needs to be updated.
>> --- a/environment.h
>> +++ b/environment.h
>> @@ -35,6 +35,7 @@ const char *getenv_safe(struct strvec *argv, const char *name);
>> #define EXEC_PATH_ENVIRONMENT "GIT_EXEC_PATH"
>> #define CEILING_DIRECTORIES_ENVIRONMENT "GIT_CEILING_DIRECTORIES"
>> #define NO_REPLACE_OBJECTS_ENVIRONMENT "GIT_NO_REPLACE_OBJECTS"
>> +#define NO_LAZY_FETCH_ENVIRONMENT "GIT_NO_LAZY_FETCH"
>> #define GIT_REPLACE_REF_BASE_ENVIRONMENT "GIT_REPLACE_REF_BASE"
>> #define GITATTRIBUTES_FILE ".gitattributes"
>> #define INFOATTRIBUTES_FILE "info/attributes"
>
> A small nit, but maybe worth keeping the two replace-related variables
> next to each other, rather than sticking the new one in the middle?
OK.
>> diff --git a/git.c b/git.c
>> index 28e8bf7497..d11d4dc77b 100644
>> --- a/git.c
>> +++ b/git.c
>> @@ -189,6 +189,9 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
>> *envchanged = 1;
>> } else if (!strcmp(cmd, "--no-lazy-fetch")) {
>> fetch_if_missing = 0;
>> + setenv(NO_LAZY_FETCH_ENVIRONMENT, "1", 1);
>> + if (envchanged)
>> + *envchanged = 1;
>> } else if (!strcmp(cmd, "--no-replace-objects")) {
>> disable_replace_refs();
>> setenv(NO_REPLACE_OBJECTS_ENVIRONMENT, "1", 1);
>
> I _suspect_ this makes the fetch_if_missing call redundant, since we
> should be parsing these before doing any repo setup that would trigger
> the code that reads the environment variable.
True. Again, we'd need to clean-up the NO_REPLACE_OBJECTS codepath
as well---the disable_replace_refs() call should also be redundant,
which I mimicked to add the no-lazy-fetch codepath (#leftoverbits).
> This should probably also be xsetenv(), though as you can see in the
> context we are not very consistent about using it. :) But certainly if
> we failed to set it I would prefer to see an error rather than
> accidentally lazy-fetching.
I'd probably leave it outside the scope of this series; as nobody
uses xsetenv() in git.c currently, it would be a clean-up topic on
its own (#leftoverbits).
>> diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh
>> index 5b7bee888d..59629cea1f 100755
>> --- a/t/t0410-partial-clone.sh
>> +++ b/t/t0410-partial-clone.sh
>> @@ -665,6 +665,15 @@ test_expect_success 'lazy-fetch when accessing object not in the_repository' '
>> git -C partial.git rev-list --objects --missing=print HEAD >out &&
>> grep "[?]$FILE_HASH" out &&
>>
>> + # The no-lazy-fetch mechanism prevents Git from fetching
>> + test_must_fail env GIT_NO_LAZY_FETCH=1 \
>> + git -C partial.git cat-file -e "$FILE_HASH" &&
>> + test_must_fail git --no-lazy-fetch -C partial.git cat-file -e "$FILE_HASH" &&
>> +
>> + # Sanity check that the file is still missing
>> + git -C partial.git rev-list --objects --missing=print HEAD >out &&
>> + grep "[?]$FILE_HASH" out &&
>
> OK, we exercise it by setting the variable directly. A more interesting
> one might be:
>
> git -c alias.foo='!git cat-file' --no-lazy-fetch ...
>
> which should fail without the patch.
True, again. I'll test all three variants (i.e. environment,
command line option to "git", forced subprocess turning command line
option to "git" into environment).
Thanks.
----- >8 --------- >8 --------- >8 --------- >8 -----
Subject: [PATCH v2 3/3] git: extend --no-lazy-fetch to work across subprocesses
Modeling after how the `--no-replace-objects` option is made usable
across subprocess spawning (e.g., cURL based remote helpers are
spawned as a separate process while running "git fetch"), allow the
`--no-lazy-fetch` option to be passed across process boundaries.
Do not model how the value of GIT_NO_REPLACE_OBJECTS environment
variable is ignored, though. Just use the usual git_env_bool() to
allow "export GIT_NO_LAZY_FETCH=0" and "unset GIT_NO_LAZY_FETCH"
to be equivalents.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Range-diff:
1: 00e202b679 ! 1: e0764f2e21 git: extend --no-lazy-fetch to work across subprocesses
@@ Documentation/git.txt: If you just want to run git as if it was started in `<pat
--literal-pathspecs::
Treat pathspecs literally (i.e. no globbing, no pathspec magic).
+@@ Documentation/git.txt: for full details.
+ Setting this Boolean environment variable to true will cause Git to treat all
+ pathspecs as case-insensitive.
+
++`GIT_NO_LAZY_FETCH`::
++ Setting this Boolean environment variable to true tells Git
++ not to lazily fetch missing objects from the promisor remote
++ on demand.
++
+ `GIT_REFLOG_ACTION`::
+ When a ref is updated, reflog entries are created to keep
+ track of the reason why the ref was updated (which is
## environment.c ##
@@ environment.c: const char * const local_repo_env[] = {
@@ environment.c: void setup_git_env(const char *git_dir)
## environment.h ##
@@ environment.h: const char *getenv_safe(struct strvec *argv, const char *name);
- #define EXEC_PATH_ENVIRONMENT "GIT_EXEC_PATH"
#define CEILING_DIRECTORIES_ENVIRONMENT "GIT_CEILING_DIRECTORIES"
#define NO_REPLACE_OBJECTS_ENVIRONMENT "GIT_NO_REPLACE_OBJECTS"
-+#define NO_LAZY_FETCH_ENVIRONMENT "GIT_NO_LAZY_FETCH"
#define GIT_REPLACE_REF_BASE_ENVIRONMENT "GIT_REPLACE_REF_BASE"
++#define NO_LAZY_FETCH_ENVIRONMENT "GIT_NO_LAZY_FETCH"
#define GITATTRIBUTES_FILE ".gitattributes"
#define INFOATTRIBUTES_FILE "info/attributes"
+ #define ATTRIBUTE_MACRO_PREFIX "[attr]"
## git.c ##
@@ git.c: static int handle_options(const char ***argv, int *argc, int *envchanged)
@@ t/t0410-partial-clone.sh: test_expect_success 'lazy-fetch when accessing object
+ # The no-lazy-fetch mechanism prevents Git from fetching
+ test_must_fail env GIT_NO_LAZY_FETCH=1 \
+ git -C partial.git cat-file -e "$FILE_HASH" &&
++
++ # The same with command line option to "git"
+ test_must_fail git --no-lazy-fetch -C partial.git cat-file -e "$FILE_HASH" &&
+
++ # The same, forcing a subprocess via an alias
++ test_must_fail git --no-lazy-fetch -C partial.git \
++ -c alias.foo="!git cat-file" foo -e "$FILE_HASH" &&
++
+ # Sanity check that the file is still missing
+ git -C partial.git rev-list --objects --missing=print HEAD >out &&
+ grep "[?]$FILE_HASH" out &&
Documentation/git.txt | 7 +++++++
environment.c | 4 ++++
environment.h | 1 +
git.c | 3 +++
t/t0410-partial-clone.sh | 15 +++++++++++++++
5 files changed, 30 insertions(+)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 2f1cb3ef4e..6fbaa9dd2b 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -183,6 +183,8 @@ If you just want to run git as if it was started in `<path>` then use
Do not fetch missing objects from the promisor remote on
demand. Useful together with `git cat-file -e <object>` to
see if the object is locally available.
+ This is equivalent to setting the `GIT_NO_LAZY_FETCH`
+ environment variable to `1`.
--literal-pathspecs::
Treat pathspecs literally (i.e. no globbing, no pathspec magic).
@@ -896,6 +898,11 @@ for full details.
Setting this Boolean environment variable to true will cause Git to treat all
pathspecs as case-insensitive.
+`GIT_NO_LAZY_FETCH`::
+ Setting this Boolean environment variable to true tells Git
+ not to lazily fetch missing objects from the promisor remote
+ on demand.
+
`GIT_REFLOG_ACTION`::
When a ref is updated, reflog entries are created to keep
track of the reason why the ref was updated (which is
diff --git a/environment.c b/environment.c
index 9e37bf58c0..afad78a3f8 100644
--- a/environment.c
+++ b/environment.c
@@ -136,6 +136,7 @@ const char * const local_repo_env[] = {
GRAFT_ENVIRONMENT,
INDEX_ENVIRONMENT,
NO_REPLACE_OBJECTS_ENVIRONMENT,
+ NO_LAZY_FETCH_ENVIRONMENT,
GIT_REPLACE_REF_BASE_ENVIRONMENT,
GIT_PREFIX_ENVIRONMENT,
GIT_SHALLOW_FILE_ENVIRONMENT,
@@ -207,6 +208,9 @@ void setup_git_env(const char *git_dir)
shallow_file = getenv(GIT_SHALLOW_FILE_ENVIRONMENT);
if (shallow_file)
set_alternate_shallow_file(the_repository, shallow_file, 0);
+
+ if (git_env_bool(NO_LAZY_FETCH_ENVIRONMENT, 0))
+ fetch_if_missing = 0;
}
int is_bare_repository(void)
diff --git a/environment.h b/environment.h
index e5351c9dd9..5cec19cecc 100644
--- a/environment.h
+++ b/environment.h
@@ -36,6 +36,7 @@ const char *getenv_safe(struct strvec *argv, const char *name);
#define CEILING_DIRECTORIES_ENVIRONMENT "GIT_CEILING_DIRECTORIES"
#define NO_REPLACE_OBJECTS_ENVIRONMENT "GIT_NO_REPLACE_OBJECTS"
#define GIT_REPLACE_REF_BASE_ENVIRONMENT "GIT_REPLACE_REF_BASE"
+#define NO_LAZY_FETCH_ENVIRONMENT "GIT_NO_LAZY_FETCH"
#define GITATTRIBUTES_FILE ".gitattributes"
#define INFOATTRIBUTES_FILE "info/attributes"
#define ATTRIBUTE_MACRO_PREFIX "[attr]"
diff --git a/git.c b/git.c
index 28e8bf7497..d11d4dc77b 100644
--- a/git.c
+++ b/git.c
@@ -189,6 +189,9 @@ static int handle_options(const char ***argv, int *argc, int *envchanged)
*envchanged = 1;
} else if (!strcmp(cmd, "--no-lazy-fetch")) {
fetch_if_missing = 0;
+ setenv(NO_LAZY_FETCH_ENVIRONMENT, "1", 1);
+ if (envchanged)
+ *envchanged = 1;
} else if (!strcmp(cmd, "--no-replace-objects")) {
disable_replace_refs();
setenv(NO_REPLACE_OBJECTS_ENVIRONMENT, "1", 1);
diff --git a/t/t0410-partial-clone.sh b/t/t0410-partial-clone.sh
index 5b7bee888d..c282851af7 100755
--- a/t/t0410-partial-clone.sh
+++ b/t/t0410-partial-clone.sh
@@ -665,6 +665,21 @@ test_expect_success 'lazy-fetch when accessing object not in the_repository' '
git -C partial.git rev-list --objects --missing=print HEAD >out &&
grep "[?]$FILE_HASH" out &&
+ # The no-lazy-fetch mechanism prevents Git from fetching
+ test_must_fail env GIT_NO_LAZY_FETCH=1 \
+ git -C partial.git cat-file -e "$FILE_HASH" &&
+
+ # The same with command line option to "git"
+ test_must_fail git --no-lazy-fetch -C partial.git cat-file -e "$FILE_HASH" &&
+
+ # The same, forcing a subprocess via an alias
+ test_must_fail git --no-lazy-fetch -C partial.git \
+ -c alias.foo="!git cat-file" foo -e "$FILE_HASH" &&
+
+ # Sanity check that the file is still missing
+ git -C partial.git rev-list --objects --missing=print HEAD >out &&
+ grep "[?]$FILE_HASH" out &&
+
git -C full cat-file -s "$FILE_HASH" >expect &&
test-tool partial-clone object-info partial.git "$FILE_HASH" >actual &&
test_cmp expect actual &&
--
2.44.0-35-ga2082dbdd3
^ permalink raw reply related [relevance 6%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-29 18:30 14% Is origin/HEAD only being created on clone a bug? #leftoverbits Ævar Arnfjörð Bjarmason
2018-05-29 19:17 8% ` Brandon Williams
@ 2018-05-30 1:24 6% ` Junio C Hamano
2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
2018-05-30 2:46 8% ` Junio C Hamano
1 sibling, 2 replies; 200+ results
From: Junio C Hamano @ 2018-05-30 1:24 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git List, Johannes Schindelin
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> If you make an initial commit and push to a remote repo "origin", you
> don't get a remote origin/HEAD reference, and a "fetch" won't create it
> either.
> ...
> Some code spelunking reveals remote_head_points_at, guess_remote_head()
> etc. in builtin/clone.c. I.e. this is special-cased as part of the
> "clone".
Correct. Originally, there was *no* way in the protocol to carry
the information, so the code always had to guess. The point of
setting origin/HEAD was mostly so that you can say "log origin.."
and rely on it getting dwimmed down to "refs/remotes/%s/HEAD..",
and it wasn't a common practice to interact with multiple remotes
with remote tracking branches (integrator interacting with dozens
of remotes, responding to pull requests using explicit URL but
without configured remotes was not uncommon), so it was sufficient
for "git clone" to create it, and "git remote add" did not exist
back then anyway.
There are two aspects in my answer to your question.
- If we create additional remote (that is, other than the one we
get when we create a repository via "clone", so if your "origin"
is from "git init there && cd there && git remote add origin", it
does count in this category), should we get a remote-tracking
symref $name/HEAD so that we can say "log $name.."?
We absolutely should. We (eh, rather, those who added "remote
add"; this was not my itch and I am using "royal we" in this
sentence) just did not bother to and I think it is a bug that you
cannot say "log $name.." Of course, it is just a "git symbolic-ref"
away to make it possible locally, so it is understandable if
"remote add" did not bother to.
- When we fetch from a remote that has refs/remotes/$name/HEAD, and
if the protocol notices that their HEAD today is pointing to a
branch different from what our side has, should we repoint ours
to match?
I am leaning against doing this, but mostly out of superstition.
Namely, I feel uneasy about the fact that the meaning of "log
..origin" changes across a fetch in this sequence:
log ..origin && fetch origin && log ..origin
Without repointing origin/HEAD, two occurrences of "log ..origin"
both means "how much ahead the primary branch we have been
interested in from this remote is, relative to our effort?".
Even though we fully expect that two "log ..origin" would report
different results (after all, that is the whole point of doing
another one after "fetch" in such a sequence like this example),
our question is about the same "primary branch we have been
interested in". But once fetch starts messing with where
origin/HEAD points at, that would no longer be the case, which is
why I am against doing something magical like that.
^ permalink raw reply [relevance 6%]
* [Leftoverbits] exit code clean-up?
@ 2023-08-16 17:04 6% ` Junio C Hamano
2023-08-17 9:24 8% ` Oswald Buddenhagen
2023-08-17 5:36 7% ` Jeff King
0 siblings, 2 replies; 200+ results
From: Junio C Hamano @ 2023-08-16 17:04 UTC (permalink / raw)
To: git
Patrick earlier found that Gitaly's CI pipeline was being overly
picky and complained about the unintended change of the exit code of
"git fetch" in the affected codepath from 128 to 1 in a recent
change that went to 'next', made by 7ba7c52d (upload-pack: fix race
condition in error messages, 2023-08-10).
The thing is, we follow that exiting with 0 is success, and exiting
with non-zero means failure, and we generally do not specify which
non-zero value is used for the latter in our documentation. This
particular case (i.e. "git fetch") certainly does not say anything
about how failure is signaled to the calling program. "git help
git" does not have "EXIT CODES" section, and it is assumed that the
"common sense" of older generation (gee, this project is more than
18 years old) that exiting with 0 is success and non-zero is failure
is shared among its users, which might not be warranted these days.
We could either
* Be more prescriptive and add "EXIT CODES" section to each and
every document to describe how we fail in the current code.
or
* Describe "In general, 0 is success, non-zero is failure, but some
commands may signal more than that with its non-zero exit codes"
in "git help git", and add "EXIT CODES" section to the manual
page of the commands whose exit codes matter (there are a
handful, like "git diff --exit-code" that explicitly says "1" is
the signal that it found difference as opposed to it failing).
I'd prefer if community agrees that we should do the latter, but I
am OK if the community consensus goes the other way.
If we were to go the former, the task becomes larger but it would be
embarrassingly parallelizable. Folks with extra time on their hand
can lend their eyes to tackle each command, find what exit code we
use in the current code, add "EXIT CODES" section to the documentation,
and extend test coverage to ensure their findings will stay unless
we deliberately change it in the future.
If we were to go the latter, the task will be significantly smaller.
We need to come up with a careful phrasing to add to "git help git"
and/or "git help cli" to give the general principle of zero vs
non-zero whose exact values are left unspecified and should not be
depended upon. We also need to identify the special cases where the
exact values have meanings (like the "git diff --exit-code" example
above), describe them by adding "EXIT CODES" section to the manual
pages of these selected commands, and extend test coverage to ensure
these values are kept intact across future changes.
Comments?
^ permalink raw reply [relevance 6%]
* Re: [PATCH] fetch --prune: exit with error if pruning fails
@ 2022-01-27 19:57 6% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-01-27 19:57 UTC (permalink / raw)
To: Thomas Gummerer; +Cc: git, Johannes Schindelin, Taylor Blau
Thomas Gummerer <t.gummerer@gmail.com> writes:
> When pruning refs fails, we currently print an error to stderr, but
> still exit 0 from 'git fetch'. Since this is a genuine error fetch
> should be exiting with some non-zero exit code. Make it so.
>
> The --prune option was introduced in f360d844de ("builtin-fetch: add
> --prune option", 2009-11-10). Unfortunately it's unclear from that
> commit whether ignoring the exit code was an oversight or
> intentional, but it feels like an oversight.
It is a good idea to signal, with a non-zero status, that the user
needs to inspect the situation and possibly take a corrective
action. I however do not know if it is sufficient to just give the
same exit status as returned by prune_refs(), which may or may not
happen to crash with other possible non-zero exit status to make it
indistinguishable from other kinds of errors.
> if (rs->nr) {
> - prune_refs(rs, ref_map, transport->url);
> + retcode = prune_refs(rs, ref_map, transport->url);
> } else {
> - prune_refs(&transport->remote->fetch,
> - ref_map,
> - transport->url);
> + retcode = prune_refs(&transport->remote->fetch,
> + ref_map,
> + transport->url);
> + }
It seems that it is possible for do_fetch() to return a negative
value, even without this patch. The return value from prune_refs()
comes from refs.c::delete_refs(), which can come from error_errno()
that is -1, so this patch adds more of the same problem to existing
ones, though.
And the value propagates up to cmd_fetch() via fetch_one(). This
will be relayed to exit() without changing via this callchain:
git.c::cmd_main()
git.c::run_argv()
git.c::handle_builtin()
git.c::run_builtin()
This is not a new problem, which does not want to be corrected as
part of this patch, but let's leave a mental note as #leftoverbits
for now.
> + if (retcode) {
> + free_refs(ref_map);
> + goto cleanup;
> }
This part is iffy. We tried to prune refs, we may have removed some
of the refs missing from the other side but we may still have some
other refs that are missing from the other side due to the failure
we noticed.
Is it sensible to abort the fetching? I am undecided, but without
further input, my gut reaction is that it is safe and may even be
better to treat this as a soft error and try to go closer to where
the user wanted to go as much as possible by continuing to fetch
from the other side, given that we have already paid for the cost of
discovering the refs from the other side.
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index 20f7110ec1..df824cc3d0 100755
> --- a/t/t5510-fetch.sh
> +++ b/t/t5510-fetch.sh
> @@ -164,6 +164,16 @@ test_expect_success 'fetch --prune --tags with refspec prunes based on refspec'
> git rev-parse sometag
> '
>
> +test_expect_success REFFILES 'fetch --prune fails to delete branches' '
> + cd "$D" &&
> + git clone . prune-fail &&
> + cd prune-fail &&
> + git update-ref refs/remotes/origin/extrabranch main &&
> + >.git/packed-refs.new &&
> + test_must_fail git fetch --prune origin
Is it because the lockfile ".new" on packed-refs prevents deletion
of refs but does not block creation and updates to existing refs
that it is an effective test for the "--prune" issue? If we somehow
"locked" the whole ref updates, then the fetch would fail even
without "--prune", so it may be "effective", but smells like knowing
too much implementation detail. Yuck, but I do not offhand think of
any better way (it is easier to think of worse ways), so without
further input, I would say that this is the best (or "least bad") we
can do.
Another tangent #leftoverbits is that many tests in this script are
so old-style that chdir around without isolating themselves in
subshells, while some do. We may want to clean them up when the
file is quiescent.
Thanks.
^ permalink raw reply [relevance 6%]
* Re: My first contribution. Outreachy
[not found] <CAL21Bm=zQ2ADTOSVk5kL1q=VyLV91J+VbsLLFbSdgPxeg3FW1g@mail.gmail.com>
@ 2017-09-21 5:30 7% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2017-09-21 5:30 UTC (permalink / raw)
To: Оля Тележная
Cc: Christian Couder, git
[Note that your email didn't make it to the mailing list because it
was formatted as HTML. You may want to tweak your gmail settings to
send plain text. Those of us on the to/cc did get it, though].
On Tue, Sep 19, 2017 at 03:45:18PM +0300, Оля Тележная wrote:
> If you could help me with choosing my first task and give some
> thoughts about where to look to solve the problem - that would be
> great.
Here are a few possibilities:
- The task mentioned in:
https://public-inbox.org/git/20170912172839.GB144745@aiede.mtv.corp.google.com/
to convert the ad-hoc doubly-linked list implementation used in
mru.c and mru.h to use the implementation from list.h.
Note that I've pointed a few other people at this task, so you may
find other candidates working on it, too (and it's possible if we
get multiple good versions submitted yours might not get applied; I
still think it's a good simple task that will help get you familiar
with writing and submitting a patch).
- We've been working with some leak-checking tools lately to try to
find memory leaks in Git by running the test suite. You can see some
example patches:
https://public-inbox.org/git/1505936846-2195-1-git-send-email-martin.agren@gmail.com/
https://public-inbox.org/git/1505936846-2195-2-git-send-email-martin.agren@gmail.com/
https://public-inbox.org/git/1505936846-2195-3-git-send-email-martin.agren@gmail.com/
You can find more instances by building with the leak-checker
(you'll need to have a recent version of gcc or clang as your
compiler):
make SANITIZE=leak
and then running individual test scripts, seeing what fails, and
investigating the leak-checker output. There's a bit more discussion
in the cover letter here:
https://public-inbox.org/git/20170905130149.agc3zp3s6i6e5aki@sigill.intra.peff.net/
Even though the patches are relatively small, there are a lot of
things to learn here about building Git and running the tests. Don't
hesitate to ask if you get stuck.
- We've started marking small unfinished tasks with the
"#leftoverbits" tag in emails, which can then be searched in the
mailing list archive:
https://public-inbox.org/git/?q=leftoverbits
We don't use a formal bug-tracker, so this is a good way of seeing
which discussions people feel newcomers may be able to jump in on.
You may need to read the surrounding thread to get context, but
again, don't hesitate to ask if you need help figuring out exactly
what the task is or how it should be done.
-Peff
^ permalink raw reply [relevance 7%]
* Re: My first contribution
[not found] <CAL21Bm=e9C4ANTsc4n1BG3xqjCJmORDSPcS5QEXYKUkK3cAH6w@mail.gmail.com>
@ 2017-09-19 8:05 7% ` Christian Couder
0 siblings, 0 replies; 200+ results
From: Christian Couder @ 2017-09-19 8:05 UTC (permalink / raw)
To: Оля Тележная
Cc: Jeff King, git
Hi Olga,
On Tue, Sep 19, 2017 at 8:44 AM, Оля Тележная <olyatelezhnaya@gmail.com> wrote:
> Hello Jeff,
> I want to try myself into new role of a Git contributor.
Welcome to Git!
> All of the projects sound super interesting for me and I am ready to take
> part in all of them, but the project "Unifying Git's format languages" will
> be super useful for me myself, so my dream is to try solve that task first.
Great that you found a project you like!
> I need help to choose my first task in the project, because first steps are
> usually the most frightening.
> I am familiar enough with C and there's no problem to read any docs, but
> please help me choosing the first task. If you have any guidance like "how
> to start" or "how to choose tasks", please send that links also.
You can try to work first on the project you are interested in or you
can find and work on a small project first.
One way to find a small project is to see what people are
talking about on the mailing list[1]. Quite often there are bugs
that can be fixed, and more experienced people may help sketch out
a solution. You can also find small items good for newcomers marked
with the "leftoverbits" tag, which you can search for in the
mailing list[2].
We don't have a written guide specifically downloading git, getting it
built, running the tests, and so forth, but you might start with:
git clone https://github.com/git/git
and reading the INSTALL file.
As the mailing list can be a bit intimidating at first, we don't mind
working with you one-on-one a bit during the application period.
About the mailing list, please add [Outreachy] in the subject to make
it clear that you are applying for the Outreachy program.
While at it on the Git mailing list we are used to replying to parts
of message after those parts. We don't usually reply before the
message. In other words we are used to "inline replying", not "top
posting" (see https://en.wikipedia.org/wiki/Posting_style). Please try
to use the same posting style as us, it will help keep discussions
more standard and easier to understand.
Also we feel free to remove parts of the messages we are quoting that
are not relevant anymore.
For getting in touch with us, direct email is our preferred method. We
could also meet on IRC if you like, but it looks like our timezones
might not overlap much. Still, we can probably set up a time.
Let us know if you have any questions at all. This is our first time
mentoring for Outreachy, so we've surely forgotten to mention some
obvious thing you would want to know. :)
Thanks,
Christian.
[1] There are details of the list at https://git-scm.com/community,
but you may want to just browse the archive at:
https://public-inbox.org/git
[2] https://public-inbox.org/git/?q=leftoverbits
^ permalink raw reply [relevance 7%]
* Re: [PATCH] bugreport.c: fix a crash in `git bugreport` with `--no-suffix` option
@ 2024-03-13 15:59 7% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2024-03-13 15:59 UTC (permalink / raw)
To: barroit via GitGitGadget; +Cc: git, barroit, Emily Shaffer, Taylor Blau
"barroit via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Jiamu Sun <barroit@linux.com>
>
> executing `git bugreport --no-suffix` led to a segmentation fault
> due to strbuf_addftime() being called with a NULL option_suffix
> variable. This occurs because negating the "--[no-]suffix" option
> causes the parser to set option_suffix to NULL, which is not
> handled prior to calling strbuf_addftime().
>
> Signed-off-by: Jiamu Sun <barroit@linux.com>
> ---
"git blame" points at 238b439d (bugreport: add tool to generate
debugging info, 2020-04-16) that is the very beginning of this tool,
and the bug survived 4f6460df (builtin/bugreport.c: use thread-safe
localtime_r(), 2020-11-30). Apparently neither commit considered
"--suffix=<string>" would invite users to say "--no-suffix" (authors
of them CC'ed for their input).
Perhaps we should update the documentation a bit while at it? Here
is what I can find in its documentation.
SYNOPSIS
--------
[verse]
'git bugreport' [(-o | --output-directory) <path>] [(-s | --suffix) <format>]
[--diagnose[=<mode>]]
-s <format>::
--suffix <format>::
Specify an alternate suffix for the bugreport name, to create a file
named 'git-bugreport-<formatted-suffix>'. This should take the form of a
strftime(3) format string; the current local time will be used.
The above does not say that it is possible to ask the code not to
use suffix at all with "--no-suffix". If we want it to happen and
behave sensibly (which I think the code with your patch does, from
my cursory read), we probably should document it. At least two
developers, considered to be expert Git developers and consider
themselves to be expert Git users, did not even anticipate that
"--no-suffix" will hit their code.
Another approach (with devil's advocate hat on) is obviously to use
the PARSE_OPT_NONEG bit so that people won't do what hurts them ;-),
but the fix is so trivial that it may be better to formally accept
"--no-suffix" in this case.
An aside #leftoverbits is to find OPTION_STRING that is used without
NONEG bit and make sure negating them with the "--no-" prefix will
not trigger a similar issue. All uses of OPT_STRING() that use a
variable that is initialized to a non-NULL string are suspect. Of
course, this is #leftoverbits and must be kept outside the topic to
fix this bug (i.e. this patch).
> bugreport.c: fix a crash in git bugreport with --no-suffix option
>
> executing git bugreport --no-suffix led to a segmentation fault due to
> strbuf_addftime() being called with a NULL option_suffix variable. This
> occurs because negating the "--[no-]suffix" option causes the parser to
> set option_suffix to NULL, which is not handled prior to calling
> strbuf_addftime().
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1693%2Fbarroit%2Ffix-bugreport-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1693/barroit/fix-bugreport-v1
> Pull-Request: https://github.com/gitgitgadget/git/pull/1693
>
> builtin/bugreport.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/bugreport.c b/builtin/bugreport.c
> index 3106e56a130..32281815b77 100644
> --- a/builtin/bugreport.c
> +++ b/builtin/bugreport.c
> @@ -138,8 +138,11 @@ int cmd_bugreport(int argc, const char **argv, const char *prefix)
> strbuf_complete(&report_path, '/');
> output_path_len = report_path.len;
>
> - strbuf_addstr(&report_path, "git-bugreport-");
> - strbuf_addftime(&report_path, option_suffix, localtime_r(&now, &tm), 0, 0);
> + strbuf_addstr(&report_path, "git-bugreport");
> + if (option_suffix) {
> + strbuf_addch(&report_path, '-');
> + strbuf_addftime(&report_path, option_suffix, localtime_r(&now, &tm), 0, 0);
> + }
> strbuf_addstr(&report_path, ".txt");
>
> switch (safe_create_leading_directories(report_path.buf)) {
>
> base-commit: 945115026aa63df4ab849ab14a04da31623abece
^ permalink raw reply [relevance 7%]
* Re: [PATCH v9 1/3] push: add reflog check for "--force-if-includes"
@ 2020-10-02 16:22 7% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2020-10-02 16:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Srinidhi Kaushik, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Having said that, the change I suggested (to use `get_reachable_subset()`
> instead of repeated `in_merge_bases_many()`) is _still_ the right thing to
> do: we are not actually interested in the merge bases at all, but in
> reachability, and in the future there might be more efficient ways to
> determine that than painting down all the way to merge bases.
I agree with you that the age-old implementation has an obvious room
for optimization. I think I already pointed out a #leftoverbit that
we can invent a version of paint_down_to_common() that can
short-circuit and return immediately after one side (the "commit"
side) gets painted, so that in_merge_bases_many() can stop
immediately after finding out that the answer is "true".
The function is *not* about computing the merge base across the
commits on the "reference" side but finding out if "commit" is
reachable from any in the "reference" side, so (1) it has a wrong
name and more importantly (2) it wants to do something quite similar
to get_reachable_subset(), but it is much less ambitious.
get_reachable_subset() is capable of doing a lot more. Unlike the
older in_merge_bases_many() that allowed only one commit on the
candidate for an ancestor side, it can throw a set and ask "which
ones among these are reachable from the other set".
So from the "semantics" point of view, get_reachable_subset() is
overkill and less suitable than in_merge_bases_many() for this
particular application. We know we have only one candidate, and we
want to ask "is this reachable, or not?" a single bit question. In
any case, they should yield the right answer from correctness point
of view ;-)
Having said that.
I do not think in the longer term we should keep both. Clearly the
get_reachable_subset() function can handle more general cases, so it
would make a lot of sense to make in_merge_bases_many() into a thin
wrapper that feeds just a single commit array on one side to be
filtered while feeding the "reference" commits to the other side, as
long as we can demonstrate that the result is just as correct as,
and it is not slower than, the current implementation. That may be
a bit larger than a typical #leftoverbit but would be a good clean-up
project.
^ permalink raw reply [relevance 7%]
* Re: [PATCH] clone: support unusual remote ref configurations
@ 2022-01-26 19:11 7% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2022-01-26 19:11 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
Jonathan Tan <jonathantanmy@google.com> writes:
> When cloning a branchless and tagless but not refless remote using
> protocol v0 or v1, Git calls transport_fetch_refs() with an empty ref
> list. This makes the clone fail with the message "remote transport
> reported error".
>
> Git should have refrained from calling transport_fetch_refs(), just like
> it does in the case that the remote is refless. Therefore, teach Git to
> do this.
Makes sense.
> diff --git a/builtin/clone.c b/builtin/clone.c
> index 727e16e0ae..3df441eb71 100644
> --- a/builtin/clone.c
> +++ b/builtin/clone.c
> @@ -862,7 +862,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> const struct ref *refs, *remote_head;
> struct ref *remote_head_points_at = NULL;
> const struct ref *our_head_points_at;
> - struct ref *mapped_refs;
> + struct ref *mapped_refs = NULL;
> const struct ref *ref;
> struct strbuf key = STRBUF_INIT;
> struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
> @@ -1184,7 +1184,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>
> refs = transport_get_remote_refs(transport, &transport_ls_refs_options);
>
> - if (refs) {
> + if (refs)
> + mapped_refs = wanted_peer_refs(refs, &remote->fetch);
> +
> + if (mapped_refs) {
> int hash_algo = hash_algo_by_ptr(transport_get_hash_algo(transport));
OK, we used to decide on what they advertised and then filtered that
to what we are interested in inside the "true" side of the if/else.
If the result of filtering became empty, we declared a trouble.
Now we do the filtering first and decide on that. No matter how
many uninteresting refs they advertise, if they show no refs of
interest to us, it is like they have an empty repository.
> @@ -1193,8 +1196,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> */
> initialize_repository_version(hash_algo, 1);
> repo_set_hash_algo(the_repository, hash_algo);
> -
> - mapped_refs = wanted_peer_refs(refs, &remote->fetch);
> /*
> * transport_get_remote_refs() may return refs with null sha-1
> * in mapped_refs (see struct transport->get_refs_list
[start #leftoverbits]
I noticed these while reading outside the context of this patch.
None of them should be part of this patch, which deals only with the
case where mapped_refs becomes empty.
Here in the post-context of this hunk, there is a loop that iterates
over the original refs list, not the filtered mapped_refs list, to
compute "complete_refs_before_fetch". Should we need to update the
loop to work on mapped_refs?
And after that, we compute remote_head using the original refs
list, not the mapped_refs list, when calling find_ref_by_name(),
but use mapped_refs when calling guess_remote_head(). The
inconsistency smells fishy.
[end #leftoverbits]
> @@ -1240,7 +1241,6 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> option_branch, remote_name);
>
> warning(_("You appear to have cloned an empty repository."));
> - mapped_refs = NULL;
And we come here instead with the new code. We claim "you appear to
have cloned an empty repository", which is much closer than
"reported an error".
> @@ -1271,7 +1271,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>
> if (is_local)
> clone_local(path, git_dir);
> - else if (refs && complete_refs_before_fetch) {
> + else if (mapped_refs && complete_refs_before_fetch) {
> if (transport_fetch_refs(transport, mapped_refs))
> die(_("remote transport reported error"));
> }
And this is the other crux of the fix. As the root cause of the
problems is to decide with NULL-ness of refs if we do something that
uses mapped_refs, this fixes the inconsistency.
Looking good.
Will queue. Thanks.
> diff --git a/t/t5700-protocol-v1.sh b/t/t5700-protocol-v1.sh
> index 468bd3e13e..6c8d4c6cf1 100755
> --- a/t/t5700-protocol-v1.sh
> +++ b/t/t5700-protocol-v1.sh
> @@ -149,6 +149,21 @@ test_expect_success 'push with file:// using protocol v1' '
> grep "push< version 1" log
> '
>
> +test_expect_success 'cloning branchless tagless but not refless remote' '
> + rm -rf server client &&
> +
> + git -c init.defaultbranch=main init server &&
> + echo foo >server/foo.txt &&
> + git -C server add foo.txt &&
> + git -C server commit -m "message" &&
> + git -C server update-ref refs/notbranch/alsonottag HEAD &&
> + git -C server checkout --detach &&
> + git -C server branch -D main &&
> + git -C server symbolic-ref HEAD refs/heads/nonexistentbranch &&
> +
> + git -c protocol.version=1 clone "file://$(pwd)/server" client
> +'
> +
> # Test protocol v1 with 'ssh://' transport
> #
> test_expect_success 'setup ssh wrapper' '
^ permalink raw reply [relevance 7%]
* Re: How To Pick And Work On A Microproject
@ 2023-10-06 19:03 7% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2023-10-06 19:03 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Naomi Ibe, Kaartic Sivaraam
Christian Couder <christian.couder@gmail.com> writes:
> I am not sure how others feel about this, but I think it would be
> better in the future to not have to prepare such pages, and to just
> have a section with a number of examples of good microprojects on this
> https://git.github.io/General-Microproject-Information/ page. It will
> be easier to update this section when we know about other good ideas
> or better ideas, or when we want to remove an idea that we don't
> consider good anymore, or just update an idea.
If we have curated one-stop shop for microproject candidates to make
it easy to find them, it would be a vast improvement over the status
quo. The easier for us to update the contents of the list, the
better for participants. Having only one place that we need to look
at is one way to do so, and the general microproject information
page would be the best place to host it. I like it.
>> Then it goes on to suggest finding a bug report, but I tend to think
>> that fixing them is way oversized to be a good microproject.
>
> I agree that it's oversized for most bugs. I have just added the
> following paragraph at the end of this "Searching for bug reports"
> subsection:
>
> "Also some bugs are difficult to understand and require too much or
> too difficult work for a microproject, so don’t spend too much time on
> them if it appears that they might not be simple to fix, and don’t
> hesitate to ask on the mailing list if they are a good microproject."
Would that be better, or would it be simpler to gut the whole
paragraph about bug reports? This is "how to pick a microproject",
not "how to pick your main project to work on during your mentoring
program".
Unlike #leftoverbits that sometimes cover trivial but boring style
normalization and easy refactoring of code into helper functions, I
have never seen a bug report on the list that may make a good
microproject. If we were to add a curated list of microproject idea
on the general microproject information page, it probably is better
to remove these mentions of bugreports and #leftoverbits, so that
readers will not get distracted. "Don't hesitate to ask" so that
they may try to tackle more challenging one, if they wish, is a good
thing to say nevertheless.
Thanks.
^ permalink raw reply [relevance 7%]
* Re: [Leftoverbits] exit code clean-up?
2023-08-16 17:04 6% ` [Leftoverbits] exit code clean-up? Junio C Hamano
2023-08-17 9:24 8% ` Oswald Buddenhagen
@ 2023-08-17 5:36 7% ` Jeff King
2023-08-17 16:03 8% ` Junio C Hamano
1 sibling, 1 reply; 200+ results
From: Jeff King @ 2023-08-17 5:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Aug 16, 2023 at 10:04:28AM -0700, Junio C Hamano wrote:
> We could either
>
> * Be more prescriptive and add "EXIT CODES" section to each and
> every document to describe how we fail in the current code.
>
> or
>
> * Describe "In general, 0 is success, non-zero is failure, but some
> commands may signal more than that with its non-zero exit codes"
> in "git help git", and add "EXIT CODES" section to the manual
> page of the commands whose exit codes matter (there are a
> handful, like "git diff --exit-code" that explicitly says "1" is
> the signal that it found difference as opposed to it failing).
>
> I'd prefer if community agrees that we should do the latter, but I
> am OK if the community consensus goes the other way.
I left some notes on upload-pack specifically elsewhere in the thread,
in which I argue that we should definitely not lock ourselves into its
current behavior.
But in the more general sense, yeah, I think that trying to document
specific exit codes for each command is a mistake. It is not just "let's
find which exit codes they use and document them". I suspect it is a
rat's nest of unplanned behaviors that come from unexpected die() calls
deep in the stack. We would not necessarily want to make promises about
what is happening in those, nor do I think it would even be sensible to
find every possible exit.
We _could_ document "128 means something really unexpected happened and
we called die() deep in the code". But even that seems misleading to me,
as we also die() for everyday shallow things (like "the name you gave is
not valid"). The value really means very little in practice, and the
biggest reason not to change it is that we know it doesn't conflict with
any codes that programs _do_ promise are meaningful (like "1" from "diff
--exit-code").
So saying "0 is success, non-zero is failure, and some commands may
document specific codes" is the closest thing to the reality of what we
as developers know and have planned. (Of course another project is not
just to figure out the possible situations/codes but to catalogue and
organize them. But that seems like an order of magnitude more work, if
not several orders).
-Peff
^ permalink raw reply [relevance 7%]
* Re: Trivial enhancement: All commands which require an author should accept --author
@ 2018-09-03 13:18 7% ` Ævar Arnfjörð Bjarmason
0 siblings, 0 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-09-03 13:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Ulrich Gemkow, git
On Thu, Aug 30 2018, Johannes Schindelin wrote:
> Hi Ævar,
>
> On Thu, 30 Aug 2018, Ævar Arnfjörð Bjarmason wrote:
>
>> On Thu, Aug 30 2018, Johannes Schindelin wrote:
>>
>> > On Wed, 29 Aug 2018, Junio C Hamano wrote:
>> >
>> >> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> >>
>> >> > The `stash` command only incidentally requires that the author is set, as
>> >> > it calls `git commit` internally (which records the author). As stashes
>> >> > are intended to be local only, that author information was never meant to
>> >> > be a vital part of the `stash`.
>> >> >
>> >> > I could imagine that an even better enhancement request would ask for `git
>> >> > stash` to work even if `user.name` is not configured.
>> >>
>> >> This would make a good bite-sized microproject, worth marking it as
>> >> #leftoverbits unless somebody is already working on it ;-)
>> >
>> > Right.
>> >
>> > What is our currently-favored approach to this, again? Do we have a
>> > favorite wiki page to list those, or do we have a bug tracker for such
>> > mini-projects?
>> >
>> > Once I know, I will add this, with enough information to get anybody
>> > interested started.
>>
>> I believe the "official" way, such as it is, is you just put
>> #leftoverbits in your E-Mail, then search the list archives,
>> e.g. https://public-inbox.org/git/?q=%23leftoverbits
>>
>> So e.g. I've taken to putting this in my own E-Mails where I spot
>> something I'd like to note as a TODO that I (or someone else) could work
>> on later:
>> https://public-inbox.org/git/?q=%23leftoverbits+f%3Aavarab%40gmail.com
>
> That is a poor way to list the current micro-projects, as it is totally
> non-obvious to the casual interested person which projects are still
> relevant, and which ones have been addressed already.
I don't think this is ideal. To be clear and in reply to both yours and
Junio's E-Mail. I meant "official" in scare quotes in the least official
way possible.
I.e. that you need to search the mailing list archive if you want to see
what these #leftoverbits are, because the full set is stored nowhere
else.
> In a bug tracker, you can at least add a comment stating that something
> has been addressed, or made a lot easier by another topic.
Yeah, a bunch of things suck about it, although I will say at least for
notes I'm leaving for myself I'm using it in a way that I wouldn't
bother to use a bugtracker, so in many cases it's the difference between
offhandendly saying "oh b.t.w. we should fix xyz in way abc
#leftoverbits" and not having a bug at all, because filing a bug /
curating a tracker etc. is a lot more work.
> In a mailing list archive, those mails are immutable, and you cannot
> update squat.
In a lot of bugtrackers you can't update existing comments either, you
make a new one noting some new status. Similarly you can send a new mail
with the correct In-Reply-To.
That doesn't solve all the issues, but helps in many cases.
^ permalink raw reply [relevance 7%]
* Re: [GSoC] Some #leftoverbits for anyone looking for little projects
@ 2019-05-20 23:49 8% ` Ævar Arnfjörð Bjarmason
2019-05-21 4:38 8% ` Matheus Tavares Bernardino
2019-05-28 10:37 8% ` Johannes Schindelin
1 sibling, 1 reply; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2019-05-20 23:49 UTC (permalink / raw)
To: Matheus Tavares
Cc: git, Christian Couder,
Оля Тележная,
Johannes Schindelin
On Mon, May 20 2019, Matheus Tavares wrote:
> Hi, Ævar
>
>> Give "rebase -i" some option so when you "reword" the patch is
>> included in the message.
>>
>> I keep going to the shell because I have no idea what change I'm
>> describing.
>
> I have the same problem, so I wanted to try solving this. The patch
> bellow creates a "rebase.verboseCommit" configuration that includes
> a diff when rewording or squashing. I'd appreciate knowing your thoughts
> on it.
>
> As Christian wisely pointed out to me, though, we can also achieve this
> behavior by setting "commit.verbose" to true. The only "downside" of it
> is that users cannot choose to see the diff only when rebasing. Despite
> of that, if we decide not to go with this patch, what do you think of
> adding a "commit.verbose" entry at git-rebase's man page?
Thanks for working on this. I'd somehow missed the addition of the
commit.verbose option, so the problem I had is 100% solved by it (and
I've turned it on).
I think it's better to just document it with rebase, perhaps rather than
mention that option specifically (but that would also be fine) promise
that we support "commit" options in general.
Do we promise anywhere that interactive rebase is going to run the
"normal" git-commit command. From a quick skimming of the docs it
doesn't seem so, perhaps we should explicitly promise that, and then
test for it if we don't (e.g. by stealing the tests you added).
Aside from that, if this patch is kept I see commit.verbose is a
bool-or-int option, but yours is maybe-bool, so there's no way with
rebase.verboseCommit to turn on the higher level of verbosity. Perhaps
if this option is kept some implementation that just grabs whatever "X"
rebase.verboseCommit=X is set to and passes it as commit.verbase=X down
to git-commit is better, letting it deal with the validation?
> diff --git a/Documentation/config/rebase.txt b/Documentation/config/rebase.txt
> index d98e32d812..ae50b3e05d 100644
> --- a/Documentation/config/rebase.txt
> +++ b/Documentation/config/rebase.txt
> @@ -62,3 +62,8 @@ rebase.rescheduleFailedExec::
> Automatically reschedule `exec` commands that failed. This only makes
> sense in interactive mode (or when an `--exec` option was provided).
> This is the same as specifying the `--reschedule-failed-exec` option.
> +
> +rebase.verboseCommit::
> + When rewording or squashing commits, during an interactive rebase, show
> + the commits' diff to help describe the modifications they bring. False
> + by default.
> diff --git a/sequencer.c b/sequencer.c
> index f88a97fb10..1596fc4cd0 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -914,6 +914,7 @@ N_("you have staged changes in your working tree\n"
> #define CLEANUP_MSG (1<<3)
> #define VERIFY_MSG (1<<4)
> #define CREATE_ROOT_COMMIT (1<<5)
> +#define VERBOSE_COMMIT (1<<6)
>
> static int run_command_silent_on_success(struct child_process *cmd)
> {
> @@ -1007,6 +1008,8 @@ static int run_git_commit(struct repository *r,
> argv_array_push(&cmd.args, "-n");
> if ((flags & AMEND_MSG))
> argv_array_push(&cmd.args, "--amend");
> + if ((flags & VERBOSE_COMMIT))
> + argv_array_push(&cmd.args, "-v");
> if (opts->gpg_sign)
> argv_array_pushf(&cmd.args, "-S%s", opts->gpg_sign);
> if (defmsg)
> @@ -1782,7 +1785,7 @@ static int do_pick_commit(struct repository *r,
> char *author = NULL;
> struct commit_message msg = { NULL, NULL, NULL, NULL };
> struct strbuf msgbuf = STRBUF_INIT;
> - int res, unborn = 0, allow;
> + int res, unborn = 0, allow, verbose_commit = 0;
>
> if (opts->no_commit) {
> /*
> @@ -1843,6 +1846,9 @@ static int do_pick_commit(struct repository *r,
> return error(_("cannot get commit message for %s"),
> oid_to_hex(&commit->object.oid));
>
> + if (git_config_get_maybe_bool("rebase.verbosecommit", &verbose_commit) < 0)
> + warning("Invalid value for rebase.verboseCommit. Using 'false' instead.");
> +
> if (opts->allow_ff && !is_fixup(command) &&
> ((parent && oideq(&parent->object.oid, &head)) ||
> (!parent && unborn))) {
> @@ -1853,6 +1859,8 @@ static int do_pick_commit(struct repository *r,
> if (res || command != TODO_REWORD)
> goto leave;
> flags |= EDIT_MSG | AMEND_MSG | VERIFY_MSG;
> + if (verbose_commit)
> + flags |= VERBOSE_COMMIT;
> msg_file = NULL;
> goto fast_forward_edit;
> }
> @@ -1909,12 +1917,17 @@ static int do_pick_commit(struct repository *r,
> author = get_author(msg.message);
> }
>
> - if (command == TODO_REWORD)
> + if (command == TODO_REWORD) {
> flags |= EDIT_MSG | VERIFY_MSG;
> + if (verbose_commit)
> + flags |= VERBOSE_COMMIT;
> + }
> else if (is_fixup(command)) {
> if (update_squash_messages(r, command, commit, opts))
> return -1;
> flags |= AMEND_MSG;
> + if (verbose_commit)
> + flags |= VERBOSE_COMMIT;
> if (!final_fixup)
> msg_file = rebase_path_squash_msg();
> else if (file_exists(rebase_path_fixup_msg())) {
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
> index 1723e1a858..9b410d31e2 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -1477,4 +1477,60 @@ test_expect_success 'valid author header when author contains single quote' '
> test_cmp expected actual
> '
>
> +write_script "reword-and-check-for-diff" <<\EOF &&
> +case "$1" in
> +*/git-rebase-todo)
> + sed s/pick/reword/ "$1" > "$1.tmp"
> + mv -f "$1.tmp" "$1"
> + ;;
> +*)
> + grep '^diff --git' "$1" >has-diff
> + ;;
> +esac
> +exit 0
> +EOF
> +
> +test_expect_success 'rebase -i does not show diff by default when rewording' '
> + rebase_setup_and_clean no-verbose-commit-reword &&
> + test_set_editor "$PWD/reword-and-check-for-diff" &&
> + git rebase -i HEAD~1 &&
> + test_line_count = 0 has-diff
> +'
> +
> +test_expect_success 'rebase -i respects rebase.verboseCommit when rewording' '
> + rebase_setup_and_clean verbose-commit-reword &&
> + test_config rebase.verboseCommit true &&
> + test_set_editor "$PWD/reword-and-check-for-diff" &&
> + git rebase -i HEAD~1 &&
> + test_line_count -gt 0 has-diff
> +'
> +
> +write_script "squash-and-check-for-diff" <<\EOF &&
> +case "$1" in
> +*/git-rebase-todo)
> + sed "s/pick \([0-9a-f]*\) E/squash \1 E/" "$1" > "$1.tmp"
> + mv -f "$1.tmp" "$1"
> + ;;
> +*)
> + grep '^diff --git' "$1" >has-diff
> + ;;
> +esac
> +exit 0
> +EOF
> +
> +test_expect_success 'rebase -i does not show diff by default when squashing' '
> + rebase_setup_and_clean no-verbose-commit-squash &&
> + test_set_editor "$PWD/squash-and-check-for-diff" &&
> + git rebase -i HEAD~2 &&
> + test_line_count = 0 has-diff
> +'
> +
> +test_expect_success 'rebase -i respects rebase.verboseCommit when squashing' '
> + rebase_setup_and_clean verbose-commit-squash &&
> + test_config rebase.verboseCommit true &&
> + test_set_editor "$PWD/squash-and-check-for-diff" &&
> + git rebase -i HEAD~2 &&
> + test_line_count -gt 0 has-diff
> +'
> +
> test_done
^ permalink raw reply [relevance 8%]
* Re: Students projects: looking for small and medium project ideas
@ 2019-02-26 20:14 8% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2019-02-26 20:14 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Fabio Aiuto, Matthieu Moy, git
Hi,
On Tue, 26 Feb 2019, Matthieu Moy wrote:
> Fabio Aiuto <polinice83@libero.it> writes:
>
> > Hi Matthieu and to all developers,
> > I'm Fabio, no more a student and I'm brand new in community
> > development. I joined the git mailing-list about two weeks ago and I'm
> > looking for some first fix or tasks. I apologize myself in advance for
> > my little know of the subject. Hope to have some useful information to
> > start workin'.
>
> My advice would be to "scratch your own itch", i.e. find something you
> dislike about Git, and try to improve that. It's hard to find the
> motivation (and time) to contribute in a purely un-interested way, but
> once you start getting the benefits of your own patches in the way _you_
> use Git, it's really rewarding !
There are also occasional bug reports on the Git mailing list, like this
one about `git grep`:
https://public-inbox.org/git/CAGHpTB+fQccqR8SF2_dS3itboKd79238KCFRe4-3PZz6bpr3iQ@mail.gmail.com/T/#u
You can also search the Git mailing list archive for `#leftoverbits`:
https://public-inbox.org/git/?q=%23leftoverbits
(Of course, caveat emptor, some of those #leftoverbits might have been
addressed in the meantime, others might not reproduce for you, yet others
might not be considered bugs or worth fixing...)
Ciao,
Johannes
^ permalink raw reply [relevance 8%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-29 18:30 14% Is origin/HEAD only being created on clone a bug? #leftoverbits Ævar Arnfjörð Bjarmason
@ 2018-05-29 19:17 8% ` Brandon Williams
2018-05-30 1:24 6% ` Junio C Hamano
1 sibling, 0 replies; 200+ results
From: Brandon Williams @ 2018-05-29 19:17 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git List, Johannes Schindelin
On 05/29, Ævar Arnfjörð Bjarmason wrote:
> Here's some more #leftoverbits where we have a clone/fetch feature
> discrepancy and where clone is magical in ways that "fetch" isn't.
>
> If you make an initial commit and push to a remote repo "origin", you
> don't get a remote origin/HEAD reference, and a "fetch" won't create it
> either.
>
> You will get it if you subseuqently "clone" the repo, but not if you use
> "git init / remote add / fetch / git checkout -t" which should otherwise
> be equivalent.
>
> If you push to "master" (or whatever HEAD is) from the clone the
> origin/HEAD will be updated accordingly, but from the repo you pushed
> from & the one you did init+fetch instead of clone you'll never see it.
>
> Some code spelunking reveals remote_head_points_at, guess_remote_head()
> etc. in builtin/clone.c. I.e. this is special-cased as part of the
> "clone".
>
> Can anyone thing of a reason for why this shouldn't be fixed as a bug?
> I've tried searching the archives but "origin/HEAD" comes up with too
> many
> results. https://public-inbox.org/git/alpine.LSU.1.00.0803020556380.22527@racer.site/#t
> seems to be the patch that initially added it, but it is not discussed
> why this should be a clone-only special case that doesn't apply to
> "fetch".
I believe the issue has to deal with how symrefs are handled. I don't
think any of the fetch code path does anything special with symrefs.
Symref info does get sent over the wire for the HEAD symref but i think
its just ignored. You'll see updates for origin/HEAD when you
subsequently fetch most likely because its recorded as a symref locally
which points at origin/master. This means that when you fetch
origin/master, origin/HEAD will also but updated just because its
locally a pointer to origin/master.
With that said, yes we should probably fix this issue with fetch because
I added symref support to protocol v2 so now symref information for refs
other than HEAD can be sent across the wire but the client just throws
that info away at the moment.
--
Brandon Williams
^ permalink raw reply [relevance 8%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-30 2:46 8% ` Junio C Hamano
@ 2018-06-01 6:51 8% ` Jeff King
0 siblings, 0 replies; 200+ results
From: Jeff King @ 2018-06-01 6:51 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð Bjarmason, Git List,
Johannes Schindelin
On Wed, May 30, 2018 at 11:46:16AM +0900, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > - When we fetch from a remote that has refs/remotes/$name/HEAD, and
> > if the protocol notices that their HEAD today is pointing to a
> > branch different from what our side has, should we repoint ours
> > to match?
> >
> > I am leaning against doing this, but mostly out of superstition.
> > ...
> > interested in". But once fetch starts messing with where
> > origin/HEAD points at, that would no longer be the case, which is
> > why I am against doing something magical like that.
>
> Well, I shouldn't say "I am against" on the last line; rather, "I
> feel uneasy".
I didn't bother to dig up the past discussions, but I am pretty sure we
intentionally avoided updating origin/HEAD without an explicit action
from the user. Because what the other side considers "the default
branch" and what you consider "the default branch" when dealing with the
remote are not necessarily the same thing. If we auto-adjust the symref
on fetch, we might be undoing the user's previous "git remote set-head"
operation.
I don't have any real problem with creating it if it _doesn't_ exist,
though. (I think ideally it would get created by "remote add", but that
command does not always talk to the remote, so this kind of
delayed-create is probably the best we can do).
-Peff
^ permalink raw reply [relevance 8%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-30 1:24 6% ` Junio C Hamano
@ 2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
2018-06-01 1:32 8% ` Junio C Hamano
2018-05-30 2:46 8% ` Junio C Hamano
1 sibling, 1 reply; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-05-31 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Johannes Schindelin
On Wed, May 30 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> If you make an initial commit and push to a remote repo "origin", you
>> don't get a remote origin/HEAD reference, and a "fetch" won't create it
>> either.
>> ...
>> Some code spelunking reveals remote_head_points_at, guess_remote_head()
>> etc. in builtin/clone.c. I.e. this is special-cased as part of the
>> "clone".
>
> Correct. Originally, there was *no* way in the protocol to carry
> the information, so the code always had to guess. The point of
> setting origin/HEAD was mostly so that you can say "log origin.."
> and rely on it getting dwimmed down to "refs/remotes/%s/HEAD..",
> and it wasn't a common practice to interact with multiple remotes
> with remote tracking branches (integrator interacting with dozens
> of remotes, responding to pull requests using explicit URL but
> without configured remotes was not uncommon), so it was sufficient
> for "git clone" to create it, and "git remote add" did not exist
> back then anyway.
>
> There are two aspects in my answer to your question.
>
> - If we create additional remote (that is, other than the one we
> get when we create a repository via "clone", so if your "origin"
> is from "git init there && cd there && git remote add origin", it
> does count in this category), should we get a remote-tracking
> symref $name/HEAD so that we can say "log $name.."?
>
> We absolutely should. We (eh, rather, those who added "remote
> add"; this was not my itch and I am using "royal we" in this
> sentence) just did not bother to and I think it is a bug that you
> cannot say "log $name.." Of course, it is just a "git symbolic-ref"
> away to make it possible locally, so it is understandable if
> "remote add" did not bother to.
>
> - When we fetch from a remote that has refs/remotes/$name/HEAD, and
> if the protocol notices that their HEAD today is pointing to a
> branch different from what our side has, should we repoint ours
> to match?
>
> I am leaning against doing this, but mostly out of superstition.
> Namely, I feel uneasy about the fact that the meaning of "log
> ..origin" changes across a fetch in this sequence:
>
> log ..origin && fetch origin && log ..origin
>
> Without repointing origin/HEAD, two occurrences of "log ..origin"
> both means "how much ahead the primary branch we have been
> interested in from this remote is, relative to our effort?".
> Even though we fully expect that two "log ..origin" would report
> different results (after all, that is the whole point of doing
> another one after "fetch" in such a sequence like this example),
> our question is about the same "primary branch we have been
> interested in". But once fetch starts messing with where
> origin/HEAD points at, that would no longer be the case, which is
> why I am against doing something magical like that.
We already have to deal with this special case of origin/HEAD being
re-pointed in a repository that we "clone", so we would just do whatever
happens to a repository that's cloned.
I.e. the "clone" sets the origin/HEAD up as a one-off, and then keeps
updating it on the basis of updating existing refs. We'd similarly set
it up as a one-off if we ever "fetch" and notice that the ref doesn't
exist yet, and then we'd update it in the same way we update it now.
So this seems like a non-issue to me as far as me coming up with some
patch to one-off write the origin/HEAD on the first "fetch", or am I
missing something?
^ permalink raw reply [relevance 8%]
* Re: Pain points in Git's patch flow
@ 2021-04-14 8:02 8% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2021-04-14 8:02 UTC (permalink / raw)
To: Bagas Sanjaya
Cc: Jonathan Nieder, Raxel Gutierrez, mricon, patchwork, Taylor Blau,
Emily Shaffer, Git Users
Bagas Sanjaya <bagasdotme@gmail.com> writes:
> There is no lists of "beginner-friendly" issues that can be worked on by
> new contributors. They had to search this ML archive for bug report
> issues and determine themselves which are beginner-friendly.
Yeah, looking for "#leftoverbits" or "low-hanging" on the list
archive is often cited as a way, and it does seem easy enough to
do. You go to https://lore.kernel.org/git/, type "leftoverbits"
or "low-hanging" in the text input and press SEARCH.
But that is only half of the story.
Anybody can throw random ideas and label them "#leftoverbits" or
"low-hanging fruit", but some of these ideas might turn out to be
ill-conceived or outright nonsense. Limiting search to the
utterances by those with known good taste does help, but as a
newbie, you do not know who these people with good taste are.
It might help to have a curated list of starter tasks, but I suspect
that they tend to get depleted rather quickly---by definition the
ones on the list are easy to do and there is nothing to stop an
eager newbie from eating all of them in one sitting X-(.
So, I dunno. We seem to suffer from the same lack of good starter
tasks before each GSoC begins.
^ permalink raw reply [relevance 8%]
* [PATCH 0/2] dl/format-patch-notes-config-fixup: clean up some leftoverbits
@ 2019-12-12 0:49 8% Denton Liu
0 siblings, 0 replies; 200+ results
From: Denton Liu @ 2019-12-12 0:49 UTC (permalink / raw)
To: Git Mailing List; +Cc: Elijah Newren, Eric Sunshine, Philip Oakley
This series gives 'dl/format-patch-notes-config-fixup' a few polishing
touches. First of all, we document the behaviour of multiple
`format.notes` configuration variables so that end-users are aware of
the change.
Also, Eric Sunshine suggested some cleanup in the previous round, like
breaking the monolithic set_display_notes() into multiple smaller
functions and not using the return value of the function to assign to
`show_notes`.
Denton Liu (2):
config/format.txt: clarify behavior of multiple format.notes
notes: break set_display_notes() into smaller functions
Documentation/config/format.txt | 18 +++++++++++++-
builtin/log.c | 7 +++++-
notes.c | 43 ++++++++++++++++++---------------
notes.h | 19 +++++++++------
revision.c | 6 ++---
revision.h | 2 +-
6 files changed, 62 insertions(+), 33 deletions(-)
--
2.24.0.627.geba02921db
^ permalink raw reply [relevance 8%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-30 1:24 6% ` Junio C Hamano
2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
@ 2018-05-30 2:46 8% ` Junio C Hamano
2018-06-01 6:51 8% ` Jeff King
1 sibling, 1 reply; 200+ results
From: Junio C Hamano @ 2018-05-30 2:46 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git List, Johannes Schindelin
Junio C Hamano <gitster@pobox.com> writes:
> - When we fetch from a remote that has refs/remotes/$name/HEAD, and
> if the protocol notices that their HEAD today is pointing to a
> branch different from what our side has, should we repoint ours
> to match?
>
> I am leaning against doing this, but mostly out of superstition.
> ...
> interested in". But once fetch starts messing with where
> origin/HEAD points at, that would no longer be the case, which is
> why I am against doing something magical like that.
Well, I shouldn't say "I am against" on the last line; rather, "I
feel uneasy".
^ permalink raw reply [relevance 8%]
* Re: Is origin/HEAD only being created on clone a bug? #leftoverbits
2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
@ 2018-06-01 1:32 8% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2018-06-01 1:32 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git List, Johannes Schindelin
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> We already have to deal with this special case of origin/HEAD
> being re-pointed in a repository that we "clone", so we would just
> do whatever happens to a repository that's cloned.
OK. Not visiting that issue while we discuss this "origin/HEAD is
useful, so create it even for non-initial-clone case" topic makes it
simpler to discuss.
^ permalink raw reply [relevance 8%]
* Re: [GSoC] Some #leftoverbits for anyone looking for little projects
2019-05-20 23:49 8% ` Ævar Arnfjörð Bjarmason
@ 2019-05-21 4:38 8% ` Matheus Tavares Bernardino
0 siblings, 0 replies; 200+ results
From: Matheus Tavares Bernardino @ 2019-05-21 4:38 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Christian Couder,
Оля Тележная,
Johannes Schindelin
On Mon, May 20, 2019 at 8:49 PM Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
>
>
> On Mon, May 20 2019, Matheus Tavares wrote:
>
> > Hi, Ævar
> >
> >> Give "rebase -i" some option so when you "reword" the patch is
> >> included in the message.
> >>
> >> I keep going to the shell because I have no idea what change I'm
> >> describing.
> >
> > I have the same problem, so I wanted to try solving this. The patch
> > bellow creates a "rebase.verboseCommit" configuration that includes
> > a diff when rewording or squashing. I'd appreciate knowing your thoughts
> > on it.
> >
> > As Christian wisely pointed out to me, though, we can also achieve this
> > behavior by setting "commit.verbose" to true. The only "downside" of it
> > is that users cannot choose to see the diff only when rebasing. Despite
> > of that, if we decide not to go with this patch, what do you think of
> > adding a "commit.verbose" entry at git-rebase's man page?
>
> Thanks for working on this. I'd somehow missed the addition of the
> commit.verbose option, so the problem I had is 100% solved by it (and
> I've turned it on).
>
> I think it's better to just document it with rebase, perhaps rather than
> mention that option specifically (but that would also be fine) promise
> that we support "commit" options in general.
Indeed, it seems to be the right way to go.
> Do we promise anywhere that interactive rebase is going to run the
> "normal" git-commit command. From a quick skimming of the docs it
> doesn't seem so, perhaps we should explicitly promise that, and then
> test for it if we don't (e.g. by stealing the tests you added).
Ok, sounds good to me. In order to avoid duplicate tests, is it OK to
assume that if one commit configuration is being respected by rebase,
then all will be? Or should a patch adding such a promise include
rebase tests for all commit.* configurations?
^ permalink raw reply [relevance 8%]
* Re: [GSoC] Some #leftoverbits for anyone looking for little projects
2019-05-20 23:49 8% ` Ævar Arnfjörð Bjarmason
@ 2019-05-28 10:37 8% ` Johannes Schindelin
2019-05-28 17:37 8% ` Matheus Tavares Bernardino
1 sibling, 1 reply; 200+ results
From: Johannes Schindelin @ 2019-05-28 10:37 UTC (permalink / raw)
To: Matheus Tavares
Cc: avarab, git, Christian Couder,
Оля Тележная
Hi Matheus,
On Mon, 20 May 2019, Matheus Tavares wrote:
> > Give "rebase -i" some option so when you "reword" the patch is
> > included in the message.
> >
> > I keep going to the shell because I have no idea what change I'm
> > describing.
>
> I have the same problem, so I wanted to try solving this. The patch
> bellow creates a "rebase.verboseCommit" configuration that includes a
> diff when rewording or squashing. I'd appreciate knowing your thoughts
> on it.
>
> As Christian wisely pointed out to me, though, we can also achieve this
> behavior by setting "commit.verbose" to true. The only "downside" of it
> is that users cannot choose to see the diff only when rebasing.
You could of course add an alias like
[alias]
myrebase = -c commit.verbose=true rebase
which *should* work.
However, I am actually slightly in favor of your patch because it *does*
make it more convenient to have this on during rebases only.
Ciao,
Dscho
^ permalink raw reply [relevance 8%]
* Re: [GSoC] Some #leftoverbits for anyone looking for little projects
2019-05-28 10:37 8% ` Johannes Schindelin
@ 2019-05-28 17:37 8% ` Matheus Tavares Bernardino
2019-05-28 18:16 8% ` Johannes Schindelin
0 siblings, 1 reply; 200+ results
From: Matheus Tavares Bernardino @ 2019-05-28 17:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ævar Arnfjörð Bjarmason, git, Christian Couder,
Оля Тележная
On Tue, May 28, 2019 at 7:37 AM Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>
> Hi Matheus,
>
> On Mon, 20 May 2019, Matheus Tavares wrote:
>
> > > Give "rebase -i" some option so when you "reword" the patch is
> > > included in the message.
> > >
> > > I keep going to the shell because I have no idea what change I'm
> > > describing.
> >
> > I have the same problem, so I wanted to try solving this. The patch
> > bellow creates a "rebase.verboseCommit" configuration that includes a
> > diff when rewording or squashing. I'd appreciate knowing your thoughts
> > on it.
> >
> > As Christian wisely pointed out to me, though, we can also achieve this
> > behavior by setting "commit.verbose" to true. The only "downside" of it
> > is that users cannot choose to see the diff only when rebasing.
>
> You could of course add an alias like
>
> [alias]
> myrebase = -c commit.verbose=true rebase
Hmm, I didn't know about `alias`. Thanks for the information.
> which *should* work.
>
> However, I am actually slightly in favor of your patch because it *does*
> make it more convenient to have this on during rebases only.
Another option we were discussing is to document that rebase obeys all
commit.* options, instead of adding the rebase.verboseCommit config.
Yes, this way we won't be able to toggle diff for rebase only, but I'm
not sure if that's something users would want to do...
> Ciao,
> Dscho
^ permalink raw reply [relevance 8%]
* Re: [GSoC] Some #leftoverbits for anyone looking for little projects
2019-05-28 17:37 8% ` Matheus Tavares Bernardino
@ 2019-05-28 18:16 8% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2019-05-28 18:16 UTC (permalink / raw)
To: Matheus Tavares Bernardino
Cc: Ævar Arnfjörð Bjarmason, git, Christian Couder,
Оля Тележная
Hi Matheus,
On Tue, 28 May 2019, Matheus Tavares Bernardino wrote:
> On Tue, May 28, 2019 at 7:37 AM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Mon, 20 May 2019, Matheus Tavares wrote:
> >
> > > > Give "rebase -i" some option so when you "reword" the patch is
> > > > included in the message.
> > > >
> > > > I keep going to the shell because I have no idea what change I'm
> > > > describing.
> > >
> > > I have the same problem, so I wanted to try solving this. The patch
> > > bellow creates a "rebase.verboseCommit" configuration that includes a
> > > diff when rewording or squashing. I'd appreciate knowing your thoughts
> > > on it.
> > >
> > > As Christian wisely pointed out to me, though, we can also achieve this
> > > behavior by setting "commit.verbose" to true. The only "downside" of it
> > > is that users cannot choose to see the diff only when rebasing.
> >
> > You could of course add an alias like
> >
> > [alias]
> > myrebase = -c commit.verbose=true rebase
>
> Hmm, I didn't know about `alias`. Thanks for the information.
>
> > which *should* work.
> >
> > However, I am actually slightly in favor of your patch because it *does*
> > make it more convenient to have this on during rebases only.
>
> Another option we were discussing is to document that rebase obeys all
> commit.* options, instead of adding the rebase.verboseCommit config.
> Yes, this way we won't be able to toggle diff for rebase only, but I'm
> not sure if that's something users would want to do...
It is rather unintuitive that the `commit.*` options apply to a rebase.
Sure, you could document it. But realistically, how many users will read
it? Yes, I agree, that is a very low percentage.
Also: you yourself mentioned the rather convincing use case of `reword`.
Personally, I never really thought that I'd need `commit.verbose`. But
your report made me think that I could use it *just* for `reword`, too.
So now you already have two active Git contributors wishing for that
feature.
Ciao,
Dscho
^ permalink raw reply [relevance 8%]
* Re: [GSoC] Some #leftoverbits for anyone looking for little projects
2018-03-17 21:20 6% [GSoC] Some #leftoverbits for anyone looking for little projects Ævar Arnfjörð Bjarmason
@ 2019-05-29 9:38 8% ` Johannes Schindelin
2019-05-29 9:40 8% ` Johannes Schindelin
1 sibling, 1 reply; 200+ results
From: Johannes Schindelin @ 2019-05-29 9:38 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]
Hi Ævar,
On Sat, 17 Mar 2018, Ævar Arnfjörð Bjarmason wrote:
> In lieu of sending a PR to https://git.github.io/SoC-2018-Microprojects/
> I thought I'd list a few more suggestions, and hopefully others will
> chime in.
I am in the same camp, and figured that GitGitGadget (which *already*
augments the Git mailing list-centric workflow via GitHub's convenient UI)
would make for a fine location for these small left-over bits. So I added
them to https://github.com/gitgitgadget/git/issues/234 (except the
"git-unpack-*" idea, as I think that should be done as a test helper
instead, and it should be done in the context of a new test case that
actually needs this).
Ciao,
Dscho
^ permalink raw reply [relevance 8%]
* Re: [GSoC] Some #leftoverbits for anyone looking for little projects
2019-05-29 9:38 8% ` Johannes Schindelin
@ 2019-05-29 9:40 8% ` Johannes Schindelin
0 siblings, 0 replies; 200+ results
From: Johannes Schindelin @ 2019-05-29 9:40 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
Hi,
On Wed, 29 May 2019, Johannes Schindelin wrote:
> On Sat, 17 Mar 2018, Ævar Arnfjörð Bjarmason wrote:
>
> > In lieu of sending a PR to https://git.github.io/SoC-2018-Microprojects/
> > I thought I'd list a few more suggestions, and hopefully others will
> > chime in.
>
> I am in the same camp, and figured that GitGitGadget (which *already*
> augments the Git mailing list-centric workflow via GitHub's convenient UI)
> would make for a fine location for these small left-over bits. So I added
> them to https://github.com/gitgitgadget/git/issues/234 (except the
Of course, I added them to https://github.com/gitgitgadget/git/issues/,
with #234 being the last from this email.
Ciao,
Dscho
> "git-unpack-*" idea, as I think that should be done as a test helper
> instead, and it should be done in the context of a new test case that
> actually needs this).
>
> Ciao,
> Dscho
^ permalink raw reply [relevance 8%]
* Re: [Leftoverbits] exit code clean-up?
2023-08-16 17:04 6% ` [Leftoverbits] exit code clean-up? Junio C Hamano
@ 2023-08-17 9:24 8% ` Oswald Buddenhagen
2023-08-17 5:36 7% ` Jeff King
1 sibling, 0 replies; 200+ results
From: Oswald Buddenhagen @ 2023-08-17 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wed, Aug 16, 2023 at 10:04:28AM -0700, Junio C Hamano wrote:
>"git help git" does not have "EXIT CODES" section, and it is assumed
>that the "common sense" of older generation [...] that exiting with 0
>is success and non-zero is failure is shared among its users, which
>might not be warranted these days.
>
well, that's actually a standard (exit(3) has things to say about it),
and given how shell scripts treat exit codes, there is no wiggle room
here. just about every shell intro tutorial explains it.
>We could either
>
> * Be more prescriptive and add "EXIT CODES" section to each and
> every document to describe how we fail in the current code.
>
>or
>
> * Describe "In general, 0 is success, non-zero is failure, but some
> commands may signal more than that with its non-zero exit codes"
> in "git help git", and add "EXIT CODES" section to the manual
> page of the commands whose exit codes matter (there are a
> handful, like "git diff --exit-code" that explicitly says "1" is
> the signal that it found difference as opposed to it failing).
>
i'd go with the second, with some minor modifications:
- 1 is the by far most common non-zero error code (and it matches
EXIT_FAILURE on all relevant systems), so it's ok to state that. it
may be wise to actually check that commands don't deviate from it
needlessly.
- the canonical name of the section appears to be "EXIT STATUS"
regards
^ permalink raw reply [relevance 8%]
* Re: [Leftoverbits] exit code clean-up?
2023-08-17 5:36 7% ` Jeff King
@ 2023-08-17 16:03 8% ` Junio C Hamano
0 siblings, 0 replies; 200+ results
From: Junio C Hamano @ 2023-08-17 16:03 UTC (permalink / raw)
To: Jeff King; +Cc: git
Jeff King <peff@peff.net> writes:
> We _could_ document "128 means something really unexpected happened and
> we called die() deep in the code". But even that seems misleading to me,
> as we also die() for everyday shallow things (like "the name you gave is
> not valid"). The value really means very little in practice, and the
> biggest reason not to change it is that we know it doesn't conflict with
> any codes that programs _do_ promise are meaningful (like "1" from "diff
> --exit-code").
Yeah, I forgot to say that we should mention 128 to tell the users
that it is a meaningless positive number chosen to signal a general
error and it is set sufficiently high so that it won't conflict with
a range of low positive numbers certain subcommands use to convey
specific meaning in their errors. And you said it nicely above.
With that clarified, my vote still goes to the "do not overly tied
to what the current implementation happens to do" route.
Thanks.
^ permalink raw reply [relevance 8%]
* [PATCH] patch reply
@ 2017-10-17 3:47 10% ` Thais Diniz
2017-10-17 3:58 6% ` [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option thais braz
1 sibling, 0 replies; 200+ results
From: Thais Diniz @ 2017-10-17 3:47 UTC (permalink / raw)
To: gitster
Cc: christian.couder, git, marius.paliga, peff, sbeller,
thais.dinizbraz
From: Thais Diniz Braz <thais.dinizbraz@gmail.com>
---
emailReply | 4 ++++
1 file changed, 4 insertions(+)
create mode 100644 emailReply
diff --git a/emailReply b/emailReply
new file mode 100644
index 000000000..2d591b55b
--- /dev/null
+++ b/emailReply
@@ -0,0 +1,4 @@
+Just to clarify I did not see Marius patch.
+Did see Marius' comment saying he would look it in the leftoverbits list,
+but since i didn't see any patch i thought i could work on it and did so based on Stephan's comment
+(which i suppose Mario also did and that is why the code resulted to be similar).
--
2.15.0.rc0.39.g2f0e14e.dirty
^ permalink raw reply related [relevance 10%]
* Is origin/HEAD only being created on clone a bug? #leftoverbits
@ 2018-05-29 18:30 14% Ævar Arnfjörð Bjarmason
2018-05-29 19:17 8% ` Brandon Williams
2018-05-30 1:24 6% ` Junio C Hamano
0 siblings, 2 replies; 200+ results
From: Ævar Arnfjörð Bjarmason @ 2018-05-29 18:30 UTC (permalink / raw)
To: Git List; +Cc: Johannes Schindelin
Here's some more #leftoverbits where we have a clone/fetch feature
discrepancy and where clone is magical in ways that "fetch" isn't.
If you make an initial commit and push to a remote repo "origin", you
don't get a remote origin/HEAD reference, and a "fetch" won't create it
either.
You will get it if you subseuqently "clone" the repo, but not if you use
"git init / remote add / fetch / git checkout -t" which should otherwise
be equivalent.
If you push to "master" (or whatever HEAD is) from the clone the
origin/HEAD will be updated accordingly, but from the repo you pushed
from & the one you did init+fetch instead of clone you'll never see it.
Some code spelunking reveals remote_head_points_at, guess_remote_head()
etc. in builtin/clone.c. I.e. this is special-cased as part of the
"clone".
Can anyone thing of a reason for why this shouldn't be fixed as a bug?
I've tried searching the archives but "origin/HEAD" comes up with too
many
results. https://public-inbox.org/git/alpine.LSU.1.00.0803020556380.22527@racer.site/#t
seems to be the patch that initially added it, but it is not discussed
why this should be a clone-only special case that doesn't apply to
"fetch".
^ permalink raw reply [relevance 14%]
Results 1-200 of ~500 next [<= 6%] | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2018-05-29 18:30 14% Is origin/HEAD only being created on clone a bug? #leftoverbits Ævar Arnfjörð Bjarmason
2018-05-29 19:17 8% ` Brandon Williams
2018-05-30 1:24 6% ` Junio C Hamano
2018-05-31 7:42 8% ` Ævar Arnfjörð Bjarmason
2018-06-01 1:32 8% ` Junio C Hamano
2018-05-30 2:46 8% ` Junio C Hamano
2018-06-01 6:51 8% ` Jeff King
2019-12-12 0:49 8% [PATCH 0/2] dl/format-patch-notes-config-fixup: clean up some leftoverbits Denton Liu
[not found] <CAL21Bm=zQ2ADTOSVk5kL1q=VyLV91J+VbsLLFbSdgPxeg3FW1g@mail.gmail.com>
2017-09-21 5:30 7% ` My first contribution. Outreachy Jeff King
[not found] <CAL21Bm=e9C4ANTsc4n1BG3xqjCJmORDSPcS5QEXYKUkK3cAH6w@mail.gmail.com>
2017-09-19 8:05 7% ` My first contribution Christian Couder
2017-10-03 21:14 6% [PATCH] branch: reset instead of release a strbuf Stefan Beller
[not found] <https://public-inbox.org/git/20180813171749.10481-1-newren@gmail.com/>
2018-08-15 17:54 ` [PATCHv4 0/6] Add missing includes and forward declares Elijah Newren
2018-08-15 17:54 ` [PATCHv4 6/6] Remove forward declaration of an enum Elijah Newren
2018-08-15 20:40 6% ` Jonathan Nieder
2018-06-24 8:56 6% [BUG] url schemes should be case-insensitive Jeff King
2018-06-25 18:19 6% ` Junio C Hamano
2024-03-18 12:47 6% [PATCH 0/2] git-compat-util: move convert_slashes from compat/mingw.h and rename it Mohit Marathe via GitGitGadget
2018-03-17 21:20 6% [GSoC] Some #leftoverbits for anyone looking for little projects Ævar Arnfjörð Bjarmason
2019-05-29 9:38 8% ` Johannes Schindelin
2019-05-29 9:40 8% ` Johannes Schindelin
2019-05-20 18:23 ` Matheus Tavares
2019-05-20 23:49 8% ` Ævar Arnfjörð Bjarmason
2019-05-21 4:38 8% ` Matheus Tavares Bernardino
2019-05-28 10:37 8% ` Johannes Schindelin
2019-05-28 17:37 8% ` Matheus Tavares Bernardino
2019-05-28 18:16 8% ` Johannes Schindelin
2019-05-20 21:53 6% [PATCH 0/3] hash-object doc: small fixes Ævar Arnfjörð Bjarmason
[not found] <aeb24944-17af-cf53-93f4-e727f9fe9988@theori.io>
[not found] ` <xmqq4km4lppy.fsf@gitster.c.googlers.com>
2020-11-06 17:02 ` [PATCH v2] diff: handle NULL filespecs in run_external_diff Jinoh Kang
2020-11-06 17:14 ` [PATCH v3] diff: make diff_free_filespec_data accept NULL Jinoh Kang
2020-11-10 14:06 ` [PATCH v4] " Jinoh Kang
2020-11-10 15:38 ` Johannes Schindelin
2020-11-11 12:30 ` Jinoh Kang
2020-11-11 16:28 6% ` Johannes Schindelin
2022-07-14 17:44 6% [PATCH 0/3] doc: unify config info on some cmds Matheus Tavares
[not found] <c74c8c386f2c2d8b6cebd4addf925d0121986067.1502114584.git.nicolas@morey-chaisemartin.com>
2017-08-07 14:04 ` [PATCH 4/4] imap-send: use curl by default Nicolas Morey-Chaisemartin
2017-08-07 20:01 ` Jeff King
2017-09-12 6:46 6% ` Junio C Hamano
2021-10-14 0:47 6% [PATCH 0/2] test-lib.sh: add BAIL_OUT function, use it for SANITIZE=leak Ævar Arnfjörð Bjarmason
2021-03-13 18:35 Regarding GSoC Project 2021 Shubham Verma
2021-03-14 1:26 6% ` ZheNing Hu
2023-10-03 20:25 [PATCH 0/10] some commit-graph leak fixes Jeff King
2023-10-03 20:30 ` [PATCH 08/10] commit-graph: free write-context entries before overwriting Jeff King
2023-10-05 17:51 6% ` Taylor Blau
2021-05-13 3:38 git-sh-prompt: bash: GIT_PS1_COMPRESSSPARSESTATE: unbound variable Christoph Anton Mitterer
2021-05-13 4:03 ` Junio C Hamano
2021-05-13 4:13 ` Junio C Hamano
2021-05-13 4:53 ` Elijah Newren
2021-05-13 5:01 ` Junio C Hamano
2021-05-19 17:56 ` Christoph Anton Mitterer
2021-05-19 23:29 ` Junio C Hamano
2021-05-20 0:09 6% ` Elijah Newren
2017-09-07 18:13 "git shortlog -sn --follow -- <path>" counts all commits to entire repo Валентин
2017-09-07 19:30 ` Stefan Beller
2017-09-08 5:10 ` Jeff King
2017-09-08 6:38 ` Junio C Hamano
2017-09-08 7:49 ` Jeff King
2017-09-08 17:37 ` Junio C Hamano
2017-09-09 6:52 6% ` Jeff King
2017-09-10 7:36 6% ` Junio C Hamano
2017-11-16 0:54 [PATCH V3] config: add --expiry-date Junio C Hamano
2017-11-18 2:27 ` [PATCH V4] " hsed
2017-11-18 3:37 6% ` Junio C Hamano
2017-11-20 17:04 ` Jeff King
2017-11-20 20:28 6% ` Stefan Beller
2020-11-23 19:04 [RFC PATCH] usage: add trace2 entry upon warning() Jonathan Tan
2020-11-24 20:05 ` [PATCH v3] " Jonathan Tan
2020-11-24 22:15 6% ` Junio C Hamano
2018-11-12 14:46 [PATCH 0/9] caching loose objects Jeff King
2018-11-12 14:55 ` [PATCH 9/9] fetch-pack: drop custom loose object cache Jeff King
2018-11-12 19:25 6% ` René Scharfe
2022-12-02 17:02 [PATCH] maintenance: compare output of pthread functions for inequality with 0 Rose via GitGitGadget
2022-12-02 18:10 6% ` Ævar Arnfjörð Bjarmason
2019-05-15 8:36 [PATCH 1/2] t5616: refactor packfile replacement Johannes Schindelin
2019-05-15 18:22 6% ` Jonathan Tan
2020-06-23 15:04 [PATCH 0/3] Accommodate for pu having been renamed to seen Johannes Schindelin via GitGitGadget
2020-06-23 15:04 ` [PATCH 1/3] docs: adjust for the recent rename of `pu` to `seen` Johannes Schindelin via GitGitGadget
2020-06-23 15:31 ` Đoàn Trần Công Danh
2020-06-23 19:31 ` Junio C Hamano
2020-06-23 21:32 6% ` Johannes Schindelin
2022-02-17 20:50 When rebase.autoStash=true is used, 'git pull' merge process still complains when incoming changes are in a different place of the file than local changes Yuri
2022-02-22 16:37 ` Phillip Wood
2022-02-23 21:23 6% ` Junio C Hamano
2017-11-20 21:21 [PATCH v3 0/8] Coping with unrecognized ssh wrapper scripts in GIT_SSH Jonathan Nieder
2017-11-20 21:22 ` [PATCH 1/8] ssh test: make copy_ssh_wrapper_as clean up after itself Jonathan Nieder
2017-11-21 1:24 6% ` Junio C Hamano
2024-02-08 23:17 [PATCH] git: --no-lazy-fetch option Junio C Hamano
2024-02-15 5:30 ` Jeff King
2024-02-15 17:04 ` Junio C Hamano
2024-02-16 17:22 ` Junio C Hamano
2024-02-16 21:09 ` [PATCH] git: extend --no-lazy-fetch to work across subprocesses Junio C Hamano
2024-02-17 5:40 ` Jeff King
2024-02-27 6:04 6% ` Junio C Hamano
2024-02-27 7:49 6% ` Jeff King
2024-02-17 5:29 ` [PATCH] git: --no-lazy-fetch option Jeff King
2024-03-09 1:57 6% ` Linus Arver
2020-08-28 6:56 Git in Outreachy? Jeff King
2020-08-31 17:41 6% ` Junio C Hamano
2018-07-03 12:38 [PATCH 0/8] X509 (gpgsm) commit signing support Henning Schild
2018-07-03 12:38 ` [PATCH 4/8] gpg-interface: introduce an abstraction for multiple gpg formats Henning Schild
2018-07-04 7:10 ` Martin Ågren
2018-07-06 17:24 ` Junio C Hamano
2018-07-10 15:37 ` Jeff King
2018-07-10 15:51 6% ` Junio C Hamano
2019-09-04 2:22 [RFC PATCH 0/1] commit-graph.c: handle corrupt commit trees Taylor Blau
2019-09-04 18:25 ` Garima Singh
2019-09-04 21:21 6% ` Taylor Blau
2017-08-23 19:39 Should rerere auto-update a merge resolution? Martin Langhoff
2017-08-23 20:34 ` Junio C Hamano
2017-08-23 21:12 ` Martin Langhoff
2017-08-25 15:16 ` Junio C Hamano
2017-08-25 16:07 ` Junio C Hamano
2017-08-25 17:08 6% ` Junio C Hamano
2023-01-20 4:56 [PATCH v2 0/2] rebase: mark --update-refs as requiring the merge backend Elijah Newren via GitGitGadget
2023-01-21 1:55 ` [PATCH v3 0/7] rebase: fix several code/testing/documentation issues around flag incompatibilities Elijah Newren via GitGitGadget
2023-01-21 1:55 ` [PATCH v3 3/7] rebase: remove --allow-empty-message from incompatible opts Elijah Newren via GitGitGadget
2023-01-21 15:09 6% ` Phillip Wood
2024-04-04 13:25 [PATCH 00/12] t: exercise Git/JGit reftable compatibility Patrick Steinhardt
2024-04-04 13:25 ` [PATCH 11/12] t0610: fix non-portable variable assignment Patrick Steinhardt
2024-04-05 16:02 ` Junio C Hamano
2024-04-05 16:12 ` [PATCH] CodingGuidelines: quote assigned value with "local" and "export" Junio C Hamano
2024-04-05 16:21 6% ` Junio C Hamano
2019-09-03 21:11 [PATCH] t: use LF variable defined in the test harness Junio C Hamano
2019-09-04 0:29 ` Taylor Blau
2019-09-05 18:17 ` Junio C Hamano
2019-09-05 18:47 6% ` Jeff King
2019-09-05 19:34 6% ` Junio C Hamano
2019-09-05 22:10 ` [PATCH] t: use common $SQ variable Denton Liu
2019-09-05 22:25 6% ` Taylor Blau
2019-09-05 22:27 6% ` Taylor Blau
2017-08-27 7:37 [PATCH] pkt-line: re-'static'-ify buffer in packet_write_fmt_1() Martin Ågren
2017-08-27 18:21 ` Lars Schneider
2017-08-27 19:09 ` Martin Ågren
2017-08-27 20:04 ` Lars Schneider
2017-08-27 23:23 ` Jeff King
2017-08-28 4:11 ` Martin Ågren
2017-08-29 17:51 ` Lars Schneider
2017-08-29 18:53 ` Jeff King
2017-08-29 19:22 ` Martin Ågren
2017-08-29 21:48 ` Jeff King
2017-08-30 5:31 ` Jeff King
2017-09-05 10:03 6% ` Junio C Hamano
2017-10-10 4:06 6% ` [PATCH 0/2] Do not call cmd_*() as a subroutine Junio C Hamano
2024-02-08 17:00 [PATCH] prune: mark rebase autostash and orig-head as reachable Phillip Wood via GitGitGadget
2024-02-09 16:19 ` [PATCH v2] " Phillip Wood via GitGitGadget
2024-02-09 18:04 6% ` Junio C Hamano
2020-04-07 14:11 [PATCH 0/6] fixup ra/rebase-i-more-options Phillip Wood
2020-07-16 17:32 ` [PATCH v7 0/5] cleanup ra/rebase-i-more-options Phillip Wood
2020-07-16 17:39 6% ` Junio C Hamano
2024-03-08 14:14 [PATCH 0/4] checkout: cleanup --conflict= Phillip Wood via GitGitGadget
2024-03-14 17:05 ` [PATCH v2 0/5] " Phillip Wood via GitGitGadget
2024-03-14 17:05 ` [PATCH v2 1/5] xdiff-interface: refactor parsing of merge.conflictstyle Phillip Wood via GitGitGadget
2024-03-14 17:19 6% ` Junio C Hamano
2022-06-21 5:36 [PATCH v2] grep: add --max-count command line option Carlos L. via GitGitGadget
2022-06-22 17:07 ` [PATCH v3 0/2] " Carlos L. via GitGitGadget
2022-06-22 17:07 ` [PATCH v3 2/2] tests: add tests for grep --max-count Carlos López via GitGitGadget
2022-06-22 18:10 6% ` Junio C Hamano
2018-11-16 17:31 [PATCH v2] read-cache: write all indexes with the same permissions Christian Couder
2018-11-17 9:29 ` Junio C Hamano
2018-11-17 11:19 ` Christian Couder
2018-11-17 13:05 6% ` Junio C Hamano
2019-07-18 13:19 [PATCH 00/24] Reinstate support for Visual Studio Johannes Schindelin via GitGitGadget
2019-07-29 20:08 ` [PATCH v2 00/23] " Johannes Schindelin via GitGitGadget
2019-07-29 20:08 ` [PATCH v2 20/23] .gitignore: touch up the entries regarding " Philip Oakley via GitGitGadget
2019-08-25 12:07 ` SZEDER Gábor
2019-08-25 13:20 ` Philip Oakley
2019-08-25 19:09 ` SZEDER Gábor
2019-08-25 22:21 ` Philip Oakley
2019-08-26 9:10 ` SZEDER Gábor
2019-08-28 11:34 6% ` Johannes Schindelin
2019-01-14 17:53 Students projects: looking for small and medium project ideas Matthieu Moy
2019-01-14 23:04 6% ` Ævar Arnfjörð Bjarmason
2019-02-23 13:28 ` Fabio Aiuto
2019-02-26 17:51 ` Matthieu Moy
2019-02-26 20:14 8% ` Johannes Schindelin
2017-08-08 17:11 [PATCH v2 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option Kaartic Sivaraam
2017-08-14 8:54 ` [PATCH v3 " Kaartic Sivaraam
2017-08-14 20:19 ` Junio C Hamano
2017-08-15 10:56 ` Kaartic Sivaraam
2017-08-15 18:58 ` Junio C Hamano
2017-08-16 18:13 ` Kaartic Sivaraam
2017-08-16 19:09 ` Junio C Hamano
2017-08-17 2:04 ` Kaartic Sivaraam
2017-09-12 6:49 6% ` Junio C Hamano
2022-03-11 13:21 [RFC PATCH 0/1] Documentation/git-sparse-checkout.txt: add an OPTIONS section Shaoxuan Yuan
2022-03-11 13:21 ` [RFC PATCH 1/1] " Shaoxuan Yuan
2022-03-11 20:56 6% ` Derrick Stolee
2022-11-15 18:53 [PATCH] builtin/gc.c: fix use-after-free in maintenance_unregister() Taylor Blau
2022-11-15 19:41 ` Ævar Arnfjörð Bjarmason
2022-11-15 19:54 ` Taylor Blau
2022-11-16 13:44 ` Derrick Stolee
2022-11-16 15:14 6% ` Ævar Arnfjörð Bjarmason
2018-02-12 17:23 [PATCH] describe: confirm that blobs actually exist Jeff King
2018-02-12 17:29 6% ` Jeff King
2022-11-26 20:21 [PATCH v2] send-email: relay '-v N' to format-patch Kyle Meyer
2022-11-27 1:25 ` Junio C Hamano
2022-11-28 12:34 6% ` Ævar Arnfjörð Bjarmason
2021-04-15 12:33 [PATCH] transport: respect verbosity when setting upstream Øystein Walle
2021-04-15 15:29 ` Eric Sunshine
2021-04-16 13:38 ` Øystein Walle
2021-04-16 18:48 6% ` Junio C Hamano
2022-06-09 23:44 [PATCH] revision: mark blobs needed for resolve-undo as reachable Junio C Hamano
2022-06-13 15:15 ` Derrick Stolee
2022-06-14 0:24 ` Ævar Arnfjörð Bjarmason
2022-06-14 14:35 ` Derrick Stolee
2022-06-15 2:02 ` Taylor Blau
2022-06-15 3:48 ` Jeff King
2022-06-15 20:47 6% ` Taylor Blau
2020-05-27 21:09 [PATCH] checkout -p: handle new files correctly Johannes Schindelin via GitGitGadget
2020-05-27 23:03 ` Jeff King
2020-05-27 19:51 6% ` Johannes Schindelin
2019-08-27 5:17 Git in Outreachy December 2019? Jeff King
2019-09-04 19:41 ` Jeff King
2019-09-23 18:07 ` SZEDER Gábor
2019-09-26 11:42 6% ` Johannes Schindelin
2017-10-19 17:44 [PATCH v2] commit: check result of resolve_ref_unsafe Jeff King
2017-10-19 17:47 ` [PATCH 2/4] remote: handle broken symrefs Jeff King
2017-10-19 17:53 6% ` Jeff King
2020-08-26 15:45 [PATCH] clone: add remote.cloneDefault config option Sean Barag via GitGitGadget
2020-08-26 18:46 ` Junio C Hamano
2020-08-26 19:04 ` Derrick Stolee
2020-08-26 19:59 6% ` Junio C Hamano
2019-04-19 21:47 Resolving deltas dominates clone time Martin Fick
2019-04-22 20:21 ` Martin Fick
2019-04-22 20:56 ` Jeff King
2019-04-22 22:32 ` Martin Fick
2019-04-23 1:55 ` Jeff King
2019-04-23 4:21 ` Jeff King
2019-04-23 10:08 ` Duy Nguyen
2019-04-30 17:50 ` Jeff King
2019-04-30 18:48 6% ` Ævar Arnfjörð Bjarmason
2021-06-20 15:11 [PATCH 00/12] Fix all leaks in tests t0002-t0099: Part 2 andrzej
2021-06-21 21:54 6% ` Elijah Newren
2021-06-24 18:29 [PATCH 0/3] Empty untracked cache performance issue Tao Klerks via GitGitGadget
2022-02-25 17:10 ` [PATCH v2 " Tao Klerks via GitGitGadget
2022-02-25 17:10 ` [PATCH v2 1/3] t7519: avoid file to index mtime race for untracked cache Tao Klerks via GitGitGadget
2022-02-25 19:07 6% ` Junio C Hamano
2018-01-03 0:18 [PATCH 00/26] protocol version 2 Brandon Williams
2018-01-25 23:58 ` [PATCH v2 00/27] " Brandon Williams
2018-01-25 23:58 ` [PATCH v2 05/27] upload-pack: factor out processing lines Brandon Williams
2018-01-26 20:12 ` Stefan Beller
2018-01-26 21:33 ` Brandon Williams
2018-01-31 14:08 6% ` Derrick Stolee
2018-02-07 1:12 ` [PATCH v3 00/35] protocol version 2 Brandon Williams
2018-02-07 1:12 ` [PATCH v3 14/35] connect: request remote refs using v2 Brandon Williams
2018-02-21 22:54 ` Jonathan Tan
2018-02-22 18:19 ` Brandon Williams
2018-02-22 18:26 ` Jeff King
2018-02-22 19:25 ` Jonathan Tan
2018-02-27 6:21 6% ` Jonathan Nieder
2023-02-19 14:13 How to find places where I can contribute? Divyanshu Agrawal
2023-02-20 9:59 ` Christian Couder
2023-02-20 21:31 6% ` Junio C Hamano
2019-02-19 7:03 Antw: Antw: Ulrich Windl
2019-02-19 17:07 ` [PATCH v2] merge-options.txt: correct wording of --no-commit option Elijah Newren
2019-02-19 19:32 ` Junio C Hamano
2019-02-19 22:31 6% ` Elijah Newren
2017-09-18 17:21 [OUTREACHY] pack: make packed_git_mru global a value instead of a pointer phionah bugosi
2017-09-18 23:17 ` Jonathan Nieder
2017-09-19 5:20 6% ` Jeff King
2020-08-08 21:34 [PATCH] gitweb: Map names/emails with mailmap Emma Brooks
2020-08-09 23:04 ` [PATCH v2] gitweb: map " Emma Brooks
2020-08-10 10:02 ` Jeff King
2020-08-11 4:17 ` Emma Brooks
2020-08-11 4:55 ` Jeff King
2020-09-05 2:55 ` Emma Brooks
2020-09-05 3:26 ` Junio C Hamano
2020-09-07 22:10 6% ` Emma Brooks
2017-11-08 16:58 Invalid memory access in `git apply` mqudsi
2017-11-11 14:10 ` [PATCH] apply: avoid out-of-bounds access in fuzzy_matchlines() René Scharfe
2017-11-12 4:45 6% ` Junio C Hamano
2024-01-11 13:47 [PATCH] git-p4: stop reaching into the refdb Patrick Steinhardt
2024-01-11 21:20 6% ` Junio C Hamano
2022-10-12 9:35 [PATCH v3 0/8] rebase: make reflog messages independent of the backend Phillip Wood via GitGitGadget
2022-10-21 9:21 ` [PATCH v4 " Phillip Wood via GitGitGadget
2022-10-21 9:21 ` [PATCH v4 8/8] rebase: cleanup action handling Phillip Wood via GitGitGadget
2022-10-21 17:54 6% ` Junio C Hamano
2024-02-07 16:47 [PATCH v2 0/5] merge-tree: handle missing objects correctly Johannes Schindelin via GitGitGadget
2024-02-22 14:36 ` [PATCH v3 " Johannes Schindelin via GitGitGadget
2024-02-22 14:36 ` [PATCH v3 1/5] merge-tree: fail with a non-zero exit code on missing tree objects Johannes Schindelin via GitGitGadget
2024-02-22 17:13 6% ` Junio C Hamano
2020-11-04 14:57 [PATCH 0/2] update-ref: Allow creation of multiple transactions Patrick Steinhardt
2020-11-04 14:57 ` [PATCH 1/2] " Patrick Steinhardt
2020-11-05 19:29 ` Jeff King
2020-11-05 21:34 ` Junio C Hamano
2020-11-06 17:52 ` Jeff King
2020-11-06 19:30 6% ` Junio C Hamano
2020-06-01 0:28 Git multiple remotes push stop at first failed connection John Siu
2020-06-01 21:40 ` Jeff King
2020-06-02 16:26 6% ` Junio C Hamano
2018-09-26 21:28 [PATCH] fetch: replace string-list used as a look-up table with a hashmap Junio C Hamano
2018-09-27 5:34 ` Jeff King
2018-09-30 2:11 ` Junio C Hamano
2018-10-19 3:48 ` [PATCH v3] " Junio C Hamano
2018-10-22 9:57 ` Johannes Schindelin
2018-10-27 6:47 ` Re*: " Junio C Hamano
2018-10-31 14:50 6% ` Johannes Schindelin
2018-07-18 16:10 [PATCH v2 00/23] Mark strings for translation Nguyễn Thái Ngọc Duy
2018-07-18 16:10 ` [PATCH v2 03/23] archive-zip.c: mark more " Nguyễn Thái Ngọc Duy
2018-07-19 18:26 6% ` Junio C Hamano
2018-07-18 16:10 ` [PATCH v2 02/23] archive-tar.c: " Nguyễn Thái Ngọc Duy
2018-07-19 18:21 6% ` Junio C Hamano
2024-01-31 22:30 [PATCH v3 0/2] index-pack: fsck honor checks Jonathan Tan
2024-02-01 1:34 ` John Cai
2024-02-01 16:44 6% ` Junio C Hamano
2017-10-04 15:20 Enhancement request: git-push: Allow (configurable) default push-option Marius Paliga
2017-10-11 20:25 ` Thais D. Braz
2017-10-11 20:25 ` [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option Thais D. Braz
2017-10-12 1:21 ` Junio C Hamano
2017-10-12 2:41 6% ` Christian Couder
2017-10-12 3:26 ` Junio C Hamano
2017-10-17 3:47 10% ` [PATCH] patch reply Thais Diniz
2017-10-17 3:58 6% ` [PATCH][Outreachy] New git config variable to specify string that will be automatically passed as --push-option thais braz
2024-03-25 13:10 [GSoC] Microproject help vk
2024-03-25 20:51 6% ` Eric Sunshine
2024-04-29 16:48 [PATCH 0/3] color: add support for 12-bit RGB colors Beat Bolli
2024-04-29 16:48 ` [PATCH 3/3] " Beat Bolli
2024-04-30 10:57 ` Jeff King
2024-04-30 17:31 6% ` Junio C Hamano
2019-06-25 21:35 [2.22.0] difftool no longer passes through to git diff if diff.tool is unset Jeff King
2019-06-25 23:09 ` Pugh, Logan
2019-06-26 18:08 6% ` Jeff King
2021-04-14 6:13 Pain points in Git's patch flow Jonathan Nieder
2021-04-14 7:22 ` Bagas Sanjaya
2021-04-14 8:02 8% ` Junio C Hamano
2022-01-24 18:09 [PATCH] clone: support unusual remote ref configurations Jonathan Tan
2022-01-26 19:11 7% ` Junio C Hamano
2022-01-27 15:37 [PATCH] fetch --prune: exit with error if pruning fails Thomas Gummerer
2022-01-27 19:57 6% ` Junio C Hamano
2017-09-25 0:02 BUG: merge -s theirs is not in effect (does the same as -s ours) Yaroslav Halchenko
2017-09-25 1:08 ` Junio C Hamano
2017-09-25 3:17 ` Yaroslav Halchenko
2017-09-25 5:33 ` Re* " Junio C Hamano
2017-09-25 14:30 ` -X theirs does not resolve symlink conflict Was: BUG: merge -s theirs is not in effect Yaroslav Halchenko
2017-09-26 1:56 ` Junio C Hamano
2017-09-26 2:16 ` Junio C Hamano
2017-09-26 2:39 6% ` Junio C Hamano
2023-05-08 21:59 [PATCH 00/15] refs: implement skip lists for packed backend Taylor Blau
2023-05-08 21:59 ` [PATCH 06/15] builtin/for-each-ref.c: add `--exclude` option Taylor Blau
2023-05-08 23:22 ` Junio C Hamano
2023-05-09 20:22 6% ` Taylor Blau
2017-10-13 5:11 [PATCH 0/3] a small branch API clean-up Junio C Hamano
2017-10-13 5:11 ` [PATCH 3/3] branch: forbid refs/heads/HEAD Junio C Hamano
2017-10-13 13:15 6% ` Jeff King
2019-02-27 12:47 [BUG] All files in folder are moved when cherry-picking commit that moves fewer files Linus Nilsson
2019-02-27 14:30 ` Phillip Wood
2019-02-27 16:02 ` Elijah Newren
2019-02-27 16:40 ` Jeff King
2019-02-27 17:31 6% ` Elijah Newren
2023-02-04 19:10 [PATCH] cache-tree: fix strbuf growth in prime_cache_tree_rec() René Scharfe
2023-02-05 21:12 ` Ævar Arnfjörð Bjarmason
2023-02-10 20:20 ` René Scharfe
2023-02-10 20:33 ` Junio C Hamano
2023-02-11 2:15 6% ` Jeff King
2017-08-30 6:46 [PATCH 00/39] per-repository object store, part 1 Jonathan Nieder
2017-08-30 6:48 ` [PATCH 01/39] pack: make packed_git_mru global a value instead of a pointer Jonathan Nieder
2017-08-30 19:44 6% ` Jeff King
2022-02-12 20:34 [PATCH v4 00/12] In-core git merge-tree ("Server side merges") Elijah Newren via GitGitGadget
2022-02-20 6:54 ` [PATCH v5 " Elijah Newren via GitGitGadget
2022-02-20 6:54 ` [PATCH v5 04/12] merge-tree: implement real merges Elijah Newren via GitGitGadget
2022-02-20 9:03 ` René Scharfe
2022-02-22 2:28 6% ` Elijah Newren
2018-08-11 20:50 [PATCHv2 0/6] Add missing includes and forward declares Elijah Newren
2018-08-13 17:17 ` [PATCHv3 " Elijah Newren
2018-08-13 17:17 ` [PATCHv3 1/6] " Elijah Newren
2018-08-15 5:10 ` Jonathan Nieder
2018-08-15 5:50 ` Elijah Newren
2018-08-15 6:13 ` Jonathan Nieder
2018-08-15 6:51 6% ` Elijah Newren
2024-03-12 16:26 [PATCH] bugreport.c: fix a crash in `git bugreport` with `--no-suffix` option barroit via GitGitGadget
2024-03-13 15:59 7% ` Junio C Hamano
2024-04-30 1:47 [PATCH v3 0/1] advice: add --no-advice global option James Liu
2024-05-03 7:17 ` [PATCH v4 0/3] advice: add "all" option to disable all hints James Liu
2024-05-03 7:17 ` [PATCH v4 1/3] doc: clean up usage documentation for --no-* opts James Liu
2024-05-03 17:30 6% ` Junio C Hamano
2018-09-30 10:23 [Outreachy] Introduce myself Ananya Krishna Maram
2018-09-30 16:57 6% ` Christian Couder
2023-12-07 22:12 [BUG] rev-list doesn't validate arguments to -n option Britton Kerin
2023-12-08 20:36 ` Junio C Hamano
2023-12-08 22:35 ` [PATCH] revision: parse integer arguments to --max-count, --skip, etc., more carefully Junio C Hamano
2023-12-12 1:30 ` Jeff King
2023-12-12 15:09 ` Junio C Hamano
2023-12-12 22:05 6% ` Jeff King
2023-09-07 9:25 [PATCH v4 00/15] Introduce new `git replay` command Christian Couder
2023-10-10 12:38 ` [PATCH v5 00/14] " Christian Couder
2023-10-10 12:38 ` [PATCH v5 11/14] replay: use standard revision ranges Christian Couder
2023-10-19 19:49 6% ` Linus Arver
2022-07-13 4:19 [PATCH 0/3] checkout: fix two bugs on count of updated entries Matheus Tavares
2022-07-13 4:19 ` [PATCH 1/3] checkout: document bug where delayed checkout counts entries twice Matheus Tavares
2022-07-13 17:57 6% ` Junio C Hamano
2020-08-26 16:45 [PATCH v1 0/3] War on dashed-git Junio C Hamano
2020-08-26 19:46 ` [PATCH v2 0/2] avoid running "git-subcmd" in the dashed form Junio C Hamano
2020-08-26 19:46 ` [PATCH v2 2/2] cvsexportcommit: do not run git programs in " Junio C Hamano
2020-08-26 21:37 ` [PATCH v2 3/2] credential-cache: use child_process.args Junio C Hamano
2020-08-26 22:25 ` [PATCH] run_command: teach API users to use embedded 'args' more Junio C Hamano
2020-08-27 4:21 ` Jeff King
2020-08-27 4:30 6% ` Junio C Hamano
2018-08-28 15:14 Git in Outreachy Dec-Mar? Jeff King
2018-08-31 8:16 ` Christian Couder
2018-09-01 8:43 ` Jeff King
2018-09-03 4:36 ` Christian Couder
2018-09-05 7:20 ` Christian Couder
2018-09-06 1:14 6% ` Jeff King
2018-09-06 1:21 ` Jeff King
2018-09-06 9:51 ` Christian Couder
2018-09-06 19:31 6% ` Jeff King
2022-02-20 5:05 [PATCH] Provide config option to expect files outside sparse patterns Elijah Newren via GitGitGadget
2022-02-21 20:34 ` Johannes Schindelin
2022-02-22 2:23 ` Elijah Newren
2022-02-22 12:11 6% ` Johannes Schindelin
2019-04-03 14:38 Feature request: Add --no-edit to git tag command Robert Dailey
2019-04-04 1:57 6% ` Jeff King
2022-02-18 18:48 [PATCH v2 2/2] Add new tests functions like test_path_is_* Junio C Hamano
2022-02-22 21:54 ` [PATCH v3 0/3] replace test [-f|-d] with more verbose functions COGONI Guillaume
2022-02-23 22:59 6% ` Junio C Hamano
2023-08-31 21:16 [PATCH v2 0/10] more unused parameters in parseopt callbacks Jeff King
2023-08-31 21:21 ` [PATCH v2 05/10] parse-options: prefer opt->value to globals in callbacks Jeff King
2023-09-02 7:34 6% ` René Scharfe
2021-03-05 0:55 [PATCH 00/11] Complete merge-ort implementation...almost Elijah Newren via GitGitGadget
2021-03-05 0:55 ` [PATCH 10/11] merge-ort: write $GIT_DIR/AUTO_MERGE whenever we hit a conflict Elijah Newren via GitGitGadget
2021-03-08 13:11 ` Ævar Arnfjörð Bjarmason
2021-03-08 21:51 6% ` Elijah Newren
2021-03-05 0:55 ` [PATCH 05/11] merge-ort: let renormalization change modify/delete into clean delete Elijah Newren via GitGitGadget
2021-03-08 12:55 6% ` Ævar Arnfjörð Bjarmason
2021-03-05 0:55 ` [PATCH 08/11] merge-ort: implement CE_SKIP_WORKTREE handling with conflicted entries Elijah Newren via GitGitGadget
2021-03-08 13:06 ` Ævar Arnfjörð Bjarmason
2021-03-08 20:54 6% ` Elijah Newren
2023-10-09 20:55 [PATCH 0/20] bounds-checks for chunk-based files Jeff King
2023-10-09 21:04 ` [PATCH 06/20] commit-graph: check consistency of fanout table Jeff King
2023-10-11 14:45 6% ` Taylor Blau
2024-04-14 16:47 [PATCH] imap-send: increase command size limit René Scharfe
2024-04-15 18:55 ` Jeff King
2024-04-16 16:08 6% ` René Scharfe
2023-10-05 22:14 How To Pick And Work On A Microproject Naomi Ibe
2023-10-05 22:42 ` Junio C Hamano
2023-10-06 9:02 ` Christian Couder
2023-10-06 19:03 7% ` Junio C Hamano
2019-08-19 23:52 [PATCH v2 0/4] format-patch: learn --infer-cover-subject option Denton Liu
2019-08-20 7:18 ` [PATCH v3 00/13] format-patch: learn --infer-cover-subject option (also t4014 cleanup) Denton Liu
2019-08-20 7:19 ` [PATCH v3 13/13] format-patch: learn --infer-cover-subject option Denton Liu
2019-08-21 19:32 ` Junio C Hamano
2019-08-23 18:15 ` Denton Liu
2019-08-23 18:46 6% ` Philip Oakley
2023-09-11 15:39 [PATCH] diff --stat: add config option to limit filename width Dragan Simic
2023-09-11 23:12 ` Junio C Hamano
2023-09-12 2:11 ` Dragan Simic
2023-09-12 17:11 6% ` Junio C Hamano
2017-11-22 17:51 [RFC PATCH] builtin/worktree: enhance worktree removal Kaartic Sivaraam
2017-11-27 17:36 ` [RFC PATCH v2] " Kaartic Sivaraam
2017-11-28 3:02 ` Junio C Hamano
2017-11-28 3:48 ` Eric Sunshine
2017-11-28 4:04 ` Junio C Hamano
2017-11-28 16:46 6% ` Kaartic Sivaraam
2022-03-09 13:16 [PATCH 00/24] revision.[ch]: add and use release_revisions() Ævar Arnfjörð Bjarmason
2022-03-09 13:16 ` [PATCH 03/24] format-patch: don't leak "extra_headers" or "ref_message_ids" Ævar Arnfjörð Bjarmason
2022-03-09 20:34 6% ` Taylor Blau
2022-07-28 14:01 [PATCH] mingw: include the Python parts in the build Johannes Schindelin via GitGitGadget
2022-07-28 17:29 ` Junio C Hamano
2022-07-29 14:29 ` Johannes Schindelin
2022-07-29 21:31 ` Johannes Sixt
2022-08-10 9:29 6% ` Johannes Schindelin
2021-02-02 9:31 [PATCH 0/9] stash show: learn --include-untracked and --only-untracked Denton Liu
2021-02-02 9:33 ` [PATCH 3/9] t3905: move all commands into test cases Denton Liu
2021-02-02 21:41 6% ` Junio C Hamano
2017-10-02 10:13 What means "git config bla ~/"? rpjday
2017-10-02 17:13 ` Jonathan Nieder
2017-10-03 0:08 ` Junio C Hamano
2017-10-03 11:45 ` Matthieu Moy
2017-10-04 4:01 6% ` Junio C Hamano
2019-08-25 18:59 [PATCH] t7300-clean: demonstrate deleting nested repo with an ignored file breakage SZEDER Gábor
2019-09-05 15:47 ` [RFC PATCH v2 00/12] Fix some git clean issues Elijah Newren
2019-09-05 15:47 ` [RFC PATCH v2 12/12] clean: fix theoretical path corruption Elijah Newren
2019-09-05 19:27 ` SZEDER Gábor
2019-09-07 0:34 6% ` Elijah Newren
2022-01-24 1:26 [PATCH] receive-pack: purge temporary data if no command is ready to run BoJun via GitGitGadget
2022-01-29 6:35 ` [PATCH v2] " Chen BoJun
2022-02-04 1:17 6% ` Junio C Hamano
2017-08-07 21:49 Suggestion: better error message when an ambiguous checkout is executed Mahmoud Al-Qudsi
2017-08-07 22:44 ` Junio C Hamano
2017-09-12 6:53 6% ` Junio C Hamano
2018-07-18 0:53 [PATCH] diff.c: offer config option to control ws handling in move detection Stefan Beller
2018-07-18 17:45 ` Junio C Hamano
2018-07-18 18:16 ` Stefan Beller
2018-07-19 16:29 ` Junio C Hamano
2018-07-19 17:29 6% ` Stefan Beller
2020-12-19 17:07 Documentation errors for HTTP protocol v2 and packfile Ross Light
2020-12-21 7:54 ` [PATCH 0/2] pack-format.txt: document lengths at start of delta data Martin Ågren
2020-12-21 7:54 ` [PATCH 1/2] pack-format.txt: define "varint" format Martin Ågren
2020-12-21 21:40 ` Junio C Hamano
2020-12-29 22:41 6% ` Martin Ågren
2019-12-19 0:01 [PATCH v1 0/1] gpg-interface: add minTrustLevel as a configuration option Hans Jerry Illikainen
2019-12-22 0:31 ` [PATCH v2 " Hans Jerry Illikainen
2019-12-22 0:31 ` [PATCH v2 1/1] " Hans Jerry Illikainen
2019-12-24 19:02 ` Junio C Hamano
2019-12-27 13:46 ` Hans Jerry Illikainen
2019-12-27 22:21 6% ` Junio C Hamano
2024-03-07 9:14 [PATCH 0/15] allow multi-byte core.commentChar Jeff King
2024-03-07 9:26 ` [PATCH 11/15] find multi-byte comment chars in unterminated buffers Jeff King
2024-03-07 19:42 ` René Scharfe
2024-03-12 8:05 ` Jeff King
2024-03-14 19:37 6% ` René Scharfe
2019-02-23 15:11 does "git clean" deliberately ignore "core.excludesFile"? Robert P. J. Day
2019-02-23 15:28 ` Junio C Hamano
2019-02-23 18:06 ` Johannes Schindelin
2019-02-23 18:19 ` Johannes Schindelin
2019-02-23 18:32 ` Robert P. J. Day
2019-02-24 5:30 ` Junio C Hamano
2019-02-24 14:15 6% ` Johannes Schindelin
2024-04-23 21:28 [PATCH v3 0/8] refs: add symref support to 'git-update-ref' Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 0/7] add symref-* commands to 'git-update-ref --stdin' Karthik Nayak
2024-04-26 15:24 ` [PATCH v4 1/7] refs: accept symref values in `ref_transaction[_add]_update` Karthik Nayak
2024-04-26 19:31 6% ` Junio C Hamano
2024-05-01 20:22 ` [PATCH v5 0/7] refs: add support for transactional symref updates Karthik Nayak
2024-05-01 20:22 ` [PATCH v5 4/7] " Karthik Nayak
2024-05-01 23:52 ` Junio C Hamano
2024-05-02 5:50 ` Karthik Nayak
2024-05-02 7:47 6% ` Patrick Steinhardt
2017-09-27 6:16 [PATCH 0/3] validate_headref: avoid reading uninitialized bytes Jeff King
2017-09-27 6:17 ` [PATCH 1/3] validate_headref: NUL-terminate HEAD buffer Jeff King
2017-09-27 7:06 6% ` Junio C Hamano
2019-11-04 9:54 [RFC PATCH v2 0/2] rebase -i: extend rebase.missingCommitsCheck to `--edit-todo' Alban Gruin
2019-12-02 23:47 ` [PATCH v3 0/2] rebase -i: extend rebase.missingCommitsCheck Alban Gruin
2019-12-02 23:47 ` [PATCH v3 1/2] sequencer: move check_todo_list_from_file() to rebase-interactive.c Alban Gruin
2019-12-06 14:38 6% ` Johannes Schindelin
2017-10-25 5:11 [PATCHv2 0/2] (x)diff cleanup: remove duplicate code Junio C Hamano
2017-10-25 18:49 ` [PATCHv3 " Stefan Beller
2017-10-25 18:49 ` [PATCH 1/2] xdiff-interface: export comparing and hashing strings Stefan Beller
2017-10-26 17:12 ` René Scharfe
2017-10-27 7:12 ` Junio C Hamano
2017-10-27 17:15 6% ` Stefan Beller
2024-02-20 15:23 [PATCH] rebase: make warning less passive aggressive Harmen Stoppels via GitGitGadget
2024-02-20 17:29 6% ` Junio C Hamano
2020-08-12 18:33 [PATCH v2] rebase -i: Fix possibly wrong onto hash in todo Antti Keränen
2020-08-13 10:41 6% ` Alban Gruin
2018-06-28 7:46 [GSoC] [PATCH 0/5] rebase: rewrite rebase in C Pratik Karki
2018-07-06 12:08 ` [GSoC] [PATCH v3 0/4] " Pratik Karki
2018-07-06 12:08 ` [PATCH v3 4/4] builtin/rebase: support running "git rebase <upstream>" Pratik Karki
2018-07-07 6:45 6% ` Christian Couder
2018-07-07 16:24 6% ` Junio C Hamano
2017-10-02 13:56 [PATCH 0/3] for-each-ref: add :remote-ref and :remote-name specifiers Johannes Schindelin
2017-10-02 13:57 ` [PATCH 2/3] for-each-ref: let upstream/push optionally report merge name Johannes Schindelin
2017-10-04 9:12 ` Junio C Hamano
2017-10-04 11:41 ` Junio C Hamano
2017-10-05 9:14 6% ` Junio C Hamano
2024-03-20 9:48 [PATCH] contrib: drop hg-to-git script Jeff King
2024-03-22 7:31 ` Johannes Schindelin
2024-03-22 15:58 ` Junio C Hamano
2024-03-22 23:43 ` Jeff King
2024-03-23 18:49 6% ` Junio C Hamano
2020-04-21 13:12 [PATCH v3 0/4] gitfaq: add issues in the 'Common Issues' section Shourya Shukla
2020-04-21 13:12 ` [PATCH v3 3/4] gitfaq: shallow cloning a repository Shourya Shukla
2020-04-21 20:00 ` Junio C Hamano
2020-04-21 20:43 ` Randall S. Becker
2020-04-22 1:30 ` Derrick Stolee
2020-04-22 4:00 6% ` Jonathan Nieder
2021-01-17 4:02 [PATCH v4 0/3] builtin/ls-files.c:add git ls-file --dedup option 阿德烈 via GitGitGadget
2021-01-19 6:30 ` [PATCH v5 " 阿德烈 via GitGitGadget
2021-01-19 6:30 ` [PATCH v5 3/3] ls-files.c: add --deduplicate option ZheNing Hu via GitGitGadget
2021-01-20 21:26 ` Junio C Hamano
2021-01-21 11:00 6% ` 胡哲宁
2021-04-14 19:14 [PATCH 0/2] prevent `repack` to unpack and delete promisor objects Rafael Silva
2021-04-18 13:57 ` [PATCH v2 0/1] " Rafael Silva
2021-04-18 13:57 ` [PATCH v2 1/1] repack: avoid loosening promisor objects in partial clones Rafael Silva
2021-04-19 23:09 6% ` Junio C Hamano
2019-11-21 0:45 [PATCH v2 00/21] t: test cleanup stemming from experimentally enabling pipefail Denton Liu
2019-11-22 18:59 ` [PATCH v3 00/22] " Denton Liu
2019-11-22 19:00 ` [PATCH v3 22/22] t7700: stop losing return codes of git commands Denton Liu
2019-11-23 1:49 6% ` Junio C Hamano
2023-08-10 14:40 [PATCH] upload-pack: fix race condition in error messages Derrick Stolee via GitGitGadget
2023-08-16 6:06 ` [PATCH] upload-pack: fix exit code when denying fetch of unreachable object ID Patrick Steinhardt
2023-08-16 16:16 ` Junio C Hamano
2023-08-16 17:04 6% ` [Leftoverbits] exit code clean-up? Junio C Hamano
2023-08-17 9:24 8% ` Oswald Buddenhagen
2023-08-17 5:36 7% ` Jeff King
2023-08-17 16:03 8% ` Junio C Hamano
2017-12-09 20:40 [PATCH v3 1/7] git-compat-util: introduce skip_to_optional_arg() Christian Couder
2017-12-10 14:31 ` Jeff King
2017-12-10 14:39 ` Jeff King
2017-12-11 5:56 6% ` Christian Couder
2018-10-04 11:30 [PATCH] [Outreachy] git/userdiff.c fix regex pattern error Ananya Krishna Maram
2018-10-04 14:26 ` Johannes Schindelin
2018-10-04 9:35 ` Ananya Krishna Maram
2018-10-04 15:26 ` Johannes Schindelin
2018-10-04 10:39 ` Ananya Krishna Maram
2018-10-04 19:42 6% ` Johannes Schindelin
2023-10-18 20:28 [PATCH v1 0/4] maintenance: use XDG config if it exists Kristoffer Haugsbakk
2024-01-14 21:43 ` [PATCH v2 " Kristoffer Haugsbakk
2024-01-14 21:43 ` [PATCH v2 3/4] config: factor out global config file retrieval Kristoffer Haugsbakk
2024-01-19 6:18 ` Patrick Steinhardt
2024-01-19 7:40 ` Kristoffer Haugsbakk
2024-01-19 7:59 ` Patrick Steinhardt
2024-01-19 23:04 6% ` Junio C Hamano
2024-03-05 21:24 [PATCH 00/22] avoid redundant pipelines Beat Bolli
2024-03-15 19:45 ` [PATCH v2 " Beat Bolli
2024-03-15 19:46 ` [PATCH v2 09/22] t/t4*: avoid redundant uses of cat Beat Bolli
2024-03-16 1:34 6% ` Taylor Blau
2024-03-05 21:25 ` [PATCH 01/22] doc: avoid redundant use " Beat Bolli
2024-03-05 22:24 6% ` Junio C Hamano
2019-01-07 21:30 [PATCH] blame: add the ability to ignore commits Barret Rhoden
2019-01-17 20:29 ` [PATCH v2 0/3] " Barret Rhoden
2019-01-17 20:29 ` [PATCH v2 1/3] Move init_skiplist() outside of fsck Barret Rhoden
2019-01-18 9:45 ` Ævar Arnfjörð Bjarmason
2019-01-18 17:36 ` Junio C Hamano
2019-01-18 20:59 ` Johannes Schindelin
2019-01-18 21:30 ` Jeff King
2019-01-18 22:26 ` Ævar Arnfjörð Bjarmason
2019-01-22 7:12 ` Jeff King
2019-01-22 9:46 6% ` Ævar Arnfjörð Bjarmason
2020-04-01 18:11 [PATCH] commit-graph: fix buggy --expire-time option Derrick Stolee via GitGitGadget
2020-04-01 19:49 ` Junio C Hamano
2020-04-01 19:57 ` Jeff King
2020-04-01 20:33 6% ` Junio C Hamano
2024-02-21 8:35 [PATCH] git-remote.txt: fix typo Jakub Wilk
2024-02-21 18:18 6% ` Junio C Hamano
2018-08-28 21:05 Trivial enhancement: All commands which require an author should accept --author Ulrich Gemkow
2018-08-29 16:14 ` Johannes Schindelin
2018-08-29 19:09 6% ` Junio C Hamano
2018-08-30 11:51 ` Johannes Schindelin
2018-08-30 12:29 6% ` Ævar Arnfjörð Bjarmason
2018-08-30 14:08 ` Johannes Schindelin
2018-09-03 13:18 7% ` Ævar Arnfjörð Bjarmason
2018-08-30 14:26 ` Junio C Hamano
2018-09-04 17:18 6% ` Jonathan Nieder
2017-10-03 10:15 Enhancement request: git-push: Allow (configurable) default push-option Marius Paliga
2017-10-03 16:53 6% ` Stefan Beller
2017-10-19 0:35 [PATCH v4 2/3] implement fetching of moved submodules Junio C Hamano
2017-10-19 18:11 ` [PATCH 1/2] t5526: check for name/path collision in submodule fetch Stefan Beller
2017-10-19 18:11 ` [PATCH 2/2] fetch, push: keep separate lists of submodules and gitlinks Stefan Beller
2017-10-23 14:12 ` Heiko Voigt
2017-10-23 18:05 6% ` Stefan Beller
2018-08-06 15:25 [PATCH 0/2] Simple fixes to t7406 Elijah Newren
2018-08-07 16:49 ` [PATCHv3 0/5] " Elijah Newren
2018-08-13 20:28 ` SZEDER Gábor
2018-08-18 20:52 6% ` Elijah Newren
2024-04-17 8:28 [PATCH 0/2] Use a "best effort" strategy in scheduled maintenance Johannes Schindelin via GitGitGadget
2024-04-17 8:28 ` [PATCH 2/2] maintenance: running maintenance should not stop on errors Johannes Schindelin via GitGitGadget
2024-04-17 15:41 6% ` Junio C Hamano
2020-12-23 4:53 [PATCH v5 0/1] mergetool: remove unconflicted lines Felipe Contreras
2020-12-23 4:53 ` [PATCH v5 1/1] mergetool: add automerge configuration Felipe Contreras
2020-12-23 13:34 ` Junio C Hamano
2020-12-23 14:23 ` Felipe Contreras
2020-12-23 20:21 ` Junio C Hamano
2020-12-24 0:14 ` Felipe Contreras
2020-12-24 0:32 6% ` Junio C Hamano
2020-02-14 0:52 [RFC][GSOC] Microproject Suggestion Robear Selwans
2020-02-14 1:41 ` Junio C Hamano
2020-02-14 7:29 ` Robear Selwans
2020-02-14 8:49 6% ` Denton Liu
2024-02-07 16:44 [PATCH 0/2] show-ref --verify: accept psuedorefs Phillip Wood via GitGitGadget
2024-02-07 16:44 ` [PATCH 1/2] show-ref --verify: accept pseudorefs Phillip Wood via GitGitGadget
2024-02-07 17:12 6% ` Junio C Hamano
2020-09-26 10:13 [PATCH v6 0/3] push: add "--[no-]force-if-includes" Srinidhi Kaushik
2020-09-26 11:46 ` [PATCH v7 " Srinidhi Kaushik
2020-09-26 11:46 ` [PATCH v7 1/3] push: add reflog check for "--force-if-includes" Srinidhi Kaushik
2020-09-26 23:42 ` Junio C Hamano
2020-09-27 12:27 6% ` Srinidhi Kaushik
2021-07-10 13:37 [PATCH v5 00/21] fsck: lib-ify object-file.c & better fsck "invalid object" error reporting Ævar Arnfjörð Bjarmason
2021-09-07 10:57 ` [PATCH v6 00/22] " Ævar Arnfjörð Bjarmason
2021-09-07 10:57 ` [PATCH v6 03/22] cat-file tests: test for missing object with -t and -s Ævar Arnfjörð Bjarmason
2021-09-16 19:57 ` Taylor Blau
2021-09-16 22:52 6% ` Ævar Arnfjörð Bjarmason
2017-11-01 16:36 Git Open Source Weekend London 11th/12th November Thomas Gummerer
2017-11-04 9:28 6% ` Jeff King
2022-08-10 21:33 [BUG] git rev-list --missing=allow-promisor Andrew Olsen
2022-08-11 8:12 ` Jeff King
2022-08-14 6:29 ` [PATCH] is_promisor_object(): fix use-after-free of tree buffer Jeff King
2022-08-15 5:32 ` Junio C Hamano
2022-08-15 22:53 6% ` Jeff King
2024-02-11 8:57 [PATCH] unit-tests: do show relative file paths on non-Windows, too Junio C Hamano
2024-02-11 11:03 ` Phillip Wood
2024-02-11 15:58 ` [PATCH v2] " Junio C Hamano
2024-02-13 19:58 ` Johannes Schindelin
2024-02-13 20:48 6% ` Junio C Hamano
2019-03-13 10:16 [PATCH 0/4] get_oid: cope with a possibly stale loose object cache Johannes Schindelin via GitGitGadget
2019-03-13 10:16 ` [PATCH 1/4] rebase -i: demonstrate obscure loose object cache bug Johannes Schindelin via GitGitGadget
2019-03-13 16:11 ` Ævar Arnfjörð Bjarmason
2019-03-13 16:35 ` Jeff King
2019-03-13 22:27 6% ` Johannes Schindelin
2021-04-09 18:10 [PATCH 00/22] multi-pack reachability bitmaps Taylor Blau
2021-06-21 22:24 ` [PATCH v2 00/24] " Taylor Blau
2021-06-21 22:25 ` [PATCH v2 04/24] Documentation: build 'technical/bitmap-format' by default Taylor Blau
2021-07-21 9:58 ` Jeff King
2021-07-21 10:08 ` Jeff King
2021-07-21 17:23 6% ` Taylor Blau
2021-07-23 7:39 ` Jeff King
2021-07-26 18:49 6% ` Taylor Blau
2020-09-27 14:17 [PATCH v8 0/3] push: add "--[no-]force-if-includes" Srinidhi Kaushik
2020-10-01 8:21 ` [PATCH v9 " Srinidhi Kaushik
2020-10-01 8:21 ` [PATCH v9 1/3] push: add reflog check for "--force-if-includes" Srinidhi Kaushik
2020-10-02 13:52 ` Johannes Schindelin
2020-10-02 14:50 ` Johannes Schindelin
2020-10-02 16:22 7% ` Junio C Hamano
2022-09-22 13:37 [PATCH v2 0/2] scalar: make unregister idempotent Derrick Stolee via GitGitGadget
2022-09-26 18:48 ` [PATCH v3 0/3] " Derrick Stolee via GitGitGadget
2022-09-26 18:48 ` [PATCH v3 1/3] maintenance: add 'unregister --force' Derrick Stolee via GitGitGadget
2022-09-26 19:23 ` Junio C Hamano
2022-09-26 20:49 6% ` Derrick Stolee
2023-05-19 7:00 Which macOS versions does Git support? M Hickford
2023-05-19 9:09 ` Jeff King
2023-05-20 0:37 ` Carlo Marcelo Arenas Belón
2023-05-20 7:36 6% ` M Hickford
2020-11-16 12:22 git-log: documenting pathspec usage Adam Spiers
2020-11-16 12:37 6% ` Ævar Arnfjörð Bjarmason
2022-06-28 13:25 [PATCH v3 0/8] rebase: update branches in multi-part topic Derrick Stolee via GitGitGadget
2022-07-12 13:06 ` [PATCH v4 00/12] " Derrick Stolee via GitGitGadget
2022-07-12 13:07 ` [PATCH v4 12/12] sequencer: notify user of --update-refs activity Derrick Stolee via GitGitGadget
2022-07-16 22:09 ` Elijah Newren
2022-07-19 16:09 6% ` Derrick Stolee
2024-03-24 21:43 [PATCH] pretty: find pretty formats case-insensitively Brian Lyles
2024-03-25 6:14 ` Jeff King
2024-03-25 18:12 6% ` Junio C Hamano
2017-10-02 0:31 [PATCH v5 0/6] Support %(trailers) arguments in for-each-ref(1) Taylor Blau
2017-10-02 0:32 ` [PATCH v5 1/6] pretty.c: delimit "%(trailers)" arguments with "," Taylor Blau
2017-10-02 0:33 ` [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom Taylor Blau
2017-10-02 5:03 6% ` Jeff King
2017-10-02 5:12 6% ` Taylor Blau
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).