Am 09.01.2018 um 00:26 schrieb Junio C Hamano:
Thomas Gummerer writes:
c3a9ad3117 ("oidset: add iterator methods to oidset", 2017-11-21)
introduced a 'oidset_init()' function in oidset.h, which has void as
return type, but returns an expression.
...
diff --git a/oidset.h b/oidset.h
index 783ab
On Mon, Jan 08, 2018 at 03:04:20PM -0500, Jeff Hostetler wrote:
> > I was thinking about something similar to the logic we use today
> > about whether to start reporting progress on other long commands.
> > That would mean you could still get the ahead/behind values if you
> > aren't that far behi
On Mon, Jan 08, 2018 at 08:43:44AM -0500, Derrick Stolee wrote:
> > Just to make sure I'm parsing this correctly: normal lookups do get faster
> > when you have a single index, given the right setup?
> >
> > I'm curious what that setup looked like. Is it just tons and tons of
> > packs? Is it one
On Mon, Jan 08, 2018 at 02:43:00PM +0100, Johannes Schindelin wrote:
> Take the interactive rebase for example. It generates todo lists with
> abbreviated commit names, for readability (and it is *really* important to
> keep this readable). As we expect new objects to be introduced by the
> intera
On Mon, Jan 08, 2018 at 11:47:20PM +0100, Lars Schneider wrote:
>
> > On 08 Jan 2018, at 22:28, Junio C Hamano wrote:
> >
> > lars.schnei...@autodesk.com writes:
> >
> >> diff --git a/sha1_file.c b/sha1_file.c
> >> index afe4b90f6e..dcb02e9ffd 100644
> >> --- a/sha1_file.c
> >> +++ b/sha1_file.
On Mon, Jan 8, 2018, at 3:49 PM, Stefan Beller wrote:
> On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres wrote:
> > Hi,
> >
> > I personally like the idea of git-evtags, but I feel that they could be
> > made so that push certificates (and being hash-algorithm agnostic)
> > should provide the sa
On Tue, Jan 9, 2018 at 6:38 AM, Brandon Williams wrote:
> On 01/08, Duy Nguyen wrote:
>> On Mon, Jan 8, 2018 at 5:30 AM, Thomas Gummerer wrote:
>> > @@ -1896,16 +1895,17 @@ int read_index_from(struct index_state *istate,
>> > const char *path)
>> > split_index->base = xcalloc(1,
On 01/08, Duy Nguyen wrote:
> On Mon, Jan 8, 2018 at 5:30 AM, Thomas Gummerer wrote:
> > @@ -1896,16 +1895,17 @@ int read_index_from(struct index_state *istate,
> > const char *path)
> > split_index->base = xcalloc(1, sizeof(*split_index->base));
> >
> > base_sha1_hex = sh
Thomas Gummerer writes:
> c3a9ad3117 ("oidset: add iterator methods to oidset", 2017-11-21)
> introduced a 'oidset_init()' function in oidset.h, which has void as
> return type, but returns an expression.
> ...
> diff --git a/oidset.h b/oidset.h
> index 783abceccd..40ec5f87fe 100644
> --- a/oidse
Lars Schneider writes:
> Nice catch. I'll fix that in the next iteration.
>
> Is it OK if I send the next iteration soon or would you prefer
> it if I wait until after 2.16 release?
>
> Plus, is it ok to keep the base of the series or would you prefer
> it if I rebase it to the latest master (bec
> On 08 Jan 2018, at 22:28, Junio C Hamano wrote:
>
> lars.schnei...@autodesk.com writes:
>
>> diff --git a/sha1_file.c b/sha1_file.c
>> index afe4b90f6e..dcb02e9ffd 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -75,14 +75,14 @@ static struct cached_object *find_cached_object(const
>>
On 01/08, Duy Nguyen wrote:
> On Mon, Jan 8, 2018 at 5:30 AM, Thomas Gummerer wrote:
> > @@ -1896,16 +1895,17 @@ int read_index_from(struct index_state *istate,
> > const char *path)
> > split_index->base = xcalloc(1, sizeof(*split_index->base));
> >
> > base_sha1_hex = sh
> On 08 Jan 2018, at 23:07, Junio C Hamano wrote:
>
> SZEDER Gábor writes:
>
>> The reason why Travis CI does it this way and why it's a better
>> approach than ours lies in how unsuccessful build jobs are
>> categorized. ...
>> ...
>> This makes it easier, both for humans looking at the Trav
On Mon, 08 Jan 2018, Ævar Arnfjörð Bjarmason wrote:
> > I'll add a "NO_RUNTIME_PREFIX_PERL" flag as per avarab@'s suggestion as a
> > potential mitigation if a problem does end up arising in Windows builds,
> > with a note that NO_RUNTIME_PREFIX_PERL can be deleted if everything seems
> > to be wo
On Mon, Jan 08 2018, Dan Jacques jotted:
> On 2018-01-08 20:27, Johannes Schindelin wrote:
>
>> > Maybe we covered this in previous submissions, but refresh my memory,
>> > why is the *_PERL define still needed? Reading this explanation doesn't
>> > make sense to me, but I'm probably missing some
René Scharfe writes:
> 7c117184d7 (bisect: fix off-by-one error in `best_bisection_sorted()`)
> fixed an off-by-one error, plugged a memory leak and removed a NULL
> check. However, the pointer p *is* actually NULL if an empty list is
> passed to the function. Let's add the check back for safet
On Mon, Jan 8, 2018 at 10:46 PM, Stefan Beller wrote:
> On Mon, Jan 8, 2018 at 1:08 PM, Per Cederqvist wrote:
>> I have a situation where I have switched a directory from being a
>> subdirectory to being a submodule. I then try to cherry-pick a commit
>> from a taskbranch that was made before th
SZEDER Gábor writes:
> The reason why Travis CI does it this way and why it's a better
> approach than ours lies in how unsuccessful build jobs are
> categorized. ...
> ...
> This makes it easier, both for humans looking at the Travis CI web
> interface and for automated tools querying the Travi
On Mon, 8 Jan 2018 15:35:59 -0500
Derrick Stolee wrote:
> Thanks! That is certainly the idea. If you know about MIDX, then you can
> benefit from it. If you do not, then you have all the same data
> available to you do to your work. Having a MIDX file will not break
> other tools (libgit2, JGi
On 2018-01-08 20:27, Johannes Schindelin wrote:
> > Maybe we covered this in previous submissions, but refresh my memory,
> > why is the *_PERL define still needed? Reading this explanation doesn't
> > make sense to me, but I'm probably missing something.
>
> If the reason is to accommodate Window
Johannes Schindelin writes:
> On Mon, 8 Jan 2018, Dan Jacques wrote:
>
>> On Mon, 08 Jan 2018, Ævar Arnfjörð Bjarmason replied:
>>
>> >>+# it. This is intentionally separate from RUNTIME_PREFIX so that
>> >>notably Windows +# can hard-code Perl library paths while still
>> >>enabling RUNTIME_PRE
Hello Dscho,
Am 08.01.2018 um 21:45 schrieb Johannes Schindelin:
> Isn't this identical to
> https://public-inbox.org/git/20180103184852.27271-1-ava...@gmail.com/ ?
yes, indeed, thanks. So here's an upvote for Ævar's patch then. :)
(I should have sent it earlier, but was not fully convinced it
On Mon, Jan 8, 2018 at 1:08 PM, Per Cederqvist wrote:
> I have a situation where I have switched a directory from being a
> subdirectory to being a submodule. I then try to cherry-pick a commit
> from a taskbranch that was made before the switch to the master
> branch. The commit touches a file
lars.schnei...@autodesk.com writes:
> diff --git a/sha1_file.c b/sha1_file.c
> index afe4b90f6e..dcb02e9ffd 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -75,14 +75,14 @@ static struct cached_object *find_cached_object(const
> unsigned char *sha1)
> }
>
>
> -static enum safe_crlf get_s
I have a situation where I have switched a directory from being a
subdirectory to being a submodule. I then try to cherry-pick a commit
from a taskbranch that was made before the switch to the master
branch. The commit touches a file outside the subdirectory/submodule.
Yet "git cherry-pick" fails
On 1/5/2018 5:22 PM, Junio C Hamano wrote:
Johannes Schindelin writes:
diff --git a/diff-lib.c b/diff-lib.c
index 8104603a3..13ff00d81 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -95,6 +95,9 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
diff_set_mnemonic_prefix(&rev
> Personally I'd dislike to include ev-tags as it might send a signal
> of "papering over sha1 issues instead of fixing it".
+1. I probably didn't convey it well, but this is what I was hoping for.
I think git has enough building blocks to provide something akin to git
evtags already.
Thanks,
-Sa
Yeah, I see where you're coming from. I don't think push certificates
have caught on yet...
You can read on them on [1], and also under the
Documentation/git-push:147.
There's also another PR trying to make a sample hook for signed
pushes on [2].
The basic idea is to push a signed data structure
On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres wrote:
> Hi,
>
> I personally like the idea of git-evtags, but I feel that they could be
> made so that push certificates (and being hash-algorithm agnostic)
> should provide the same functionality with less code.
>
> To me, a git evtag is basically
Hi René,
On Mon, 8 Jan 2018, René Scharfe wrote:
> 7c117184d7 (bisect: fix off-by-one error in `best_bisection_sorted()`)
> fixed an off-by-one error, plugged a memory leak and removed a NULL
> check. However, the pointer p *is* actually NULL if an empty list is
> passed to the function. Let's
On Mon, Jan 8, 2018, at 3:40 PM, Santiago Torres wrote:
> Hi,
>
> I personally like the idea of git-evtags, but I feel that they could be
> made so that push certificates (and being hash-algorithm agnostic)
> should provide the same functionality with less code.
What's a "push certificate"? (I
Hi,
I personally like the idea of git-evtags, but I feel that they could be
made so that push certificates (and being hash-algorithm agnostic)
should provide the same functionality with less code.
To me, a git evtag is basically a signed tag + a data structure similar
to a push certificate embedd
Elijah Newren writes:
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 2ecf495cc2..780f81a8bd 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> @@ -1952,6 +1952,13 @@ int merge_trees(struct merge_options *o,
> }
>
> if (oid_eq(&common->object.oid, &merge->obje
7c117184d7 (bisect: fix off-by-one error in `best_bisection_sorted()`)
fixed an off-by-one error, plugged a memory leak and removed a NULL
check. However, the pointer p *is* actually NULL if an empty list is
passed to the function. Let's add the check back for safety. Bisecting
nothing doesn't m
On 1/8/2018 2:32 PM, Jonathan Tan wrote:
On Sun, 7 Jan 2018 13:14:42 -0500
Derrick Stolee wrote:
+Design Details
+--
+
+- The MIDX file refers only to packfiles in the same directory
+ as the MIDX file.
+
+- A special file, 'midx-head', stores the hash of the latest
+ MIDX file
Hi,
On Mon, 8 Jan 2018, Colin Walters wrote:
> Hi, so quite a while ago I wrote this:
> https://github.com/cgwalters/git-evtag
For the benefit of readers who prefer to stay in their mail readers:
git-evtag
git-evtag can be used as a replacement for git-tag -s. It will
g
On 1/4/2018 5:33 PM, Johannes Schindelin wrote:
Hi Alex,
On Tue, 2 Jan 2018, Alex Vandiver wrote:
Rather than display one very long line, summarize the contents of that
line. The tests do not currently rely on any content except the first
line ("no fsmonitor" / "fsmonitor last update").
T
Hi,
On Mon, 8 Jan 2018, Dan Jacques wrote:
> On Mon, 08 Jan 2018, Ævar Arnfjörð Bjarmason replied:
>
> >>+# it. This is intentionally separate from RUNTIME_PREFIX so that
> >>notably Windows +# can hard-code Perl library paths while still
> >>enabling RUNTIME_PREFIX +# resolution.
> >
> > Maybe
On 1/4/2018 5:27 PM, Johannes Schindelin wrote:
Hi Alex,
On Tue, 2 Jan 2018, Alex Vandiver wrote:
These were inline'd when they were first introduced, presumably as an
optimization for cases when they were called in tight loops. This
complicates using these functions, as untracked_cache_inv
Hi,
On Mon, 8 Jan 2018, Ævar Arnfjörð Bjarmason wrote:
>
> On Mon, Jan 08 2018, Dan Jacques jotted:
>
> From 3/3 (not not send 2 e-mails):
>
> >+# it. This is intentionally separate from RUNTIME_PREFIX so that notably
> >Windows
> >+# can hard-code Perl library paths while still enabling RUNT
Hi, so quite a while ago I wrote this:
https://github.com/cgwalters/git-evtag
Since I last posted about this on the list here, of course
shattered.io happened. It also looks
like there was a node.js implementation written.
Any interest in having this in core git?
On Mon, Jan 8, 2018 at 11:56 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +static struct color_field {
>> + timestamp_t hop;
>> + char col[COLOR_MAXLEN];
>> +} *colorfield;
>> +static int colorfield_nr, colorfield_alloc;
>> +
>> +static void parse_color_fields(const char *s)
>>
On 1/8/2018 2:49 PM, Ben Peart wrote:
On 1/8/2018 10:48 AM, Jeff Hostetler wrote:
From: Jeff Hostetler
This is version 4 of my patch series to avoid expensive ahead/behind
calculations in status. This version removes the last commit containing
the experimental config setting. And removes
On Mon, Jan 08 2018, Dan Jacques jotted:
> On Mon, 08 Jan 2018, Ævar Arnfjörð Bjarmason replied:
>>>+# it. This is intentionally separate from RUNTIME_PREFIX so that notably
>>>Windows
>>>+# can hard-code Perl library paths while still enabling RUNTIME_PREFIX
>>>+# resolution.
>>
>> Maybe we cov
Stefan Beller writes:
> +static struct color_field {
> + timestamp_t hop;
> + char col[COLOR_MAXLEN];
> +} *colorfield;
> +static int colorfield_nr, colorfield_alloc;
> +
> +static void parse_color_fields(const char *s)
> +{
> + struct string_list l = STRING_LIST_INIT_DUP;
> + str
On 1/8/2018 10:48 AM, Jeff Hostetler wrote:
From: Jeff Hostetler
This is version 4 of my patch series to avoid expensive ahead/behind
calculations in status. This version removes the last commit containing
the experimental config setting. And removes the undefined return values
for the nr_a
On Sat, Jan 6, 2018 at 12:26 AM, Eric Sunshine wrote:
> On Thu, Jan 4, 2018 at 5:10 PM, Stefan Beller wrote:
>> On Thu, Dec 28, 2017 at 2:29 PM, Eric Sunshine
>> wrote:
>>> On Thu, Dec 28, 2017 at 4:03 PM, Stefan Beller wrote:
+static inline void colors_unset(const char **use_color, const
Hi Matwey,
On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
> 2018-01-08 19:32 GMT+03:00 Johannes Schindelin :
> >
> > On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
> >
> >> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov :
> >> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin
> >> > :
> >> >> Hi Mat
Stefan Beller writes:
> +color.blame.repeatedMeta::
> + Use the customized color for the part of git-blame output that
> + is repeated meta information per line (such as commit id,
> + author name, date and timezone). Defaults to dark gray.
> +
> ...
"Dark gray on default background"
On Sun, 7 Jan 2018 13:14:42 -0500
Derrick Stolee wrote:
> +Design Details
> +--
> +
> +- The MIDX file refers only to packfiles in the same directory
> + as the MIDX file.
> +
> +- A special file, 'midx-head', stores the hash of the latest
> + MIDX file so we can load the file with
On Mon, 08 Jan 2018, Ævar Arnfjörð Bjarmason replied:
> Thanks, applied this on top of next and it works for me, i.e. install to
> /tmp/git and move to /tmp/git2 = works for me. Comments below.
Good to hear! I've run this through a few machines at my disposal, but
the more hands on the better.
>
"Christian Couder" wrote:
> Hi,
>
> On Fri, Jan 5, 2018 at 12:18 PM, Johannes Schindelin
> wrote:
>> Hi,
>>
>> On Fri, 5 Jan 2018, Matthieu Moy wrote:
>>
>>> If we go for it, we need:
>>>
>>> * Admins
>>>
>>> * Potential mentors
>>
>> Count me in as a potential mentor.
>
> I am ok to be admin
Stefan Beller writes:
> /*
> - * Set the color buffer (which must be COLOR_MAXLEN bytes)
> - * to the raw color bytes; this is useful for initializing
> - * default color variables.
> + * NEEDSWWORK: document this function or refactor grep.c to stop using this
> + * function.
> */
> -void colo
On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
wrote:
> These are just a few improvements that I thought would make the documentation
> related to submodules a little better in various way such as readability,
> consistency etc., These were things I noticed while reading thise documents.
>
> So
On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
wrote:
> Signed-off-by: Kaartic Sivaraam
> ---
> Documentation/git-submodule.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index ff612001d..b
On 01/05, Ramsay Jones wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Brandon,
>
> If you need to re-roll your 'bw/protocol-v2' branch, could you please
> squash this (or something like it) into the relevant patches. The first
> hunk would go in commit 6ec1105192, "upload-pack: convert to
Ævar Arnfjörð Bjarmason writes:
> I agree that there should be some prerequisite to skip this on Windows
> by default since 6 minutes is clearly excessive (although I think you'll
> find it runs a bit faster in the branch above), but that should be
> something like:
>
> test_lazy_prereq EXPEN
On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
wrote:
> Signed-off-by: Kaartic Sivaraam
> ---
> Documentation/gitsubmodules.txt | 19 ++-
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> ind
On Sat, Jan 6, 2018 at 4:39 PM, Eric Sunshine wrote:
> On Sat, Jan 6, 2018 at 1:46 PM, Kaartic Sivaraam
> wrote:
>> Signed-off-by: Kaartic Sivaraam
>> ---
>> diff --git a/Documentation/gitsubmodules.txt
>> b/Documentation/gitsubmodules.txt
>> @@ -113,7 +113,7 @@ obtain the submodule from is con
Matthieu Moy writes:
> From: Alex Bennée
>
> We had a regression that broke Linux's get_maintainer.pl. Using
> Mail::Address to parse email addresses fixed it, but let's protect
> against future regressions.
>
> Note that we need --cc-cmd to be relative because this option doesn't
> accept space
On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
wrote:
> Signed-off-by: Kaartic Sivaraam
> ---
> Documentation/gitsubmodules.txt | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> index 3f73983d5..e
On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
wrote:
> Signed-off-by: Kaartic Sivaraam
> ---
> Documentation/gitsubmodules.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> index cb795c6b6..3f73983d5 100644
> -
On Sat, Jan 6, 2018 at 10:46 AM, Kaartic Sivaraam
wrote:
> Signed-off-by: Kaartic Sivaraam
> ---
> Documentation/gitsubmodules.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/gitsubmodules.txt b/Documentation/gitsubmodules.txt
> index bf46b0fb5..cb795c6
On Sat, Jan 6, 2018 at 4:29 PM, Eric Sunshine wrote:
> On Sat, Jan 6, 2018 at 1:46 PM, Kaartic Sivaraam
> wrote:
>> Signed-off-by: Kaartic Sivaraam
>> ---
>> diff --git a/Documentation/gitsubmodules.txt
>> b/Documentation/gitsubmodules.txt
>> @@ -36,8 +36,8 @@ The `gitlink` entry contains the o
On Mon, Jan 08, 2018 at 03:38:48PM +0100, Lars Schneider wrote:
[]
> > Some comments:
> >
> > I would like to have the CRLF conversion a little bit more strict -
> > many users tend to set core.autocrlf=true or write "* text=auto"
> > in the .gitattributes.
> > Reading all the effort about BOM mar
On January 7, 2018 4:18 PM, brian m. Carlson wrote:
> On Sun, Jan 07, 2018 at 03:57:59PM -0500, Randall S. Becker wrote:
> > I'm looking for a proper (i.e. not sneaky) way to detect the platform
> > I am on during testing so that some tests can be modified/skipped
> > other than using the standard
I haven't used perforce so am unfamiliar with any behaviors specific to that
but the logic to have git automatically tell watchman to start watching repos
is just a convenience feature. Feel free to remove/disable/modify it in the
fsmonitor-watchman integration script:
if ($retry > 0 a
2018-01-08 19:32 GMT+03:00 Johannes Schindelin :
> Hi,
>
> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
>
>> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov :
>> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin
>> > :
>> >> Hi Matwey,
>> >>
>> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
>> >>
Ever since we started building and testing Git on Travis CI (522354d70
(Add Travis CI support, 2015-11-27)), we build Git in the
'before_script' phase and run the test suite in the 'script' phase
(except in the later introduced 32 bit Linux and Windows build jobs,
where we build in the 'script' pha
Hi!
I could be wrong about this, but I when I tried mixing watchman with
git-p4, I found that on "git p4 submit" it ended up watching the p4
repo, which seems a bit pointless (and was also very slow).
$ [create git-p4 clone of some p4 repo]
$ : >bar
$ git add bar && git commit -m 'adding bar'
$ g
Hi,
On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
> 2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov :
> > 2018-01-08 16:56 GMT+03:00 Johannes Schindelin :
> >> Hi Matwey,
> >>
> >> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
> >>
> >>> I think that rebase preserve-merges algorithm needs further
>
From: Jeff Hostetler
Teach long (normal) status format to respect the --no-ahead-behind
parameter and skip the possibly expensive ahead/behind computation
between the branch and the upstream.
Long status also respects "status.aheadBehind" config setting.
Signed-off-by: Jeff Hostetler
---
buil
From: Jeff Hostetler
Teach "git status --short --branch" to respect "--no-ahead-behind"
parameter to skip computing ahead/behind counts for the branch and
its upstream and just report '[different]'.
Short status also respect the "status.aheadBehind" config setting.
Signed-off-by: Jeff Hostetler
From: Jeff Hostetler
This is version 4 of my patch series to avoid expensive ahead/behind
calculations in status. This version removes the last commit containing
the experimental config setting. And removes the undefined return values
for the nr_ahead/nr_behind arguments as discussed on the mai
From: Jeff Hostetler
Extend stat_tracking_info() to return +1 when branches are not equal and to
take a new "enum ahead_behind_flags" argument to allow skipping the (possibly
expensive) ahead/behind computation.
This will be used in the next commit to allow "git status" to avoid full
ahead/behin
From: Jeff Hostetler
Teach "git status" and "git commit" to accept "--no-ahead-behind"
and "--ahead-behind" arguments to request quick or full ahead/behind
reporting.
When "--no-ahead-behind" is given, the existing porcelain V2 line
"branch.ab x y" is replaced with a new "branch equal eq|neq" li
Hi,
On Mon, Jan 8, 2018 at 3:45 PM, Yasushi SHOJI wrote:
> Hi all,
>
> Thank you guys for insightful help. I just read the code and now I understand
> what you guys are saying. Yeah, I can say the fix is "spot on".
>
> But, to be honest, it's hard to see why you need "if (p)" at the first
> g
2018-01-08 17:42 GMT+03:00 Matwey V. Kornilov :
> 2018-01-08 16:56 GMT+03:00 Johannes Schindelin :
>> Hi Matwey,
>>
>> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
>>
>>> I think that rebase preserve-merges algorithm needs further
>>> improvements. Probably, you already know it.
>>
>> Yes. preserv
Hi all,
Thank you guys for insightful help. I just read the code and now I understand
what you guys are saying. Yeah, I can say the fix is "spot on".
But, to be honest, it's hard to see why you need "if (p)" at the first glance.
So, how about this fix, instead?
I also found a bug in show_list
2018-01-08 16:56 GMT+03:00 Johannes Schindelin :
> Hi Matwey,
>
> On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
>
>> I think that rebase preserve-merges algorithm needs further
>> improvements. Probably, you already know it.
>
> Yes. preserve-merges is a fundamentally flawed design.
>
> Please have
> On 07 Jan 2018, at 10:38, Torsten Bögershausen wrote:
>
> On Sat, Jan 06, 2018 at 01:48:01AM +0100, lars.schnei...@autodesk.com wrote:
>> From: Lars Schneider
>>
>> Hi,
>>
>> Patches 1-5 and 6 are helper functions and preparation.
>> Patch 6 is the actual change.
>>
>> I am still torn betw
On 1/8/2018 1:37 AM, Jeff King wrote:
On Fri, Jan 05, 2018 at 11:46:24AM -0500, Jeff Hostetler wrote:
I'm mildly negative on this "level 2" config. If influencing the
porcelain via config creates compatibility headaches, then why would we
allow it here? And if it doesn't, then why do we need
Hi Matwey,
On Mon, 8 Jan 2018, Matwey V. Kornilov wrote:
> I think that rebase preserve-merges algorithm needs further
> improvements. Probably, you already know it.
Yes. preserve-merges is a fundamentally flawed design.
Please have a look here:
https://github.com/git/git/pull/447
Sin
Hi Myles,
On Mon, 8 Jan 2018, Myles Fong wrote:
> Brief description:
> When two tags are pointing to the same commit, e.g. tagA and tagB, if I
> do `git checkout tagA` then `git checkout tagB`, and then `git status`,
> it shows `HEAD detached at tagA`
>
> Expected behaviour:
> I'm expecting it
On 1/8/2018 5:20 AM, Jeff King wrote:
On Sun, Jan 07, 2018 at 07:08:54PM -0500, Derrick Stolee wrote:
(Not a critique of this, just a (stupid) question)
What's the practical use-case for this feature? Since it doesn't help
with --abbrev=40 the speedup is all in the part that ensures we don't
s
Hi Peff,
On Mon, 8 Jan 2018, Jeff King wrote:
> On Sun, Jan 07, 2018 at 07:08:54PM -0500, Derrick Stolee wrote:
>
> > > (Not a critique of this, just a (stupid) question)
> > >
> > > What's the practical use-case for this feature? Since it doesn't
> > > help with --abbrev=40 the speedup is all
Hi Ævar,
On Sat, 6 Jan 2018, Ævar Arnfjörð Bjarmason wrote:
> Can you please provide me with the output of the test under -v -x -d
> from github.com:avar/git.git wildmatch-refactor-8 branch?
With -v -x -i:
-- snip --
[...]
expecting success:
printf '%s' '?a?b' >e
On Mon, Jan 08 2018, Jeff King jotted:
> On Mon, Jan 08, 2018 at 05:20:29AM -0500, Jeff King wrote:
>
>> I.e., what if we did something like this:
>>
>> diff --git a/sha1_name.c b/sha1_name.c
>> index 611c7d24dd..04c661ba85 100644
>> --- a/sha1_name.c
>> +++ b/sha1_name.c
>> @@ -600,6 +600,15 @@
Hi Duy,
On Sun, 7 Jan 2018, Duy Nguyen wrote:
> On Sat, Jan 6, 2018 at 7:51 PM, Johannes Schindelin
> wrote:
> > Nobody likes to run tests that take too
> > long. And look at this:
> >
> > ...
> > ok 1511 - ipathmatch: match 'Z' '[Z-y]'
> > ok 1512 - ipathmatch(ls): match
--
Greetings,
Can you handle a transaction that involves the transfer of fund valued
15 million Euros into a foreign account. I will give you the full
detailed information as soon as I hear from you. Send me the
followings if you are willing and ready to work with me.
1)Full Names (2)Occupation (
Matthieu Moy writes:
> We now use Mail::Address unconditionaly, hence parse_mailboxes is now
> dead code. Remove it and its tests.
>
> Signed-off-by: Matthieu Moy
Reviewed-by: Alex Bennée
> ---
> No change since v2.
>
> perl/Git.pm | 71
> --
Matthieu Moy writes:
> We used to have two versions of the email parsing code. Our
> parse_mailboxes (in Git.pm), and Mail::Address which we used if
> installed. Unfortunately, both versions have different sets of bugs, and
> changing the behavior of git depending on whether Mail::Address is
> i
From: "Friedrich Spee von Langenfeld"
Hi,
I analyzed the GitHub repository with Cppcheck. The resulting XML file
is attached. Please open it in Cppcheck to view it comfortably.
Especially the bunch of errors could be of interest to you.
Hi,
Thanks for the submission.
The list prefers that
On Mon, Jan 08 2018, Derrick Stolee jotted:
> On 1/7/2018 5:42 PM, Ævar Arnfjörð Bjarmason wrote:
>> If something cares about both throughput and e.g. is saving the
>> abbreviated SHA-1s isn't it better off picking some arbitrary size
>> (e.g. --abbrev=20), after all the default abbreviation is g
On Mon, Jan 8, 2018 at 5:30 AM, Thomas Gummerer wrote:
> @@ -1896,16 +1895,17 @@ int read_index_from(struct index_state *istate, const
> char *path)
> split_index->base = xcalloc(1, sizeof(*split_index->base));
>
> base_sha1_hex = sha1_to_hex(split_index->base_sha1);
> -
From: Alex Bennée
We had a regression that broke Linux's get_maintainer.pl. Using
Mail::Address to parse email addresses fixed it, but let's protect
against future regressions.
Note that we need --cc-cmd to be relative because this option doesn't
accept spaces in script names (probably to allow
We now use Mail::Address unconditionaly, hence parse_mailboxes is now
dead code. Remove it and its tests.
Signed-off-by: Matthieu Moy
---
No change since v2.
perl/Git.pm | 71
t/t9000-addresses.sh | 27
t/t9000/t
We used to have two versions of the email parsing code. Our
parse_mailboxes (in Git.pm), and Mail::Address which we used if
installed. Unfortunately, both versions have different sets of bugs, and
changing the behavior of git depending on whether Mail::Address is
installed was a bad idea.
A first
Eric Sunshine writes:
> On Fri, Jan 5, 2018 at 1:36 PM, Matthieu Moy wrote:
>> From: Alex Bennée
>>
>> We had a regression that broke Linux's get_maintainer.pl. Using
>> Mail::Address to parse email addresses fixed it, but let's protect
>> against future regressions.
>>
>> Patch-edited-by: Matt
On Mon, Jan 08, 2018 at 05:20:29AM -0500, Jeff King wrote:
> I.e., what if we did something like this:
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 611c7d24dd..04c661ba85 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -600,6 +600,15 @@ int find_unique_abbrev_r(char *hex, const unsigned
1 - 100 of 103 matches
Mail list logo
