* [PATCH] diff-tree: Use ---\n as a message separator
From: Timo Hirvonen @ 2006-06-27 12:39 UTC (permalink / raw)
To: junkio; +Cc: git
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
builtin-diff-tree.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-diff-tree.c b/builtin-diff-tree.c
index ae1cde9..1e66fca 100644
--- a/builtin-diff-tree.c
+++ b/builtin-diff-tree.c
@@ -72,6 +72,7 @@ int cmd_diff_tree(int argc, const char *
init_revisions(opt);
opt->abbrev = 0;
opt->diff = 1;
+ opt->diffopt.msg_sep = "---\n";
argc = setup_revisions(argc, argv, opt, NULL);
while (--argc > 0) {
--
1.4.1.rc1.g5576-dirty
^ permalink raw reply related
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-27 12:39 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <46a038f90606270409t6724b105h6c56d55138fd58c5@mail.gmail.com>
Hi,
On Tue, 27 Jun 2006, Martin Langhoff wrote:
> the patches should be rather obvious, GNU patch recognises them as
> 'already applied', but they may be slightly different in ways that
> break the hashing.
Did you try with git-apply? This is much more anal than GNU patch, and
should give you an idea what is happening.
> I'll play with git-cherry to see, I assume that you've copied the logic
> from there.
Yup. Well, from git-patch-id, but that was used by git-cherry.
Note that I made sure that the patch-id is the same as for git-patch-id.
It only differs with renaming patches (the "---" and "+++" lines are
hashed, to make sure it is the same patch, but the "rename from" and
"rename to" lines are not generated by diff_flush_patch_id()).
Ciao,
Dscho
^ permalink raw reply
* Re: CFT: merge-recursive in C
From: Alex Riesen @ 2006-06-27 12:17 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, Fredrik Kuivinen
In-Reply-To: <20060626233838.GA3121@steel.home>
On 6/27/06, Alex Riesen <fork0@t-online.de> wrote:
> Hi all.
>
> I finally got pis^Witched enough by my platform at work and decided
> to start the effort of converting Fredriks git-merge-recursive to C.
> At the moment it is the only one annoyingly slow thing there.
>
Just tested it on my project. It's still the slow thing (even a bit
slower, looks CPU bound).
^ permalink raw reply
* [PATCH] Print empty line between raw, stat, summary and patch
From: Timo Hirvonen @ 2006-06-27 12:09 UTC (permalink / raw)
To: junkio; +Cc: git
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
Should we print options->line_termination instead of \n between all
fields? The old code didn't support as many combinations of raw,
stat, summary and patch so I'm not 100% sure about this.
diff.c | 47 ++++++++++++++++++++++++++++++++++++++++++-----
1 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/diff.c b/diff.c
index 8880150..2c47f11 100644
--- a/diff.c
+++ b/diff.c
@@ -2040,15 +2040,43 @@ static void diff_summary(struct diff_fil
}
}
+static int is_summary_empty(const struct diff_queue_struct *q)
+{
+ int i;
+
+ for (i = 0; i < q->nr; i++) {
+ const struct diff_filepair *p = q->queue[i];
+
+ switch (p->status) {
+ case DIFF_STATUS_DELETED:
+ case DIFF_STATUS_ADDED:
+ case DIFF_STATUS_COPIED:
+ case DIFF_STATUS_RENAMED:
+ return 0;
+ default:
+ if (p->score)
+ return 0;
+ if (p->one->mode && p->two->mode &&
+ p->one->mode != p->two->mode)
+ return 0;
+ break;
+ }
+ }
+ return 1;
+}
+
void diff_flush(struct diff_options *options)
{
struct diff_queue_struct *q = &diff_queued_diff;
int i, output_format = options->output_format;
+ int separator = 0;
/*
* Order: raw, stat, summary, patch
* or: name/name-status/checkdiff (other bits clear)
*/
+ if (!q->nr)
+ goto free_queue;
if (output_format & (DIFF_FORMAT_RAW |
DIFF_FORMAT_NAME |
@@ -2059,11 +2087,15 @@ void diff_flush(struct diff_options *opt
if (check_pair_status(p))
flush_one_pair(p, options);
}
+ separator++;
}
if (output_format & DIFF_FORMAT_DIFFSTAT) {
struct diffstat_t diffstat;
+ if (separator++)
+ putchar('\n');
+
memset(&diffstat, 0, sizeof(struct diffstat_t));
diffstat.xm.consume = diffstat_consume;
for (i = 0; i < q->nr; i++) {
@@ -2074,18 +2106,22 @@ void diff_flush(struct diff_options *opt
show_stats(&diffstat);
}
- if (output_format & DIFF_FORMAT_SUMMARY) {
+ if (output_format & DIFF_FORMAT_SUMMARY && !is_summary_empty(q)) {
+ if (separator++)
+ putchar('\n');
+
for (i = 0; i < q->nr; i++)
diff_summary(q->queue[i]);
}
if (output_format & DIFF_FORMAT_PATCH) {
- if (output_format & (DIFF_FORMAT_DIFFSTAT |
- DIFF_FORMAT_SUMMARY)) {
- if (options->stat_sep)
+ if (separator) {
+ if (options->stat_sep) {
+ /* attach patch instead of inline */
fputs(options->stat_sep, stdout);
- else
+ } else {
putchar(options->line_termination);
+ }
}
for (i = 0; i < q->nr; i++) {
@@ -2097,6 +2133,7 @@ void diff_flush(struct diff_options *opt
for (i = 0; i < q->nr; i++)
diff_free_filepair(q->queue[i]);
+free_queue:
free(q->queue);
q->queue = NULL;
q->nr = q->alloc = 0;
--
1.4.1.rc1.g8637
^ permalink raw reply related
* Re: CFT: merge-recursive in C
From: Alex Riesen @ 2006-06-27 11:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Fredrik Kuivinen
In-Reply-To: <Pine.LNX.4.63.0606271248270.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > - have you considered using run-command() instead of system()?
> >
> > No. What run-program?
>
> run-command.c:run_command(). Call it like this:
>
> int return_code = run_command("git-read-tree", sha1_to_hex(sha1), NULL);
>
Oh, I see. Will convert right away.
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Martin Langhoff @ 2006-06-27 11:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <Pine.LNX.4.63.0606271251440.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > It does, but it may be "right" even though it's not realising that
> > some of the patches were cherry picked. git-cherry doesn't either. So
> > that algorythm isn't so hot in this case :-/
>
> What do you mean? Is the patch-id of the cherry-picked different? (If
> there was a conflict which was manually resolved, I think there is no way
> we can detect that that patch was cherry-picked, but if it applied
> cleanly, the patch-id should be equal both in upstream and downstream.)
I'll look more into it tomorrow at work. Knowing the codebase, some of
the patches should be rather obvious, GNU patch recognises them as
'already applied', but they may be slightly different in ways that
break the hashing. Maybe. I'll play with git-cherry to see, I assume
that you've copied the logic from there.
cheers,
martin
^ permalink raw reply
* Re: [TRYTHIS] cvsimport: fix initial import
From: Johannes Schindelin @ 2006-06-27 11:01 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <46a038f90606270352w32e3888dk1557eefbe1043d92@mail.gmail.com>
Hi,
On Tue, 27 Jun 2006, Martin Langhoff wrote:
> this patch doesn't quite make sense to me. The git-read-tree should be
> in the else block of the unless you have right there (and it's
> actually there, but it may be breaking in some cases? Perhaps should
> happen a bit earlier?).
>
> How do you expect to run git-read-tree or die _before_ git-init-db?
Oops. I even do not remember what I smoked.
The git-read-tree before git-init-db evidently only works if this is not
the initial import. Which it wasn't in my case.
And I keep getting confused with the "if" and "unless" sometimes
prepended, sometimes appended. Well, that is Perl before Swine for me ;-)
How about this instead:
git-cvsimport.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 50f5d96..4caef10 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -470,8 +470,6 @@ my %index; # holds filenames of one inde
$index{$opt_o} = tmpnam();
$ENV{GIT_INDEX_FILE} = $index{$opt_o};
-system("git-read-tree", $opt_o);
-die "read-tree failed: $?\n" if $?;
unless(-d $git_dir) {
system("git-init-db");
@@ -482,6 +480,8 @@ unless(-d $git_dir) {
$last_branch = $opt_o;
$orig_branch = "";
} else {
+ system("git-read-tree", $opt_o);
+ die "read-tree failed: $?\n" if $?;
-f "$git_dir/refs/heads/$opt_o"
or die "Branch '$opt_o' does not exist.\n".
"Either use the correct '-o branch' option,\n".
^ permalink raw reply related
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-27 10:54 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <46a038f90606270252p2beac88bo3cf7aa8d3845450c@mail.gmail.com>
Hi,
On Tue, 27 Jun 2006, Martin Langhoff wrote:
> On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > I just cloned your repo, and as far as I can tell, the latest commit is on
> > June 23rd. So your numbers should be the same as mine. But not all are.
>
> Taht repo is on a machine at work, but it's possible that I've cherry
> picked a new commit onto master that isn't on the publc repo yet.
I hoped that much.
> > (Did not test here, since I do not have an old git-format-patch.sh
> > handy, and am too lazy to get the last version from my git repo.)
>
> I think I did something like
>
> git-cat-file blob v1.3.3:git-format-patch.sh > git-format-patch.sh
> chmod ugo+x git-format-patch.sh
Yes, I am lazy.
> > But anyway, looking at your numbers I take it that the new format-patch
> > with --ignore-if-in-upstream has the same output as the old format-patch,
> > right?
>
> It does, but it may be "right" even though it's not realising that
> some of the patches were cherry picked. git-cherry doesn't either. So
> that algorythm isn't so hot in this case :-/
What do you mean? Is the patch-id of the cherry-picked different? (If
there was a conflict which was manually resolved, I think there is no way
we can detect that that patch was cherry-picked, but if it applied
cleanly, the patch-id should be equal both in upstream and downstream.)
Ciao,
Dscho
^ permalink raw reply
* Re: [TRYTHIS] cvsimport: fix initial import
From: Martin Langhoff @ 2006-06-27 10:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andreas Ericsson, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0606271234350.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Hi Johannes,
this patch doesn't quite make sense to me. The git-read-tree should be
in the else block of the unless you have right there (and it's
actually there, but it may be breaking in some cases? Perhaps should
happen a bit earlier?).
How do you expect to run git-read-tree or die _before_ git-init-db?
cheers,
martin
^ permalink raw reply
* Re: CFT: merge-recursive in C
From: Johannes Schindelin @ 2006-06-27 10:51 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano, Fredrik Kuivinen
In-Reply-To: <81b0412b0606270158i16ebee20me81ca2b9fa71db5c@mail.gmail.com>
Hi,
On Tue, 27 Jun 2006, Alex Riesen wrote:
> On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > I finally got pis^Witched enough by my platform at work and decided
> > > to start the effort of converting Fredriks git-merge-recursive to C.
> >
> > Darn. I was working on the same thing since a few days.
>
> I didn't know :)
Vice versa, I guess.
> > - have you considered using run-command() instead of system()?
>
> No. What run-program?
run-command.c:run_command(). Call it like this:
int return_code = run_command("git-read-tree", sha1_to_hex(sha1), NULL);
> > - in setup_index(), you set GIT_INDEX_FILE, but I do not think that the
> > rest of git picks up on it. environment.cc:get_index_file() checks if
> > the variable was set already, but not if it changed.
>
> Not even sure it's needed. Leftover from conversion
I think it _is_ needed, in order not to mess up the current index. Setting
the environment variable works for exec()ed processes, but I think we need
to add a set_index_file(const char *) to environment.c.
> > - I always wondered why merge-recursive did not call merge-base, but did
> > its own thing. Hmm?
>
> No idea yet.
Frederik?
Ciao,
Dscho
^ permalink raw reply
* Re: cvs importer woes
From: Andreas Ericsson @ 2006-06-27 10:49 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90606270342k2288cc2ds34ae05e089b8c906@mail.gmail.com>
Martin Langhoff wrote:
> On 6/27/06, Andreas Ericsson <ae@op5.se> wrote:
>
>> Sadly, the cvsimport command no longer works to create new repositories
>> from scratch.
>
>
> We are seeing some breakage in cvsimport that started with a patch of mine:
>
> 8f732649bc4d5619a1b399e5808b3f4c662ad200 cvsimport: keep one index
> per branch during import
>
I experimented a bit with that one too, but it worked for my (very
small, no branches, no tags) cvs repo
>
>> The culprit is definitely 061303f0b50a648db8e0af23791fc56181f6bf93.
>>
>> Any perl-literate takers? Otherwise, just reverting the patch makes
>> things work (for me) again.
>
>
> Don't just revert that patch, unless I'm wrong there is some subtle
> branch-creation breakage too.
>
Dscho's patch on top of 061303f0b works wonders. Thanks all the same though.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: cvs importer woes
From: Martin Langhoff @ 2006-06-27 10:42 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <44A102F0.9090604@op5.se>
On 6/27/06, Andreas Ericsson <ae@op5.se> wrote:
> Sadly, the cvsimport command no longer works to create new repositories
> from scratch.
We are seeing some breakage in cvsimport that started with a patch of mine:
8f732649bc4d5619a1b399e5808b3f4c662ad200 cvsimport: keep one index
per branch during import
so I'd say that if you are using cvsimport, stick to the v1.4.0
version. You can do
git-cat-file blob v1.4.0:git-cvsimport.perl >git-cvsimport.perl
> problem seems to be firstly 061303f0b50a648db8e0af23791fc56181f6bf93.
Yes, that commit will break brand new imports, but it's trying to
fixup breakage that started with my patch. It shouldn't be too hard to
fix up, but real life is interfering.
> Oh, now it's done (4 minutes for 620 revisions with automated testing
> between good/bad. *LOVE* bisect).
Love bisect too for easy-to-test cases.
> The culprit is definitely 061303f0b50a648db8e0af23791fc56181f6bf93.
>
> Any perl-literate takers? Otherwise, just reverting the patch makes
> things work (for me) again.
Don't just revert that patch, unless I'm wrong there is some subtle
branch-creation breakage too.
cheers,
martin
^ permalink raw reply
* Re: [TRYTHIS] cvsimport: fix initial import
From: Andreas Ericsson @ 2006-06-27 10:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0606271234350.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> ---
> Hi,
>
> On Tue, 27 Jun 2006, Andreas Ericsson wrote:
>
>
>>Sadly, the cvsimport command no longer works to create new repositories from
>>scratch. I'm not nearly perl literate enough to fix it, but the problem seems
>>to be firstly 061303f0b50a648db8e0af23791fc56181f6bf93.
>
>
> My bad. Could you try this patch on top of 'next'?
>
Works wonderfully. Weird that it didn't when I removed the read-tree
completely. There was probably some pilot error involved on my part
there and then.
Thanks, and ack.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [TRYTHIS] cvsimport: fix initial import
From: Johannes Schindelin @ 2006-06-27 10:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <44A102F0.9090604@op5.se>
---
Hi,
On Tue, 27 Jun 2006, Andreas Ericsson wrote:
> Sadly, the cvsimport command no longer works to create new repositories from
> scratch. I'm not nearly perl literate enough to fix it, but the problem seems
> to be firstly 061303f0b50a648db8e0af23791fc56181f6bf93.
My bad. Could you try this patch on top of 'next'?
git-cvsimport.perl | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 50f5d96..f8eb6ef 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -471,7 +471,6 @@ my %index; # holds filenames of one inde
$ENV{GIT_INDEX_FILE} = $index{$opt_o};
system("git-read-tree", $opt_o);
-die "read-tree failed: $?\n" if $?;
unless(-d $git_dir) {
system("git-init-db");
^ permalink raw reply related
* Re: Rework a patch serie
From: Karl Hasselström @ 2006-06-27 10:16 UTC (permalink / raw)
To: moreau francis; +Cc: git
In-Reply-To: <20060627084130.28886.qmail@web25814.mail.ukl.yahoo.com>
On 2006-06-27 08:41:30 +0000, moreau francis wrote:
> Then I submit these patches for reviewing. Unfortunately, they're
> not perfect, so after some feedbacks from the communauty it appears
> that I need to make small modifications in the second commit in the
> topic branch for example...
>
> What is the best and fastest way to do that ? Should I create a new
> topic branch and cherry pick from the old one ?
stgit is a good fit for this situation. You just pop patches off the
stack untill you reach the one you want to modify, then do your
changes, refresh the patch, and push the other patches back. (If you
want to keep the original series for future reference, you can simply
tag HEAD before you embark on this procedure.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* cvs importer woes
From: Andreas Ericsson @ 2006-06-27 10:05 UTC (permalink / raw)
To: Git Mailing List
Sadly, the cvsimport command no longer works to create new repositories
from scratch. I'm not nearly perl literate enough to fix it, but the
problem seems to be firstly 061303f0b50a648db8e0af23791fc56181f6bf93. In
particular "Also, make sure that the initial git-read-tree is
performed." which fails if there is not a complete git repo already
created with at least one tree committed.
Some sample output:
$ git cvsimport -k -u -d:local:/home/CVS packages
fatal: Not a git repository: '/data/home/exon/git/packages/.git'
read-tree failed: 32768
Removing the unconditional read-tree call, I get this (still in an empty
directory which isn't a repo):
$ git cvsimport -k -u -d:local:/home/CVS packages
fatal: Not a git repository: '/data/home/exon/git/packages/.git'
read-tree failed: 32768
$ git init-db
defaulting to local storage area
$ git cvsimport -k -u -d:local:/home/CVS packages
fatal: Not a valid object name origin
read-tree failed: 32768
Bisect running now. v1.3.1 is good and imports the stuff properly to an
empty directory.
Oh, now it's done (4 minutes for 620 revisions with automated testing
between good/bad. *LOVE* bisect).
The culprit is definitely 061303f0b50a648db8e0af23791fc56181f6bf93.
Any perl-literate takers? Otherwise, just reverting the patch makes
things work (for me) again.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Martin Langhoff @ 2006-06-27 9:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Langhoff (CatalystIT), git, junkio
In-Reply-To: <Pine.LNX.4.63.0606271016450.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> I just cloned your repo, and as far as I can tell, the latest commit is on
> June 23rd. So your numbers should be the same as mine. But not all are.
Taht repo is on a machine at work, but it's possible that I've cherry
picked a new commit onto master that isn't on the publc repo yet.
> The problem I see: from the 53 non-merges in nzvleportfolio (who makes up
> your branch names anyway?), there are two already in upstream: e3f56c and
> 7e448c5c. So it really should be 51.
>
> > $ git-rev-list svnhead..master | wc -l
> > 61
>
> Same on my repo.
And if you add --no-merges it'll give you 51 or 52, depending...
> > $ ~/local/git/git-format-patch.sh -o .patchesold svnhead master
> > ...
> > $ ls .patchesold | wc -l
> > 52
>
> I guess this propagates from git-cherry. (Did not test here, since I do
> not have an old git-format-patch.sh handy, and am too lazy to get the last
> version from my git repo.)
I think I did something like
git-cat-file blob v1.3.3:git-format-patch.sh > git-format-patch.sh
chmod ugo+x git-format-patch.sh
> But anyway, looking at your numbers I take it that the new format-patch
> with --ignore-if-in-upstream has the same output as the old format-patch,
> right?
It does, but it may be "right" even though it's not realising that
some of the patches were cherry picked. git-cherry doesn't either. So
that algorythm isn't so hot in this case :-/
I jumped to conclusions earlier because I called git format-patch with
the old syntax (theirs ours) and it gave me 186 patches, which may
very well be the whole repo history, like it did earlier with git
itself. I thought that 186 were the patches pending, and that
git-cherry was cutting that to 52. Not so: it was a syntax issue.
Sorry about the noise!
cheers,
martin
^ permalink raw reply
* [PATCH] pre-commit hook: less easily-tripped conflict marker detection
From: Eric Wong @ 2006-06-27 9:06 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Eric Wong
This should make adding asciidoc files to Documentation easier.
Only complain about conflict markers if we see that we have
some combination of '<<<<<<< ', '>>>>>>> ', and '======='.
Also add a NO_VERIFY environment check to this hook, in case
there's something that we want to force in but still gets
tripped by this hook. It'd be a lot more work to add
--no-verify flags to all things that could potentially call this
hook.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
templates/hooks--pre-commit | 32 ++++++++++++++++++++++++++++----
1 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/templates/hooks--pre-commit b/templates/hooks--pre-commit
index 723a9ef..1657f96 100644
--- a/templates/hooks--pre-commit
+++ b/templates/hooks--pre-commit
@@ -1,4 +1,5 @@
#!/bin/sh
+test -n "$NO_VERIFY" && exit 0
#
# An example hook script to verify what is about to be committed.
# Called by git-commit with no arguments. The hook should
@@ -24,8 +25,9 @@ perl -e '
my $filename;
my $reported_filename = "";
my $lineno;
- sub bad_line {
- my ($why, $line) = @_;
+ my $in_unresolved;
+ my @unresolved;
+ sub bad_common {
if (!$found_bad) {
print STDERR "*\n";
print STDERR "* You have some suspicious patch lines:\n";
@@ -36,12 +38,34 @@ perl -e '
print STDERR "* In $filename\n";
$reported_filename = $filename;
}
+ }
+ sub bad_line {
+ my ($why, $line) = @_;
+ bad_common();
print STDERR "* $why (line $lineno)\n";
print STDERR "$filename:$lineno:$line\n";
}
+ sub show_unresolved {
+ # if we want even less easily-tripped checks,
+ # change the "||" to "&&" here. Right now, we can deal with
+ # the case where somebody removed one of the <{7} or >{7} lines
+ # but left the other one (as well as ={7}) in there.
+ if (($unresolved[0]->[0] =~ /^<{7} / ||
+ $unresolved[-1]->[0] =~ /^>{7} /) &&
+ grep { $_->[0] =~ /^={7}$/ } @unresolved) {
+ bad_common();
+ foreach my $l (@unresolved) {
+ print STDERR "* unresolved merge conflict (line $l->[1])\n";
+ print STDERR "$filename:$l->[1]:$l->[0]\n"
+ }
+ }
+ @unresolved = ();
+ }
+
while (<>) {
if (m|^diff --git a/(.*) b/\1$|) {
$filename = $1;
+ show_unresolved() if @unresolved;
next;
}
if (/^@@ -\S+ \+(\d+)/) {
@@ -61,8 +85,8 @@ perl -e '
if (/^\s* /) {
bad_line("indent SP followed by a TAB", $_);
}
- if (/^(?:[<>=]){7}/) {
- bad_line("unresolved merge conflict", $_);
+ if (/^[<>]{7} / || /^={7}$/) {
+ push @unresolved, [ $_, $lineno ];
}
}
}
--
1.4.1.rc1.g2faf-dirty
^ permalink raw reply related
* [PATCH/RFC] Add git-instaweb, instantly browse the working repo with gitweb
From: Eric Wong @ 2006-06-27 9:05 UTC (permalink / raw)
To: git; +Cc: Eric Wong
I got tired of having to configure gitweb for every repository
I work on. I sometimes prefer gitweb to standard GUIs like gitk
or gitview; so this lets me automatically configure gitweb to
browse my working repository and also opens my browser to it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
.gitignore | 1
Documentation/git-instaweb.txt | 84 ++++++++++++++++
Makefile | 16 +++
git-instaweb.sh | 206 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 306 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index 7b954d5..2bcc604 100644
--- a/.gitignore
+++ b/.gitignore
@@ -46,6 +46,7 @@ git-http-push
git-imap-send
git-index-pack
git-init-db
+git-instaweb
git-local-fetch
git-log
git-lost-found
diff --git a/Documentation/git-instaweb.txt b/Documentation/git-instaweb.txt
new file mode 100644
index 0000000..7dd393b
--- /dev/null
+++ b/Documentation/git-instaweb.txt
@@ -0,0 +1,84 @@
+git-instaweb(1)
+===============
+
+NAME
+----
+git-instaweb - instantly browse your working repository in gitweb
+
+SYNOPSIS
+--------
+'git-instaweb' [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
+
+'git-instaweb' [--start] [--stop] [--restart]
+
+DESCRIPTION
+-----------
+A simple script to setup gitweb and a web server for browsing the local
+repository.
+
+OPTIONS
+-------
+
+-l|--local::
+ Only bind the web server to the local IP (127.0.0.1).
+
+-d|--httpd::
+ The HTTP daemon command-line that will be executed.
+ Command-line options may be specified here, and the
+ configuration file will be added at the end of the command-line.
+ Currently, lighttpd and apache2 are the only supported servers.
+ (Default: lighttpd)
+
+-m|--module-path::
+ The module path (only needed if httpd is Apache).
+ (Default: /usr/lib/apache2/modules)
+
+-p|--port::
+ The port number to bind the httpd to. (Default: 1234)
+
+-b|--browser::
+
+ The web browser command-line to execute to view the gitweb page.
+ If blank, the URL of the gitweb instance will be printed to
+ stdout. (Default: 'firefox')
+
+--start::
+ Start the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance.
+
+--stop::
+ Stop the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance,
+ nor does it close the browser.
+
+--restart::
+ Restart the httpd instance and exit. This does not generate
+ any of the configuration files for spawning a new instance.
+
+CONFIGURATION
+-------------
+
+You may specify configuration in your .git/config
+
+-----------------------------------------------------------------------
+[instaweb]
+ local = true
+ httpd = apache2 -f
+ port = 4321
+ browser = konqueror
+ modulepath = /usr/lib/apache2/modules
+
+-----------------------------------------------------------------------
+
+Author
+------
+Written by Eric Wong <normalperson@yhbt.net>
+
+Documentation
+--------------
+Documentation by Eric Wong <normalperson@yhbt.net>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index cde619c..83d8922 100644
--- a/Makefile
+++ b/Makefile
@@ -142,7 +142,7 @@ SCRIPT_PYTHON = \
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
$(patsubst %.py,%,$(SCRIPT_PYTHON)) \
- git-cherry-pick git-status
+ git-cherry-pick git-status git-instaweb
# The ones that do not have to link with lcrypto, lz nor xdiff.
SIMPLE_PROGRAMS = \
@@ -545,6 +545,20 @@ git-status: git-commit
cp $< $@+
mv $@+ $@
+git-instaweb: git-instaweb.sh gitweb/gitweb.cgi gitweb/gitweb.css
+ rm -f $@ $@+
+ sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
+ -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's/@@NO_PYTHON@@/$(NO_PYTHON)/g' \
+ $@.sh | sed \
+ -e 's|@@GITWEB_CGI@@|#!$(PERL_PATH_SQ)|; T; r gitweb/gitweb.cgi' \
+ | sed \
+ -e 's|@@GITWEB_CSS@@||; T; r gitweb/gitweb.css' \
+ > $@+
+ chmod +x $@+
+ mv $@+ $@
+
# These can record GIT_VERSION
git$X git.spec \
$(patsubst %.sh,%,$(SCRIPT_SH)) \
diff --git a/git-instaweb.sh b/git-instaweb.sh
new file mode 100755
index 0000000..8f4b2df
--- /dev/null
+++ b/git-instaweb.sh
@@ -0,0 +1,206 @@
+#!/bin/sh
+#
+# Copyright (c) 2006 Eric Wong
+#
+USAGE='[--start] [--stop] [--restart]
+ [--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
+ [--module-path=<path> (for Apache2 only)]'
+
+. git-sh-setup
+
+if echo $GIT_DIR | grep ^/
+then
+ fqgitdir="$GIT_DIR"
+else
+ fqgitdir="$PWD/$GIT_DIR"
+fi
+
+local="`git repo-config --bool --get instaweb.local`"
+httpd="`git repo-config --get instaweb.httpd`"
+browser="`git repo-config --get instaweb.browser`"
+port=`git repo-config --get instaweb.port`
+module_path="`git repo-config --get instaweb.modulepath`"
+
+conf=$GIT_DIR/gitweb/httpd.conf
+
+# Defaults:
+
+# if installed, it doesn't need further configuration (module_path)
+test -z "$httpd" && httpd='lighttpd -f'
+
+# probably the most popular browser among gitweb users
+test -z "$browser" && browser='firefox'
+
+# any untaken local port will do...
+test -z "$port" && port=1234
+
+start_httpd () {
+ if echo $httpd | grep ^/ >/dev/null || which $httpd >/dev/null
+ then
+ $httpd $fqgitdir/gitweb/httpd.conf
+ else
+ # many httpds are installed in /usr/sbin or /usr/local/sbin
+ # these days and those are not in most users $PATHs
+ httpd_only=`echo $httpd | sed 's/ .*$//'`
+ for i in /usr/local/sbin /usr/sbin
+ do
+ if test -x "$i/$httpd_only"
+ then
+ $i/$httpd $fqgitdir/gitweb/httpd.conf
+ return
+ fi
+ done
+ fi
+}
+
+stop_httpd () {
+ if test -f "$fqgitdir/pid"
+ then
+ kill `cat "$fqgitdir/pid"` 2>/dev/null
+ fi
+}
+
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ --stop|stop)
+ stop_httpd
+ exit 0
+ ;;
+ --start|start)
+ start_httpd
+ exit 0
+ ;;
+ --restart|restart)
+ stop_httpd
+ start_httpd
+ exit 0
+ ;;
+ --local|-l)
+ local=true
+ ;;
+ -d|--httpd|--httpd=*)
+ case "$#,$1" in
+ *,*=*)
+ httpd=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ httpd="$2"
+ shift ;;
+ esac
+ ;;
+ -b|--browser|--browser=*)
+ case "$#,$1" in
+ *,*=*)
+ browser=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ browser="$2"
+ shift ;;
+ esac
+ ;;
+ -p|--port|--port=*)
+ case "$#,$1" in
+ *,*=*)
+ port=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ port="$2"
+ shift ;;
+ esac
+ ;;
+ -m|--module-path=*|--module-path)
+ case "$#,$1" in
+ *,*=*)
+ module_path=`expr "$1" : '-[^=]*=\(.*\)'` ;;
+ 1,*)
+ usage ;;
+ *)
+ module_path="$2"
+ shift ;;
+ esac
+ ;;
+ *)
+ usage
+ ;;
+ esac
+ shift
+done
+
+mkdir -p "$GIT_DIR/gitweb/tmp"
+
+lighttpd_conf () {
+ cat > "$conf" <<EOF
+server.document-root = "$fqgitdir/gitweb"
+server.port = $port
+server.modules = ( "mod_cgi" )
+server.indexfiles = ( "gitweb.cgi" )
+server.pid-file = "$fqgitdir/pid"
+cgi.assign = ( ".cgi" => "" )
+mimetype.assign = ( ".css" => "text/css" )
+EOF
+ test "$local" = true && echo 'server.bind = "127.0.0.1"' >> "$conf"
+}
+
+apache2_conf () {
+ test -z "$module_path" && module_path=/usr/lib/apache2/modules
+ mkdir -p "$GIT_DIR/gitweb/logs"
+ bind=
+ test -n "$local" = true && bind='127.0.0.1:'
+ echo 'text/css css' > $fqgitdir/mime.types
+ cat > "$conf" <<EOF
+ServerRoot "$fqgitdir/gitweb"
+DocumentRoot "$fqgitdir/gitweb"
+PidFile "$fqgitdir/pid"
+Listen $bind$port
+LoadModule cgi_module $module_path/mod_cgi.so
+TypesConfig $fqgitdir/mime.types
+DirectoryIndex gitweb.cgi
+AddHandler cgi-script .cgi
+<Location /gitweb.cgi>
+ Options +ExecCGI
+</Location>
+EOF
+}
+
+script='s#^my $projectroot =.*#my $projectroot = "'`dirname $fqgitdir`'";#;
+s#my $gitbin =.*#my $gitbin = "'`git --exec-path`'";#;
+s#my $projects_list =.*#my $projects_list = $projectroot;#;
+s#my $git_temp =.*#my $git_temp = "'$fqgitdir/gitweb/tmp'";#'
+
+gitweb_cgi () {
+ cat > "$1.tmp" <<\EOFGITWEB
+@@GITWEB_CGI@@
+EOFGITWEB
+ sed "$script" "$1.tmp" > "$1"
+ chmod +x "$1"
+ rm -f "$1.tmp"
+}
+
+gitweb_css () {
+ cat > "$1" <<\EOFGITWEB
+@@GITWEB_CSS@@
+EOFGITWEB
+}
+
+gitweb_cgi $GIT_DIR/gitweb/gitweb.cgi
+gitweb_css $GIT_DIR/gitweb/gitweb.css
+
+if echo "$httpd" | grep lighttpd >/dev/null
+then
+ lighttpd_conf
+elif echo "$httpd" | grep apache2 >/dev/null
+then
+ apache2_conf
+else
+ echo "Unknown httpd specified: $httpd"
+ exit 1
+fi
+
+start_httpd
+test -z "$browser" && browser=echo
+$browser http://127.0.0.1:$port
+
--
1.4.1.rc1.g2faf-dirty
^ permalink raw reply related
* Re: CFT: merge-recursive in C
From: Alex Riesen @ 2006-06-27 8:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Fredrik Kuivinen
In-Reply-To: <Pine.LNX.4.63.0606270936520.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On 6/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I finally got pis^Witched enough by my platform at work and decided
> > to start the effort of converting Fredriks git-merge-recursive to C.
>
> Darn. I was working on the same thing since a few days.
I didn't know :)
> - have you considered using run-command() instead of system()?
No. What run-program?
> - in setup_index(), you set GIT_INDEX_FILE, but I do not think that the
> rest of git picks up on it. environment.cc:get_index_file() checks if
> the variable was set already, but not if it changed.
Not even sure it's needed. Leftover from conversion
> - You work with linked lists all the time. This is slow, especially for
> the checks, if a file/directory is already there. Sorted lists would be
> way faster there. Since you encapsulated that, it is no problem to
> change that later (before inclusion).
Right, that's why it is mostly encapsulated.
> - is not "struct commit_list" more appropriate than "struct graph"?
Not even properly considered it yet. It probably is.
> - I always wondered why merge-recursive did not call merge-base, but did
> its own thing. Hmm?
No idea yet.
> > To my deep disappointment, it didn't work out as good as I hoped: one
> > program I see most often and for longest time in the process list
> > (git-diff-tree) is a too complex thing to be put directly into
> > merge-recursive.c, so any help in this direction will be greatly
> > appreciated.
>
> Maybe something like this (ripped from my fragment of merge-recursive.c):
>
> static struct container *get_renames(struct tree *tree,
> struct tree *o, struct tree *a, struct tree *b,
> struct container *cache_entries)
...
> It is not tested, evidently, since I did not get the merge-base code
> integrated yet. But it should give you an idea.
>
Thanks! It was something I was getting at after Junio explained it.
Will have to wait until after work.
^ permalink raw reply
* Re: Rework a patch serie
From: Andreas Ericsson @ 2006-06-27 8:53 UTC (permalink / raw)
To: moreau francis; +Cc: git
In-Reply-To: <20060627084130.28886.qmail@web25814.mail.ukl.yahoo.com>
moreau francis wrote:
> Hello
>
> Several times I have a topic branch that contains several commits like
> this:
>
> "master"
> o---o
> \ "topic"
> o---o---o---o---o---o
>
>
> When I think everything is in a good shape I generate several patches to
> submit them. For that, I do:
>
> $ git checkout topic
> $ git-format-patch -s -k -n master
> 001-aaa.patch
> 002-bbb.patch
> [...]
> 006-fff.patch
>
> Then I submit these patches for reviewing. Unfortunately, they're not perfect,
> so after some feedbacks from the communauty it appears that I need to make
> small modifications in the second commit in the topic branch for example...
>
> What is the best and fastest way to do that ? Should I create a new topic branch
> and cherry pick from the old one ?
>
It really depends on what the problem is. If it's a thinko in the design
I usually find it worth keeping to avoid falling in the same trap again.
I do the same for bugfixes, although some don't like that (I'm lazy,
they're anal). In this case, patches go on top of topic. Typos and stuff
can usually be changed inside the patch-file, in which case you can just
apply them to a new topic-branch.
It all boils down to how lazy you are, how much of your f***ups you want
to preserve (they *are* useful sometimes) and what you prefer, really.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Rework a patch serie
From: moreau francis @ 2006-06-27 8:41 UTC (permalink / raw)
To: git
Hello
Several times I have a topic branch that contains several commits like
this:
"master"
o---o
\ "topic"
o---o---o---o---o---o
When I think everything is in a good shape I generate several patches to
submit them. For that, I do:
$ git checkout topic
$ git-format-patch -s -k -n master
001-aaa.patch
002-bbb.patch
[...]
006-fff.patch
Then I submit these patches for reviewing. Unfortunately, they're not perfect,
so after some feedbacks from the communauty it appears that I need to make
small modifications in the second commit in the topic branch for example...
What is the best and fastest way to do that ? Should I create a new topic branch
and cherry pick from the old one ?
Thanks for your advices
Francis
^ permalink raw reply
* Re: Notes on diffcore API
From: Alex Riesen @ 2006-06-27 8:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Timo Hirvonen, git
In-Reply-To: <7virmn9hx8.fsf_-_@assigned-by-dhcp.cox.net>
On 6/27/06, Junio C Hamano <junkio@cox.net> wrote:
> -- >8 --
> Notes on diffcore API
> =====================
Thanks!
> Diffcore Transformation
> -----------------------
>
> The input file pairs recorded in the previous phase are
> collected in diff_queued_diff (a global variable -- which means
> that you cannot have two diffs running in parallel with the
> current setup). This is an expandable array of pointers to
> `struct diff_filepair` structure.
>
merge-recursive shouldn't have any problems with that, as the
renames are just read in the current implementation.
Still, it is somehow uncomfortable to see the amount of APIs
with the above restriction. Never know when it'll bite.
^ permalink raw reply
* [PATCH] git.c: Re-introduce sane error messages on missing commands.
From: Andreas Ericsson @ 2006-06-27 8:28 UTC (permalink / raw)
To: git
Somewhere in the alias handling git turned hostile on fat fingers:
$ git showbranch
Failed to run command '': Is a directory
This patch fixes that by doing 2 things:
* The variable git_command[MAX_PATH + 1] is now retired from
git.c:main() where it was never set. Instead the variable "cmd"
is used for all error messages.
* The introduction of the "exec_errno" variable which preserves the
errno number from the execve() attempt. Later "why did it fail"
tests evaluate exec_errno, which gives the correct error message
along with the brief command-list (telling me I missed the dash in
"show-branch").
It's possible that alias handling can fail and set errno to something
proper, making this change less sane than I think, but handle_alias()
seems to take care of its own error-handling so it shouldn't matter.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
git.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 94e9a4a..b04424f 100644
--- a/git.c
+++ b/git.c
@@ -206,9 +206,8 @@ int main(int argc, const char **argv, ch
{
const char *cmd = argv[0];
char *slash = strrchr(cmd, '/');
- char git_command[PATH_MAX + 1];
const char *exec_path = NULL;
- int done_alias = 0;
+ int exec_errno = 0, done_alias = 0;
/*
* Take the basename of argv[0] as the command
@@ -300,6 +299,9 @@ int main(int argc, const char **argv, ch
/* .. then try the external ones */
execv_git_cmd(argv);
+ /* if it's not an alias, the execve() errno is what we want */
+ exec_errno = errno;
+
/* It could be an alias -- this works around the insanity
* of overriding "git log" with "git show" by having
* alias.log = show
@@ -309,11 +311,11 @@ int main(int argc, const char **argv, ch
done_alias = 1;
}
- if (errno == ENOENT)
+ if (exec_errno == ENOENT)
cmd_usage(0, exec_path, "'%s' is not a git-command", cmd);
fprintf(stderr, "Failed to run command '%s': %s\n",
- git_command, strerror(errno));
+ cmd, strerror(exec_errno));
return 1;
}
--
1.4.1.rc1.g1ef9
^ permalink raw reply related
* Re: [PATCH 3/2] format-patch: use clear_commit_marks() instead of some adhocery
From: Johannes Schindelin @ 2006-06-27 8:31 UTC (permalink / raw)
To: Martin Langhoff (CatalystIT); +Cc: Martin Langhoff, git, junkio
In-Reply-To: <44A06A8D.7080202@catalyst.net.nz>
Hi,
I just cloned your repo, and as far as I can tell, the latest commit is on
June 23rd. So your numbers should be the same as mine. But not all are.
On Tue, 27 Jun 2006, Martin Langhoff (CatalystIT) wrote:
> Ok, I cooked the numbers up a bit, it was 60 total, with 10 merged upstream.
> Here's what I have today:
>
> $ git-cherry svnhead..master | grep -c '+'
> 52
Here, it is 51!
The problem I see: from the 53 non-merges in nzvleportfolio (who makes up
your branch names anyway?), there are two already in upstream: e3f56c and
7e448c5c. So it really should be 51.
> $ git-rev-list svnhead..master | wc -l
> 61
Same on my repo.
> $ ~/local/git/git-format-patch.sh -o .patchesold svnhead master
> ...
> $ ls .patchesold | wc -l
> 52
I guess this propagates from git-cherry. (Did not test here, since I do
not have an old git-format-patch.sh handy, and am too lazy to get the last
version from my git repo.)
> $ ~/local/git/git format-patch -o .patchesnewall svnhead..master
> ...
> $ ls .patchesnewall/ | wc -l
> 53
Same on my repo. Correct, since
"git rev-list --parents svnhead..master | grep -c \ .*\ "
yields 8, which is exactly 61 - 53.
> $ ~/local/git/git format-patch --ignore-if-in-upstream -o .patchesnewignore
> svnhead..master
> ...
> $ ls .patchesnewignore | wc -l
> 52
Again, I get 51.
I do not know what is happening, but it could be that there was a bug
fixed lately. I run a slightly modified version of 'next', updated about
15 minutes ago.
But anyway, looking at your numbers I take it that the new format-patch
with --ignore-if-in-upstream has the same output as the old format-patch,
right?
Ciao,
Dscho
^ 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