* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Junio C Hamano @ 2008-07-15 22:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Geoffrey Irving, git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0807152255020.2990@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Okay, it seems like I never have time to review this, so I'll just
> take a few minutes to comment on some aspects:
>
>> @@ -1094,6 +1104,8 @@ int cmd_cherry(int argc, const char **argv,
>> const char *prefix)
>> const char *limit = NULL;
>> int verbose = 0;
>>
>> + git_config(git_cherry_config, NULL);
>> +
>> if (argc > 1 && !strcmp(argv[1], "-v")) {
>> verbose = 1;
>> argc--;
>
> Is this really purely for cherry, and not at all for "log --cherry-pick"?
> Maybe it should be "cache.patchIds" to begin with.
What other things would we want caches for?
As a general rule, I'd prefer keeping these unproven new features opt
in (i.e. default to false unless explicitly asked for).
>> +union cached_sha1_map_header {
>> + struct {
>> + char signature[4]; /* CS1M */
>> + uint32_t version;
>> + uint32_t count;
>> + uint32_t size;
>> + uint32_t pad; /* pad to 20 bytes */
>> + } u;
>> + /* pad header out to 40 bytes. As a consistency
>> + * check, pad.value stores the sha1 of pad.key. */
>> + struct cached_sha1_entry pad;
>
> Why does it have to be a union?
Hmm. I think you are right.
struct cached_sha1_map_header {
char signature[4];
uint32_t version;
uint32_t count;
uint32_t size;
uint32_t unused;
unsigned char csum[20];
};
would equally be good, as long as we assume the struct is naturally
packed. I do agree with you that it may not worth checking only the
header, though.
>> +static const char *signature = "CS1M";
>
> Carrie Scr*ws 1 Man?
No Idea ;-)
>> + cache->mmapped = 0;
>> + cache->dirty = 1;
>
> Is it already dirty? I don't think so.
This flag is more about "do we need to write it back to file", and when it
starts out without reading from an existing file, we always need to as
long as the table contains something at the end of the processing.
You could instead check (!cache->mmapped && cache->count) for that, I
guess.
>> + cache->entries = calloc(size, sizeof(struct cached_sha1_entry));
>> + if (!cache->entries) {
>> + warning("failed to allocate empty map of size %"PRIu32" for %s",
>> + size, git_path(cache->filename));
>
> xcalloc() to the rescue.
This is purely optional cache and we would want to degrade to operate
without it if any of these fails. xcalloc() won't let you do so.
> Really, I think that these checks should be _made_ unnecessary, by
> restricting the size of the cache. IMO Caching more than 2^10 patch ids
> (completely made up on the spot) is probably even detrimental, and it
> might be better to just scratch them all and start with a new cache then.
Probably. Or fall back on uncached operation.
>> +static int init_cached_sha1_map(struct cached_sha1_map *cache)
>> +{
>>
>> [...]
>>
>> + SHA1_Init(&ctx);
>> + SHA1_Update(&ctx, header.pad.key, 20);
>> + SHA1_Final(header.pad.key, &ctx); /* reuse pad.key to store its sha1 */
>> + if (hashcmp(header.pad.key, header.pad.value)) {
>> + warning("%s header has invalid sha1", filename);
>> + goto empty;
>> + }
>
> I do not think that it is worth checking that. If you do not trust your
> hard disk, you might just as well jump out the window.
>
> Checking just takes too much time.
This is only checking the header, so it won't take much time, but I tend
to doubt the value of this.
>> + /* mmap entire file so that file / memory blocks are aligned */
>> + map_size = sizeof(struct cached_sha1_entry) * (cache->size + 1);
>> + cache->entries = mmap(NULL, map_size,
>> + PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
>
> AFAIR there were _serious_ performance issues with mmap() on non-Linux
> platforms. I chose pread() in my original implementation for a reason.
That is not a reason to punish users on platforms with working mmap(2) ;-).
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Johannes Schindelin @ 2008-07-15 22:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Dmitry Potapov, Petr Baudis, Nicolas Pitre, Gerrit Pape, git
In-Reply-To: <7v3amb0ymg.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 15 Jul 2008, Junio C Hamano wrote:
> What troubles me the most is that you seem to be forgetting that we are
> using git to manage our codebase.
I don't. I have vivid memories of updating an ancient git repository of
Git itself, which had some almost forgotten changes in it. That was in
the bad old days, when the version number did not even have a "1" in it.
It could not even fetch the current git.git.
I do _not_ want that to happen to anybody else, _even if_ we leave 1.4.4.4
Behind as if it was an American Child.
Having said that, I do not have the resources to test and fix everything
that may arise from Debian being seemingly unable to update to Git 1.5.
So I agree completely that the ball is in Debian's half, and if they let
it rot, it is sad, but I cannot help it.
Ciao,
Dscho
^ permalink raw reply
* [RFC/PATCH 1/2 (No Wrap)] Avoid rescanning unchanged entries in search for copies.
From: Alexander Gavrilov @ 2008-07-15 22:05 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200807160159.56228.angavrilov@gmail.com>
Repeatedly comparing the same entry against the same set
of blobs in search for copies is quite pointless. This
huge waste of effort can be avoided using a flag in
the blame_entry structure.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
I'm terribly sorry, word wrap was turned on. I disabled it permanently.
-- Alexander
builtin-blame.c | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index b451f6c..a6cf6b6 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -161,6 +161,10 @@ struct blame_entry {
*/
char guilty;
+ /* true if the entry has been scanned for copies in the current parent
+ */
+ char scanned;
+
/* the line number of the first line of this group in the
* suspect's file; internally all line numbers are 0 based.
*/
@@ -1048,12 +1052,12 @@ static struct blame_list *setup_blame_list(struct scoreboard *sb,
struct blame_list *blame_list = NULL;
for (e = sb->ent, num_ents = 0; e; e = e->next)
- if (!e->guilty && same_suspect(e->suspect, target))
+ if (!e->scanned && !e->guilty && same_suspect(e->suspect, target))
num_ents++;
if (num_ents) {
blame_list = xcalloc(num_ents, sizeof(struct blame_list));
for (e = sb->ent, i = 0; e; e = e->next)
- if (!e->guilty && same_suspect(e->suspect, target))
+ if (!e->scanned && !e->guilty && same_suspect(e->suspect, target))
blame_list[i++].ent = e;
}
*num_ents_p = num_ents;
@@ -1061,6 +1065,16 @@ static struct blame_list *setup_blame_list(struct scoreboard *sb,
}
/*
+ * Reset the scanned status on all entries.
+ */
+static void reset_scanned_flag(struct scoreboard *sb)
+{
+ struct blame_entry *e;
+ for (e = sb->ent; e; e = e->next)
+ e->scanned = 0;
+}
+
+/*
* For lines target is suspected for, see if we can find code movement
* across file boundary from the parent commit. porigin is the path
* in the parent we already tried.
@@ -1152,6 +1166,8 @@ static int find_copy_in_parent(struct scoreboard *sb,
split_blame(sb, split, blame_list[j].ent);
made_progress = 1;
}
+ else
+ blame_list[j].ent->scanned = 1;
decref_split(split);
}
free(blame_list);
@@ -1164,6 +1180,7 @@ static int find_copy_in_parent(struct scoreboard *sb,
break;
}
}
+ reset_scanned_flag(sb);
diff_flush(&diff_opts);
diff_tree_release_paths(&diff_opts);
return retval;
--
1.5.6.2.39.gd084
^ permalink raw reply related
* [RFC/PATCH 2/2] Do not try to detect move/copy for entries below threshold.
From: Alexander Gavrilov @ 2008-07-15 22:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200807160159.56228.angavrilov@gmail.com>
Splits for such entries are rejected anyway, so there is no
point even trying to compute them.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
builtin-blame.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index a6cf6b6..01453e2 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -1020,7 +1020,8 @@ static int find_move_in_parent(struct scoreboard *sb,
while (made_progress) {
made_progress = 0;
for (e = sb->ent; e; e = e->next) {
- if (e->guilty || !same_suspect(e->suspect, target))
+ if (e->guilty || !same_suspect(e->suspect, target) ||
+ blame_move_score >= ent_score(sb, e))
continue;
find_copy_in_blob(sb, e, parent, split, &file_p);
if (split[1].suspect &&
@@ -1045,6 +1046,7 @@ struct blame_list {
*/
static struct blame_list *setup_blame_list(struct scoreboard *sb,
struct origin *target,
+ int min_score,
int *num_ents_p)
{
struct blame_entry *e;
@@ -1052,12 +1054,16 @@ static struct blame_list *setup_blame_list(struct scoreboard *sb,
struct blame_list *blame_list = NULL;
for (e = sb->ent, num_ents = 0; e; e = e->next)
- if (!e->scanned && !e->guilty && same_suspect(e->suspect, target))
+ if (!e->scanned && !e->guilty &&
+ same_suspect(e->suspect, target) &&
+ ent_score(sb, e) > min_score)
num_ents++;
if (num_ents) {
blame_list = xcalloc(num_ents, sizeof(struct blame_list));
for (e = sb->ent, i = 0; e; e = e->next)
- if (!e->scanned && !e->guilty && same_suspect(e->suspect, target))
+ if (!e->scanned && !e->guilty &&
+ same_suspect(e->suspect, target) &&
+ ent_score(sb, e) > min_score)
blame_list[i++].ent = e;
}
*num_ents_p = num_ents;
@@ -1092,7 +1098,7 @@ static int find_copy_in_parent(struct scoreboard *sb,
struct blame_list *blame_list;
int num_ents;
- blame_list = setup_blame_list(sb, target, &num_ents);
+ blame_list = setup_blame_list(sb, target, blame_copy_score, &num_ents);
if (!blame_list)
return 1; /* nothing remains for this target */
@@ -1174,7 +1180,7 @@ static int find_copy_in_parent(struct scoreboard *sb,
if (!made_progress)
break;
- blame_list = setup_blame_list(sb, target, &num_ents);
+ blame_list = setup_blame_list(sb, target, blame_copy_score, &num_ents);
if (!blame_list) {
retval = 1;
break;
--
1.5.6.2.39.gd084
^ permalink raw reply related
* [RFC/PATCH 1/2] Avoid rescanning unchanged entries in search for copies.
From: Alexander Gavrilov @ 2008-07-15 21:59 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200807160158.34994.angavrilov@gmail.com>
Repeatedly comparing the same entry against the same set
of blobs in search for copies is quite pointless. This
huge waste of effort can be avoided using a flag in
the blame_entry structure.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
builtin-blame.c | 21 +++++++++++++++++++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index b451f6c..a6cf6b6 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -161,6 +161,10 @@ struct blame_entry {
*/
char guilty;
+ /* true if the entry has been scanned for copies in the current parent
+ */
+ char scanned;
+
/* the line number of the first line of this group in the
* suspect's file; internally all line numbers are 0 based.
*/
@@ -1048,12 +1052,12 @@ static struct blame_list *setup_blame_list(struct
scoreboard *sb,
struct blame_list *blame_list = NULL;
for (e = sb->ent, num_ents = 0; e; e = e->next)
- if (!e->guilty && same_suspect(e->suspect, target))
+ if (!e->scanned && !e->guilty && same_suspect(e->suspect, target))
num_ents++;
if (num_ents) {
blame_list = xcalloc(num_ents, sizeof(struct blame_list));
for (e = sb->ent, i = 0; e; e = e->next)
- if (!e->guilty && same_suspect(e->suspect, target))
+ if (!e->scanned && !e->guilty && same_suspect(e->suspect, target))
blame_list[i++].ent = e;
}
*num_ents_p = num_ents;
@@ -1061,6 +1065,16 @@ static struct blame_list *setup_blame_list(struct
scoreboard *sb,
}
/*
+ * Reset the scanned status on all entries.
+ */
+static void reset_scanned_flag(struct scoreboard *sb)
+{
+ struct blame_entry *e;
+ for (e = sb->ent; e; e = e->next)
+ e->scanned = 0;
+}
+
+/*
* For lines target is suspected for, see if we can find code movement
* across file boundary from the parent commit. porigin is the path
* in the parent we already tried.
@@ -1152,6 +1166,8 @@ static int find_copy_in_parent(struct scoreboard *sb,
split_blame(sb, split, blame_list[j].ent);
made_progress = 1;
}
+ else
+ blame_list[j].ent->scanned = 1;
decref_split(split);
}
free(blame_list);
@@ -1164,6 +1180,7 @@ static int find_copy_in_parent(struct scoreboard *sb,
break;
}
}
+ reset_scanned_flag(sb);
diff_flush(&diff_opts);
diff_tree_release_paths(&diff_opts);
return retval;
--
1.5.6.2.39.gd084
^ permalink raw reply related
* [RFC/PATCH 0/2] Enhance performance of blame -C -C
From: Alexander Gavrilov @ 2008-07-15 21:58 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This pair of patches aims at increasing performance of copy detection in blame
by avoiding unnecessary comparisons. Note that since I'm new to this code, I
might have misunderstood something.
There are two cases than I aim to fix:
1) Copy detection is done by comparing all outstanding chunks of the target file
to all blobs in the parent. After that, chunks with suitable matches are split, and
comparison is repeated again, until there are no new matches. The trouble is,
chunks that didn't match the first time, and weren't split, are compared against
the same set of blobs again and again. I add a flag to track that.
On my test case it decreased blame -C -C time from over 10min to ~6min; 4min with -C80.
2) Chunks are split only if the match scores above a certain threshold. I understand
that a split of an entry cannot score more than the entry itself. Thus, it is pointless
to even try doing costly comparisons for small entries.
(Time goes down to 4min; 2min with -C80)
Alexander Gavrilov (2):
Avoid rescanning unchanged entries in search for copies.
Do not try to detect move/copy for entries below threshold.
builtin-blame.c | 33 ++++++++++++++++++++++++++++-----
1 files changed, 28 insertions(+), 5 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index b451f6c..01453e2 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -161,6 +161,10 @@ struct blame_entry {
*/
char guilty;
+ /* true if the entry has been scanned for copies in the current parent
+ */
+ char scanned;
+
/* the line number of the first line of this group in the
* suspect's file; internally all line numbers are 0 based.
*/
@@ -1016,7 +1020,8 @@ static int find_move_in_parent(struct scoreboard *sb,
while (made_progress) {
made_progress = 0;
for (e = sb->ent; e; e = e->next) {
- if (e->guilty || !same_suspect(e->suspect, target))
+ if (e->guilty || !same_suspect(e->suspect, target) ||
+ blame_move_score >= ent_score(sb, e))
continue;
find_copy_in_blob(sb, e, parent, split, &file_p);
if (split[1].suspect &&
@@ -1041,6 +1046,7 @@ struct blame_list {
*/
static struct blame_list *setup_blame_list(struct scoreboard *sb,
struct origin *target,
+ int min_score,
int *num_ents_p)
{
struct blame_entry *e;
@@ -1048,12 +1054,16 @@ static struct blame_list *setup_blame_list(struct scoreboard *sb,
struct blame_list *blame_list = NULL;
for (e = sb->ent, num_ents = 0; e; e = e->next)
- if (!e->guilty && same_suspect(e->suspect, target))
+ if (!e->scanned && !e->guilty &&
+ same_suspect(e->suspect, target) &&
+ ent_score(sb, e) > min_score)
num_ents++;
if (num_ents) {
blame_list = xcalloc(num_ents, sizeof(struct blame_list));
for (e = sb->ent, i = 0; e; e = e->next)
- if (!e->guilty && same_suspect(e->suspect, target))
+ if (!e->scanned && !e->guilty &&
+ same_suspect(e->suspect, target) &&
+ ent_score(sb, e) > min_score)
blame_list[i++].ent = e;
}
*num_ents_p = num_ents;
@@ -1061,6 +1071,16 @@ static struct blame_list *setup_blame_list(struct scoreboard *sb,
}
/*
+ * Reset the scanned status on all entries.
+ */
+static void reset_scanned_flag(struct scoreboard *sb)
+{
+ struct blame_entry *e;
+ for (e = sb->ent; e; e = e->next)
+ e->scanned = 0;
+}
+
+/*
* For lines target is suspected for, see if we can find code movement
* across file boundary from the parent commit. porigin is the path
* in the parent we already tried.
@@ -1078,7 +1098,7 @@ static int find_copy_in_parent(struct scoreboard *sb,
struct blame_list *blame_list;
int num_ents;
- blame_list = setup_blame_list(sb, target, &num_ents);
+ blame_list = setup_blame_list(sb, target, blame_copy_score, &num_ents);
if (!blame_list)
return 1; /* nothing remains for this target */
@@ -1152,18 +1172,21 @@ static int find_copy_in_parent(struct scoreboard *sb,
split_blame(sb, split, blame_list[j].ent);
made_progress = 1;
}
+ else
+ blame_list[j].ent->scanned = 1;
decref_split(split);
}
free(blame_list);
if (!made_progress)
break;
- blame_list = setup_blame_list(sb, target, &num_ents);
+ blame_list = setup_blame_list(sb, target, blame_copy_score, &num_ents);
if (!blame_list) {
retval = 1;
break;
}
}
+ reset_scanned_flag(sb);
diff_flush(&diff_opts);
diff_tree_release_paths(&diff_opts);
return retval;
^ permalink raw reply related
* MSysGit Stability
From: Joe Fiorini @ 2008-07-15 21:58 UTC (permalink / raw)
To: git
Hey all,
I'm going to be working with a small dev shop in the near future and
we would like to use Git for our project. Two of us are on Macs, but
the other is on Windows. I know the options are MSysGit or Git
through cygwin. I'm curious which is better to use and if MSysGit is
even stable yet. Does anyone have experience running Git on Windows?
Any experiences you can share? Is MSysGit ready yet or should we
wait?
Thanks all!
Joe
--
joe fiorini
http://www.faithfulgeek.org
// freelancing & knowledge sharing
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johannes Schindelin @ 2008-07-15 21:52 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <7f9d599f0807150957o78d46204x280668c763fba2bf@mail.gmail.com>
Hi,
Okay, it seems like I never have time to review this, so I'll just
take a few minutes to comment on some aspects:
On Tue, 15 Jul 2008, Geoffrey Irving wrote:
> +static int git_cherry_config(const char *var, const char *value, void *cb)
> +{
> + if (!strcmp(var, "cherry.cachepatchids")) {
> + cache_patch_ids = git_config_bool(var, value);
> + return 0;
> + }
> +
> + return 0;
> +}
> +
> static const char cherry_usage[] =
> "git-cherry [-v] <upstream> [<head>] [<limit>]";
> int cmd_cherry(int argc, const char **argv, const char *prefix)
> @@ -1094,6 +1104,8 @@ int cmd_cherry(int argc, const char **argv,
> const char *prefix)
> const char *limit = NULL;
> int verbose = 0;
>
> + git_config(git_cherry_config, NULL);
> +
> if (argc > 1 && !strcmp(argv[1], "-v")) {
> verbose = 1;
> argc--;
Is this really purely for cherry, and not at all for "log --cherry-pick"?
Maybe it should be "cache.patchIds" to begin with.
> diff --git a/cached-sha1-map.c b/cached-sha1-map.c
> new file mode 100644
> index 0000000..9cf7252
> --- /dev/null
> +++ b/cached-sha1-map.c
> @@ -0,0 +1,293 @@
> +#include "cached-sha1-map.h"
> +
> +union cached_sha1_map_header {
> + struct {
> + char signature[4]; /* CS1M */
> + uint32_t version;
> + uint32_t count;
> + uint32_t size;
> + uint32_t pad; /* pad to 20 bytes */
> + } u;
> + /* pad header out to 40 bytes. As a consistency
> + * check, pad.value stores the sha1 of pad.key. */
> + struct cached_sha1_entry pad;
Why does it have to be a union?
> +};
> +
> +static const char *signature = "CS1M";
Carrie Scr*ws 1 Man?
> +static int init_empty_map(struct cached_sha1_map *cache, uint32_t size)
> +{
> + cache->count = 0;
> + cache->size = size;
We seem to call this "alloc" (almost) everywhere else.
> + cache->initialized = 1;
Maybe we do not need that: when size is != 0, it was initialized.
> + cache->mmapped = 0;
> + cache->dirty = 1;
Is it already dirty? I don't think so.
> + cache->entries = calloc(size, sizeof(struct cached_sha1_entry));
> + if (!cache->entries) {
> + warning("failed to allocate empty map of size %"PRIu32" for %s",
> + size, git_path(cache->filename));
xcalloc() to the rescue.
> +static int grow_map(struct cached_sha1_map *cache)
> +{
> + struct cached_sha1_map new_cache;
> + uint32_t i;
> +
> + if (cache->size * 2 == 0) {
> + warning("%s overflowed, so resetting to empty",
> + git_path(cache->filename));
IMHO we can safely ignore that case: If that is true, we have seen at
least 2^32 objects. However, each object takes more than 4 bytes, so that
is a literal impossibility.
I'd rather not bother with this case.
> + /* allocate cache with twice the size */
> + new_cache.filename = cache->filename;
> + if (init_empty_map(&new_cache, cache->size * 2)) {
Really, I think that these checks should be _made_ unnecessary, by
restricting the size of the cache. IMO Caching more than 2^10 patch ids
(completely made up on the spot) is probably even detrimental, and it
might be better to just scratch them all and start with a new cache then.
Besides, the file would have a substantial size by then.
> +static int init_cached_sha1_map(struct cached_sha1_map *cache)
> +{
>
> [...]
>
> + SHA1_Init(&ctx);
> + SHA1_Update(&ctx, header.pad.key, 20);
> + SHA1_Final(header.pad.key, &ctx); /* reuse pad.key to store its sha1 */
> + if (hashcmp(header.pad.key, header.pad.value)) {
> + warning("%s header has invalid sha1", filename);
> + goto empty;
> + }
I do not think that it is worth checking that. If you do not trust your
hard disk, you might just as well jump out the window.
Checking just takes too much time.
> + /* mmap entire file so that file / memory blocks are aligned */
> + map_size = sizeof(struct cached_sha1_entry) * (cache->size + 1);
> + cache->entries = mmap(NULL, map_size,
> + PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
AFAIR there were _serious_ performance issues with mmap() on non-Linux
platforms. I chose pread() in my original implementation for a reason.
> +static int32_t find_helper(struct cached_sha1_map *cache,
> + const unsigned char *key)
> +{
> + int32_t i, mask, full;
> +
> + mask = cache->size - 1;
> + i = get_hash_index(key) & mask;
> + full = (i-1) & mask;
> +
> + for (; ; i = (i+1) & mask) {
Wow, that is ugly.
> +struct cached_sha1_map {
> + const char *filename; /* relative to GIT_DIR */
Why does the map need to know its name? The index does not.
> +static struct diff_options default_options;
> +#define IGNORED_DIFF_OPTS (DIFF_OPT_HAS_CHANGES | DIFF_OPT_CHECK_FAILED)
>
> static int commit_patch_id(struct commit *commit, struct diff_options *options,
> unsigned char *sha1)
> {
> + int use_cache = 0;
> + int ret;
> +
> + /* only cache if diff options are defaults */
> + if (cache_patch_ids) {
> + default_options.found_changes = options->found_changes;
> + default_options.flags = (options->flags & IGNORED_DIFF_OPTS)
> + | (default_options.flags & ~IGNORED_DIFF_OPTS);
> + use_cache = !memcmp(options, &default_options,
> + sizeof(struct diff_options));
> + }
Hmm.
I'd rather set "revs.diff" late, and unset "cache_patch_ids" if it is set.
IOW let the rev_opt parser decide.
Unfortunately, I do not have time to look into your patch in more detail,
even if I like the idea.
Ciao,
Dscho
^ permalink raw reply
* Re: git-mergetool + WinMerge
From: Steffen Prohaska @ 2008-07-15 21:51 UTC (permalink / raw)
To: chongyc; +Cc: git
In-Reply-To: <59f9aa2d-75f2-493d-8f83-1a5fcb24a889@34g2000hsh.googlegroups.com>
On Jul 15, 2008, at 4:55 AM, chongyc wrote:
> I am going to merge conflict by using git-mergetool of msysgit(for
> windows) and Winmerge.
>
> what shall i do?
If you have already read the documentation of "git mergetool", see
http://www.kernel.org/pub/software/scm/git/docs/git-mergetool.html
what is your specific question?
Steffen
^ permalink raw reply
* Re: [PATCH 2/2] git-gui: Allow "Stage Line" to stage adjacent changes independently
From: Junio C Hamano @ 2008-07-15 21:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Shawn O. Pearce, git
In-Reply-To: <1216156261-9687-2-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Consider this hunk:
>
> @@ -10,4 +10,4 @@
> context before
> -old 1
> -old 2
> +new 1
> +new 2
> context after
>
> [Nomenclature: to "stage change 2" means to stage lines "-old 1" and
> "+new 1", in any order; likewise for "unstage" and "change 2".]
You lost me.
Do you mean to say that you always interpret the above hunk as:
@@ -10,4 +10,4 @@
context before
-old 1
+new 1
-old 2
+new 2
context after
and call "replace 'old 1' with 'new 1'" as "change 1", "replace 'old
2' with 'new 2'" as "change 2"?
If it is what you are doing, it does not make much sense to me. "new 1"
may correspond to "old 1" and "old 2" while "new 2" may be an independent
addition. E.g.
@@ -10,4 +10,4 @@
context before
-#define add(x,y) \
- (x) + (y)
+#define add(x,y) ((x)+(y))
+#define sub(x,y) ((x)-(y))
context after
I might want to pick bugfix of add() definition without using the new
definition of sub().
Please call
"-old 1" - change #1
"-old 2" - change #2
"+new 1" - change #3
"+new 2" - change #4
and try explaining what you are doing again, pretty please?
^ permalink raw reply
* Re: Git rebase failure: .dotest overwritten
From: René Scharfe @ 2008-07-15 21:48 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Joe Fiorini, git, Johannes Schindelin, Jari Aalto
In-Reply-To: <20080715212211.GL6244@leksak.fem-net>
Stephan Beyer schrieb:
> git-rebase (without -i/-m) generates a directory called ".dotest/" to
> save temporary stuff like the commits you want to rebase.
In February it was discussed to move .dotest below $GIT_DIR. There was
even a patch (to rename it to .git-dotest). I suspect the upcoming
version 1.6.0 is a good opportunity to finally remove this wart.
René
^ permalink raw reply
* Re: [PATCH 1/4] Allow e-mails to be sent with the Unix sendmail tool
From: Catalin Marinas @ 2008-07-15 21:47 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Mark Brown, git
In-Reply-To: <20080715123432.GB17008@diana.vm.bytemark.co.uk>
2008/7/15 Karl Hasselström <kha@treskal.com>:
> On 2008-07-15 13:22:20 +0100, Mark Brown wrote:
>
>> On Sun, Jul 13, 2008 at 12:40:26PM +0100, Catalin Marinas wrote:
>>
>> > If the stgit.smtpserver configuration option does not have a
>> > host:port format, it is assumed to be an external tool. For
>> > example, to use sendmail just set this variable to
>> > "/usr/sbin/sendmail -t -i" (see the examples/gitconfig file).
>>
>> I'd really expect to be able to just specify the hostname alone if
>> using the standard SMTP port. Perhaps checking for a / in the server
>> might be less surprising?
>
> This is actually what the code does, and what the documentation claims
> it should do. It's just the commit message that's confused. Catalin?
Yes, indeed, but too many things to keep in sync :-).
--
Catalin
^ permalink raw reply
* Re: [PATCH] Only use GIT_CONFIG in "git config", not other programs
From: Daniel Barkalow @ 2008-07-15 21:46 UTC (permalink / raw)
To: sverre; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <bd6139dc0807151056q61a9379l84761fe021d4541c@mail.gmail.com>
On Tue, 15 Jul 2008, Sverre Rabbelier wrote:
> On Mon, Jun 30, 2008 at 9:37 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > @@ -611,31 +613,28 @@ int git_config(config_fn_t fn, void *data)
> > {
> > int ret = 0;
> > char *repo_config = NULL;
> > - const char *home = NULL, *filename;
> > + const char *home = NULL;
> >
> > /* $GIT_CONFIG makes git read _only_ the given config file,
> > * $GIT_CONFIG_LOCAL will make it process it in addition to the
> > * global config file, the same way it would the per-repository
> > * config file otherwise. */
>
> I noticed today while looking at config.c (because of the 'git config
> oddity' thread) that this reference to GIT_CONFIG_LOCAL was not
> removed?
Actually, it looks like that whole comment is obsolete; only
builtin-config.c cares about any of this stuff.
> On latest next:
> $ grep GIT_CONFIG_LOCAL *
> config.c: * $GIT_CONFIG_LOCAL will make it process it in addition to the
> git-svn: my $file = $ENV{GIT_CONFIG} || $ENV{GIT_CONFIG_LOCAL} ||
> git-svn.perl: my $file = $ENV{GIT_CONFIG} || $ENV{GIT_CONFIG_LOCAL} ||
I'm not sure if git-svn is doing the right thing here, either.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git rebase failure: .dotest overwritten
From: Stephan Beyer @ 2008-07-15 21:22 UTC (permalink / raw)
To: Joe Fiorini; +Cc: git
In-Reply-To: <73fd69b50807151408i6a916da6p7b89fe81e65fc717@mail.gmail.com>
Hi,
Joe Fiorini wrote:
> A friend of mine asked me for help with a git rebase problem. I was
> clueless. Here is what he was seeing:
> The main problem seems to be the following error: "fatal: Untracked
> working tree file '.dotest/0001' would be overwritten by merge."; also
> all the files that it says "already exist in working directory" did
> not exist before he ran the rebase. Maybe it's trying to run the
> rebase more than once? His working copy was clean. Any thoughts? Any
> other details I can provide?
git-rebase (without -i/-m) generates a directory called ".dotest/" to
save temporary stuff like the commits you want to rebase.
And it seems that at least one commit in his repo has .dotest/* files
in the tree, so that message occurs.
Hmm, he should perhaps clean that commit up and remove the .dotest
files from it. (After figuring out that commit, he could try
git rebase -i ...
and change the "pick" line to "edit".)
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* [PATCH 2/2] git-gui: Allow "Stage Line" to stage adjacent changes independently
From: Johannes Sixt @ 2008-07-15 21:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
In-Reply-To: <1216156261-9687-1-git-send-email-johannes.sixt@telecom.at>
Consider this hunk:
@@ -10,4 +10,4 @@
context before
-old 1
-old 2
+new 1
+new 2
context after
[Nomenclature: to "stage change 2" means to stage lines "-old 1" and
"+new 1", in any order; likewise for "unstage" and "change 2".]
Previously, we had this situation:
stage change 1 was not possible
stage change 2 was possible
unstage change 1 was possible
unstage change 2 was not possible
With this change we have this situation:
stage change 1 is possible
stage change 2 is not possible
unstage change 1 is possible
unstage change 2 is not possible
What's the deal?
Previously, it was impossible to stage change 1 without also staging
change 2; not even by staging the complete hunk and unstaging the unwanted
part.
With this change we can achieve all goals:
hunk is want staged want unstaged do this
----------------------------------------------------------------------
unstaged change 1 change 2 stage change 1
unstaged change 2 change 1 stage hunk, unstage change 1
staged change 1 change 2 unstage hunk, stage change 1
staged change 2 change 1 unstage change 1
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
lib/diff.tcl | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index ee7f391..77990c5 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -411,6 +411,53 @@ proc apply_line {x y} {
set hh [lindex [split $hh ,] 0]
set hln [lindex [split $hh -] 1]
+ # There is a special situation to take care of. Consider this hunk:
+ #
+ # @@ -10,4 +10,4 @@
+ # context before
+ # -old 1
+ # -old 2
+ # +new 1
+ # +new 2
+ # context after
+ #
+ # We used to keep the context lines in the order they appear in the
+ # hunk. But then it is not possible to correctly stage only
+ # "-old 1" and "+new 1" - it would result in this staged text:
+ #
+ # context before
+ # old 2
+ # new 1
+ # context after
+ #
+ # (By symmetry it is not possible to *un*stage "old 2" and "new 2".)
+ #
+ # We resolve the problem by introducing an asymmetry, namely, when
+ # a "+" line is *staged*, it is moved in front of the context lines
+ # that are generated from the "-" lines that are immediately before
+ # the "+" block. That is, we construct this patch:
+ #
+ # @@ -10,4 +10,5 @@
+ # context before
+ # +new 1
+ # old 1
+ # old 2
+ # context after
+ #
+ # But we do *not* treat "-" lines that are *un*staged in a special
+ # way.
+ #
+ # With this asymmetry it is possible to stage the change
+ # "old 1" -> "new 1" directly, and to stage the change
+ # "old 2" -> "new 2" by first staging the entire hunk and
+ # then unstaging the change "old 1" -> "new 1".
+
+ # This is non-empty if and only if we are _staging_ changes;
+ # then it accumulates the consecutive "-" lines (after converting
+ # them to context lines) in order to be moved after the "+" change
+ # line.
+ set pre_context {}
+
set n 0
set i_l [$ui_diff index "$i_l + 1 lines"]
set patch {}
@@ -422,19 +469,27 @@ proc apply_line {x y} {
[$ui_diff compare $the_l < $next_l]} {
# the line to stage/unstage
set ln [$ui_diff get $i_l $next_l]
- set patch "$patch$ln"
if {$c1 eq {-}} {
set n [expr $n+1]
+ set patch "$patch$pre_context$ln"
+ } else {
+ set patch "$patch$ln$pre_context"
}
+ set pre_context {}
} elseif {$c1 ne {-} && $c1 ne {+}} {
# context line
set ln [$ui_diff get $i_l $next_l]
- set patch "$patch$ln"
+ set patch "$patch$pre_context$ln"
set n [expr $n+1]
+ set pre_context {}
} elseif {$c1 eq $to_context} {
# turn change line into context line
set ln [$ui_diff get "$i_l + 1 chars" $next_l]
- set patch "$patch $ln"
+ if {$c1 eq {-}} {
+ set pre_context "$pre_context $ln"
+ } else {
+ set patch "$patch $ln"
+ }
set n [expr $n+1]
}
set i_l $next_l
--
1.5.6.3.323.g1e58
^ permalink raw reply related
* [PATCH 1/2] git-gui: Fix "Stage/Unstage Line" with one line of context.
From: Johannes Sixt @ 2008-07-15 21:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Johannes Sixt
To "Stage/Unstage Line" we construct a patch that contains exactly one
change (either addition or removal); the hunk header was forged by counting
the old side and adjusting the count by +/-1 for the new side. But when we
counted the context we never counted the changed line itself. If the hunk
had only one removal line and one line of context, like this:
@@ -1,3 +1,2 @@
context 1
-removal
context 2
We had constructed this patch:
@@ -1,2 +1,1 @@
context 1
-removal
context 2
which does not apply because git apply deduces that it must apply at the
end of the file. ("context 2" is considered garbage and ignored.) The fix
is that removal lines must be counted towards the context of the old side.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
lib/diff.tcl | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 96ba949..ee7f391 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -423,6 +423,9 @@ proc apply_line {x y} {
# the line to stage/unstage
set ln [$ui_diff get $i_l $next_l]
set patch "$patch$ln"
+ if {$c1 eq {-}} {
+ set n [expr $n+1]
+ }
} elseif {$c1 ne {-} && $c1 ne {+}} {
# context line
set ln [$ui_diff get $i_l $next_l]
--
1.5.6.3.323.g1e58
^ permalink raw reply related
* Git rebase failure: .dotest overwritten
From: Joe Fiorini @ 2008-07-15 21:08 UTC (permalink / raw)
To: git
A friend of mine asked me for help with a git rebase problem. I was
clueless. Here is what he was seeing:
The main problem seems to be the following error: "fatal: Untracked
working tree file '.dotest/0001' would be overwritten by merge."; also
all the files that it says "already exist in working directory" did
not exist before he ran the rebase. Maybe it's trying to run the
rebase more than once? His working copy was clean. Any thoughts? Any
other details I can provide?
Thanks!
Joe
git rebase master
First, rewinding head to replay your work on top of it...
HEAD is now at 9bba5f1... Create function snippet
Applying People page templates
.dotest/patch:59: trailing whitespace.
.dotest/patch:60: space before tab in indent.
parent::BuildControlArray($EventParameters);
.dotest/patch:61: space before tab in indent.
}
.dotest/patch:65: trailing whitespace, space before tab in indent.
.dotest/patch:67: trailing whitespace.
error: .dotest/0001: already exists in working directory
error: .dotest/0002: already exists in working directory
error: .dotest/0003: already exists in working directory
error: .dotest/binary: already exists in working directory
error: .dotest/final-commit: already exists in working directory
error: .dotest/info: already exists in working directory
error: .dotest/keep: already exists in working directory
error: .dotest/last: already exists in working directory
error: .dotest/msg: already exists in working directory
error: .dotest/msg-clean: already exists in working directory
error: .dotest/next: already exists in working directory
error: .dotest/patch: already exists in working directory
error: .dotest/sign: already exists in working directory
error: .dotest/utf8: already exists in working directory
error: .dotest/whitespace: already exists in working directory
Using index info to reconstruct a base tree...
stdin:59: trailing whitespace.
stdin:60: space before tab in indent.
parent::BuildControlArray($EventParameters);
stdin:61: space before tab in indent.
}
stdin:65: trailing whitespace, space before tab in indent.
stdin:67: trailing whitespace.
warning: squelched 49 whitespace errors
warning: 54 lines add whitespace errors.
Falling back to patching base and 3-way merge...
fatal: Untracked working tree file '.dotest/0001' would be overwritten by merge.
Failed to merge in the changes.
Patch failed at 0001.
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
--
joe fiorini
http://www.faithfulgeek.org
// freelancing & knowledge sharing
^ permalink raw reply
* Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Yves Orton @ 2008-07-15 20:26 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Petr Baudis, Johannes Schindelin, gitster, git
In-Reply-To: <487CF5A4.2070700@dawes.za.net>
On Tue, 2008-07-15 at 21:08 +0200, Rogan Dawes wrote:
> Yves Orton wrote:
>
> > Hmm, realizing that was the workdir it wanted i tried it like so:
> >
> > [dmq@somewhere apps]$ git --work-tree="$(git-rev-parse --git-dir)/.."
> > pull --rebase
> > /usr/bin/git-sh-setup: line 139: cd: /home/dmq/git_tree/main/apps/.git:
> > No such file or directory
> > Unable to determine absolute path of git directory
> >
> > Yet:
> >
> > [dmq@somewhere apps]$ git-rev-parse --git-dir
> > /home/dmq/git_tree/main/.git
> >
> > is correct.
> >
>
> Are you sure you don't want to specify the --git-dir rather than the
> work dir?
>
> i.e.
>
> git --git-dir="$(git-rev-parse --git-dir)" pull --rebase
That doesnt seem to work correctly either. If i do it from the symlinked
directory i get a notice about each file needing an update. While it
works as expected from the real repo directory.
I think this shows what i mean:
demerphq@gemini:~/git_test/bar$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: bar
#
no changes added to commit (use "git add" and/or "git commit -a")
demerphq@gemini:~/git_test/bar$ git commit -a -m'changed bar'
Created commit 7cbbdc9: changed bar
1 files changed, 1 insertions(+), 0 deletions(-)
demerphq@gemini:~/git_test/bar$ git --git-dir="$(git-rev-parse
--git-dir)" pull --rebase
bar/bar: needs update
refusing to pull with rebase: your working tree is not up-to-date
demerphq@gemini:~/git_test/bar$ cd ../foo2
demerphq@gemini:~/git_test/foo2$ git --git-dir="$(git-rev-parse
--git-dir)" pull --rebase
Current branch master is up to date.
demerphq@gemini:~/git_test/foo2$ cd ..
demerphq@gemini:~/git_test$ ls -lart
total 24
drwxr-xr-x 4 demerphq demerphq 4096 2008-07-15 22:17 foo
drwxr-xr-x 116 demerphq demerphq 12288 2008-07-15 22:18 ..
lrwxrwxrwx 1 demerphq demerphq 8 2008-07-15 22:20 bar -> foo2/bar
drwxr-xr-x 4 demerphq demerphq 4096 2008-07-15 22:20 .
drwxr-xr-x 4 demerphq demerphq 4096 2008-07-15 22:21 foo2
Yves
^ permalink raw reply
* Re: git-rebase eats empty commits
From: Stephan Beyer @ 2008-07-15 20:19 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g5fpnm$3jb$1@ger.gmane.org>
Hi,
Michael J Gruber wrote:
> Stephan Beyer venit, vidit, dixit 13.07.2008 00:12:
>> To sum up, use rebase -i and when it's pausing, do "git commit --allow-empty"
>> and then "git rebase --continue" and you have what you want.
>
> I assume this is with git from master? With git 1.5.6.2 rebase -i
> doesn't stop there, not even when I change "pick" to "edit"!
Hmm, in fact this is with my git from Debian, from master and my
sequencer-based one:
$ /usr/bin/git --version
git version 1.5.6
$ ./git --version
git version 1.5.6.3.350.g6c11a
$ git --version
git version 1.5.6.3.506.g902dd
And, btw, the reason of this behavior is no special case in rebase-i,
it's just that git-cherry-pick fails (exit status != 0), if you pick an
empty commit (and then rebase-i will pause because of conflict). And
*this* is because builtin-revert.c runs git-commit without --allow-empty.
This has never changed, so I cannot believe that the behavior changed in
any version of git. Or I am missing a point.
$ git cherry-pick empty # empty is an empty commit tagged as "empty"
Already uptodate!
Finished one cherry-pick.
# Not currently on any branch.
# Untracked files:
[...]
nothing added to commit but untracked files present (use "git add" to track)
$ echo $?
1
$ EDITOR=touch git commit --allow-empty
Created commit 145f1d0: empty
The same happens when doing rebase -i instead of cherry-pick.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: Standard "git svn init ; git svn fetch" behavior
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-15 20:14 UTC (permalink / raw)
Cc: git
In-Reply-To: <eaa105840807150737u11b02f50xba2c8201ce96eec0@mail.gmail.com>
Peter, thanks for your swift reply! It cleared up things for me.
^ permalink raw reply
* StGit: kha/{stable,safe,experimental} updated
From: Karl Hasselström @ 2008-07-15 19:58 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
It's been a while since I sent one of these updates.
Catalin, you probably want to pull stable and safe, to get Miklos's
setup.py fixes (I backported them to stable, and then merged back to
the main branch). (The stable branch has a handful of fixes since
0.14.3; it might be time for 0.14.4?)
-+-
The following changes since commit a6c4be12abcf0906a63de8a72c887c360f89ea82:
Karl Hasselström (1):
Don't allow extra diff options with "stg status"
are available in the git repository at:
git://repo.or.cz/stgit/kha.git stable
Miklos Vajna (2):
setup.py: don't try to import stgit.run before the python version check
setup.py: fix error message when running with python-2.3
setup.py | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
-+-
The following changes since commit 2e37b61d886ef21200007b57f496aaf182f42705:
Karl Hasselström (1):
Test for "stg edit"
are available in the git repository at:
git://repo.or.cz/stgit/kha.git safe
Karl Hasselström (1):
Merge branch 'stable'
Miklos Vajna (2):
setup.py: don't try to import stgit.run before the python version check
setup.py: fix error message when running with python-2.3
setup.py | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
-+-
The following changes since commit d8461a9dfb9a34e582019de5a67798fad44f42c7:
Karl Hasselström (1):
Merge branch 'stable'
are available in the git repository at:
git://repo.or.cz/stgit/kha.git experimental
Karl Hasselström (21):
Discard stderr output from git apply if the caller wants
Do simple in-index merge with diff+apply instead of read-tree
Reuse the same temp index in a transaction
Library functions for tree and blob manipulation
Write to a stack log when stack is modified
Add utility function for reordering patches
New command: stg reset
Log conflicts separately
Log conflicts separately for all commands
Add a --hard flag to stg reset
Don't write a log entry if there were no changes
Move stack reset function to a shared location
New command: stg undo
New command: stg redo
Log and undo external modifications
Make "stg log" show stack log instead of patch log
Convert "stg refresh" to the new infrastructure
New refresh tests
Remove --undo flags from stg commands and docs
Refactor stgit.commands.edit
Implement "stg refresh --edit" again
Documentation/tutorial.txt | 4 +-
TODO | 2 -
stgit/commands/branch.py | 19 +-
stgit/commands/clone.py | 2 +-
stgit/commands/coalesce.py | 2 +-
stgit/commands/common.py | 18 +-
stgit/commands/diff.py | 6 +-
stgit/commands/edit.py | 82 +------
stgit/commands/export.py | 2 +-
stgit/commands/files.py | 6 +-
stgit/commands/float.py | 2 +-
stgit/commands/fold.py | 2 +-
stgit/commands/goto.py | 3 +-
stgit/commands/hide.py | 2 +-
stgit/commands/id.py | 2 +-
stgit/commands/imprt.py | 4 +-
stgit/commands/log.py | 169 ++++---------
stgit/commands/mail.py | 8 +-
stgit/commands/new.py | 3 +-
stgit/commands/patches.py | 2 +-
stgit/commands/pick.py | 2 +-
stgit/commands/pop.py | 4 +-
stgit/commands/pull.py | 2 +-
stgit/commands/push.py | 31 +--
stgit/commands/rebase.py | 4 +-
stgit/commands/redo.py | 52 ++++
stgit/commands/refresh.py | 338 +++++++++++++++++---------
stgit/commands/rename.py | 2 +-
stgit/commands/repair.py | 11 +-
stgit/commands/reset.py | 57 +++++
stgit/commands/resolved.py | 2 +-
stgit/commands/show.py | 2 +-
stgit/commands/sink.py | 2 +-
stgit/commands/status.py | 3 +-
stgit/commands/sync.py | 26 +--
stgit/commands/undo.py | 49 ++++
stgit/commands/unhide.py | 2 +-
stgit/git.py | 4 -
stgit/lib/edit.py | 99 ++++++++
stgit/lib/git.py | 348 +++++++++++++++++++++++-----
stgit/lib/log.py | 537 ++++++++++++++++++++++++++++++++++++++++++
stgit/lib/stack.py | 25 ++
stgit/lib/transaction.py | 139 ++++++++---
stgit/main.py | 8 +
stgit/stack.py | 45 +----
stgit/utils.py | 18 +-
t/t1200-push-modified.sh | 2 +-
t/t1201-pull-trailing.sh | 2 +-
t/t1202-push-undo.sh | 8 +-
t/t1400-patch-history.sh | 103 --------
t/t2300-refresh-subdir.sh | 29 +++-
t/t3100-reset.sh | 151 ++++++++++++
t/t3101-reset-hard.sh | 56 +++++
t/t3102-undo.sh | 86 +++++++
t/t3103-undo-hard.sh | 56 +++++
t/t3104-redo.sh | 122 ++++++++++
t/t3105-undo-external-mod.sh | 68 ++++++
t/t3300-edit.sh | 4 +-
58 files changed, 2179 insertions(+), 660 deletions(-)
create mode 100644 stgit/commands/redo.py
create mode 100644 stgit/commands/reset.py
create mode 100644 stgit/commands/undo.py
create mode 100644 stgit/lib/edit.py
create mode 100644 stgit/lib/log.py
delete mode 100755 t/t1400-patch-history.sh
create mode 100755 t/t3100-reset.sh
create mode 100755 t/t3101-reset-hard.sh
create mode 100755 t/t3102-undo.sh
create mode 100755 t/t3103-undo-hard.sh
create mode 100755 t/t3104-redo.sh
create mode 100755 t/t3105-undo-external-mod.sh
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* git-svn: add/obey a hooks/prepare-commit-msg
From: W Snyder @ 2008-07-15 19:10 UTC (permalink / raw)
To: git
First, thanks for git-svn!
I'm trying to make a edit to the log message when pulling
from SVN into GIT using git-svn.
It's going bidirectionally, so I don't want to
git-filter-branch.
I tried creating a hooks/prepare-commit-msg script; it works
ok when manually doing a "git-commit" but seems to be
ignored by "git-svn fetch". I made a hacked-up copy of
git-svn that edits the log message the way I want and it all
seems to work.
Can support for obeying commit-msg hooks be added to
git-svn? Or, is there another way to do this?
Thanks!
^ permalink raw reply
* Re: [PATCH] git rev-parse: Fix --show-cdup inside symlinked directory
From: Rogan Dawes @ 2008-07-15 19:08 UTC (permalink / raw)
To: Yves Orton; +Cc: Petr Baudis, Johannes Schindelin, gitster, git
In-Reply-To: <1216141099.19334.196.camel@gemini>
Yves Orton wrote:
> Hmm, realizing that was the workdir it wanted i tried it like so:
>
> [dmq@somewhere apps]$ git --work-tree="$(git-rev-parse --git-dir)/.."
> pull --rebase
> /usr/bin/git-sh-setup: line 139: cd: /home/dmq/git_tree/main/apps/.git:
> No such file or directory
> Unable to determine absolute path of git directory
>
> Yet:
>
> [dmq@somewhere apps]$ git-rev-parse --git-dir
> /home/dmq/git_tree/main/.git
>
> is correct.
>
Are you sure you don't want to specify the --git-dir rather than the
work dir?
i.e.
git --git-dir="$(git-rev-parse --git-dir)" pull --rebase
Rogan
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Junio C Hamano @ 2008-07-15 18:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Dmitry Potapov, Petr Baudis, Nicolas Pitre, Gerrit Pape, git
In-Reply-To: <alpine.DEB.1.00.0807151623120.8950@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 15 Jul 2008, Dmitry Potapov wrote:
>
>> Those repos that think that access for Git 1.4 users is important for
>> them can set indexformat=1.
>
> Unfortunately, you place quite a high maintenance burden on the repository
> maintainers here.
>
> From the time balance sheet, it does not look good at all: a few minutes
> for Junio to change and commit, up to a few hours (because they missed it
> in the release notes) for probably more than hundred repository
> maintainers that are not subscribed to the Git mailing list.
>
> And I absolutely agree with Pasky that this does _nothing_ in the vague
> direction of wielding a reputation of being easy to use.
>
> Sure, we can make it easy on ourselves. And it is just as easy to make it
> hard on others. If you're okay with that, I am not.
I was not planning to comment on this issue further as the ball is in
Debian's court, but I think you are misguided.
We are not making anything hard on others. Sticking to 1.4.4.4 codebase
is forced by Debian (for its policy) and choice made by its users (for not
knowing or using backports). 1.5.0 and later are vastly better and we
encourage users to update on every occassion we get.
I do not know the extent of the backporting effort necessary, the size of
potentially impacted population if Debian keeps shipping unpatched
1.4.4.4, nor how much Debian cares about supporting their 1.4.4.4 users
i.e. if they are willing and able to carry distro-only forward
compatibility patches, and knowing all of these is necessary before we
declare this is worth handling _ourselves_. That is why I did not want to
take a definitive stance on this issue before hearing from the Debian
maintainer about them -- I said "Debian has to ask with list of items",
didn't I?
What troubles me the most is that you seem to be forgetting that we are
using git to manage our codebase. Even if this turns out to be something
we would want to handle ourselves, it does not have to come from me. If
you care that much, you could backport whatever change is appropriate to
keep 1.4.4.X codebase alive and arrange it to be published as 1.4.4.5.
In any case, it will _definitely_ *NOT* a few minutes of me nor anybody.
Release engineering takes quite a lot of time.
^ permalink raw reply
* Re: [PATCH v2] index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
From: Junio C Hamano @ 2008-07-15 18:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Nicolas Pitre, Stephan Hennig, Andreas Ericsson
In-Reply-To: <20080715044534.GA2794@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Version 2 plugs the case Nico noticed, where the patch was causing
> the exact behavior it was trying to prevent while recovering from
> what it did to avoid the excessive memory usage in the first place.
Thanks both; it makes sense.
^ 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