Joel Teichroeb writes:
> +static void stash_create_callback(struct diff_queue_struct *q,
> + struct diff_options *opt, void *cbdata)
> +{
> + int i;
> +
> + for (i = 0; i < q->nr; i++) {
> + struct diff_filepair *p = q->queue[i];
> + con
On Fri, Jun 16, 2017 at 11:10 PM, Ævar Arnfjörð Bjarmason
wrote:
> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> index 35cc34b2fb..2169e5c97f 100644
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -189,6 +189,14 @@ object
SZEDER Gábor writes:
> Due to limitations/bugs in the current implementation, some
> configuration variables specified via 'git clone -c var=val' (or 'git
> -c var=val clone') are ignored during the initial fetch and checkout.
>
> Let the users know which configuration variables are known to be
>
SZEDER Gábor writes:
> diff --git a/remote.c b/remote.c
> index 336db8298..a021decee 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -919,6 +919,26 @@ char *apply_refspecs(struct refspec *refspecs, int
> nr_refspec,
> return query.dst;
> }
>
> +void strbuf_add_refspec(struct strbuf *sb, c
SZEDER Gábor writes:
> 'struct remote' stores refspecs twice: once in their original string
> form in remote->{fetch,push}_refspecs and once in their parsed form in
> remote->{fetch,push}. This is necessary, because we need the refspecs
> for lazy parsing after we finished reading the configurat
Mahmoud Al-Qudsi writes:
> I hope it is not considered too forward of me for my first post to this list
> to be a suggestion on a change to git’s behavior (though not in any
> functional manner); but a persistent frustration for me and everyone I’ve
> worked with (so, yes, 100% based off of anecd
On Fri, Jun 16 2017, Jonathan Nieder jotted:
> Part of the reason I suggested previously that it would be helpful to
> try to benchmark Git with various hash functions (which didn't go over
> well, for some reason) is that it makes these comparisons more
> concrete. Without measuring, it is hard
Jeff King writes:
> On Fri, Jun 16, 2017 at 12:30:49AM -0400, Liam Beguin wrote:
>
>> @@ -1642,6 +1664,8 @@ static void wt_longstatus_print(struct wt_status *s)
>> } else
>> printf(_("nothing to commit, working tree clean\n"));
>> }
>> +if (!git_config_g
Liam Beguin writes:
> Most of the time, a 'stash entry' is called a 'stash'
> or a 'stash state'. Lets use 'stash entry' instead.
>
> Signed-off-by: Liam Beguin
> ---
> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> index 70191d06b69e..59979ad31dfe 100644
> --- a/Docume
Junio C Hamano wrote:
> Junio C Hamano writes:
>> Adam Langley writes:
>>> However, as I'm not a git developer, I've no opinion on whether the
>>> cost of carrying implementations of these functions is worth the speed
>>> vs using SHA-256, which can be assumed to be supported everywhere
>>> alre
Junio C Hamano writes:
> Adam Langley writes:
>
>> However, as I'm not a git developer, I've no opinion on whether the
>> cost of carrying implementations of these functions is worth the speed
>> vs using SHA-256, which can be assumed to be supported everywhere
>> already.
>
> Thanks.
>
> My imp
On Fri, Jun 16 2017, Jonathan Nieder jotted:
> Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Jun 16 2017, SZEDER Gábor jotted:
>
>>> --- a/Documentation/git-clone.txt
>>> +++ b/Documentation/git-clone.txt
>>> @@ -186,6 +186,11 @@ objects from the source repository into a pack in the
>>> cloned repos
Johannes Sixt writes:
> Am 16.06.2017 um 15:49 schrieb Johannes Schindelin:
>> On Thu, 15 Jun 2017, Junio C Hamano wrote:
>>> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh
>>> index 325ec75353..801bce25da 100755
>>> --- a/t/t3420-rebase-autostash.sh
>>> +++ b/t/t3420-reba
Adam Langley writes:
> However, as I'm not a git developer, I've no opinion on whether the
> cost of carrying implementations of these functions is worth the speed
> vs using SHA-256, which can be assumed to be supported everywhere
> already.
Thanks.
My impression from this thread is that even
On Fri, Jun 16, 2017 at 03:24:19PM +0200, Johannes Schindelin wrote:
> I have no doubt that Visual Studio Team Services, GitHub and Atlassian
> will eventually end up with FPGAs for hash computation. So that's that.
I actually doubt this from the GitHub side. Hash performance is not even
on our r
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jun 16 2017, SZEDER Gábor jotted:
>> --- a/Documentation/git-clone.txt
>> +++ b/Documentation/git-clone.txt
>> @@ -186,6 +186,11 @@ objects from the source repository into a pack in the
>> cloned repository.
>> values are given for the same key, each
SZEDER Gábor wrote:
> Helped-by: Jeff King
> Signed-off-by: SZEDER Gábor
> ---
> builtin/clone.c | 36 +++-
> remote.c| 13 +
> remote.h| 1 +
> t/t5611-clone-config.sh | 47
SZEDER Gábor wrote:
> Due to limitations/bugs in the current implementation, some
> configuration variables specified via 'git clone -c var=val' (or 'git
> -c var=val clone') are ignored during the initial fetch and checkout.
>
> Let the users know which configuration variables are known to be
> i
Ævar Arnfjörð Bjarmason writes:
> A follow-up to the existing "type" rule added in an earlier
> change. This catches some occurrences that are missed by the previous
> rule.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason
> ---
Hmph, I wonder if the "type" thing is really needed. Over there,
"ptr"
Do the same as in the previous patch, but for push refspecs, i.e. with
remote->push_refspec, remote->push and add_push_refspec().
Signed-off-by: SZEDER Gábor
---
builtin/push.c | 12 +++-
builtin/remote.c | 19 ---
remote.c | 29 +++--
re
builtin/remote.c uses remote->fetch_refspec and remote->push_refspec,
i.e. refspecs as strings, in a few places, e.g. in an error message or
to set configuration variables.
Since we are about to eliminate remote->{fetch,push}_refspec, recreate
those strings from the corresponding remote->{fetch,pu
Currently neither add_fetch_refspec() nor add_push_refspec() duplicate
the refspecs before appending them to an array of refspecs, therefore
all their callers pass them copies of refspecs. Soon we won't store
refspecs as strings, therefore passing duplicated strings to these
functions will not be
'struct remote' stores refspecs twice: once in their original string
form in remote->{fetch,push}_refspecs and once in their parsed form in
remote->{fetch,push}. This is necessary, because we need the refspecs
for lazy parsing after we finished reading the configuration: we don't
want to die() on
'struct remote' stores fetch refspecs twice: once in their original
string form in remote->fetch_refspecs and once in their parsed form in
remote->fetch.
The main reason for this is that we want to read the configuration
only once, but we don't want to error out while doing so because of a
bogus r
Fetch refspecs read from the configuration are currently parsed
lazily: they are collected into a string array for each remote while
reading the configuration and then refspecs of a particular remote are
parsed together later when the remote is accessed by remote_get() or
for_each_remote().
We are
Am 16.06.2017 um 15:49 schrieb Johannes Schindelin:
On Thu, 15 Jun 2017, Junio C Hamano wrote:
diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh
index 325ec75353..801bce25da 100755
--- a/t/t3420-rebase-autostash.sh
+++ b/t/t3420-rebase-autostash.sh
@@ -45,7 +45,7 @@ create_e
SZEDER Gábor wrote:
> Signed-off-by: SZEDER Gábor
> ---
> A mere plural "line-feeds" was too subtle for me to grasp on first
> (and second...) reading.
This could go in the commit message.
> Documentation/pretty-formats.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
With or w
On Fri, Jun 16 2017, SZEDER Gábor jotted:
> Due to limitations/bugs in the current implementation, some
> configuration variables specified via 'git clone -c var=val' (or 'git
> -c var=val clone') are ignored during the initial fetch and checkout.
>
> Let the users know which configuration variab
On Fri, Jun 16, 2017 at 6:24 AM, Johannes Schindelin
wrote:
>
> And while I am really thankful that Adam chimed in, I think he would agree
> that BLAKE2 is a purposefully weakened version of BLAKE, for the benefit
> of speed
That is correct.
Although worth keeping in mind that the analysis resul
The initial fetch during a clone doesn't transfer refs matching
additional fetch refspecs given on the command line as configuration
variables. This contradicts the documentation stating that
configuration variables specified via 'git clone -c = ...'
"take effect immediately after the repository i
Only small, straightforward adjustments, mostly based on Jonathan's
comments.
The one exception is passing the default refspec using
strbuf_detach(), because add_fetch_refspec() doesn't make a copy of it
internally. It doesn't make any difference in practice, because
strbuf default_refspec remai
Due to limitations/bugs in the current implementation, some
configuration variables specified via 'git clone -c var=val' (or 'git
-c var=val clone') are ignored during the initial fetch and checkout.
Let the users know which configuration variables are known to be
ignored ('remote.origin.mirror' a
On Wed, Jun 14, 2017 at 2:48 AM, Jonathan Nieder wrote:
>> diff --git a/remote.h b/remote.h
>> index 924881169..9ad8c1085 100644
>> --- a/remote.h
>> +++ b/remote.h
>> @@ -164,6 +164,7 @@ struct ref *ref_remove_duplicates(struct ref *ref_map);
>>
>> int valid_fetch_refspec(const char *refspec);
Joel Teichroeb writes:
> diff --git a/builtin/stash.c b/builtin/stash.c
> new file mode 100644
> index 00..a9680f2909
> --- /dev/null
> +++ b/builtin/stash.c
> ...
> +static const char *ref_stash = "refs/stash";
> +static int quiet = 0;
Let BSS take care of zero-initialization, i.e. drop
On Thu, Jun 15, 2017 at 11:46 PM, Michael Haggerty wrote:
> On 06/16/2017 07:42 AM, Stefan Beller wrote:
>> On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty
>> wrote:
>>> This will later become a method of `packed_ref_store`.
>>
>> Also while touching it, maybe rename sha1 to object_hash
>> (no
On Thu, Jun 15, 2017 at 11:43 PM, Michael Haggerty wrote:
> I chose that name because it is a `ref_store`, with `packed_` being a
> short prefix that tells what kind of `ref_store`.
>
> The next question is, why `ref_store` as opposed to `refs_store`? To me
> it sounds more natural in English for
On Mon, Jun 12, 2017 at 1:27 PM, Stefan Beller wrote:
> On Sat, Jun 10, 2017 at 6:28 AM, John Shahid wrote:
>> bump. it's been a while and I'm still not clear what the next steps
>> are. I'm happy to send a patch but I would like to get a consensus
>> first.
>
> What do you want a consensus on?
>
Hi Liam,
On Thu, 15 Jun 2017, Liam Beguin wrote:
> On 14/06/17 09:08 AM, Johannes Schindelin wrote:
> > diff --git a/sequencer.c b/sequencer.c
> > index a697906d463..a0e020dab09 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -2640,3 +2640,110 @@ int check_todo_list(void)
> >
> >
Hi Junio,
On Thu, 15 Jun 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Changes since v4:
> >
> > - replaced the "sha1s" part of the names by "ids", to reflect the
> > current effort to move away from the cryptographically unsafe SHA-1
> >
> > - replaced the confusing term "i
Hi Junio,
On Thu, 15 Jun 2017, Junio C Hamano wrote:
> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh
> index 325ec75353..801bce25da 100755
> --- a/t/t3420-rebase-autostash.sh
> +++ b/t/t3420-rebase-autostash.sh
> @@ -45,7 +45,7 @@ create_expected_success_am() {
> }
>
>
Hi,
On Fri, 16 Jun 2017, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jun 16 2017, brian m. carlson jotted:
>
> > On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
> >
> >> So I don't follow the argument that we shouldn't weigh future HW
> >> acceleration highly just because y
Hi,
On 16/06/17 08:16 AM, Jeff King wrote:
> On Fri, Jun 16, 2017 at 12:30:47AM -0400, Liam Beguin wrote:
>
>> As discussed here [*1*], this allows `git status` to show the number of
>> entries currently stashed away.
>>
>> I also tried to update the related parts of the documentation to use
>>
On Thu, Jun 15, 2017 at 06:12:31PM +0200, René Scharfe wrote:
> Am 15.06.2017 um 15:52 schrieb Jeff King:
> > But for the special case of the "-local" formats, we can
> > just skip the adjustment and use localtime() instead of
> > gmtime(). This makes --date=format-local:%Z work correctly,
> > sho
On Fri, Jun 16, 2017 at 11:27:39AM +, Clébio C. Felix wrote:
>>> Details: https://github.com/git-for-windows/git/issues/1203
>>>
>>> Version with bug: 2.13.1
>>> Normal: 2.13.0
>>
>> Attached are the pictures for those who doesn't want to browse that bug
>> and dig them up.
>>
>> Basicall
On Fri, Jun 16, 2017 at 12:30:47AM -0400, Liam Beguin wrote:
> As discussed here [*1*], this allows `git status` to show the number of
> entries currently stashed away.
>
> I also tried to update the related parts of the documentation to use
> 'stash entry' instead of 'stash' as we agreed that it
On Fri, Jun 16, 2017 at 12:30:50AM -0400, Liam Beguin wrote:
> diff --git a/Documentation/glossary-content.txt
> b/Documentation/glossary-content.txt
> index 6e991c246915..026f66e7240a 100644
> --- a/Documentation/glossary-content.txt
> +++ b/Documentation/glossary-content.txt
> @@ -570,6 +570,10
On Fri, Jun 16, 2017 at 12:30:49AM -0400, Liam Beguin wrote:
> @@ -1642,6 +1664,8 @@ static void wt_longstatus_print(struct wt_status *s)
> } else
> printf(_("nothing to commit, working tree clean\n"));
> }
> + if (!git_config_get_bool("status.showStas
On Fri, Jun 16, 2017 at 12:30:48AM -0400, Liam Beguin wrote:
> Most of the time, a 'stash entry' is called a 'stash'
> or a 'stash state'. Lets use 'stash entry' instead.
I agree that this reads better. There is one exception:
> diff --git a/git-stash.sh b/git-stash.sh
> index 2fb651b2b8d9..0dfa
If this is an intentional change and not a bug, then gitk has become less
useful to me, since I've always used it to do a quick review before committing.
It's easier than using bash. Sad.
:-(
De: Konstantin Khomoutov
Para: Clébio C. Felix
Cc: git@vger.kernel
On Fri, Jun 16, 2017 at 04:06:48PM +0530, Kaartic Sivaraam wrote:
> From what I could get from this thread, I guess the current patch
> stands something like the one below. I tried building it with the below
> change, it seems to be having a little issue. I'm not sure why, it
> seems to be working
On Thu, 2017-06-15 at 09:12 -0400, Jeff King wrote:
> On Thu, Jun 15, 2017 at 07:43:17AM -0400, Samuel Lijin wrote:
>
> > > Saying just "staged changes" is definitely accurate. I don't know
> > > if
> > > some users would find that too terse, too. The phrase "not staged
> > > for
> > > commit" gi
(Sorry I sent this originally last night in gmail but not in plain
text mode and it bounced)
Hi Michael,
In git if you don't merge often then you get these merge conflict hell
situations.
In my experience the main conflicts come not from the unified diff of
those 130 commits but from difference
52 matches
Mail list logo