Jeff King writes:
> On Thu, Sep 17, 2015 at 04:27:39PM +0200, Matthieu Moy wrote:
>
>> > Therefore I would argue that -u is behaving differently from other
>> > arguments (especially when considered across all git subcommands)
>>
>> This is because you have options with non-optional argument in
Hi Jacob,
On 11 September 2015 at 02:30, Chris Packham wrote:
> On Fri, Sep 11, 2015 at 4:28 AM, Jacob Keller wrote:
>> Hey,
>>
>> does anyone know of any tricks for storing a cover letter for a patch
>> series inside of git somehow? I'd guess the only obvious way currently
>> is to store it at
Stefan Beller writes:
> On Thu, Sep 17, 2015 at 2:44 PM, Junio C Hamano wrote:
>
>> Hmm, you are relying on the fact that a valid pid can never be 0, so
>> you can just use pp->children[i].child.pid to see if a "slot" is
>> occupied without even using pp->slots[] (or pp->children[i].in_use).
>
>
On Thu, Sep 17, 2015 at 2:44 PM, Junio C Hamano wrote:
> Hmm, you are relying on the fact that a valid pid can never be 0, so
> you can just use pp->children[i].child.pid to see if a "slot" is
> occupied without even using pp->slots[] (or pp->children[i].in_use).
We could either use the pid as a
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
I'll be offline til Monday 21st, when 2.6-rc3 is planned to happen.
You can find the changes described here in the integration branches
of the
The latest maintenance release Git v2.5.3 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.5.3'
tag and the 'maint' branch that the tag points at:
url = https://kernel
John Keeping writes:
>> +--[no-]merged []::
>
> We prefer to write --[no-]* as:
>
> --option::
> --no-option::
>
> although this may be the first instance that we see this combination
> with an argument.
>
> I also found the "[]" syntax confusing and had to go and figure
> out what PA
Remi Pommarel writes:
> On Thu, Sep 17, 2015 at 12:51:18PM -0700, Junio C Hamano wrote:
>> IIRC historically the division between ssl and crypto was messy.
>> Especially, I am not sure if the change to NEEDS_SSL_WITH_CRYPTO
>> in this patch is correct for platforms that require that macro
>> defi
Stefan Beller writes:
> time -->
> output: |---A---| |-B-| |C---| |-D-| |-E-|
Be nice and distribute the line evenly around "C". Same for thread
2 below.
> diff --git a/run-command.c b/run-command.c
> index c892e9a..3af97ab 100644
> --- a/run-command.c
> +++ b/run-command
On Thu, Sep 10, 2015 at 09:52:49PM +0530, Karthik Nayak wrote:
> Use 'ref-filter' APIs to implement the '--merged' and '--no-merged'
> options into 'tag.c'. The '--merged' option lets the user to only list
> tags merged into the named commit. The '--no-merged' option lets the
> user to only list ta
On Thu, Sep 17, 2015 at 12:51:18PM -0700, Junio C Hamano wrote:
> IIRC historically the division between ssl and crypto was messy.
> Especially, I am not sure if the change to NEEDS_SSL_WITH_CRYPTO
> in this patch is correct for platforms that require that macro
> defined.
I think it is correct as
On Wed, Sep 16, 2015 at 9:39 PM, Stefan Beller wrote:
> git submodule update: Redirect any output to stderr
This commit message seems to be lacking an explanation of why this is
being done.
> There are no tests, which fail by this.
Not sure what this means. I suppose you're trying to say that t
On Thu, Sep 17, 2015 at 1:31 PM, Eric Sunshine wrote:
> On Wed, Sep 16, 2015 at 9:39 PM, Stefan Beller wrote:
>> git submodule update: Redirect any output to stderr
>
> This commit message seems to be lacking an explanation of why this is
> being done.
>
>> There are no tests, which fail by this.
On Wed, Sep 16, 2015 at 9:39 PM, Stefan Beller wrote:
> git submodule update: cmd_update_recursive
Commit message doesn't seem to match the patch...
> Signed-off-by: Stefan Beller
> ---
> git-submodule.sh | 31 ---
> 1 file changed, 20 insertions(+), 11 deletions(-)
On Wed, Sep 16, 2015 at 9:39 PM, Stefan Beller wrote:
> We should not pass --prefix NULL into the helper. Although the helper
> can deal with it, it's just messy.
Perhaps the commit message can explain under what conditions $prefix
will be null...
> Signed-off-by: Stefan Beller
> ---
> diff --g
Remi Pommarel writes:
> Subject: Re: [PATCH] Makefile: Change library order for static linking
s/Change/change/;
But more importantly, I think you can do much better with the same
space. Perhaps like this.
Makefile: link libcurl before openssl and crypto
> For static linking especially l
On Thu, Sep 17, 2015 at 03:25:00PM -0400, Eric Sunshine wrote:
> On Thu, Sep 17, 2015 at 5:12 PM, Remi Pommarel wrote:
> > For static linking especially library order while linking is important. For
> > example libssl contains symbol from libcrypto so the farmer should be linked
>
> I hope you me
On Thu, Sep 17, 2015 at 11:54 AM, Johannes Schindelin
wrote:
> Hi Duy,
>
> On 2015-09-17 15:29, Duy Nguyen wrote:
>> On Thu, Sep 3, 2015 at 5:00 PM, Johannes Schindelin
>> wrote:
>>>
>>> yes, it is true: since mid-August I am working for Microsoft. Over a
>>> year ago, I got into contact with the
On Thu, Sep 17, 2015 at 5:12 PM, Remi Pommarel wrote:
> For static linking especially library order while linking is important. For
> example libssl contains symbol from libcrypto so the farmer should be linked
I hope you meant: s/farmer/former/
> before the latter. The global link order should
Hi Duy,
On 2015-09-17 15:29, Duy Nguyen wrote:
> On Thu, Sep 3, 2015 at 5:00 PM, Johannes Schindelin
> wrote:
>>
>> yes, it is true: since mid-August I am working for Microsoft. Over a
>> year ago, I got into contact with the Visual Studio Online group at
>> Microsoft, of which I am now a happy m
For static linking especially library order while linking is important. For
example libssl contains symbol from libcrypto so the farmer should be linked
before the latter. The global link order should be libcurl then libssl then
libcrypto then libintl and finally zlib.
Signed-off-by: Remi Pommarel
On Thu, Sep 17, 2015 at 10:38 PM, Matthieu Moy
wrote:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> But that's still workable: struct ref_sorting could contain a flag
>>> "head_first" that would be set by ref_default_sorting() and only it, and
>>> then read by cmp_ref_sorting.
>>
>>
On Thu, Sep 17, 2015 at 8:50 AM, Phillip Sz wrote:
> just 2 strings I think we could translate better.
>
> Signed-off-by: Phillip Sz
> ---
> po/de.po | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/po/de.po b/po/de.po
> index 6ed3509..2f54093 100644
> --- a/po/de.po
On Thu, Sep 17, 2015 at 10:54:39AM -0700, Junio C Hamano wrote:
> OK. Trying to repurpose strbuf_read() for non-blocking FD was a
> silly idea to begin with, as it wants to read thru to the EOF, and
> setting FD explicitly to O_NONBLOCK is a sign that the caller wants
> to grab as much as possibl
Jeff King writes:
> I actually wonder if callers who are _expecting_ non-blocking want to
> loop in strbuf_read() at all.
>
> strbuf_read() is really about reading to EOF, and growing the buffer to
> fit all of the input. But that's not at all what you want to do with
> non-blocking. There you be
Jeff King writes:
> I think they have to loop for correctness, but they may do this:
>
> if (xread(fd, buf, len) < 0)
> die_errno("OMG, an error!");
>
> which is not correct if "fd" is unknowingly non-blocking.
> ...
> The spinning behavior is not great, but does mean that we spin and
> c
On Thu, Sep 17, 2015 at 10:50 AM, Jeff King wrote:
> On Thu, Sep 17, 2015 at 10:45:40AM -0700, Stefan Beller wrote:
>
>> > You _can_ loop on read until you hit EAGAIN, but I think in general you
>> > shouldn't; if you get a lot of input on this fd, you'll starve all of
>> > the other descriptors y
On Thu, Sep 17, 2015 at 10:45:40AM -0700, Stefan Beller wrote:
> > You _can_ loop on read until you hit EAGAIN, but I think in general you
> > shouldn't; if you get a lot of input on this fd, you'll starve all of
> > the other descriptors you're polling. You're better off to read a
> > finite amo
On Thu, Sep 17, 2015 at 10:35 AM, Jeff King wrote:
>
>
> You _can_ loop on read until you hit EAGAIN, but I think in general you
> shouldn't; if you get a lot of input on this fd, you'll starve all of
> the other descriptors you're polling. You're better off to read a
> finite amount from each d
On Thu, Sep 17, 2015 at 04:27:39PM +0200, Matthieu Moy wrote:
> > Therefore I would argue that -u is behaving differently from other
> > arguments (especially when considered across all git subcommands)
>
> This is because you have options with non-optional argument in mind, or
> options that hav
On Thu, Sep 17, 2015 at 10:26:19AM -0700, Stefan Beller wrote:
> > If we return -1, though, we have a similar annoyance. If the caller
> > notices a -1 return value and finds EAGAIN, they still may need to check
> > sb->len to see if they made forward progress and have data they should
> > be deal
On Thu, Sep 17, 2015 at 10:13 AM, Jeff King wrote:
> On Thu, Sep 17, 2015 at 09:58:00AM -0700, Junio C Hamano wrote:
>
>> > Certainly anybody who does not realize their descriptor is O_NONBLOCK
>> > and is using the spinning for correctness. I tend to think that such
>> > sites are wrong, though,
Matthieu Moy writes:
> ... But we can decide "if sorting on refname, then
> HEAD always comes first anyway".
Sure.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info
On Thu, Sep 17, 2015 at 9:58 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Thu, Sep 17, 2015 at 09:13:40AM -0700, Junio C Hamano wrote:
>>
>>> And your new caller that does O_NONBLOCK wants to do more than
>>> looping upon EWOULDBLOCK. It certainly would not want us to loop
>>> here.
>>>
On Thu, Sep 17, 2015 at 09:58:00AM -0700, Junio C Hamano wrote:
> > Certainly anybody who does not realize their descriptor is O_NONBLOCK
> > and is using the spinning for correctness. I tend to think that such
> > sites are wrong, though, and would benefit from us realizing they are
> > spinning.
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> But that's still workable: struct ref_sorting could contain a flag
>> "head_first" that would be set by ref_default_sorting() and only it, and
>> then read by cmp_ref_sorting.
>
> Hmm, I am still puzzled. "refname" atom would expand to things l
On Wed, Sep 16, 2015 at 6:38 PM, Stefan Beller wrote:
> It took me a while to get the idea how to realize parallelism with the
> parallel run command structure now as opposed to the thread pool I proposed
> earlier, but I think it will be straightforward from here.
>
Yea at least from a cursory r
Jeff King writes:
> On Tue, Sep 15, 2015 at 06:14:26PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > It seems like nobody is actually that interested in what "blame
>> > --first-parent --reverse" does in the first place, though, and there's
>> > no reason for its complexity to hol
On Thu, Sep 17, 2015 at 09:44:19AM -0700, Junio C Hamano wrote:
> > Arguably we should actually return the number of bytes we _did_ read,
> > but then caller cannot easily tell the difference between EOF and
> > EAGAIN.
>
> Why can't it check errno==EAGAIN/EWOULDBLOCK?
Is it trustworthy to check
Jeff King writes:
> On Thu, Sep 17, 2015 at 09:13:40AM -0700, Junio C Hamano wrote:
>
>> And your new caller that does O_NONBLOCK wants to do more than
>> looping upon EWOULDBLOCK. It certainly would not want us to loop
>> here.
>>
>> So I wonder if you can just O_NONBLOCK the fd and use the us
On Thu, 2015-09-17 at 20:18 +0700, Duy Nguyen wrote:
> On Mon, Sep 14, 2015 at 10:37 PM, Joakim Tjernlund
> wrote:
> > On Mon, 2015-08-31 at 16:56 +0700, Duy Nguyen wrote:
> > > On Fri, Aug 21, 2015 at 6:36 PM, Joakim Tjernlund
> > > wrote:
> > > > I cannot push:
> > > > # > git push origin
> > >
Jeff King writes:
> Yeah, that was my thinking. Since I _did_ end up doing the cleanup and
> posted it earlier, please feel free to review and express an opinion on
> the original versus the cleanup.
>
> I'm on the fence. I do think the cleaned-up version is much nicer, but
> I always worry abou
On Thu, Sep 17, 2015 at 9:44 AM, Junio C Hamano wrote:
> On Thu, Sep 17, 2015 at 9:30 AM, Jeff King wrote:
>>
>> So I think we would probably want to treat EAGAIN specially: return -1
>> to signal to the caller but _don't_ truncate the strbuf.
>
> Yeah, "don't truncate" is needed.
>
>> Arguably w
Matthieu Moy writes:
> But that's still workable: struct ref_sorting could contain a flag
> "head_first" that would be set by ref_default_sorting() and only it, and
> then read by cmp_ref_sorting.
Hmm, I am still puzzled. "refname" atom would expand to things like
"HEAD", "refs/heads/master", e
On Thu, Sep 17, 2015 at 9:30 AM, Jeff King wrote:
>
> So I think we would probably want to treat EAGAIN specially: return -1
> to signal to the caller but _don't_ truncate the strbuf.
Yeah, "don't truncate" is needed.
> Arguably we should actually return the number of bytes we _did_ read,
> but
Hi,
On Thu, Sep 17, 2015 at 3:12 AM, Robert Strobl
wrote:
> It might be an unusual workflow, however it leads to a bug:
>
> git checkout feature_branch
> git rebase master
>
Ok so you are performing the rebase...
> # a couple of conflicts occur, which I don’t want to fix. there is an updated
>
David Turner writes:
> On Fri, 2015-09-04 at 12:01 -0400, David Turner wrote:
>> On Thu, 2015-09-03 at 16:10 -0700, Junio C Hamano wrote:
>> >
>> > [03/43] seems to be missing
>>
>> I just attempted to re-send it, but I still don't see it on gmane.
>> Perhaps this is because it is greater than
On Thu, Sep 17, 2015 at 09:13:40AM -0700, Junio C Hamano wrote:
> And your new caller that does O_NONBLOCK wants to do more than
> looping upon EWOULDBLOCK. It certainly would not want us to loop
> here.
>
> So I wonder if you can just O_NONBLOCK the fd and use the usual
> strbuf_read(), i.e. wi
strtoul_ui uses strtoul to get a long unsigned, then checks that casting
to unsigned does not lose information and return the casted value.
On 64 bits architecture, checking that the cast does not change the value
catches most errors, but when sizeof(int) == sizeof(long) (e.g. i386),
the check doe
On Thu, Sep 17, 2015 at 08:38:32AM -0700, Junio C Hamano wrote:
> > In some of the cases, as you've seen, I dug further in cleaning things
> > up. But in others I did the minimal fix (especially in this case, the
> > limitations are only about the deprecated "branches" and "remotes"
> > file), mos
Matthieu Moy writes:
> This patch catches negative values before it's too late, i.e. before
> calling strtoul. We still silently accept very large integers that wrap
> to a valid "unsigned int".
Is the last statement correct? A very large long uint that wrap to
uint would not fit in long uint a
Stefan Beller writes:
> Subject: Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock
s/Add/add/;
> We need to read from pipes without blocking in a later patch.
I am hoping that you are at least not spinning---i.e. do a poll
first to make sure there is at least some progress to be made
before c
On 15-09-17 11:34 AM, Matthieu Moy wrote:
> Marc Branchaud writes:
>
>>> --- a/git-compat-util.h
>>> +++ b/git-compat-util.h
>>> @@ -814,6 +814,9 @@ static inline int strtoul_ui(char const *s, int base,
>>> unsigned int *result)
>>> char *p;
>>>
>>> errno = 0;
>>> + /* negative value
just 2 strings I think we could translate better.
Signed-off-by: Phillip Sz
---
po/de.po | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/po/de.po b/po/de.po
index 6ed3509..2f54093 100644
--- a/po/de.po
+++ b/po/de.po
@@ -10785,7 +10785,7 @@ msgid ""
"it will be removed.
Jeff King writes:
> On Wed, Sep 16, 2015 at 03:54:50PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> >> Is this conversion correct? This seems to me that the caller wants
>> >> to create an IMAP folder name immediately under the root hierarchy
>> >> and wants to have the leading sl
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Karthik Nayak writes:
>>
>>> So either we could introduce a new atom for sorting something like
>>> `branch_sort` which uses the FILTER_REFS_(DETACHED_HEAD | BRANCHES |
>>> REMOTES)
>>
>> I don't think you need a new atom. You can just change t
Jeff King writes:
> On Wed, Sep 16, 2015 at 12:52:26PM -0700, Junio C Hamano wrote:
>
>> > diff --git a/remote.c b/remote.c
>> > index 5ab0f7f..1b69751 100644
>> > --- a/remote.c
>> > +++ b/remote.c
>> > @@ -297,7 +297,6 @@ static void read_branches_file(struct remote *remote)
>> >int n = 100
Marc Branchaud writes:
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -814,6 +814,9 @@ static inline int strtoul_ui(char const *s, int base,
>> unsigned int *result)
>> char *p;
>>
>> errno = 0;
>> +/* negative values would be accepted by strtoul */
>> +if (strch
On 15-09-17 10:37 AM, Matthieu Moy wrote:
> strtoul_ui uses strtoul to get a long unsigned, then checks that casting
> to unsigned does not lose information and return the casted value.
>
> On 64 bits architecture, checking that the cast does not change the value
> catches most errors, but when si
Matthieu Moy writes:
> Karthik Nayak writes:
>
>> So either we could introduce a new atom for sorting something like
>> `branch_sort` which uses the FILTER_REFS_(DETACHED_HEAD | BRANCHES |
>> REMOTES)
>
> I don't think you need a new atom. You can just change the sorting
> function to consider t
Duy Nguyen writes:
> We do keep another lock before coming to opening this log file. So
> once we get here we already know nobody else will be opening the log
> file. We can simply open it the normal way, then make sure we clean it
> up at atexit().
>
>>> This doesn't seem like a common thing to
strtoul_ui uses strtoul to get a long unsigned, then checks that casting
to unsigned does not lose information and return the casted value.
On 64 bits architecture, checking that the cast does not change the value
catches most errors, but when sizeof(int) == sizeof(long) (e.g. i386),
the check doe
Alastair McGowan-Douglas writes:
> It seemed that the argument to -u was being ignored. It turns out that
> 'no' was not actually being considered an argument to -u in the first
> place.
-u takes an optional argument. We can't consider the command-line
argument following u as its argument, becau
Karthik Nayak writes:
> So either we could introduce a new atom for sorting something like
> `branch_sort` which uses the FILTER_REFS_(DETACHED_HEAD | BRANCHES |
> REMOTES)
I don't think you need a new atom. You can just change the sorting
function to consider that detached HEAD is always first,
On Thu, Sep 3, 2015 at 5:00 PM, Johannes Schindelin
wrote:
> Hey all,
>
> yes, it is true: since mid-August I am working for Microsoft. Over a
> year ago, I got into contact with the Visual Studio Online group at
> Microsoft, of which I am now a happy member. A large part of my mission
> is to imp
On Tue, Sep 15, 2015 at 12:15 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
>> index 473623d..889a72a 100644
>> --- a/Documentation/gitignore.txt
>> +++ b/Documentation/gitignore.txt
>> @@ -82,12 +82,9 @@ PATT
On Mon, Sep 14, 2015 at 10:37 PM, Joakim Tjernlund
wrote:
> On Mon, 2015-08-31 at 16:56 +0700, Duy Nguyen wrote:
>> On Fri, Aug 21, 2015 at 6:36 PM, Joakim Tjernlund
>> wrote:
>> > I cannot push:
>> > # > git push origin
>> > Login for jo...@git.transmode.se
>> > Password:
>> > Counting objects:
On Wed, Sep 16, 2015 at 11:00 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I'm not sure what behavior you want. At one point you say "puts the file
>> to a final place if it is non-empty" but later you say "leave it if
>> non-empty". Should the file be written directly, or should it
On Thu, Sep 17, 2015 at 3:08 AM, Giuseppe Bilotta
wrote:
> Hello all,
>
> I've recently started to note an issue with git rebase -i failing with
> alarming frequency, especially on one of my repositories, claiming
> that index.lock could not be created because it exists, even though it
> doesn't a
On Thu, Sep 17, 2015 at 07:28:56AM -0400, Jeff King wrote:
> Here is the patch I ended up with:
>
> -- >8 --
> Subject: [PATCH] read_branches_file: simplify string handling
And here is the matching cleanup for read_remotes_file, which
lets us drop the static global "buffer" entirely.
-- >8 --
S
On Thu, Sep 17, 2015 at 07:28:56AM -0400, Jeff King wrote:
> /*
>* The branches file would have URL and optionally
>* #branch specified. The "master" (or specified) branch is
> - * fetched and stored in the local branch of the same name.
> + * fetched and stored in
On Wed, Sep 16, 2015 at 04:42:26PM -0400, Jeff King wrote:
> > We use buffer[BUFSIZ] to read various things in this file, not just
> > $GIT_DIR/branches/* files, with fgets(), which may be better done if
> > we switched to strbuf_getline(). Then we can also use trim family
> > of calls from the s
Using git version 2.3.8 (Apple Git-58), when I try to clone a repository with
submodules using option --depth 1, I get two different behaviors for two
different commands:
# 1 - using git clone --recursive directly (OK)
# repository last ref is cloned as well as its submodules
$ git submodule clo
On Wed, Sep 16, 2015 at 06:39:00PM -0700, Stefan Beller wrote:
> +static int determine_return_value(int wait_status,
> + int *result,
> + int *error_code,
> + const char *argv0)
> +{
> + if (WIFSIGNALED(w
Hi list,
Today I found what I thought was a bug in git status:
https://paste.fedoraproject.org/268333/42480833/
It seemed that the argument to -u was being ignored. It turns out that
'no' was not actually being considered an argument to -u in the first
place.
The documentation supports this:
It might be an unusual workflow, however it leads to a bug:
git checkout feature_branch
git rebase master
# a couple of conflicts occur, which I don’t want to fix. there is an updated
version on origin
# so I’d like to go with that one
git add .
git stash
git checkout master
git branch -D featu
On Wed, Sep 16, 2015 at 11:53 AM, Karthik Nayak wrote:
> On Tue, Sep 15, 2015 at 1:05 AM, Junio C Hamano wrote:
>> Karthik Nayak writes:
>>
>>> + /*
>>> + * First we obtain all regular branch refs and if the HEAD is
>>> + * detached then we insert that ref to the end of the ref_fis
On 09/16/2015 06:00 PM, Junio C Hamano wrote:
> *1* But one "gc" could be foreground gc that does not write to a log
> file and the other "gc" could be background that does write to a
> log file, so this cannot be the primary way to avoid double
> execution.
^^^ This was the point that
78 matches
Mail list logo
