* Re: 2.11.0-rc1 will not be tagged for a few days
From: Junio C Hamano @ 2016-11-11 0:26 UTC (permalink / raw)
To: git
In-Reply-To: <xmqqoa1n57u4.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I'll report back an updated schedule when able.
>
> I pushed some updates out on 'master' today. Between 'master' and
> 'pu' on the first-parent history there is a merge 52975d2b1f ("Merge
> branch 'ls/macos-update' into jch", 2016-11-10) and that matches
> what I expect to be in -rc1 tomorrow (modulo RelNotes and the actual
> version tag), unless there is a showstopper regresion reported, in
> which case we may want to first look into reverting the whole series
> that introduced the regression before considering to pile on fix-up
> patches.
Please make that 71d1bcb661 ("Merge branch 'ls/macos-update' into
jch", 2016-11-10); among the three extra topics that is not yet in
'master', as/merge-attr-sleep topic has been updated with a better
fix from Dscho.
Thanks.
^ permalink raw reply
* Re: [PATCH] fetch: do not redundantly calculate tag refmap
From: Jeff King @ 2016-11-11 2:09 UTC (permalink / raw)
To: Jonathan Tan; +Cc: git
In-Reply-To: <1478823208-10647-1-git-send-email-jonathantanmy@google.com>
On Thu, Nov 10, 2016 at 04:13:28PM -0800, Jonathan Tan wrote:
> builtin/fetch.c redundantly calculates refmaps for tags twice. Remove
> the first calculation.
>
> This is only a code simplification and slight performance improvement -
> the result is unchanged, as the redundant refmaps are subsequently
> removed by the invocation to "ref_remove_duplicates" anyway.
>
> This was introduced in commit c5a84e9 ("fetch --tags: fetch tags *in
> addition to* other stuff", 2013-10-29) when modifying the effect of the
> --tags parameter to "git fetch". The refmap-for-tag calculation was
> copied instead of moved.
>
> Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
> ---
>
> (I noticed this when working on something in this file.)
Coincidentally I noticed this a few weeks ago, too, while working on
[1], but didn't follow it up. Mainly I was worried there was something
hidden or clever going on, but I think it really is just a case of the
code growing the two calls over time. So this looks good to me. Thanks
for digging it up.
-Peff
[1] http://public-inbox.org/git/20161024132932.i42rqn2vlpocqmkq@sigill.intra.peff.net/
^ permalink raw reply
* Re: [PATCH v7 03/17] ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
From: Jacob Keller @ 2016-11-11 5:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karthik Nayak, Git mailing list
In-Reply-To: <xmqqoa1m5335.fsf@gitster.mtv.corp.google.com>
On Thu, Nov 10, 2016 at 3:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>>> @@ -49,6 +51,10 @@ static struct used_atom {
>>> enum { C_BARE, C_BODY, C_BODY_DEP, C_LINES, C_SIG, C_SUB } option;
>>> unsigned int nlines;
>>> } contents;
>>> + struct {
>>> + const char *if_equals,
>>> + *not_equals;
>>
>>
>> Same here, why do we need both strings here stored separately? Could
>> we instead store which state to check and store the string once? I'm
>> not sure that really buys us any storage.
>
> I am not sure if storage is an issue, but I tend to agree that it
> would be semantically cleaner if this was done as a pair of <what
> operation uses this string constant?, the string constant>, and the
> former would be enum { COMPARE_EQUAL, COMPARE_UNEQUAL}.
>
> You could later enhance the comparison operator more easily with
> such an arrangement (e.g. if-equals-case-insensitively).
The main advantage I see is that it ensures in the API that there is
no way for it to be both "equal" and "not equal" at the same time,
where as two separate pointers while not actually done in practice
could both be set somehow, leading to potential questions.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v7 03/17] ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>)
From: Jacob Keller @ 2016-11-11 5:27 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <CAOLa=ZQCP2KtgLQie5p+PBiFjiNVFduUh=AmuLWcOKX5QA_BXA@mail.gmail.com>
On Thu, Nov 10, 2016 at 9:31 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
> On Wed, Nov 9, 2016 at 4:52 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
>>
>> Ok. How does this handle whitespace? The previous if implementation
>> treated whitespace as trimming to ignore. Does this require an exact
>> whitespace match? It appears by the code that strings must match
>> exactly. Would it make more sense to always trim the value of
>> whitespace first before comparison? Hmm.. I think we should avoid
>> doing that actually.
>>
>
> This does not trim whitespace what so ever and requires an exact match.
> I don't see the reason behind trimming whitespace though.
>
The comment was made in reference to the fact that %(if)<atom>%(then)
essentially trims whitespace, since if the <atom> prints only
whitespace it does not match.
Thus, it might make sense to keep it all the same and have this trim
as well. However, I think there is no benefit or reasoning to do so in
this case.
Thanks,
Jake
^ permalink raw reply
* Re: [PATCH v7 04/17] ref-filter: modify "%(objectname:short)" to take length
From: Jacob Keller @ 2016-11-11 5:29 UTC (permalink / raw)
To: Karthik Nayak; +Cc: Git mailing list
In-Reply-To: <CAOLa=ZRDNGGc-OA+d+T1=9JvoVe2eBZt0DYQEHmeNKhDpxQbdg@mail.gmail.com>
On Thu, Nov 10, 2016 at 9:36 AM, Karthik Nayak <karthik.188@gmail.com> wrote:
> On Wed, Nov 9, 2016 at 4:57 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
>>> From: Karthik Nayak <karthik.188@gmail.com>
>>>
>>> Add support for %(objectname:short=<length>) which would print the
>>> abbreviated unique objectname of given length. When no length is
>>> specified, the length is 'DEFAULT_ABBREV'. The minimum length is
>>> 'MINIMUM_ABBREV'. The length may be exceeded to ensure that the provided
>>> object name is unique.
>>>
>>
>> Ok this makes sense. It may be annoying that the length might go
>> beyond the size that we wanted, but I think it's better than printing
>> a non-unique short abbreviation.
>>
>> I have one suggested change, which is to drop O_LENGTH and have
>> O_SHORT store the length always, setting it to DEFAULT_ABBREV when no
>> length provided. This allows you to drop some code. I don't think it's
>> actually worth a re-roll by itself since the current code is correct.
>>
>> Thanks,
>> Jake
>>
>
> That does make sense, It would also not error out when we use
> %(objectname:short=) and
> not specify the length. Idk, if that's desirable or not. But it does
> make the code a little more
> confusing to read at the same time.
>
I am not sure that would be the case. If you see "objectname:short"
you trreat this as if they had passed "objectname:short=<default
abbrev>" but if you see "objectname:short=" you die, no?
> So since its a small change, I'd be okay going either ways with this.
>
> --
> Regards,
> Karthik Nayak
^ permalink raw reply
* Re: [PATCH] t6026: ensure that long-running script really is
From: Johannes Sixt @ 2016-11-11 6:50 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git, Jeff King, Andreas Schwab
In-Reply-To: <xmqqfumy51tk.fsf@gitster.mtv.corp.google.com>
Am 11.11.2016 um 00:53 schrieb Junio C Hamano:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
>> When making sure that background tasks are cleaned up in 5babb5b
>> (t6026-merge-attr: clean up background process at end of test case,
>> 2016-09-07), we considered to let the background task sleep longer, just
>> to be certain that it will still be running when we want to kill it
>> after the test.
>>
>> Sadly, the assumption appears not to hold true that the test case passes
>> quickly enough to kill the background task within a second.
>>
>> Simply increase it to an hour. No system can be possibly slow enough to
>> make above-mentioned assumption incorrect.
>>
>> Reported by Andreas Schwab.
>>
>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> ---
>> Published-As: https://github.com/dscho/git/releases/tag/t6026-sleep-v1
>> Fetch-It-Via: git fetch https://github.com/dscho/git t6026-sleep-v1
>
> OK, I think this is a much better option. Assuming 3600 is long
> enough for everybody (and if not, we have a bigger problem ;-),
> it will ensure that the stray process will be around when we run the
> 'git merge' test, and by not adding "|| :" after the kill, we check
> that the stray process is still there, i.e. we tested what we wanted
> to test.
>
> Will revert the two patches that were queued previously and then
> queue this one.
Shouldn't we then move the 'kill' out of test_when_finished and make
it a proper condition of the test? Like this?
diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
index 348d78b205..6ad8bd098a 100755
--- a/t/t6026-merge-attr.sh
+++ b/t/t6026-merge-attr.sh
@@ -187,13 +187,19 @@ test_expect_success 'custom merge does not lock index' '
sleep 3600 &
echo $! >sleep.pid
EOF
- test_when_finished "kill \$(cat sleep.pid)" &&
test_write_lines >.gitattributes \
"* merge=ours" "text merge=sleep-an-hour" &&
test_config merge.ours.driver true &&
test_config merge.sleep-an-hour.driver ./sleep-an-hour.sh &&
- git merge master
+ git merge master &&
+
+ # We are testing that the custom merge driver does not block
+ # index.lock on Windows due to an inherited file handle.
+ # To ensure that this test checks this condition, the process
+ # must still be running at this point (and must have started
+ # in the first place), hence, this kill must not fail:
+ kill "$(cat sleep.pid)"
'
test_done
^ permalink raw reply related
* [credential.helper] unexpectedly save credential to multiple credential files
From: Qi Nark @ 2016-11-11 8:10 UTC (permalink / raw)
To: git
1. git config --global credential.helper store
2. cd to a local repository directory, git config credential.helper
store --file ./my_cred
3. execute some git command which need credential like git ls-remote
4. input my username & password, command done.
As the result, **BOTH** the ./my_cred and ~/.git-credentials will save
the credentials I just input. But, shouldn't the local config override
the global ones, and only the ./my_cred should save it?
Thx.
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Lars Schneider @ 2016-11-11 8:22 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Torsten Bögershausen, git, Eric Sunshine,
hvoigt
In-Reply-To: <20161110161012.jube4bwbww2wa2ew@sigill.intra.peff.net>
On 10 Nov 2016, at 17:10, Jeff King <peff@peff.net> wrote:
> On Thu, Nov 10, 2016 at 12:07:14PM +0100, Lars Schneider wrote:
>
>>> Using Apache in the tests has been the source of frequent portability
>>> problems and configuration headaches. I do wonder if we'd be better off
>>> using some small special-purpose web server (even a short perl script
>>> written around HTTP::Server::Simple or something).
>>>
>>> On the other hand, testing against Apache approximates a more real-world
>>> case, which has value. It might be nice if our tests supported multiple
>>> web servers, but that would mean duplicating the config for each
>>> manually.
>>
>> I agree that the real-world Apache test is more valuable and I really want
>> to keep the Linux Apache test running. However, I don't think many people
>> use macOS as Git web server and therefore I thought it is not worth the
>> effort to investigate this problem further.
>
> IMHO, the value in the http tests is not testing the server side, but
> the client side. Without being able to set up a dummy HTTP server, we do
> not have any way to exercise the client side of git-over-http at all.
> And people on macOS _do_ use that. :)
Well, I haven't seen it from that perspective, yet, but I agree :-)
To all macOS users on the list:
Does anyone execute the tests with GIT_TEST_HTTPD enabled successfully?
There would be an alternative way to approach the problem:
Someone (GitHub?, BitBucket?, GitLab?, ...) could setup a bunch of webservers
with popular configurations and a way to reset a clean test environment. Then
the TravisCI client tests could go against these servers.
I realize that this idea is probably unrealistic because too much setup and
maintenance work would be required.
Cheers,
Lars
^ permalink raw reply
* Re: [git-for-windows] [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0
From: Lars Schneider @ 2016-11-11 8:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git-for-windows, Git Mailing List, me
In-Reply-To: <alpine.DEB.2.20.1611102237230.24684@virtualbox>
On 10 Nov 2016, at 22:39, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:
> Hi Lars,
>
> On Wed, 9 Nov 2016, Lars Schneider wrote:
>
>> On 05 Nov 2016, at 10:50, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:
>>
>>> I finally got around to rebase the Windows-specific patches (which seem to
>>> not make it upstream as fast as we get new ones) on top of upstream Git
>>> v2.11.0-rc0, and to bundle installers, portable Git and MinGit [*1*]:
>>>
>>> https://github.com/git-for-windows/git/releases/tag/v2.11.0-rc0.windows.1
>>
>>
>> I tested a new feature in 2.11 on Windows today and it failed. After some
>> confusion I realized that the feature is not on your 2.11 branch.
>
> Oops. That must have been a major snafu on my side, very sorry for that.
>
> I just tagged v2.11.0-rc0.windows.2 in https://github.com/dscho/git and
> will make a new prerelease tomorrow.
No worries! I am looking forward to the new release!
For some reason my own build of Git for Windows cannot use HTTPS properly.
I need to debug this further at some point.
Thanks,
Lars
^ permalink raw reply
* Re: [credential.helper] unexpectedly save credential to multiple credential files
From: Jeff King @ 2016-11-11 8:36 UTC (permalink / raw)
To: Qi Nark; +Cc: git
In-Reply-To: <CACNr1V_fRfqvHUN=AQC8-Dj7ZAE7KXRAt+5skL3ZrcKu7SCLgA@mail.gmail.com>
On Fri, Nov 11, 2016 at 04:10:55PM +0800, Qi Nark wrote:
> 1. git config --global credential.helper store
> 2. cd to a local repository directory, git config credential.helper
> store --file ./my_cred
> 3. execute some git command which need credential like git ls-remote
> 4. input my username & password, command done.
>
> As the result, **BOTH** the ./my_cred and ~/.git-credentials will save
> the credentials I just input. But, shouldn't the local config override
> the global ones, and only the ./my_cred should save it?
No, that's the expected result. The set of credential helpers form a
list, and each is run in turn. From "git help credentials":
If there are multiple instances of the credential.helper configuration
variable, each helper will be tried in turn, and may provide a
username, password, or nothing. Once Git has acquired both a username
and a password, no more helpers will be tried.
That's talking about lookup, but the same principle applies to storage.
But you may also find the paragraph below helpful:
If credential.helper is configured to the empty string, this resets
the helper list to empty (so you may override a helper set by a
lower-priority config file by configuring the empty-string helper,
followed by whatever set of helpers you would like).
Note that the "reset" behavior was introduced in git v2.9.0, so you'll
need at least that version.
-Peff
^ permalink raw reply
* Re: [PATCH] t6026: ensure that long-running script really is
From: Jeff King @ 2016-11-11 8:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin, git, Andreas Schwab
In-Reply-To: <fbf517ad-7341-eb6d-ab38-4fe91410e57c@kdbg.org>
On Fri, Nov 11, 2016 at 07:50:14AM +0100, Johannes Sixt wrote:
> Shouldn't we then move the 'kill' out of test_when_finished and make
> it a proper condition of the test? Like this?
>
> diff --git a/t/t6026-merge-attr.sh b/t/t6026-merge-attr.sh
> index 348d78b205..6ad8bd098a 100755
> --- a/t/t6026-merge-attr.sh
> +++ b/t/t6026-merge-attr.sh
> @@ -187,13 +187,19 @@ test_expect_success 'custom merge does not lock index' '
> sleep 3600 &
> echo $! >sleep.pid
> EOF
> - test_when_finished "kill \$(cat sleep.pid)" &&
>
> test_write_lines >.gitattributes \
> "* merge=ours" "text merge=sleep-an-hour" &&
> test_config merge.ours.driver true &&
> test_config merge.sleep-an-hour.driver ./sleep-an-hour.sh &&
> - git merge master
> + git merge master &&
> +
> + # We are testing that the custom merge driver does not block
> + # index.lock on Windows due to an inherited file handle.
> + # To ensure that this test checks this condition, the process
> + # must still be running at this point (and must have started
> + # in the first place), hence, this kill must not fail:
> + kill "$(cat sleep.pid)"
> '
That makes it more obvious that the return value of "kill" is important,
which is good.
But the other thing the "kill" is doing is make sure we clean up after
ourselves, even if another part of the test fails. What happens if
"merge" unexpectedly fails after starting the sleep process?
I think the best compromise is a comment like the one you have here, but
around the test_when_finished call (and possibly bumping the call down
to right before "git merge master", which is where we expect the process
to start).
-Peff
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Jeff King @ 2016-11-11 8:47 UTC (permalink / raw)
To: Lars Schneider
Cc: Junio C Hamano, Torsten Bögershausen, git, Eric Sunshine,
hvoigt
In-Reply-To: <2088B631-4FE8-4232-9F3C-699122E6A7B0@gmail.com>
On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote:
> There would be an alternative way to approach the problem:
> Someone (GitHub?, BitBucket?, GitLab?, ...) could setup a bunch of webservers
> with popular configurations and a way to reset a clean test environment. Then
> the TravisCI client tests could go against these servers.
>
> I realize that this idea is probably unrealistic because too much setup and
> maintenance work would be required.
Yeah, it seems like it adds a lot of complexity for little gain. Plus it
creates a network dependency on running the tests. I know you care
mostly about Travis, but I am much more interested in all of the people
(developers and not) who run "make test" on their own platforms.
If you did want to have a more real-world network-based test, I think
the right solution is not for GitHub to set up a bunch of mock servers,
but to design client-side tests that hit the _real_ GitHub (or GitLab,
or whatever) and perform some basic operations. OTOH, people running
"master" (or "next", etc) are doing that implicitly every day.
-Peff
^ permalink raw reply
* Re: [PATCH v1 0/2] Fix default macOS build locally and on Travis CI
From: Lars Schneider @ 2016-11-11 9:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, tboegi
In-Reply-To: <xmqqwpgb58ab.fsf@gitster.mtv.corp.google.com>
On 10 Nov 2016, at 22:34, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Schneider <larsxschneider@gmail.com> writes:
>
>>> I've followed what was available at the public-inbox archive, but it
>>> is unclear what the conclusion was.
>>>
>>> For the first one your "how about" non-patch, to which Peff said
>>> "that's simple and good", looked good to me as well, but is it
>>> available as a final patch that I can just take and apply (otherwise
>>> I think I can do the munging myself, but I'd rather be spoon-fed
>>> when able ;-).
>>
>> Sure! Here you go:
>> http://public-inbox.org/git/20161110111348.61580-1-larsxschneider@gmail.com/
>>
>>
>>> I do not have a strong opinion on the second one. For an interim
>>> solution, disabling webserver tests certainly is expedite and safe,
>>> so I am fine taking it as-is, but I may have missed strong
>>> objections.
>>
>> I haven't seen strong objections either. Just for reference, here is the patch:
>> http://public-inbox.org/git/20161017002550.88782-3-larsxschneider@gmail.com/
>
> Thanks. Picked up both of them.
Thanks! This makes "next" pass, again:
https://travis-ci.org/git/git/builds/174946111
BTW: If you want to learn about the build status of "git/git" branches on the
command line then you can use this snippet:
$ branch=next; echo "$branch: $(curl -s https://api.travis-ci.org/repos/git/git/branches/$branch | perl -lape 's/.*"state":"(\w+)".*"sha":"(\w{7}).*/$1 $2/g')"
Cheers,
Lars
^ permalink raw reply
* Re: [PATCH v7 01/17] ref-filter: implement %(if), %(then), and %(else) atoms
From: Karthik Nayak @ 2016-11-11 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jacob Keller, Git mailing list
In-Reply-To: <xmqqwpgb3p3g.fsf@gitster.mtv.corp.google.com>
On Fri, Nov 11, 2016 at 4:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jacob Keller <jacob.keller@gmail.com> writes:
>
>> Ok, so I have only one minor nit, but otherwise this looks quite good
>> to me. A few comments explaining my understanding, but only one
>> suggested
>> change which is really a minor nit and not worth re-rolling just for it.
>
> As you didn't snip parts you didn't comment, I'll use this to add my
> own for convenience ;-)
>
>>> +if::
>>> + Used as %(if)...%(then)...(%end) or
>>> + %(if)...%(then)...%(else)...%(end). If there is an atom with
>>> + value or string literal after the %(if) then everything after
>>> + the %(then) is printed, else if the %(else) atom is used, then
>>> + everything after %(else) is printed. We ignore space when
>>> + evaluating the string before %(then), this is useful when we
>>> + use the %(HEAD) atom which prints either "*" or " " and we
>>> + want to apply the 'if' condition only on the 'HEAD' ref.
>>> +
>>> In addition to the above, for commit and tag objects, the header
>>> field names (`tree`, `parent`, `object`, `type`, and `tag`) can
>>> be used to specify the value in the header field.
>
> I see a few instances of (%end) that were meant to be %(end).
>
Will change that.
> Aren't the following two paragraphs ...
>
>>> +When a scripting language specific quoting is in effect (i.e. one of
>>> +`--shell`, `--perl`, `--python`, `--tcl` is used), except for opening
>>> +atoms, replacement from every %(atom) is quoted when and only when it
>>> +appears at the top-level (that is, when it appears outside
>>> +%($open)...%(end)).
>
>>> +When a scripting language specific quoting is in effect, everything
>>> +between a top-level opening atom and its matching %(end) is evaluated
>>> +according to the semantics of the opening atom and its result is
>>> +quoted.
>
> ... saying the same thing?
>
Yes. I'm not sure of what the context even was, but I shall remove the
first paragraph,
the second one seems to notify the same thing in simpler terms.
>
>>> + }
>>> + } else if (!if_then_else->condition_satisfied)
>>
>> Minor nit. I'm not sure what standard we use here at Git, but
>> traditionally, I prefer to see { } blocks on all sections even if only
>> one of them needs it. (That is, only drop the braces when every
>> section is one line.) It also looks weird with a comment since it
>> appears as multiple lines to the reader. I think the braces improve
>> readability.
>>
>> I don't know whether that's Git's code base standard or not, however.
>> It's not really worth a re-roll unless something else would need to
>> change.
>>
>
> In principle, we mimick the kernel style of using {} block even on a
> single-liner body in if/else if/else cascade when any one of them is
> not a single-liner and requires {}. But we often ignore that when a
> truly trivial single liner follows if() even if its else clause is a
> big block, e.g.
>
> if (cond)
> single;
> else {
> big;
> block;
> }
>
> I agree with you that this case should just use {} for the following
> paragraph, because it is technically a single-liner, but comes with
> a big comment block and is very much easier to read with {} around
> it.
>
Ah! I see, sure I'll change it :)
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [credential.helper] unexpectedly save credential to multiple credential files
From: Qi Nark @ 2016-11-11 9:12 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20161111083649.d5newszupwyq5j6w@sigill.intra.peff.net>
On Fri, Nov 11, 2016 at 4:36 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 11, 2016 at 04:10:55PM +0800, Qi Nark wrote:
>
>> 1. git config --global credential.helper store
>> 2. cd to a local repository directory, git config credential.helper
>> store --file ./my_cred
>> 3. execute some git command which need credential like git ls-remote
>> 4. input my username & password, command done.
>>
>> As the result, **BOTH** the ./my_cred and ~/.git-credentials will save
>> the credentials I just input. But, shouldn't the local config override
>> the global ones, and only the ./my_cred should save it?
>
> No, that's the expected result. The set of credential helpers form a
> list, and each is run in turn. From "git help credentials":
>
> If there are multiple instances of the credential.helper configuration
> variable, each helper will be tried in turn, and may provide a
> username, password, or nothing. Once Git has acquired both a username
> and a password, no more helpers will be tried.
>
> That's talking about lookup, but the same principle applies to storage.
> But you may also find the paragraph below helpful:
>
> If credential.helper is configured to the empty string, this resets
> the helper list to empty (so you may override a helper set by a
> lower-priority config file by configuring the empty-string helper,
> followed by whatever set of helpers you would like).
>
> Note that the "reset" behavior was introduced in git v2.9.0, so you'll
> need at least that version.
>
> -Peff
Ok, that's fair enough. Thanks for your detailed explanation. The
version info is very important to me.
Thank you again.
^ permalink raw reply
* Re: [PATCH v7 01/17] ref-filter: implement %(if), %(then), and %(else) atoms
From: Karthik Nayak @ 2016-11-11 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jacob Keller, Git mailing list
In-Reply-To: <xmqqshqy53cj.fsf@gitster.mtv.corp.google.com>
On Fri, Nov 11, 2016 at 4:50 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Karthik Nayak <karthik.188@gmail.com> writes:
>
>>> Minor nit. I'm not sure what standard we use here at Git, but
>>> traditionally, I prefer to see { } blocks on all sections even if only
>>> one of them needs it. (That is, only drop the braces when every
>>> section is one line.) It also looks weird with a comment since it
>>> appears as multiple lines to the reader. I think the braces improve
>>> readability.
>>>
>>> I don't know whether that's Git's code base standard or not, however.
>>> It's not really worth a re-roll unless something else would need to
>>> change.
>>>
>> I believe this is the syntax followed in Git, xdiff/xmerge.c:173 and so on.
>
> That is a bad example for two reasons, if you mean this part:
>
> if ((size = file->recs[i]->size) &&
> file->recs[i]->ptr[size - 1] == '\n')
> /* Last line; ends in LF; Is it CR/LF? */
> return size > 1 &&
> file->recs[i]->ptr[size - 2] == '\r';
> * if (!i)
> /* The only line has no eol */
> return -1;
> /* Determine eol from second-to-last line */
>
>
> What Jacob prefers is this:
>
> ---------------------------------------------
> if (cond)
> simple;
> else if (cond)
> simple;
> else
> simple;
> ---------------------------------------------
> if (cond) {
> simple;
> } else if (cond) {
> no;
> longer;
> simple;
> } else {
> simple;
> }
> ---------------------------------------------
>
> That is, as long as all arms of if/else if/.../else cascade is
> simple, {} is used nowhere in the cascade, but once even one of them
> requires {} then all others gain {}.
I see, I mistook Jacob then.
I was talking about if we need to use {} whenever there's only a
single line of code
but followed by a comment which extends the if/else if/.../else block.
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Lars Schneider @ 2016-11-11 9:13 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Torsten Bögershausen, git, Eric Sunshine,
hvoigt
In-Reply-To: <20161111084725.jkdsdt4yslzsuh6d@sigill.intra.peff.net>
On 11 Nov 2016, at 09:47, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote:
>
>> There would be an alternative way to approach the problem:
>> Someone (GitHub?, BitBucket?, GitLab?, ...) could setup a bunch of webservers
>> with popular configurations and a way to reset a clean test environment. Then
>> the TravisCI client tests could go against these servers.
>>
>> I realize that this idea is probably unrealistic because too much setup and
>> maintenance work would be required.
>
> Yeah, it seems like it adds a lot of complexity for little gain. Plus it
> creates a network dependency on running the tests. I know you care
> mostly about Travis, but I am much more interested in all of the people
> (developers and not) who run "make test" on their own platforms.
>
> If you did want to have a more real-world network-based test, I think
> the right solution is not for GitHub to set up a bunch of mock servers,
> but to design client-side tests that hit the _real_ GitHub (or GitLab,
> or whatever) and perform some basic operations. OTOH, people running
> "master" (or "next", etc) are doing that implicitly every day.
That is actually a neat idea. We could setup a test repo on each of the major
Git hosting sites and then the TravisCI run could clone a repo and push
changes to it. That shouldn't take long and would probably be a good real
world test.
The credentials of these repos could be stored encrypted in Travis CI [1].
Where would such a test repo live on github.com? On github.com/git or would
you prefer a separate organization? (no worries, I am not going to tackle this
anytime soon -- too many things in my backlog already).
BTW: I just noticed https://github.com/git/hello-world ... is this legitimate
or did someone hack github.com/git? :)
Cheers,
Lars
[1] https://docs.travis-ci.com/user/environment-variables/#Defining-encrypted-variables-in-.travis.yml
^ permalink raw reply
* pre-rebase, post-rewrite, ...
From: Uwe Hausbrand @ 2016-11-11 9:22 UTC (permalink / raw)
To: git
Hi all,
I am using the pre-rebase hook to generate a tag. I am using this tag
to check if my rebase lost any commits or content when i'm cleaning up
my local commit history.
What i now want to do is using a post-rebase hook to make a diff check
and remove my generated tag in case there is no difference.
I use the post-rewrite hook to make this check, but this only triggers
in case of a rewrite happening (which is understandable). But the
pre-rebase hook triggers on every git rebase call and so i generate
tags which could be removed automatically.
Is there any other hook i could use or why is there no post-rebase hook?
An older post mentions ( http://marc.info/?l=git&m=120796177421283&w=2
) point 5 which i think applies to my problem, but as i can't alias
real git commands (which is ok) i would need to use a new command.
Best regards,
Uwe
^ permalink raw reply
* Re: [PATCH v1 2/2] travis-ci: disable GIT_TEST_HTTPD for macOS
From: Jeff King @ 2016-11-11 9:28 UTC (permalink / raw)
To: Lars Schneider
Cc: Junio C Hamano, Torsten Bögershausen, git, Eric Sunshine,
hvoigt
In-Reply-To: <BAB2E4AE-7241-4991-A993-A60DBA75092B@gmail.com>
On Fri, Nov 11, 2016 at 10:13:44AM +0100, Lars Schneider wrote:
> > If you did want to have a more real-world network-based test, I think
> > the right solution is not for GitHub to set up a bunch of mock servers,
> > but to design client-side tests that hit the _real_ GitHub (or GitLab,
> > or whatever) and perform some basic operations. OTOH, people running
> > "master" (or "next", etc) are doing that implicitly every day.
>
> That is actually a neat idea. We could setup a test repo on each of the major
> Git hosting sites and then the TravisCI run could clone a repo and push
> changes to it. That shouldn't take long and would probably be a good real
> world test.
>
> The credentials of these repos could be stored encrypted in Travis CI [1].
>
> Where would such a test repo live on github.com? On github.com/git or would
> you prefer a separate organization? (no worries, I am not going to tackle this
> anytime soon -- too many things in my backlog already).
I think I'd prefer for it to live outside of the "git" organization
entirely, if only because it's credentials will be necessarily less
secure. It would be nice if people could point the suite at their own
user/repo, too, so they can run it outside of travis.
> BTW: I just noticed https://github.com/git/hello-world ... is this legitimate
> or did someone hack github.com/git? :)
Hmm. I wondered myself. There's no audit record of who created it, but
the creation timestamp is from 2008-07-23, which predates a lot of the
logging. So offhand, I'd say the likely explanation is "Scott Chacon
experimenting".
It's probably worth cleaning out now, though.
-Peff
^ permalink raw reply
* Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter
From: Lars Schneider @ 2016-11-11 9:28 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git, me
In-Reply-To: <20161110160809.2gvf67rlnvounulf@sigill.intra.peff.net>
On 10 Nov 2016, at 17:08, Jeff King <peff@peff.net> wrote:
> On Thu, Nov 10, 2016 at 01:10:17PM +0100, Matthieu Moy wrote:
>
>> Lars Schneider <larsxschneider@gmail.com> writes:
>>
>>> I haven't looked at an implemenation approach at all. I wonder if this could
>>> be OK from a conceptional point of view or if there are obvious security
>>> problems that I am missing.
>>
>> Did you consider just running "git credential" from the filter? It may
>> not be the perfect solution, but it should work. I already used it to
>> get credential from a remote-helper (git-remote-mediawiki). When
>> prompting credentials interactively, it grabs the terminal directly, so
>> it work even if stdin/stdout are used for the protocol.
>
> Yeah, that is the solution I was going to suggest. The credentials are
> totally orthogonal to the filters, and I would rather not shove them
> into the protocol. It's an extra process, but with the new multi-use
> smudge filter, it's one per git invocation, not one per file.
The trouble with "git credential" is that it works only if the credential
helper is setup correctly. Although I assume that most people have setup this,
I have also worked with a number of people who prefer to enter their passwords
every time Git makes a network connection.
- Lars
^ permalink raw reply
* Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter
From: Jeff King @ 2016-11-11 9:31 UTC (permalink / raw)
To: Lars Schneider; +Cc: Matthieu Moy, git, me
In-Reply-To: <77603924-3552-4146-9C9E-A106CFA96D7A@gmail.com>
On Fri, Nov 11, 2016 at 10:28:56AM +0100, Lars Schneider wrote:
> > Yeah, that is the solution I was going to suggest. The credentials are
> > totally orthogonal to the filters, and I would rather not shove them
> > into the protocol. It's an extra process, but with the new multi-use
> > smudge filter, it's one per git invocation, not one per file.
>
> The trouble with "git credential" is that it works only if the credential
> helper is setup correctly. Although I assume that most people have setup this,
> I have also worked with a number of people who prefer to enter their passwords
> every time Git makes a network connection.
Are you sure about that? If I do:
echo url=https://example.com/repo.git |
git credential fill
I get prompted for a username and password.
-Peff
^ permalink raw reply
* Re: [RFC] Add way to make Git credentials accessible from clean/smudge filter
From: Lars Schneider @ 2016-11-11 9:40 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git, me
In-Reply-To: <20161111093122.osbdwmze5x5t742v@sigill.intra.peff.net>
On 11 Nov 2016, at 10:31, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 11, 2016 at 10:28:56AM +0100, Lars Schneider wrote:
>
>>> Yeah, that is the solution I was going to suggest. The credentials are
>>> totally orthogonal to the filters, and I would rather not shove them
>>> into the protocol. It's an extra process, but with the new multi-use
>>> smudge filter, it's one per git invocation, not one per file.
>>
>> The trouble with "git credential" is that it works only if the credential
>> helper is setup correctly. Although I assume that most people have setup this,
>> I have also worked with a number of people who prefer to enter their passwords
>> every time Git makes a network connection.
>
> Are you sure about that? If I do:
>
> echo url=https://example.com/repo.git |
> git credential fill
>
> I get prompted for a username and password.
Hm.. either I don't understand you or I expressed myself unclear.
Let's say a user runs:
$ git clone https://myrepo.git
If no credential helper is setup, then Git asks the user for credentials.
Afterwards Git starts downloading stuff. At some point Git will run my
smudge filter on some files and in my case the smudge filter needs the
Git credentials. AFAIK, the smudge filter has no way to get the credentials
from Git at this point - not even by invoking "git credential".
Is this correct?
- Lars
^ permalink raw reply
* [PATCH] doc: fix location of 'info/' with $GIT_COMMON_DIR
From: Patrick Steinhardt @ 2016-11-11 11:23 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy, Patrick Steinhardt
With the introduction of the $GIT_COMMON_DIR variable, the
repository layout manual was changed to reflect the location for
many files in case the variable is set. While adding the new
locations, one typo snuck in regarding the location of the
'info/' folder, which is falsely claimed to reside at
"$GIT_COMMON_DIR/index".
Fix the typo to point to "$GIT_COMMON_DIR/info/" instead.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Documentation/gitrepository-layout.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitrepository-layout.txt b/Documentation/gitrepository-layout.txt
index 577ee84..a5f99cb 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -177,7 +177,7 @@ sharedindex.<SHA-1>::
info::
Additional information about the repository is recorded
in this directory. This directory is ignored if $GIT_COMMON_DIR
- is set and "$GIT_COMMON_DIR/index" will be used instead.
+ is set and "$GIT_COMMON_DIR/info" will be used instead.
info/refs::
This file helps dumb transports discover what refs are
--
2.10.2
^ permalink raw reply related
* [PATCH v6 01/16] Git.pm: add subroutines for commenting lines
From: Vasco Almeida @ 2016-11-11 12:45 UTC (permalink / raw)
To: git
Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA, Jakub Narębski, David Aguilar,
Junio C Hamano
In-Reply-To: <20161005172110.30801-1-vascomalmeida@sapo.pt>
Add subroutines prefix_lines and comment_lines.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
perl/Git.pm | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index b2732822a..69cd1ddec 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1438,6 +1438,30 @@ sub END {
} # %TEMP_* Lexical Context
+=item prefix_lines ( PREFIX, STRING [, STRING... ])
+
+Prefixes lines in C<STRING> with C<PREFIX>.
+
+=cut
+
+sub prefix_lines {
+ my $prefix = shift;
+ my $string = join("\n", @_);
+ $string =~ s/^/$prefix/mg;
+ return $string;
+}
+
+=item comment_lines ( STRING [, STRING... ])
+
+Comments lines following core.commentchar configuration.
+
+=cut
+
+sub comment_lines {
+ my $comment_line_char = config("core.commentchar") || '#';
+ return prefix_lines("$comment_line_char ", @_);
+}
+
=back
=head1 ERROR HANDLING
--
2.11.0.rc0.33.gec17dab
^ permalink raw reply related
* [PATCH v6 05/16] i18n: clean.c: match string with git-add--interactive.perl
From: Vasco Almeida @ 2016-11-11 12:45 UTC (permalink / raw)
To: git
Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason,
Jean-Noël AVILA, Jakub Narębski, David Aguilar,
Junio C Hamano
In-Reply-To: <20161005172110.30801-1-vascomalmeida@sapo.pt>
Change strings for help to match the ones in git-add--interactive.perl.
The strings now represent one entry to translate each rather then two
entries each different only by an ending newline character.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
builtin/clean.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 0371010af..d6bc3aaae 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -287,11 +287,11 @@ static void pretty_print_menus(struct string_list *menu_list)
static void prompt_help_cmd(int singleton)
{
clean_print_color(CLEAN_COLOR_HELP);
- printf_ln(singleton ?
+ printf(singleton ?
_("Prompt help:\n"
"1 - select a numbered item\n"
"foo - select item based on unique prefix\n"
- " - (empty) select nothing") :
+ " - (empty) select nothing\n") :
_("Prompt help:\n"
"1 - select a single item\n"
"3-5 - select a range of items\n"
@@ -299,7 +299,7 @@ static void prompt_help_cmd(int singleton)
"foo - select item based on unique prefix\n"
"-... - unselect specified items\n"
"* - choose all items\n"
- " - (empty) finish selecting"));
+ " - (empty) finish selecting\n"));
clean_print_color(CLEAN_COLOR_RESET);
}
@@ -508,7 +508,7 @@ static int parse_choice(struct menu_stuff *menu_stuff,
if (top <= 0 || bottom <= 0 || top > menu_stuff->nr || bottom > top ||
(is_single && bottom != top)) {
clean_print_color(CLEAN_COLOR_ERROR);
- printf_ln(_("Huh (%s)?"), (*ptr)->buf);
+ printf(_("Huh (%s)?\n"), (*ptr)->buf);
clean_print_color(CLEAN_COLOR_RESET);
continue;
}
@@ -774,7 +774,7 @@ static int ask_each_cmd(void)
static int quit_cmd(void)
{
string_list_clear(&del_list, 0);
- printf_ln(_("Bye."));
+ printf(_("Bye.\n"));
return MENU_RETURN_NO_LOOP;
}
--
2.11.0.rc0.33.gec17dab
^ permalink raw reply related
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