Bug after removing a local branch and restore the remote branch during a rebase

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

Re: [PATCH 33/67] read_branches_file: replace strcpy with xstrdup

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

Re: [PATCH 33/67] read_branches_file: replace strcpy with xstrdup

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 --

Re: [PATCH 02/10] run-command: factor out return value computation

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

Shallow submodules update not working?

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

Re: [PATCH 33/67] read_branches_file: replace strcpy with xstrdup

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

git status -u is mildly astonishing

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:

Re: [PATCH v4] gc: save log from daemonized gc --auto and print it next time

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

Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list

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 >>> +

[PATCH v2] strtoul_ui: reject negative values

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

Re: [PATCH 66/67] use strbuf_complete to conditionally append slash

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 >> >>

Re: [PATCH 00/43] refs lmdb backend

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

Re: [PATCH] strtoul_ui: reject negative values

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;

Re: Bug after removing a local branch and restore the remote branch during a rebase

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH] strtoul_ui: reject negative values

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

Re: [PATCH] strtoul_ui: reject negative values

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH 33/67] read_branches_file: replace strcpy with xstrdup

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),

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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.

Re: [PATCH 33/67] read_branches_file: replace strcpy with xstrdup

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) >>

Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list

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 |

[PATCH] l10n: de.po: better language for 2 strings

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 @@

Re: [PATCH] strtoul_ui: reject negative values

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

Re: git rebase -i failing due to phantom index.lock

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

Re: On a personal note

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

Re: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied

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

[PATCH] strtoul_ui: reject negative values

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

Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list

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

Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list

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.

Re: git status -u is mildly astonishing

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

Re: [PATCH v4] gc: save log from daemonized gc --auto and print it next time

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

Re: [PATCH v4] gc: save log from daemonized gc --auto and print it next time

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

Re: [PATCH v2 2/2] dir.c: don't exclude whole dir prematurely if neg pattern may match

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 >> +++

Re: [PATCH 00/10] fetch submodules in parallel and a preview on parallel "submodule update"

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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 >

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH] l10n: de.po: better language for 2 strings

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

Re: Unable to create temporary file '/var/git/tmv3-target-overlay.git/shallow_Un8ZOR': Permission denied

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 > > >

Re: [Feature Request] git blame showing only revisions from git rev-list --first-parent

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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 > >

Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH v4 3/8] branch: roll show_detached HEAD into regular ref_list

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

Re: [PATCH 33/67] read_branches_file: replace strcpy with xstrdup

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH] Makefile: Change library order for static linking

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

Re: [PATCH 06/10] git submodule update: Redirect any output to stderr

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

[PATCH] Makefile: Change library order for static linking

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

Re: [PATCH] Makefile: Change library order for static linking

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

Re: [PATCH 06/10] git submodule update: Redirect any output to stderr

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

Re: [PATCH] Makefile: Change library order for static linking

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

Re: On a personal note

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

Re: [PATCH 09/10] git submodule update: cmd_update_recursive

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

Re: On a personal note

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 >>

Re: [PATCH 07/10] git submodule update: pass --prefix only with a non empty prefix

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

Re: [PATCH 03/10] run-command: add an asynchronous parallel child processor

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 > ---

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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

Re: [PATCH] Makefile: Change library order for static linking

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

Re: [PATCH] Makefile: Change library order for static linking

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

Re: [PATCH v17 14/14] tag.c: implement '--merged' and '--no-merged' options

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

What's cooking in git.git (Sep 2015, #04; Thu, 17)

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

[ANNOUNCE] Git v2.5.3

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 =

Re: git status -u is mildly astonishing

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH 01/10] strbuf: Add strbuf_read_noblock

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

Re: [PATCH 03/10] run-command: add an asynchronous parallel child processor

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

Re: [PATCH 03/10] run-command: add an asynchronous parallel child processor

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

Re: storing cover letter of a patch series?

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