* [PATCH 1/2] fast-export: rename handle_object function
From: Jeff King @ 2013-03-17 8:33 UTC (permalink / raw)
To: git
In-Reply-To: <20130317083235.GA29907@sigill.intra.peff.net>
The handle_object function is rather vaguely named; it only
operates on blobs, and its purpose is to export the blob to
the output stream. Let's call it "export_blob" to make it
more clear what it does.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/fast-export.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 77dffd1..3eba852 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -113,7 +113,7 @@ static void show_progress(void)
printf("progress %d objects\n", counter);
}
-static void handle_object(const unsigned char *sha1)
+static void export_blob(const unsigned char *sha1)
{
unsigned long size;
enum object_type type;
@@ -312,7 +312,7 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)
/* Export the referenced blobs, and remember the marks. */
for (i = 0; i < diff_queued_diff.nr; i++)
if (!S_ISGITLINK(diff_queued_diff.queue[i]->two->mode))
- handle_object(diff_queued_diff.queue[i]->two->sha1);
+ export_blob(diff_queued_diff.queue[i]->two->sha1);
mark_next_object(&commit->object);
if (!is_encoding_utf8(encoding))
@@ -512,7 +512,7 @@ static void get_tags_and_duplicates(struct rev_cmdline_info *info,
commit = (struct commit *)tag;
break;
case OBJ_BLOB:
- handle_object(tag->object.sha1);
+ export_blob(tag->object.sha1);
continue;
default: /* OBJ_TAG (nested tags) is already handled */
warning("Tag points to object of unexpected type %s, skipping.",
--
1.8.2.rc2.7.gef06216
^ permalink raw reply related
* [PATCH 2/2] fast-export: do not load blob objects twice
From: Jeff King @ 2013-03-17 8:38 UTC (permalink / raw)
To: git
In-Reply-To: <20130317083235.GA29907@sigill.intra.peff.net>
When fast-export wants to export a blob object, it first
calls parse_object to get a "struct object" and check
whether we have already shown the object. If we haven't
shown it, we then use read_sha1_file to pull it from disk
and write it out.
That means we load each blob from disk twice: once for
parse_object to find its type and check its sha1, and a
second time when we actually output it. We can drop this to
a single load by using lookup_object to check the SHOWN
flag, and then checking the signature on and outputting a
single buffer.
This provides modest speedups on git.git (best-of-five, "git
fast-export HEAD >/dev/null"):
[before] [after]
real 0m14.347s real 0m13.780s
user 0m14.084s user 0m13.620s
sys 0m0.208s sys 0m0.100s
and somewhat more on more blob-heavy repos (this is a
repository full of media files):
[before] [after]
real 0m52.236s real 0m44.451s
user 0m50.568s user 0m43.000s
sys 0m1.536s sys 0m1.284s
Signed-off-by: Jeff King <peff@peff.net>
---
We actually spend a non-trivial amount of time re-checking the sha1 of
objects we are loading. This change also makes it easy to drop that
checking, though perhaps the additional safety is a good thing to have
during an export. The timings without it are:
git.git (was 14.347s)
real 0m11.452s
user 0m11.336s
sys 0m0.072s
photos (was 44.451s)
real 0m18.383s
user 0m17.108s
sys 0m1.224s
builtin/fast-export.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index 3eba852..d380155 100644
--- a/builtin/fast-export.c
+++ b/builtin/fast-export.c
@@ -119,6 +119,7 @@ static void export_blob(const unsigned char *sha1)
enum object_type type;
char *buf;
struct object *object;
+ int eaten;
if (no_data)
return;
@@ -126,16 +127,18 @@ static void export_blob(const unsigned char *sha1)
if (is_null_sha1(sha1))
return;
- object = parse_object(sha1);
- if (!object)
- die ("Could not read blob %s", sha1_to_hex(sha1));
-
- if (object->flags & SHOWN)
+ object = lookup_object(sha1);
+ if (object && object->flags & SHOWN)
return;
buf = read_sha1_file(sha1, &type, &size);
if (!buf)
die ("Could not read blob %s", sha1_to_hex(sha1));
+ if (check_sha1_signature(sha1, buf, size, typename(type)) < 0)
+ die("sha1 mismatch in blob %s", sha1_to_hex(sha1));
+ object = parse_object_buffer(sha1, type, size, buf, &eaten);
+ if (!object)
+ die("Could not read blob %s", sha1_to_hex(sha1));
mark_next_object(object);
@@ -147,7 +150,8 @@ static void export_blob(const unsigned char *sha1)
show_progress();
object->flags |= SHOWN;
- free(buf);
+ if (!eaten)
+ free(buf);
}
static int depth_first(const void *a_, const void *b_)
--
1.8.2.rc2.7.gef06216
^ permalink raw reply related
* Re: [PATCH 0/3] fix unparsed object access in upload-pack
From: Jeff King @ 2013-03-17 8:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk3p6sg7l.fsf@alter.siamese.dyndns.org>
On Sat, Mar 16, 2013 at 11:17:18PM -0700, Junio C Hamano wrote:
> > I almost wonder if we should cut it out entirely. It is definitely a
> > possible race condition, but I wonder if anybody actually hits it in
> > practice (and if they do, the consequence is that the fetch fails and
> > needs to be retried). As far as I can tell, the code path has never
> > actually been followed, and I do not recall ever seeing a bug report or
> > complaint about it (though perhaps it happened once, which spurred the
> > initial development?).
>
> If you run multiple servers serving the same repository at the same
> URL with a small mirroring lag, one may observe a set of refs from
> one server, that are a tad older than the other server you actually
> fetch from. k.org may have such an arrangement, but does GitHub
> serve the same repository on multiple machines without tying the
> same client to the same backend?
Each repository is a on a single backend host. They're redundant
internally (each host is actually multiple hosts), but pure-git requests
go to a single master for each host (though for some read-only
operations I think we spread the load across the redundant spares). You
might get a separate machine during a failover event, but they share
block devices via DRBD, so in theory an fsync() should hit both
machines, and there is no lag (and you are likely to get an intermittent
failure in such a case, anyway, since the machine serving your git
request probably died mid-packet).
I thought this change was to prevent against the common race:
1. Client request stateless ref advertisement.
2. Somebody updates ref.
3. Client requests "want" objects based on old advertisement.
and I think it does solve that (assuming step 2 is not a rewind). The
important thing is that time always moves forward.
But if you are talking about mirror lag, time can move in either
direction. Imagine you have two machines, A and B, and A is missing an
update to B. If you hit A first, then B, it is the same as the update
sequence above. The patch helps. But if you hit B first, then A, you
will ask it for objects it has not yet received, and we must fail.
So I think any such mirroring setup would want to try very hard to make
sure you hit the same machine both times anyway, regardless of this
patch.
I'm fine to leave it. I was just questioning its utility since AFAICT,
it has never worked and nobody has cared. It's not too much code,
though, and it is only run when we hit the race, so I don't think it is
hurting anything.
-Peff
^ permalink raw reply
* Re: [PATCH] Preallocate hash tables when the number of inserts are known in advance
From: Jeff King @ 2013-03-17 8:51 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1363490886-29729-1-git-send-email-pclouds@gmail.com>
On Sun, Mar 17, 2013 at 10:28:06AM +0700, Nguyen Thai Ngoc Duy wrote:
> This avoids unnecessary re-allocations and reinsertions. On webkit.git
> (i.e. about 182k inserts to the name hash table), this reduces about
> 100ms out of 3s user time.
Good idea.
I had a similar thought when analyzing the hashing behavior of
pack-objects' "Counting objects..." phase, but it had even less impact
there. The insertions are just drowned out by the number of lookups in
that case.
-Peff
^ permalink raw reply
* Re: [PATCH 05/12] pretty: save commit encoding from logmsg_reencode if the caller needs it
From: Eric Sunshine @ 2013-03-17 8:57 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1363400683-14813-6-git-send-email-pclouds@gmail.com>
On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy
<pclouds@gmail.com> wrote:
> The commit encoding is parsed by logmsg_reencode, there's no need for
> the caller to re-parse it again. The reencoded message now have the
s/have/has/
> new encoding, not the original one. The caller would need to read
> commit object again before parsing.
^ permalink raw reply
* Re: [PATCH 09/12] pretty: add %C(auto) for auto-coloring on the next placeholder
From: Eric Sunshine @ 2013-03-17 8:59 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1363400683-14813-10-git-send-email-pclouds@gmail.com>
On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy
<pclouds@gmail.com> wrote:
> This is not simply convenient over $C(auto,xxx). Some placeholders
s/\$/%/
> (actually only one, %d) do multi coloring and we can't emit a multiple
> colors with %C(auto,xxx).
>
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index 66345d1..8734224 100644
> --- a/Documentation/pretty-formats.txt
> +++ b/Documentation/pretty-formats.txt
> @@ -154,7 +154,8 @@ The placeholders are:
> adding `auto,` at the beginning will emit color only when colors are
> enabled for log output (by `color.diff`, `color.ui`, or `--color`, and
> respecting the `auto` settings of the former if we are going to a
> - terminal)
> + terminal). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring
s/auto coloring/auto-coloring/
> + on the following placeholder.
^ permalink raw reply
* Re: [PATCH 10/12] pretty: support padding placeholders, %< %> and %><
From: Eric Sunshine @ 2013-03-17 9:03 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1363400683-14813-11-git-send-email-pclouds@gmail.com>
On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy
<pclouds@gmail.com> wrote:
> Either %<, %> or %<> standing before a placeholder specifies how many
s/%<>/%></
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index 8734224..87ca2c4 100644
> --- a/Documentation/pretty-formats.txt
> +++ b/Documentation/pretty-formats.txt
> @@ -162,6 +162,14 @@ The placeholders are:
> - '%x00': print a byte from a hex code
> - '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of
> linkgit:git-shortlog[1].
> +- '%<(<N>)': make the next placeholder take at least N columns,
> + padding spaces on the right if necessary
> +- '%<|(<N>)': make the next placeholder take at least until Nth
> + columns, padding spaces on the right if necessary
> +- '%>(<N>)', '%>|(<N>)': similar to '%<(<N<)', '%<|(<N<)'
s/<N</<N>/g
> + respectively, but padding spaces on the left
> +- '%><(<N>)', '%><|(<N>)': similar to '%<(<N<)', '%<|(<N<)'
Ditto: s/<N</<N>/g
> + respectively, but padding both sides (i.e. the text is centered)
^ permalink raw reply
* Re: [PATCH 12/12] pretty: support %>> that steal trailing spaces
From: Eric Sunshine @ 2013-03-17 9:06 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1363400683-14813-13-git-send-email-pclouds@gmail.com>
On Fri, Mar 15, 2013 at 10:24 PM, Nguyễn Thái Ngọc Duy
<pclouds@gmail.com> wrote:
> This is pretty useful in `%<(100)%s%Cred%>(20)% an' where %s does not
s/% an/%an/
> use up all 100 columns and %an needs more than 20 columns. By
> replacing %>(20) with %>>(20), %an can steal spaces from %s.
>
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index 17f82f4..036c14a 100644
> --- a/Documentation/pretty-formats.txt
> +++ b/Documentation/pretty-formats.txt
> @@ -170,7 +170,10 @@ The placeholders are:
> columns, padding spaces on the right if necessary
> - '%>(<N>)', '%>|(<N>)': similar to '%<(<N<)', '%<|(<N<)'
> respectively, but padding spaces on the left
> -- '%><(<N>)', '%><|(<N>)': similar to '%<(<N<)', '%<|(<N<)'
> +- '%>>(<N>)', '%>>|(<N>)': similar to '%>(<N<)', '%>|(<N<)'
s/<N</<N>/g
> + respectively, except that if the next placeholder takes more spaces
> + than given and there are spaces on its left, use those spaces
> +- '%><(<N>)', '%><|(<N>)': similar to '% <(<N<)', '%<|(<N<)'
Ditto: s/<N</<N>/g
> respectively, but padding both sides (i.e. the text is centered)
^ permalink raw reply
* Re: [PATCH] sha1_name: pass object name length to diagnose_invalid_sha1_path()
From: René Scharfe @ 2013-03-17 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list, Matthieu Moy
In-Reply-To: <7vzjy2qz6g.fsf@alter.siamese.dyndns.org>
Am 17.03.2013 08:10, schrieb Junio C Hamano:
>> @@ -1158,16 +1159,16 @@ static void diagnose_invalid_sha1_path(const char *prefix,
>> if (!get_tree_entry(tree_sha1, fullname,
>> sha1, &mode)) {
>> die("Path '%s' exists, but not '%s'.\n"
>> - "Did you mean '%s:%s' aka '%s:./%s'?",
>> + "Did you mean '%.*s:%s' aka '.*%.*s:./%s'?",
>
> Will squash an obvious fix in and apply.
Did I try to make a point there? Certainly not. It seems I need to go
back to http://vim-adventures.com/.
Thank you for spotting this!
René
^ permalink raw reply
* Re: [PATCH] gitk: Add user-configurable branch bg color
From: Manuel Bua @ 2013-03-17 12:46 UTC (permalink / raw)
To: David Aguilar; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <CAJDDKr5XqX3dKLEiOAo7VeaofN37Q8aAN=GyMVf5-bGiiv9FDw@mail.gmail.com>
On 03/17/2013 03:57 AM, David Aguilar wrote:
>
> > In some cases, the default branch background color (green) isn't
> > an optimal choice, thus it can be difficult to read.
>
> I'm just curious -- is it "difficult to read" because gitk does not
> specify a foreground color, thus causing it to pickup a system default
> (which can vary), or is it for a different reason?
>
> If this is the reason then I wonder whether gitk should explicitly set
> a foreground color. Apologies if it already works that way -- I just
> wanted to better understand the motivation behind this patch.
>
Yes, having gitk to specify a foreground color instead would probably
solve it too: i can remember the branch rectangles were a lot more
readable in the past, but this could probably be due to me using a dark
system theme at the time.
For example, in my case it would look a lot more readable if the text
was "white on green" instead of "black on green", that could be even
hardcoded as it was with the "green" color, but the reason behind the
choice to let the user customize it is that i think it is better to
honour the user system colors giving the means to adjust it to match his
actual system configuration, rather than overriding it.
Regards,
Manuel
^ permalink raw reply
* [PATCH] combine-diff: coalesce lost lines optimally
From: Antoine Pelisse @ 2013-03-17 13:03 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, Junio C Hamano
In-Reply-To: <7vboalw6lt.fsf@alter.siamese.dyndns.org>
This replaces the greedy implementation to coalesce lost lines by using
dynamic programming to find the Longest Common Subsequence.
The O(n²) time complexity is obviously bigger than previous
implementation but it can produce shorter diff results (and most likely
easier to read).
List of lost lines is now doubly-linked because we reverse-read it when
reading the direction matrix.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
Hi,
This is a very first draft for improving the way we coalesce lost
lines. It has only been tested with the two scenarios below.
What is left to do:
- Test it more extensively
- Had some tests scenarios
I'm also having a hard time trying it with more than two parents. How I
am supposed to have more than two parents while octopus merge refuses if
there are conflicts ?
Tested scenarios:
git init
>test
git add test
git commit -m initial
git checkout -b side1
seq 10 >>test
git commit -m all -a
git checkout master
seq 1 2 10 >test
git commit -m three -a
git merge side1
>test
git commit -m merge -a
git show
AND
git init
>test
git add test
git commit -m initial
echo "3\n1\n2\n4" >test
git commit -m shuffled -a
git checkout -b side HEAD^
echo "1\n2\n3\n4" >test
git commit -m sorted -a
git merge master
>test
git commit -m merge -a
git show
combine-diff.c | 192 ++++++++++++++++++++++++++++++++++++++++++++++----------
1 file changed, 160 insertions(+), 32 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 35d41cd..252dd72 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -73,16 +73,24 @@ static struct combine_diff_path *intersect_paths(struct combine_diff_path *curr,
/* Lines lost from parent */
struct lline {
- struct lline *next;
+ struct lline *next, *prev;
int len;
unsigned long parent_map;
char line[FLEX_ARRAY];
};
+/* Lines lost from current parent (before coalescing) */
+struct plost {
+ struct lline *lost_head, *lost_tail;
+ int len;
+};
+
/* Lines surviving in the merge result */
struct sline {
- struct lline *lost_head, **lost_tail;
- struct lline *next_lost;
+ /* Accumulated and coalesced lost lines */
+ struct lline *lost;
+ int lenlost;
+ struct plost plost;
char *bol;
int len;
/* bit 0 up to (N-1) are on if the parent has this line (i.e.
@@ -94,6 +102,132 @@ struct sline {
unsigned long *p_lno;
};
+enum coalesce_direction { MATCH, BASE, NEW };
+
+/* Coalesce new lines into base by finding LCS */
+static struct lline *coalesce_lines(struct lline *base, int *lenbase,
+ struct lline *new, int lennew,
+ unsigned long parent)
+{
+ int **lcs;
+ enum coalesce_direction **directions;
+ struct lline *baseend, *newend;
+ int i, j, origbaselen = *lenbase;
+
+ if (new == NULL)
+ return base;
+
+ if (base == NULL) {
+ *lenbase = lennew;
+ return new;
+ }
+
+ /*
+ * Coalesce new lines into base by finding the LCS
+ * - Create the table to run dynamic programing
+ * - Compute the LCS
+ * - Then reverse read the direction structure:
+ * - If we have MATCH, assign parent to base flag, and consume
+ * both baseend and newend
+ * - Else if we have BASE, consume baseend
+ * - Else if we have NEW, insert newend lline into base and
+ * consume newend
+ */
+ lcs = xcalloc(origbaselen + 1, sizeof(int*));
+ directions = xcalloc(origbaselen + 1, sizeof(enum coalesce_direction*));
+ for (i = 0; i < origbaselen + 1; i++) {
+ lcs[i] = xcalloc(lennew + 1, sizeof(int));
+ directions[i] = xcalloc(lennew + 1, sizeof(enum coalesce_direction));
+ directions[i][0] = BASE;
+ }
+ for (j = 1; j < lennew + 1; j++)
+ directions[0][j] = NEW;
+
+ for (i = 1, baseend = base; i < origbaselen + 1; i++) {
+ for (j = 1, newend = new; j < lennew + 1; j++) {
+ if (baseend->len == newend->len &&
+ !memcmp(baseend->line, newend->line, baseend->len)) {
+ lcs[i][j] = lcs[i - 1][j - 1] + 1;
+ directions[i][j] = MATCH;
+ } else if (lcs[i][j - 1] >= lcs[i - 1][j]) {
+ lcs[i][j] = lcs[i][j - 1];
+ directions[i][j] = NEW;
+ } else {
+ lcs[i][j] = lcs[i - 1][j];
+ directions[i][j] = BASE;
+ }
+ if (newend->next)
+ newend = newend->next;
+ }
+ if (baseend->next)
+ baseend = baseend->next;
+ }
+
+ for (i = 0; i < origbaselen + 1; i++)
+ free(lcs[i]);
+ free(lcs);
+
+ /* At this point, baseend and newend point to the end of each lists */
+ i--;
+ j--;
+ while (i != 0 || j != 0) {
+ if (directions[i][j] == MATCH) {
+ baseend->parent_map |= 1<<parent;
+ baseend = baseend->prev;
+ newend = newend->prev;
+ i--;
+ j--;
+ } else if (directions[i][j] == NEW) {
+ struct lline *lline;
+
+ lline = newend;
+ /* Remove lline from new list and update newend */
+ if (lline->prev)
+ lline->prev->next = lline->next;
+ else
+ new = lline->next;
+ if (lline->next)
+ lline->next->prev = lline->prev;
+
+ newend = lline->prev;
+ j--;
+
+ /* Add lline to base list */
+ if (baseend) {
+ lline->next = baseend->next;
+ lline->prev = baseend;
+ if (lline->prev)
+ lline->prev->next = lline;
+ }
+ else {
+ lline->next = base;
+ base = lline;
+ }
+ (*lenbase)++;
+
+ if (lline->next)
+ lline->next->prev = lline;
+
+ } else {
+ baseend = baseend->prev;
+ i--;
+ }
+ }
+
+ newend = new;
+ while (newend) {
+ struct lline *lline = newend;
+ newend = newend->next;
+ free(lline);
+ }
+
+ for (i = 0; i < origbaselen + 1; i++)
+ free(directions[i]);
+ free(directions);
+
+ return base;
+}
+
static char *grab_blob(const unsigned char *sha1, unsigned int mode,
unsigned long *size, struct userdiff_driver *textconv,
const char *path)
@@ -129,29 +263,19 @@ static void append_lost(struct sline *sline, int n, const char *line, int len)
if (line[len-1] == '\n')
len--;
- /* Check to see if we can squash things */
- if (sline->lost_head) {
- lline = sline->next_lost;
- while (lline) {
- if (lline->len == len &&
- !memcmp(lline->line, line, len)) {
- lline->parent_map |= this_mask;
- sline->next_lost = lline->next;
- return;
- }
- lline = lline->next;
- }
- }
-
lline = xmalloc(sizeof(*lline) + len + 1);
lline->len = len;
lline->next = NULL;
+ lline->prev = sline->plost.lost_tail;
+ if (lline->prev)
+ lline->prev->next = lline;
+ else
+ sline->plost.lost_head = lline;
+ sline->plost.lost_tail = lline;
+ sline->plost.len++;
lline->parent_map = this_mask;
memcpy(lline->line, line, len);
lline->line[len] = 0;
- *sline->lost_tail = lline;
- sline->lost_tail = &lline->next;
- sline->next_lost = NULL;
}
struct combine_diff_state {
@@ -194,7 +318,6 @@ static void consume_line(void *state_, char *line, unsigned long len)
xcalloc(state->num_parent,
sizeof(unsigned long));
state->sline[state->nb-1].p_lno[state->n] = state->ob;
- state->lost_bucket->next_lost = state->lost_bucket->lost_head;
return;
}
if (!state->lost_bucket)
@@ -255,8 +378,17 @@ static void combine_diff(const unsigned char *parent, unsigned int mode,
struct lline *ll;
sline[lno].p_lno[n] = p_lno;
+ /* Coalesce new lines */
+ if (sline[lno].plost.lost_head) {
+ struct sline *sl = &sline[lno];
+ sl->lost = coalesce_lines(sl->lost, &sl->lenlost,
+ sl->plost.lost_head, sl->plost.len, n);
+ sl->plost.lost_head = sl->plost.lost_tail = NULL;
+ sl->plost.len = 0;
+ }
+
/* How many lines would this sline advance the p_lno? */
- ll = sline[lno].lost_head;
+ ll = sline[lno].lost;
while (ll) {
if (ll->parent_map & nmask)
p_lno++; /* '-' means parent had it */
@@ -276,7 +408,7 @@ static int interesting(struct sline *sline, unsigned long all_mask)
/* If some parents lost lines here, or if we have added to
* some parent, it is interesting.
*/
- return ((sline->flag & all_mask) || sline->lost_head);
+ return ((sline->flag & all_mask) || sline->lost);
}
static unsigned long adjust_hunk_tail(struct sline *sline,
@@ -459,7 +591,7 @@ static int make_hunks(struct sline *sline, unsigned long cnt,
has_interesting = 0;
for (j = i; j < hunk_end && !has_interesting; j++) {
unsigned long this_diff = sline[j].flag & all_mask;
- struct lline *ll = sline[j].lost_head;
+ struct lline *ll = sline[j].lost;
if (this_diff) {
/* This has some changes. Is it the
* same as others?
@@ -613,7 +745,7 @@ static void dump_sline(struct sline *sline, const char *line_prefix,
int j;
unsigned long p_mask;
struct sline *sl = &sline[lno++];
- ll = (sl->flag & no_pre_delete) ? NULL : sl->lost_head;
+ ll = (sl->flag & no_pre_delete) ? NULL : sl->lost;
while (ll) {
printf("%s%s", line_prefix, c_old);
for (j = 0; j < num_parent; j++) {
@@ -664,7 +796,7 @@ static void reuse_combine_diff(struct sline *sline, unsigned long cnt,
jmask = (1UL<<j);
for (lno = 0; lno <= cnt; lno++) {
- struct lline *ll = sline->lost_head;
+ struct lline *ll = sline->lost;
sline->p_lno[i] = sline->p_lno[j];
while (ll) {
if (ll->parent_map & jmask)
@@ -923,10 +1055,6 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
sline = xcalloc(cnt+2, sizeof(*sline));
sline[0].bol = result;
- for (lno = 0; lno <= cnt + 1; lno++) {
- sline[lno].lost_tail = &sline[lno].lost_head;
- sline[lno].flag = 0;
- }
for (lno = 0, cp = result; cp < result + result_size; cp++) {
if (*cp == '\n') {
sline[lno].len = cp - sline[lno].bol;
@@ -976,8 +1104,8 @@ static void show_patch_diff(struct combine_diff_path *elem, int num_parent,
free(result);
for (lno = 0; lno < cnt; lno++) {
- if (sline[lno].lost_head) {
- struct lline *ll = sline[lno].lost_head;
+ if (sline[lno].lost) {
+ struct lline *ll = sline[lno].lost;
while (ll) {
struct lline *tmp = ll;
ll = ll->next;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 4/6] introduce a commit metapack
From: Duy Nguyen @ 2013-03-17 13:21 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20130131110656.GA28093@lanh>
On Thu, Jan 31, 2013 at 6:06 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Wed, Jan 30, 2013 at 09:16:29PM +0700, Duy Nguyen wrote:
>> Perhaps we could store abbrev sha-1 instead of full sha-1. Nice
>> space/time trade-off.
>
> Following the on-disk format experiment yesterday, I changed the
> format to:
>
> - a list a _short_ SHA-1 of cached commits
> ..
>
> The length of SHA-1 is chosen to be able to unambiguously identify any
> cached commits. Full SHA-1 check is done after to catch false
> positives. For linux-2.6, SHA-1 length is 6 bytes, git and many
> moderate-sized projects are 4 bytes.
And if we are going to create index v3, the same trick could be used
for the sha-1 table in the index. We use the short sha-1 table for
binary search and put the rest of sha-1 in a following table (just
like file offset table). The advantage is a denser search space, about
1/4-1/3 the size of full sha-1 table.
--
Duy
^ permalink raw reply
* Make GIT_USE_LOOKUP default?
From: Duy Nguyen @ 2013-03-17 13:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
This env comes from jc/sha1-lookup in 2008 (merge commit e9f9d4f), 5
years ago. I wonder if it's good enough to turn on by default and keep
improving from there, or is it still experimental?
--
Duy
^ permalink raw reply
* Re: [PATCH] combine-diff: coalesce lost lines optimally
From: Antoine Pelisse @ 2013-03-17 13:58 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse, Junio C Hamano
In-Reply-To: <1363525436-21667-1-git-send-email-apelisse@gmail.com>
> I'm also having a hard time trying it with more than two parents. How I
> am supposed to have more than two parents while octopus merge refuses if
> there are conflicts ?
OK, creating the merge commit myself solves the issue:
git init
>test
git add test
git commit -m initial
seq 100 >test
git commit -m all -a
git checkout -b side1 HEAD^1
seq 1 2 100 >test
git commit -m side1 -a
git checkout -b side2 HEAD^1
seq 1 4 100 >test
git commit -m side2 -a
git checkout -b side3 HEAD^1
seq 1 8 100 >test
git commit -m side3 -a
git checkout -b side4 HEAD^1
seq 1 16 100 >test
git commit -m side4 -a
git checkout master
>test
git add test
TREE=$(git write-tree)
COMMIT=$(git commit-tree $TREE -p master -p side1 -p side2 -p side3 -p
side4 -m merge)
git show $COMMIT
This will work with the basic greedy implementation if all parents are
in this order. But the optimal result will be lost if we change the
order of -p parameters in git-commit-tree.
The patch seems to be correct, always finding the best result (we
always have 100 lines diff) whatever the order of parents.
^ permalink raw reply
* [PATCH] safe_create_leading_directories: fix race that could give a false negative
From: Steven Walter @ 2013-03-17 14:09 UTC (permalink / raw)
To: git, gitster; +Cc: Steven Walter
In-Reply-To: <7v7gl6sfsg.fsf@alter.siamese.dyndns.org>
If two processes are racing to create the same directory tree, they will
both see that the directory doesn't exist, both try to mkdir(), and one
of them will fail. This is okay, as we only care that the directory
gets created. So, we add a check for EEXIST from mkdir, and continue if
the directory now exists.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
---
sha1_file.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/sha1_file.c b/sha1_file.c
index 40b2329..5668ecc 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -123,6 +123,15 @@ int safe_create_leading_directories(char *path)
}
}
else if (mkdir(path, 0777)) {
+ if (errno == EEXIST) {
+ /*
+ * We could be racing with another process to
+ * create the directory. As long as the
+ * directory gets created, we don't care.
+ */
+ if (stat(path, &st) && S_ISDIR(st.st_mode))
+ continue;
+ }
*pos = '/';
return -1;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 0/3] fix unparsed object access in upload-pack
From: René Scharfe @ 2013-03-17 16:38 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20130317054039.GA16070@sigill.intra.peff.net>
Am 17.03.2013 06:40, schrieb Jeff King:
> We do have the capability to roll out to one or a few of our servers
> (the granularity is not 0.2%, but it is still small). I'm going to try
> to keep us more in sync with upstream git, but I don't know if I will
> get to the point of ever deploying "master" or "next", even for a small
> portion of the population. We are accumulating more hacks[1] on top of
> git, so it is not just "run master for an hour on this server"; I have
> to actually merge our fork.
Did you perhaps intend to list these hacks in a footnote or link to a
repository containing them? (I can't find the counterpart of that [1].)
René
^ permalink raw reply
* Re: [PATCH/RFC] http_init: only initialize SSL for https
From: Antoine Pelisse @ 2013-03-17 17:41 UTC (permalink / raw)
To: Daniel Stenberg
Cc: Jeff King, Junio C Hamano, Johannes Schindelin, kusmabite, git,
msysgit
In-Reply-To: <alpine.DEB.2.00.1303162355120.21738@tvnag.unkk.fr>
> With redirects taken into account, I can't think of any really good way
> around avoiding this init...
Is there any way for curl to initialize SSL on-demand ?
^ permalink raw reply
* Re: [PATCH] safe_create_leading_directories: fix race that could give a false negative
From: Junio C Hamano @ 2013-03-17 19:45 UTC (permalink / raw)
To: Steven Walter; +Cc: git
In-Reply-To: <1363529367-5919-1-git-send-email-stevenrwalter@gmail.com>
Steven Walter <stevenrwalter@gmail.com> writes:
> If two processes are racing to create the same directory tree, they will
> both see that the directory doesn't exist, both try to mkdir(), and one
> of them will fail. This is okay, as we only care that the directory
> gets created. So, we add a check for EEXIST from mkdir, and continue if
> the directory now exists.
>
> Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
> ---
> sha1_file.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index 40b2329..5668ecc 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -123,6 +123,15 @@ int safe_create_leading_directories(char *path)
> }
> }
> else if (mkdir(path, 0777)) {
> + if (errno == EEXIST) {
> + /*
> + * We could be racing with another process to
> + * create the directory. As long as the
> + * directory gets created, we don't care.
> + */
> + if (stat(path, &st) && S_ISDIR(st.st_mode))
> + continue;
You probably meant !stat() here, "we can successfully stat() and it
turns out that we already have a directory there, so let's not do
the error thing".
Don't you need to restore (*pos = '/') before doing anything else,
like "continue", by the way? We were given "a/b/c", and in order to
make sure "a" exists, we made it to "a\0b/c", did a stat() and found
it was missing, did a mkdir() and now we got EEXIST. pos points at
that NUL, so I would imagine that in order to continue you need to
* restore the string to be "a/b/c"; and
* make pos to point at "b" in the string.
Perhaps something like this instead?
sha1_file.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 9152974..964c4d4 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -122,8 +122,13 @@ int safe_create_leading_directories(char *path)
}
}
else if (mkdir(path, 0777)) {
- *pos = '/';
- return -1;
+ if (errno == EEXIST &&
+ !stat(path, &st) && S_ISDIR(st.st_mode)) {
+ ; /* somebody created it since we checked */
+ } else {
+ *pos = '/';
+ return -1;
+ }
}
else if (adjust_shared_perm(path)) {
*pos = '/';
^ permalink raw reply related
* Re: [PATCH v2 4/4] pack-refs: add fully-peeled trait
From: Junio C Hamano @ 2013-03-17 20:01 UTC (permalink / raw)
To: Jeff King; +Cc: git, Michael Haggerty
In-Reply-To: <20130317082829.GD29550@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> From: Michael Haggerty <mhagger@alum.mit.edu>
>
> Older versions of pack-refs did not write peel lines for
> refs outside of refs/tags. This meant that on reading the
> pack-refs file, we might set the REF_KNOWS_PEELED flag for
> such a ref, even though we do not know anything about its
> peeled value.
>
> The previous commit updated the writer to always peel, no
> matter what the ref is. That means that packed-refs files
> written by newer versions of git are fine to be read by both
> old and new versions of git. However, we still have the
> problem of reading packed-refs files written by older
> versions of git, or by other implementations which have not
> yet learned the same trick.
>
> The simplest fix would be to always unset the
> REF_KNOWS_PEELED flag for refs outside of refs/tags that do
> not have a peel line (if it has a peel line, we know it is
> valid, but we cannot assume a missing peel line means
> anything). But that loses an important optimization, as
> upload-pack should not need to load the object pointed to by
> refs/heads/foo to determine that it is not a tag.
>
> Instead, we add a "fully-peeled" trait to the packed-refs
> file. If it is set, we know that we can trust a missing peel
> line to mean that a ref cannot be peeled. Otherwise, we fall
> back to assuming nothing.
>
> [commit message and tests by Jeff King <peff@peff.net>]
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This uses Michael's approach for managing the flags within
> read_packed_refs, which is more readable. As I picked up his
> code and comments, I realized that there was basically
> nothing of mine left, so I switched the authorship. But do
> note:
>
> 1. It should have Michael's signoff, which was not present
> in the commit I lifted the code from.
>
> 2. I tweaked the big comment above read_packed_refs to
> reduce some ambiguities. Please double-check that I am
> not putting inaccurate words in your mouth. :)
>
> pack-refs.c | 2 +-
> refs.c | 43 +++++++++++++++++++++++++++++++++++++++++--
> t/t3211-peel-ref.sh | 22 ++++++++++++++++++++++
> 3 files changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/pack-refs.c b/pack-refs.c
> index ebde785..4461f71 100644
> --- a/pack-refs.c
> +++ b/pack-refs.c
> @@ -128,7 +128,7 @@ int pack_refs(unsigned int flags)
> die_errno("unable to create ref-pack file structure");
>
> /* perhaps other traits later as well */
> - fprintf(cbdata.refs_file, "# pack-refs with: peeled \n");
> + fprintf(cbdata.refs_file, "# pack-refs with: peeled fully-peeled \n");
>
> for_each_ref(handle_one_ref, &cbdata);
> if (ferror(cbdata.refs_file))
> diff --git a/refs.c b/refs.c
> index 175b9fc..bdeac28 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -803,11 +803,39 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
> return line;
> }
>
> +/*
> + * Read f, which is a packed-refs file, into dir.
> + *
> + * A comment line of the form "# pack-refs with: " may contain zero or
> + * more traits. We interpret the traits as follows:
> + *
> + * No traits:
> + *
> + * Probably no references are peeled. But if the file contains a
> + * peeled value for a reference, we will use it.
> + *
> + * peeled:
> + *
> + * References under "refs/tags/", if they *can* be peeled, *are*
> + * peeled in this file. References outside of "refs/tags/" are
> + * probably not peeled even if they could have been, but if we find
> + * a peeled value for such a reference we will use it.
> + *
> + * fully-peeled:
> + *
> + * All references in the file that can be peeled are peeled.
> + * Inversely (and this is more important, any references in the
A missing closing paren after "more important". Also the e-mail
quote reveals there is some inconsistent indentation (HTs vs runs of
SPs) here.
> + * file for which no peeled value is recorded is not peelable. This
> + * trait should typically be written alongside "fully-peeled" for
Alongside "peeled", no?
> @@ -816,8 +844,10 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
>
> if (!strncmp(refline, header, sizeof(header)-1)) {
> const char *traits = refline + sizeof(header) - 1;
> - if (strstr(traits, " peeled "))
> + if (strstr(traits, " fully-peeled "))
> flag |= REF_KNOWS_PEELED;
> + else if (strstr(traits, " peeled "))
> + refs_tags_peeled = 1;
> /* perhaps other traits later as well */
> continue;
> }
> @@ -825,6 +855,8 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
> refname = parse_ref_line(refline, sha1);
> if (refname) {
> last = create_ref_entry(refname, sha1, flag, 1);
> + if (refs_tags_peeled && !prefixcmp(refname, "refs/tags/"))
> + last->flag |= REF_KNOWS_PEELED;
I am not sure why you find this any more readable.
The "flag" is set earlier to contain REF_KNOWS_PEELED only when we
have fully-peeled trait, and peeled trait is recorded as a separate
local variable. The fully-peeled case sets the flag by passing the
flag to create_ref_entry() but the peeled case adds it to last->flag
manually after the fact.
If you set two local variables when you read the traits (iow, no
futzing with "flag" there), this part would become either:
last = create_ref_entry(refname, sha1, REF_ISPACKED, 1);
if (refs_fully_peeled ||
(refs_tags_peeled && !prefixcmp(refname, "refs/tags/")))
last->flag |= REF_KNOWS_PEELED;
or
flag = REF_ISPACKED;
if (refs_fully_peeled ||
(refs_tags_peeled && !prefixcmp(refname, "refs/tags/")))
flag |= REF_KNOWS_PEELED;
last = create_ref_entry(refname, sha1, flag, 1);
either of which would be much more readable at least to me.
^ permalink raw reply
* Re: [PATCH] git-p4: support exclusively locked files
From: Pete Wyckoff @ 2013-03-17 20:04 UTC (permalink / raw)
To: Danny Thomas; +Cc: git
In-Reply-To: <CD666D0F.1DC6E%danny.thomas@blackboard.com>
Danny.Thomas@blackboard.com wrote on Wed, 13 Mar 2013 13:51 -0400:
> By default, newly added binary files are exclusively locked by Perforce:
>
> 'add default change (binary+l) *exclusive*'
>
> This results in a 'Could not determine file type' error as the regex
> expects
> the line to end after the file type matching group. Some repositories are
> also configured to always require exclusive locks, so may be a problem for
> all revisions in some cases.
Can you explain how to configure p4d to default everything to
binary+l? Also, what version are you using ("p4 info")? I'm
trying to write a test case for this.
I did find a way to play with typemap to get +l, as:
( p4 typemap -o ; printf "\tbinary+l\t//.../bash*" ) | p4 typemap -i
With this, the 2011.1 here just says:
tic-git-test$ p4 opened bash
//depot/bash#1 - add default change (binary+l)
I've not been able to make it say " *exclusive*" too.
> result = p4_read_pipe(["opened", wildcard_encode(file)])
> - match = re.match(".*\((.+)\)\r?$", result)
> + match = re.match(".*\((.+)\)(?:.+)?\r?$", result)
I think this whole function would be less brittle
using p4's "-G" output, like:
d = p4Cmd(["fstat", "-T", "type", wildcard_encode(file)])
# some error checking
return d['type']
But I'm curious if your p4d includes " *exclusive*" in the
type there too, in which case we'll have to strip it.
Thanks for starting the patch on this. It's good if we can keep
others from running into the same problem.
-- Pete
^ permalink raw reply
* Re: [PATCH] combine-diff: coalesce lost lines optimally
From: Junio C Hamano @ 2013-03-17 20:10 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <1363525436-21667-1-git-send-email-apelisse@gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> This replaces the greedy implementation to coalesce lost lines by using
> dynamic programming to find the Longest Common Subsequence.
>
> The O(n²) time complexity is obviously bigger than previous
> implementation but it can produce shorter diff results (and most likely
> easier to read).
>
> List of lost lines is now doubly-linked because we reverse-read it when
> reading the direction matrix.
>
> Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
> ---
> Hi,
> This is a very first draft for improving the way we coalesce lost
> lines. It has only been tested with the two scenarios below.
>
> What is left to do:
> - Test it more extensively
> - Had some tests scenarios
>
> I'm also having a hard time trying it with more than two parents. How I
> am supposed to have more than two parents while octopus merge refuses if
> there are conflicts ?
9fdb62af92c7 ([ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica
asus fops pnpacpi branches into release, 2006-01-24) is one of the
amusing examples ;-) Cf.
http://thread.gmane.org/gmane.comp.version-control.git/15486
^ permalink raw reply
* Re: Make GIT_USE_LOOKUP default?
From: Junio C Hamano @ 2013-03-17 20:13 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Git Mailing List
In-Reply-To: <CACsJy8AihriCDfN=cz7FjdHzZAhnPPGML_w8yWcVVrmTQLZyjw@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> This env comes from jc/sha1-lookup in 2008 (merge commit e9f9d4f), 5
> years ago. I wonder if it's good enough to turn on by default and keep
> improving from there, or is it still experimental?
The algorithm has been used in production in other codepaths like
patch-ids and replace-object, so correctness-wise it should be fine
to turn it on. I think nobody has bothered to benchmark with and
without the environment to see if it is really worth the complexity.
It may be a good idea to try doing so, now you have noticed it ;-).
^ permalink raw reply
* Re: [PATCH] combine-diff: coalesce lost lines optimally
From: Antoine Pelisse @ 2013-03-17 20:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhak9rdne.fsf@alter.siamese.dyndns.org>
Hopefully, my patch takes about the same time as git 1.7.9.5 and
produces the same output on that commit ;)
Unfortunately on a commit that would remove A LOT of lines (10000)
from 7 parents, the times goes from 0.01s to 1.5s... I'm pretty sure
that scenario is quite uncommon though.
On Sun, Mar 17, 2013 at 9:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>> This replaces the greedy implementation to coalesce lost lines by using
>> dynamic programming to find the Longest Common Subsequence.
>>
>> The O(n²) time complexity is obviously bigger than previous
>> implementation but it can produce shorter diff results (and most likely
>> easier to read).
>>
>> List of lost lines is now doubly-linked because we reverse-read it when
>> reading the direction matrix.
>>
>> Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
>> ---
>> Hi,
>> This is a very first draft for improving the way we coalesce lost
>> lines. It has only been tested with the two scenarios below.
>>
>> What is left to do:
>> - Test it more extensively
>> - Had some tests scenarios
>>
>> I'm also having a hard time trying it with more than two parents. How I
>> am supposed to have more than two parents while octopus merge refuses if
>> there are conflicts ?
>
> 9fdb62af92c7 ([ACPI] merge 3549 4320 4485 4588 4980 5483 5651 acpica
> asus fops pnpacpi branches into release, 2006-01-24) is one of the
> amusing examples ;-) Cf.
>
> http://thread.gmane.org/gmane.comp.version-control.git/15486
^ permalink raw reply
* [PATCH] remote.<name>.pushurl does not consider aliases when pushing
From: Rob Hoelz @ 2013-03-17 21:40 UTC (permalink / raw)
To: git; +Cc: josh
Hi everyone! I found a bug in Git today and wrote up a fix; I did my best to conform to the rules layed out in Documentation/SubmittingPatches, but please let me know if I need to change anything to get my work merged. =) I have CC'ed Josh Triplet, as
he was the last one to touch the line I modified. I hope my commit messages explain the problem I encountered well enough; if not,
I can always go back and amend them.
Patches follow.
-Rob
>From 5007b11e86c0835807632cb41e6cfa75ce9a1aa1 Mon Sep 17 00:00:00 2001
From: Rob Hoelz <rob@hoelz.ro>
Date: Sun, 17 Mar 2013 21:49:20 +0100
Subject: [PATCH 1/2] Add test for pushInsteadOf + pushurl
git push currently doesn't consider pushInsteadOf when
using pushurl; this test tests that.
Signed-off-by: Rob Hoelz <rob@hoelz.ro>
---
t/t5500-push-pushurl.sh | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
create mode 100644 t/t5500-push-pushurl.sh
diff --git a/t/t5500-push-pushurl.sh b/t/t5500-push-pushurl.sh
new file mode 100644
index 0000000..74d4ff6
--- /dev/null
+++ b/t/t5500-push-pushurl.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+#
+# Copyright (c) 2013 Rob Hoelz
+#
+
+test_description='Test that remote.<name>.pushurl uses pushInsteadOf'
+. ./test-lib.sh
+
+wd=$(pwd)
+test_expect_success 'setup test repositories' '
+ mkdir ro &&
+ mkdir rw &&
+
+ git init --bare ro/repo &&
+ git init --bare rw/repo &&
+ git init test-repo
+'
+
+test_expect_success 'setup remote config' "
+ cd test-repo &&
+ git config 'url.file://$wd/ro/.insteadOf' herero: &&
+ git config 'url.file://$wd/rw/.pushInsteadOf' hererw: &&
+ git remote add origin herero:repo &&
+ git config remote.origin.pushurl hererw:repo
+"
+
+test_expect_success 'test commit and push' '
+ test_commit one &&
+ git push origin master:master
+'
+
+test_expect_success 'check for commits in rw repo' '
+ cd ../rw/repo &&
+ git log --pretty=oneline | grep -q .
+'
+
+test_done
--
1.8.2
>From 0cbd1aab6bdc0c2f8893ed8b9a8e3eb0126917d1 Mon Sep 17 00:00:00 2001
From: Rob Hoelz <rob@hoelz.ro>
Date: Sun, 17 Mar 2013 16:34:35 +0100
Subject: [PATCH 2/2] push: Alias pushurl from push rewrites
If you use pushurl with an alias that has a pushInsteadOf configuration
value, Git does not take advantage of it. For example:
[url "git://github.com/"]
insteadOf = github:
[url "git://github.com/myuser/"]
insteadOf = mygithub:
[url "git@github.com:myuser/"]
pushInsteadOf = mygithub:
[remote "origin"]
url = github:organization/project
pushurl = mygithub:project
This commit fixes that.
Signed-off-by: Rob Hoelz <rob@hoelz.ro>
---
remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index ca1f8f2..de7a915 100644
--- a/remote.c
+++ b/remote.c
@@ -465,7 +465,7 @@ static void alias_all_urls(void)
if (!remotes[i])
continue;
for (j = 0; j < remotes[i]->pushurl_nr; j++) {
- remotes[i]->pushurl[j] = alias_url(remotes[i]->pushurl[j], &rewrites);
+ remotes[i]->pushurl[j] = alias_url(remotes[i]->pushurl[j], &rewrites_push);
}
add_pushurl_aliases = remotes[i]->pushurl_nr == 0;
for (j = 0; j < remotes[i]->url_nr; j++) {
--
1.8.2
^ permalink raw reply related
* Re: [PATCH v1 11/45] parse_pathspec: support stripping submodule trailing slashes
From: Junio C Hamano @ 2013-03-17 21:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1363327620-29017-12-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This flag is equivalent to builtin/ls-files.c:strip_trailing_slashes()
> and is intended to replace that function when ls-files is converted to
> use parse_pathspec.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> pathspec.c | 9 +++++++++
> pathspec.h | 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/pathspec.c b/pathspec.c
> index b2446c3..2da8bc9 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -204,6 +204,15 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
> *raw = item->match = match;
> item->original = elt;
> item->len = strlen(item->match);
> +
> + if ((flags & PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP) &&
I see that having cheap and expensive variant at these steps is a
way to achieve a bug-for-bug compatible rewrite of the existing
code, but in the longer term should we lose one of them? After all,
a path that points at the working tree of another repository that is
beyond a symlink cannot be added to us as a submodule, so CHEAP can
be used only when we know that any intermediate component on the
path is not a symlink pointing elsewhere, and the user in the
codepath of ls-files may know it.
To put it differently, shouldn't CHEAP and EXPENSIVE be accompanied
by in-code comment and updates to Documentation/technical/api-*.txt
to help users of the API to decide which one to use?
^ permalink raw reply
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