* Do "git add" as a builtin
From: Linus Torvalds @ 2006-05-17 16:33 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
First try. Let's see how well this works.
In many ways, the hard parts of "git commit" are not so different from
this, and a builtin commit would share a lot of the code, I think.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
It passes the tests for me. I dropped the strange "--error-unmatch" test,
because it was really ugly and I didn't see the point. It seems to do all
the right things, but hey, a mistake here is obviously a bad thing.
I suspect that if I get around to "git commit", we'd be getting to the
point where most of the core/easy/often-used/whatever commands would be
all built-in.
diff --git a/Makefile b/Makefile
index f43ac63..e6f7794 100644
--- a/Makefile
+++ b/Makefile
@@ -218,7 +218,7 @@ LIB_OBJS = \
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
- builtin-grep.o
+ builtin-grep.o builtin-add.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/builtin-add.c b/builtin-add.c
new file mode 100644
index 0000000..e815b3d
--- /dev/null
+++ b/builtin-add.c
@@ -0,0 +1,228 @@
+/*
+ * "git add" builtin command
+ *
+ * Copyright (C) 2006 Linus Torvalds
+ */
+#include <fnmatch.h>
+
+#include "cache.h"
+#include "builtin.h"
+#include "dir.h"
+
+static const char builtin_add_usage[] =
+"git-add [-n] [-v] <filepattern>...";
+
+static int common_prefix(const char **pathspec)
+{
+ const char *path, *slash, *next;
+ int prefix;
+
+ if (!pathspec)
+ return 0;
+
+ path = *pathspec;
+ slash = strrchr(path, '/');
+ if (!slash)
+ return 0;
+
+ prefix = slash - path + 1;
+ while ((next = *++pathspec) != NULL) {
+ int len = strlen(next);
+ if (len >= prefix && !memcmp(path, next, len))
+ continue;
+ for (;;) {
+ if (!len)
+ return 0;
+ if (next[--len] != '/')
+ continue;
+ if (memcmp(path, next, len+1))
+ continue;
+ prefix = len + 1;
+ break;
+ }
+ }
+ return prefix;
+}
+
+static int match(const char **pathspec, const char *name, int namelen, int prefix)
+{
+ const char *match;
+
+ name += prefix;
+ namelen -= prefix;
+
+ while ((match = *pathspec++) != NULL) {
+ int matchlen;
+
+ 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 (!fnmatch(match, name, 0))
+ return 1;
+ }
+ return 0;
+}
+
+static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
+{
+ int i;
+ struct dir_entry **src, **dst;
+
+ src = dst = dir->entries;
+ i = dir->nr;
+ while (--i >= 0) {
+ struct dir_entry *entry = *src++;
+ if (!match(pathspec, entry->name, entry->len, prefix)) {
+ free(entry);
+ continue;
+ }
+ *dst++ = entry;
+ }
+ dir->nr = dst - dir->entries;
+}
+
+static void fill_directory(struct dir_struct *dir, const char **pathspec)
+{
+ const char *path, *base;
+ int baselen;
+
+ /* Set up the default git porcelain excludes */
+ memset(dir, 0, sizeof(*dir));
+ dir->exclude_per_dir = ".gitignore";
+ path = git_path("info/exclude");
+ if (!access(path, R_OK))
+ add_excludes_from_file(dir, path);
+
+ /*
+ * Calculate common prefix for the pathspec, and
+ * use that to optimize the directory walk
+ */
+ baselen = common_prefix(pathspec);
+ path = ".";
+ base = "";
+ if (baselen) {
+ char *common = xmalloc(baselen + 1);
+ common = xmalloc(baselen + 1);
+ memcpy(common, *pathspec, baselen);
+ common[baselen] = 0;
+ path = base = common;
+ }
+
+ /* Read the directory and prune it */
+ read_directory(dir, path, base, baselen);
+ if (pathspec)
+ prune_directory(dir, pathspec, baselen);
+}
+
+static int add_file_to_index(const char *path, int verbose)
+{
+ int size, namelen;
+ struct stat st;
+ struct cache_entry *ce;
+
+ if (lstat(path, &st))
+ die("%s: unable to stat (%s)", path, strerror(errno));
+
+ if (!S_ISREG(st.st_mode) && !S_ISLNK(st.st_mode))
+ die("%s: can only add regular files or symbolic links", path);
+
+ namelen = strlen(path);
+ size = cache_entry_size(namelen);
+ ce = xcalloc(1, size);
+ memcpy(ce->name, path, namelen);
+ ce->ce_flags = htons(namelen);
+ fill_stat_cache_info(ce, &st);
+
+ ce->ce_mode = create_ce_mode(st.st_mode);
+ if (!trust_executable_bit) {
+ /* If there is an existing entry, pick the mode bits
+ * from it.
+ */
+ int pos = cache_name_pos(path, namelen);
+ if (pos >= 0)
+ ce->ce_mode = active_cache[pos]->ce_mode;
+ }
+
+ if (index_path(ce->sha1, path, &st, 1))
+ die("unable to index file %s", path);
+ if (add_cache_entry(ce, ADD_CACHE_OK_TO_ADD))
+ die("unable to add %s to index",path);
+ if (verbose)
+ printf("add '%s'\n", path);
+ return 0;
+}
+
+static struct cache_file cache_file;
+
+int cmd_add(int argc, const char **argv, char **envp)
+{
+ int i, newfd;
+ int verbose = 0, show_only = 0;
+ const char *prefix = setup_git_directory();
+ const char **pathspec;
+ struct dir_struct dir;
+
+ git_config(git_default_config);
+
+ newfd = hold_index_file_for_update(&cache_file, get_index_file());
+ if (newfd < 0)
+ die("unable to create new cachefile");
+
+ if (read_cache() < 0)
+ die("index file corrupt");
+
+ for (i = 1; i < argc; i++) {
+ const char *arg = argv[i];
+
+ if (arg[0] != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "-n")) {
+ show_only = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-v")) {
+ verbose = 1;
+ continue;
+ }
+ die(builtin_add_usage);
+ }
+ git_config(git_default_config);
+ pathspec = get_pathspec(prefix, argv + i);
+
+ fill_directory(&dir, pathspec);
+
+ if (show_only) {
+ const char *sep = "", *eof = "";
+ for (i = 0; i < dir.nr; i++) {
+ printf("%s%s", sep, dir.entries[i]->name);
+ sep = " ";
+ eof = "\n";
+ }
+ fputs(eof, stdout);
+ return 0;
+ }
+
+ for (i = 0; i < dir.nr; i++)
+ add_file_to_index(dir.entries[i]->name, verbose);
+
+ if (active_cache_changed) {
+ if (write_cache(newfd, active_cache, active_nr) ||
+ commit_index_file(&cache_file))
+ die("Unable to write new index file");
+ }
+
+ return 0;
+}
diff --git a/builtin.h b/builtin.h
index 7744f7d..1b77f4b 100644
--- a/builtin.h
+++ b/builtin.h
@@ -24,5 +24,6 @@ extern int cmd_count_objects(int argc, c
extern int cmd_push(int argc, const char **argv, char **envp);
extern int cmd_grep(int argc, const char **argv, char **envp);
+extern int cmd_add(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index a94d9ee..fac46af 100644
--- a/git.c
+++ b/git.c
@@ -50,6 +50,7 @@ static void handle_internal_command(int
{ "count-objects", cmd_count_objects },
{ "diff", cmd_diff },
{ "grep", cmd_grep },
+ { "add", cmd_add },
};
int i;
^ permalink raw reply related
* Re: Git 1.3.2 on Solaris
From: Jason Riedy @ 2006-05-17 16:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Stefan Pfetzing, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605170919290.10823@g5.osdl.org>
And Linus Torvalds writes:
-
- Now, I'm told pkgsrc is horrible, but it can't be so horrid as to not
- allow private directories?
Works fine.
1) Depend on the GNU tools through the buildlink, um, stuff.
2) Add a config.mak via a local patch that sets gitexecprefix.
3) Add another local patch that sets up links within that
gitexecprefix to the GNU tools. Remember to check if the
GNU tools were installed without the silly g prefix.
And pkgsrc itself works just fine without the silly g prefix,
or at least does for me as a mere user (and as well as it does
work). But if you intend on adding the package upstream, it'll
need something to cope with the g. And pkgsrc handles local
patches...
Jason
^ permalink raw reply
* Re: [PATCH] builtin-grep: workaround for non GNU grep.
From: Junio C Hamano @ 2006-05-17 17:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605170722590.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> - if (!cached) {
>> + if (!cached &&
>> + (!NO_H_OPTION_IN_GREP ||
>> + (!opt->count && !opt->unmatch_name_only))) {
>> hit = external_grep(opt, paths, cached);
>> if (hit >= 0)
>> return hit;
>
> That's the ugliest test ever, and at all the wrong levels.
>
> Just make "external_grep()" test for the cases that it cannot handle, and
> return -1. That's how it's designed to work.
Ah.... *BLUSH* I was not thinking when I saw that "if (hit >= 0)"
stuff. Yes, you made it to fall back.
^ permalink raw reply
* Re: [PATCH] builtin-grep: workaround for non GNU grep.
From: Junio C Hamano @ 2006-05-17 17:42 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <4fb292fa0605170839r259732dcw1c1bae3f1808db32@mail.gmail.com>
"Bertrand Jacquin" <beber.mailing@gmail.com> writes:
> Sorry, maybe a C code beginner question but while you define
> NO_H_OPTION_IN_GREP in Makefile, why don't use a build time ``if''
> instead of a runtime one ?
>
> Like :
>
> #if NO_H_OPTION_IN_GREP
> push_arg("/dev/null");
> #else
> push_arg("-H");
> push_arg("--");
> #fi
Exactly because I wanted to avoid conditional compilation using
C preprocessor directive (#if).
^ permalink raw reply
* Re: [PATCH] builtin-grep: workaround for non GNU grep.
From: Linus Torvalds @ 2006-05-17 18:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bertrand Jacquin, git
In-Reply-To: <7vhd3ofsyv.fsf@assigned-by-dhcp.cox.net>
On Wed, 17 May 2006, Junio C Hamano wrote:
>
> "Bertrand Jacquin" <beber.mailing@gmail.com> writes:
> >
> > #if NO_H_OPTION_IN_GREP
> > push_arg("/dev/null");
> > #else
> > push_arg("-H");
> > push_arg("--");
> > #fi
>
> Exactly because I wanted to avoid conditional compilation using
> C preprocessor directive (#if).
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.
Linus
---
diff --git a/builtin-grep.c b/builtin-grep.c
index 66111de..d09ddf0 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -453,7 +453,6 @@ static int external_grep(struct grep_opt
len = nr = 0;
push_arg("grep");
- push_arg("-H");
if (opt->fixed)
push_arg("-F");
if (opt->linenum)
@@ -503,17 +502,35 @@ static int external_grep(struct grep_opt
push_arg("-e");
push_arg(p->pattern);
}
- push_arg("--");
+
+ /*
+ * To make sure we get the header printed out when we want it,
+ * add /dev/null to the paths to grep. This is unnecessary
+ * (and wrong) with "-l" or "-L", which always print out the
+ * name anyway.
+ *
+ * GNU grep has "-H", but this is portable.
+ */
+ if (!opt->name_only && !opt->unmatch_name_only)
+ push_arg("/dev/null");
hit = 0;
argc = nr;
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
+ const char *name;
if (ce_stage(ce) || !S_ISREG(ntohl(ce->ce_mode)))
continue;
if (!pathspec_matches(paths, ce->name))
continue;
- argv[argc++] = ce->name;
+ name = ce->name;
+ if (name[0] == '-') {
+ int len = ce_namelen(ce);
+ name = xmalloc(len + 3);
+ memcpy(name, "./", 2);
+ memcpy(name + 2, ce->name, len + 1);
+ }
+ argv[argc++] = name;
if (argc < MAXARGS)
continue;
hit += exec_grep(argc, argv);
^ permalink raw reply related
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Junio C Hamano @ 2006-05-17 18:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4f1ta$e07$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> In #git channel somebody asked about 'branches' and 'heads' and was referred
> to the glossary. I had taken then a look at appropriate glossary entries.
>
> 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/`.
>
> head::
> The top of a branch. It contains a ref to the corresponding
> commit object.
>
> head ref::
> A ref pointing to a head. Often, this is abbreviated to "head".
> Head refs are stored in `$GIT_DIR/refs/heads/`.
>
> revision::
> A particular state of files and directories which was stored in
> the object database. It is referenced by a commit object.
> ----
>
> It is just me or the glossary entry for `branch` is unnecessary
> complicated?
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.
As you point out it talks primarily about the mesh of all
possible histories (i.e commit DAG), without talking much about
what "branch" means and what role "branch" plays.
I cannot easily do a glossary entry to describe that specific
term, but maybe somebody else can split the following up and
paraphrase.
A project history is born by recording a particular
state ("revision") as a root commit, and built up by
recording subsequent states ("revisions") on top of the
previous commits. Thus, a group of commits connected by
their parent fields form a directed acyclic graph
("DAG"). Often this linkage between commits by their
parent fields is called "ancestry chain", and a commit
that has another commit in its "parent" field is called
a "child commit" of the latter.
There can be multiple root commits in the history of a
project. In other words, projects born independently
can later be glued together to become a single project.
The history is grown by building on top of previous
commits, and by the nature of distributed development,
many lineages of histories are grown simultaneously.
Each lineage is called a "branch".
A commit that can be reached by following the ancestry
chain from a commit that is "on the branch" is also "on
the branch", and a commit that cannot be reached by
following the ancestry chain from any commit that is "on
the branch" is not "on the branch". The commit that
bootstraps this recursive definition of "on the branch"
is called its "branch head", the "tip of the branch", or
the "top commit". In other words, it is topologically
the latest commit on the branch.
The above does not mean the top commit of a branch does
not have any child commit in the global project
histories. It just means that these children are not on
the branch; they may be on some other branches, forked
from it. To create a branch whose "on the branch"
commits are strict superset of "on the branch" commits
of another branch is called "forking" the branch.
^ permalink raw reply
* Re: [RFC 5/5] Support 'master@2 hours ago' syntax
From: Junio C Hamano @ 2006-05-17 18:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, git
In-Reply-To: <Pine.LNX.4.64.0605170745270.10823@g5.osdl.org>
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".
^ 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
* 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
* [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: 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
* 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: [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: 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] 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: [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] 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: "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: 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: 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: [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: "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: "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: 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: [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
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