Jeff King writes:
> In my opinion this feature is so contrary to Git's general assumptions
> that it's likely to create a ton of information leaks of the supposedly
> protected data.
> ...
Yup, with s/implemented/designed/, I agree all you said here
(snipped).
> Sorry I don't have a more
On 2018.12.05 23:48, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Dec 05 2018, Josh Steadmon wrote:
>
> > Breaks load_commit_graph_one() into a new function,
> > parse_commit_graph(). The latter function operates on arbitrary buffers,
> > which makes it suitable as a fuzzing target.
> >
> > Adds
Frank Schäfer writes:
> Just to be sure that I'm not missing anything here:
> What's your definition of "LF in repository, CRLF in working tree" in
> terms of config parameters ?
:::Documentation/config/core.txt:::
core.autocrlf::
Setting this variable to "true" is the same as setting
Ævar Arnfjörð Bjarmason writes:
>> Documentation says "If you are absolutely certain that you want your
>> script to load and execute a file from the current directory, then use
>> a ./ prefix". We can do that, like so:
>>
>> diff --git i/gitweb/Makefile w/gitweb/Makefile
>> index
Konstantin Khomoutov writes:
> On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
>
>> It would be great if git-log has a formatting option to insert an
>> index of the current commit since HEAD.
>>
>> It would allow after quitting the git-log to immediately fire up "git
>>
On Wed, Dec 05, 2018 at 04:01:05PM -0500, Jeff King wrote:
> You could work around that by teaching the server to refuse to use "X"
> in any way when the client does not have the right permissions. But:
>
> - that's just one example; there are probably a number of such leaks
>
> - you're
Jeff King writes:
> But the ^C case is interesting. Try running your script under "sh -x"
> and hitting ^C. The signal interrupts the first wait. In my script (or
> yours modified to use a single wait), we then proceed immediately to the
> "exit", and get output from the subshells after we've
inline...
On 12/05/2018 04:12 PM, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Dec 05 2018, Duy Nguyen wrote:
>
>>
>> Another option is builtin per-blob encryption (maybe with just
>> clean/smudge filter), then access control will be about obtaining the
>> decryption key (*) and we don't break object
Jonathan Tan writes:
> Looking at the bigger picture, the speed of the connectivity check
> during a fetch might be further improved by passing only the negotiation
> tips (obtained through --negotiation-tip) instead of "--all". This patch
> just handles the low-hanging fruit first.
That sounds
On Wed, Dec 05 2018, Josh Steadmon wrote:
> Breaks load_commit_graph_one() into a new function,
> parse_commit_graph(). The latter function operates on arbitrary buffers,
> which makes it suitable as a fuzzing target.
>
> Adds fuzz-commit-graph.c, which provides a fuzzing entry point
>
Johannes Sixt writes:
> Am 05.12.18 um 16:37 schrieb Elijah Newren:
>> On Tue, Dec 4, 2018 at 11:40 PM Junio C Hamano wrote:
>>>
>>> Johannes Sixt writes:
>>>
Please let me deposit my objection. This paragraph is not the right
place to explain what directory renme detection is and
On Wed, Dec 05 2018, Coiner, John wrote:
I forgot to mention this in my initial reply in
<878t13zp8y@evledraar.gmail.com>, but on a re-reading I re-spotted
this:
> - hashes are secret. If the hashes from a protected tree leak, the
> data also leaks. No check on the ser
On 11/21/2018 01:00 AM, Junio C Hamano wrote:
* md/list-lazy-objects-fix (2018-10-29) 1 commit
- list-objects.c: don't segfault for missing cmdline objects
"git rev-list --exclude-promissor-objects" had to take an object
that does not exist locally (and is lazily available) from the
On Wed, Dec 05, 2018 at 01:20:35PM +0100, SZEDER Gábor wrote:
> On Wed, Dec 05, 2018 at 12:17:09AM -0500, Jeff King wrote:
> > On Tue, Dec 04, 2018 at 05:34:56PM +0100, SZEDER Gábor wrote:
> >
> > > Several test scripts run daemons like 'git-daemon' or Apache, and
> > > communicate with them
On Wed, Dec 05, 2018 at 03:01:06PM +0100, SZEDER Gábor wrote:
> > > - Make '--stress' imply '--verbose-log' and discard the test's
> > > standard ouput and error; dumping the output of several parallel
> > > tests to the terminal would create a big ugly mess.
> >
> > Makes sense. My
On Wed, Dec 05, 2018 at 11:34:54AM +0100, SZEDER Gábor wrote:
>
> Just a quick reply to this one point for now:
>
> On Wed, Dec 05, 2018 at 12:44:09AM -0500, Jeff King wrote:
> > On Tue, Dec 04, 2018 at 05:34:57PM +0100, SZEDER Gábor wrote:
> > > + job_nr=0
> > > + while test $job_nr -lt
Am 05.12.18 um 20:29 schrieb Frank Schäfer:
Am 02.12.18 um 22:22 schrieb Johannes Sixt:
Am 02.12.18 um 20:31 schrieb Frank Schäfer:
With other words:
"If CR comes immediately before a LF, do the following with *all* lines:
after the CR if eol=lf but do not after the CR if
eol=crlf."
Why?
Am 05.12.18 um 16:37 schrieb Elijah Newren:
On Tue, Dec 4, 2018 at 11:40 PM Junio C Hamano wrote:
Johannes Sixt writes:
Please let me deposit my objection. This paragraph is not the right
place to explain what directory renme detection is and how it works
under the hood. "works fine" in
On Wed, Dec 05 2018, Duy Nguyen wrote:
> On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote:
>> This directory-level security is not a goal for VFS for Git, and I don't
>> see itbecoming a priority as it breaks a number of design decisions we
>> made in our object storage and communication
On Wed, Dec 05, 2018 at 08:13:16PM +, Coiner, John wrote:
> One obstacle to moving AMD to git/VFSForGit is the lack of access
> control support in git. AMD has a lot of data whose distribution must be
> limited. Sometimes it's a legal requirement, eg. CPU core designs are
> covered by US
On Wed, Dec 5, 2018 at 9:46 PM Derrick Stolee wrote:
> This directory-level security is not a goal for VFS for Git, and I don't
> see itbecoming a priority as it breaks a number of design decisions we
> made in our object storage and communication models.
>
> The best I can think about when
On 12/5/2018 3:34 PM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Dec 05 2018, Coiner, John wrote:
I'm an engineer with AMD. I'm looking at whether we could switch our
internal version control to a monorepo, possibly one based on git and
VFSForGit.
Has anyone looked at adding access control to
On Wed, Dec 05 2018, Coiner, John wrote:
> I'm an engineer with AMD. I'm looking at whether we could switch our
> internal version control to a monorepo, possibly one based on git and
> VFSForGit.
>
> One obstacle to moving AMD to git/VFSForGit is the lack of access
> control support in git.
On Wed, Dec 05, 2018 at 07:41:44PM +0100, René Scharfe wrote:
> > If we start to convert those, there's a
> > little bit of a rabbit hole, but it's actually not too bad.
>
> You don't need to crawl in just for quick_has_loose(), but eventually
> everything has to be converted. It seems a bit
On Wed, Dec 05 2018, SZEDER Gábor wrote:
> On Wed, Dec 05, 2018 at 03:01:41PM +0100, Ævar Arnfjörð Bjarmason wrote:
>> >> decide to stress test in advance, since we'd either flock() the trash
>> >> dir, or just mktemp(1)-it.
>> >
>> > While 'mktemp' seems to be more portable than 'flock', it
Am 03.12.18 um 02:15 schrieb Junio C Hamano:
> Frank Schäfer writes:
>
>> Hi Junio,
>>
>> Am 29.11.18 um 03:11 schrieb Junio C Hamano:
>> [...]
>>> This was misspoken a bit. Let's revise it to
>>>
>>> When producing a colored output (not limited to whitespace
>>> error coloring of diff
Am 02.12.18 um 22:22 schrieb Johannes Sixt:
> Am 02.12.18 um 20:31 schrieb Frank Schäfer:
>> With other words:
>> "If CR comes immediately before a LF, do the following with *all* lines:
>> after the CR if eol=lf but do not after the CR if
>> eol=crlf."
>
> Why? It is the pager's duty to
On Wed, Dec 05 2018, Jonathan Nieder wrote:
> Martin Mares wrote[1]:
>
>> After upgrade to Stretch, gitweb no longer finds the configuration file
>> "gitweb_config.perl" in the current directory. However, "man gitweb" still
>> mentions this as one of the possible locations of the config file
Am 05.12.2018 um 09:15 schrieb Jeff King:
> On Wed, Dec 05, 2018 at 01:51:36AM -0500, Jeff King wrote:
>
>>> This
>>> function is easily converted to struct object_id, though, as its single
>>> caller can pass one on -- this makes the copy unnecessary.
>>
>> If you mean modifying
Hello, Jeff.
On Thu, Nov 15, 2018 at 09:40:44AM -0500, Jeff King wrote:
> Sorry for the slow reply. This was on my to-look-at pile, but for
> some reason I accidentally put in my done pile.
No worries and sorry about my late reply too. Things were a bit
hectic.
> > * A new built-in command
On Dez 05 2018, Elijah Newren wrote:
> Or, just use name-rev so it works with non-linear histories too:
>
> git log | git name-rev --refs=$(git symbolic-ref HEAD) --stdin | less
That wouldn't work for a detached HEAD, though, and you need to use
--no-abbrev.
Andreas.
--
Andreas Schwab,
On Tue, Dec 4, 2018 at 11:40 PM Junio C Hamano wrote:
>
> Johannes Sixt writes:
>
> > Please let me deposit my objection. This paragraph is not the right
> > place to explain what directory renme detection is and how it works
> > under the hood. "works fine" in the original text is the right
On Wed, Dec 5, 2018 at 6:56 AM Konstantin Khomoutov wrote:
>
> On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
>
> > It would be great if git-log has a formatting option to insert an
> > index of the current commit since HEAD.
> >
> > It would allow after quitting the
On Wed, Dec 05, 2018 at 05:22:14PM +0300, Konstantin Kharlamov wrote:
> It would be great if git-log has a formatting option to insert an
> index of the current commit since HEAD.
>
> It would allow after quitting the git-log to immediately fire up "git
> rebase -i HEAD~index" instead of "git
On Wed, Dec 05, 2018 at 03:01:41PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> decide to stress test in advance, since we'd either flock() the trash
> >> dir, or just mktemp(1)-it.
> >
> > While 'mktemp' seems to be more portable than 'flock', it doesn't seem
> > to be portable enough; at least
concurrent tests without needing to decide
to concurrently test in advance.
>> decide to stress test in advance, since we'd either flock() the trash
>> dir, or just mktemp(1)-it.
>
> While 'mktemp' seems to be more portable than 'flock', it doesn't seem
> to be portable eno
On Wed, Dec 05, 2018 at 12:44:09AM -0500, Jeff King wrote:
> On Tue, Dec 04, 2018 at 05:34:57PM +0100, SZEDER Gábor wrote:
>
> > To prevent the several parallel invocations of the same test from
> > interfering with each other:
> >
> > - Include the parallel job's number in the name of the
On Wed, Dec 05, 2018 at 12:17:09AM -0500, Jeff King wrote:
> On Tue, Dec 04, 2018 at 05:34:56PM +0100, SZEDER Gábor wrote:
>
> > Several test scripts run daemons like 'git-daemon' or Apache, and
> > communicate with them through TCP sockets. To have unique ports where
> > these daemons are
mktemp(1)-it.
While 'mktemp' seems to be more portable than 'flock', it doesn't seem
to be portable enough; at least it's not in POSIX.
And in general I'd prefer deterministic trash directory names. If I
re-run a failed test after fixing the bug, then currently the trash
directory will be overwri
Just a quick reply to this one point for now:
On Wed, Dec 05, 2018 at 12:44:09AM -0500, Jeff King wrote:
> On Tue, Dec 04, 2018 at 05:34:57PM +0100, SZEDER Gábor wrote:
> > + job_nr=0
> > + while test $job_nr -lt "$job_count"
> > + do
> > + wait
> > + job_nr=$(($job_nr
On Wed, Dec 05, 2018 at 01:51:36AM -0500, Jeff King wrote:
> > This
> > function is easily converted to struct object_id, though, as its single
> > caller can pass one on -- this makes the copy unnecessary.
>
> If you mean modifying sha1_loose_object_info() to take an oid, then
> sure, I agree
Johannes Sixt writes:
> Please let me deposit my objection. This paragraph is not the right
> place to explain what directory renme detection is and how it works
> under the hood. "works fine" in the original text is the right phrase
> here; if there is concern that this induces expectations
Am 05.12.18 um 07:20 schrieb Elijah Newren:
On Tue, Dec 4, 2018 at 7:54 PM Junio C Hamano wrote:
Elijah Newren writes:
Gah, when I was rebasing on your patch I adopted your sentence rewrite
but forgot to remove the "sometimes". Thanks for catching; correction:
-- 8< --
Subject: [PATCH
Elijah Newren writes:
> What depends on stage#2 coming from the commit that will become the
> first parent?
How about "git diff --cc" for a starter? What came from HEAD's
ancestry should appear first and then what came from the side branch
that is merged into.
On Wed, Dec 05, 2018 at 07:02:17AM +0100, René Scharfe wrote:
> > I actually wrote it that way initially, but doing the hashcpy() in the
> > caller is a bit more awkward. My thought was to punt on that until the
> > rest of the surrounding code starts handling oids.
>
> The level of awkwardness
Jonathan Tan writes:
> +struct output_state {
> + char buffer[8193];
> + int used;
> +};
> +
> +static int read_pack_objects_stdout(int outfd, struct output_state *os)
> +{
The naming feels quite odd. We are downstream of pack-objects and
reading its standard output stream, so "read
On Tue, Dec 4, 2018 at 7:54 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Gah, when I was rebasing on your patch I adopted your sentence rewrite
> > but forgot to remove the "sometimes". Thanks for catching; correction:
>
> >
> > -- 8< --
> > Subject: [PATCH v2] git-rebase.txt:
On Wed, Dec 05, 2018 at 12:35:08PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Since 26125f6b9b ("detect broken alternates.", 2006-02-22) we've
> > emitted an error if the alternates directory doesn't exist, but not
> > for the common misstep of adding a path to
Am 05.12.2018 um 05:46 schrieb Jeff King:
> On Tue, Dec 04, 2018 at 10:45:13PM +0100, René Scharfe wrote:
>
>>> The comment in the context there is warning callers to remember to load
>>> the cache first. Now that we have individual caches, might it make sense
>>> to change the interface a bit,
Junio C Hamano writes:
> So, this is OK, but
>
>> +Clients then should understand that the returned packfile could be
>> incomplete,
>> +and that it needs to download all the given URIs before the fetch or clone
>> is
>> +complete. Each URI should point to a Git packfile (which may be a thin
On Wed, Dec 05, 2018 at 12:37:58PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > Change the "error" message emitted by alt_odb_usable() to be a
> > "warning" instead. As noted in commits leading up to this one this has
> > never impacted the exit code ever since the
On Tue, Dec 04, 2018 at 07:11:08PM +0100, Ævar Arnfjörð Bjarmason wrote:
> It's a frequent annoyance of mine in the test suite that I'm
> e.g. running t*.sh with some parallel "prove" in one screen, and then I
> run tABCD*.sh manually, and get unlucky because they use the same trash
> dir, and
On Tue, Dec 04, 2018 at 06:04:14PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Dec 04 2018, SZEDER Gábor wrote:
>
> > The number of parallel invocations is determined by, in order of
> > precedence: the number specified as '--stress=', or the value of
> > the GIT_TEST_STRESS_LOAD
On Tue, Dec 04, 2018 at 05:34:57PM +0100, SZEDER Gábor wrote:
> To prevent the several parallel invocations of the same test from
> interfering with each other:
>
> - Include the parallel job's number in the name of the trash
> directory and the various output files under 't/test-results/'
On Tue, Dec 04, 2018 at 05:34:56PM +0100, SZEDER Gábor wrote:
> Several test scripts run daemons like 'git-daemon' or Apache, and
> communicate with them through TCP sockets. To have unique ports where
> these daemons are accessible, the ports are usually the number of the
> corresponding test
Jonathan Tan writes:
> +This feature allows servers to serve part of their packfile response as URIs.
> +This allows server designs that improve scalability in bandwidth and CPU
> usage
> +(for example, by serving some data through a CDN), and (in the future)
> provides
> +some measure of
On Tue, Dec 04, 2018 at 05:34:55PM +0100, SZEDER Gábor wrote:
> There are two places where we strip off any leading path components
> and the '.sh' suffix from the test script's pathname, and there are
> two places where we construct the filename of test output files in
> 't/test-results/'. The
On Tue, Dec 04, 2018 at 02:42:38PM -0800, Jonathan Tan wrote:
> diff --git a/revision.c b/revision.c
> index b5108b75ab..e7da2c57ab 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -212,7 +212,20 @@ static struct object *get_reference(struct rev_info
> *revs, const char *name,
> {
>
On Tue, Dec 04, 2018 at 10:45:13PM +0100, René Scharfe wrote:
> > The comment in the context there is warning callers to remember to load
> > the cache first. Now that we have individual caches, might it make sense
> > to change the interface a bit, and make these members private. I.e.,
> >
On Tue, Dec 4, 2018 at 6:26 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > On Tue, Dec 4, 2018 at 6:43 PM Elijah Newren wrote:
> >> > > > +--ours::
> >> > > > +--theirs::
> >> ...
> >> go away. Maybe it can still be fixed (I haven't dug too deeply into
> >> it), but if so, the only fix
On Tue, Dec 4, 2018 at 6:14 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> >> My single biggest worry about this whole series is that I'm worried
> >> you're perpetuating and even further ingraining one of the biggest
> >> usability problems with checkout: people suggest and use it for
> >>
Jonathan Tan writes:
> The git command line expects Git servers to follow a specific order of
"Command line"? It sounds like you are talking about the order of
command line arguments and options, but apparently that is not what
you are doing. Is it "The git over-the-wire protocol"?
> +
On Tue, Dec 04, 2018 at 06:48:22PM -0800, Stefan Beller wrote:
> > Perhaps we should note this more prominently, and since Brandon isn't at
> > Google anymore can some of you working there edit this post? It's the
> > first Google result for "git protocol v2", so it's going to be quite
> >
Elijah Newren writes:
> Gah, when I was rebasing on your patch I adopted your sentence rewrite
> but forgot to remove the "sometimes". Thanks for catching; correction:
>
> -- 8< --
> Subject: [PATCH v2] git-rebase.txt: update note about directory rename
> detection and am
>
> In commit
Ævar Arnfjörð Bjarmason writes:
> Change the "error" message emitted by alt_odb_usable() to be a
> "warning" instead. As noted in commits leading up to this one this has
> never impacted the exit code ever since the check was initially added
> in 26125f6b9b ("detect broken alternates.",
Ævar Arnfjörð Bjarmason writes:
> Since 26125f6b9b ("detect broken alternates.", 2006-02-22) we've
> emitted an error if the alternates directory doesn't exist, but not
> for the common misstep of adding a path to another git repository as
> an alternate, as opposed to its "objects" directory.
Stefan Beller writes:
> This is a resend of sb/submodule-recursive-fetch-gets-the-tip,
> with all feedback addressed. As it took some time, I'll send it
> without range-diff, but would ask for full review.
Is that a "resend" or reroll/update (or whatever word that does not
imply "just sending
-cc linux list
> Perhaps we should note this more prominently, and since Brandon isn't at
> Google anymore can some of you working there edit this post? It's the
> first Google result for "git protocol v2", so it's going to be quite
> confusing for people if after 2.20 the instructions in it no
Duy Nguyen writes:
> On Tue, Dec 4, 2018 at 6:43 PM Elijah Newren wrote:
>> > > > +--ours::
>> > > > +--theirs::
>> ...
>> go away. Maybe it can still be fixed (I haven't dug too deeply into
>> it), but if so, the only fix needed here would be to remove this long
>> explanation about why the
Duy Nguyen writes:
>> My single biggest worry about this whole series is that I'm worried
>> you're perpetuating and even further ingraining one of the biggest
>> usability problems with checkout: people suggest and use it for
>> reverting/restoring paths to a previous version, but it doesn't do
> Try fetching a submodule by object id if the object id that the
> superproject points to, cannot be found.
Mention here the consequences of what happens when this attempt to fetch
fails. Also, this seems to be a case of "do or do not, there is no try"
- maybe it's better to say "Fetch commits
> Keep the properties introduced in 10f5c52656 (submodule: avoid
> auto-discovery in prepare_submodule_repo_env(), 2016-09-01), by fixating
> the git directory of the submodule.
This is to avoid the autodetection of the Git repository, making it less
error-prone; looks good to me.
> We used to recurse into submodules, even if they were broken having
> only an objects directory. The child process executed in the submodule
> would fail though if the submodule was broken. This is tested via
> "fetching submodule into a broken repository" in t5526.
>
> This patch tightens the
> We can string_list_insert() to maintain sorted-ness of the
> list as we find new items, or we can string_list_append() to
> build an unsorted list and sort it at the end just once.
>
> As we do not rely on the sortedness while building the
> list, we pick the "append and sort at the end" as it
On Tue, Dec 4, 2018 at 1:53 PM Johannes Sixt wrote:
>
> Am 04.12.18 um 22:24 schrieb Elijah Newren:
> > + The am backend sometimes does not because it operates on
> > +"fake ancestors" that involve trees containing only the files modified
> > +in the patch. Without accurate tree
On Tue, Dec 4, 2018 at 2:42 PM Jonathan Tan wrote:
>
> When fetching into a repository, a connectivity check is first made by
> check_exist_and_connected() in builtin/fetch.c that runs:
>
> git rev-list --objects --stdin --not --all --quiet <(list of objects)
>
> If the client repository has
Am 04.12.18 um 22:24 schrieb Elijah Newren:
+ The am backend sometimes does not because it operates on
+"fake ancestors" that involve trees containing only the files modified
+in the patch. Without accurate tree information, directory rename
+detection cannot safely operate and is thus
Am 03.12.2018 um 23:04 schrieb Jeff King:
> On Sun, Dec 02, 2018 at 11:52:50AM +0100, René Scharfe wrote:
>
>>> And for mu.git, a ~20k object repo:
>>>
>>> Test origin/master
>>> peff/jk/loose-cache avar/check-collisions-config
>>>
On Mon, 3 Dec 2018, Johannes Sixt wrote:
> The text body of section Behavioral Differences is typeset as code,
> but should be regular text. Remove the indentation to achieve that.
>
> While here, prettify the language:
>
> - use "the x backend" instead of "x-based rebase";
> - use present
On Tue, Dec 4, 2018 at 11:28 AM Duy Nguyen wrote:
> Haven't really worked on killing the term "detached HEAD" yet. But I
> noticed the other day that git-branch reports
>
> * (HEAD detached from 703266f6e4)
>
> and I didn't know how to rephrase that. I guess "unnamed branch from
> 703266f6e4" is
On Mon, Dec 3, 2018 at 3:38 PM Jonathan Tan wrote:
>
> This is a partial implementation of upload-pack sending part of its
> packfile response as URIs.
It does so by implementing a new flag `--exclude-configured-blobs`
in pack-objects, which would change the output of pack-objects to
output a
> Some thoughts here:
>
> First, I'd like to see a section (and a bit in the implementation)
> requiring HTTPS if the original protocol is secure (SSH or HTTPS).
> Allowing the server to downgrade to HTTP, even by accident, would be a
> security problem.
>
> Second, this feature likely should be
On Thu, 29 Nov 2018 at 16:39, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 29 2018, Mateusz Loskot wrote:
> > On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason
> > wrote:
> >> On Wed, Nov 28 2018, Mateusz Loskot wrote:
> >> >
> >> > (using git version 2.19.2.windows.1)
> >> >
> >> > I've
On Tue, Dec 4, 2018 at 7:31 PM Elijah Newren wrote:
>
> On Tue, Dec 4, 2018 at 10:22 AM Duy Nguyen wrote:
> >
> > On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren wrote:
> > > > > > - Two more fancy features (the "git checkout --index" being the
> > > > > > default mode and the backup log for
On Tue, Dec 4, 2018 at 10:22 AM Duy Nguyen wrote:
>
> On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren wrote:
> > > > > - Two more fancy features (the "git checkout --index" being the
> > > > > default mode and the backup log for accidental overwrites) are of
> > > > > course still missing. But
On Tue, Dec 4, 2018 at 6:45 PM Elijah Newren wrote:
> > > > - Two more fancy features (the "git checkout --index" being the
> > > > default mode and the backup log for accidental overwrites) are of
> > > > course still missing. But they are coming.
> > > >
> > > > I did not go replace
sure how to move it here (I guess 'here' is
restore-files since we won't move HEAD). All the --mixed, --merge and
--hard are confusing. But maybe we could just make 'git restore-files
--from HEAD -f :/" behave just like "git reset --hard HEAD" (but with
some safety net) But we can l
On Tue, Dec 04 2018, SZEDER Gábor wrote:
> Unfortunately, we have a few flaky tests, whose failures tend to be
> hard to reproduce. We've found that the best we can do to reproduce
> such a failure is to run the test repeatedly while the machine is
> under load, and wait in the hope that the
On Tue, Dec 4, 2018 at 8:28 AM Duy Nguyen wrote:
>
> On Tue, Dec 4, 2018 at 2:29 AM Elijah Newren wrote:
> >
> > On Thu, Nov 29, 2018 at 2:01 PM Nguyễn Thái Ngọc Duy
> > wrote:
> > >
> > > v3 sees switch-branch go back to switch-branch (in v2 it was
> > > checkout-branch). checkout-files is
On Tue, Dec 4, 2018 at 8:22 AM Duy Nguyen wrote:
>
> Thanks for all the comments! There are still some I haven't replied
> (either I'll agree and do it anyway, or I'll need some more time to
> digest)
>
> On Tue, Dec 4, 2018 at 1:45 AM Elijah Newren wrote:
> > > +'git restore-files' [--from=]
On Tue, Dec 04, 2018 at 06:04:14PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Dec 04 2018, SZEDER Gábor wrote:
>
> > The number of parallel invocations is determined by, in order of
> > precedence: the number specified as '--stress=', or the value of
> > the GIT_TEST_STRESS_LOAD
On Tue, Dec 04 2018, SZEDER Gábor wrote:
> The number of parallel invocations is determined by, in order of
> precedence: the number specified as '--stress=', or the value of
> the GIT_TEST_STRESS_LOAD environment variable, or twice the number of
> available processors in '/proc/cpuinfo', or 8.
On Tue, Dec 4, 2018 at 2:29 AM Elijah Newren wrote:
>
> On Thu, Nov 29, 2018 at 2:01 PM Nguyễn Thái Ngọc Duy
> wrote:
> >
> > v3 sees switch-branch go back to switch-branch (in v2 it was
> > checkout-branch). checkout-files is also renamed restore-files (v1 was
> > restore-paths). Hopefully we
Thanks for all the comments! There are still some I haven't replied
(either I'll agree and do it anyway, or I'll need some more time to
digest)
On Tue, Dec 4, 2018 at 1:45 AM Elijah Newren wrote:
> > +'git restore-files' [--from=] ...
>
> Isn't this already inferred by the previous line? Or was
On Tue, Nov 27, 2018 at 11:54:45PM +0100, Ævar Arnfjörð Bjarmason wrote:
> As noted in the updated t/README documentation being added here
> setting this new GIT_TODO_TESTS variable is usually better than
> GIT_SKIP_TESTS.
I don't see why this is "usually better". I get how it can help your
On Tue, 2018-12-04 at 13:01 +0100, Christian Couder wrote:
> To debug I think it would be interesting to see the output of the
> following commands just before we get different results:
>
> git for-each-ref 'refs/bisect/*'
>
> and
>
> git log -1 --format=oneline
>
I placed the following
On Tue, Dec 4, 2018 at 12:20 PM Lukáš Krejčí wrote:
>
> On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
> >
> > Could you try to check that? And first could you give us the output of:
> >
> > git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
> >
(I'm sorry about the formatting, here's the message again.)
Executing git bisect replay reaches a different commit than
the one that is obtained by running the commands from the bisect log manually.
Distribution: Arch Linux
git: 2.19.2-1
perl: 5.28.1-1
pcre2: 10.32-1
expat: 2.2.6-1
perl-error:
On Tue, 2018-12-04 at 12:04 +0100, Christian Couder wrote:
>
> Could you try to check that? And first could you give us the output of:
>
> git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
> 94710cac0ef4ee177a63b5227664b38c95bbf703
$ git merge-base 5b394b2ddf0347bef56e50c69a58773c94343ff3
On Tue, Dec 4, 2018 at 10:53 AM Lukáš Krejčí wrote:
>
> Executing git bisect replay reaches a different commit than
> the one that is obtained by running the commands from the bisect log manually.
> $ git bisect replay /var/tmp/git-bisect.log
> We are not bisecting.
> Bisecting: a merge base
101 - 200 of 100366 matches
Mail list logo
