Re: [RFC/PATCH 2/3] wildmatch: add interface for precompiling wildmatch() patterns

Ævar Arnfjörð Bjarmason writes: > +struct wildmatch_compiled *wildmatch_compile(const char *pattern, unsigned > int flags) > +{ > + struct wildmatch_compiled *code = xmalloc(sizeof(struct > wildmatch_compiled)); > + code->pattern = xstrdup(pattern); > +

Re: [PATCH v2 00/29] Create a reference backend for packed refs

On Fri, Jun 23, 2017 at 02:47:01PM -0700, Junio C Hamano wrote: > > Speculating on my own question. I guess it would prepare us for a day > > when a possible ref store is to use a packed-refs _without_ loose refs. > > IOW, the property is defined on packed-refs today, but a possible future > >

Re: --color-moved feedback, was Re: [PATCH v2 19/29] packed-backend: new module for handling packed references

On Fri, Jun 23, 2017 at 01:23:52PM -0700, Stefan Beller wrote: > > In the end, I just did --color-moved=plain, ... > > "yep, this is all a giant moved chunk, so I don't have to look carefully > > at it". > > This is dangerous, as "plain" does not care about permutations. > See the 7f5af90798

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

Junio C Hamano writes: > But for the purpose of this "moved line coloring", > excluding multiple copy destinations of the same thing may be a > simpler and more robust solution. It will not catch "somebody > stupidly removed one function and made two private copies", though.

Re: [PATCH 2/3] builtin/fetch: parse recurse-submodules-default at default options parsing

Stefan Beller writes: >>> if (recurse_submodules != RECURSE_SUBMODULES_OFF) { >>> - if (recurse_submodules_default) { >>> - int arg = >>> parse_fetch_recurse_submodules_arg("--recurse-submodules-default", >>>

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

Stefan Beller writes: > * add some heuristic to omit small blobs, (empty lines, closing braces) > Maybe this is can be solved by not considering anything > that occurs multiple times? I vaguely recall that we had to do something similar in "blame -C" where it tries to

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

Ævar Arnfjörð Bjarmason writes: > This is bad: > > $ ./git --exec-path=$PWD -c diff.colorMoved=crap show > fatal: unable to parse 'diff.colormoved' from command-line config > > Fixed with: > > diff --git a/diff.c b/diff.c > index 7cae4f1ddb..036dbc1c3c 100644 >

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

Junio C Hamano writes: >>> * ab/sha1dc (2017-06-07) 2 commits >>> ... >>> Will keep in 'pu'. >>> Impact to the various build and release infrastructure of using >>> submodule is not yet fully known, but this lets us dip our toes. >> ... >> But it's been 1 month kicking

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

> This is good: > > $ ./git --exec-path=$PWD show --color-moved=crap > fatal: bad --color-moved argument: crap > > This is bad: > > $ ./git --exec-path=$PWD -c diff.colorMoved=crap show > fatal: unable to parse 'diff.colormoved' from command-line config > > Fixed with: > > diff

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

On Fri, Jun 23, 2017 at 2:59 PM, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Jun 22 2017, Junio C. Hamano jotted: > >> * sb/diff-color-move (2017-06-21) 25 commits >> - diff: document the new --color-moved setting >> - diff.c: add dimming to moved line detection >> - diff.c:

Re: [PATCH] xdiff: trim common tail with -U0 after diff

On 23.06.2017 22:39, René Scharfe wrote: > The changed test script passes just fine for me even without your change > to xdiff-interface.c, which is odd. Sorry, I've apparently messed this up - it seems to be the case for me, too. I would assume that using the functions.c context/diff in this

Re: [PATCH] submodule--helper: teach push-check to handle HEAD

Brandon Williams writes: > In 06bf4ad1d (push: propagate remote and refspec with > --recurse-submodules) push was taught how to propagate a refspec down to > submodules when the '--recurse-submodules' flag is given. The only refspecs > that are allowed to be propagated are

Re: [PATCH 2/3] builtin/fetch: parse recurse-submodules-default at default options parsing

On Fri, Jun 23, 2017 at 3:36 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> @@ -1333,10 +1336,8 @@ int cmd_fetch(int argc, const char **argv, const char >> *prefix) >> deepen = 1; >> >> if (recurse_submodules !=

Re: [PATCH 2/3] builtin/fetch: parse recurse-submodules-default at default options parsing

Stefan Beller writes: > @@ -1333,10 +1336,8 @@ int cmd_fetch(int argc, const char **argv, const char > *prefix) > deepen = 1; > > if (recurse_submodules != RECURSE_SUBMODULES_OFF) { > - if (recurse_submodules_default) { > -

Re: [PATCH 1/3] builtin/fetch: factor submodule recurse parsing out to submodule config

Stefan Beller writes: > Later we want to access this parsing in builtin/pull as well. > > Signed-off-by: Stefan Beller > --- > builtin/fetch.c| 18 ++ > submodule-config.c | 22 ++ > submodule-config.h | 3 +++ >

Re: [PATCH v2 3/3] t1700: make sure split-index respects core.sharedrepository

Christian Couder writes: > Add a few tests to check that both the split-index file and the > shared-index file are created using the right permissions when > core.sharedrepository is set. > > Signed-off-by: Christian Couder > --- >

Re: [PATCH v2 1/3] read-cache: use shared perms when writing shared index

Christian Couder writes: > Since f6ecc62dbf (write_shared_index(): use tempfile module, 2015-08-10) > write_shared_index() has been using mks_tempfile() to create the > temporary file that will become the shared index. > > But even before that, it looks like the

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

On Thu, Jun 22 2017, Junio C. Hamano jotted: > * sb/diff-color-move (2017-06-21) 25 commits > - diff: document the new --color-moved setting > - diff.c: add dimming to moved line detection > - diff.c: color moved lines differently, plain mode > - diff.c: color moved lines differently > -

Re: [PATCH v2 1/3] read-cache: use shared perms when writing shared index

Christian Couder writes: > Since f6ecc62dbf (write_shared_index(): use tempfile module, 2015-08-10) > write_shared_index() has been using mks_tempfile() to create the > temporary file that will become the shared index. > > But even before that, it looks like the

Re: [PATCH v2 00/29] Create a reference backend for packed refs

Jeff King writes: > On Fri, Jun 23, 2017 at 03:01:59PM -0400, Jeff King wrote: > >> On Fri, Jun 23, 2017 at 09:01:18AM +0200, Michael Haggerty wrote: >> >> > * Change patch 17 "packed_ref_store: support iteration" to always >> > iterate over the packed refs using

Re: [showing-off RFC/PATCH 26/26] diff.c: have a "machine parseable" move coloring

On Tue, Jun 20 2017, Stefan Beller jotted: > + Ævar, who was not part of the email where I copied all recipients > from for this series. I played around with this a bit, it would be great to have something like this on top of --color-moved eventually. It's a lot easier to /^_ in a pager than

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

On Fri, Jun 23, 2017 at 1:54 PM, Junio C Hamano wrote: > Jacob Keller writes: > >> Instead, lets add support for a new refs/tracking/* hierarchy which is >> laid out in such a way to avoid this inconsistency. All refs in >> "refs/tracking//*" will

Re: [PATCH v2 19/29] packed-backend: new module for handling packed references

Jeff King writes: > On Fri, Jun 23, 2017 at 09:01:37AM +0200, Michael Haggerty wrote: > >> Now that the interface between `files_ref_store` and >> `packed_ref_store` is relatively narrow, move the latter into a new >> module, "refs/packed-backend.h" and "refs/packed-backend.c". It

Re: [PATCH] pathspec: die on empty strings as pathspec

Torsten Bögershausen writes: > On 23/06/17 20:04, Junio C Hamano wrote: >... >> At this point in the test sequence, there is no modified path that >> need to be further added before committing; the working tree is >> empty except for .gitattributes which was just added to the

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

Jacob Keller writes: > Instead, lets add support for a new refs/tracking/* hierarchy which is > laid out in such a way to avoid this inconsistency. All refs in > "refs/tracking//*" will include the complete ref, such that > dropping the "tracking/" part will give the

Re: [PATCH] pathspec: die on empty strings as pathspec

On 23/06/17 20:04, Junio C Hamano wrote: Junio C Hamano writes: Sorry for my mess, see below I am not sure if we even want the dot there, but at least that is what the original author of the test intended to do when s/he decided to pass an empty string as the pathspec.

Re: [PATCH] xdiff: trim common tail with -U0 after diff

Am 23.06.2017 um 12:36 schrieb Daniel Hahler: When -U0 is used, trim_common_tail should be called after `xdl_diff`, so that `--indent-heuristic` (and other diff processing) works as expected. It also removes the check for `!(xecfg->flags & XDL_EMIT_FUNCCONTEXT)` added in e0876bca4, which does

Re: [PATCH] submodule--helper: teach push-check to handle HEAD

On Fri, Jun 23, 2017 at 1:04 PM, Brandon Williams wrote: > In 06bf4ad1d (push: propagate remote and refspec with > --recurse-submodules) push was taught how to propagate a refspec down to > submodules when the '--recurse-submodules' flag is given. The only refspecs > that are

Re: [PATCH v2 00/29] Create a reference backend for packed refs

Jeff King writes: > On Fri, Jun 23, 2017 at 09:01:18AM +0200, Michael Haggerty wrote: > >> * Change patch 17 "packed_ref_store: support iteration" to always >> iterate over the packed refs using `DO_FOR_EACH_INCLUDE_BROKEN`. >> This switches off the check in the packed-ref

Re: --color-moved feedback, was Re: [PATCH v2 19/29] packed-backend: new module for handling packed references

On Fri, Jun 23, 2017 at 1:10 PM, Jeff King wrote: > [I culled the cc list, as it was big and they don't all necessarily care > about this feature] Yeah I was on the verge to do that, but did not pull through. > > In the end, I just did --color-moved=plain, ... > "yep, this is

Re: [PATCH v2 01/29] t1408: add a test of stale packed refs covered by loose refs

Jeff King writes: > On Fri, Jun 23, 2017 at 09:01:19AM +0200, Michael Haggerty wrote: > >> +test_expect_success setup ' >> +test_tick && >> +git commit --allow-empty -m one && >> +one=$(git rev-parse HEAD) && >> +git for-each-ref >actual && >> +echo "$one

Re: [PATCHv2 04/25] diff.c: introduce emit_diff_symbol

On Fri, Jun 23, 2017 at 1:07 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> diff --git a/new.txt b/new.txt >> index fa69b07..412428c 100644 >> Binary files a/new.txt and b/new.txt differ >> >> could be buffered as >>

--color-moved feedback, was Re: [PATCH v2 19/29] packed-backend: new module for handling packed references

[I culled the cc list, as it was big and they don't all necessarily care about this feature] On Fri, Jun 23, 2017 at 12:46:47PM -0700, Stefan Beller wrote: > > Looks good. Stefan will be happy to know that I used --color-moved to > > look at it. ;) > > Hah! > > As a follow up on that, let's

Re: [PATCHv2 04/25] diff.c: introduce emit_diff_symbol

Stefan Beller writes: > diff --git a/new.txt b/new.txt > index fa69b07..412428c 100644 > Binary files a/new.txt and b/new.txt differ > > could be buffered as > DIFF_SYMBOL_DIFF_START + new.txt > DIFF_SYMBOL_INDEX_MODE + fa69b07 412428c "non-executable"

[PATCH] submodule--helper: teach push-check to handle HEAD

In 06bf4ad1d (push: propagate remote and refspec with --recurse-submodules) push was taught how to propagate a refspec down to submodules when the '--recurse-submodules' flag is given. The only refspecs that are allowed to be propagated are ones which name a ref which exists in both the

Re: [PATCH v2 00/29] Create a reference backend for packed refs

On Fri, Jun 23, 2017 at 03:01:59PM -0400, Jeff King wrote: > On Fri, Jun 23, 2017 at 09:01:18AM +0200, Michael Haggerty wrote: > > > * Change patch 17 "packed_ref_store: support iteration" to always > > iterate over the packed refs using `DO_FOR_EACH_INCLUDE_BROKEN`. > > This switches off

Re: [PATCH v2 29/29] read_packed_refs(): die if `packed-refs` contains bogus data

On Fri, Jun 23, 2017 at 09:01:47AM +0200, Michael Haggerty wrote: > The old code ignored any lines that it didn't understand. This is > dangerous. Instead, `die()` if the `packed-refs` file contains any > lines that we don't know how to handle. This seems like a big improvement. Is it worth

Re: [PATCH v2 28/29] repack_without_refs(): don't lock or unlock the packed refs

On Fri, Jun 23, 2017 at 09:01:46AM +0200, Michael Haggerty wrote: > Change `repack_without_refs()` to expect the packed-refs lock to be > held already, and not to release the lock before returning. Change the > callers to deal with lock management. > > This change makes it possible for callers

Re: [PATCH v2 27/29] commit_packed_refs(): remove call to `packed_refs_unlock()`

On Fri, Jun 23, 2017 at 09:01:45AM +0200, Michael Haggerty wrote: > Instead, change the callers of `commit_packed_refs()` to call > `packed_refs_unlock()`. Why? I can guess that the reason is probably "because we're going to add a new caller that doesn't want to do that", but it's nice to hear

Re: [RFC/PATCH v4 09/49] Add initial external odb support

On 6/20/2017 3:54 AM, Christian Couder wrote: From: Jeff King Signed-off-by: Christian Couder I'd suggest you make the function names consistent with the capabilities flags (ie get, put, have) both here in odb_helper.c/h and in external_odb.c/h.

Re: [PATCH v2 26/29] clear_packed_ref_cache(): don't protest if the lock is held

On Fri, Jun 23, 2017 at 09:01:44AM +0200, Michael Haggerty wrote: > The existing callers already check that the lock isn't held just > before calling `clear_packed_ref_cache()`, and in the near future we > want to be able to call this function when the lock is held. OK. It's not immediately

Re: [PATCH v2 19/29] packed-backend: new module for handling packed references

On Fri, Jun 23, 2017 at 12:35 PM, Jeff King wrote: > On Fri, Jun 23, 2017 at 09:01:37AM +0200, Michael Haggerty wrote: > >> Now that the interface between `files_ref_store` and >> `packed_ref_store` is relatively narrow, move the latter into a new >> module, "refs/packed-backend.h"

Re: [PATCH v2 22/29] commit_packed_refs(): use a staging file separate from the lockfile

On Fri, Jun 23, 2017 at 09:01:40AM +0200, Michael Haggerty wrote: > @@ -522,10 +529,16 @@ int lock_packed_refs(struct ref_store *ref_store, int > flags) > timeout_configured = 1; > } > > + /* > + * Note that we close the lockfile immediately because we > + *

Re: [PATCH] xdiff: trim common tail with -U0 after diff

Stefan Beller writes: > So I tried finding out more about this hack, > and found the patch that introduced the common tail trimming at > https://public-inbox.org/git/7vmysez0oa@gitster.siamese.dyndns.org/ > 913b45f51b (xdi_diff: trim common trailing lines, 2007-12-13)

Re: [PATCH v2 20/29] packed_ref_store: make class into a subclass of `ref_store`

On Fri, Jun 23, 2017 at 09:01:38AM +0200, Michael Haggerty wrote: > Add the infrastructure to make `packed_ref_store` implement > `ref_store`, at least formally (few of the methods are actually > implemented yet). Change the functions in its interface to take > `ref_store *` arguments. Change

Re: [PATCH] xdiff: trim common tail with -U0 after diff

On Fri, Jun 23, 2017 at 12:13 PM, Junio C Hamano wrote: > Daniel Hahler writes: > >> When -U0 is used, trim_common_tail should be called after `xdl_diff`, so >> that `--indent-heuristic` (and other diff processing) works as expected. > > I thought common-tail

Re: [PATCH v2 19/29] packed-backend: new module for handling packed references

On Fri, Jun 23, 2017 at 09:01:37AM +0200, Michael Haggerty wrote: > Now that the interface between `files_ref_store` and > `packed_ref_store` is relatively narrow, move the latter into a new > module, "refs/packed-backend.h" and "refs/packed-backend.c". It still > doesn't quite implement the

Re: [PATCH] xdiff: trim common tail with -U0 after diff

Daniel Hahler writes: > When -U0 is used, trim_common_tail should be called after `xdl_diff`, so > that `--indent-heuristic` (and other diff processing) works as expected. I thought common-tail trimming was a hack/optimization to avoid having to pass the whole thing to have

[PATCH 2/3] builtin/fetch: parse recurse-submodules-default at default options parsing

Instead of just storing the string and then later calling our own parsing function 'parse_fetch_recurse_submodules_arg', make use of the function callback 'option_fetch_parse_recurse_submodules' that was introduced in the last patch. Also move all submodule recursing variables in one spot at the

[PATCH 3/3] pull: optionally rebase submodules (remote submodule changes only)

Teach pull to optionally update submodules when '--recurse-submodules' is provided. This will teach pull to run 'submodule update --rebase' when the '--recurse-submodules' and '--rebase' flags are given under specific circumstances. On a rebase workflow: = 1. Both sides

[PATCH 1/3] builtin/fetch: factor submodule recurse parsing out to submodule config

Later we want to access this parsing in builtin/pull as well. Signed-off-by: Stefan Beller --- builtin/fetch.c| 18 ++ submodule-config.c | 22 ++ submodule-config.h | 3 +++ 3 files changed, 27 insertions(+), 16 deletions(-) diff

[PATCH 0/3] pull: optionally rebase submodules

This supersedes the RFC in May by Brandon https://public-inbox.org/git/20170511172437.96878-1-bmw...@google.com/ It adds more (enough?) error checking, as explained in the last commit message. Documentation and issues raised in the review of that RFC have been addressed. The first two patches

Re: [PATCH v2 17/29] packed_ref_store: support iteration

On Fri, Jun 23, 2017 at 09:01:35AM +0200, Michael Haggerty wrote: > +static int packed_ref_iterator_advance(struct ref_iterator *ref_iterator) > +{ > + struct packed_ref_iterator *iter = > + (struct packed_ref_iterator *)ref_iterator; I thought had some kind of safe downcasting

Re: [PATCH v2 00/29] Create a reference backend for packed refs

On Fri, Jun 23, 2017 at 09:01:18AM +0200, Michael Haggerty wrote: > * Change patch 17 "packed_ref_store: support iteration" to always > iterate over the packed refs using `DO_FOR_EACH_INCLUDE_BROKEN`. > This switches off the check in the packed-ref iterator of whether a > reference is

Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes

Junio C Hamano writes: > For 3420, I can wrap the two-liner patch I showed here earlier into > a commit on top of the series. So, here is what I'll queue on top before merging the topic down to 'master'. -- >8 -- Subject: [PATCH] t3420: fix under GETTEXT_POISON build

Re: [PATCH v2 01/29] t1408: add a test of stale packed refs covered by loose refs

On Fri, Jun 23, 2017 at 09:01:19AM +0200, Michael Haggerty wrote: > +test_expect_success setup ' > + test_tick && > + git commit --allow-empty -m one && > + one=$(git rev-parse HEAD) && > + git for-each-ref >actual && > + echo "$one commit refs/heads/master" >expect && >

Re: [RFC/PATCH v4 07/49] Git/Packet.pm: add packet_initialize()

I like where this ends but it seems to me that patches 6, 7 and 8 should just get merged into patch 4 and 5. On 6/20/2017 3:54 AM, Christian Couder wrote: Add a function to initialize the communication. And use this function in 't/t0021/rot13-filter.pl'. Signed-off-by: Christian Couder

Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes

Junio C Hamano writes: > 3404 needs a similar fix-up for the series to be able to stand on > its own. Alternatively, at least we need to understand what in 'pu' > makes the result of the merge pass---the symptom indicates that this > topic cannot be merged to a released

Re: your mail

Jeff King writes: > On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote: > >> Otoh, "community" page does not encourage subscription as a way to >> ensure you'll see follow-up discussion, which may be a good thing to >> add. >> >> A tangent I just found funny is this

Re: [RFC/PATCH v4 00/49] Add initial experimental external ODB support

On 6/20/2017 3:54 AM, Christian Couder wrote: Goal Git can store its objects only in the form of loose objects in separate files or packed objects in a pack file. To be able to better handle some kind of objects, for example big blobs, it would be nice if Git could store its objects in

Re: [PATCH] pathspec: die on empty strings as pathspec

Junio C Hamano writes: > I am not sure if we even want the dot there, but at least that is > what the original author of the test intended to do when s/he > decided to pass an empty string as the pathspec. > > t/t0027-auto-crlf.sh | 2 +- > 1 file changed, 1 insertion(+), 1

Re: [PATCH v4 00/20] repository object

Jeff Hostetler writes: > On 6/22/2017 2:43 PM, Brandon Williams wrote: >> As before you can find this series at: >> https://github.com/bmwill/git/tree/repository-object >> >> Changes in v4: >> >> * Patch 11 is slightly different and turns off all path relocation when a >>

Re: [PATCH 1/3] list-objects: add filter_blob to traverse_commit_list

On 6/22/2017 6:10 PM, Jonathan Tan wrote: On Thu, 22 Jun 2017 14:45:26 -0700 Jonathan Tan wrote: On Thu, 22 Jun 2017 20:36:13 + Jeff Hostetler wrote: From: Jeff Hostetler In preparation for partial/sparse

Re: [PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

Jeff King writes: > The idea was that eventually the caller might be able to come up with a > TZ that is not blank, but is also not what strftime("%Z") would produce. > Conceivably that could be done if Git commits carried the "%Z" > information (not likely), or if we used a

Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes

Phillip Wood writes: > t3404 passes for me, > $ make GETTEXT_POISON=YesPlease > $ cd t & t3404-rebase-interactive.sh -i -v > ... > # still have 1 known breakage(s) > # passed all remaining 95 test(s) > 1..96 Interesting. The tip of 'pu', which includes this series,

Re: your mail

On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote: > Otoh, "community" page does not encourage subscription as a way to > ensure you'll see follow-up discussion, which may be a good thing to > add. > > A tangent I just found funny is this paragraph on the "community" > page: > >

Re: [PATCH v4 00/20] repository object

On 6/22/2017 2:43 PM, Brandon Williams wrote: As before you can find this series at: https://github.com/bmwill/git/tree/repository-object Changes in v4: * Patch 11 is slightly different and turns off all path relocation when a worktree is provided instead of just for the index file

Re: [PATCH -v2] strbuf: change an always NULL/"" strbuf_addftime() param to bool

On Fri, Jun 23, 2017 at 04:36:06PM +, Ævar Arnfjörð Bjarmason wrote: > I believe this addresses the comments in the thread so far. Also Re: > René's "why const?" in a2673ce4-5cf8-6b40-d4db-8e2a49518...@web.de: > Because tzname_from_tz isn't changed in the body of the function, only > read.

Re: [PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

On Fri, Jun 23, 2017 at 06:23:10PM +0200, René Scharfe wrote: > > > I have a WIP patch (which may not make it on-list, depending) playing > > > with the idea I proposed in > > > CACBZZX5OQc45fUyDVayE89rkT=+8m5s4efsxcabcy7upme5...@mail.gmail.com which > > > just inserts the custom TZ name based on

[PATCH -v2] strbuf: change an always NULL/"" strbuf_addftime() param to bool

Change the code for deciding what's to be done about %Z to stop passing always either a NULL or "" char * to strbuf_addftime(). Instead pass a boolean int to indicate whether the strftime() %Z format should be expanded to an empty string, which is what this code is actually doing. This code grew

Re: [PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

Am 23.06.2017 um 17:23 schrieb Jeff King: On Fri, Jun 23, 2017 at 05:13:38PM +0200, Ævar Arnfjörð Bjarmason wrote: The idea was that eventually the caller might be able to come up with a TZ that is not blank, but is also not what strftime("%Z") would produce. Conceivably that could be done if

Re: [PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

Am 23.06.2017 um 17:25 schrieb Jeff King: On Fri, Jun 23, 2017 at 05:20:19PM +0200, René Scharfe wrote: diff --git a/strbuf.c b/strbuf.c index be3b9e37b1..81ff3570e2 100644 --- a/strbuf.c +++ b/strbuf.c @@ -786,7 +786,7 @@ char *xstrfmt(const char *fmt, ...) } void strbuf_addftime(struct

Re: [PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

On Fri, Jun 23, 2017 at 05:20:19PM +0200, René Scharfe wrote: > > diff --git a/strbuf.c b/strbuf.c > > index be3b9e37b1..81ff3570e2 100644 > > --- a/strbuf.c > > +++ b/strbuf.c > > @@ -786,7 +786,7 @@ char *xstrfmt(const char *fmt, ...) > > } > > void strbuf_addftime(struct strbuf *sb, const

Re: [PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

On Fri, Jun 23, 2017 at 05:13:38PM +0200, Ævar Arnfjörð Bjarmason wrote: > > The idea was that eventually the caller might be able to come up with a > > TZ that is not blank, but is also not what strftime("%Z") would produce. > > Conceivably that could be done if Git commits carried the "%Z" > >

Re: [PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

Am 23.06.2017 um 16:46 schrieb Ævar Arnfjörð Bjarmason: Change the code for deciding what's to be done about %Z to stop passing always either a NULL or "" char * to strbuf_addftime(). Instead pass a boolean int to indicate whether the strftime() %Z format should be omitted, which is what this

[PATCH v2 2/3] t1301: move modebits() to test-lib-functions.sh

As the modebits() function can be useful outside t1301, let's move it into test-lib-functions.sh, and while at it let's rename it test_modebits(). Signed-off-by: Christian Couder --- t/t1301-shared-repo.sh | 18 +++--- t/test-lib-functions.sh | 5 + 2

[PATCH v2 3/3] t1700: make sure split-index respects core.sharedrepository

Add a few tests to check that both the split-index file and the shared-index file are created using the right permissions when core.sharedrepository is set. Signed-off-by: Christian Couder --- t/t1700-split-index.sh | 17 + 1 file changed, 17

[PATCH v2 1/3] read-cache: use shared perms when writing shared index

Since f6ecc62dbf (write_shared_index(): use tempfile module, 2015-08-10) write_shared_index() has been using mks_tempfile() to create the temporary file that will become the shared index. But even before that, it looks like the functions used to create this file didn't call adjust_shared_perm(),

Re: [PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

On Fri, Jun 23 2017, Jeff King jotted: > On Fri, Jun 23, 2017 at 02:46:03PM +, Ævar Arnfjörð Bjarmason wrote: > >> Change the code for deciding what's to be done about %Z to stop >> passing always either a NULL or "" char * to >> strbuf_addftime(). Instead pass a boolean int to indicate

Re: [PATCH 1/3] read-cache: use shared perms when writing shared index

On Thu, Jun 22, 2017 at 9:51 PM, Junio C Hamano wrote: > Christian Couder writes: >> Let's fix that by using create_tempfile() instead of mks_tempfile() >> to create the shared index file. >> >> ... >> - fd = mks_tempfile(_sharedindex, >>

Re: [PATCH 2/3] t1301: move movebits() to test-lib-functions.sh

On Fri, Jun 23, 2017 at 1:09 AM, Ramsay Jones wrote: > > > On 22/06/17 20:52, Junio C Hamano wrote: >> Christian Couder writes: >> >>> As the movebits() function can be useful outside t1301, >>> let's move it into test-lib-functions.sh,

Re: [PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

On Fri, Jun 23, 2017 at 02:46:03PM +, Ævar Arnfjörð Bjarmason wrote: > Change the code for deciding what's to be done about %Z to stop > passing always either a NULL or "" char * to > strbuf_addftime(). Instead pass a boolean int to indicate whether the > strftime() %Z format should be

[PATCH] strbuf: change an always NULL/"" strbuf_addftime() param to bool

Change the code for deciding what's to be done about %Z to stop passing always either a NULL or "" char * to strbuf_addftime(). Instead pass a boolean int to indicate whether the strftime() %Z format should be omitted, which is what this code is actually doing. This code grew organically between

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

On Fri, Jun 23, 2017 at 6:52 AM, Jacob Keller wrote: > From: Jacob Keller > > Historically, git has tracked the status of remote branches (heads) in > refs/remotes//*. This is necessary and useful as it allows users > to track the difference

[RFC PATCH] proposal for refs/tracking/* hierarchy

From: Jacob Keller Historically, git has tracked the status of remote branches (heads) in refs/remotes//*. This is necessary and useful as it allows users to track the difference between their local work and the last known status of the remote work. Unfortunately this

[PATCH] xdiff: trim common tail with -U0 after diff

When -U0 is used, trim_common_tail should be called after `xdl_diff`, so that `--indent-heuristic` (and other diff processing) works as expected. It also removes the check for `!(xecfg->flags & XDL_EMIT_FUNCCONTEXT)` added in e0876bca4, which does not appear to be necessary anymore after moving

Re: [PATCH v3 0/4] Add regression tests for recent rebase -i fixes

On 23/06/17 06:07, Junio C Hamano wrote: > Junio C Hamano writes: > >>> git-rebase.sh | 4 +- >>> sequencer.c | 11 ++-- >>> t/t3404-rebase-interactive.sh | 7 +++ >>> t/t3420-rebase-autostash.sh | 136 >>>

Re: What's cooking in git.git (Jun 2017, #06; Thu, 22)

> On 23 Jun 2017, at 00:35, Junio C Hamano wrote: > > Here are the topics that have been cooking. Commits prefixed with > '-' are only in 'pu' (proposed updates) while commits prefixed with > '+' are in 'next'. The ones marked with '.' do not appear in any of > the

[PATCH v2 25/29] packed_refs_unlock(), packed_refs_is_locked(): new functions

Add two new public functions, `packed_refs_unlock()` and `packed_refs_is_locked()`, with which callers can manage and query the `packed-refs` lock externally. Call `packed_refs_unlock()` from `commit_packed_refs()` and `rollback_packed_refs()`. Signed-off-by: Michael Haggerty

[PATCH v2 23/29] packed_refs_lock(): function renamed from lock_packed_refs()

Rename `lock_packed_refs()` to `packed_refs_lock()` for consistency with how other methods are named. Also, it's about to get some companions. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 4 ++-- refs/packed-backend.c | 10 +- refs/packed-backend.h

[PATCH v2 18/29] packed_read_raw_ref(): new function, replacing `resolve_packed_ref()`

Add a new function, `packed_read_raw_ref()`, which is nearly a `read_raw_ref_fn`. Use it in place of `resolve_packed_ref()`. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 36 +--- 1 file changed, 17 insertions(+), 19

[PATCH v2 15/29] repack_without_refs(): take a `packed_ref_store *` parameter

It only cares about the packed-refs part of the reference store. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index

[PATCH v2 11/29] lock_packed_refs(): take a `packed_ref_store *` parameter

It only cares about the packed-refs part of the reference store. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index

[PATCH v2 26/29] clear_packed_ref_cache(): don't protest if the lock is held

The existing callers already check that the lock isn't held just before calling `clear_packed_ref_cache()`, and in the near future we want to be able to call this function when the lock is held. Signed-off-by: Michael Haggerty --- refs/packed-backend.c | 2 -- 1 file

[PATCH v2 10/29] add_packed_ref(): take a `packed_ref_store *` parameter

It only cares about the packed-refs part of the reference store. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index bc5c0de84e..4943207098

[PATCH v2 08/29] get_packed_ref_cache(): take a `packed_ref_store *` parameter

It only cares about the packed-refs part of the reference store. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 26 -- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index

[PATCH v2 29/29] read_packed_refs(): die if `packed-refs` contains bogus data

The old code ignored any lines that it didn't understand. This is dangerous. Instead, `die()` if the `packed-refs` file contains any lines that we don't know how to handle. Signed-off-by: Michael Haggerty --- refs/packed-backend.c | 6 +++--- 1 file changed, 3

[PATCH v2 27/29] commit_packed_refs(): remove call to `packed_refs_unlock()`

Instead, change the callers of `commit_packed_refs()` to call `packed_refs_unlock()`. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 2 ++ refs/packed-backend.c | 18 -- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git

[PATCH v2 28/29] repack_without_refs(): don't lock or unlock the packed refs

Change `repack_without_refs()` to expect the packed-refs lock to be held already, and not to release the lock before returning. Change the callers to deal with lock management. This change makes it possible for callers to hold the packed-refs lock for a longer span of time, a possibility that

[PATCH v2 24/29] packed_refs_lock(): report errors via a `struct strbuf *err`

That way the callers don't have to come up with error messages themselves. Signed-off-by: Michael Haggerty --- refs/files-backend.c | 6 ++ refs/packed-backend.c | 17 +++-- refs/packed-backend.h | 6 +++--- 3 files changed, 16 insertions(+), 13

  1   2   >