* Re: git-add + git-reset --hard = Arrrggh!
From: Linus Torvalds @ 2006-05-17 14:43 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060517094526.GA8563@spearce.org>
On Wed, 17 May 2006, Shawn Pearce wrote:
>
> Oh, and I totally agree with that discussion about GIT not clobbering
> files the user is working on which the user can't easily recover.
> I just wish recovery from the above stupidity didn't require going
> through .git/objects looking for the newest file. :-)
It doesn't.
Just do "git fsck-objects". It should have said
dangling blob <sha1>
and you can just do
git cat-file blob <sha1> > missing-file-name
and you're done.
That said, I think we should make everybody very aware of just how a
_dangerous_ operation "git reset --hard" is. It does delete your work. On
purpose. The fact that you can sometimes get it back doesn't change
anything.
(And I say "sometimes", because you'll obviously have lost all the
modifications that are only in your working tree - both to any added files
and to any old-time files. That's the _point_ of it, after all).
The default for "git reset" is to _not_ do any modifications in the
working tree. And there's a reason that's a default ;)
Linus
^ permalink raw reply
* Re: [RFC 5/5] Support 'master@2 hours ago' syntax
From: Linus Torvalds @ 2006-05-17 14:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn Pearce, git
In-Reply-To: <7vbqtwhpum.fsf@assigned-by-dhcp.cox.net>
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?
Linus
^ permalink raw reply
* Re: "git add $ignored_file" fail
From: Linus Torvalds @ 2006-05-17 14:49 UTC (permalink / raw)
To: Santi; +Cc: Alex Riesen, Johannes Schindelin, git
In-Reply-To: <8aa486160605170641p2ab8704o@mail.gmail.com>
On Wed, 17 May 2006, Santi wrote:
>
> In the other way, now I find the value of being able to say:
>
> $ git add t*
Exactly. The shell will expand the path, so the fact that the path exists
on the command line does not mean that "git add" should just trust it.
> and be sure that it does not add an ignored file. Unfortunately
> git-add cannot distinguish between both. So what I propose is to
> document it explicitly, something like:
Documenting this more clearly (and the workaround of forcing it with
"git-update-index --add" by hand) is certainly a good idea.
Linus
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Stefan Pfetzing @ 2006-05-17 15:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605170728520.10823@g5.osdl.org>
Hi Linus,
2006/5/17, Linus Torvalds <torvalds@osdl.org>:
>
> So let me just quote the thing you quoted but apparently didn't read:
[snip]
I did read that.
> There already _is_ such a directory. It's your "prefix=" directory plus
> "bin".
>
> So what you can do is make sure you compile with
>
> make prefix=/my/git/installation/prefix
>
> and then install the GNU tools in /my/git/installation/prefix/bin, and
> you're all set.
Ok, if I would do so, my prefix would be /usr/pkg, and the bindir would be
/usr/pkg/bin. So I would need to have an xargs and so on symlink in
/usr/pkg/bin.
But this is simply not acceptable, because it breaks other NetBSD
pkgsrc scripts.
Besides that, installing git to a different location is not an option
for me, because
I want to have git packaged by pkgsrc.
I suggest Junio's solution will work (gitexecdir) but I have to try
that later today.
> At most you might have to make some of the tests use "git xyzzy" instead
> of "git-xyzzy", and run "make install" before "make test".
>
> It wouldn't be wonderful, but hey, I've given alternatives (like using the
> GNU tools by default, or helping make git more portable in the first
> place). So it's a hack.
Yes I know, as far as I can, I'm willing to help with this.
bye
dreamind
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ permalink raw reply
* Re: [PATCH 1/2] Handle branch names with slashes
From: Catalin Marinas @ 2006-05-17 15:18 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, git
In-Reply-To: <20060516074504.GA27234@diana.vm.bytemark.co.uk>
On 16/05/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-05-15 23:48:04 -0700, Junio C Hamano wrote:
>
> > Karl Hasselström <kha@treskal.com> writes:
> >
> > > I had to change the patch@branch/top command-line syntax to
> > > patch@branch%top, in order to get sane parsing. The /top variant
> > > is still available for repositories that have no slashy branches;
> > > it is disabled as soon as there exists at least one subdirectory
> > > of refs/heads. Preferably, this compatibility hack can be killed
> > > some time in the future.
> >
> > I wonder if using double-slashes is an easier alternative to type
> > than '%', like "patch@branch//top". That way, you do not have to
> > forbid per-cent sign in branch names.
>
> Good argument. And // does look slightly better than %, too. But I'll
> wait a few days this time, or else someone will surely come along with
> an even better idea. :-)
I also thing // is a better solution than %.
There is another option, a bit more complicated, "patch@branch:top".
This would imply replacing : with .. in the current handling of the -r
option in diff/mail/export but it would make the commit or patch
ranges look more like GIT's arguments.
--
Catalin
^ permalink raw reply
* Re: [PATCH] builtin-grep: workaround for non GNU grep.
From: Bertrand Jacquin @ 2006-05-17 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vves5geng.fsf_-_@assigned-by-dhcp.cox.net>
On 5/17/06, Junio C Hamano <junkio@cox.net> wrote:
> +ifdef NO_H_OPTION_IN_GREP
> + NO_H_OPTION_IN_GREP=1
> +else
> + NO_H_OPTION_IN_GREP=0
> +endif
> + if (NO_H_OPTION_IN_GREP)
> + push_arg("/dev/null");
> + else {
> + push_arg("-H");
> + push_arg("--");
> + }
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
--
Beber
#e.fr@freenode
^ permalink raw reply
* Git interfaces, frontends and other tools list
From: Jakub Narebski @ 2006-05-17 15:49 UTC (permalink / raw)
To: git
Authors of Git related tools are encouraged to enter the information about
those tools on GitWiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
and, of course, correct and expand information there.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [ANNOUNCE] tig - text-mode interface for git
From: Jonas Fonseca @ 2006-05-17 15:53 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060517165305.07b682b2.tihirvon@gmail.com>
Timo Hirvonen <tihirvon@gmail.com> wrote Wed, May 17, 2006:
> Jonas Fonseca <fonseca@diku.dk> wrote:
>
> > Hello,
> >
> > I am pleased to announce tig, a simple git repository browser written
> > using ncurses. Basically, it just acts as a front-end for git-log and
> > git-show/git-diff. Additionally, you can also use it as a pager for git
> > commands.
> >
> > Currently, it just provides a minimum support for looking through
> > changes. I hope to slowly extend it to also be usable as a front-end for
> > git-blame and for tree browsing. Also, it doesn't do any fancy revision
> > graph rendering, but I want to at least give it a shot at some point. :)
>
> Thanks. This makes browsing repositories much easier. It would be
> great if the colors were customizable.
I am open to providing a better default color scheme, since my fondness
of green might be too dominating. For now you will have to edit the
colors defined under LINE_INFO, but sure. I think supporting something
similar to CG_COLORS will suffice.
--
Jonas Fonseca
^ permalink raw reply
* Re: Git 1.3.2 on Solaris
From: Linus Torvalds @ 2006-05-17 16:24 UTC (permalink / raw)
To: Stefan Pfetzing; +Cc: Git Mailing List
In-Reply-To: <f3d7535d0605170808l21d9f6d0gff1afaa10db17af9@mail.gmail.com>
On Wed, 17 May 2006, Stefan Pfetzing wrote:
>
> Ok, if I would do so, my prefix would be /usr/pkg, and the bindir would be
> /usr/pkg/bin. So I would need to have an xargs and so on symlink in
> /usr/pkg/bin.
> But this is simply not acceptable, because it breaks other NetBSD
> pkgsrc scripts.
DON'T USE /usr/pkg then.
Use /usr/pkg/git-core/share/ or something that is normally not on your
path.
And then install _just_ the "git" binary in /usr/pkg/bin.
That must be allowable by whatever solaris packaging rules: it's not like
other projects don't have their own internal library files.
Then you install the GNU symlinks under that same
/usr/pkg/git-core/share/bin
and you're all set. The only binary you can _see_ is "git", and when that
executes any scripts or other git binaries, it will set up the path to
include that magic hidden directory.
> Besides that, installing git to a different location is not an option
> for me, because I want to have git packaged by pkgsrc.
Now, I'm told pkgsrc is horrible, but it can't be so horrid as to not
allow private directories?
Linus
^ permalink raw reply
* 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
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