Nickolai Belakovski writes:
> Either way, I do see an issue with the current code that anybody who
> wants to know the lock status and/or lock reason of a worktree gets
> faced with a confusing, misleading, and opaque piece of code.
Sorry, I don't. I do not mind a better documentation for
is_wo
On Mon, Oct 29, 2018 at 1:45 AM Nickolai Belakovski
wrote:
> On Sun, Oct 28, 2018 at 9:01 PM Eric Sunshine wrote:
> > That said, I wouldn't necessarily oppose renaming the function, but I
> > also don't think it's particularly important to do so.
>
> To me, I would just go lookup the signature of
Denton Liu writes:
> This adds the --fetch option to `git remote set-url` such that when
> executed we move the remote.*.url to remote.*.pushurl and set
> remote.*.url to the given url argument.
>
I suspect this is a horrible idea from end-user's point of view.
"set-url --push" is used to SET pu
On Sun, Oct 28, 2018 at 9:01 PM Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 9:11 PM Nickolai Belakovski
> wrote:
> > I would also suggest renaming is_worktree_locked to
> > worktree_lock_reason, the former makes me think the function is
> > returning a boolean, whereas the latter more clearl
On Sun, Oct 28, 2018 at 8:52 PM Junio C Hamano wrote:
>
>
> If the field "reason" should always be populated, there is *no*
> reason why we need the "valid" boolean. They work as a pair to
> realize lazy population of rarely used field. The lazy evaluation
> technique is used as an optimization
Ævar Arnfjörð Bjarmason writes:
> Add DWYM support for pushing a ref in refs/remotes/* when the
I think most people call it do-what-*I*-mean, not do-what-you-mean.
> ref is unqualified. Now instead of erroring out we support e.g.:
>
> $ ./git-push avar refs/remotes/origin/master:upstream-
Ævar Arnfjörð Bjarmason writes:
> Add a test asserting that "git push origin :" where is
> a branch, tag, tree or blob in refs/remotes/* doesn't DWYM when
> is unqualified. This has never worked, but there's been no test for
> this behavior.
"has never worked" sounded as if there is a breakag
Ævar Arnfjörð Bjarmason writes:
> + if (!advice_push_unqualified_ref_name)
> + return;
> +
> + if (get_oid(matched_src_name, &oid))
> + BUG("'%s' is not a valid object, "
> + "match_explicit_lhs() should catch this!",
> + matched_sr
Ævar Arnfjörð Bjarmason writes:
> Improve the error message added in f8aae12034 ("push: allow
> unqualified dest refspecs to DWIM", 2008-04-23), which before this
> change looks like this:
>
> $ git push avar v2.19.0^{commit}:newbranch -n
> error: unable to push to unqualified destinatio
Anders Waldenborg writes:
> This new format placeholder allows displaying only a single
> trailer. The formatting done is similar to what is done for
> --decorate/%d using parentheses and comma separation.
>
> It's intended use is for things like ticket references in trailers.
>
> So with a commi
Junio C Hamano writes:
> To put it another way, I would think both of these two have at most
> the same probability that the push wants to go to a local branch:
>
> git push refs/remotes/foo:foo
> git push :foo
>
> and I would further say that the former is less likely than the
> latt
On Sun, Oct 28, 2018 at 9:11 PM Nickolai Belakovski
wrote:
> On Sun, Oct 28, 2018 at 4:03 PM Eric Sunshine wrote:
> > Aside from that, it doesn't seem like worktree needs any changes for
> > the ref-filter atom you have in mind. (Don't interpret this
> > observation as me being averse to changes
Nickolai Belakovski writes:
> This is an improvement because it fixes an issue in which the fields
> lock_reason and lock_reason_valid of the worktree struct were not
> being populated.
If the field "reason" should always be populated, there is *no*
reason why we need the "valid" boolean. They
Jeff King writes:
> Hmph. So I was speaking before purely hypothetically, but now that your
> patch is in 'next', it is part of my daily build. And indeed, I hit a
> false positive within 5 minutes of building it. ;)
Sounds like somebody is having not-so-fun-a-time having "I told you
so" moment.
Stefan Beller writes:
> Thanks Jonathan for your thoughtful comments,
> here is the product of the discussion:
Can you use v$n in the subject (if these rerolls are meant for
application and not primarily for discussion, that is)? It quickly
gets confusing to see many messages with the same subj
Eric Sunshine writes:
>> diff --git a/sequencer.c b/sequencer.c
>> @@ -2849,10 +2849,14 @@ static int do_reset(const char *name, int len,
>> struct replay_opts *opts)
>> /* Determine the length of the label */
>> + for (i = 0; i < len; i++) {
>> +
SZEDER Gábor writes:
> The test in question runs
>
> test_i18ngrep ! "refusing to lose untracked file at" err
>
> which fails in normal test runs, because 'grep' does find the
> undesired string; that's the known breakage. Under GETTEXT_POISION,
> however, 'test_i18ngrep' always succeeds becau
Glenn Strauss writes:
> use "GIT_HTTP_EXPORT_ALL" => "1" with a value for best compatiblity.
> lighttpd 1.4.51 setenv.add-environment does add vars with empty value.
> lighttpd setenv.set-environment does, but was only introduced in 1.4.46
>
> git-http-backend may be found at /usr/libexec/git-cor
Alban Gruin writes:
> At the center of the "interactive" part of the interactive rebase lies
> the todo list. When the user starts an interactive rebase, a todo list
> is generated, presented to the user (who then edits it using a text
> editor), read back, and then is checked and processed befo
Duy Nguyen writes:
>> Nice analyzes.
>> I have one question here:
>> If the user specifies '**' and nothing is found,
>> would it be better to die() with a useful message
>> instead of silently correcting it ?
>
> Consider the main use case of wildmatch, .gitignore patterns, dying
> would be real
Jeff King writes:
> Cases like this are kind of weird. I'd expect to see wait_all() return
> immediately when !HAVE_THREADS. But we don't need to, because later we
> do this:
>
>> -if (num_threads)
>> +if (HAVE_THREADS && num_threads)
>> hit |= wait_all();
>
> Which I think w
Nguyễn Thái Ngọc Duy writes:
> Compared to the version on 'pu', this one moves all the config files
> to Documentation/config/ directory. imap.* is also added back in
> config.txt (curently only documented in git-imap-send.txt)
The other biggie seems to be http.* that are now in a separate
file
Ramsay Jones writes:
> ...
>24 clear_contains_cache
> $
>
> you will find 24 copies of the commit-slab routines for the contains_cache.
> Of course, when you enable optimizations again, these duplicate static
> functions (mostly) disappear. Compiling with gcc at -O2, leaves two static
>
On Sun, Oct 28, 2018 at 4:03 PM Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 5:55 PM Nickolai Belakovski
> > wrote: This was meant to be a reply to
> > https://public-inbox.org/git/cac05386f1x7tspr6kgkulwewsmdiq4vktf5rxahvzpkwbmx...@mail.gmail.com/T/#m8898c8f7c68e1ea234aca21cb2d7776b375c6f51,
Ævar Arnfjörð Bjarmason writes:
> I was going to submit an update to this, as an additional improvement
> can anyone think of a reason not to always infer that we'd like a new
> branch if the LHS of the refspec starts with refs/remotes/* ?
Depends on what purpose the remote you are pushing into
Jeff King writes:
> Of course any cache raises questions of cache invalidation, but I think
> we've already dealt with that for this case. When we use
> OBJECT_INFO_QUICK, that is a sign that we want to make this kind of
> accuracy/speed tradeoff (which does a similar caching thing with
> packfil
"brian m. carlson" writes:
>> > +
>> > +#include "git-compat-util.h"
>>
>> this shouldn't be needed and might be discouraged as per the
>> instructions in Documentation/CodingGuidelines
>
> This may not strictly be needed, but removing it makes the header no
> longer self-contained, which blows
Matthew DeVore writes:
> When a command is invoked with both --exclude-promisor-objects,
> --objects-edge-aggressive, and a missing object on the command line,
> the rev_info.cmdline array could get a NULL pointer for the value of
> an 'item' field. Prevent dereferencing of a NULL pointer in that
On Sun, Oct 28, 2018 at 5:55 PM Nickolai Belakovski
> wrote: This was meant to be a reply to
> https://public-inbox.org/git/cac05386f1x7tspr6kgkulwewsmdiq4vktf5rxahvzpkwbmx...@mail.gmail.com/T/#m8898c8f7c68e1ea234aca21cb2d7776b375c6f51,
> please look there for some more context. I think it both di
Change the pack-objects tests to not leave their .git directory
corrupt and the end.
In 2fca19fbb5 ("fix multiple issues with t5300", 2010-02-03) a comment
was added warning against adding any subsequent tests, but since
4614043c8f ("index-pack: use streaming interface for collision test on
large
Add a new core.checkCollisions setting. On by default, it can be set
to 'false' to disable the check for existing objects in sha1_object().
As noted in the documentation being added here this is done out of
paranoia about future SHA-1 collisions and as a canary (redundant to
"git fsck") for local
This patch series implements what I suggested in
https://public-inbox.org/git/87lg6jljmf@evledraar.gmail.com/
It's not a replacement for what Geert Jansen's RFC in
https://public-inbox.org/git/ed25e182-c296-4d08-8170-340567d89...@amazon.com/
does, which was to turn this off entirely on "clone"
Change a test added in 51054177b3 ("index-pack: detect local
corruption in collision check", 2017-04-01) so that the repository
isn't left dirty at the end.
Due to the caveats explained in 720dae5a19 ("config doc: elaborate on
fetch.fsckObjects security", 2018-07-27) even a "fetch" that fails
will
Modernize the quoting and indentation style of two tests added in
8685da4256 ("don't ever allow SHA1 collisions to exist by fetching a
pack", 2007-03-20), and of a subsequent one added in
4614043c8f ("index-pack: use streaming interface for collision test on
large blobs", 2012-05-24) which had copi
This was meant to be a reply to
https://public-inbox.org/git/cac05386f1x7tspr6kgkulwewsmdiq4vktf5rxahvzpkwbmx...@mail.gmail.com/T/#m8898c8f7c68e1ea234aca21cb2d7776b375c6f51,
please look there for some more context. I think it both did and
didn't get listed as a reply? In my mailbox I see two separa
On Sun, 28 Oct 2018 at 20:01, Eric Sunshine wrote:
>
> On Sun, Oct 28, 2018 at 11:32 AM Martin Ågren wrote:
> > [...]
> > Let's be explicit about breaking out of the loop. This helps the
> > compiler grok our intention. As a bonus, it might make it (even) more
> > obvious to human readers that th
On Sun, Oct 28, 2018 at 11:32 AM Martin Ågren wrote:
> [...]
> Let's be explicit about breaking out of the loop. This helps the
> compiler grok our intention. As a bonus, it might make it (even) more
> obvious to human readers that the loop stops at the first space.
This did come up in review[1,2
Hello Dear,
how are you today,I hope you are doing great.
It is my great pleasure to contact you,I want to make a new and special
friend,I hope you don't mind. My name is Tracy William from the United States,
Am a french and English nationality. I will give you pictures and more details
a
On Wed, Oct 24, 2018 at 08:02:55PM -0700, Carlo Arenas wrote:
> On Wed, Oct 24, 2018 at 7:41 PM brian m. carlson
> wrote:
> > diff --git a/sha256/block/sha256.h b/sha256/block/sha256.h
> > new file mode 100644
> > index 00..38f02f7e6c
> > --- /dev/null
> > +++ b/sha256/block/sha256.h
> > @
On Sat, Oct 27, 2018 at 02:47:47AM +0100, Ramsay Jones wrote:
>
> I have some changes to the hdr-check Makefile target in the works, but
> these clean-ups don't have to be held up by those changes.
>
> The 'fetch-object.h' patch is the same one I sent separately last time,
> since it only applied
When we find a space, we set `len = i`, which gives us the answer we are
looking for, but which also breaks out of the loop through these steps:
1. `len = i`
2. `i = i + 1`
3. Is `i < len`? No, so break out.
Since `i` is signed, step 2 is undefined if `i` has the value `INT_MAX`.
It can't
This new format placeholder allows displaying only a single
trailer. The formatting done is similar to what is done for
--decorate/%d using parentheses and comma separation.
It's intended use is for things like ticket references in trailers.
So with a commit with a message like:
> Some good com
On Sun, Oct 28, 2018 at 06:41:06AM +0100, Duy Nguyen wrote:
> Something fishy is going on but I don't think I'll spend time hunting
> it down so I post here in case somebody else is interested. It might
> also indicate a problem with poison gettext, not the test case too.
I haven't actually run th
I'm not sure if Junio still takes .po patches or only Jiang Xin does.
I CC Jiang here just in case.
On Thu, Oct 25, 2018 at 3:05 AM Minh Nguyen wrote:
>
> ---
> po/vi.po | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/po/vi.po b/po/vi.po
> index bc79319b6..e646825ed 10
44 matches
Mail list logo
