* Re: [PATCH v2 2/7] test-lib: parse some --options earlier
From: Jeff King @ 2019-01-03 4:53 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git, Junio C Hamano
In-Reply-To: <20181230190419.GB6120@szeder.dev>
On Sun, Dec 30, 2018 at 08:04:19PM +0100, SZEDER Gábor wrote:
> > (in fact, given that this is just
> > the internal tests, I am tempted to say that we should just make it
> > "-r<arg>" for the sake of simplicity and consistency. But maybe somebody
> > would be annoyed. I have never used "-r" ever myself).
>
> I didn't even know what '-r' does...
I had to look it up, too. :)
> And I agree that changing it to '-r<arg>' would be the best, but this
> patch series is about adding '--stress', so changing how '-r' gets its
> mandatory argument (and potentially annoying someone) is beyond the
> scope, I would say.
OK, I'm fine with that (though once we've built the infrastructure to
handle its unstuck form, I don't know if there's much point in changing
it, so we can probably just let it live on forever).
-Peff
^ permalink raw reply
* Re: [PATCH v2] Simplify handling of setup_git_directory_gently() failure cases.
From: Jeff King @ 2019-01-03 4:54 UTC (permalink / raw)
To: Erin Dahlgren; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <CAP_Smy0tMe=mq2u6OFBfYzutHvoLETOyRtFEzLVViupjMLVLrA@mail.gmail.com>
On Thu, Dec 27, 2018 at 03:46:10PM -0800, Erin Dahlgren wrote:
> > Heh, I should learn to cut and paste better. This should be:
> >
> > if (!nongit_ok || !*nongit_ok)
> >
> > (which comes from the current code).
>
> Yep, but I think we can benefit from De Morgan's law here, where:
>
> (!nongit_ok || !*nongit_ok) == (!(nongit_ok && *nongit_ok))
>
> PATCH v3 (just sent) uses that transformation like this:
>
> if (nongit_ok && *nongit_ok) {
> ... startup_info->has_repository = 0;
> } else {
> // !nongit_ok || !*nongit_ok
> .. startup_info->has_repository = 1;
> }
>
> Because IMHO (nongit_ok && *nongit_ok) is easier to read and reason
> about. Added brief comments as well.
Ah yes, that's much better.
-Peff
^ permalink raw reply
* Re: [PATCH v3] Simplify handling of setup_git_directory_gently() failure cases.
From: Jeff King @ 2019-01-03 5:14 UTC (permalink / raw)
To: Erin Dahlgren; +Cc: git, Johannes Schindelin, Junio C Hamano
In-Reply-To: <1545953789-15040-1-git-send-email-eedahlgren@gmail.com>
On Thu, Dec 27, 2018 at 03:36:29PM -0800, Erin Dahlgren wrote:
> Before this change are two misleading additional behaviors:
>
> - GIT_DIR_HIT_CEILING: setup_nongit() changes to the cwd for no
> apparent reason. We never had the chance to change directories
> up to this point so chdir(current cwd) is pointless.
> - GIT_DIR_HIT_MOUNT_POINT: strbuf_release() frees the buffer
> of a static struct strbuf (cwd). This is unnecessary because the
> struct is static so its buffer is always reachable. This is also
> misleading because nowhere else in the function is this buffer
> released.
> [..]
Overall this looks good to me, and I'd be fine to see it go in as-is.
A few minor nits/comments, though:
> During review, this change was amended to additionally include:
> [...]
When I find myself writing big bullet lists of changes in a commit
message, that is often a good time to split the commit into several
sub-parts.
This patch isn't _too_ big, so I don't think it's worth the effort at
this point for this particular case, but just something to think about
for the future. A series around this topic would probably be something
like:
1: drop the useless chdir and fold setup_nongit() into the main
function
2: stop doing the early return from HIT_MOUNT_POINT, and treat it just
like HIT_CEILING (and drop the useless strbuf release)
3: treat GIT_DIR_NONE as a BUG
4: rearrange the nongit logic at the end of the function for clarity
> + /*
> + * At this point, nongit_ok is stable. If it is non-NULL and points
> + * to a non-zero value, then this means that we haven't found a
> + * repository and that the caller expects startup_info to reflect
> + * this.
Right, makes sense.
> + *
> + * Regardless of the state of nongit_ok, startup_info->prefix and
> + * the GIT_PREFIX environment variable must always match. For details
> + * see Documentation/config/alias.txt.
> + */
I think this "must match" makes sense to comment. I didn't find
config/alias.txt particularly enlightening in that regard, though. :)
> + if (nongit_ok && *nongit_ok) {
> + startup_info->have_repository = 0;
> + startup_info->prefix = NULL;
> setenv(GIT_PREFIX_ENVIRONMENT, "", 1);
> -
> - startup_info->have_repository = !nongit_ok || !*nongit_ok;
> - startup_info->prefix = prefix;
> + } else {
> + // !nongit_ok || !*nongit_ok
> + startup_info->have_repository = 1;
> + startup_info->prefix = prefix;
> + if (prefix)
> + setenv(GIT_PREFIX_ENVIRONMENT, prefix, 1);
> + else
> + setenv(GIT_PREFIX_ENVIRONMENT, "", 1);
> + }
We usually avoid "//" comments, even for single lines (though that is
perhaps superstition at this point, as we've started to embrace several
other C99-isms). IMHO this particular comment is not even really
necessary, as the whole conditional is suitably short and obvious after
your refactor.
> @@ -1132,7 +1142,10 @@ const char *setup_git_directory_gently(int *nongit_ok)
> * the user has set GIT_DIR. It may be beneficial to disallow bogus
> * GIT_DIR values at some point in the future.
> */
> - if (startup_info->have_repository || getenv(GIT_DIR_ENVIRONMENT)) {
> + if (// GIT_DIR_EXPLICIT, GIT_DIR_DISCOVERED, GIT_DIR_BARE
> + startup_info->have_repository ||
> + // GIT_DIR_EXPLICIT
> + getenv(GIT_DIR_ENVIRONMENT)) {
Same "//" style issue as above. I'm not sure how much value there is in
repeating the GIT_DIR_* cases here, as they're likely to grow out of
sync with the switch() statement above.
At first I thought this could all be folded into the "else" clause of
the conditional above (which would make the logic much easier to
follow), but that wouldn't cover the case of GIT_DIR=/bogus, which is
what that getenv() is trying to handle here.
So I think this is the best we can do for now.
-Peff
^ permalink raw reply
* Re: [PATCH v4 0/3]
From: Jeff King @ 2019-01-03 5:22 UTC (permalink / raw)
To: nbelakovski; +Cc: git, rafa.almas, gitster, avarab
In-Reply-To: <20181224084756.49952-1-nbelakovski@gmail.com>
On Mon, Dec 24, 2018 at 12:47:53AM -0800, nbelakovski@gmail.com wrote:
> From: Nickolai Belakovski <nbelakovski@gmail.com>
>
> > I don't think that works. The default function is always_equal(), which
> > will treat two entries equal if they have the same hash value. I.e., any
> > collisions would be considered a match.
>
> You're absolutely right. I've added a compare function, but I left out the
> functionality for it to work with an entry passed in as a key. Doing so would
> mean the user would have to allocate a worktree struct, which just seems silly
> when the ref is all that's needed (and also defeats the purpose of avoiding
> extra allocations).
Unfortunately, that doesn't quite work. :)
Your compare function has to handle _both_ cases: two keys, or one key
and a keydata.
The former may be called when the hashmap has to compare two entries
internally (e.g., when it has to re-bucket all of the entries after a
resize). Your tests likely wouldn't run into this case in practice,
since you'd only have a handful of worktrees. But if you added, say,
thousands of worktrees and we had to grow the hash midway through the
process, it would segfault. So you do need to handle the case when your
keydata is NULL.
In theory it would also be used for comparisons if we used a more clever
data structure to hold entries within a bucket. But since we just use a
linked list and linear search for now, we don't.
> And while most of the hashmap API seems OK, yea, this is definitely awful. It
> feels like it should just be able to take a key and return either an entry or
> NULL, and do away with entry_or_key and equals_function_data.
In your case, yeah, equals_function_data is not used at all (but there
are a few call-sites which need it to avoid relying on global data).
But the entry_or_key (coupled with keydata) is the magic that lets the
same function be used for both lookups as well as internal entry
comparisons.
I think having two separate comparison functions would make this a lot
more clear, though likely at the cost of having more boilerplate.
-Peff
^ permalink raw reply
* Re: [PATCH v4 1/3] ref-filter: add worktreepath atom
From: Jeff King @ 2019-01-03 5:40 UTC (permalink / raw)
To: nbelakovski; +Cc: git, rafa.almas, gitster, avarab
In-Reply-To: <20181224084756.49952-2-nbelakovski@gmail.com>
On Mon, Dec 24, 2018 at 12:47:54AM -0800, nbelakovski@gmail.com wrote:
> [...]
Thanks for keeping with this. I think we're getting quite close, though
I did find a few small-ish issues.
> @@ -34,6 +36,8 @@ static struct ref_msg {
> "ahead %d, behind %d"
> };
>
> +static struct worktree **worktrees;
> +
Maybe define this near "struct hashmap ref_to_worktree_map" so it's
more obvious that the two are related?
> @@ -75,6 +79,11 @@ static struct expand_data {
> struct object_info info;
> } oi, oi_deref;
>
> +struct ref_to_worktree_entry {
> + struct hashmap_entry ent; /* must be the first member! */
> + struct worktree *wt; /* key is wt->head_ref */
> +};
Indent with spaces?
> -static int used_atom_cnt, need_tagged, need_symref;
> +static int used_atom_cnt, need_tagged, need_symref, has_worktree;
> +static struct hashmap ref_to_worktree_map;
Makes sense. I thought at first has_worktree was a flag that we might
care about between parsing and formatting, but it's really just a flag
to say "we lazy-loaded the worktree list".
> +static int worktree_hashmap_cmpfnc(const void *unused_lookupdata, const void *existing_hashmap_entry_to_test,
> + const void *unused_key, const void *keydata_aka_refname)
> +{
> + const struct ref_to_worktree_entry *e = existing_hashmap_entry_to_test;
> + return strcmp(e->wt->head_ref, keydata_aka_refname);
> +}
So from the discussion in the cover letter, this needs to be more like:
static int worktree_hashmap_cmpfnc(const void *unused_lookupdata,
const void *ve1, const void *ve2,
const void *keydata_aka_refname)
{
const struct ref_to_worktree_entry *e1 = ve1, *e2 = ve2;
return strcmp(e1->wt->head_ref, keydata_aka_refname ?
keydata_aka_refname :
e2->wt->head_ref);
}
> +static int worktree_atom_parser(const struct ref_format *format,
> + struct used_atom *atom,
> + const char *arg,
> + struct strbuf *unused_err)
> +{
> + int i;
> + if (has_worktree)
> + return 0;
Minor style nit, but please put a space between the declarations and the
start of the code (not strictly necessary for a short function which has
no other linebreaks, like the cmpfunc above, but here I think it's
confusing not to).
> + worktrees = get_worktrees(0);
> +
> + hashmap_init(&ref_to_worktree_map, worktree_hashmap_cmpfnc, NULL, 0);
> +
> + for (i = 0; worktrees[i]; i++) {
> + if (worktrees[i]->head_ref) {
> + struct ref_to_worktree_entry *entry;
> + entry = xmalloc(sizeof(*entry));
> + entry->wt = worktrees[i];
> + hashmap_entry_init(entry, strhash(worktrees[i]->head_ref));
> +
> + hashmap_add(&ref_to_worktree_map, entry);
> + }
> + }
Makes sense to load the map.
> +static const char *get_worktree_path(const struct used_atom *atom, const struct ref_array_item *ref)
> +{
> + struct strbuf val = STRBUF_INIT;
> + struct hashmap_entry entry;
> + struct ref_to_worktree_entry *lookup_result;
> +
> + hashmap_entry_init(&entry, strhash(ref->refname));
> + lookup_result = hashmap_get(&ref_to_worktree_map, &entry, ref->refname);
> +
> + strbuf_addstr(&val, lookup_result ? lookup_result->wt->path : "");
> +
> + return strbuf_detach(&val, NULL);
> +}
And that makes sense to look up an item in it. Good.
Adding an empty string to a strbuf is a noop, so that part might more
clearly be written as just:
if (lookup_result)
strbuf_addstr(&val, lookup_result->wt->path);
We return a "const char *" here, but the result is always allocated. Do
we leak the result? Or should this return a "char *"?
I think there are a lot of other atoms that leak currently, but that is
being fixed in another topic that is currently in pu.
> @@ -2020,6 +2085,11 @@ void ref_array_clear(struct ref_array *array)
> free_array_item(array->items[i]);
> FREE_AND_NULL(array->items);
> array->nr = array->alloc = 0;
> + if (has_worktree)
> + {
> + hashmap_free(&ref_to_worktree_map, 1);
> + free_worktrees(worktrees);
> + }
Here we free everything, but we don't unset has_worktree. So anybody
trying to format more refs afterward would see our freed worktree list.
We probably want:
has_worktree = 0;
here. Or simpler still, I think get_worktrees() will always return a
non-NULL list (even if it is empty). So you could just drop has_worktree
entirely, and use:
if (worktrees)
return; /* already loaded */;
in the loading function, and:
free_worktrees(worktrees);
worktrees = NULL;
here.
> +test_expect_success '"add" a worktree' '
> + mkdir worktree_dir &&
> + git worktree add -b master_worktree worktree_dir master
> +'
> +
> +test_expect_success 'validate worktree atom' '
> + {
> + echo master: $PWD &&
> + echo master_worktree: $PWD/worktree_dir &&
> + echo side: not checked out
> + } > expect &&
Minor style nit: use "} >expect" without the extra space.
This checks the actual directories. Good. I can never remember the rules
for when to use $PWD versus $(pwd) on Windows. We may run afoul of the
distinction here.
-Peff
^ permalink raw reply
* Re: [PATCH v4 3/3] branch: Add an extra verbose output displaying worktree path for refs checked out in a linked worktree
From: Jeff King @ 2019-01-03 5:42 UTC (permalink / raw)
To: nbelakovski; +Cc: git, rafa.almas, gitster, avarab
In-Reply-To: <20181224084756.49952-4-nbelakovski@gmail.com>
On Mon, Dec 24, 2018 at 12:47:56AM -0800, nbelakovski@gmail.com wrote:
> From: Nickolai Belakovski <nbelakovski@gmail.com>
>
> ---
> builtin/branch.c | 4 ++++
> 1 file changed, 4 insertions(+)
This patch should describe the new behavior in Documentation/git-branch.txt,
I'd think.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] t0006-date.sh: add `human` date format tests.
From: Junio C Hamano @ 2019-01-03 6:42 UTC (permalink / raw)
To: Stephen & Linda Smith
Cc: git, Linus Torvalds, Ævar Arnfjörð Bjarmason
In-Reply-To: <2832897.SWEsZI4Xea@thunderbird>
Stephen & Linda Smith <ischis2@cox.net> writes:
> On Wednesday, January 2, 2019 11:15:02 AM MST Junio C Hamano wrote:
>> 'date +%s' is used everywhere in this patch but has never been used
>> in our test suite before. It is not portable.
> So I don't make this mistake again, Is there a reference somewhere for that is
> and is not portable?
I usually go to http://pubs.opengroup.org/onlinepubs/9699919799/
Even though we do not say "We'll use anything that is in POSIX.1; it
is your problem if your platform does not support it", we tend to
say "It's not even in POSIX, so let's see if we can avoid it".
>> Using "show" here is much better than "log -1" above; using "show
>> -s" would be even better.
>
> I was attempting to test both git log and git show. For get log the `-1` was
> to only get the latest commit.
>
> Are you suggesting that t4202-log.sh not be updated and that only and t7007-
> show.sh and t0006-date.sh updated?
I am saying that using "log -1" and "show" in different tests _only_
for the value of "Date:" field does not buy us much. And by unifying,
I was hoping that the single helper can be placed in a common file
that is dot-sourced by these three scripts more easily.
Thanks.
^ permalink raw reply
* Re: Parsing trailers
From: Jeff King @ 2019-01-03 7:07 UTC (permalink / raw)
To: William Chargin; +Cc: Git Mailing List
In-Reply-To: <CAFW+GMDazFSDzBrvzMqaPGwew=+CP7tw7G5FfDqcAUYd3qjPuQ@mail.gmail.com>
On Sun, Dec 23, 2018 at 02:41:20PM -0800, William Chargin wrote:
> I'm interested in parsing the output of `git-interpret-trailers` in a
> script. I had hoped that the `--parse` option would make this easy, but
> it seems that the `trailer.separators` configuration option is used to
> specify both the input format (which separators may indicate a trailer)
> and the output format of `git interpret-trailers --parse`. Given that
> `trailer.separators` may contain any (non-NUL) characters, including
> whitespace, parsing the output is not straightforward.
IMHO this is a bug in --parse. It was always meant to give sane,
normalized output, that you could parse with something like:
[^:]+: .*
That's what "%(trailers:only)" does (even if the original separator was
something else). It also trims any extra whitespace.
So I think it would be reasonable to:
1. Add an --output-separator option. This should be uncontroversial.
2. Make --parse imply "--output-separator=:". This might be more
controversial, because it does change the output. But as I said
above, I consider the current behavior to simply be a bug.
3. (Optional) Add a "-z" option which uses "\0" both
within and between trailer records. This obviously solves your
problem without steps 1 and 2, but I think we should have a way to
do it without relying on NULs, since they're harder to work with in
some tools.
-Peff
^ permalink raw reply
* Re: [PATCH v4 1/4] transport-helper: use xread instead of read
From: Jeff King @ 2019-01-03 7:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: randall.s.becker, git, Randall S. Becker
In-Reply-To: <xmqqbm4ykcdk.fsf@gitster-ct.c.googlers.com>
On Wed, Jan 02, 2019 at 12:55:51PM -0800, Junio C Hamano wrote:
> > Signed-off-by: Randall S. Becker <rsbecker@nexbridge.com>
> > ---
> > transport-helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/transport-helper.c b/transport-helper.c
> > index bf225c698f..a290695a12 100644
> > --- a/transport-helper.c
> > +++ b/transport-helper.c
> > @@ -1225,7 +1225,7 @@ static int udt_do_read(struct unidirectional_transfer *t)
> > return 0; /* No space for more. */
> >
> > transfer_debug("%s is readable", t->src_name);
> > - bytes = read(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
> > + bytes = xread(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
> > - if (bytes < 0 && errno != EWOULDBLOCK && errno != EAGAIN &&
> > - errno != EINTR) {
> > + if (bytes < 0 && errno != EINTR) {
> > error_errno(_("read(%s) failed"), t->src_name);
>
> Can't we also lose EINTR check, though? When read() returns
> negative, we check errno and if it is EINTR, continue the loop.
Yes.
I also wondered if this caller might actually be relying on the current
non-looping behavior, but it looks like I already traced through and
determined this was OK:
https://public-inbox.org/git/20180111063110.GB31213@sigill.intra.peff.net/
(the cleanup is correct either way, but that is what makes the
conversion to xread() OK).
We may want to just take the xread() conversion and then do the patch
that I linked above on top, since it also cleans up the xwrite() spot,
too.
-Peff
^ permalink raw reply
* Re: [PATCH v2] doc: remove unneeded TODO for release_commit_memory
From: Junio C Hamano @ 2019-01-03 7:21 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Albert Burt, Git Mailing List, Stefan Beller
In-Reply-To: <CACsJy8B4FCkrV0srm8pvcU41DMWoZwDHgW8Wu0j3nZT5JLhEBA@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Wed, Jan 2, 2019 at 3:09 AM Albert Burt <aburthinds@gmail.com> wrote:
>>
>> Remove TODO that was left in from:
>> commit 110240588d (Merge branch 'sb/object-store-alloc' - 2018-06-25)
>>
>> Todo can be removed as:
>> 9d2c97016f (commit.h: delete 'util' field in struct commit - 2018-05-19)
>> deletes commit->util.
>>
>> Signed-off-by: Albert Burt <aburthinds@gmail.com>
>> ---
>>
>> Thanks for looking at this for me Duy. I updated some of the changes you
>> suggested.
>>
>> Let me know if there's anything else that I would need to clean up, or do better.
>> :)
>
> Nope. The patch looks good to me.
Yes, but we'll fix this with 6a7895fd ("commit: prepare
free_commit_buffer and release_commit_memory for any repo",
2018-12-14) anyway, so I am not sure if this is worth pursuing
separately.
>
>>
>> commit.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/commit.c b/commit.c
>> index 2d94e0b199..2ff6dca0bc 100644
>> --- a/commit.c
>> +++ b/commit.c
>> @@ -357,8 +357,6 @@ void release_commit_memory(struct commit *c)
>> c->index = 0;
>> free_commit_buffer(c);
>> free_commit_list(c->parents);
>> - /* TODO: what about commit->util? */
>> -
>> c->object.parsed = 0;
>> }
>>
>> --
>> 2.17.2 (Apple Git-113)
>>
^ permalink raw reply
* Re: Git extra hook, pre-upload
From: Jeff King @ 2019-01-03 7:29 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Xheroz 128, git
In-Reply-To: <87k1jqem1p.fsf@evledraar.gmail.com>
On Sun, Dec 30, 2018 at 10:34:26PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Sun, Dec 30 2018, Xheroz 128 wrote:
>
> > Currently, I’m doing my Final Year Project that requires a hook that executes automatically on the server side of the repository, before the objects been pulled to the client side, and after the objects have been pushed to the server side, which is "post-receive" hook. The post-receive hook work well for me, but I couldn’t find any hook to be executed immediately before an upload-operation is performed, i.e. before data is sent to the client.
> >
> > Why Git doesn't have a hook that executed immediately before the data is sent to the client? Any advice on getting this hook or any similar function of the hook?
>
> We do not have such a pre-upload hook, but could have one. There's an
> old thread from 2011 detailing some potential downsides:
>
> https://public-inbox.org/git/CAMK1S_jaEWV=F6iHKZw_6u5ncDW0bPosNx-03W9bOLOfEEEY1Q@mail.gmail.com/
>
> FWIW I think most servers who find themselves needing such a hook use it
> to e.g. log how many fetches a given repository might serve, and end up
> instead wrapping git commands in some custom shell.
>
> It's also possible to imagine a much deeper integration for such a hook,
> e.g. something that would allow you to implement the functionality of
> the uploadpack.* variables and more in your own code, but I don't know
> if that's the sort of thing you're imagining.
Since that thread, we've added this config:
uploadpack.packObjectsHook
If this option is set, when upload-pack would run git
pack-objects to create a packfile for a client, it will run
this shell command instead. The pack-objects command and
arguments it would have run (including the git pack-objects
at the beginning) are appended to the shell command. The
stdin and stdout of the hook are treated as if pack-objects
itself was run. I.e., upload-pack will feed input intended
for pack-objects to the hook, and expects a completed
packfile on stdout.
Note that this configuration variable is ignored if it is
seen in the repository-level config (this is a safety
measure against fetching from untrusted repositories).
So:
1. That's some prior art for how an upload-pack hook could behave
without introducing a security problem.
2. Depending on what you want to do, this hook may be enough already.
But it can't do everything (for instance, a fetch which results in
no objects being requested would not trigger the hook at all, so if
you were planning to keep stats about no-op fetches, it would not
work).
-Peff
^ permalink raw reply
* Re: [PATCH 1/3] Add 'human' date format
From: Jeff King @ 2019-01-03 7:37 UTC (permalink / raw)
To: Stephen P . Smith
Cc: git, Linus Torvalds, Junio C Hamano,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20181231003150.8031-2-ischis2@cox.net>
On Sun, Dec 30, 2018 at 05:31:48PM -0700, Stephen P. Smith wrote:
> Also add 'auto' date mode, which defaults to human if we're using the
> pager. So you can do
>
> git config --add log.date auto
>
> and your "git log" commands will show the human-legible format unless
> you're scripting things.
I like the idea of "human", and I like the idea of "auto", but it seems
to me that these are really two orthogonal things. E.g., might some
people not want to do something like:
git config log.date auto:relative
?
I don't personally care about using this myself, but we already had to
deal with retrofitting "local" as a modifier. I'd prefer to avoid making
the same mistake again.
(I'd actually argue that "log.date" should basically _always_ have the
"auto" behavior, since it tends to get treated as plumbing anyway, and I
suspect that anybody who sets log.date now would see subtle breakage
from scripts. But maybe it's too late at this point?).
> diff --git a/builtin/blame.c b/builtin/blame.c
> index 6d798f9939..f684e31d82 100644
> --- a/builtin/blame.c
> +++ b/builtin/blame.c
> @@ -925,6 +925,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
> */
> blame_date_width = utf8_strwidth(_("4 years, 11 months ago")) + 1; /* add the null */
> break;
> + case DATE_HUMAN:
> + /* If the year is shown, no time is shown */
> + blame_date_width = sizeof("Thu Oct 19 16:00");
> + break;
OK, and we expect the year to be less than 5 characters. I briefly
wondered what would happen at Y100K (or somebody maliciously using a
bogus year), but it is not a buffer overflow. It is simply a mis-aligned
blame line (and actually, the same goes for the existing entries, which
use a 4-digit year).
-Peff
^ permalink raw reply
* Re: Parsing trailers
From: William Chargin @ 2019-01-03 7:43 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20190103070744.GA24149@sigill.intra.peff.net>
> That's what "%(trailers:only)" does (even if the original separator was
> something else). It also trims any extra whitespace.
Ooh, this is good to know: thanks. (I had found `print_tok_val` in
`trailer.c` and assumed that this was the only place with the output
logic, but I now see that `format_trailer_info` also exists in the same
file.)
> IMHO this is a bug in --parse. It was always meant to give sane,
> normalized output
Okay; this is good to hear. In that case, what would you think about
changing `interpret-trailers` as a whole to always emit colons? (Note
that the command is already lossy: even with no flags, it replaces each
separator character with the first character of `trailer.separators`.)
This has the advantage that we avoid adding a configuration option of
dubious value—it’s not clear to me why a user would actually _want_ to
change the separator to anything other than a colon. The patch should be
quite simple, too (only tested lightly on my machine):
diff --git a/trailer.c b/trailer.c
index 0796f326b3..722040e48c 100644
--- a/trailer.c
+++ b/trailer.c
@@ -156,7 +156,7 @@ static void print_tok_val(FILE *outfile, const
char *tok, const char *val)
if (strchr(separators, c))
fprintf(outfile, "%s%s\n", tok, val);
else
- fprintf(outfile, "%s%c %s\n", tok, separators[0], val);
+ fprintf(outfile, "%s: %s\n", tok, val);
}
Is this veering too much from “bug fix” toward “backward-incompatible
behavior change” for your comfort?
I agree that either this or your (1) and (2) would eliminate the need
for `-z`, which is nice.
Best,
WC
^ permalink raw reply related
* Re: [PATCH 3/3] t0006-date.sh: add `human` date format tests.
From: Jeff King @ 2019-01-03 7:44 UTC (permalink / raw)
To: Stephen P . Smith
Cc: git, Linus Torvalds, Junio C Hamano,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20181231003150.8031-4-ischis2@cox.net>
On Sun, Dec 30, 2018 at 05:31:50PM -0700, Stephen P. Smith wrote:
> The `human` date format varies based on two inputs: the date in the
> reference time which is constant and the local computers date which
> varies. Using hardcoded test expected output dates would require
> holding the local machines date and time constant which is not
> desireable.
>
> Alternatively, letting the local date vary, which is the normal
> situation, implies that the tests would be checking for formating
> changes based on on a ref date relative to the local computers time.
We already have $TEST_DATE_NOW, which "test-tool date" will respect for
various commands to pretend that it's currently a particular time. I
think you'd need to add a sub-command similar to "relative" (which
directly calls show_date_relative()) which calls into the "human" code.
Note that there _isn't_ a way to have actual non-test git programs read
the current time from an environment variable (as opposed to actually
calling gettimeofday()).
-Peff
^ permalink raw reply
* Re: Parsing trailers
From: Jeff King @ 2019-01-03 7:50 UTC (permalink / raw)
To: William Chargin; +Cc: Git Mailing List
In-Reply-To: <CAFW+GMD9P-E4xCP+K5JAX70a6cgoHUzOXU-Tv3w6yhKGT_GaEg@mail.gmail.com>
On Wed, Jan 02, 2019 at 11:43:55PM -0800, William Chargin wrote:
> > IMHO this is a bug in --parse. It was always meant to give sane,
> > normalized output
>
> Okay; this is good to hear. In that case, what would you think about
> changing `interpret-trailers` as a whole to always emit colons? (Note
> that the command is already lossy: even with no flags, it replaces each
> separator character with the first character of `trailer.separators`.)
> This has the advantage that we avoid adding a configuration option of
> dubious value—it’s not clear to me why a user would actually _want_ to
> change the separator to anything other than a colon. The patch should be
> quite simple, too (only tested lightly on my machine):
>
> diff --git a/trailer.c b/trailer.c
> index 0796f326b3..722040e48c 100644
> --- a/trailer.c
> +++ b/trailer.c
> @@ -156,7 +156,7 @@ static void print_tok_val(FILE *outfile, const
> char *tok, const char *val)
> if (strchr(separators, c))
> fprintf(outfile, "%s%s\n", tok, val);
> else
> - fprintf(outfile, "%s%c %s\n", tok, separators[0], val);
> + fprintf(outfile, "%s: %s\n", tok, val);
> }
>
> Is this veering too much from “bug fix” toward “backward-incompatible
> behavior change” for your comfort?
I think that gets weird in non-parse modes. For example, if I'm not
trying to parse, but rather to _add_ a new trailer (because I'm writing
out a commit message to feed to git-commit-tree), then I'd presumably
want the normal configured separators.
I dunno. I don't think I've ever seen a trailer with a non-colon
separator, nor have I ever used interpret-trailers for anything except
parsing. But it obviously was designed with more flexibility in mind,
and I suspect the patch above has a high chance of breaking something
somewhere. Tying it to --parse seems a lot safer, since that was
introduced exactly for this case.
-Peff
^ permalink raw reply
* Re: git-send-email warnings & process dying of signal 11
From: Rafał Miłecki @ 2019-01-03 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <1e4ac3d5-f6f5-bcce-2f09-0519934289b9@milecki.pl>
On 2019-01-01 23:45, Rafał Miłecki wrote:
> Hello & Happy New Year!
>
> I've recently switched from openSUSE 42.3 (perl 5.18.2 & git 2.13.7) to
> the openSUSE Tumbleweed (perl 5.28.1 & git 2.20.1) and send-email
> doesn't work for me anymore.
>
> FWIW it doesn't seem like a git regression. I've manually installed
> 2.13.7 in my new OS and it also fails.
>
> It basically fails with the:
> Warning: unable to close filehandle __ANONIO__ properly: Bad file
> descriptor at /usr/lib/git/git-send-email line 812.
> Warning: unable to close filehandle __ANONIO__ properly: Bad file
> descriptor at /usr/lib/git/git-send-email line 812.
> error: git-send-email died of signal 11
It appears to be a problem with (my?) perl. I've tried reporting it:
https://rt.perl.org/Public/Bug/Display.html?id=133750
^ permalink raw reply
* Re: [PATCH v4 1/3] ref-filter: add worktreepath atom
From: Eric Sunshine @ 2019-01-03 9:31 UTC (permalink / raw)
To: Jeff King
Cc: Nickolai Belakovski, Git List, Rafael Ascensao, Junio C Hamano,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20190103054043.GG20047@sigill.intra.peff.net>
On Thu, Jan 3, 2019 at 12:40 AM Jeff King <peff@peff.net> wrote:
> On Mon, Dec 24, 2018 at 12:47:54AM -0800, nbelakovski@gmail.com wrote:
> > +test_expect_success 'validate worktree atom' '
> > + {
> > + echo master: $PWD &&
> > + echo master_worktree: $PWD/worktree_dir &&
> > + echo side: not checked out
> > + } > expect &&
>
> Minor style nit: use "} >expect" without the extra space.
An interpolating here-doc would be even more natural:
cat >expect <-EOF &&
master: $(pwd)
master_worktree: $(pwd)/worktree_dir
side: not checked out
EOF
> This checks the actual directories. Good. I can never remember the rules
> for when to use $PWD versus $(pwd) on Windows. We may run afoul of the
> distinction here.
As I understand it, this is exactly a case in which you would need to
use $(pwd); namely, when coming up with an "expect" value. t/README
talks about it.
^ permalink raw reply
* Suspicious fetch-pack behaviour
From: Guilhem Bonnefille @ 2019-01-03 9:52 UTC (permalink / raw)
To: Git List
Hi,
One of my users reported a strange problem: a simple HTTPS clone did
not work with Git 1.8.3.1 on RedHat 7.
I did many tests and I was not able to understand why his clone don't
work while I'm able to do it on other similar host.
Nevertheless, we did more investigations. One of them: a raw strace.
I discovered two strange behaviours:
- fetch-pack closes its standard input and standard output and then
tries to print the references on standard input and finaly dies.
- git-remote-https does not react to fetch-pack death and continue
polling an empty set of FD.
Reading fetch-pack code, the behaviour is explicit:
When "--stateless-rpc" is provided, fd is filled with standard input
and standard ouput which are then closed.
https://git.kernel.org/pub/scm/git/git.git/tree/builtin/fetch-pack.c?h=v1.8.3.1#n156
Reading this, I did not understand why it could work.
Any help appreciated.
Here is the strace's extract:
2801 getdents(3, /* 2 entries */, 32768) = 48
2801 getdents(3, /* 0 entries */, 32768) = 0
2801 close(3) = 0
2801 close(0) = 0
2801 close(1) = 0
2801 fstat(1, 0x7ffe10ab4730) = -1 EBADF (Bad file descriptor)
2801 mmap(NULL, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f220c9e3000
2801 fstat(1, 0x7ffe10ab5040) = -1 EBADF (Bad file descriptor)
2801 write(1, "4df1dbf3224064cc5dd2e4c095da2dda"..., 159) = -1 EBADF
(Bad file descriptor)
2801 exit_group(0) = ?
2801 +++ exited with 0 +++
2769 <... poll resumed> ) = ? ERESTART_RESTARTBLOCK
(Interrupted by signal)
2769 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=2801,
si_uid=7561, si_status=0, si_utime=0, si_stime=0} ---
2769 restart_syscall(<... resuming interrupted poll ...>) = 0
2769 poll(NULL, 0, 1000) = 0 (Timeout)
2769 poll(NULL, 0, 1000) = 0 (Timeout)
2769 poll(NULL, 0, 1000) = 0 (Timeout)
2769 poll(NULL, 0, 1000) = 0 (Timeout)
2769 poll(NULL, 0, 1000) = 0 (Timeout)
2769 poll(NULL, 0, 1000) = 0 (Timeout)
--
Guilhem BONNEFILLE
-=- JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ permalink raw reply
* Re: Regression `git checkout $rev -b branch` while in a `--no-checkout` clone does not check out files
From: Duy Nguyen @ 2019-01-03 10:04 UTC (permalink / raw)
To: Anthony Sottile, Ben Peart; +Cc: Git Mailing List
In-Reply-To: <CA+dzEB=TPxng4YBC4Vfh=ZcctAzRQ+drJ3y2sXwP=JXf+UweSA@mail.gmail.com>
On Wed, Jan 2, 2019 at 11:18 PM Anthony Sottile <asottile@umich.edu> wrote:
> heated a small room but here's the results of the bisect!
>
> fa655d8411cc2d7ffcf898e53a1493c737d7de68 is the first bad commit
> commit fa655d8411cc2d7ffcf898e53a1493c737d7de68
> Author: Ben Peart <Ben.Peart@microsoft.com>
> Date: Thu Aug 16 18:27:11 2018 +0000
>
> checkout: optimize "git checkout -b <new_branch>"
I did test this commit before and could not reproduce. But one thing I
did not notice is I set sparsecheckout on by default. which always
forces this optimization off Turning off sparse checkout, I could
indeed reproduce.
I plan to revert this commit anyway when the new command "git
switch-branch" comes. The optimization will be unconditionally in the
new command without this hack and users are encouraged to use that one
instead of "git checkout".
Meanwhile, let's see if Ben wants to fix this or revert it.
>
> Skip merging the commit, updating the index and working directory if and
> only if we are creating a new branch via "git checkout -b <new_branch>."
> Any other checkout options will still go through the former code path.
>
> If sparse_checkout is on, require the user to manually opt in to this
> optimzed behavior by setting the config setting checkout.optimizeNewBranch
> to true as we will no longer update the skip-worktree bit in the index, nor
> add/remove files in the working directory to reflect the current sparse
> checkout settings.
>
> For comparison, running "git checkout -b <new_branch>" on a large
> repo takes:
>
> 14.6 seconds - without this patch
> 0.3 seconds - with this patch
>
> Signed-off-by: Ben Peart <Ben.Peart@microsoft.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> :040000 040000 817bfb8ef961545a554005d42967b5ab7cfdb041
> e57e576d0d4fb7f25c12a5dcc7651ef6698e961b M Documentation
> :040000 040000 c089f91f4532caa2a17e4f10a1a7ed3aa5d2023c
> 7cf16a0aa288f898a880ffefe82ee7506b83bef4 M builtin
> :040000 040000 adfdb05964a692e03ee07d2e43841f6304d996bd
> 8681416093802b9051599ebea8f63f5a45968e6f M t
> bisect run success
>
>
> Here's the script and invocations:
>
> ```
> #!/usr/bin/env bash
> set -euxo pipefail
>
> rm -rf "$PWD/prefix"
> make prefix="$PWD/prefix" -j8 install
> export PATH="$PWD/prefix/bin:$PATH"
>
> rm -rf src dest
>
> git --version
>
> git init src
> echo hi > src/a
> git -C src add .
> git -C src commit -m "initial commit"
> rev="$(git -C src rev-parse HEAD)"
>
> git clone --no-checkout src dest
> git -C dest checkout "$rev" -b branch
> test -f dest/a
>
> : 'SUCCESS!'
> ```
>
> ```
> git bisect begin
> git bisect bad HEAD
> git bisect good v2.17.1
> git bisect run ./bisect.sh
> ```
>
> Anthony
--
Duy
^ permalink raw reply
* Re: [PATCH] test-lib: check Bash version for '-x' without using shell arrays
From: SZEDER Gábor @ 2019-01-03 11:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Max Kirillov, Carlo Arenas, Jeff King, git
In-Reply-To: <20190101231949.8184-1-szeder.dev@gmail.com>
On Wed, Jan 02, 2019 at 12:19:49AM +0100, SZEDER Gábor wrote:
> To my understanding both shells are right and conform to POSIX,
> because the standard allows both behavior by stating the following
> under '2.8.1 Consequences of Shell Errors':
>
> "An expansion error is one that occurs when the shell expansions
> define in wordexp are carried out (for example, "${x!y}", because
That "define" above always stops my (non-native) English parser for a
moment or two... shouldn't it be s/define/defined/ ?
It's not a copy-paste error, POSIX does indeed write "define" there,
see:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01
(First paragraph below the table and the Notes.)
> '!' is not a valid operator); an implementation may treat these as
> syntax errors if it is able to detect them during tokenization,
> rather than during expansion."
>
^ permalink raw reply
* [PATCH v2] test-lib: check Bash version for '-x' without using shell arrays
From: SZEDER Gábor @ 2019-01-03 11:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Sixt, Max Kirillov, Carlo Arenas, Jeff King,
Eric Sunshine, git, SZEDER Gábor
In-Reply-To: <xmqqa7kjknwp.fsf@gitster-ct.c.googlers.com>
One of our test scripts, 't1510-repo-setup.sh' [1], still can't be
reliably run with '-x' tracing enabled, unless it's executed with a
Bash version supporting BASH_XTRACEFD (since v4.1). We have a lengthy
condition to check the version of the shell running the test script,
and disable tracing if it's not executed with a suitable Bash version
[2].
This condition uses non-portable shell array accesses to easily get
Bash's major and minor version number. This didn't seem to be
problematic, because the simple commands expanding those array
accesses are only executed when the test script is actually run with
Bash. When run with Dash, the only shell I have at hand that doesn't
support shell arrays, there are no issues, as it apparently skips
right over the non-executed simple commands without noticing the
non-supported constructs.
Alas, it has been reported that NetBSD's /bin/sh does complain about
them:
./test-lib.sh: 327: Syntax error: Bad substitution
where line 327 contains the first ${BASH_VERSINFO[0]} array access.
To my understanding both shells are right and conform to POSIX,
because the standard allows both behaviors by stating the following
under '2.8.1 Consequences of Shell Errors' [3]:
"An expansion error is one that occurs when the shell expansions
define in wordexp are carried out (for example, "${x!y}", because
'!' is not a valid operator); an implementation may treat these as
syntax errors if it is able to detect them during tokenization,
rather than during expansion."
Avoid this issue with NetBSD's /bin/sh (and potentially with other,
less common shells) by hiding the shell array syntax behind 'eval'
that is only executed with Bash.
[1] 5827506928 (t1510-repo-setup: mark as untraceable with '-x',
2018-02-24)
[2] 5fc98e79fc (t: add means to disable '-x' tracing for individual
test scripts, 2018-02-24)
[3] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_01
Reported-by: Max Kirillov <max@max630.net>
Helped-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com>
---
Changes since v1:
- Hide the shell array syntax behind 'eval'.
(I'm fine with both versions, take your pick.)
- Corrected typo in commit message that Eric pointed out.
- Added a link to the relevant section in POSIX.
t/test-lib.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0f1faa24b2..c34831a4de 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -323,12 +323,12 @@ do
# this test is marked as such, and ignore '-x' if it
# isn't executed with a suitable Bash version.
if test -z "$test_untraceable" || {
- test -n "$BASH_VERSION" && {
+ test -n "$BASH_VERSION" && eval '
test ${BASH_VERSINFO[0]} -gt 4 || {
test ${BASH_VERSINFO[0]} -eq 4 &&
test ${BASH_VERSINFO[1]} -ge 1
}
- }
+ '
}
then
trace=t
--
2.20.1.151.gec613c4b75
^ permalink raw reply related
* Re: [PATCH 3/3] t0006-date.sh: add `human` date format tests.
From: Stephen & Linda Smith @ 2019-01-03 13:12 UTC (permalink / raw)
To: Jeff King
Cc: git, Linus Torvalds, Junio C Hamano,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20190103074421.GC24925@sigill.intra.peff.net>
On Thursday, January 3, 2019 12:44:22 AM MST Jeff King wrote:
> We already have $TEST_DATE_NOW, which "test-tool date" will respect for
> various commands to pretend that it's currently a particular time. I
> think you'd need to add a sub-command similar to "relative" (which
> directly calls show_date_relative()) which calls into the "human" code.
I'll investigate. Looks like this comment is related other comments.
> Note that there _isn't_ a way to have actual non-test git programs read
> the current time from an environment variable (as opposed to actually
> calling gettimeofday()).
Agreed
>
> -Peff
^ permalink raw reply
* Re: [PATCH 1/3] Add 'human' date format
From: Stephen P. Smith @ 2019-01-03 13:19 UTC (permalink / raw)
To: Jeff King
Cc: git, Linus Torvalds, Junio C Hamano,
Ævar Arnfjörð Bjarmason
In-Reply-To: <20190103073735.GB24925@sigill.intra.peff.net>
On Thursday, January 3, 2019 12:37:35 AM MST Jeff King wrote:
> I like the idea of "human", and I like the idea of "auto", but it seems
> to me that these are really two orthogonal things. E.g., might some
> people not want to do something like:
>
> git config log.date auto:relative
I didn't see anything in the code which would prohibit setting something like
that.
>
> I don't personally care about using this myself, but we already had to
> deal with retrofitting "local" as a modifier. I'd prefer to avoid making
> the same mistake again.
Since I wasn't involved could you summarize the you are referring to?
>
> (I'd actually argue that "log.date" should basically _always_ have the
> "auto" behavior, since it tends to get treated as plumbing anyway, and I
> suspect that anybody who sets log.date now would see subtle breakage
> from scripts. But maybe it's too late at this point?).
If auto isn't added to the "log.date" file, then the date behaviour is not
changed from is currently in the code base. Therefore, there shouldn't be
any breakage.
>
> > diff --git a/builtin/blame.c b/builtin/blame.c
> > index 6d798f9939..f684e31d82 100644
> > --- a/builtin/blame.c
> > +++ b/builtin/blame.c
> > @@ -925,6 +925,10 @@ int cmd_blame(int argc, const char **argv, const char
> > *prefix)>
> > */
> >
> > blame_date_width = utf8_strwidth(_("4 years, 11 months ago")) + 1; /*
> > add the null */ break;
> >
> > + case DATE_HUMAN:
> > + /* If the year is shown, no time is shown */
> > + blame_date_width = sizeof("Thu Oct 19 16:00");
> > + break;
>
> OK, and we expect the year to be less than 5 characters. I briefly
> wondered what would happen at Y100K (or somebody maliciously using a
> bogus year), but it is not a buffer overflow. It is simply a mis-aligned
> blame line (and actually, the same goes for the existing entries, which
> use a 4-digit year).
>
> -Peff
^ permalink raw reply
* Re: [PATCH 3/3] t0006-date.sh: add `human` date format tests.
From: Stephen P. Smith @ 2019-01-03 13:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Linus Torvalds, Ævar Arnfjörð Bjarmason
In-Reply-To: <xmqqk1jmi6nn.fsf@gitster-ct.c.googlers.com>
On Wednesday, January 2, 2019 11:42:20 PM MST Junio C Hamano wrote:
> > Are you suggesting that t4202-log.sh not be updated and that only and
> > t7007- show.sh and t0006-date.sh updated?
>
> I am saying that using "log -1" and "show" in different tests _only_
> for the value of "Date:" field does not buy us much. And by unifying,
> I was hoping that the single helper can be placed in a common file
> that is dot-sourced by these three scripts more easily.
Thanks for the clarification.
^ permalink raw reply
* ps/stash-in-c, was Re: What's cooking in git.git (Dec 2018, #02; Fri, 28)
From: Johannes Schindelin @ 2019-01-03 13:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqh8explya.fsf@gitster-ct.c.googlers.com>
Hi Junio,
On Fri, 28 Dec 2018, Junio C Hamano wrote:
> * ps/stash-in-c (2018-11-26) 22 commits
> . stash: replace all `write-tree` child processes with API calls
> . stash: optimize `get_untracked_files()` and `check_changes()`
> . stash: convert `stash--helper.c` into `stash.c`
> . stash: convert save to builtin
> . stash: make push -q quiet
> . stash: convert push to builtin
> . stash: convert create to builtin
> . stash: convert store to builtin
> . stash: convert show to builtin
> . stash: convert list to builtin
> . stash: convert pop to builtin
> . stash: convert branch to builtin
> . stash: convert drop and clear to builtin
> . stash: convert apply to builtin
> . stash: mention options in `show` synopsis
> . stash: add tests for `git stash show` config
> . stash: rename test cases to be more descriptive
> . t3903: modernize style
> . stash: improve option parsing test coverage
> . strbuf.c: add `strbuf_insertf()` and `strbuf_vinsertf()`
> . strbuf.c: add `strbuf_join_argv()`
> . sha1-name.c: add `get_oidf()` which acts like `get_oid()`
>
> "git stash" rewritten in C.
>
> Expecting a reroll, probably on top of the sd/stash-wo-user-name
> topic after it stabilizes, with an escape hatch like the one in
> "rebase in C".
There you go:
https://public-inbox.org/git/cover.1545331726.git.ungureanupaulsebastian@gmail.com/
Happy new year!
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox