* 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: 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: 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: 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: 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: 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: 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
* 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: [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
* 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
* [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
* 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
* 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
* 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
* [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
* 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] 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: irc usage..
From: Yann Dirson @ 2006-05-20 20:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605201016090.10823@g5.osdl.org>
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.
FWIW, I have mentionned a problem that may be the same, under
Message-ID <20060107090148.GB32585@nowhere.earth>, that was on January
7th. Namely, when importing a repository with very large files over
pserver or ssh, timeouts can occur and prevent the import from
working. But, as you said, it's not easy to get precise info from the
logs :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] fmt-patch: Support --attach
From: Johannes Schindelin @ 2006-05-20 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu07k1sr8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 20 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sat, 20 May 2006, Junio C Hamano wrote:
> >
> > As for --check: how about having yet another diff "format":
> > DIFF_FORMAT_CHECK? Instead of showing the diff, it only shows the line(s)
> > which are offending.
>
> Never thought of that but I think it makes sense.
>
> I liked the way Sean did the --summary; I am wondering if we
> could clean up the --with-* stuff in a similar way. We
> currently do "if DIFF_FORMAT_XYZ or with_xyz then do this" which
> is quite honestly disgusting (my fault).
I do not think the --with-* stuff can be done in a similar way. If I do
"git log --summary -p", I do not get a summary. The only way to "clean it
up" would be to add a linked list of diff_formats (to preserve the order).
But frankly, I think that is overkill. After all, how often have you
dreamt about showing first the patch, then the summary, and maybe a
diffstat, and after that the patch again, for each commit?
Ciao,
Dscho
^ permalink raw reply
* Re: irc usage..
From: Jakub Narebski @ 2006-05-20 18:52 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmhc1t70.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Maybe somebody can run a dumb 'bot that notices somebody said
> something that ends with a '?' and there is no activity there
> for N minutes and inject a recorded message that reminds the
> mailing list address ;-).
Or something like fsbot or other bots on #emacs channel
http://www.emacswiki.org/cgi-bin/wiki/EmacsChannel
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Segfaults with USE_CURL_MULTI
From: Florian Weimer @ 2006-05-20 18:47 UTC (permalink / raw)
To: git
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.
^ permalink raw reply
* Re: [PATCH] fmt-patch: Support --attach
From: Junio C Hamano @ 2006-05-20 18:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605201945110.32590@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 20 May 2006, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> There are two options missing: --signoff and --check.
>
> --signoff is my fault: it is probably a good thing to drop it from
> format-patch, and only leave it in applymbox.
I think that is fine. format-patch only formats existing
commits, and if you are signing off something you could already
have done that when you made the commits anyway, so that flag
was redundant.
> As for --check: how about having yet another diff "format":
> DIFF_FORMAT_CHECK? Instead of showing the diff, it only shows the line(s)
> which are offending.
Never thought of that but I think it makes sense.
I liked the way Sean did the --summary; I am wondering if we
could clean up the --with-* stuff in a similar way. We
currently do "if DIFF_FORMAT_XYZ or with_xyz then do this" which
is quite honestly disgusting (my fault).
^ permalink raw reply
* Re: [PATCH] fmt-patch: Support --attach
From: Johannes Schindelin @ 2006-05-20 17:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pzk3831.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 20 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > I only changed the "From " line (note the missing ":") to match the output
> > from git-format-patch.sh.
>
> Not a big deal, but I was hoping you would keep the inception
> date of git (April one) in the final version ;-). The September
> date is totally a random date and does not have any
> significance.
Actually, I just tested something: pine seems to be confused when parsing
a "From " line where the day of month is only one digit without two
leading digits. I don't care.
> Anyway, with this change (and a lot of testing ;-) I think we
> can replace the script with built-in. Thanks.
There are two options missing: --signoff and --check.
--signoff is my fault: it is probably a good thing to drop it from
format-patch, and only leave it in applymbox.
As for --check: how about having yet another diff "format":
DIFF_FORMAT_CHECK? Instead of showing the diff, it only shows the line(s)
which are offending.
Ciao,
Dscho
^ permalink raw reply
* Re: irc usage..
From: Junio C Hamano @ 2006-05-20 17:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605201016090.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I hate irc.
>...
> Can we perhaps fix that, and the people who are active on irc please also
> make it clear to people that if they have some real problems that don't
> get an immediate answer, the git mailing list ends up where a lot of
> people can actually look more closely at it.. And tell them what the
> address is.
I hate irc, too. Number of times easily solvable usage problems
come up and I look at the log to realize when the solutions
suggested were waaaaay suboptimal it is too late (with loops
being quite active recently things have improved a lot, but we
should not expect him to be 24/7).
Maybe somebody can run a dumb 'bot that notices somebody said
something that ends with a '?' and there is no activity there
for N minutes and inject a recorded message that reminds the
mailing list address ;-).
^ permalink raw reply
* Re: [PATCH] fmt-patch: Support --attach
From: Junio C Hamano @ 2006-05-20 17:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605201904320.31887@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I only changed the "From " line (note the missing ":") to match the output
> from git-format-patch.sh.
Not a big deal, but I was hoping you would keep the inception
date of git (April one) in the final version ;-). The September
date is totally a random date and does not have any
significance.
Anyway, with this change (and a lot of testing ;-) I think we
can replace the script with built-in. Thanks.
^ 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