* [PATCH 1/4] diff-lib: allow ita entries treated as "not yet exist in index"
From: Nguyễn Thái Ngọc Duy @ 2016-10-24 10:42 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <20161024104222.31128-1-pclouds@gmail.com>
When comparing the index and the working tree to show which paths are
new, and comparing the tree recorded in the HEAD and the index to see if
committing the contents recorded in the index would result in an empty
commit, we would want the former comparison to say "these are new paths"
and the latter to say "there is no change" for paths that are marked as
intent-to-add.
We made a similar attempt at d95d728a ("diff-lib.c: adjust position of
i-t-a entries in diff", 2015-03-16), which redefined the semantics of
these two comparison modes globally, which was a disaster and had to be
reverted at 78cc1a54 ("Revert "diff-lib.c: adjust position of i-t-a
entries in diff"", 2015-06-23).
To make sure we do not repeat the same mistake, introduce a new internal
diffopt option so that this different semantics can be asked for only by
callers that ask it, while making sure other unaudited callers will get
the same comparison result.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
diff-lib.c | 14 ++++++++++++++
diff.h | 1 +
t/t2203-add-intent.sh | 16 +++++++++++++++-
t/t7064-wtstatus-pv2.sh | 4 ++--
wt-status.c | 7 ++++++-
5 files changed, 38 insertions(+), 4 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index 3007c85..27f1228 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -214,6 +214,12 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
!is_null_oid(&ce->oid),
ce->name, 0);
continue;
+ } else if (revs->diffopt.ita_invisible_in_index &&
+ ce_intent_to_add(ce)) {
+ diff_addremove(&revs->diffopt, '+', ce->ce_mode,
+ EMPTY_BLOB_SHA1_BIN, 0,
+ ce->name, 0);
+ continue;
}
changed = match_stat_with_submodule(&revs->diffopt, ce, &st,
@@ -379,6 +385,14 @@ static void do_oneway_diff(struct unpack_trees_options *o,
struct rev_info *revs = o->unpack_data;
int match_missing, cached;
+ /* i-t-a entries do not actually exist in the index */
+ if (revs->diffopt.ita_invisible_in_index &&
+ idx && ce_intent_to_add(idx)) {
+ idx = NULL;
+ if (!tree)
+ return; /* nothing to diff.. */
+ }
+
/* if the entry is not checked out, don't examine work tree */
cached = o->index_only ||
(idx && ((idx->ce_flags & CE_VALID) || ce_skip_worktree(idx)));
diff --git a/diff.h b/diff.h
index ec76a90..68a6618 100644
--- a/diff.h
+++ b/diff.h
@@ -146,6 +146,7 @@ struct diff_options {
int dirstat_permille;
int setup;
int abbrev;
+ int ita_invisible_in_index;
/* white-space error highlighting */
#define WSEH_NEW 1
#define WSEH_CONTEXT 2
diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh
index 8f22c43..2276e4e 100755
--- a/t/t2203-add-intent.sh
+++ b/t/t2203-add-intent.sh
@@ -5,10 +5,24 @@ test_description='Intent to add'
. ./test-lib.sh
test_expect_success 'intent to add' '
+ test_commit 1 &&
+ git rm 1.t &&
+ echo hello >1.t &&
echo hello >file &&
echo hello >elif &&
git add -N file &&
- git add elif
+ git add elif &&
+ git add -N 1.t
+'
+
+test_expect_success 'git status' '
+ git status --porcelain | grep -v actual >actual &&
+ cat >expect <<-\EOF &&
+ DA 1.t
+ A elif
+ A file
+ EOF
+ test_cmp expect actual
'
test_expect_success 'check result of "add -N"' '
diff --git a/t/t7064-wtstatus-pv2.sh b/t/t7064-wtstatus-pv2.sh
index 3012a4d..e319fa2 100755
--- a/t/t7064-wtstatus-pv2.sh
+++ b/t/t7064-wtstatus-pv2.sh
@@ -246,8 +246,8 @@ test_expect_success 'verify --intent-to-add output' '
git add --intent-to-add intent1.add intent2.add &&
cat >expect <<-EOF &&
- 1 AM N... 000000 100644 100644 $_z40 $EMPTY_BLOB intent1.add
- 1 AM N... 000000 100644 100644 $_z40 $EMPTY_BLOB intent2.add
+ 1 .A N... 000000 000000 100644 $_z40 $_z40 intent1.add
+ 1 .A N... 000000 000000 100644 $_z40 $_z40 intent2.add
EOF
git status --porcelain=v2 >actual &&
diff --git a/wt-status.c b/wt-status.c
index 9a14658..05a7dcb 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -437,7 +437,7 @@ static void wt_status_collect_changed_cb(struct diff_queue_struct *q,
switch (p->status) {
case DIFF_STATUS_ADDED:
- die("BUG: worktree status add???");
+ d->mode_worktree = p->two->mode;
break;
case DIFF_STATUS_DELETED:
@@ -547,6 +547,7 @@ static void wt_status_collect_changes_worktree(struct wt_status *s)
setup_revisions(0, NULL, &rev, NULL);
rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
DIFF_OPT_SET(&rev.diffopt, DIRTY_SUBMODULES);
+ rev.diffopt.ita_invisible_in_index = 1;
if (!s->show_untracked_files)
DIFF_OPT_SET(&rev.diffopt, IGNORE_UNTRACKED_IN_SUBMODULES);
if (s->ignore_submodule_arg) {
@@ -570,6 +571,7 @@ static void wt_status_collect_changes_index(struct wt_status *s)
setup_revisions(0, NULL, &rev, &opt);
DIFF_OPT_SET(&rev.diffopt, OVERRIDE_SUBMODULE_CONFIG);
+ rev.diffopt.ita_invisible_in_index = 1;
if (s->ignore_submodule_arg) {
handle_ignore_submodules_arg(&rev.diffopt, s->ignore_submodule_arg);
} else {
@@ -605,6 +607,8 @@ static void wt_status_collect_changes_initial(struct wt_status *s)
if (!ce_path_match(ce, &s->pathspec, NULL))
continue;
+ if (ce_intent_to_add(ce))
+ continue;
it = string_list_insert(&s->change, ce->name);
d = it->util;
if (!d) {
@@ -911,6 +915,7 @@ static void wt_longstatus_print_verbose(struct wt_status *s)
init_revisions(&rev, NULL);
DIFF_OPT_SET(&rev.diffopt, ALLOW_TEXTCONV);
+ rev.diffopt.ita_invisible_in_index = 1;
memset(&opt, 0, sizeof(opt));
opt.def = s->is_initial ? EMPTY_TREE_SHA1_HEX : s->reference;
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* Re: [PATCH] hex: use unsigned index for ring buffer
From: René Scharfe @ 2016-10-23 17:57 UTC (permalink / raw)
To: Jeff King; +Cc: Git List, Junio C Hamano
In-Reply-To: <20161023091146.p2kmqvgwxdf77dnn@sigill.intra.peff.net>
Am 23.10.2016 um 11:11 schrieb Jeff King:
> On Sun, Oct 23, 2016 at 11:00:48AM +0200, René Scharfe wrote:
>
>> Overflow is defined for unsigned integers, but not for signed ones.
>> Make the ring buffer index in sha1_to_hex() unsigned to be on the
>> safe side.
>>
>> Signed-off-by: Rene Scharfe <l.s.r@web.de>
>> ---
>> Hard to trigger, but probably even harder to diagnose once someone
>> somehow manages to do it on some uncommon architecture.
>
> Indeed. If we are worried about overflow, we would also want to assume
> that it wraps at a multiple of 4, but that is probably a sane
> assumption.
Hmm, I can't think of a way to violate this assumption except with
unsigned integers that are only a single bit wide. That would be a
weird machine. Are there other possibilities?
>> diff --git a/hex.c b/hex.c
>> index ab2610e..8c6c189 100644
>> --- a/hex.c
>> +++ b/hex.c
>> @@ -76,7 +76,7 @@ char *oid_to_hex_r(char *buffer, const struct object_id *oid)
>>
>> char *sha1_to_hex(const unsigned char *sha1)
>> {
>> - static int bufno;
>> + static unsigned int bufno;
>> static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
>> return sha1_to_hex_r(hexbuffer[3 & ++bufno], sha1);
>> }
>
> I wonder if just truncating bufno would be conceptually simpler (albeit
> longer):
>
> bufno++;
> bufno &= 3;
> return sha1_to_hex_r(hexbuffer[bufno], sha1);
>
> You could also write the second line like:
>
> bufno %= ARRAY_SIZE(hexbuffer);
>
> which is less magical (right now the set of buffers must be a power of
> 2). I expect the compiler could turn that into a bitmask itself.
Expelling magic is a good idea. And indeed, at least gcc, clang and icc
on x86-64 are smart enough to use an AND instead of dividing
(https://godbolt.org/g/rFPpzF).
But gcc also adds a sign extension (cltq/cdqe) if we store the truncated
value, unlike the other two compilers. I don't see why -- the bit mask
operation enforces a value between 0 and 3 (inclusive) and the upper
bits of eax are zeroed automatically, so the cltq is effectively a noop.
Using size_t gets us rid of the extra instruction and is the right type
anyway. It would suffice on its own, hmm..
> I'm fine with any of the options. I guess you'd want a similar patch for
> find_unique_abbrev on top of jk/no-looking-at-dotgit-outside-repo.
Actually I'd want you to want to amend your series yourself. ;) Maybe I
can convince Coccinelle to handle that issue for us.
And there's also path.c::get_pathname(). That's enough cases to justify
adding a macro, I'd say:
---
cache.h | 3 +++
hex.c | 4 ++--
path.c | 4 ++--
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/cache.h b/cache.h
index 05ecb88..8bb4918 100644
--- a/cache.h
+++ b/cache.h
@@ -555,6 +555,9 @@ extern int daemonize(void);
} \
} while (0)
+#define NEXT_RING_ITEM(array, index) \
+ (array)[(index) = ((index) + 1) % ARRAY_SIZE(array)]
+
/* Initialize and use the cache information */
struct lock_file;
extern int read_index(struct index_state *);
diff --git a/hex.c b/hex.c
index ab2610e..5e711b9 100644
--- a/hex.c
+++ b/hex.c
@@ -76,9 +76,9 @@ char *oid_to_hex_r(char *buffer, const struct
object_id *oid)
char *sha1_to_hex(const unsigned char *sha1)
{
- static int bufno;
+ static size_t bufno;
static char hexbuffer[4][GIT_SHA1_HEXSZ + 1];
- return sha1_to_hex_r(hexbuffer[3 & ++bufno], sha1);
+ return sha1_to_hex_r(NEXT_RING_ITEM(hexbuffer, bufno), sha1);
}
char *oid_to_hex(const struct object_id *oid)
diff --git a/path.c b/path.c
index a8e7295..60dba6a 100644
--- a/path.c
+++ b/path.c
@@ -24,8 +24,8 @@ static struct strbuf *get_pathname(void)
static struct strbuf pathname_array[4] = {
STRBUF_INIT, STRBUF_INIT, STRBUF_INIT, STRBUF_INIT
};
- static int index;
- struct strbuf *sb = &pathname_array[3 & ++index];
+ static size_t index;
+ struct strbuf *sb = &NEXT_RING_ITEM(pathname_array, index);
strbuf_reset(sb);
return sb;
}
--
2.10.1
^ permalink raw reply related
* Re: RFC Failover url for fetches?
From: Jakub Narębski @ 2016-10-23 17:40 UTC (permalink / raw)
To: Junio C Hamano, Stefan Beller; +Cc: git@vger.kernel.org
In-Reply-To: <xmqqeg39bk40.fsf@gitster.mtv.corp.google.com>
W dniu 21.10.2016 o 21:03, Junio C Hamano pisze:
> Stefan Beller <sbeller@google.com> writes:
>
>> So when pushing it is possible to have multiple urls
>> (remote.<name>.url) configured.
>>
>> When fetching only the first configured url is considered.
>> Would it make sense to allow multiple urls and
>> try them one by one until one works?
>
> I do not think the two are related. Pushing to multiple is not "I
> want to update at least one of them" in the first place.
Push is/should be 'update all', fetch is/should be 'fetch any'.
I thought that multiple remote.<name>.url values provide this
fallback for fetch, but it looks like it isn't so...
>
> As to fetching from two or more places as "fallback", I am
> moderately negative to add it as a dumb feature that does nothing
> more than "My fetch from A failed, so let's blindly try it from B".
> I'd prefer to keep the "My fetch from A is failing" knowledge near
> the surface of end user's consciousness as a mechanism to pressure A
> to fix it--that way everybody who is fetching from A benefits.
> After all, doing "git remote add B" once (you'd need to tell the URL
> for B anyway to Git) and issuing "git fetch B" after seeing your
> regular "git fetch" fails once in a blue moon is not all that
> cumbersome, I would think.
One would need to configure fallback B remote to use the same
remote-branch namespace as remote A, if it is to be used as fallback,
I would think.
>
> Some people _may_ have objection based on A and B going out of sync,
> especially B may fall behind even yourself and cause non-ff errors,
> but I personally am not worried about that, because when somebody
> configures B as a fallback for A, there is an expectation that B is
> kept reasonably up to date. It would be a problem if some refs are
> expected to be constantly rewound at A (e.g. 'pu' in my tree) and
> configured to always force-fetch, though. A stale B would silently
> set such a branch in your repository back without failing.
Nb. there is also http-alternates mechanism... which nowadays doesn't
matter anyway, I would think.
--
Jakub Narębski
^ permalink raw reply
* Re: [PATCH v1 10/19] read-cache: regenerate shared index if necessary
From: Ramsay Jones @ 2016-10-23 16:07 UTC (permalink / raw)
To: Christian Couder, git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-11-chriscool@tuxfamily.org>
On 23/10/16 10:26, Christian Couder wrote:
> When writing a new split-index and there is a big number of cache
> entries in the split-index compared to the shared index, it is a
> good idea to regenerate the shared index.
>
> By default when the ratio reaches 20%, we will push back all
> the entries from the split-index into a new shared index file
> instead of just creating a new split-index file.
>
> The threshold can be configured using the
> "splitIndex.maxPercentChange" config variable.
>
> We need to adjust the existing tests in t1700 by setting
> "splitIndex.maxPercentChange" to 100 at the beginning of t1700,
> as the existing tests are assuming that the shared index is
> regenerated only when `git update-index --split-index` is used.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> read-cache.c | 33 ++++++++++++++++++++++++++++++++-
> t/t1700-split-index.sh | 1 +
> 2 files changed, 33 insertions(+), 1 deletion(-)
>
> diff --git a/read-cache.c b/read-cache.c
> index bb53823..a91fabe 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -2216,6 +2216,36 @@ static int write_shared_index(struct index_state *istate,
> return ret;
> }
>
> +static const int default_max_percent_split_change = 20;
> +
> +int too_many_not_shared_entries(struct index_state *istate)
This function is a file-loacal symbol; could you please make it
a static function.
Thanks.
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 28/36] attr: keep attr stack for each check
From: Ramsay Jones @ 2016-10-23 15:10 UTC (permalink / raw)
To: Stefan Beller, gitster; +Cc: git, bmwill, pclouds
In-Reply-To: <20161022233225.8883-29-sbeller@google.com>
On 23/10/16 00:32, Stefan Beller wrote:
> Instead of having a global attr stack, attach the stack to each check.
> This allows to use the attr in a multithreaded way.
>
>
>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> attr.c | 101 +++++++++++++++++++++++++++++++++++++++-----------------------
> attr.h | 4 ++-
> hashmap.h | 2 ++
> 3 files changed, 69 insertions(+), 38 deletions(-)
>
> diff --git a/attr.c b/attr.c
> index 89ae155..b65437d 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -372,15 +372,17 @@ static struct match_attr *parse_attr_line(const char *line, const char *src,
> * .gitignore file and info/excludes file as a fallback.
> */
>
> -/* NEEDSWORK: This will become per git_attr_check */
> -static struct attr_stack {
> +struct attr_stack {
> struct attr_stack *prev;
> char *origin;
> size_t originlen;
> unsigned num_matches;
> unsigned alloc;
> struct match_attr **attrs;
> -} *attr_stack;
> +};
> +
> +struct hashmap all_attr_stacks;
> +int all_attr_stacks_init;
Mark symbols 'all_attr_stacks' and 'all_attr_stacks_init' with
the static keyword. (ie. these are file-local symbols).
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 17/36] attr: expose validity check for attribute names
From: Ramsay Jones @ 2016-10-23 15:07 UTC (permalink / raw)
To: Stefan Beller, gitster; +Cc: git, bmwill, pclouds
In-Reply-To: <20161022233225.8883-18-sbeller@google.com>
On 23/10/16 00:32, Stefan Beller wrote:
> From: Junio C Hamano <gitster@pobox.com>
>
> Export attr_name_valid() function, and a helper function that
> returns the message to be given when a given <name, len> pair
> is not a good name for an attribute.
>
> We could later update the message to exactly spell out what the
> rules for a good attribute name are, etc.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
[snip]
> +extern int attr_name_valid(const char *name, size_t namelen);
> +extern void invalid_attr_name_message(struct strbuf *, const char *, int);
> +
The symbol 'attr_name_valid()' is not used outside of attr.c, even
by the end of this series. Do you expect this function to be used
in any future series? (The export is deliberate and it certainly
seems like it should be part of the public interface, but ...)
In contrast, the 'invalid_attr_name_message()' function is called
from code in pathspec.c, which relies on 'git_attr_counted()' to
call 'attr_name_valid()' internally to check for validity. :-D
ATB,
Ramsay Jones
^ permalink raw reply
* Re: git clone --bare --origin incompatible?
From: Roman Neuhauser @ 2016-10-23 12:50 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <87y41f8czg.fsf@linux-m68k.org>
# schwab@linux-m68k.org / 2016-10-23 14:29:55 +0200:
> On Okt 23 2016, Roman Neuhauser <neuhauser@sigpipe.cz> wrote:
>
> > what is the reason clone --bare prohibits --origin?
> >
> > % git clone --bare -o fubar anything anywhere
> > fatal: --bare and --origin fubar options are incompatible.
>
> Since a bare clone maps remote branches directly to local branches,
> without any remote-tracking branches, --origin doesn't make sense.
is it going to break something though? i can still go and rename
the remote in the bare repo's config file afterwards.
--
roman
^ permalink raw reply
* Re: git clone --bare --origin incompatible?
From: Andreas Schwab @ 2016-10-23 12:29 UTC (permalink / raw)
To: Roman Neuhauser; +Cc: git
In-Reply-To: <20161023110338.GA1486@isis.sigpipe.cz>
On Okt 23 2016, Roman Neuhauser <neuhauser@sigpipe.cz> wrote:
> what is the reason clone --bare prohibits --origin?
>
> % git clone --bare -o fubar anything anywhere
> fatal: --bare and --origin fubar options are incompatible.
Since a bare clone maps remote branches directly to local branches,
without any remote-tracking branches, --origin doesn't make sense.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* git clone --bare --origin incompatible?
From: Roman Neuhauser @ 2016-10-23 11:03 UTC (permalink / raw)
To: git
hello,
what is the reason clone --bare prohibits --origin?
% git clone --bare -o fubar anything anywhere
fatal: --bare and --origin fubar options are incompatible.
--
roman
^ permalink raw reply
* Re: tools for easily "uncommitting" parts of a patch I just commited?
From: Duy Nguyen @ 2016-10-23 10:27 UTC (permalink / raw)
To: Jeff King; +Cc: Lukas Fleischer, Git Mailing List
In-Reply-To: <20161023013846.ct3olfabw2yhzio2@sigill.intra.peff.net>
On Sun, Oct 23, 2016 at 8:38 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Oct 23, 2016 at 08:23:01AM +0700, Duy Nguyen wrote:
>
>> I hit the same problem sometimes, but in my case sometimes I
>> accidentally do "git add" after "git add -p" and a configuration in
>> "git commit -a" won't help me. I'd prefer we could undo changes in
>> index instead. Something like reflog but for index.
>
> An index write always writes the whole file from scratch, so you really
> just need to save a copy of the old file. Perhaps something like:
>
> rm -f $GIT_DIR/index.old
> ln $GIT_DIR/index.old $GIT_DIR/index
> ... and then open $GIT_DIR/index.tmp ...
> ... and then rename(index.tmp, index) ...
>
> could do it cheaply. It's a little more complicated if you want to save
> a sequence of versions, and eventually would take a lot of space, but
> presumably a handful of saved indexes would be sufficient.
Yeah. I had something [1] like that but never sorted out the UI for it :(
> Another option would be an index format that journals, and you could
> potentially walk back the journal to a point. That seems like a much
> bigger change (and has weird layering, because deciding when to fold in
> the journal is usually a performance thing, but obviously this would
> have user-visible impact about how far back you could undo).
v2 [2] goes in this direction (but not a full blown COW, the journal
does not take part in any core operations of the index)
[1] https://public-inbox.org/git/%3C1375597720-13236-1-git-send-email-pclouds@gmail.com%3E/
[2] https://public-inbox.org/git/1375966270-10968-1-git-send-email-pclouds@gmail.com/
--
Duy
^ permalink raw reply
* Re: [PATCH 2/3] submodule tests: replace cloning from . by "$(pwd)"
From: Johannes Sixt @ 2016-10-23 10:14 UTC (permalink / raw)
To: Stefan Beller
Cc: Junio C Hamano, Johannes Schindelin, git@vger.kernel.org, Karl A.,
Dennis Kaarsemaker, Jonathan Nieder
In-Reply-To: <CAGZ79kaukGh2ynkOQcF=skzxTMYr8CFRyGJw6FEmNsTAcaG_VQ@mail.gmail.com>
Am 22.10.2016 um 22:46 schrieb Stefan Beller:
> I have looked into it again, and by now I think the bug is a feature,
> actually.
>
> Consider this:
>
> git clone . super
> git -C super submodule add ../submodule
> # we thought the previous line is buggy
> git clone super super-clone
At this point, we *should* have this if there were no bugs (at least
that is my assumption):
/tmp
!
+ submodule <- submodule's remote repo
!
+ foo <- we are here (.), super's remote repo
!
+ super <- remote.origin.url=/tmp/foo/.
!
+ submodule <- remote.origin.url=/tmp/foo/./../submodule
submodule.submodule.url=../submodule
When I test this, 'git submodule add' fails:
foo@master> git -C super submodule add ../submodule
fatal: repository '/tmp/foo/submodule' does not exist
fatal: clone of '/tmp/foo/submodule' into submodule path
'/tmp/foo/super/submodule' failed
> Now in the super-clone the ../submodule is the correct
> relative url, because the url where we cloned from doesn't
> end in /.
I do not understand why this would be relevant. The question is not how
the submodule's remote URL ends, but how the submodule's remote URL is
constructed from the super-project's URL and the relative path specified
for 'git submodule add'.
Whether ../submodule or ./submodule is the correct relative URL depends
on where the origin of the submodule is located relative to the origin
of the super-project. In the above example, it is ../submodule. However,
the error message tells us that git looked in /tmp/foo/submodule, which
looks like the /. bug!
I do not understand where you see a feature here. What am I missing?
-- Hannes
^ permalink raw reply
* Re: [PATCH v5 00/27] Prepare the sequencer for the upcoming rebase -i patches
From: Johannes Schindelin @ 2016-10-23 9:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Stefan Beller, Jeff King, Jakub Narębski, Johannes Sixt,
Ramsay Jones
In-Reply-To: <alpine.DEB.2.20.1610231151140.3264@virtualbox>
Hi Junio,
On Sun, 23 Oct 2016, Johannes Schindelin wrote:
> On Sat, 22 Oct 2016, Junio C Hamano wrote:
>
> > Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> >
> > > This patch series marks the '4' in the countdown to speed up rebase -i
> > > by implementing large parts in C (read: there will be three more patch
> > > series after that before the full benefit hits git.git: sequencer-i,
> > > rebase--helper and rebase-i-extra).
> > > ...
> > > It would be *really* nice if we could get this patch series at least
> > > into `next` soon, as it gets late and later for the rest of the
> > > patches to make it into `master` in time for v2.11 (and it is not for
> > > lack of trying on my end...).
> >
> > This "countdown 4" step can affect cherry-pick and revert, even
Oh, I forgot to comment on this tidbit of your mail, sorry.
This *is* the countdown 4, as the remaining 3 patch series depend on each
other in the order I sent them out.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v5 00/27] Prepare the sequencer for the upcoming rebase -i patches
From: Johannes Schindelin @ 2016-10-23 9:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Stefan Beller, Jeff King, Jakub Narębski, Johannes Sixt,
Ramsay Jones
In-Reply-To: <xmqqinsk8g1b.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Sat, 22 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > This patch series marks the '4' in the countdown to speed up rebase -i
> > by implementing large parts in C (read: there will be three more patch
> > series after that before the full benefit hits git.git: sequencer-i,
> > rebase--helper and rebase-i-extra).
> > ...
> > It would be *really* nice if we could get this patch series at least
> > into `next` soon, as it gets late and later for the rest of the
> > patches to make it into `master` in time for v2.11 (and it is not for
> > lack of trying on my end...).
>
> This "countdown 4" step can affect cherry-pick and revert, even
> though we were careful to review changes to the sequencer.c code.
As I pointed out in another mail in this thread: we should not fall into
the trap of overrating review.
In the case of the rebase--helper patches, so far the review mainly
resulted in more work for me (having to change spellings elsewhere, for
example), not in improving the changes I intended to introduce into
git.git's code.
Sure, there has been the occasional improvement, but it certainly feels as
if I spent about 80% of the work after each -v1 iteration on things that
have positively nothing at all to do with accelerating rebase -i.
> I prefer to cook it in 'next' sufficiently long to ensure that we hear
> feedbacks from non-Windows users if there is any unexpected breakage.
FWIW I am using the same patches not only on Windows but also in my Linux
VM.
> There isn't enough time to include this topic in the upcoming
> release within the current https://tinyurl.com/gitCal calendar,
> however, which places the final on Nov 11th.
More is the pity.
Thank you, though, for being upfront with me. I will shift my focus to
tasks that require my attention more urgently, then.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v5 00/27] Prepare the sequencer for the upcoming rebase -i patches
From: Johannes Schindelin @ 2016-10-23 9:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narębski, Johannes Sixt, Ramsay Jones
In-Reply-To: <xmqqinslbl5t.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Fri, 21 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> I still do not understand (note that I am not saying "I do not
> accept"--acceptance or rejection happens after an understandable
> explanation is given, and "do not understand" means no such
> explanation has been given yet) your justification behind adding a
> technical debt to reimplement the author-script parser and not
> sharing it with "git am" in 13/27.
At this point, I am most of all reluctant to introduce such a huge change,
which surely would introduce a regression.
This is what happened a couple of times to me, most recently with the
hide-dot-gitdir patch series that worked flawlessly for years, had to be
dramatically changed during review to enter git.git, and introduced the
major regression that `core.hideDotFiles = gitDirOnly` was broken.
The lesson I learned: review should not be valued more than the test of
time. This lesson has been reinforced by all the regressions that have not
been caught by review nor the test suite running on Linux only.
It would be a different matter if I still had the cross-validator in place
(which I did when I sent out v1 of this patch series) and tons of time to
spend on accommodating your wishes, however I may disagree with them. And
in this instance, I thought I made clear that I disagree, and why:
Internally, git-am and git-rebase-i handle the author-script very
differently. That may change at some stage in the future, and it would be
a good time then and there to take care of unifying this code. Currently,
not so much, as the only excuse to use the same parser would be that they
both read the same file, while they have to do very different things with
the parsed output (in fact, your suggestion would ask the parser in the
sequencer to rip apart the information into key/value pairs, only to
re-glue them back together when they are used as the environment variables
as which rebase-i treats the contents of the author-script file).
So no, at this point I am not willing to risk introducing breakages in
code that has been proven to work in practice.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v5 22/27] sequencer: teach write_message() to append an optional LF
From: Johannes Schindelin @ 2016-10-23 9:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narębski, Johannes Sixt, Ramsay Jones
In-Reply-To: <xmqqmvhxbljm.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Fri, 21 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > This commit prepares for future callers that will have a pointer/length
> > to some text to be written that lacks an LF, yet an LF is desired.
> > Instead of requiring the caller to append an LF to the buffer (and
> > potentially allocate memory to do so), the write_message() function
> > learns to append an LF at the end of the file.
>
> As no existing callers need this, it probably is better left out and
> added to the series that actually needs the new feature as a
> preparatory step.
Apart from this patch series being semantically the right place
("prepare-sequencer"), there is also the following consideration:
The next patch series is already quite long. Taking this current patch
series into account, which started out as a 22-patch series and needed to
bloat by 25% through four subsequent iterations, it is probably not a wise
idea to move this patch to a patch series that already weighs 34 patches.
So I respectfully, and forcefully, disagree,
Dscho
^ permalink raw reply
* Re: Stash pop/apply conflict and --theirs and --ours
From: Jeff King @ 2016-10-23 9:30 UTC (permalink / raw)
To: Sven Strickroth; +Cc: Git List, Junio C Hamano
In-Reply-To: <169639c9-054f-8f4c-26bd-3f130fa4c1ee@cs-ware.de>
On Sun, Oct 23, 2016 at 12:58:12AM +0200, Sven Strickroth wrote:
> I regularly experience that beginners have problems unterstanding that
> --ours and --theirs are swapped when a conflict occurrs on git stash
> apply or stash pop.
>
> From the HCI perspective this is really counter intuitive.
I know that people have complained about "rebase" swapping the two, but
I don't think anybody has ever mentioned it for stash. I'm not sure I
that they are swapped, though.
The "ours" content is generally what was in the HEAD before the
operation started, and "theirs" is what the operation is bringing into
that history. That is true of "merge" and "cherry-pick". And AFAICT, it
is true of "stash", too (I basically think of "stash apply" as a
cherry-pick).
So with a setup like:
git init
echo base >file
git add file
git commit -m file
echo stash >file
git stash
echo master >file
git commit -am master
git checkout -b branch HEAD^
echo branch >file
git commit -am branch
if we merge, then --theirs is the branch we are merging:
git checkout master
git merge branch
git checkout --theirs file
cat file
# "branch"
Likewise, if we cherry-pick:
git reset --hard
git cherry-pick branch
git checkout --theirs file
cat file
# "branch"
And likewise if we apply the stash:
git reset --hard
git stash apply
git checkout --theirs file
cat file
# "stash"
So that seems consistent to me.
I guess if you are stashing in order to pull somebody else's work, like:
git stash
git pull
git stash pop
then conceptually the stash is "ours" and HEAD is "theirs". This is
exactly like the rebase case. E.g., if you instead did:
git commit -m 'tmp stash'
git pull --rebase
So I sympathize, but I don't think that having "stash" flip the order
would be the right thing to do in all cases. In theory there could be
some kind of option (and things like pull autostash could use it), but I
suspect it may be hard to implement in practice. The unpack-trees code
does not treat "ours" and "theirs" entirely symmetrically (the "ours"
side represents the current working tree, so we might do things like
check whether the index is fresh). I guess you could flip the "1" and
"2" bits in the index after the conflicted merge completes.
I'm still not convinced it's a good idea, though.
-Peff
^ permalink raw reply
* Re: [PATCH v4 20/25] sequencer: refactor write_message()
From: Johannes Schindelin @ 2016-10-23 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narębski, Johannes Sixt, Ramsay Jones
In-Reply-To: <xmqqr379d82b.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Fri, 21 Oct 2016, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Ah, make that four steps. The final one is:
> >>
> >> - add append_eol parameter that nobody uses at this step in the
> >> series.
> >>
> >> This is a new feature to the helper. While it is OK to have it as a
> >> preparatory step in this series, it is easier to understand if it
> >> kept as a separate step. It is even more preferrable if it is made
> >> as a preparatory step in a series that adds a caller that passes
> >> true to append_eol to this helper...
> >
> > Done,
> > Dscho
>
> Hmm, what has been done exactly? I still see append_eol in v5 where
> nobody uses it yet. Confused...
Your bullet point suggests that this change should be a separate patch. I
did that.
And since this patch series' purpose is to prepare the sequencer for the
upcoming series that teaches it to understand git-rebase-todo scripts,
this patch falls fair and square into the preparatory phase.
Ciao,
Dscho
^ permalink raw reply
* [PATCH v1 06/19] t1700: add tests for core.splitIndex
From: Christian Couder @ 2016-10-23 9:26 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t1700-split-index.sh | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index 292a072..db8c39f 100755
--- a/t/t1700-split-index.sh
+++ b/t/t1700-split-index.sh
@@ -200,4 +200,41 @@ EOF
test_cmp expect actual
'
+test_expect_success 'set core.splitIndex config variable to true' '
+ git config core.splitIndex true &&
+ : >three &&
+ git update-index --add three &&
+ git ls-files --stage >ls-files.actual &&
+ cat >ls-files.expect <<EOF &&
+100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 one
+100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 three
+100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 two
+EOF
+ test_cmp ls-files.expect ls-files.actual &&
+ BASE=$(test-dump-split-index .git/index | grep "^base") &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<EOF &&
+$BASE
+replacements:
+deletions:
+EOF
+ test_cmp expect actual
+'
+
+test_expect_success 'set core.splitIndex config variable to false' '
+ git config core.splitIndex false &&
+ git update-index --force-remove three &&
+ git ls-files --stage >ls-files.actual &&
+ cat >ls-files.expect <<EOF &&
+100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 one
+100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0 two
+EOF
+ test_cmp ls-files.expect ls-files.actual &&
+ test-dump-split-index .git/index | sed "/^own/d" >actual &&
+ cat >expect <<EOF &&
+not a split index
+EOF
+ test_cmp expect actual
+'
+
test_done
--
2.10.1.462.g7e1e03a
^ permalink raw reply related
* [PATCH v1 14/19] read-cache: touch shared index files when used
From: Christian Couder @ 2016-10-23 9:26 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-1-chriscool@tuxfamily.org>
When a split-index file is created, let's update the mtime of the
shared index file that the split-index file is referencing.
In a following commit we will make shared index file expire
depending on their mtime, so updating the mtime makes sure that
the shared index file will not be deleted soon.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
read-cache.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/read-cache.c b/read-cache.c
index a91fabe..3aeff77 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -2268,6 +2268,12 @@ int write_locked_index(struct index_state *istate, struct lock_file *lock,
int ret = write_shared_index(istate, lock, flags);
if (ret)
return ret;
+ } else {
+ /* Signal that the shared index is used */
+ const char *shared_index = git_path("sharedindex.%s",
+ sha1_to_hex(si->base_sha1));
+ if (!check_and_freshen_file(shared_index, 1))
+ warning("could not freshen '%s'", shared_index);
}
return write_split_index(istate, lock, flags);
--
2.10.1.462.g7e1e03a
^ permalink raw reply related
* [PATCH v1 08/19] Documentation/git-update-index: talk about core.splitIndex config var
From: Christian Couder @ 2016-10-23 9:26 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-update-index.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 7386c93..e091b2a 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -171,6 +171,12 @@ may not support it yet.
given again, all changes in $GIT_DIR/index are pushed back to
the shared index file. This mode is designed for very large
indexes that take a significant amount of time to read or write.
++
+These options take effect whatever the value of the `core.splitIndex`
+configuration variable (see linkgit:git-config[1]). But a warning is
+emitted when the change goes against the configured value, as the
+configured value will take effect next time the index is read and this
+will remove the intended effect of the option.
--untracked-cache::
--no-untracked-cache::
--
2.10.1.462.g7e1e03a
^ permalink raw reply related
* [PATCH v1 16/19] read-cache: unlink old sharedindex files
From: Christian Couder @ 2016-10-23 9:26 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-1-chriscool@tuxfamily.org>
Everytime split index is turned on, it creates a "sharedindex.XXXX"
file in the git directory. This change makes sure that shared index
files that haven't been used for a long time are removed when a new
shared index file is created.
The new "splitIndex.sharedIndexExpire" config variable is created
to tell the delay after which an unused shared index file can be
deleted. It defaults to "1.week.ago".
A previous commit made sure that each time a split index file is
created the mtime of the shared index file it references is updated.
This makes sure that recently used shared index file will not be
deleted.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
read-cache.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/read-cache.c b/read-cache.c
index 3aeff77..65ceb29 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -2190,6 +2190,64 @@ static int write_split_index(struct index_state *istate,
return ret;
}
+static const char *shared_index_expire = "1.week.ago";
+
+static unsigned long get_shared_index_expire_date(void)
+{
+ static unsigned long shared_index_expire_date;
+ static int shared_index_expire_date_prepared;
+
+ if (!shared_index_expire_date_prepared) {
+ git_config_get_date_string("splitindex.sharedindexexpire",
+ &shared_index_expire);
+ shared_index_expire_date = approxidate(shared_index_expire);
+ shared_index_expire_date_prepared = 1;
+ }
+
+ return shared_index_expire_date;
+}
+
+static int can_delete_shared_index(const char *shared_sha1_hex)
+{
+ struct stat st;
+ unsigned long expiration;
+ const char *shared_index = git_path("sharedindex.%s", shared_sha1_hex);
+
+ /* Check timestamp */
+ expiration = get_shared_index_expire_date();
+ if (!expiration)
+ return 0;
+ if (stat(shared_index, &st))
+ return error_errno("could not stat '%s", shared_index);
+ if (st.st_mtime > expiration)
+ return 0;
+
+ return 1;
+}
+
+static void clean_shared_index_files(const char *current_hex)
+{
+ struct dirent *de;
+ DIR *dir = opendir(get_git_dir());
+
+ if (!dir) {
+ error_errno("unable to open git dir: %s", get_git_dir());
+ return;
+ }
+
+ while ((de = readdir(dir)) != NULL) {
+ const char *sha1_hex;
+ if (!skip_prefix(de->d_name, "sharedindex.", &sha1_hex))
+ continue;
+ if (!strcmp(sha1_hex, current_hex))
+ continue;
+ if (can_delete_shared_index(sha1_hex) > 0 &&
+ unlink(git_path("%s", de->d_name)))
+ error_errno("unable to unlink: %s", git_path("%s", de->d_name));
+ }
+ closedir(dir);
+}
+
static struct tempfile temporary_sharedindex;
static int write_shared_index(struct index_state *istate,
@@ -2211,8 +2269,11 @@ static int write_shared_index(struct index_state *istate,
}
ret = rename_tempfile(&temporary_sharedindex,
git_path("sharedindex.%s", sha1_to_hex(si->base->sha1)));
- if (!ret)
+ if (!ret) {
hashcpy(si->base_sha1, si->base->sha1);
+ clean_shared_index_files(sha1_to_hex(si->base->sha1));
+ }
+
return ret;
}
--
2.10.1.462.g7e1e03a
^ permalink raw reply related
* [PATCH v1 19/19] Documentation/git-update-index: explain splitIndex.*
From: Christian Couder @ 2016-10-23 9:26 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-update-index.txt | 33 +++++++++++++++++++++++++--------
1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index e091b2a..635d157 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -163,14 +163,10 @@ may not support it yet.
--split-index::
--no-split-index::
- Enable or disable split index mode. If enabled, the index is
- split into two files, $GIT_DIR/index and $GIT_DIR/sharedindex.<SHA-1>.
- Changes are accumulated in $GIT_DIR/index while the shared
- index file contains all index entries stays unchanged. If
- split-index mode is already enabled and `--split-index` is
- given again, all changes in $GIT_DIR/index are pushed back to
- the shared index file. This mode is designed for very large
- indexes that take a significant amount of time to read or write.
+ Enable or disable split index mode. If split-index mode is
+ already enabled and `--split-index` is given again, all
+ changes in $GIT_DIR/index are pushed back to the shared index
+ file.
+
These options take effect whatever the value of the `core.splitIndex`
configuration variable (see linkgit:git-config[1]). But a warning is
@@ -394,6 +390,27 @@ Although this bit looks similar to assume-unchanged bit, its goal is
different from assume-unchanged bit's. Skip-worktree also takes
precedence over assume-unchanged bit when both are set.
+Split index
+-----------
+
+This mode is designed for very large indexes that take a significant
+amount of time to read or write.
+
+In this mode, the index is split into two files, $GIT_DIR/index and
+$GIT_DIR/sharedindex.<SHA-1>. Changes are accumulated in
+$GIT_DIR/index, the split index, while the shared index file contains
+all index entries and stays unchanged.
+
+All changes in the split index are pushed back to the shared index
+file when the number of entries in the split index reaches a level
+specified by the splitIndex.maxPercentChange config variable (see
+linkgit:git-config[1]).
+
+Each time a new shared index file is created, the old shared index
+files are deleted if they are older than what is specified by the
+splitIndex.sharedIndexExpire config variable (see
+linkgit:git-config[1]).
+
Untracked cache
---------------
--
2.10.1.462.g7e1e03a
^ permalink raw reply related
* [PATCH v1 18/19] Documentation/config: add splitIndex.sharedIndexExpire
From: Christian Couder @ 2016-10-23 9:26 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/config.txt | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 380eeb8..5212a97 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2776,6 +2776,17 @@ splitIndex.maxPercentChange::
than 20 percent of the total number of entries.
See linkgit:git-update-index[1].
+splitIndex.sharedIndexExpire::
+ When the split index feature is used, shared index files with
+ a mtime older than this time will be removed when a new shared
+ index file is created. The value "now" expires all entries
+ immediately, and "never" suppresses expiration altogether.
+ The default value is "one.week.ago".
+ Note that each time a new split-index file is created, the
+ mtime of the related shared index file is updated to the
+ current time.
+ See linkgit:git-update-index[1].
+
status.relativePaths::
By default, linkgit:git-status[1] shows paths relative to the
current directory. Setting this variable to `false` shows paths
--
2.10.1.462.g7e1e03a
^ permalink raw reply related
* [PATCH v1 17/19] t1700: test shared index file expiration
From: Christian Couder @ 2016-10-23 9:26 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-1-chriscool@tuxfamily.org>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t1700-split-index.sh | 44 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index f03addf..f448fc1 100755
--- a/t/t1700-split-index.sh
+++ b/t/t1700-split-index.sh
@@ -310,4 +310,48 @@ EOF
test_cmp expect actual
'
+test_expect_success 'shared index files expire after 7 days by default' '
+ : >ten &&
+ git update-index --add ten &&
+ test $(ls .git/sharedindex.* | wc -l) -gt 1 &&
+ just_under_7_days_ago=$((1-7*86400)) &&
+ test-chmtime =$just_under_7_days_ago .git/sharedindex.* &&
+ : >eleven &&
+ git update-index --add eleven &&
+ test $(ls .git/sharedindex.* | wc -l) -gt 1 &&
+ just_over_7_days_ago=$((-1-7*86400)) &&
+ test-chmtime =$just_over_7_days_ago .git/sharedindex.* &&
+ : >twelve &&
+ git update-index --add twelve &&
+ test $(ls .git/sharedindex.* | wc -l) = 1
+'
+
+test_expect_success 'check splitIndex.sharedIndexExpire set to 8 days' '
+ git config splitIndex.sharedIndexExpire "8.days.ago" &&
+ test-chmtime =$just_over_7_days_ago .git/sharedindex.* &&
+ : >thirteen &&
+ git update-index --add thirteen &&
+ test $(ls .git/sharedindex.* | wc -l) -gt 1 &&
+ just_over_8_days_ago=$((-1-8*86400)) &&
+ test-chmtime =$just_over_8_days_ago .git/sharedindex.* &&
+ : >fourteen &&
+ git update-index --add fourteen &&
+ test $(ls .git/sharedindex.* | wc -l) = 1
+'
+
+test_expect_success 'check splitIndex.sharedIndexExpire set to "never" and "now"' '
+ git config splitIndex.sharedIndexExpire never &&
+ just_10_years_ago=$((-365*10*86400)) &&
+ test-chmtime =$just_10_years_ago .git/sharedindex.* &&
+ : >fifteen &&
+ git update-index --add fifteen &&
+ test $(ls .git/sharedindex.* | wc -l) -gt 1 &&
+ git config splitIndex.sharedIndexExpire now &&
+ just_1_second_ago=-1 &&
+ test-chmtime =$just_1_second_ago .git/sharedindex.* &&
+ : >sixteen &&
+ git update-index --add sixteen &&
+ test $(ls .git/sharedindex.* | wc -l) = 1
+'
+
test_done
--
2.10.1.462.g7e1e03a
^ permalink raw reply related
* [PATCH v1 15/19] config: add git_config_get_date_string() from gc.c
From: Christian Couder @ 2016-10-23 9:26 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nguyen Thai Ngoc Duy,
Ævar Arnfjörð Bjarmason, Christian Couder
In-Reply-To: <20161023092648.12086-1-chriscool@tuxfamily.org>
This function will be used in a following commit to get the expiration
time of the shared index files from the config, and it is generic
enough to be put in "config.c".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin/gc.c | 15 ++-------------
cache.h | 1 +
config.c | 13 +++++++++++++
3 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 069950d..c1e9602 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -62,17 +62,6 @@ static void report_pack_garbage(unsigned seen_bits, const char *path)
string_list_append(&pack_garbage, path);
}
-static void git_config_date_string(const char *key, const char **output)
-{
- if (git_config_get_string_const(key, output))
- return;
- if (strcmp(*output, "now")) {
- unsigned long now = approxidate("now");
- if (approxidate(*output) >= now)
- git_die_config(key, _("Invalid %s: '%s'"), key, *output);
- }
-}
-
static void process_log_file(void)
{
struct stat st;
@@ -111,8 +100,8 @@ static void gc_config(void)
git_config_get_int("gc.auto", &gc_auto_threshold);
git_config_get_int("gc.autopacklimit", &gc_auto_pack_limit);
git_config_get_bool("gc.autodetach", &detach_auto);
- git_config_date_string("gc.pruneexpire", &prune_expire);
- git_config_date_string("gc.worktreepruneexpire", &prune_worktrees_expire);
+ git_config_get_date_string("gc.pruneexpire", &prune_expire);
+ git_config_get_date_string("gc.worktreepruneexpire", &prune_worktrees_expire);
git_config(git_default_config, NULL);
}
diff --git a/cache.h b/cache.h
index a625b47..bcfc0f1 100644
--- a/cache.h
+++ b/cache.h
@@ -1811,6 +1811,7 @@ extern int git_config_get_bool(const char *key, int *dest);
extern int git_config_get_bool_or_int(const char *key, int *is_bool, int *dest);
extern int git_config_get_maybe_bool(const char *key, int *dest);
extern int git_config_get_pathname(const char *key, const char **dest);
+extern int git_config_get_date_string(const char *key, const char **output);
extern int git_config_get_untracked_cache(void);
extern int git_config_get_split_index(void);
extern int git_config_get_max_percent_split_change(void);
diff --git a/config.c b/config.c
index 5580f56..f88c61b 100644
--- a/config.c
+++ b/config.c
@@ -1685,6 +1685,19 @@ int git_config_get_pathname(const char *key, const char **dest)
return ret;
}
+int git_config_get_date_string(const char *key, const char **output)
+{
+ int ret = git_config_get_string_const(key, output);
+ if (ret)
+ return ret;
+ if (strcmp(*output, "now")) {
+ unsigned long now = approxidate("now");
+ if (approxidate(*output) >= now)
+ git_die_config(key, _("Invalid %s: '%s'"), key, *output);
+ }
+ return ret;
+}
+
int git_config_get_untracked_cache(void)
{
int val = -1;
--
2.10.1.462.g7e1e03a
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox