* Is anybody actually using git-cherry.sh?
From: Johannes Schindelin @ 2006-06-23 16:22 UTC (permalink / raw)
To: git
Hi,
from git-cherry.sh:
-- snip --
for c in $inup
do
git-diff-tree -p $c
done | git-patch-id |
while read id name
do
echo $name >>$patch/$id
done
-- snap --
AFAICS this _must_ be broken. git-diff-tree -p <ent> does not emit
"diff-tree <sha1>", and neither "commit <sha1>" lines. So this code would
yield just one file, treating all diffs as one huge diff. A quick fix
would be this change (without the patch I sent out earlier):
+ echo "diff-tree $c"
git-diff-tree -p $c
Am I wrong?
Ciao,
Dscho
^ permalink raw reply
* CVS import broken?
From: Johannes Schindelin @ 2006-06-23 16:14 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
Hi,
I track quite a few CVS repos with 'git-cvsimport -k -i', but recently it
stopped working (of course, I was not reimporting, but incrementally
tracking them). I think it is the introduction of one-index-per-branch
policy:
> fatal: index file mmap failed (Invalid argument)
> unable to write to git-update-index: at /.../git-cvsimport line 606, <CVS> line 277425.
It seems that git-cvsimport makes a temporary file of size 0, which cannot
get mmap()ed, because it has size 0.
Any help appreciated,
Dscho
^ permalink raw reply
* Re: [PATCH] patch-id: "diff-tree" => "commit"
From: Johannes Schindelin @ 2006-06-23 16:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.64.0606230849290.6483@g5.osdl.org>
Hi,
On Fri, 23 Jun 2006, Linus Torvalds wrote:
> On Fri, 23 Jun 2006, Johannes Schindelin wrote:
> >
> > Some time ago we changed git-log in a massive way, and one consequence is
> > that the keyword changed. Adjust patch-id for that.
>
> Ahh. Yes. Except I think you should allow both, for historical reasons (ie
> not remove the old case).
Hmm. If you are alluding to mailboxes, where there could be mails from
older git versions, then this might not be enough. Look at my patch, for
example. There is no "diff-tree", and no "commit".
However, the only official user of patch-id is git-cherry (and indirectly,
all users of git-cherry). And this user works on data which is generated
on the fly, i.e. there will be no "diff-tree" at the beginning.
Of course, there is a Pandora's box: a line in a commit message is much
more likely to start with "commit <sha1>" than "diff-tree <sha1>". So my
patch probably breaks many cases.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] patch-id: "diff-tree" => "commit"
From: Linus Torvalds @ 2006-06-23 15:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0606231731280.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 23 Jun 2006, Johannes Schindelin wrote:
>
> Some time ago we changed git-log in a massive way, and one consequence is
> that the keyword changed. Adjust patch-id for that.
Ahh. Yes. Except I think you should allow both, for historical reasons (ie
not remove the old case).
Linus
^ permalink raw reply
* [FYI/PATCH] diff: add diff_flush_patch_id()
From: Johannes Schindelin @ 2006-06-23 15:44 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: martin.langhoff, git
In-Reply-To: <Pine.LNX.4.63.0606231431420.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Call it like this:
unsigned char id[20];
if (diff_flush_patch_id(diff_options, id))
printf("And the patch id is: %s\n", sha1_to_hex(id));
This patch also adds a switch "--with-patch-id" to the diff family, to
print out the patch id before each patch.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
> > > - add a DIFF_FORMAT_PATCH_ID
> >
> > Please don't add any DIFF_FORMAT_*. I'm cleaning the diff output code
> > and replacing diff_options.output_format with one-bit flags.
>
> Okay. For the purposes of git-format-patch, this is not needed
> anyway, but rather a function which takes two tree objects and
> returns the patch id. When you are finished it should be easy to
> add this as a display format.
Timo, I am prepared to redo this patch when you finished
the cleanup.
diff.c | 129 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
diff.h | 3 +
2 files changed, 132 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index 5b34f73..1140d54 100644
--- a/diff.c
+++ b/diff.c
@@ -1460,6 +1460,8 @@ int diff_opt_parse(struct diff_options *
options->output_format = DIFF_FORMAT_PATCH;
options->with_stat = 1;
}
+ else if (!strcmp(arg, "--with-patch-id"))
+ options->with_patch_id = 1;
else if (!strcmp(arg, "-z"))
options->line_termination = 0;
else if (!strncmp(arg, "-l", 2))
@@ -2027,12 +2029,139 @@ static void diff_summary(struct diff_fil
}
}
+struct patch_id_t {
+ struct xdiff_emit_state xm;
+ SHA_CTX *ctx;
+ int patchlen;
+};
+
+static int remove_space(char *line, int len)
+{
+ int i;
+ char *dst = line;
+ unsigned char c;
+
+ for (i = 0; i < len; i++)
+ if (!isspace((c = line[i])))
+ *dst++ = c;
+
+ return dst - line;
+}
+
+static void patch_id_consume(void *priv, char *line, unsigned long len)
+{
+ struct patch_id_t *data = priv;
+ int new_len;
+
+ /* Ignore line numbers when computing the SHA1 of the patch */
+ if (!strncmp(line, "@@ -", 4))
+ return;
+
+ new_len = remove_space(line, len);
+
+ SHA1_Update(data->ctx, line, new_len);
+ data->patchlen += new_len;
+}
+
+/* returns 0 upon success, and writes result into sha1 */
+int diff_flush_patch_id(struct diff_options *options, unsigned char *sha1)
+{
+ struct diff_queue_struct *q = &diff_queued_diff;
+ int i;
+ SHA_CTX ctx;
+ struct patch_id_t data;
+ char buffer[PATH_MAX * 4 + 20];
+
+ SHA1_Init(&ctx);
+ memset(&data, 0, sizeof(struct patch_id_t));
+ data.ctx = &ctx;
+ data.xm.consume = patch_id_consume;
+
+ for (i = 0; i < q->nr; i++) {
+ xpparam_t xpp;
+ xdemitconf_t xecfg;
+ xdemitcb_t ecb;
+ mmfile_t mf1, mf2;
+ struct diff_filepair *p = q->queue[i];
+ int len1, len2;
+
+ if (p->status == 0)
+ return error("internal diff status error");
+ if (p->status == DIFF_STATUS_UNKNOWN)
+ continue;
+ if (diff_unmodified_pair(p))
+ continue;
+ if ((DIFF_FILE_VALID(p->one) && S_ISDIR(p->one->mode)) ||
+ (DIFF_FILE_VALID(p->two) && S_ISDIR(p->two->mode)))
+ continue;
+ if (DIFF_PAIR_UNMERGED(p))
+ continue;
+
+ diff_fill_sha1_info(p->one);
+ diff_fill_sha1_info(p->two);
+ if (fill_mmfile(&mf1, p->one) < 0 ||
+ fill_mmfile(&mf2, p->two) < 0)
+ return error("unable to read files to diff");
+
+ /* Maybe hash p->two? into the patch id? */
+ if (mmfile_is_binary(&mf2))
+ continue;
+
+ len1 = remove_space(p->one->path, strlen(p->one->path));
+ len2 = remove_space(p->two->path, strlen(p->two->path));
+ if (p->one->mode == 0)
+ len1 = snprintf(buffer, sizeof(buffer),
+ "diff--gita/%.*sb/%.*s"
+ "newfilemode%06o"
+ "---/dev/null"
+ "+++b/%.*s",
+ len1, p->one->path,
+ len2, p->two->path,
+ p->two->mode,
+ len2, p->two->path);
+ else if (p->two->mode == 0)
+ len1 = snprintf(buffer, sizeof(buffer),
+ "diff--gita/%.*sb/%.*s"
+ "deletedfilemode%06o"
+ "---a/%.*s"
+ "+++/dev/null",
+ len1, p->one->path,
+ len2, p->two->path,
+ p->one->mode,
+ len1, p->one->path);
+ else
+ len1 = snprintf(buffer, sizeof(buffer),
+ "diff--gita/%.*sb/%.*s"
+ "---a/%.*s"
+ "+++b/%.*s",
+ len1, p->one->path,
+ len2, p->two->path,
+ len1, p->one->path,
+ len2, p->two->path);
+ SHA1_Update(&ctx, buffer, len1);
+
+ xpp.flags = XDF_NEED_MINIMAL;
+ xecfg.ctxlen = 3;
+ xecfg.flags = 3;
+ ecb.outf = xdiff_outf;
+ ecb.priv = &data;
+ xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
+ }
+
+ SHA1_Final(sha1, &ctx);
+ return 0;
+}
+
void diff_flush(struct diff_options *options)
{
struct diff_queue_struct *q = &diff_queued_diff;
int i;
int diff_output_format = options->output_format;
struct diffstat_t *diffstat = NULL;
+ unsigned char sha1[20];
+
+ if (options->with_patch_id && !diff_flush_patch_id(options, sha1))
+ printf("patch-id %s\n", sha1_to_hex(sha1));
if (diff_output_format == DIFF_FORMAT_DIFFSTAT || options->with_stat) {
diffstat = xcalloc(sizeof (struct diffstat_t), 1);
diff --git a/diff.h b/diff.h
index 7d7b6cd..29aac52 100644
--- a/diff.h
+++ b/diff.h
@@ -27,6 +27,7 @@ struct diff_options {
unsigned recursive:1,
with_raw:1,
with_stat:1,
+ with_patch_id:1,
tree_in_recursive:1,
binary:1,
full_index:1,
@@ -185,4 +186,6 @@ extern int run_diff_files(struct rev_inf
extern int run_diff_index(struct rev_info *revs, int cached);
+extern int diff_flush_patch_id(struct diff_options *, unsigned char *);
+
#endif /* DIFF_H */
--
1.4.0.g319e-dirty
^ permalink raw reply related
* [PATCH] patch-id: "diff-tree" => "commit"
From: Johannes Schindelin @ 2006-06-23 15:36 UTC (permalink / raw)
To: git, junkio
Some time ago we changed git-log in a massive way, and one consequence is
that the keyword changed. Adjust patch-id for that.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
patch-id.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/patch-id.c b/patch-id.c
index edbc4aa..01845be 100644
--- a/patch-id.c
+++ b/patch-id.c
@@ -40,8 +40,8 @@ static void generate_id_list(void)
char *p = line;
int len;
- if (!memcmp(line, "diff-tree ", 10))
- p += 10;
+ if (!memcmp(line, "commit ", 7))
+ p += 7;
if (!get_sha1_hex(p, n)) {
flush_current_id(patchlen, sha1, &ctx);
--
1.4.1.rc1.g406e
^ permalink raw reply related
* Re: What's in git.git and announcing v1.4.1-rc1
From: Linus Torvalds @ 2006-06-23 14:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Git Mailing List, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.63.0606231305000.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Fri, 23 Jun 2006, Johannes Schindelin wrote:
> >
> > - default to red/green for old/new lines. That's the norm, I'd think.
>
> ... and which happens to be useless for 10% of the male population (and
> even more if you look specifically at Asian people). But then, I just
> pasted that part from somewhere else.
Sure.
(Although I think it's 7% in general, and more in certain populations,
some Western European countries included)
Which just means that we should have some way to let people set their own
colors.
The _default_ should be the one people expect, though.
Linus
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Johannes Schindelin @ 2006-06-23 14:25 UTC (permalink / raw)
To: Pádraig Brady
Cc: Linus Torvalds, Junio C Hamano, Git Mailing List,
Linux Kernel Mailing List
In-Reply-To: <449BF508.9040207@draigBrady.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 376 bytes --]
Hi,
On Fri, 23 Jun 2006, Pádraig Brady wrote:
> So 10% of the male population need to learn traffic light positions
> rather than colours?
A friend of mine was at the military and had to check new recruits for
color-blindness. Only after the 20th color-blind man in a row he realized
for the first time in hist life that it was _him_, being the color-blind.
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git and announcing v1.4.1-rc1
From: Pádraig Brady @ 2006-06-23 14:04 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Junio C Hamano, Git Mailing List,
Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.63.0606231305000.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 22 Jun 2006, Linus Torvalds wrote:
>
>
>>On Thu, 22 Jun 2006, Junio C Hamano wrote:
>>
>>> - diff --color (Johannes).
>>
>> - default to red/green for old/new lines. That's the norm, I'd think.
>
>
> ... and which happens to be useless for 10% of the male population (and
> even more if you look specifically at Asian people). But then, I just
> pasted that part from somewhere else.
:)
So 10% of the male population need to learn
traffic light positions rather than colours?
I'm red/green colour blind which means I can't
distinguish _subtley_ different shades of red and green.
vim is another fondue fork offender as it merges
syntax highlighting and diff colours in diff mode (vimdiff).
I put the following in ~/.vimrc to disable that madness:
if &diff
"I'm only interested in diff colours
syntax off
endif
Pádraig.
^ permalink raw reply
* Re: [PATCH] Customizable error handlers
From: Petr Baudis @ 2006-06-23 13:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060623133227.27854.65567.stgit@machine.or.cz>
Dear diary, on Fri, Jun 23, 2006 at 03:32:27PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 5d543d2..e954002 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -36,9 +36,13 @@ #endif
> #endif
>
> /* General helper functions */
> -extern void usage(const char *err) NORETURN;
> -extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
> -extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
> +void usage(const char *err) NORETURN;
> +void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
> +int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
Wah, this kind of slipped through. Below is a patch without the
externs removed. Sorry about the noise.
> int error(const char *err, ...)
> {
> va_list params;
> + int ret;
>
> va_start(params, err);
> - report("error: ", err, params);
> + ret = error_routine(err, params);
> va_end(params);
> - return -1;
> + return ret;
> }
BTW, I don't mind if you just force the return value to -1 here.
It might be saner.
---
[PATCH] Customizable error handlers
This patch makes the usage(), die() and error() handlers customizable.
Nothing in the git code itself uses that but many other libgit users
(like Git.pm) will.
This is implemented using the mutator functions primarily because you
cannot directly modifying global variables of libgit from a program that
dlopen()ed it, apparently. But having functions for that is a better API
anyway.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
diff --git a/git-compat-util.h b/git-compat-util.h
index 5d543d2..0c5ceb3 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -40,6 +40,10 @@ extern void usage(const char *err) NORET
extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
+extern void set_usage_routine(void (*routine)(const char *err) NORETURN);
+extern void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN);
+extern void set_error_routine(int (*routine)(const char *err, va_list params));
+
#ifdef NO_MMAP
#ifndef PROT_READ
diff --git a/usage.c b/usage.c
index 1fa924c..445456d 100644
--- a/usage.c
+++ b/usage.c
@@ -12,28 +12,68 @@ static void report(const char *prefix, c
fputs("\n", stderr);
}
-void usage(const char *err)
+void usage_builtin(const char *err)
{
fprintf(stderr, "usage: %s\n", err);
exit(129);
}
+void die_builtin(const char *err, va_list params)
+{
+ report("fatal: ", err, params);
+ exit(128);
+}
+
+int error_builtin(const char *err, va_list params)
+{
+ report("error: ", err, params);
+ return -1;
+}
+
+
+/* If we are in a dlopen()ed .so write to a global variable would segfault
+ * (ugh), so keep things static. */
+static void (*usage_routine)(const char *err) NORETURN = usage_builtin;
+static void (*die_routine)(const char *err, va_list params) NORETURN = die_builtin;
+static int (*error_routine)(const char *err, va_list params) = error_builtin;
+
+void set_usage_routine(void (*routine)(const char *err) NORETURN)
+{
+ usage_routine = routine;
+}
+
+void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN)
+{
+ die_routine = routine;
+}
+
+void set_error_routine(int (*routine)(const char *err, va_list params))
+{
+ error_routine = routine;
+}
+
+
+void usage(const char *err)
+{
+ usage_routine(err);
+}
+
void die(const char *err, ...)
{
va_list params;
va_start(params, err);
- report("fatal: ", err, params);
+ die_routine(err, params);
va_end(params);
- exit(128);
}
int error(const char *err, ...)
{
va_list params;
+ int ret;
va_start(params, err);
- report("error: ", err, params);
+ ret = error_routine(err, params);
va_end(params);
- return -1;
+ return ret;
}
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply related
* [PATCH] git-commit: allow -e option anywhere on command line
From: Jeff King @ 2006-06-23 13:43 UTC (permalink / raw)
To: junkio; +Cc: git
Previously, the command 'git-commit -e -m foo' would ignore the '-e' option
because the '-m' option overwrites the no_edit flag during sequential
option parsing. Now we cause -e to reset the no_edit flag after all
options are parsed.
Signed-off-by: Jeff King <peff@peff.net>
---
git-commit.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 6dd04fd..4bb16db 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -199,6 +199,7 @@ only=
logfile=
use_commit=
amend=
+edit_flag=
no_edit=
log_given=
log_message=
@@ -246,7 +247,7 @@ do
shift
;;
-e|--e|--ed|--edi|--edit)
- no_edit=
+ edit_flag=t
shift
;;
-i|--i|--in|--inc|--incl|--inclu|--includ|--include)
@@ -384,6 +385,7 @@ do
;;
esac
done
+case "$edit_flag" in t) no_edit= ;; esac
################################################################
# Sanity check options
--
1.4.1.rc1.gf603-dirty
^ permalink raw reply related
* [PATCH] Customizable error handlers
From: Petr Baudis @ 2006-06-23 13:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch makes the usage(), die() and error() handlers customizable.
Nothing in the git code itself uses that but many other libgit users
(like Git.pm) will.
This is implemented using the mutator functions primarily because you
cannot directly modifying global variables of libgit from a program that
dlopen()ed it, apparently. But having functions for that is a better API
anyway.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-compat-util.h | 10 +++++++---
usage.c | 50 +++++++++++++++++++++++++++++++++++++++++++++-----
2 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 5d543d2..e954002 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -36,9 +36,13 @@ #endif
#endif
/* General helper functions */
-extern void usage(const char *err) NORETURN;
-extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
-extern int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
+void usage(const char *err) NORETURN;
+void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
+int error(const char *err, ...) __attribute__((format (printf, 1, 2)));
+
+void set_usage_routine(void (*routine)(const char *err) NORETURN);
+void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN);
+void set_error_routine(int (*routine)(const char *err, va_list params));
#ifdef NO_MMAP
diff --git a/usage.c b/usage.c
index 1fa924c..445456d 100644
--- a/usage.c
+++ b/usage.c
@@ -12,28 +12,68 @@ static void report(const char *prefix, c
fputs("\n", stderr);
}
-void usage(const char *err)
+void usage_builtin(const char *err)
{
fprintf(stderr, "usage: %s\n", err);
exit(129);
}
+void die_builtin(const char *err, va_list params)
+{
+ report("fatal: ", err, params);
+ exit(128);
+}
+
+int error_builtin(const char *err, va_list params)
+{
+ report("error: ", err, params);
+ return -1;
+}
+
+
+/* If we are in a dlopen()ed .so write to a global variable would segfault
+ * (ugh), so keep things static. */
+static void (*usage_routine)(const char *err) NORETURN = usage_builtin;
+static void (*die_routine)(const char *err, va_list params) NORETURN = die_builtin;
+static int (*error_routine)(const char *err, va_list params) = error_builtin;
+
+void set_usage_routine(void (*routine)(const char *err) NORETURN)
+{
+ usage_routine = routine;
+}
+
+void set_die_routine(void (*routine)(const char *err, va_list params) NORETURN)
+{
+ die_routine = routine;
+}
+
+void set_error_routine(int (*routine)(const char *err, va_list params))
+{
+ error_routine = routine;
+}
+
+
+void usage(const char *err)
+{
+ usage_routine(err);
+}
+
void die(const char *err, ...)
{
va_list params;
va_start(params, err);
- report("fatal: ", err, params);
+ die_routine(err, params);
va_end(params);
- exit(128);
}
int error(const char *err, ...)
{
va_list params;
+ int ret;
va_start(params, err);
- report("error: ", err, params);
+ ret = error_routine(err, params);
va_end(params);
- return -1;
+ return ret;
}
^ permalink raw reply related
* Re: [PATCH] Introduce Git.pm (v3)
From: Petr Baudis @ 2006-06-23 12:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e7g079$8qt$1@sea.gmane.org>
Dear diary, on Fri, Jun 23, 2006 at 08:03:23AM CEST, I got a letter
where Jakub Narebski <jnareb@gmail.com> said that...
> Perhaps Git.pm should provide also generic, pure Perl (and slower)
> fallback implementation (when for some reason we cannot compile XS).
I fiercely want to avoid this if there is any other possible way to go
about it - this is a path to hell of massive code duplication and
additional work, as the number of routines will grow. If it is question
of spending many developer-hours uselessly duplicating code in a way
that'll be much slower than possible anyway OR building with -fPIC... ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] git-merge --squash
From: Thomas Glanzmann @ 2006-06-23 12:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0606231433370.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hello,
> Isn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT
> by cherry picking my way through a messy branch, often combining patches
> by '-n'.
yes it is. I didn't know about the cherry-pick -n option. Thanks.
Thomas
^ permalink raw reply
* Re: [PATCH] Introduce Git.pm (v3)
From: Petr Baudis @ 2006-06-23 12:39 UTC (permalink / raw)
To: Junio C Hamano, Eric W. Biederman; +Cc: git
In-Reply-To: <7vejxgckq9.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Jun 23, 2006 at 10:57:50AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > Also, is there any real problem with just using -fPIC?
>
> Personally, not really, but I consider it a workaround having to
> compile with -fPIC (being able to compile with -fPIC is a
> feature).
Well, for the .xs you do need an .so and for that you apparently need
-fPIC on most architectures, so there's no way around it.
There's a patch to build libgit.so, would you take it as an excuse to
always compile with -fPIC? ;-)
> Doesn't it have performance implications to use -fPIC when you
> do not have to?
No idea here.
> By the way, you also need to adjust the testsuite so that it
> finds the Perl modules from freshly built tree before
> installing. I think (but haven't checked yet) the stuff written
> in Python does that already, so you might want to mimic it.
It should be enough to -I../perl/blib/lib -I../perl/blib/arch/auto/Git.
Dear diary, on Fri, Jun 23, 2006 at 02:04:17PM CEST, I got a letter
where "Eric W. Biederman" <ebiederm@xmission.com> said that...
> The question is why are we building with a .so?
To make use of it in Git.pm - it can call libgit routines directly from
inside of Perl, but for that it needs to dynamically link libgit to the
Perl process on the fly (using dlopen()).
We _can_ avoid the .so, but that involved producing a new perl
executable with libgit statically linked to it, which is quite
impractical, so to say.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* Re: [PATCH] git-merge --squash
From: Johannes Schindelin @ 2006-06-23 12:36 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Junio C Hamano, git
In-Reply-To: <20060623122501.GD15631@cip.informatik.uni-erlangen.de>
Hi,
On Fri, 23 Jun 2006, Thomas Glanzmann wrote:
> Hello Junio,
>
> > So in that sense I would imagine --squash is not really useless
> > in such a situation as I made it sound like, but at the same
> > time I suspect people might be better off to use tools like
> > StGIT which are specially designed to support such a workflow if
> > they were to do this.
>
> thanks for --squash. So --squash is basically a 'suck multiple deltas
> from another branch into ., but don't commit it'. I very often use that
> way of work flow. I do small and many commits, and when I am done I
> merge them to one a bit bigger one and submit it upstream. I useally use
> 'one branch per feature'.
Isn't this the same as 'git-cherry-pick -n'? I often do a poor man's StGIT
by cherry picking my way through a messy branch, often combining patches
by '-n'.
Ciao,
Dscho
^ permalink raw reply
* Re: git-format-patch builtin isn't using git-cherry?
From: Johannes Schindelin @ 2006-06-23 12:33 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: martin.langhoff, git
In-Reply-To: <20060623152321.2c20e9f8.tihirvon@gmail.com>
Hi,
On Fri, 23 Jun 2006, Timo Hirvonen wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > Basically, it will involve the following recipe:
> >
> > - add a DIFF_FORMAT_PATCH_ID
>
> Please don't add any DIFF_FORMAT_*. I'm cleaning the diff output code
> and replacing diff_options.output_format with one-bit flags.
Okay. For the purposes of git-format-patch, this is not needed anyway, but
rather a function which takes two tree objects and returns the patch id.
When you are finished it should be easy to add this as a display format.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-merge --squash
From: Thomas Glanzmann @ 2006-06-23 12:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5d09pe2.fsf@assigned-by-dhcp.cox.net>
Hello Junio,
> So in that sense I would imagine --squash is not really useless
> in such a situation as I made it sound like, but at the same
> time I suspect people might be better off to use tools like
> StGIT which are specially designed to support such a workflow if
> they were to do this.
thanks for --squash. So --squash is basically a 'suck multiple deltas
from another branch into ., but don't commit it'. I very often use that
way of work flow. I do small and many commits, and when I am done I
merge them to one a bit bigger one and submit it upstream. I useally use
'one branch per feature'.
Thomas
^ permalink raw reply
* Re: git-format-patch builtin isn't using git-cherry?
From: Timo Hirvonen @ 2006-06-23 12:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: martin.langhoff, git
In-Reply-To: <Pine.LNX.4.63.0606231357420.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Basically, it will involve the following recipe:
>
> - add a DIFF_FORMAT_PATCH_ID
Please don't add any DIFF_FORMAT_*. I'm cleaning the diff output code
and replacing diff_options.output_format with one-bit flags.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: git-format-patch builtin isn't using git-cherry?
From: Johannes Schindelin @ 2006-06-23 12:05 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90606221732k6d93bcceic2761081d7a7c72b@mail.gmail.com>
Hi,
On Fri, 23 Jun 2006, Martin Langhoff wrote:
> Reading cmd_format_patch() in builtin-log.c, it seems to have lost that
> magic that made it so useful... :( Can a kind soul that speaks C
> fluently help me out here?
My fault. But note that it is much faster now, too! I think I can trick it
back into doing something like the old script, but I'll do that only with
an option (in order to not slow down the now-common case). And it will
take a while. So if anybody wants to give it a try...
Basically, it will involve the following recipe:
- add a DIFF_FORMAT_PATCH_ID
- calculate _all_ the patch ids in upstream since branch point
- in cmd_format_patch, in the get_revision() loop, skip those
commits which have the same patch id
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce Git.pm (v3)
From: Eric W. Biederman @ 2006-06-23 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vejxgckq9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Petr Baudis <pasky@suse.cz> writes:
>
>> Also, is there any real problem with just using -fPIC?
>
> Personally, not really, but I consider it a workaround having to
> compile with -fPIC (being able to compile with -fPIC is a
> feature).
>
> Doesn't it have performance implications to use -fPIC when you
> do not have to?
>
> By the way, you also need to adjust the testsuite so that it
> finds the Perl modules from freshly built tree before
> installing. I think (but haven't checked yet) the stuff written
> in Python does that already, so you might want to mimic it.
So what was being compiled was a shared Git.so.
32bit x86 is on of the few architectures that allows you to build
a .so without compiling with -fPIC.
The question is why are we building with a .so?
Eric
^ permalink raw reply
* Re: [PATCH] Make -p --stat and --stat -p behave like --patch-with-stat
From: Timo Hirvonen @ 2006-06-23 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: junkio, git
In-Reply-To: <7vr71hkofg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> The diff output has four parts, each of which can independently
> be enabled. When no options are specified on the command line,
> each command has its own default but in general the low-level
> commands default to raw output only, and the higher-level ones
> default to patch output only.
>
> The four parts are controlled with a bit each, and are output in
> the fixed order (iow the order of the options given from the
> command line does not matter): raw, stat, summary and patch.
>
> When --name-only or --name-status is specified, that would be
> the only thing that is output (iow the above four parts would
> not be shown, just names optionally with the status are shown).
>
> The four switches are: --raw, --stat, --summary and --patch.
> Existing flags are supported as obvious shorthands to turn on
> the corresponding bits:
>
> -p, -u --patch
> --patch-with-raw --raw --patch
> --patch-with-stat --stat --patch
>
> Anybody interested in doing a patch?
I'll try. It shouldn't be too hard.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Never-seen Onlinee Casino. Go and Playy It
From: Walker @ 2006-06-23 11:37 UTC (permalink / raw)
To: glenn
Age is a very high price to pay for maturity If cow-man pass wild meat whah mek me must pick up am.
Online Casino witth 85+ games. Play It Now! http://ewcnss.com/d1/check
Old habits die hard Haste makes waste.
^ permalink raw reply
* A series file for git?
From: Eric W. Biederman @ 2006-06-23 11:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vpshtyffk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> (a) git-rev-list --pretty=oneline "$upstream"..ORIG_HEAD > rev-list
>>
>> (b) edit the rev-list, moving the single lines around, deleting them, etc
>>
>> (c) cat rev-list |
>> git-format-patch -k --stdout --stdin --full_index |
>> git-am
>>
> Tentatively my feeling is that we should make it known that the
> list format-patch takes from --stdin is supposed to be _not_
> reversed, and do nothing in format-patch. In other words, the
> list fed is a moral equivalent to quilt "series" file.
Agreed that seem to make a lot of sense.
> What this means is:
>
> git-format-patch $revargs
>
> is not equivalent to
>
> git-rev-list $revargs | git-format-patch --stdin
>
> but is equivalent to
>
> git-rev-list $revargs | tac | git-format-patch --stdin
At least for now the using tac is fine. Longer term I think
having some reverse arguments to rev-list or even better
git-log so we can review patches in order instead backwards
would be very interesting.
> Thoughts from the list?
So I have played with this some and a bit of feedback.
I was using:
git-rev-list $revargs | tac > list
for sha1 in $(cat list); do git-cherry-pick -r $sha1 ; done
Is there any real difference between using git-format-patch | git-am
and using git-am to apply patches. I was using git-cherry-pick simply
because it was easier to sha1 too.
- When you reorder patches minor merge conflicts are common
so a big pipe won't work very often in practice. So you
need a way to handle failures in the middle.
- Keeping patches in git and just remembering their sha1 is nice
but it has the downside that it can be really easy to loose
the sha1, and thus the patch. So some sort of history mechanism
so you can get back to where you were would be nice.
- This is a similar technique to topic branches. However in some
of the more interesting cases a topic branch can't be used because
you have a whole series of little changes, that allow depend on
each other. So topic branches need not apply.
- One of the places where we currently uses series files
(patch-scripts && quilt), and heavy cherry picking is for patch
aging. That is letting patches sit in a testing branch for
a while so people have a chance to test and look at them.
The important pieces there are the ability to reorder the changes
to put the patches with the highest confidence first.
The ability to comment on the patches so that it is possible
to record groups of patches and information about their relative
stability. As once a patch series gets large without at least
a few comments it is too much for a person to remember what
is happening with each patch without a few clues.
- The other place where we use series files is in pure development
where we are breaking up or otherwise creating the needed changes
in a set of simple obviously correct changes.
....
So I think it could be very interesting to have a series file
as something the base git porcelain helps to deal with.
If we create a meta data branch with just the series file
we can remove the risk of loosing things, as we always
have a path back to the old history if we want it.
We can keep track of the series file with a SERIES_HEAD
similar to FETCH_HEAD. This fairly easily allows editing
in different places in the patch stack that normally happens
with quilt or patch-scripts.
We can put comments in a series file to keep track of probationary
patches.
The two tricky pieces I see with this idea are:
- teaching git-fsck-objects that we have a sha1 in a blob objects.
- Where to put the active checkout series file when we are working,
so we don't stumble on it.
...
I'm trying to sort out a sane work flow for developing with a large
number of highly related patches on the development side. I care
because the way I think I usually fix the root cause of problems.
It took me nearly 25 patches to decouple the brain damage the msi
code imposed on x86 irq handling. In the development of that
I had to reorder and edit things extensively as I broke the
work up, and created a sane patch flow.
The trick with rev-list | tac to create a series file for reordering
changes was very useful but it wasn't enough to say it solve the
problem.
One trivial issue was that git-cherry-pick -r always does the full
git-commit so it is much more I/O bound than necessary, because
git-commit does git-status. Which is just silly if you are applying
a bunch of changes that apply without errors.
Eric
^ permalink raw reply
* The newest Online Casinno. Go and Play It
From: Estela @ 2006-06-23 11:32 UTC (permalink / raw)
To: git
God helps those who help themselves
Online Casino with 85+ games. PPlay It Now! http://ewcnss.com/d1/check
So he that goeth in to his neighbour's wife; whosoever toucheth her shall not be innocent.
^ 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