* 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
* Re: 1.3.2 git-clone segfaults
From: Bill Yoder @ 2006-05-17 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Wolfgang Denk
In-Reply-To: <7vwtckcwve.fsf@assigned-by-dhcp.cox.net>
Dear Junio (and Fernando):
> Could you try 1.3.3?
Here are the last few lines of output from 1.3.3, cooked with gcc 3.2.3:
Getting alternates list for http://www.denx.de/git/linux-2.6-denx.git/
got b603ba9e9b5482d3e80fc8e0fa96bb9a943502ff
got 1635ee25918fc19ea613d1e8dbcb672075220efb
got dd7d627bf66f306b4ee9401f06ed4fb574896a85
got c771a7db9871bfa3f3c76b78c1369111c4be767b
got 374e20ad8b0d02f15fbcaa5315e272eabd6c4f76
got a8bef1d1371cc999ce6882d355c7554ca7738173
got ab08f35cbc355f4b2058d88ff289552f202ea5b4
Getting pack list for http://www.denx.de/git/linux-2.6-denx.git/
got 92297ff24e8525de2617dff728b3420a4649f66a
got 93dcbe1abb4c83b65cc6af59fb84c3c5e16effbb
got 41ecbb847f32f301a7ecd30b6438fea702886a33
got 94f557fa46369ec94ec718d25616ceb0b73fd2d2
got 09e00433c78e267b37b3f485c0d877de780a0674
got da7c09e4ede6e83198bf1ab5f16c571b0cc214ee
got 85533ec5aaa17f4146452a16ef61ca40fc601c80
got 50e338d2ffda9cb5a835d67849e38ae0ceba1647
/usr/local/downloads/git-1.3.3/git-clone: line 323: 1124
Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
Regards,
Bill
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Pavel Roskin @ 2006-05-17 19:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4f9eo$b60$1@sea.gmane.org>
On Wed, 2006-05-17 at 15:46 +0200, Jakub Narebski wrote:
> Santi wrote:
>
> > In the other way, now I find the value of being able to say:
> >
> > $ git add t*
> >
> > and be sure that it does not add an ignored file. Unfortunately
> > git-add cannot distinguish between both.
>
> Well, it could. If 'git add <filespec>' would result in NO files
> added, take <filespec> as literate <file> (filename), regardless
> of ignores.
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.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Eric W. Biederman @ 2006-05-17 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsln8cwn6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Importing a quilt patch series into git is not very difficult
>> but parsing the patch descriptions and all of the other
>> minutia take a bit of effort to get right, so this automates it.
>>
>> Since git and quilt complement each other it makes sense
>> to make it easy to go back and forth between the two.
>>
>> If a patch is encountered that it cannot derive the author
>> from the user is asked.
>
> 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.
There are a few tweaks that can be made to git-mailinfo to
make it better at parsing information out of patches. I
cut the list down to about 49 that way. I had it all of the
way down to 1. But then I realized that the first Singed-off-by
really doesn't accurately reflect the author. I suspect a
few of my other teaks are equally suspicious.
> 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.
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.
Eric
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Jakub Narebski @ 2006-05-17 19:13 UTC (permalink / raw)
To: git
In-Reply-To: <7viro4ecao.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> In 'Documentation/glossary.txt' we have:
>> ----
>> branch::
>> A non-cyclical graph of revisions, i.e. the complete history of
>> a particular revision, which is called the branch head. The
>> branch heads are stored in `$GIT_DIR/refs/heads/`.
>> ----
>
> While technically it might be correct, the above description for
> "branch" completely misses the point in the context of other
> entries. I do not recall when this entry was first written, but
> I suspect it probably predates other entries that talk about the
> same thing.
[cut long description]
The description you gave is nice, but it belongs in Tutorial rather than in
Glossary. Additionally it mainly deals with branches fron the 'revision
history' point of view, although the 'commit' point of view can also be
seen.
Glossary entry should be short, up to the point, and encompass al three
points of view:
a.) conceptual point of view, i.e. "branch is separate line of
development" (be it stable or development direction, introducing new
feature aka. 'topic', or following aka. 'tracking' changes in other
repository),
b) revision history point of view, i.e. "on branch means, roughly,
reachable from branch head aka. tip", or "branch is lineage of history of
project" (somewhat mudded by merges[*1*], fork points[*2*] and multiple
roots). This is what current glossary entry tries to present,
c) commit point of view, i.e. "branch tip is where we do commit
changes" (branch tip is [one of] parent(s) of current commit, and branch
tip is advanced to new commit).
[*1*] Problem with merges:
---.---.---A-\--.---.---.---B-- branch1
\
---.---.---C---*D---.---.---E-- branch2
Does A belong to branch2? It is one of parents of commit D. We can assume
that only first parent in merges continues branch. But what if we have the
following history:
---.---.---A-\ <---- there was branch1 here
\
---.---.---C---*D---.---.---E-- branch2
To which branch belongs A then?
[*2*] Problem with fork point
/--1---2---3-- maintenance/stable/fixes branch
/
---A---B----C---D---E-- master/development branch
Following the ancestry chain we get that commit A is on branch 'maint' (it
is also on branch 'master'); git does not record fork points. Perhaps the
branch logging and/or per branch configuration could be used to resolve
this issue.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [Patch] git-cvsimport: tiny fix
From: Junio C Hamano @ 2006-05-17 19:12 UTC (permalink / raw)
To: git; +Cc: Elrond
In-Reply-To: <20060510173703.GA10335@memak.tu-darmstadt.de>
Elrond <elrond+kernel.org@samba-tng.org> writes:
> git-cvsimport: Handle "Removed" from pserver
>
> Sometimes the pserver says "Removed" instead of
> "Remove-entry".
>
> Signed-off-by: Elrond <elrond+kernel.org@samba-tng.org>
> ---
> Hi,
>
> At least the above happened to me on a repository I tried
> to convert.
> Without the patch, it just die("Unknown: Removed ...")s.
Could somebody who actually works with CVS import Ack this?
Pretty please?
^ permalink raw reply
* Re: Do "git add" as a builtin
From: Junio C Hamano @ 2006-05-17 19:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605170927050.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> ... I dropped the strange "--error-unmatch" test, because it
> was really ugly and I didn't see the point.
By "not seeing the point", do you mean you do not agree with
what bba319b5 and 45e48120 tried to do to help users?
$ git add no-such-path-in-the-tree
$ git add 'this-pattern-matches-nobody*'
More realistically:
$ git add Documentaiton ;# misspelled
[References]
(bba319b5)
When you say "git commit Documentaiton" to make partial commit
for the files only in that directory, we did not detect that as
a misspelled pathname and attempted to commit index without
change. If nothing matched, there is no harm done, but if the
index gets modified otherwise by having another valid pathspec
or after an explicit update-index, a user will not notice
without paying attention to the "git status" preview.
This introduces --error-unmatch option to ls-files, and uses it
to detect this common user error.
(45e48120)
This is in the same spirit as an earlier patch for git-commit.
It does an extra ls-files to avoid complaining when a fully
tracked directory name is given on the command line (otherwise
--others restriction would say the pathspec does not match).
^ permalink raw reply
* Re: [PATCH] builtin-grep: workaround for non GNU grep.
From: Junio C Hamano @ 2006-05-17 18:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605171109170.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> I think this is portable and correct.
>
> Of course, it still ignores the fact that not all grep's support some of
> the flags like -F/-L/-A/-C etc, but for those cases, the external grep
> itself will happily just say "unrecognized option -F" or similar.
>
> So with this change, "git grep" should handle all the flags the native
> grep handles, which is really quite fine. We don't _need_ to expose
> anything more, and if you do want our extensions, you can get them with
> "--uncached" and an up-to-date index.
>
> No configuration necessary, and we automatically take advantage of any
> native grep we have, if possible.
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.
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Junio C Hamano @ 2006-05-17 18:51 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1bqtw4hk7.fsf_-_@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Importing a quilt patch series into git is not very difficult
> but parsing the patch descriptions and all of the other
> minutia take a bit of effort to get right, so this automates it.
>
> Since git and quilt complement each other it makes sense
> to make it easy to go back and forth between the two.
>
> If a patch is encountered that it cannot derive the author
> from the user is asked.
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?
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.
^ permalink raw reply
* Re: 1.3.2 git-clone segfaults
From: Junio C Hamano @ 2006-05-17 18:46 UTC (permalink / raw)
To: Bill Yoder; +Cc: git
In-Reply-To: <879BAFDD-87DB-4041-8753-5D63630076B5@cs.utexas.edu>
Bill Yoder <byoder@cs.utexas.edu> writes:
> I have twice downloaded git-1.3.2, most recently the git-1.3.2.tar.gz
> source package from http://www.t2-project.org/packages/git.html.
Could you try 1.3.3?
^ permalink raw reply
* [PATCH] Implement git-quiltimport (take 2)
From: Eric W. Biederman @ 2006-05-17 18:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7v1wut2p5z.fsf@assigned-by-dhcp.cox.net>
Importing a quilt patch series into git is not very difficult
but parsing the patch descriptions and all of the other
minutia take a bit of effort to get right, so this automates it.
Since git and quilt complement each other it makes sense
to make it easy to go back and forth between the two.
If a patch is encountered that it cannot derive the author
from the user is asked.
---
Documentation/git-quiltimport.txt | 55 +++++++++++++++++++
Makefile | 2 -
git-quiltimport.sh | 106 +++++++++++++++++++++++++++++++++++++
3 files changed, 162 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-quiltimport.txt
create mode 100644 git-quiltimport.sh
5041c213c1090007dac9c03049c18a1433ccbefc
diff --git a/Documentation/git-quiltimport.txt b/Documentation/git-quiltimport.txt
new file mode 100644
index 0000000..e694537
--- /dev/null
+++ b/Documentation/git-quiltimport.txt
@@ -0,0 +1,55 @@
+git-quiltimport(1)
+================
+
+NAME
+----
+git-quiltimport - Applies a quilt patchset onto the current branch
+
+
+SYNOPSIS
+--------
+[verse]
+'git-quiltimport' [--author <author>] [--patches <dir>]
+
+
+DESCRIPTION
+-----------
+Applies a quilt patchset onto the current git branch, preserving
+the patch boundaries, patch order, and patch descriptions present
+in the quilt patchset.
+
+For each patch the code attempts to extract the author from the
+patch description. If that fails it falls back to the author
+specified with --author. If the --author flag was not given
+the patch description is displayed and the user is asked to
+interactively enter the author of the patch.
+
+If a subject is not found in the patch description the patch name is
+preserved as the 1 line subject in the git description.
+
+OPTIONS
+-------
+--author Author Name <Author Email>::
+ The author name and email address to use when no author
+ information can be found in the patch description.
+
+--patches <dir>::
+ The directory to find the quilt patches and the
+ quilt series file.
+
+ The default for the patch directory is patches
+ or the value of the $QUILT_PATCHES environment
+ variable.
+
+Author
+------
+Written by Eric Biederman <ebiederm@lnxi.com>
+
+Documentation
+--------------
+Documentation by Eric Biederman <ebiederm@lnxi.com>
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index 37fbe78..1f4abe6 100644
--- a/Makefile
+++ b/Makefile
@@ -125,7 +125,7 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh git-grep.sh \
- git-lost-found.sh
+ git-lost-found.sh git-quiltimport.sh
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
new file mode 100644
index 0000000..be43f9d
--- /dev/null
+++ b/git-quiltimport.sh
@@ -0,0 +1,106 @@
+#!/bin/sh
+USAGE='--author <author> --patches </path/to/quilt/patch/directory>'
+SUBDIRECTORY_ON=Yes
+. git-sh-setup
+
+quilt_author=""
+while case "$#" in 0) break;; esac
+do
+ case "$1" in
+ --au=*|--aut=*|--auth=*|--autho=*|--author=*)
+ quilt_author=$(expr "$1" : '-[^=]*\(.*\)')
+ shift
+ ;;
+
+ --au|--aut|--auth|--autho|--author)
+ case "$#" in 1) usage ;; esac
+ shift
+ quilt_author="$1"
+ shift
+ ;;
+
+ --pa=*|--pat=*|--patc=*|--patch=*|--patche=*|--patches=*)
+ QUILT_PATCHES=$(expr "$1" : '-[^=]*\(.*\)')
+ shift
+ ;;
+
+ --pa|--pat|--patc|--patch|--patche|--patches)
+ case "$#" in 1) usage ;; esac
+ shift
+ QUILT_PATCHES="$1"
+ shift
+ ;;
+
+ *)
+ break
+ ;;
+ esac
+done
+
+# Quilt Author
+if [ -n "$quilt_author" ] ; then
+ quilt_author_name=$(expr "z$quilt_author" : 'z\(.*[^ ]\) *<.*') &&
+ quilt_author_email=$(expr "z$quilt_author" : '.*<\([^>]*\)') &&
+ test '' != "$quilt_author_name" &&
+ test '' != "$quilt_author_email" ||
+ die "malformatted --author parameter"
+fi
+
+# Quilt patch directory
+: ${QUILT_PATCHES:=patches}
+if ! [ -d "$QUILT_PATCHES" ] ; then
+ echo "The \"$QUILT_PATCHES\" directory does not exist."
+ exit 1
+fi
+
+# Temporay directories
+tmp_dir=.dotest
+tmp_msg="$tmp_dir/msg"
+tmp_patch="$tmp_dir/patch"
+tmp_info="$tmp_dir/info"
+
+
+# Find the intial commit
+commit=$(git-rev-parse HEAD)
+
+mkdir $tmp_dir || exit 2
+for patch_name in $(cat "$QUILT_PATCHES/series" | grep -v '^#'); do
+ echo $patch_name
+ (cat $QUILT_PATCHES/$patch_name | git-mailinfo "$tmp_msg" "$tmp_patch" > "$tmp_info") || exit 3
+
+ # 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")
+ 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
+ echo "No author found in $patch_name";
+ echo "---"
+ cat $tmp_msg
+ echo -n "Author: ";
+ read patch_author
+
+ echo "$patch_author"
+
+ patch_author_name=$(expr "z$patch_author" : 'z\(.*[^ ]\) *<.*') &&
+ patch_author_email=$(expr "z$patch_author" : '.*<\([^>]*\)') &&
+ test '' != "$patch_author_name" &&
+ test '' != "$patch_author_email" &&
+ GIT_AUTHOR_NAME="$patch_author_name" &&
+ GIT_AUTHOR_EMAIL="$patch_author_email"
+ fi
+ done
+ export GIT_AUTHOR_DATE=$(sed -ne 's/Date: //p' "$tmp_info")
+ export SUBJECT=$(sed -ne 's/Subject: //p' "$tmp_info")
+ if [ -z "$SUBJECT" ] ; then
+ 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
+done
+rm -rf $tmp_dir || exit 5
--
1.3.2.g2256-dirty
^ permalink raw reply related
* Re: 1.3.2 git-clone segfaults
From: Fernando J. Pereda @ 2006-05-17 18:41 UTC (permalink / raw)
To: Bill Yoder; +Cc: git, Wolfgang Denk
In-Reply-To: <879BAFDD-87DB-4041-8753-5D63630076B5@cs.utexas.edu>
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
On Wed, May 17, 2006 at 01:32:39PM -0500, Bill Yoder wrote:
> Please let me know if I can supply more information or if I'm
> misusing the command.
I reported this same issue to Nick Hengeveld and he said he'll take a
look at it. this is also Gentoo Bug #133412 [1].
- ferdy
[1] https://bugs.gentoo.org/show_bug.cgi?id=133412
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* 1.3.2 git-clone segfaults
From: Bill Yoder @ 2006-05-17 18:32 UTC (permalink / raw)
To: git; +Cc: Wolfgang Denk
Dear Git maintainers:
I have twice downloaded git-1.3.2, most recently the git-1.3.2.tar.gz
source package from http://www.t2-project.org/packages/git.html.
Both the prebuilt version and the source version, built with gcc
3.2.3 on x86/Linux, run into trouble when executing this command:
% git --exec-path=/usr/local/downloads/git-1.3.2 clone http://
www.denx.de/git/linux-2.6-denx.git linux-2.6-denx
Both git operations proceed with some 18,000+ lines of output,
culminating in this message:
got 243a15f54002445f5b8b4938981ec90430b73ec6
got 03914b7e41b17871aea961f6522ec4ce26a4f8ed
got a305ae2e44b6dde305d3afe241768e32c47d8907
got 33a653913d942fa35c263edf1d019f36f4e0f5b1
got f13f49afe198cc0d59e998fe3a6e721d70fca6b4
error: The requested URL returned error: 405 (curl_result = 22,
http_code = 405, sha1 = b323ff5779672c77b6adfba1c1bdc87f4981f85c)
error: Unable to find b323ff5779672c77b6adfba1c1bdc87f4981f85c under
http://www.denx.de/git/linux-2.6-denx.git/
Cannot obtain needed blob b323ff5779672c77b6adfba1c1bdc87f4981f85c
while processing commit ea989b3245993f95e58e6c0320bf6165a949b072.
Waiting for http://www.denx.de/git/linux-2.6-denx.git/objects/
31/548303ee3767095f86efb47696ce433662450e
/usr/local/downloads/git-1.3.2/git-clone: line 323: 25972
Segmentation fault git-http-fetch -v -a -w "$tname" "$name" "$1/"
I have also tested git-1.2.3 built from source, and it works dandily.
Please let me know if I can supply more information or if I'm
misusing the command.
Thanks,
Bill Yoder
Git Newbie
^ 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