* cvsimport weird
From: Bertrand Jacquin @ 2006-05-18 1:00 UTC (permalink / raw)
To: Git Mailing List
Hi,
I would like to make some git-cvsimport test on a public repo. And I
get some problem and don't know if it's a remote server
(enlightenment) problem or a git-cvsimport one.
Here is the log :
/mnt/data/src/e-tmp % git-cvsimport -v
-d:pserver:anonymous@anoncvs.enlightenment.org:/var/cvs/e e17
connect error: Network is unreachable
WARNING: malformed CVS version str: Server:
WARNING: Your CVS client version:
[Client: Concurrent Versions System (CVS) 1.12.12 (client)]
and/or server version:
[Server: ]
are too old to properly support the rlog command.
This command was introduced in 1.11.1. Cvsps
will use log instead, but PatchSet numbering
may become unstable due to pruned empty
directories.
cvs [log aborted]: end of file from server (consult above messages if any)
DONE.
Already up-to-date.
/mnt/data/src/e-tmp %
I use cvs 1.12.12, cvsps 2.1, git 1.3.3
I don't why it tell me that Network is unreachable as I can do normal
cvs checkout.
Also, I have the repo in another directory, and I don't know how to
use a :local: CVSROOT
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: 1.3.2 git-clone segfaults
From: Linus Torvalds @ 2006-05-18 0:54 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Bill Yoder, git, Wolfgang Denk
In-Reply-To: <1147909920.32050.29.camel@dv>
On Wed, 17 May 2006, Pavel Roskin wrote:
>
> Looks like a curl bug to me. curl 7.15.1, glibc 2.4, git master branch.
If the thing is fixed by turning off DAV support (and I thought somebody
reported it was), maybe we should turn that off by default? Ie, make
NO_EXPAT be the default, and you have to explicitly turn it off.
Linus
^ permalink raw reply
* Re: 1.3.2 git-clone segfaults
From: Pavel Roskin @ 2006-05-17 23:52 UTC (permalink / raw)
To: Bill Yoder; +Cc: git, Wolfgang Denk
In-Reply-To: <1147894165.16654.10.camel@dv>
On Wed, 2006-05-17 at 15:29 -0400, Pavel Roskin wrote:
> On Wed, 2006-05-17 at 13:32 -0500, Bill Yoder wrote:
> > /usr/local/downloads/git-1.3.2/git-clone: line 323: 25972
> > Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
>
> I've seen git-http-fetch segfaults many times when cloning qgit, but
> it's hard to reproduce on demand.
>
> I think you should compile git without optimizations and allow coredumps
> (ulimit -c unlimited), then load git-http-fetch in gdb with the core
> (gdb --core=core git-http-fetch) and run bt to see the backtrace.
Also comment out both "trap" invocations in git-clone, or the coredump
will be deleted.
That's what I've got on Fedora Core 5 x86_64 with glibc and curl debug
info installed:
#0 __strncasecmp (s1=Variable "s1" is not available.
) at strncase.c:68
68 while ((result = TOLOWER (*p1) - TOLOWER (*p2++)) == 0)
(gdb) where
#0 __strncasecmp (s1=Variable "s1" is not available.
) at strncase.c:68
#1 0x00000031f3e26c09 in curl_strnequal (first=Variable "first" is not available.
) at strequal.c:60
#2 0x00000031f3e0f43a in checkheaders (data=Variable "data" is not available.
) at http.c:119
#3 0x00000031f3e10cf9 in Curl_http (conn=0x1c421c0, done=Variable "done" is not available.
) at http.c:1580
#4 0x00000031f3e1a858 in Curl_do (connp=0x83af88, done=0x7fff29c97ebb "\001\001")
at url.c:3841
#5 0x00000031f3e28f22 in curl_multi_perform (multi_handle=0x53b590,
running_handles=0x7fff29c97ef8) at multi.c:526
#6 0x00000000004040c0 in step_active_slots () at http.c:376
#7 0x000000000040412c in run_active_slot (slot=0x546690) at http.c:400
#8 0x0000000000403e44 in http_cleanup () at http.c:275
#9 0x00000000004077d7 in main (argc=7, argv=0x7fff29c98258) at http-fetch.c:1274
(gdb) p p1
$1 = (const unsigned char *) 0x0
(gdb) p p2
$2 = (const unsigned char *) 0x31f3e2e817 "User-Agent:"
(gdb)
Looks like a curl bug to me. curl 7.15.1, glibc 2.4, git master branch.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Junio C Hamano @ 2006-05-17 23:34 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1zmhg31cm.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> What's the expected workflow for you to work on a 1300 patch
>> series you get from Andrew in the next installment to deal with
>> 88 unattributed patches? Answer the question 88 times and make
>> sure you get the answers right every time? Or abort and
>> hand-edit them to help mailinfo to notice the correct
>> attribution and re-run?
>
> For the internal consumption case it isn't a big deal. I
> can specify --author with something bogus and it works.
Yes.
>> I know I am guilty of suggesting "going interactive", but I have
>> a feeling that having an optional file that maps patch-name to
>> author might be easier to work with. If the old patches are
>> recycled in the updated -mm set, you probably can reuse the
>> mapping for them, adding entries for newly introduced "unnamed"
>> patches as needed.
>
> Short of getting the script where it has a sane restart in the
> middle mode going interactive and asking questions makes a lot
> of sense. Especially with smaller trees.
Yes perhaps on smaller trees, but that does not mean much. For
smaller trees and/or smaller patch series almost anything would
do.
How about doing something like this, so that the user can record
the fixup information, especially with --dry-run patch? Then
the next round from the updated -mm tree the user would not have
to retype them again ("then..fi" part should be indented in the
final version, but I did not want indentation changes to
distract you):
# Parse the author information
export GIT_AUTHOR_NAME=$(sed -ne 's/Author: //p' "$tmp_info")
export GIT_AUTHOR_EMAIL=$(sed -ne 's/Email: //p' "$tmp_info")
+ already_tried_fixup=
while test -z "$GIT_AUTHOR_EMAIL" && test -z "$GIT_AUTHOR_NAME" ; do
if [ -n "$quilt_author" ] ; then
GIT_AUTHOR_NAME="$quilt_author_name";
GIT_AUTHOR_EMAIL="$quilt_author_email";
else
+ if test -z "$already_tried_fixup"
+ then
+ patch_author=`grep author-fixup "$patch_name"`
+ already_tried_fixup=t
+ fi
+ if test -z "$patch_author"
+ then
echo "No author found in $patch_name";
echo "---"
cat $tmp_msg
echo -n "Author: ";
read patch_author
+ fi
echo "$patch_author"
> For Andrews tree before I play anymore with technical solutions I
> need to talk to Andrew and see if we can improve the situation
> upstream. Possibly with a quilt-audit script that finds problem
> patches.
Yes, that sounds very sensible.
^ permalink raw reply
* Re: [RFC] qgit with tabs
From: Pavel Roskin @ 2006-05-17 23:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550605131538u63b87002o3e9b5542c0e15bf7@mail.gmail.com>
Hi, Marco!
On Sun, 2006-05-14 at 00:38 +0200, Marco Costalba wrote:
> Hi Pavel,
>
> >
> > Sure, but I often want to see what changed in a particular file.
> >
> > And of course I only mean the subwindow dislaying the files affected by the
> > patch. The file tree should still have file annotation bound to the double
> > click.
> >
>
> I understand your reasons, but I have some doubts about this change:
>
> 1) The context menu is currently shared between the tree and the file
> list, splitting in two subcases adds some crap to the code (ok, this
> is not the real doubt ;-) )
Actually, "Get revision/patch" and "External diff" shouldn't be in the
popup used in the tree, or at least they should only appear for the
files affected by the currently selected patch.
"External diff" may be a good candidate for the toolbar if you find out
how to feed a multi-file patch to kompare (I guess you'll need two
temporary directories populated with differing files).
> 2) The context menu is currently shared between the file list in main
> view and the file list in patch view. The file list in patch view, of
> course, does not need a double click, a single click is enough to
> select corresponding file's diff. In main view you currently need a
> single click _plus_ a 'p' key press to change the view. So we should
> add another subcase here.
Yes. It should be perfectly OK to have different menus for different
contexts.
> 3) It is true that double clicking on a revision switch to the patch
> view at top position (if no file is selected), but it's also true that
> you can select the file's related diff directly in patch view with a
> single click on the right column file list.
That's true. But I still find myself double clicking on the file in the
file list and expecting to see the patch for the file. It's very
natural.
If I see the list of the recent patches, I see the descriptions and the
affected files. If I'm interested to see what changed in the file, it's
only natural for me to double-click the corresponding entry in the list.
Full history of a file is a much more advanced operation, and it's not
something I need to do often while browsing recently merged changes.
> 4) Once a file is selected, as example with a single click, you can
> browse through rev list and the selection is preserved, it means that
> anytime you switch to patch view page the content will be _already_
> centered on the correct diff.
That's useful, but irrelevant.
> 5) Double clicking on a file name is currently the only way (without
> opening the menu) to show the file content tab, with your suggested
> change we will have two ways to switch to patch view and no one to
> switch to file view.
That's a good thing. That's called consistency. git is about patches,
so showing the patches should be the default whenever practical.
The file viewer is a great feature, and it should be discoverable, but
it doesn't mean it should pop up when users expect something else.
>
> 6) Selecting from the tree view is very slow if you have to search for
> the correct file, it is fast only if the file is already selected, but
> in this case is faster to press 'p' key ;-)
That's true, but we are talking about double click behavior. Every
reasonable person can learn shortcuts, but the software should work
predictably even if operated by the mouse.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Linus Torvalds @ 2006-05-17 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ecb688.fsf@assigned-by-dhcp.cox.net>
On Wed, 17 May 2006, Junio C Hamano wrote:
>
> If you give a pattern that would match two files but one of them
> were hidden by .gitignore, this approach would not help you
> much.
Correct. On the other hand, what could you do?
I think that the common case for that is literally something like
git add dirname/
or
git add file*
and it turns out that there are object files under the directory, or that
there's a file.c, file.h _and_ a already-compiled file.o file.
Under both of those circumstances (one pattern that matches multiple files
but ignores others - or several different patterns where _some_ of the
patterns are ignored), we actually do what I think is the only sane thing.
Namely to just silently add everything that makes sense to add.
> Even if we wanted to say something like "if the user explicitly
> tells us to add etc/mtab~ by spelling it out, we should ignore
> *~ entry in .gitignore", the shell expansion bites us because it
> is done before we get to what the user give us. We cannot
> distinguish that with the user typing etc/?tab* for example.
Right.
The only case that we cando anything at all about is really the case where
we didn't add anything at all, and then we might reasonably ask "do you
know what the heck you're doing".
That's kind of what my last patch did. It's a total special case, but it's
the _only_ special case that I can see that is at all relevant (ie in all
other cases it would just be annoying as _hell_ if we started talking
about how we're ignoring object files. Of _course_ we're ignoring them,
and that's why they are listed in .gitignore).
So I'd love to have the built-in "git add", but quite frankly, if you drop
that last patch as "too ugly to live", I certainly won't complain. I sent
it out more as a "we -could- do this" thing rather than anything more
serious.
Linus
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Junio C Hamano @ 2006-05-17 23:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605171342370.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Well, with the new-and-improved builtin "git add", you could probably do
> something like the appended (on top of my most recent patch).
>
> It says
>
> No added files - did you perhaps mean to do a 'git update-index'?
>
> whenever it finds that "git add" has ignored a file and not actually added
> anything. That, btw, can happen either because it refused to see the file
> in the first place (ie it was ignored), or because all the files listed
> were already added.
>
> In both cases the warning may or may not be sensible.
>
> Anyway, I dunno. I don't have any strong opinions on this.
If you give a pattern that would match two files but one of them
were hidden by .gitignore, this approach would not help you
much.
Even if we wanted to say something like "if the user explicitly
tells us to add etc/mtab~ by spelling it out, we should ignore
*~ entry in .gitignore", the shell expansion bites us because it
is done before we get to what the user give us. We cannot
distinguish that with the user typing etc/?tab* for example.
If somebody (Jakub, perhaps?) cares strong enough, we could show
by default "matched the pathspec but ignored by .gitignore"
paths with fprintf(stderr, "ignoring '%s'\n"), and have an
option -q to squelch it.
I do not have strong feeling on this, so I'll see if somebody
comes up with a better implementation.
^ permalink raw reply
* [RFC 6/5] Fix ref log parsing so it works properly.
From: Shawn Pearce @ 2006-05-17 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The log parser was only ever matching the last log record due to
calling strtoul on "> 1136091609" rather than " 1136091609". Also
once a match for '@' has been found after the name of the ref there
is no point in looking for another '@' within the remaining text.
---
Uh yea, I found a couple of bugs. :-)
This applies on top of the other 5 patches (hence the 6/5).
refs.c | 2 +-
sha1_name.c | 1 +
2 files changed, 2 insertions(+), 1 deletions(-)
fbc7bf049255370f1611a5772c39d35422a81e24
diff --git a/refs.c b/refs.c
index 4c99e37..ae9825d 100644
--- a/refs.c
+++ b/refs.c
@@ -459,7 +459,7 @@ int read_ref_at(const char *ref, unsigne
c++;
if (c == logend || *c == '\n')
die("Log %s is corrupt.", logfile);
- date = strtoul(c, NULL, 10);
+ date = strtoul(c + 1, NULL, 10);
if (date <= at_time) {
if (get_sha1_hex(rec + 41, sha1))
die("Log %s is corrupt.", logfile);
diff --git a/sha1_name.c b/sha1_name.c
index 3ac3ab4..4376cb3 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -267,6 +267,7 @@ static int get_sha1_basic(const char *st
at_time = approxidate(date_spec);
free(date_spec);
len = at_mark;
+ break;
}
}
--
1.3.2.g7278
^ permalink raw reply related
* Re: [RFC 5/5] Support 'master@2 hours ago' syntax
From: Shawn Pearce @ 2006-05-17 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060517220613.GC30313@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <junkio@cox.net> wrote:
> >
> > Also I wonder how much complexity would we suffer and how much
> > efficiency would we gain if we binary search the logdata (the
> > committer info is variable length, so you would need to resync
> > in each step).
>
> I thought about doing this but did not think it would be worth the
> effort (either developer to code or CPU to execute) at this point
> in time. I don't think users will be pulling refs from the log very
> often and if they are they will probably be pulling from recent time,
> not very far back. Thus starting at the end and walking back is
> probably "good enough".
>
> But if it proves to be too slow in practice I'm sure I can come up
> with a faster way to walk through the log. :-)
I just ran a test on my PowerBook: walking a 10,000 line log file and
extracting the very oldest commit along. Each hit on git-rev-parse
seems to took about 100 ms. Hardly worth worrying about for casual
use. Further git-rev-parse is taking 73 ms just to run '--verify
HEAD' so an extra 30 ms to read the 10k log is pretty much nothing.
[spearce@pb15 trash]$ wc -l .git/logs/refs/heads/master
10000 .git/logs/refs/heads/master
[spearce@pb15 trash]$ head -n 1 .git/logs/refs/heads/master
b943559a305bdd6bdee2cef6e5df2413c3d30a00 0000000000000000000000000000000000000000 A U Thor <example@example.com> 1136091600 -0500
[spearce@pb15 trash]$ perl -e 'print scalar(localtime shift),"\n"' 1136091600
Sun Jan 1 00:00:00 2006
[spearce@pb15 trash]$ time ../../git-rev-parse --verify HEAD@'300 days'
warning: Log .git/logs/refs/heads/master only goes back to Thu, 1 Jan 1970 00:00:00 +0000.
b943559a305bdd6bdee2cef6e5df2413c3d30a00
real 0m0.112s
user 0m0.029s
sys 0m0.023s
[spearce@pb15 trash]$ time ../../git-rev-parse --verify HEAD@'300 days'
warning: Log .git/logs/refs/heads/master only goes back to Thu, 1 Jan 1970 00:00:00 +0000.
b943559a305bdd6bdee2cef6e5df2413c3d30a00
real 0m0.105s
user 0m0.029s
sys 0m0.023s
--
Shawn.
^ permalink raw reply
* Re: [RFC 5/5] Support 'master@2 hours ago' syntax
From: Shawn Pearce @ 2006-05-17 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqtwhpum.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> + fprintf(stderr, "warning: Log %s only goes back to %s.\n",
> + logfile, show_rfc2822_date(date, tz));
> + return 0;
>
> I am not sure about this part. If the oldest log entry was 3
> hours ago, the second oldest 2 hours ago, we can tell during
> that one hour period the ref was at that point. If the user
> asked "ref as of four hours ago", and if the oldest log entry
> had old SHA1 that is not 0{40} (because the log was not enabled
> before that record), it might make more sense to give that back.
If I understand my own code here what I'm doing is walking back
in the log file, realizing I fell off the first line of it, then
loading the old ref from the first line. This is the oldest ref
I can find so I return it as a valid ref to the caller but I'm
printing out this warning to tell the user that the oldest point
in time I found in the log is effectively the update date as I have
no idea when that old sha1 first became the value of the ref.
So I think I'm doing what you are expecting here. The log will start
with the value in the ref at the time the log started, not 0{40}
and that value is what gets returned when we have this warning
come out.. That's the best anyone can expect...
> Also I wonder how much complexity would we suffer and how much
> efficiency would we gain if we binary search the logdata (the
> committer info is variable length, so you would need to resync
> in each step).
I thought about doing this but did not think it would be worth the
effort (either developer to code or CPU to execute) at this point
in time. I don't think users will be pulling refs from the log very
often and if they are they will probably be pulling from recent time,
not very far back. Thus starting at the end and walking back is
probably "good enough".
But if it proves to be too slow in practice I'm sure I can come up
with a faster way to walk through the log. :-)
--
Shawn.
^ permalink raw reply
* Make git-rev-list understand --tags/--branches/--remotes
From: Linus Torvalds @ 2006-05-17 21:44 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
We shouldn't add stuff to git-rev-parse without teaching git-rev-list and
all the other tools to do the same.
In fact, these days there is much less reason for git-rev-parse in the
first place: it's usually used to verify a particular reference, or to
just split the different argument types up from each other. Most tools
don't need or use it any more (eg "gitk" will just pass its arguments
directly to git-rev-list).
With this, you can now do (for example)
gitk HEAD --not --tags
to see all the work on all the main branch that hasn't been included in a
tagged version (replace HEAD with "--branches" to show all branches, of
course).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/revision.c b/revision.c
index 2294b16..1fc6725 100644
--- a/revision.c
+++ b/revision.c
@@ -470,11 +470,13 @@ static int handle_one_ref(const char *pa
return 0;
}
-static void handle_all(struct rev_info *revs, unsigned flags)
+typedef int (*ref_fn_t)(int (*)(const char *, const unsigned char *));
+
+static void handle_ref(ref_fn_t fn, struct rev_info *revs, unsigned flags)
{
all_revs = revs;
all_flags = flags;
- for_each_ref(handle_one_ref);
+ fn(handle_one_ref);
}
static int add_parents_only(struct rev_info *revs, const char *arg, int flags)
@@ -614,7 +616,19 @@ int setup_revisions(int argc, const char
continue;
}
if (!strcmp(arg, "--all")) {
- handle_all(revs, flags);
+ handle_ref(for_each_ref, revs, flags);
+ continue;
+ }
+ if (!strcmp(arg, "--branches")) {
+ handle_ref(for_each_branch_ref, revs, flags);
+ continue;
+ }
+ if (!strcmp(arg, "--tags")) {
+ handle_ref(for_each_tag_ref, revs, flags);
+ continue;
+ }
+ if (!strcmp(arg, "--remotes")) {
+ handle_ref(for_each_remote_ref, revs, flags);
continue;
}
if (!strcmp(arg, "--not")) {
^ permalink raw reply related
* Re: [RFC 5/5] Support 'master@2 hours ago' syntax
From: Shawn Pearce @ 2006-05-17 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v7j4kec3h.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Wed, 17 May 2006, Junio C Hamano wrote:
> >>
> >> This does not allow '2006-05-17 00:00:00' as the timespec, and
> >> the documentation carefully avoids giving that example, but I
> >> think it is better to spell that limitation out.
> >
> > It doesn't? The "approxidate()" function should handle any reasonable date
> > specifier, and the above is certainly more than reasonable.
> >
> > Why doesn't approxidate handle it?
>
> The way I read the code is that get_sha1() would first do its
> magic at the first colon and feeds get_sha1_1() with prefix up
> to the first colon. This gets passed down to get_sha1_basic()
> and what approxidate() is fed is the suffix of that prefix. It
> ends up seeing stuff between '@' and ':'. I.e.
>
> "master@2006-05-17 00:00:00:cache.h"
>
> would ask for "00:00:cache.h" file in the "master" branch as of
> timestamp "2006-05-17 00".
Good catch. I'll see if I can deal with it later; probably early
tomorrow morning before work. It may just come down to documenting
this particular case as ambiguous and sure to parse the way you
did not mean it to. :-)
I tested a bunch of other date formats but not the basic ISO. Argh.
I'll send a test case soon for the expression parsing here, to be
sure we pull stuff from the log as expected as well as parse the
expression in a consistent way between releases. :-)
--
Shawn.
^ permalink raw reply
* Re: git-add + git-reset --hard = Arrrggh!
From: Shawn Pearce @ 2006-05-17 21:35 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0605170722u15702301p2565e8ac29a5a0da@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> On 5/17/06, Shawn Pearce <spearce@spearce.org> wrote:
> >All I can say is I'm very happy that update-index does a lot more
> >than just update the index. I was easily able to find the deleted
> >test by finding the most recently modified object in my .git/objects
> >directory and pulling it back out with git cat-file. :-)
> >
>
> Maybe git-lost-found would help here?
Thanks! I did that the hard way with git fsck-objects only to find
I actually had a lot of dangling objects. Luckily the most recent
one was the one I was looking for so a quick pipe through perl and
ls -t found it quite quickly.
What would have really helped me was just using GIT properly
rather than slamming something in fast with `git reset --hard`.
Somehow that option has become part of my finger feel when using
reset and that's just not right. :-)
--
Shawn.
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Linus Torvalds @ 2006-05-17 20:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4g1f4$anv$1@sea.gmane.org>
On Wed, 17 May 2006, Jakub Narebski wrote:
>
> The changes in docummentation are nice and dandy, but it would be even nicer
> if "git add" told us about "git update-index --add" when it adds no files,
> as it is certainly the case when something is wrong (perhaps user
> expectations, but still...).
Well, with the new-and-improved builtin "git add", you could probably do
something like the appended (on top of my most recent patch).
It says
No added files - did you perhaps mean to do a 'git update-index'?
whenever it finds that "git add" has ignored a file and not actually added
anything. That, btw, can happen either because it refused to see the file
in the first place (ie it was ignored), or because all the files listed
were already added.
In both cases the warning may or may not be sensible.
Anyway, I dunno. I don't have any strong opinions on this.
Linus
---
diff --git a/builtin-add.c b/builtin-add.c
index 82e8f44..8641137 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -12,6 +12,8 @@ #include "dir.h"
static const char builtin_add_usage[] =
"git-add [-n] [-v] <filepattern>...";
+static int ignored;
+
static int common_prefix(const char **pathspec)
{
const char *path, *slash, *next;
@@ -123,8 +125,10 @@ static void prune_directory(struct dir_s
/* Existing file? We must have ignored it */
match = pathspec[i];
- if (!lstat(match, &st))
+ if (!lstat(match, &st)) {
+ ignored = 1;
continue;
+ }
die("pathspec '%s' did not match any files", match);
}
}
@@ -257,6 +261,9 @@ int cmd_add(int argc, const char **argv,
for (i = 0; i < dir.nr; i++)
add_file_to_index(dir.entries[i]->name, verbose);
+ if (ignored && !active_cache_changed)
+ fprintf(stderr, "No added files - did you perhaps mean to do a 'git update-index'?\n");
+
if (active_cache_changed) {
if (write_cache(newfd, active_cache, active_nr) ||
commit_index_file(&cache_file))
^ permalink raw reply related
* Re: "git add $ignored_file" fail
From: Jakub Narebski @ 2006-05-17 20:35 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0605171325200.10823@g5.osdl.org>
Linus Torvalds wrote:
> On Wed, 17 May 2006, Pavel Roskin wrote:
>> [...] implementation should be easy - if the file
>> is present, but git-ls-file doesn't show it, tell the user to
>> adjust .gitignore or to use some flag like --force.
>
> Umm. That's exactly the semantics for "git add" right now. We _always_
> respect the ignore rules.
>
> That was what people were complaining about.
>
> Although I think Santi realized why we do it, and isn't even complaining
> any more.
>
> So we're all good again.
The changes in docummentation are nice and dandy, but it would be even nicer
if "git add" told us about "git update-index --add" when it adds no files,
as it is certainly the case when something is wrong (perhaps user
expectations, but still...).
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Linus Torvalds @ 2006-05-17 20:26 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Sean, jnareb, git
In-Reply-To: <1147895816.30618.6.camel@dv>
On Wed, 17 May 2006, Pavel Roskin wrote:
> On Wed, 2006-05-17 at 15:39 -0400, Sean wrote:
> > On Wed, 17 May 2006 15:23:06 -0400
> > Pavel Roskin <proski@gnu.org> wrote:
> >
> > Shouldn't git just always respect the ignore rules? Forcing someone to
> > remove a file from the .gitignore or employ the other work around
> > mentioned earlier doesn't seem too bad. How often are people adding
> > files that are explicitly ignored?
>
> That's a good idea! And the implementation should be easy - if the file
> is present, but git-ls-file doesn't show it, tell the user to
> adjust .gitignore or to use some flag like --force.
Umm. That's exactly the semantics for "git add" right now. We _always_
respect the ignore rules.
That was what people were complaining about.
Although I think Santi realized why we do it, and isn't even complaining
any more.
So we're all good again.
Linus
^ permalink raw reply
* Re: Do "git add" as a builtin
From: Linus Torvalds @ 2006-05-17 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd3ocvyy.fsf@assigned-by-dhcp.cox.net>
On Wed, 17 May 2006, Junio C Hamano wrote:
>
> By "not seeing the point", do you mean you do not agree with
> what bba319b5 and 45e48120 tried to do to help users?
Naah, I just didn't see why, and didn't bother to go exploring.
How about this patch on top of the previous one?
Linus
----
diff --git a/builtin-add.c b/builtin-add.c
index e815b3d..82e8f44 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -44,50 +44,89 @@ static int common_prefix(const char **pa
return prefix;
}
-static int match(const char **pathspec, const char *name, int namelen, int prefix)
+static int match_one(const char *match, const char *name, int namelen)
{
+ int matchlen;
+
+ /* If the match was just the prefix, we matched */
+ matchlen = strlen(match);
+ if (!matchlen)
+ return 1;
+
+ /*
+ * If we don't match the matchstring exactly,
+ * we need to match by fnmatch
+ */
+ if (strncmp(match, name, matchlen))
+ return !fnmatch(match, name, 0);
+
+ /*
+ * If we did match the string exactly, we still
+ * need to make sure that it happened on a path
+ * component boundary (ie either the last character
+ * of the match was '/', or the next character of
+ * the name was '/' or the terminating NUL.
+ */
+ return match[matchlen-1] == '/' ||
+ name[matchlen] == '/' ||
+ !name[matchlen];
+}
+
+static int match(const char **pathspec, const char *name, int namelen, int prefix, char *seen)
+{
+ int retval;
const char *match;
name += prefix;
namelen -= prefix;
- while ((match = *pathspec++) != NULL) {
- int matchlen;
-
+ for (retval = 0; (match = *pathspec++) != NULL; seen++) {
+ if (retval & *seen)
+ continue;
match += prefix;
- matchlen = strlen(match);
- if (!matchlen)
- return 1;
- if (!strncmp(match, name, matchlen)) {
- if (match[matchlen-1] == '/')
- return 1;
- switch (name[matchlen]) {
- case '/': case '\0':
- return 1;
- }
+ if (match_one(match, name, namelen)) {
+ retval = 1;
+ *seen = 1;
}
- if (!fnmatch(match, name, 0))
- return 1;
}
- return 0;
+ return retval;
}
static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
{
- int i;
+ char *seen;
+ int i, specs;
struct dir_entry **src, **dst;
+ for (specs = 0; pathspec[specs]; specs++)
+ /* nothing */;
+ seen = xmalloc(specs);
+ memset(seen, 0, specs);
+
src = dst = dir->entries;
i = dir->nr;
while (--i >= 0) {
struct dir_entry *entry = *src++;
- if (!match(pathspec, entry->name, entry->len, prefix)) {
+ if (!match(pathspec, entry->name, entry->len, prefix, seen)) {
free(entry);
continue;
}
*dst++ = entry;
}
dir->nr = dst - dir->entries;
+
+ for (i = 0; i < specs; i++) {
+ struct stat st;
+ const char *match;
+ if (seen[i])
+ continue;
+
+ /* Existing file? We must have ignored it */
+ match = pathspec[i];
+ if (!lstat(match, &st))
+ continue;
+ die("pathspec '%s' did not match any files", match);
+ }
}
static void fill_directory(struct dir_struct *dir, const char **pathspec)
^ permalink raw reply related
* [PATCH] Implement a --dry-run option to git-quiltimport
From: Eric W. Biederman @ 2006-05-17 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsln8cwn6.fsf@assigned-by-dhcp.cox.net>
Since large quilt trees like -mm can easily have patches
without clear authorship information, add a --dry-run
option to make the problem patches easy to find.
---
This patch should make it easy to communicate to Andrew
and others exactly which patches there are problems
with, and should make it possible to easily edit
those patches before they are imported.
Documentation/git-quiltimport.txt | 8 +++++++-
git-quiltimport.sh | 24 ++++++++++++++++++------
2 files changed, 25 insertions(+), 7 deletions(-)
cb0ff8090e1492f177a521b01cf987c16b125d81
diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt
index e694537..97f4071 100644
--- a/Documentation/git-quiltimport.txt
+++ b/Documentation/git-quiltimport.txt
@@ -9,7 +9,7 @@ git-quiltimport - Applies a quilt patchs
SYNOPSIS
--------
[verse]
-'git-quiltimport' [--author <author>] [--patches <dir>]
+'git-quiltimport' [--dry-run] [--author <author>] [--patches <dir>]
DESCRIPTION
@@ -29,6 +29,12 @@ preserved as the 1 line subject in the g
OPTIONS
-------
+--dry-run::
+ Walk through the patches in the series and warn
+ if we cannot find all of the necessary information to commit
+ a patch. At the time of this writing only missing author
+ information is warned about.
+
--author Author Name <Author Email>::
The author name and email address to use when no author
information can be found in the patch description.
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index be43f9d..476e078 100644
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -1,8 +1,9 @@
#!/bin/sh
-USAGE='--author <author> --patches </path/to/quilt/patch/directory>'
+USAGE='--dry-run --author <author> --patches </path/to/quilt/patch/directory>'
SUBDIRECTORY_ON=Yes
. git-sh-setup
+dry_run=""
quilt_author=""
while case "$#" in 0) break;; esac
do
@@ -19,6 +20,11 @@ do
shift
;;
+ --dry-run)
+ shift
+ dry_run=1
+ ;;
+
--pa=*|--pat=*|--patc=*|--patch=*|--patche=*|--patches=*)
QUILT_PATCHES=$(expr "$1" : '-[^=]*\(.*\)')
shift
@@ -75,8 +81,12 @@ for patch_name in $(cat "$QUILT_PATCHES/
if [ -n "$quilt_author" ] ; then
GIT_AUTHOR_NAME="$quilt_author_name";
GIT_AUTHOR_EMAIL="$quilt_author_email";
+ elif [ -n "$dry_run" ]; then
+ echo "No author found in $patch_name" >&2;
+ GIT_AUTHOR_NAME="dry-run-not-found";
+ GIT_AUTHOR_EMAIL="dry-run-not-found";
else
- echo "No author found in $patch_name";
+ echo "No author found in $patch_name" >&2;
echo "---"
cat $tmp_msg
echo -n "Author: ";
@@ -98,9 +108,11 @@ for patch_name in $(cat "$QUILT_PATCHES/
SUBJECT=$(echo $patch_name | sed -e 's/.patch$//')
fi
- git-apply --index -C1 "$tmp_patch" &&
- tree=$(git-write-tree) &&
- commit=$((echo "$SUBJECT"; echo; cat "$tmp_msg") | git-commit-tree $tree -p $commit) &&
- git-update-ref HEAD $commit || exit 4
+ if [ -z "$dry_run" ] ; then
+ git-apply --index -C1 "$tmp_patch" &&
+ tree=$(git-write-tree) &&
+ commit=$((echo "$SUBJECT"; echo; cat "$tmp_msg") | git-commit-tree $tree -p $commit) &&
+ git-update-ref HEAD $commit || exit 4
+ fi
done
rm -rf $tmp_dir || exit 5
--
1.3.2.g5041c-dirty
^ permalink raw reply related
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Jakub Narebski @ 2006-05-17 20:06 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xp0ctlf.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> [cut long description]
>>
>> The description you gave is nice, but it belongs in Tutorial rather than
>> in the Glossary.
>
> I suspect I was not clear enough for you when I said:
>
> I cannot easily do a glossary entry to describe that specific
> term, but maybe somebody else can split the following up and
> paraphrase.
Maybe I should say that the description you gave is a nice source for
eventual glossary entry, but I feel that as the whole is worth preserving
in some tutorial text.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Junio C Hamano @ 2006-05-17 19:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4fsla$oth$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> [cut long description]
>
> The description you gave is nice, but it belongs in Tutorial rather than in
> Glossary.
I suspect I was not clear enough for you when I said:
I cannot easily do a glossary entry to describe that specific
term, but maybe somebody else can split the following up and
paraphrase.
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Pavel Roskin @ 2006-05-17 19:56 UTC (permalink / raw)
To: Sean; +Cc: jnareb, git
In-Reply-To: <20060517153903.6b896fdd.seanlkml@sympatico.ca>
On Wed, 2006-05-17 at 15:39 -0400, Sean wrote:
> On Wed, 17 May 2006 15:23:06 -0400
> Pavel Roskin <proski@gnu.org> wrote:
>
> Shouldn't git just always respect the ignore rules? Forcing someone to
> remove a file from the .gitignore or employ the other work around
> mentioned earlier doesn't seem too bad. How often are people adding
> files that are explicitly ignored?
That's a good idea! And the implementation should be easy - if the file
is present, but git-ls-file doesn't show it, tell the user to
adjust .gitignore or to use some flag like --force.
Libification of git-ls-files would allow even more precise messages.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Jakub Narebski @ 2006-05-17 19:52 UTC (permalink / raw)
To: git
In-Reply-To: <BAYC1-PASMTP12920BE00C27B0CF31CB9FAEA10@CEZ.ICE>
Sean wrote:
> Shouldn't git just always respect the ignore rules? Forcing someone to
> remove a file from the .gitignore [...]
Or adding exclude rule (!filename) for specific file to .gitignore.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Sean @ 2006-05-17 19:39 UTC (permalink / raw)
To: Pavel Roskin; +Cc: jnareb, git
In-Reply-To: <1147893786.16654.5.camel@dv>
On Wed, 17 May 2006 15:23:06 -0400
Pavel Roskin <proski@gnu.org> wrote:
> Can we apply the ignore rules to the directories but not the files?
>
> This way, "git-add *" would add all files (rarely a good idea), whereas
> "git-add ." would respect the ignore rules.
>
> Kludgy as it is, this approach would generally produce more expected
> results than others. If you let the shell expand the pattern, expect
> all junk to be added. If you let git expand the pattern, expect it to
> adhere to the ignore rules.
Shouldn't git just always respect the ignore rules? Forcing someone to
remove a file from the .gitignore or employ the other work around
mentioned earlier doesn't seem too bad. How often are people adding
files that are explicitly ignored?
Sean
^ permalink raw reply
* Re: [PATCH] builtin-grep: workaround for non GNU grep.
From: Linus Torvalds @ 2006-05-17 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodxwcwa1.fsf@assigned-by-dhcp.cox.net>
On Wed, 17 May 2006, Junio C Hamano wrote:
>
> This makes -c misbehave in a subtle way.
>
> git grep -c -e no-such-string-anywhere | head -n 1
>
> But I do not think we care.
Ahh, yes. That appears to be unfixable without using special GNU
extensions.
I agree that we probably don't care, though.
Linus
^ permalink raw reply
* Re: 1.3.2 git-clone segfaults
From: Pavel Roskin @ 2006-05-17 19:29 UTC (permalink / raw)
To: Bill Yoder; +Cc: git, Wolfgang Denk
In-Reply-To: <879BAFDD-87DB-4041-8753-5D63630076B5@cs.utexas.edu>
On Wed, 2006-05-17 at 13:32 -0500, Bill Yoder wrote:
> /usr/local/downloads/git-1.3.2/git-clone: line 323: 25972
> Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
I've seen git-http-fetch segfaults many times when cloning qgit, but
it's hard to reproduce on demand.
I think you should compile git without optimizations and allow coredumps
(ulimit -c unlimited), then load git-http-fetch in gdb with the core
(gdb --core=core git-http-fetch) and run bt to see the backtrace.
--
Regards,
Pavel Roskin
^ 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