* [PATCH] Document that diff/diff-tree accept any number of trees.
From: Santi @ 2006-05-20 20:51 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
b98780e10df65bf9b37b4368d97bac53b5371170
Documentation/git-diff-tree.txt | 5 ++++-
Documentation/git-diff.txt | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
b98780e10df65bf9b37b4368d97bac53b5371170
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 906830d..3141ad8 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -11,7 +11,7 @@ SYNOPSIS
[verse]
'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty]
[-t] [-r] [-c | --cc] [--root] [<common diff options>]
- <tree-ish> [<tree-ish>] [<path>...]
+ <tree-ish>... [<path>...]
DESCRIPTION
-----------
@@ -20,6 +20,9 @@ Compares the content and mode of the blo
If there is only one <tree-ish> given, the commit is compared with its parents
(see --stdin below).
+If three or more <tree-ish> are given, it shows the differences from each of
+the <tree-ish> to the first one simultaneously (see -c below).
+
Note that "git-diff-tree" can use the tree encapsulated in a commit object.
OPTIONS
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 7267bcd..1842d7a 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -8,7 +8,7 @@ git-diff - Show changes between commits,
SYNOPSIS
--------
-'git-diff' [ --diff-options ] <ent>{0,2} [<path>...]
+'git-diff' [ --diff-options ] [<ent>...] [<path>...]
DESCRIPTION
-----------
@@ -25,7 +25,7 @@ the number of ents given to the command.
`--cached` can be given to compare the index file and
the named tree.
-* When two <ent>s are given, these two trees are compared
+* When two or more <ent>s are given, these trees are compared
using `git-diff-tree`.
OPTIONS
--
1.3.3.g5b1bb
^ permalink raw reply related
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Greg KH @ 2006-05-20 21:32 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1ac9dv2ld.fsf@ebiederm.dsl.xmission.com>
On Fri, May 19, 2006 at 08:42:38PM -0600, Eric W. Biederman wrote:
> Greg KH <greg@kroah.com> writes:
>
> > On Thu, May 18, 2006 at 04:48:26AM -0600, Eric W. Biederman wrote:
> >>
> >> Yes, a smaller patch series, that is what I meant.
> >> Most quilt trees that I know about are small.
> >
> > $ quilt series | wc -l
> > 207
> >
> > And that is about "normal" for me. Sometimes it grows to about 500+
> > patches, but that only happens when there's a longer kernel release
> > cycle.
> >
> > Another tree that I work on all the time is about 700+ patches, and yet
> > another 2000+. So you might re-evaluate your statement about "small"
> > quilt series :)
>
> Sure. On fixing the upstream attribution issue you and Andi Kleen
> look like people that are worth talking to, as there were several
> patches in Andrews tree from both of you that were lacking attribution.
Yes, I know I don't put any headers on patches I create until they are
ready to be sent upstream to Linus. I'll try to be better about that in
the future, sorry.
> > In looking at your script, it doesn't seem to be able to handle patches
> > in quilt that are in mbox format. Any thoughts to allow this to handle
> > the attribution properly?
>
> Mbox format but one patch per file, or multiple patches in one mbox file?
The patches are already in mbox format in each file, but I dump them all
together into one big one, to preserve the proper order as defined in
the quilt series file so that git gets it right.
> If it is one patch per file but with mbox headers, it is relatively
> simple to teach git-mailinfo to parse things in a slightly more intelligent
> way. I played with that but I didn't have any patches that helped with.
Hm, I'll try playing with that.
If you want, just grab my quilt trees from kernel.org and play with
them, they should all be in mbox format for the individual patches (with
some exceptions as noted above, just kick me about them to get me to fix
them...)
thanks,
greg k-h
^ permalink raw reply
* [PATCH] fmt-patch: add --check option
From: Johannes Schindelin @ 2006-05-20 21:43 UTC (permalink / raw)
To: git, junkio
Actually, it is a diff option now, so you can say
git diff --check
to ask if what you are about to commit is a good patch.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
The temptation to bastardize diff_flush_patch was not high
enough. It would be ugly.
Internally, I called it checkdiff, not just check, to make it
more obvious what it does.
diff.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
diff.h | 1 +
2 files changed, 115 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index 3e2828b..af26dda 100644
--- a/diff.c
+++ b/diff.c
@@ -397,6 +397,46 @@ static void show_stats(struct diffstat_t
total_files, adds, dels);
}
+struct checkdiff_t {
+ struct xdiff_emit_state xm;
+ const char *filename;
+ int lineno;
+};
+
+static void checkdiff_consume(void *priv, char *line, unsigned long len)
+{
+ struct checkdiff_t *data = priv;
+
+ if (line[0] == '+') {
+ int i, spaces = 0;
+
+ data->lineno++;
+
+ /* check space before tab */
+ for (i = 1; i < len && (line[i] == ' ' || line[i] == '\t'); i++)
+ if (line[i] == ' ')
+ spaces++;
+ if (line[i - 1] == '\t' && spaces)
+ printf("%s:%d: space before tab:%.*s\n",
+ data->filename, data->lineno, (int)len, line);
+
+ /* check white space at line end */
+ if (line[len - 1] == '\n')
+ len--;
+ if (isspace(line[len - 1]))
+ printf("%s:%d: white space at end: %.*s\n",
+ data->filename, data->lineno, (int)len, line);
+ } else if (line[0] == ' ')
+ data->lineno++;
+ else if (line[0] == '@') {
+ char *plus = strchr(line, '+');
+ if (plus)
+ data->lineno = strtol(plus, line + len, 10);
+ else
+ die("invalid diff");
+ }
+}
+
static unsigned char *deflate_it(char *data,
unsigned long size,
unsigned long *result_size)
@@ -624,6 +664,41 @@ static void builtin_diffstat(const char
}
}
+static void builtin_checkdiff(const char *name_a, const char *name_b,
+ struct diff_filespec *one,
+ struct diff_filespec *two)
+{
+ mmfile_t mf1, mf2;
+ struct checkdiff_t data;
+
+ if (!two)
+ return;
+
+ memset(&data, 0, sizeof(data));
+ data.xm.consume = checkdiff_consume;
+ data.filename = name_b ? name_b : name_a;
+ data.lineno = 0;
+
+ if (fill_mmfile(&mf1, one) < 0 || fill_mmfile(&mf2, two) < 0)
+ die("unable to read files to diff");
+
+ if (mmfile_is_binary(&mf2))
+ return;
+ else {
+ /* Crazy xdl interfaces.. */
+ xpparam_t xpp;
+ xdemitconf_t xecfg;
+ xdemitcb_t ecb;
+
+ xpp.flags = XDF_NEED_MINIMAL;
+ xecfg.ctxlen = 0;
+ xecfg.flags = 0;
+ ecb.outf = xdiff_outf;
+ ecb.priv = &data;
+ xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
+ }
+}
+
struct diff_filespec *alloc_filespec(const char *path)
{
int namelen = strlen(path);
@@ -1180,6 +1255,25 @@ static void run_diffstat(struct diff_fil
builtin_diffstat(name, other, p->one, p->two, diffstat, complete_rewrite);
}
+static void run_checkdiff(struct diff_filepair *p, struct diff_options *o)
+{
+ const char *name;
+ const char *other;
+
+ if (DIFF_PAIR_UNMERGED(p)) {
+ /* unmerged */
+ return;
+ }
+
+ name = p->one->path;
+ other = (strcmp(name, p->two->path) ? p->two->path : NULL);
+
+ diff_fill_sha1_info(p->one);
+ diff_fill_sha1_info(p->two);
+
+ builtin_checkdiff(name, other, p->one, p->two);
+}
+
void diff_setup(struct diff_options *options)
{
memset(options, 0, sizeof(*options));
@@ -1205,7 +1299,8 @@ int diff_setup_done(struct diff_options
* recursive bits for other formats here.
*/
if ((options->output_format == DIFF_FORMAT_PATCH) ||
- (options->output_format == DIFF_FORMAT_DIFFSTAT))
+ (options->output_format == DIFF_FORMAT_DIFFSTAT) ||
+ (options->output_format == DIFF_FORMAT_CHECKDIFF))
options->recursive = 1;
if (options->detect_rename && options->rename_limit < 0)
@@ -1288,6 +1383,8 @@ int diff_opt_parse(struct diff_options *
}
else if (!strcmp(arg, "--stat"))
options->output_format = DIFF_FORMAT_DIFFSTAT;
+ else if (!strcmp(arg, "--check"))
+ options->output_format = DIFF_FORMAT_CHECKDIFF;
else if (!strcmp(arg, "--summary"))
options->summary = 1;
else if (!strcmp(arg, "--patch-with-stat")) {
@@ -1610,6 +1707,19 @@ static void diff_flush_stat(struct diff_
run_diffstat(p, o, diffstat);
}
+static void diff_flush_checkdiff(struct diff_filepair *p,
+ struct diff_options *o)
+{
+ if (diff_unmodified_pair(p))
+ return;
+
+ if ((DIFF_FILE_VALID(p->one) && S_ISDIR(p->one->mode)) ||
+ (DIFF_FILE_VALID(p->two) && S_ISDIR(p->two->mode)))
+ return; /* no tree diffs in patch format */
+
+ run_checkdiff(p, o);
+}
+
int diff_queue_is_empty(void)
{
struct diff_queue_struct *q = &diff_queued_diff;
@@ -1740,6 +1850,9 @@ static void flush_one_pair(struct diff_f
case DIFF_FORMAT_DIFFSTAT:
diff_flush_stat(p, options, diffstat);
break;
+ case DIFF_FORMAT_CHECKDIFF:
+ diff_flush_checkdiff(p, options);
+ break;
case DIFF_FORMAT_PATCH:
diff_flush_patch(p, options);
break;
diff --git a/diff.h b/diff.h
index 83619eb..08b3fed 100644
--- a/diff.h
+++ b/diff.h
@@ -155,6 +155,7 @@ #define DIFF_FORMAT_NO_OUTPUT 3
#define DIFF_FORMAT_NAME 4
#define DIFF_FORMAT_NAME_STATUS 5
#define DIFF_FORMAT_DIFFSTAT 6
+#define DIFF_FORMAT_CHECKDIFF 7
extern void diff_flush(struct diff_options*);
--
1.3.3.g734b-dirty
^ permalink raw reply related
* synchronizing incremental git changes to cvs
From: Jim Meyering @ 2006-05-20 22:13 UTC (permalink / raw)
To: git
Hello,
Can anyone point me at code to mirror a git repository to cvs?
I'd like to develop using git, and have a commit hook mirror the
day-to-day changes (tags/commits) made in the git repo to a
cvs repository. The idea is that the only way changes get into
the cvs repo is via the git commit hook.
I've experimented with git-cvsexportcommit, and found a few bugs (it
couldn't handle simple things, like adding a file in a new directory --
fixed that, along with a few other minor problems), adding an empty file
in git still gets a patch application error on the cvs side, but I can
live with that for now. More seriously, making a change on a git branch
mistakenly tries to apply the delta on the cvs trunk. None of this is
particularly hard to fix -- or even critical, as long as you don't care
about branches. I'm just hoping someone has already produced something
more robust. From the looks of darcs/tailor, it doesn't handle the use
of git as a source.
Why am I interested? I want to switch the development of GNU coreutils
from cvs to git. I would also like to continue making the repository
available via cvs, for the sake of continuity. At worst, I can always
cut the CVS cord, but that's a last resort.
Jim
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-20 22:18 UTC (permalink / raw)
To: Yann Dirson; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20060520203911.GI6535@nowhere.earth>
[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]
Yann Dirson wrote:
> On Sat, May 20, 2006 at 10:26:22AM -0700, Linus Torvalds wrote:
>> I'm reading the irc logs, and seeing that people have problems, but (a) it
>> was while I was asleep and (b) irc use doesn't encourage people to
>> actually explain what the problems _are_, so I have no clue.
>>
>> So now I know that "spyderous" has problems importing some 1GB gentoo CVS
>> archive, but that's pretty much it. Grr.
Hi all,
I just subscribed and this post is the only one I've got from the
thread, so I'm responding to it instead of the original. Gentoo's an
IRC-based community, so I tend to try IRC first for any problems I have
and fall back to the list later if I can't get things figured out.
Here's a rough summary:
Our main repo is actually a bit over 2G (2103621223) now that I check,
but it's not very complex. There's actually just one branch, and I don't
think anyone would care if we lost the history from it because it's a
release branch from a few years ago.
Somebody else tried importing it with git-cvsimport, but he said he hit
some kind of problem and recalled that it was a cvsps segfault. Sounds
about right, since I've never gotten cvsps to run successfully on the
whole repo either.
I tried with parsecvs, but it runs into OOM even on a machine with 4G
RAM after reading in all the ,v files, presumably while it's building
some huge tree of changesets in memory. Keith Packard's suggested that
there are ways to reduce parsecvs's memory use, because it retains the
full tree in memory for each revision rather than just the files that
actually changed. But my C skills are pretty weak; I'm an OK reader but
not much of a writer yet.
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: irc usage..
From: Linus Torvalds @ 2006-05-20 22:45 UTC (permalink / raw)
To: Donnie Berkholz; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <446F95A2.6040909@gentoo.org>
On Sat, 20 May 2006, Donnie Berkholz wrote:
>
> Our main repo is actually a bit over 2G (2103621223) now that I check,
> but it's not very complex. There's actually just one branch, and I don't
> think anyone would care if we lost the history from it because it's a
> release branch from a few years ago.
Can you point to it? I'm not a CVS user, but I've played with cvsps before
(to get it to work), and I'm a humanitarian - rescuing people from CVS is
to me not just a good idea, it's a moral imperative.
Linus
^ permalink raw reply
* [PATCH] Remove possible segfault in http-fetch.
From: Sean @ 2006-05-20 22:46 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87fyj4y1lx.fsf@mid.deneb.enyo.de>
Free the curl string lists after running http_cleanup to
avoid an occasional segfault in the curl library. Seems
to only occur if the website returns a 405 error.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
On Sat, 20 May 2006 20:47:54 +0200
Florian Weimer <fw@deneb.enyo.de> wrote:
> Is anybody else seeing segfaults on dumb HTTP pull with
> USE_CURL_MULTI? For example, this crashes for me:
>
> $ git clone http://git.enyo.de/fw/debian/debfoster.git upstream
>
> GDB shows that this happens inside the call to curl_multi_perform.
>
Florian, could you please test this patch.
It comes with a big disclaimer because I don't really know the
code in here all that well. However gdb reports the segfault
happens in a strncasecmp call, and seeing as we've released a
bunch of strings prior to the call....
Testing seems to confirm that the segfault is removed by this patch.
As to why the website returns a 405 error in the first place is still
a mystery to me.
Sean
http-fetch.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/http-fetch.c b/http-fetch.c
index 861644b..178f1ee 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -1269,10 +1269,10 @@ int main(int argc, char **argv)
if (pull(commit_id))
rc = 1;
- curl_slist_free_all(no_pragma_header);
-
http_cleanup();
+ curl_slist_free_all(no_pragma_header);
+
if (corrupt_object_found) {
fprintf(stderr,
"Some loose object were found to be corrupt, but they might be just\n"
--
1.3.GIT
^ permalink raw reply related
* gitweb.cgi, $my_uri and too many slashes in url
From: Brandon Philips @ 2006-05-20 22:58 UTC (permalink / raw)
To: git
gitweb.cgi creates bad URLs when too many slashes are put in a URL.
Visiting http://kernel.org///git/ causes all URL prefixes to be
http://git/
Explicitly setting $my_uri fixes the problem so it is likely a bug in
the CGI library.
my $my_uri = $cgi->url(-absolute => 1);
I reproduced the bug on a system with the latest version of gitweb and
Perl's CGI in Debian Unstable to ensure it wasn't just a kernel.org bug.
Thanks,
Brandon
--
http://ifup.org
^ permalink raw reply
* Re: [PATCH] Remove possible segfault in http-fetch.
From: Florian Weimer @ 2006-05-20 23:00 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP082397700A9527CC2F3786AEA40@CEZ.ICE>
* Sean:
> Testing seems to confirm that the segfault is removed by this patch.
It seems to fix it for me, too.
> As to why the website returns a 405 error in the first place is still
> a mystery to me.
The web server does not support PROPFIND.
^ permalink raw reply
* dangling commits.
From: Dave Jones @ 2006-05-20 23:05 UTC (permalink / raw)
To: git
What's wrong here?
(tmp)$ mkdir git
(tmp)$ cd git
(git)$ rsync -azq rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/ .git
(git)$ git-fsck-objects --full
dangling commit fc024e5e1b92fb11d11aa3c15e9e3f92a888acb6
dangling commit be49def3dd524b241e3f14c657e740f2e4d73d39
dangling commit e659abda29b2b25db2771c3e6086f15bc74b1d06
dangling commit 0f5aaf12d411debc2958dfb029ffcf873d980f15
dangling commit 8eed8a5da8330df6901f254eab4b7056855b919c
The version of git on that box is 1.2.6-1 from Debian etch.
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: synchronizing incremental git changes to cvs
From: Johannes Schindelin @ 2006-05-20 23:05 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87mzdcjqey.fsf@rho.meyering.net>
Hi,
On Sun, 21 May 2006, Jim Meyering wrote:
> Why am I interested? I want to switch the development of GNU coreutils
> from cvs to git. I would also like to continue making the repository
> available via cvs, for the sake of continuity. At worst, I can always
> cut the CVS cord, but that's a last resort.
If you only want to make a cvs repository available for tracking the
project, git-cvsserver is what you want. It is even faster than the
original cvs...
Ciao,
Dscho
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-20 23:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yann Dirson, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605201543260.3649@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 826 bytes --]
Linus Torvalds wrote:
>
> On Sat, 20 May 2006, Donnie Berkholz wrote:
>> Our main repo is actually a bit over 2G (2103621223) now that I check,
>> but it's not very complex. There's actually just one branch, and I don't
>> think anyone would care if we lost the history from it because it's a
>> release branch from a few years ago.
>
> Can you point to it? I'm not a CVS user, but I've played with cvsps before
> (to get it to work), and I'm a humanitarian - rescuing people from CVS is
> to me not just a good idea, it's a moral imperative.
I don't want to post the link publicly for a few reasons, including the
huge amount of bandwidth it would suck up for lots of people to download
it. I've sent it to you off-list, and if anyone else would also like it,
please drop me a note.
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: dangling commits.
From: Sean @ 2006-05-20 23:08 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20060520230531.GA27511@redhat.com>
On Sat, 20 May 2006 19:05:31 -0400
Dave Jones <davej@redhat.com> wrote:
> What's wrong here?
>
> (tmp)$ mkdir git
> (tmp)$ cd git
> (git)$ rsync -azq rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git/ .git
> (git)$ git-fsck-objects --full
> dangling commit fc024e5e1b92fb11d11aa3c15e9e3f92a888acb6
> dangling commit be49def3dd524b241e3f14c657e740f2e4d73d39
> dangling commit e659abda29b2b25db2771c3e6086f15bc74b1d06
> dangling commit 0f5aaf12d411debc2958dfb029ffcf873d980f15
> dangling commit 8eed8a5da8330df6901f254eab4b7056855b919c
>
> The version of git on that box is 1.2.6-1 from Debian etch.
>
> Dave
>
Nothing wrong. Those commits were just dropped from the "pu" branch at
one time or another when it was rewound. The repository could use a
pruning, but there's no harm done by having those objects remain in
the object database. If you had used any protocol other than rsync,
they would not have appeared in your cloned copy.
Sean
^ permalink raw reply
* Re: dangling commits.
From: Linus Torvalds @ 2006-05-20 23:19 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20060520230531.GA27511@redhat.com>
On Sat, 20 May 2006, Dave Jones wrote:
>
> What's wrong here?
Nothing, except
- you used rsync to fetch the thing (so you get all objects, regardless
of whether they are reachable or not)
- junio re-bases his "pu" branch, and I just end up following him (I
should stop exporting git entirely, here's no point, really). Thus,
whenever "pu" gets reset to something else, the old head of pu gets
dropped on the floor and ends up as a "dangling" commit (no branch head
points to it any more).
The moral(s) of the story being that
(a) dangling commits are normal if you reset branch heads (which includes
things like "git rebase", for example)
(b) rsync is not a good transfer protocol, since it will just blindly
transfer objects that aren't needed - or worse - successfully clone a
corrupt repository.
but there's nothing to _worry_ about in this particular schenario.
Linus
^ permalink raw reply
* Re: dangling commits.
From: Dave Jones @ 2006-05-20 23:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605201615270.3649@g5.osdl.org>
On Sat, May 20, 2006 at 04:19:06PM -0700, Linus Torvalds wrote:
> > What's wrong here?
>
> Nothing, except
>
> - you used rsync to fetch the thing (so you get all objects, regardless
> of whether they are reachable or not)
Ah. I actually noticed this when I poked around the box that does
the nightly snapshots, and wondered for a few minutes why I never
switched it over to git:// last time I poked at that script.
Then it came back to me: rsync -q worked better than redirecting
git to /dev/null
- git-clone's -q was still outputting some stuff, so recloning each
time the cronjob ran wasn't an option,
- subsequent git pull's were noisy too
When run from a cronjob, unless something fatal happens, I basically
never want to get mail from the snapshotting script.
> - junio re-bases his "pu" branch, and I just end up following him (I
> should stop exporting git entirely, here's no point, really).
I just updated the snapshot script to pull from
http://www.kernel.org/pub/scm/git/git.git/ instead.
thanks,
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: synchronizing incremental git changes to cvs
From: Martin Langhoff @ 2006-05-21 0:09 UTC (permalink / raw)
To: Jim Meyering; +Cc: git
In-Reply-To: <87mzdcjqey.fsf@rho.meyering.net>
On 5/21/06, Jim Meyering <jim@meyering.net> wrote:
> Can anyone point me at code to mirror a git repository to cvs?
Ive thought a couple of times about writing an exporter that would
replay things into a true CVS repo, but it's truly not worth it. We've
already got git-cvsserver that does all that -- better for me to focus
on that codebase.
> I've experimented with git-cvsexportcommit, and found a few bugs (it
> couldn't handle simple things, like adding a file in a new directory --
> fixed that, along with a few other minor problems), adding an empty file
> in git still gets a patch application error on the cvs side, but I can
> live with that for now. More seriously, making a change on a git branch
> mistakenly tries to apply the delta on the cvs trunk.
cvsexportcommit is clearly for manual usage, not for automagic usage.
It is a bit rough, (and I'd like to see your patches to it!) but it
wants to be driven by a smarter script to, for instance, know what
branch you want things in.
> Why am I interested? I want to switch the development of GNU coreutils
> from cvs to git. I would also like to continue making the repository
> available via cvs, for the sake of continuity. At worst, I can always
> cut the CVS cord, but that's a last resort.
git-cvsserver is the word. It currently tracks the git repo itself
pretty well (perfectly, AFAICS) and it also tracks a git tree that is
actually imported daily from CVS -- doing
CVSrepo ->cvsimport -> GIT -> cvsserver -> CVS checkout
git-cvsserver works great for anon cvs access (does pserver) and
TortoiseCVS and cli cvs work great with it. Eclipse works well, but it
has been quite hard to get 'right'. Optionally, it can support users
with commit rights via ssh. It does track git 'heads' but they don't
show up as branches, they show up as different modules. So you to get
a checkout of the master branch, you do:
cvs -d pserver:anonymouys@foo.com:/var/foo.git co master
hope that helps!
martin
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Eric W. Biederman @ 2006-05-21 0:36 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git
In-Reply-To: <20060520213257.GH24672@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Fri, May 19, 2006 at 08:42:38PM -0600, Eric W. Biederman wrote:
>
>> If it is one patch per file but with mbox headers, it is relatively
>> simple to teach git-mailinfo to parse things in a slightly more intelligent
>> way. I played with that but I didn't have any patches that helped with.
>
> Hm, I'll try playing with that.
>
> If you want, just grab my quilt trees from kernel.org and play with
> them, they should all be in mbox format for the individual patches (with
> some exceptions as noted above, just kick me about them to get me to fix
> them...)
So I just grabbed the gregkh-2.6 set of patches and with an unmodified
git-mailinfo I only have problems with the following patches:
gregkh/gkh-version.patch
gregkh/sysfs-test.patch
gregkh/gregkh-usb-minors.patch
gregkh/gregkh-debugfs_example.patch
gregkh/gpl_future-test.patch
usb/usb-gotemp.patch
None of which actually have from headers.
Currently git-mailinfo distinguishes headers and non-headers by the
presence of the first blank line. So it seems to work just fine on
mbox format patches.
Eric
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Junio C Hamano @ 2006-05-21 0:41 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1fyj4qkm2.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Currently git-mailinfo distinguishes headers and non-headers by the
> presence of the first blank line. So it seems to work just fine on
> mbox format patches.
The program was designed to be fed one e-mail a time (the
intended way for it to work is that a wrapper script uses
git-mailsplit to break mbox up and call git-mailinfo one by
one).
^ permalink raw reply
* Re: [PATCH 0/5] More ref logging
From: Shawn Pearce @ 2006-05-21 0:50 UTC (permalink / raw)
To: Sean; +Cc: junkio, git
In-Reply-To: <20060519071603.11d3be5d.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Fri, 19 May 2006 05:14:56 -0400
> Shawn Pearce <spearce@spearce.org> wrote:
>
> > * [PATCH 5/5] Enable ref log creation in git checkout -b.
> >
> > Fix git checkout -b to behave like git branch.
>
> It seems that the ref log is a new way of tagging commits with some
> extra meta data. Conceptually this seems very close to what git tags
> already do. So... what about using regular git tags rather than
> creating a ref log? All the regular git-rev-list tools could be
> used to query the tags and prune would delete them automatically etc.
It sort of is a new way of tagging commits with extra data. But its
also sort of a way of versioning your ref `database'. Using tags
to save the points in time might be useful but it would generate
a lot of temporary files. A commit every 5 minutes for a typical
working week would generate 480 tags per week. That's just too much.
I was actually thinking this morning that another way to do this
is to keep a metadata branch within the repository which records
all of the refs in tree objects, then save the root commit under
the special ref `LOG` in GIT_DIR. Every update to a logged ref
would cause the tree to be updated and a new commit to be built.
The branch would be a relatively simple string of pearls as its
doubtful you would branch it.
There are a number of downsides to this, not the least of which is
I'd like to put a commit or tag SHA1 into the tree object rather than
writing each ref as a blob (saves space). Currently commits and tags
aren't permitted in a tree object so that would require some effort.
But on the other hand you could pull (and track!) someone elses
ref log through the standard GIT protocol.
But this is starting to head down into the `bind commit` discussion;
how do we record a number of commits as being related and tie them
up into a single super commit?
--
Shawn.
^ permalink raw reply
* Re: gitk highlight feature
From: Paul Mackerras @ 2006-05-21 0:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605200934240.10823@g5.osdl.org>
Linus Torvalds writes:
> I think the "Find" field should highlight things too. Right now there's no
> way to get highlighting for somebody having signed-off on a patch, for
> example, even though you can _search_ for it.
Yes, I think the way to go is to extend the highlight feature to be
able to do everything that the "Find" function can do, and then I
think the "Find" function won't be needed any more.
> Also, right now it says "Author/committer", but it actually only triggers
> on author. Which may be the right thing to do (it's certainly what I'd
> normally want to see), but it doesn't match the description.
If the author matches, it highlights both the headline and the
author. If the committer matches, it highlights only the headline (as
it does for any other highlighting). Try it with "torvalds" in the
author/committer field on commit a54c9d30 (compared to cb46c370,
say). If that's confusing I can change it of course.
Paul.
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Eric W. Biederman @ 2006-05-21 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xow1a6r.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Currently git-mailinfo distinguishes headers and non-headers by the
>> presence of the first blank line. So it seems to work just fine on
>> mbox format patches.
>
> The program was designed to be fed one e-mail a time (the
> intended way for it to work is that a wrapper script uses
> git-mailsplit to break mbox up and call git-mailinfo one by
> one).
In this case what is meant is a leading "From " header (no colon)
at the start of the patch.
Where git-mailinfo is likely to fall down is more in the quilt
patches from Andi Kleen. If you look at my quoted patch header below
you will see the subject is a plain line, followed by a space followed
by a from. On this example git-mailinfo works (except for picking up
the subject) but it appears to be a fluke.
>From x86_64-mm-add-abilty-to-enable-disable-nmi-watchdog-from-sysfs.patch:
> Add abilty to enable/disable nmi watchdog with sysctl
>
> From: dzickus <dzickus@redhat.com>
>
> Adds a new /proc/sys/kernel/nmi call that will enable/disable the nmi
> watchdog.
>
> Signed-off-by: Don Zickus <dzickus@redhat.com>
> Signed-off-by: Andi Kleen <ak@suse.de>
>
> ---
> arch/i386/kernel/nmi.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++
> arch/x86_64/kernel/nmi.c | 48 +++++++++++++++++++++++++++++++++++++++++++
> include/asm-i386/nmi.h | 1
> include/asm-x86_64/nmi.h | 1
> include/linux/sysctl.h | 1
> kernel/sysctl.c | 11 +++++++++
> 6 files changed, 114 insertions(+)
>
> Index: linux/arch/i386/kernel/nmi.c
Eric
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Shawn Pearce @ 2006-05-21 1:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605191853570.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> wrote:
>
> On Fri, 19 May 2006, Daniel Barkalow wrote:
> >
> > I guess I did forget that it sticks around. So you have to be doing
> > something somewhat more complicated, like fetching the latest versions of
> > multiple topic branches.
>
> I actually don't think it's at all unlikely that I'd start using this.
Hey, if its useful. :-) If its not then I'm doing something
wrong here...
[snip]
> I'm not entirely sure about the syntax, though. It ends up being pretty
> command-line-unfriendly. The "gitk ORIG_HEAD.." thing is fairly easy to
> type, but typing
>
> gitk 'master@{2 hours ago}'..
>
> on a Finnish keyboard (yeah, that's what I still use) is "interesting",
> since all of '@', '{' and '}' are complex characters (AltGr + '2', AltGr +
> '7' and AltGr + '0' respectively), and you have to remember the quoting.
Wow. So what you are saying is writing any sort of C code must be
rather painful. :-)
I received a suggestion of using ' (single quote) rather than {
as the quoting character. I didn't make the quoting character
optional as I realized users were likely to forget they needed it
on date specs which contain ':', so I just made them required to
keep things consistent at all times. Further {} won out over ''
as {} is also used with the ^ operator (e.g. v1.3.3^{tree}).
> Not that I see any obvious better syntax. Although allowing a shorthand
> like "@2.hours.ago" for "current branch, at given date" might help a
> bit, at least that wouldn't need quoting:
>
> gitk @2.hours.ago..
The empty prefix for `HEAD` is simple. The '.' part would need to
be fixed in approxidate() (and thus --since would also benefit).
Omitting the {} might be OK but see above...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Junio C Hamano @ 2006-05-21 1:02 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m13bf4qjjv.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Where git-mailinfo is likely to fall down is more in the quilt
> patches from Andi Kleen. If you look at my quoted patch header below
> you will see the subject is a plain line, followed by a space followed
> by a from. On this example git-mailinfo works (except for picking up
> the subject) but it appears to be a fluke.
>
> From x86_64-mm-add-abilty-to-enable-disable-nmi-watchdog-from-sysfs.patch:
>
Yeah, that's right, but in a real mailbox wouldn't that line be
prefixed with a '>' ;-)?
^ permalink raw reply
* Re: git-svn vs. $Id$
From: Eric Wong @ 2006-05-21 1:12 UTC (permalink / raw)
To: Tommi Virtanen; +Cc: Linus Torvalds, git
In-Reply-To: <446A15F8.3040106@inoi.fi>
Tommi Virtanen <tv@inoi.fi> wrote:
> Linus Torvalds wrote:
> > Isn't there some flag to svn to avoid keyword expansion, like "-ko" to
> > CVS?
> >
> > Any import script definitely should avoid keyword expansion (and that's
> > true whether you end up wanting to use keywords or not).
>
> Well, yes, I agree. But, at least git-svn.txt says this:
>
> BUGS
> ----
> ...
> svn:keywords can't be ignored in Subversion (at least I don't know of
> a way to ignore them).
>
> I guess one might be able to reach that information through the svn API.
>
> Or just propget svn:keywords and sed s/\$Id\(:[^$]*\)\$/$Id$/ all files
> with keywords, for all relevant keywords. Eww.
I'm working on a solution to this (using files in .svn/text-base).
keyword expansion behavior seems inconsistent on some SVN repos and I
can't reproduce it on my local repositories, so I think I will have to
weaken some integrity checks[1] in git-svn to work around it...
1 - I don't think these integrity checks were ever tripped in the first
place.
--
Eric Wong
^ permalink raw reply
* Re: irc usage..
From: Donnie Berkholz @ 2006-05-21 1:14 UTC (permalink / raw)
To: Donnie Berkholz; +Cc: Yann Dirson, Linus Torvalds, Git Mailing List
In-Reply-To: <446F95A2.6040909@gentoo.org>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
Donnie Berkholz wrote:
> Somebody else tried importing it with git-cvsimport, but he said he hit
> some kind of problem and recalled that it was a cvsps segfault. Sounds
> about right, since I've never gotten cvsps to run successfully on the
> whole repo either.
Much to my surprise, a cvsps run I started earlier has just finished
without segfaulting. But attempts to actually run cvsps (e.g., cvsps -a
spyderous) spit thousands of warnings of "WARNING: revision 1.1.1.1 of
file $FILENAME on unnamed branch".
Thanks,
Donnie
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ 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