* Re: [PATCH] built-in tar-tree and remote tar-tree
From: Junio C Hamano @ 2006-05-19 22:56 UTC (permalink / raw)
To: Sven Ekman; +Cc: git
In-Reply-To: <20060519214318.38240.qmail@web25910.mail.ukl.yahoo.com>
Sven Ekman <svekman@yahoo.se> writes:
> Thanks for your answer. I'm looking forward to try the
> remote tar-tree at the weekend.
A word of caution. This obviously needs the updated stuff on
both ends. The downloader needs to have updated tar-tree, and
the other end needs the new command upload-tar.
> Is there a simple way to retrieve a single object or a
> list of objects _without_ any of their parents?
The thing is, I do not think that is what you really want.
If you do not have the necessary parents, many of the benefit
you list as "why do I want kernel from git repo" would not work.
The next fetch will try to see where the common ancestry commit
is, in order to download only from that one, for example. For
that you would need a well formed repositories on both ends.
Obviously bisect and anything that deal with the traversal of
ancestry chain would break, and while you would say "I accept
that some things may not work", their failure mode do not even
consider that the user might start from such an incomplete
repositories to begin with, so one thing is that the user would
be very confused, and another thing is that I would not be
surprised if some operations further "corrupt" such an already
incomplete repository (fsck, prune and probably bisect when it
tries to rewind the bisection branch -- your branch head may
point at nowhere and the user might need to do manual update-ref
instead of "git checkout master" to recover from it), causing
further grief.
In other words, to support such partial/incomplete repositories
properly, you are talking about a major major surgery. I just
do not want to think about it right now.
On the other hand, the primary point of my patch is that the
result does _not_ pretend it is a proper git repository, so we
do not have to worry about all the above issues.
^ permalink raw reply
* [PATCH 1/2] Move pathspec matching from builtin-add.c into dir.c
From: Linus Torvalds @ 2006-05-19 23:07 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
I'll use it for builtin-rm.c too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/builtin-add.c b/builtin-add.c
index 2afb82d..02fe38b 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -13,86 +13,6 @@ #include "cache-tree.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_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;
-
- for (retval = 0; (match = *pathspec++) != NULL; seen++) {
- if (retval & *seen)
- continue;
- match += prefix;
- if (match_one(match, name, namelen)) {
- retval = 1;
- *seen = 1;
- }
- }
- return retval;
-}
-
static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
{
char *seen;
@@ -108,7 +28,7 @@ static void prune_directory(struct dir_s
i = dir->nr;
while (--i >= 0) {
struct dir_entry *entry = *src++;
- if (!match(pathspec, entry->name, entry->len, prefix, seen)) {
+ if (!match_pathspec(pathspec, entry->name, entry->len, prefix, seen)) {
free(entry);
continue;
}
diff --git a/dir.c b/dir.c
index d40b62e..d778ecd 100644
--- a/dir.c
+++ b/dir.c
@@ -11,6 +11,86 @@ #include <fnmatch.h>
#include "cache.h"
#include "dir.h"
+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_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];
+}
+
+int match_pathspec(const char **pathspec, const char *name, int namelen, int prefix, char *seen)
+{
+ int retval;
+ const char *match;
+
+ name += prefix;
+ namelen -= prefix;
+
+ for (retval = 0; (match = *pathspec++) != NULL; seen++) {
+ if (retval & *seen)
+ continue;
+ match += prefix;
+ if (match_one(match, name, namelen)) {
+ retval = 1;
+ *seen = 1;
+ }
+ }
+ return retval;
+}
+
void add_exclude(const char *string, const char *base,
int baselen, struct exclude_list *which)
{
diff --git a/dir.h b/dir.h
index 4f65f57..56a1b7f 100644
--- a/dir.h
+++ b/dir.h
@@ -39,6 +39,9 @@ struct dir_struct {
struct exclude_list exclude_list[3];
};
+extern int common_prefix(const char **pathspec);
+extern int match_pathspec(const char **pathspec, const char *name, int namelen, int prefix, char *seen);
+
extern int read_directory(struct dir_struct *, const char *path, const char *base, int baselen);
extern int excluded(struct dir_struct *, const char *);
extern void add_excludes_from_file(struct dir_struct *, const char *fname);
^ permalink raw reply related
* [PATCH 2/2] Add builtin "git rm" command
From: Linus Torvalds @ 2006-05-19 23:19 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605191607010.10823@g5.osdl.org>
This changes semantics very subtly, because it adds a new atomicity
guarantee.
In particular, if you "git rm" several files, it will now do all or
nothing. The old shell-script really looped over the removed files one by
one, and would basically randomly fail in the middle if "-f" was used and
one of the files didn't exist in the working directory.
This C builtin one will not re-write the index after each remove, but
instead remove all files at once. However, that means that if "-f" is used
(to also force removal of the file from the working directory), and some
files have already been removed from the workspace, it won't stop in the
middle in some half-way state like the old one did.
So what happens is that if the _first_ file fails to be removed with "-f",
we abort the whole "git rm". But once we've started removing, we don't
leave anything half done. If some of the other files don't exist, we'll
just ignore errors of removal from the working tree.
This is only an issue with "-f", of course.
I think the new behaviour is strictly an improvement, but perhaps more
importantly, it is _different_. As a special case, the semantics are
identical for the single-file case (which is the only one our test-suite
seems to test).
The other question is what to do with leading directories. The old "git
rm" script didn't do anything, which is somewhat inconsistent. This one
will actually clean up directories that have become empty as a result of
removing the last file, but maybe we want to have a flag to decide the
behaviour?
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/Makefile b/Makefile
index 5373986..06b31d8 100644
--- a/Makefile
+++ b/Makefile
@@ -120,7 +120,7 @@ SCRIPT_SH = \
git-merge-one-file.sh git-parse-remote.sh \
git-prune.sh git-pull.sh git-rebase.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
- git-resolve.sh git-revert.sh git-rm.sh git-sh-setup.sh \
+ git-resolve.sh git-revert.sh git-sh-setup.sh \
git-tag.sh git-verify-tag.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
@@ -170,7 +170,8 @@ PROGRAMS = \
BUILT_INS = git-log$X git-whatchanged$X git-show$X \
git-count-objects$X git-diff$X git-push$X \
- git-grep$X git-add$X git-rev-list$X git-check-ref-format$X
+ git-grep$X git-add$X git-rm$X git-rev-list$X \
+ git-check-ref-format$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -218,7 +219,8 @@ LIB_OBJS = \
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
- builtin-grep.o builtin-add.o builtin-rev-list.o builtin-check-ref-format.o
+ builtin-grep.o builtin-add.o builtin-rev-list.o builtin-check-ref-format.o \
+ builtin-rm.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
diff --git a/builtin-rm.c b/builtin-rm.c
new file mode 100644
index 0000000..67e0f79
--- /dev/null
+++ b/builtin-rm.c
@@ -0,0 +1,150 @@
+/*
+ * "git rm" builtin command
+ *
+ * Copyright (C) Linus Torvalds 2006
+ */
+#include "cache.h"
+#include "builtin.h"
+#include "dir.h"
+
+static const char builtin_rm_usage[] =
+"git-rm [-n] [-v] [-f] <filepattern>...";
+
+static struct {
+ int nr, alloc;
+ const char **name;
+} list;
+
+static void add_list(const char *name)
+{
+ if (list.nr >= list.alloc) {
+ list.alloc = alloc_nr(list.alloc);
+ list.name = xrealloc(list.name, list.alloc * sizeof(const char *));
+ }
+ list.name[list.nr++] = name;
+}
+
+static int remove_file(const char *name)
+{
+ int ret;
+ char *slash;
+
+ ret = unlink(name);
+ if (!ret && (slash = strrchr(name, '/'))) {
+ char *n = strdup(name);
+ do {
+ n[slash - name] = 0;
+ name = n;
+ } while (!rmdir(name) && (slash = strrchr(name, '/')));
+ }
+ return ret;
+}
+
+static struct cache_file cache_file;
+
+int cmd_rm(int argc, const char **argv, char **envp)
+{
+ int i, newfd;
+ int verbose = 0, show_only = 0, force = 0;
+ const char *prefix = setup_git_directory();
+ const char **pathspec;
+ char *seen;
+
+ git_config(git_default_config);
+
+ newfd = hold_index_file_for_update(&cache_file, get_index_file());
+ if (newfd < 0)
+ die("unable to create new index file");
+
+ if (read_cache() < 0)
+ die("index file corrupt");
+
+ for (i = 1 ; i < argc ; i++) {
+ const char *arg = argv[i];
+
+ if (*arg != '-')
+ break;
+ if (!strcmp(arg, "--")) {
+ i++;
+ break;
+ }
+ if (!strcmp(arg, "-n")) {
+ show_only = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-v")) {
+ verbose = 1;
+ continue;
+ }
+ if (!strcmp(arg, "-f")) {
+ force = 1;
+ continue;
+ }
+ die(builtin_rm_usage);
+ }
+ pathspec = get_pathspec(prefix, argv + i);
+
+ seen = NULL;
+ if (pathspec) {
+ for (i = 0; pathspec[i] ; i++)
+ /* nothing */;
+ seen = xmalloc(i);
+ memset(seen, 0, i);
+ }
+
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ if (!match_pathspec(pathspec, ce->name, ce_namelen(ce), 0, seen))
+ continue;
+ add_list(ce->name);
+ }
+
+ if (pathspec) {
+ const char *match;
+ for (i = 0; (match = pathspec[i]) != NULL ; i++) {
+ if (*match && !seen[i])
+ die("pathspec '%s' did not match any files", match);
+ }
+ }
+
+ /*
+ * First remove the names from the index: we won't commit
+ * the index unless all of them succeed
+ */
+ for (i = 0; i < list.nr; i++) {
+ const char *path = list.name[i];
+ printf("rm '%s'\n", path);
+
+ if (remove_file_from_cache(path))
+ die("git rm: unable to remove %s", path);
+ }
+
+ /*
+ * Then, if we used "-f", remove the filenames from the
+ * workspace. If we fail to remove the first one, we
+ * abort the "git rm" (but once we've successfully removed
+ * any file at all, we'll go ahead and commit to it all:
+ * by then we've already committed ourself and can't fail
+ * in the middle)
+ */
+ if (force) {
+ int removed = 0;
+ for (i = 0; i < list.nr; i++) {
+ const char *path = list.name[i];
+ if (!remove_file(path)) {
+ removed = 1;
+ continue;
+ }
+ if (!removed)
+ die("git rm: %s: %s", path, strerror(errno));
+ }
+ }
+
+ 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 78275ea..d150c7c 100644
--- a/builtin.h
+++ b/builtin.h
@@ -25,6 +25,7 @@ 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_rm(int argc, const char **argv, char **envp);
extern int cmd_add(int argc, const char **argv, char **envp);
extern int cmd_rev_list(int argc, const char **argv, char **envp);
extern int cmd_check_ref_format(int argc, const char **argv, char **envp);
diff --git a/git-rm.sh b/git-rm.sh
deleted file mode 100755
index fda4541..0000000
--- a/git-rm.sh
+++ /dev/null
@@ -1,70 +0,0 @@
-#!/bin/sh
-
-USAGE='[-f] [-n] [-v] [--] <file>...'
-SUBDIRECTORY_OK='Yes'
-. git-sh-setup
-
-remove_files=
-show_only=
-verbose=
-while : ; do
- case "$1" in
- -f)
- remove_files=true
- ;;
- -n)
- show_only=true
- ;;
- -v)
- verbose=--verbose
- ;;
- --)
- shift; break
- ;;
- -*)
- usage
- ;;
- *)
- break
- ;;
- esac
- shift
-done
-
-# This is typo-proofing. If some paths match and some do not, we want
-# to do nothing.
-case "$#" in
-0) ;;
-*)
- git-ls-files --error-unmatch -- "$@" >/dev/null || {
- echo >&2 "Maybe you misspelled it?"
- exit 1
- }
- ;;
-esac
-
-if test -f "$GIT_DIR/info/exclude"
-then
- git-ls-files -z \
- --exclude-from="$GIT_DIR/info/exclude" \
- --exclude-per-directory=.gitignore -- "$@"
-else
- git-ls-files -z \
- --exclude-per-directory=.gitignore -- "$@"
-fi |
-case "$show_only,$remove_files" in
-true,*)
- xargs -0 echo
- ;;
-*,true)
- xargs -0 sh -c "
- while [ \$# -gt 0 ]; do
- file=\$1; shift
- rm -- \"\$file\" && git-update-index --remove $verbose \"\$file\"
- done
- " inline
- ;;
-*)
- git-update-index --force-remove $verbose -z --stdin
- ;;
-esac
diff --git a/git.c b/git.c
index 7db5cc1..63aa311 100644
--- a/git.c
+++ b/git.c
@@ -51,6 +51,7 @@ static void handle_internal_command(int
{ "count-objects", cmd_count_objects },
{ "diff", cmd_diff },
{ "grep", cmd_grep },
+ { "rm", cmd_rm },
{ "add", cmd_add },
{ "rev-list", cmd_rev_list },
{ "check-ref-format", cmd_check_ref_format }
^ permalink raw reply related
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Greg KH @ 2006-05-19 23:58 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1ejyr38xx.fsf@ebiederm.dsl.xmission.com>
On Thu, May 18, 2006 at 04:48:26AM -0600, Eric W. Biederman wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > ebiederm@xmission.com (Eric W. Biederman) writes:
> >
> >> Junio C Hamano <junkio@cox.net> writes:
> >>
> >>> What's the expected workflow for you to work on a 1300 patch
> >>> series you get from Andrew in the next installment to deal with
> >>> 88 unattributed patches? Answer the question 88 times and make
> >>> sure you get the answers right every time? Or abort and
> >>> hand-edit them to help mailinfo to notice the correct
> >>> attribution and re-run?
> >>
> >> For the internal consumption case it isn't a big deal. I
> >> can specify --author with something bogus and it works.
> >
> > Yes.
> >
> >>> I know I am guilty of suggesting "going interactive", but I have
> >>> a feeling that having an optional file that maps patch-name to
> >>> author might be easier to work with. If the old patches are
> >>> recycled in the updated -mm set, you probably can reuse the
> >>> mapping for them, adding entries for newly introduced "unnamed"
> >>> patches as needed.
> >>
> >> Short of getting the script where it has a sane restart in the
> >> middle mode going interactive and asking questions makes a lot
> >> of sense. Especially with smaller trees.
> >
> > Yes perhaps on smaller trees, but that does not mean much. For
> > smaller trees and/or smaller patch series almost anything would
> > do.
>
> Yes, a smaller patch series, that is what I meant.
> Most quilt trees that I know about are in needed small.
$ quilt series | wc -l
207
And that is about "normal" for me. Sometimes it grows to about 500+
patches, but that only happens when there's a longer kernel release
cycle.
Another tree that I work on all the time is about 700+ patches, and yet
another 2000+. So you might re-evaluate your statement about "small"
quilt series :)
In looking at your script, it doesn't seem to be able to handle patches
in quilt that are in mbox format. Any thoughts to allow this to handle
the attribution properly?
Right now my development flow has me converting my quilt tree to one big
mbox file and then using 'git applymbox' to import it before asking
Linus to pull from it.
With your script I could skip at least one step, which would save me
some time...
thanks,
greg k-h
^ permalink raw reply
* Re: gitk highlight feature
From: Paul Mackerras @ 2006-05-20 0:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605030946260.4086@g5.osdl.org>
Linus Torvalds writes:
> But the real thing I found is that when I decided I wanted to highlight, I
> didn't actually want to highlight by "git-rev-list" at all. At least not
> most of the time.
I just pushed some changes to the "new" branch of the gitk.git
repository which change the way we do highlighting. There is now a
row of controls across the middle of the window, just below the row
containing the sha1 ID, "Find" button, etc., which controls the
highlighting. There are (currently) three ways to do highlighting: by
path, by view, and by author/committer. The author/committer matching
is case-insensitive (since I'm clearly an insensitive sort of guy :)
and matches any of the given strings anywhere in the author and
committer fields. The path and author/committer entry widgets take a
whitespace-delimited list of paths or names of interest, using shell
quoting rules, so you can put for example:
"david s. miller" benh
in there and you'll get commits from either davem or benh highlighted.
Do people think this is useful and on the right track interface-wise?
Paul.
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Daniel Barkalow @ 2006-05-20 0:28 UTC (permalink / raw)
To: Shawn Pearce; +Cc: David Kågedal, git
In-Reply-To: <20060519092136.GN22257@spearce.org>
On Fri, 19 May 2006, Shawn Pearce wrote:
> David K?gedal <davidk@lysator.liu.se> wrote:
> > I noticed that some of this seems to be changing slightly with the
> > introduction of branch logs, but I don't know how those are supposed
> > to be used yet.
>
> $ git commit -a
> $ git pull . some/other-tag
> # go to lunch
> $ git pull . some/bad-stuff
> $ git commit -a
> # go home
> $ test...
> # realize this is all bad
> $ git reset --hard "master@{yesterday}"
>
> :-)
>
> Its really only useful for recording the history of your ref's state,
> so you can 'undo' a bad merge that you might have done a few days
> ago but not realized was bad until now.
I still think it's useful for presenting a local view of how things have
changed. I.e.:
$ git pull . stuff
# Notice that the diffstat is exciting
# What did I just get?
$ git log master@{5 minutes ago}..master
This is about the only easy way to find out that the fast-forward you just
did included merging a line which contains a commit from several weeks
ago. (Because the "before" state isn't easily accessible for a
fast-forward, and the date of the old commit puts it way back in a
date-ordered log.)
I still think that a local changelog, which groups the additions due to
each logged value, would be a useful way of viewing the history in a way
that's meaningful to the particular user, and I think it would fit user
expectations of gitweb (i.e., when looking at Linus's tree's summary,
things would be ordered by when they hit Linus's tree, not when they were
originally committed, so between the listing of the merge at 23:48:54
today and the one 7 minutes before would be those things which weren't in
Linus's tree during those 7 minutes).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Junio C Hamano @ 2006-05-20 0:35 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605192006400.6713@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> $ git pull . stuff
> # Notice that the diffstat is exciting
> # What did I just get?
> $ git log master@{5 minutes ago}..master
>
> This is about the only easy way to find out that the fast-forward you just
> did included merging a line which contains a commit from several weeks
> ago. (Because the "before" state isn't easily accessible for a
> fast-forward, and the date of the old commit puts it way back in a
> date-ordered log.)
Did you forget about "git log ORIG_HEAD.."?
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Daniel Barkalow @ 2006-05-20 1:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7wxfs7v.fsf@assigned-by-dhcp.cox.net>
On Fri, 19 May 2006, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > $ git pull . stuff
> > # Notice that the diffstat is exciting
> > # What did I just get?
> > $ git log master@{5 minutes ago}..master
> >
> > This is about the only easy way to find out that the fast-forward you just
> > did included merging a line which contains a commit from several weeks
> > ago. (Because the "before" state isn't easily accessible for a
> > fast-forward, and the date of the old commit puts it way back in a
> > date-ordered log.)
>
> Did you forget about "git log ORIG_HEAD.."?
I guess I did forget that it sticks around. So you have to be doing
something somewhat more complicated, like fetching the latest versions of
multiple topic branches.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Linus Torvalds @ 2006-05-20 2:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605192116360.6713@iabervon.org>
On Fri, 19 May 2006, Daniel Barkalow wrote:
>
> I guess I did forget that it sticks around. So you have to be doing
> something somewhat more complicated, like fetching the latest versions of
> multiple topic branches.
I actually don't think it's at all unlikely that I'd start using this.
I tend to work in "spurts", where I do one thing for a while, and then
merge several pull requests in fairly short order. So while I use
ORIG_HEAD a lot, I can certainly imagine myself using the "since 2 hours
ago" format too.
I'm not entirely sure about the syntax, though. It ends up being pretty
command-line-unfriendly. The "gitk ORIG_HEAD.." thing is fairly easy to
type, but typing
gitk 'master@{2 hours ago}'..
on a Finnish keyboard (yeah, that's what I still use) is "interesting",
since all of '@', '{' and '}' are complex characters (AltGr + '2', AltGr +
'7' and AltGr + '0' respectively), and you have to remember the quoting.
Not that I see any obvious better syntax. Although allowing a shorthand
like "@2.hours.ago" for "current branch, at given date" might help a
bit, at least that wouldn't need quoting:
gitk @2.hours.ago..
Linus
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Eric W. Biederman @ 2006-05-20 2:42 UTC (permalink / raw)
To: Greg KH; +Cc: Junio C Hamano, git
In-Reply-To: <20060519235825.GA3289@kroah.com>
Greg KH <greg@kroah.com> writes:
> On Thu, May 18, 2006 at 04:48:26AM -0600, Eric W. Biederman wrote:
>>
>> Yes, a smaller patch series, that is what I meant.
>> Most quilt trees that I know about are small.
>
> $ quilt series | wc -l
> 207
>
> And that is about "normal" for me. Sometimes it grows to about 500+
> patches, but that only happens when there's a longer kernel release
> cycle.
>
> Another tree that I work on all the time is about 700+ patches, and yet
> another 2000+. So you might re-evaluate your statement about "small"
> quilt series :)
Sure. On fixing the upstream attribution issue you and Andi Kleen
look like people that are worth talking to, as there were several
patches in Andrews tree from both of you that were lacking attribution.
> In looking at your script, it doesn't seem to be able to handle patches
> in quilt that are in mbox format. Any thoughts to allow this to handle
> the attribution properly?
Mbox format but one patch per file, or multiple patches in one mbox file?
If it is one patch per file but with mbox headers, it is relatively
simple to teach git-mailinfo to parse things in a slightly more intelligent
way. I played with that but I didn't have any patches that helped with.
> Right now my development flow has me converting my quilt tree to one big
> mbox file and then using 'git applymbox' to import it before asking
> Linus to pull from it.
>
> With your script I could skip at least one step, which would save me
> some time...
Sure. That is the point of making it generic.
Eric
^ permalink raw reply
* Re: [RFC] qgit with tabs
From: Pavel Roskin @ 2006-05-20 9:42 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550605190954w4baab5fcj4f48a539bd120364@mail.gmail.com>
Quoting Marco Costalba <mcostalba@gmail.com>:
> > If I see the list of the recent patches, I see the descriptions and the
> > affected files. If I'm interested to see what changed in the file, it's
> > only natural for me to double-click the corresponding entry in the list.
> >
>
> Ok. patch pushed.
Working fine here. Thank you!
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] Document that "git add" only adds non-ignored files.
From: Santi @ 2006-05-20 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyj5ispx.fsf@assigned-by-dhcp.cox.net>
2006/5/19, Junio C Hamano <junkio@cox.net>:
> Thanks for the reminder, but I wonder if it is good to update
> the description of this command, and ls-files to use the
> same wording for consistency. We seem to use <pathspec> to mean
> "this is not necessarily a filename -- we glob", so that may be
> a good candidate (we do not have <pathspec> in glossary yet --
> we would need to add).
I changed it to match with the new usage string in the buildin-add.c.
>
> Please don't touch description for diff-* family -- right now,
> they say <path>, because they do not glob. If we decide that it
> is a good idea to glob (which I suspect we don't for the
> low-level stuff, but we probably do for the "git-diff" wrapper),
> we would update the code and the description at the same time.
>
OK.
Santi
^ permalink raw reply
* Re: [RFC] qgit with tabs
From: Paul Mackerras @ 2006-05-20 10:28 UTC (permalink / raw)
To: Marco Costalba; +Cc: Pavel Roskin, git
In-Reply-To: <e5bfff550605130431w417b8aacl2b17cf5655b46f31@mail.gmail.com>
Marco Costalba writes:
> FWIK gitk does not have a file content viewer.
It does now, actually.
Paul.
^ permalink raw reply
* Re: [RFC] qgit with tabs
From: Marco Costalba @ 2006-05-20 11:46 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Pavel Roskin, git
In-Reply-To: <17518.61262.957027.606886@cargo.ozlabs.ibm.com>
On 5/20/06, Paul Mackerras <paulus@samba.org> wrote:
> Marco Costalba writes:
>
> > FWIK gitk does not have a file content viewer.
>
> It does now, actually.
>
> Paul.
>
Yes, I've checked the current gitk version only _after_ email was sent.
Sorry for this.
Marco
^ permalink raw reply
* [BUG] "stg pull" on qgit tree shows problems, including git-http-fetch segfault
From: Yann Dirson @ 2006-05-20 12:58 UTC (permalink / raw)
To: GIT list
With "master" branch pointing to tags/qgit-1.2~17 and "origin" to
0a327c900530d9dd293cd252894a24913d4172c3, with no patch applied on
"master" stack, using stgit 0.9 and git 1.3.2:
$ stg pull
Pulling from "origin"...
Fetching refs/heads/master from http://digilander.libero.it/mcostalba/scm/qgit.git using http
got 5d0d2f1703976e04c6db1e55ea6a044981b9ed20
walk 5d0d2f1703976e04c6db1e55ea6a044981b9ed20
[...]
got 1f151284442358eee6da80394585491295c94380
error: File 24bd6f23c6d0161f7e775a0e6ab767725b6344ab (http://digilander.libero.it/mcostalba/scm/qgit.git/objects/f7/dc43059ca42dec2ea7214a33d1ff3c35e0aca5) corrupt
Getting pack list for http://digilander.libero.it/mcostalba/scm/qgit.git/
got 63dc5a19ec0ac37fec09e4023cd51a62eb3efa15
[...]
got 53563b4b6b32ba7ea184a4eeb555db76e276c8a6
error: XML error: syntax error
got 73c20d6d667ff3860718d5e1382e686531360082
[...]
got 0219d8723f9a4fa562d99eb0840741112a13466d
error: The requested URL returned error: 405
Getting alternates list for http://digilander.libero.it/mcostalba/scm/qgit.git/
got 33e3b252eb5dbe84116a858136b9b35fe43bf768
Also look at <meta http-equiv="Refresh" content="5;URL=http://digiland.libe
Also look at <BASE HREF="http://digiland.liber
/usr/bin/git-fetch: line 268: 3725 Segmentation fault git-http-fetch -v -a "$head" "$remote/"
stg pull: Failed "git-pull origin"
Running "stg pull" again gives only another "XML error", and finishes
the pull.
After unpacking all packs (mv .git/objects/pack and git-unpack-object
the contents) to be sure pruning does force everything to be
re-fetched, the following commands allow to reproduce the problem:
git-rev-parse tags/qgit-1.2~17 > .git/refs/heads/master
git-rev-parse tags/qgit-1.2~17 > .git/refs/bases/master
echo 0a327c900530d9dd293cd252894a24913d4172c3 >.git/refs/heads/origin
git-prune
cg-reset
stg pull
Output then reproducibly goes like the above, if one reruns the same
6 commands repeatedly, though the fetch order is not deterministic,
which may explain slight differences in the output.
Using current HEAD git instead of 1.3.2 does not improve things.
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [BUG] "stg pull" on qgit tree shows problems, including git-http-fetch segfault
From: Yann Dirson @ 2006-05-20 13:12 UTC (permalink / raw)
To: GIT list
In-Reply-To: <20060520125804.GG6535@nowhere.earth>
Let's be more precise - the command that repedetly fails is the
following. It is reponsible for both the "XML error" message and the
segfault.
git-http-fetch -v -a 79ac640b3129344d4e94573ddaea09ccda1b8e3b http://digilander.libero.it/mcostalba/scm/qgit.git/
Output goes like:
walk 79ac640b3129344d4e94573ddaea09ccda1b8e3b
walk d8bc846d8d2709fa240887da512e8b125a669006
walk 5d0d2f1703976e04c6db1e55ea6a044981b9ed20
error: File f7dc43059ca42dec2ea7214a33d1ff3c35e0aca5 (http://digilander.libero.it/mcostalba/scm/qgit.git/objects/f7/dc43059ca42dec2ea7214a33d1ff3c35e0aca5) corrupt
Getting pack list for http://digilander.libero.it/mcostalba/scm/qgit.git/
error: XML error: syntax error
Getting index for pack c47999034002469dddee39ba0069c1b1a84487a5
error: Unable to open local file .git/objects/pack/pack-c47999034002469dddee39ba0069c1b1a84487a5.idx for pack index
Getting alternates list for http://digilander.libero.it/mcostalba/scm/qgit.git/
Also look at <meta http-equiv="Refresh" content="5;URL=http://digiland.libe
Also look at <BASE HREF="http://digiland.liber
Segmentation fault (core dumped)
gdb backtrace is:
#0 0xb7caa5d0 in strncpy () from /lib/tls/libc.so.6
#1 0x0804c177 in process_alternates_response (callback_data=0xbfd428ec) at http-fetch.c:587
#2 0x0804a6c8 in process_curl_messages () at http.c:461
#3 0x0804a773 in step_active_slots () at http.c:379
#4 0x0804a7c7 in run_active_slot (slot=0x807f6a8) at http.c:400
#5 0x0804c565 in fetch_alternates (base=0xbfd45424 "http://digilander.libero.it/mcostalba/scm/qgit.git/") at http-fetch.c:668
#6 0x0804d46c in fetch (sha1=0x807f448 "÷ÜC\005\234¤-ì.§!J3Ñÿ<5ଥ\225¹\005\b") at http-fetch.c:1131
#7 0x0804a1ad in pull (target=0xbfd453fb "79ac640b3129344d4e94573ddaea09ccda1b8e3b") at fetch.c:168
#8 0x0804b590 in main (argc=5, argv=0xbfd43af4) at http-fetch.c:1269
The crash in process_alternates_response occurs on line:
587 strncpy(target + serverlen, data + i,
588 posn - i - 7);
(gdb) p target
$1 = 0x80800b8 "http://digilander.libero.it//-->\n</script>\n\n<script language=\"Javascript\" src=\"/x/js/nu05.js\"></script>\n\n<script>\n<!--\n\nfunction loaded() {\n\tcommon_boot();\n\t\n\t\t\n}\n\nfunction unloaded() {\n\tcommon_unload"...
(gdb) p target+serverlen
$2 = 0x80800d3 "//-->\n</script>\n\n<script language=\"Javascript\" src=\"/x/js/nu05.js\"></script>\n\n<script>\n<!--\n\nfunction loaded() {\n\tcommon_boot();\n\t\n\t\t\n}\n\nfunction unloaded() {\n\tcommon_unload();\n\t}\n\nfunction eoc() {\n\tc"...
(gdb) p data
$3 = 0x809c840 ""
(gdb) p i
$4 = 134739640
(gdb) p posn
$5 = 1304
Looks like something is going very wrong, like wrong assumptions about received HTML.
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* [PATCH] fmt-patch: Support --attach
From: Johannes Schindelin @ 2006-05-20 13:40 UTC (permalink / raw)
To: git, junkio
This patch touches a couple of files, because it adds options to print a
custom text just after the subject of a commit, and just after the
diffstat.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Maybe it would be a good idea to store the options to
pretty_print_commit() in a struct...
Also, I realized that it might be necessary to check the commit
message for a single "." in a line, since that has special meaning
in emails.
builtin-log.c | 13 ++++++++++---
builtin-rev-list.c | 2 +-
commit.c | 10 +++++++++-
commit.h | 2 +-
diff.c | 5 ++++-
diff.h | 1 +
log-tree.c | 35 +++++++++++++++++++++++++++++++----
revision.h | 1 +
show-branch.c | 2 +-
9 files changed, 59 insertions(+), 12 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 12a6d19..a30e974 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -183,7 +183,9 @@ int cmd_format_patch(int argc, const cha
argv[i + 1]);
output_directory = strdup(argv[i + 1]);
i++;
- } else
+ } else if (!strcmp(argv[i], "--attach"))
+ rev.mime_boundary = "050802040500080604070107";
+ else
argv[j++] = argv[i];
}
argc = j;
@@ -224,8 +226,13 @@ int cmd_format_patch(int argc, const cha
shown = log_tree_commit(&rev, commit);
free(commit->buffer);
commit->buffer = NULL;
- if (shown)
- printf("-- \n%s\n\n", git_version_string);
+ if (shown) {
+ if (rev.mime_boundary)
+ printf("\n--------------%s--\n\n\n",
+ rev.mime_boundary);
+ else
+ printf("-- \n%s\n\n", git_version_string);
+ }
if (!use_stdout)
fclose(stdout);
}
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 6a2e874..78b9c23 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -84,7 +84,7 @@ static void show_commit(struct commit *c
static char pretty_header[16384];
pretty_print_commit(revs.commit_format, commit, ~0,
pretty_header, sizeof(pretty_header),
- revs.abbrev, NULL);
+ revs.abbrev, NULL, NULL);
printf("%s%c", pretty_header, hdr_termination);
}
fflush(stdout);
diff --git a/commit.c b/commit.c
index 84558ba..0b163d4 100644
--- a/commit.c
+++ b/commit.c
@@ -498,7 +498,7 @@ static int add_merge_info(enum cmit_fmt
return offset;
}
-unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit, unsigned long len, char *buf, unsigned long space, int abbrev, const char *subject)
+unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *commit, unsigned long len, char *buf, unsigned long space, int abbrev, const char *subject, const char *after_subject)
{
int hdr = 1, body = 0;
unsigned long offset = 0;
@@ -591,6 +591,14 @@ unsigned long pretty_print_commit(enum c
buf[offset++] = '\n';
if (fmt == CMIT_FMT_ONELINE)
break;
+ if (after_subject) {
+ int slen = strlen(after_subject);
+ if (slen > space - offset - 1)
+ slen = space - offset - 1;
+ memcpy(buf + offset, after_subject, slen);
+ offset += slen;
+ after_subject = NULL;
+ }
subject = NULL;
}
while (offset && isspace(buf[offset-1]))
diff --git a/commit.h b/commit.h
index 8d7514c..c9de167 100644
--- a/commit.h
+++ b/commit.h
@@ -51,7 +51,7 @@ enum cmit_fmt {
};
extern enum cmit_fmt get_commit_format(const char *arg);
-extern unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *, unsigned long len, char *buf, unsigned long space, int abbrev, const char *subject);
+extern unsigned long pretty_print_commit(enum cmit_fmt fmt, const struct commit *, unsigned long len, char *buf, unsigned long space, int abbrev, const char *subject, const char *after_subject);
/** Removes the first commit from a list sorted by date, and adds all
* of its parents.
diff --git a/diff.c b/diff.c
index e16e0bf..3e2828b 100644
--- a/diff.c
+++ b/diff.c
@@ -1867,7 +1867,10 @@ void diff_flush(struct diff_options *opt
show_stats(diffstat);
free(diffstat);
diffstat = NULL;
- putchar(options->line_termination);
+ if (options->stat_sep)
+ fputs(options->stat_sep, stdout);
+ else
+ putchar(options->line_termination);
}
for (i = 0; i < q->nr; i++) {
struct diff_filepair *p = q->queue[i];
diff --git a/diff.h b/diff.h
index 7410607..83619eb 100644
--- a/diff.h
+++ b/diff.h
@@ -44,6 +44,7 @@ struct diff_options {
int rename_limit;
int setup;
int abbrev;
+ const char *stat_sep;
int nr_paths;
const char **paths;
diff --git a/log-tree.c b/log-tree.c
index 526d578..7f0f54b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -20,7 +20,7 @@ void show_log(struct rev_info *opt, stru
int abbrev_commit = opt->abbrev_commit ? opt->abbrev : 40;
const char *extra;
int len;
- char* subject = NULL;
+ char *subject = NULL, *after_subject = NULL;
opt->loginfo = NULL;
if (!opt->verbose_header) {
@@ -52,6 +52,7 @@ void show_log(struct rev_info *opt, stru
*/
if (opt->commit_format == CMIT_FMT_EMAIL) {
+ char *sha1 = sha1_to_hex(commit->object.sha1);
if (opt->total > 0) {
static char buffer[64];
snprintf(buffer, sizeof(buffer),
@@ -63,8 +64,34 @@ void show_log(struct rev_info *opt, stru
else
subject = "Subject: ";
- printf("From %s Thu Apr 7 15:13:13 2005\n",
- sha1_to_hex(commit->object.sha1));
+ printf("From %s Mon Sep 17 00:00:00 2001\n", sha1);
+ if (opt->mime_boundary) {
+ static char subject_buffer[1024];
+ static char buffer[1024];
+ snprintf(subject_buffer, sizeof(subject_buffer) - 1,
+ "MIME-Version: 1.0\n"
+ "Content-Type: multipart/mixed;\n"
+ " boundary=\"------------%s\"\n"
+ "\n"
+ "This is a multi-part message in MIME "
+ "format.\n"
+ "--------------%s\n"
+ "Content-Type: text/plain; "
+ "charset=UTF-8; format=fixed\n"
+ "Content-Transfer-Encoding: 8bit\n\n",
+ opt->mime_boundary, opt->mime_boundary);
+ after_subject = subject_buffer;
+
+ snprintf(buffer, sizeof(buffer) - 1,
+ "--------------%s\n"
+ "Content-Type: text/x-patch;\n"
+ " name=\"%s.diff\"\n"
+ "Content-Transfer-Encoding: 8bit\n"
+ "Content-Disposition: inline;\n"
+ " filename=\"%s.diff\"\n\n",
+ opt->mime_boundary, sha1, sha1);
+ opt->diffopt.stat_sep = buffer;
+ }
} else {
printf("%s%s",
opt->commit_format == CMIT_FMT_ONELINE ? "" : "commit ",
@@ -81,7 +108,7 @@ void show_log(struct rev_info *opt, stru
/*
* And then the pretty-printed message itself
*/
- len = pretty_print_commit(opt->commit_format, commit, ~0u, this_header, sizeof(this_header), abbrev, subject);
+ len = pretty_print_commit(opt->commit_format, commit, ~0u, this_header, sizeof(this_header), abbrev, subject, after_subject);
printf("%s%s%s", this_header, extra, sep);
}
diff --git a/revision.h b/revision.h
index 62759f7..bdbdd23 100644
--- a/revision.h
+++ b/revision.h
@@ -59,6 +59,7 @@ struct rev_info {
enum cmit_fmt commit_format;
struct log_info *loginfo;
int nr, total;
+ const char *mime_boundary;
/* special limits */
int max_count;
diff --git a/show-branch.c b/show-branch.c
index bbe26c2..684ffd1 100644
--- a/show-branch.c
+++ b/show-branch.c
@@ -259,7 +259,7 @@ static void show_one_commit(struct commi
struct commit_name *name = commit->object.util;
if (commit->object.parsed)
pretty_print_commit(CMIT_FMT_ONELINE, commit, ~0,
- pretty, sizeof(pretty), 0, NULL);
+ pretty, sizeof(pretty), 0, NULL, NULL);
else
strcpy(pretty, "(unavailable)");
if (!strncmp(pretty, "[PATCH] ", 8))
--
1.3.3.gea94-dirty
^ permalink raw reply related
* Re: [PATCH] fmt-patch: Support --attach
From: Jakub Narebski @ 2006-05-20 14:16 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0605201537290.17869@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> - printf("From %s Thu Apr 7 15:13:13 2005\n",
> - sha1_to_hex(commit->object.sha1));
> + printf("From %s Mon Sep 17 00:00:00 2001\n", sha1);
What's with the date?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [BUG] "stg pull" on qgit tree shows problems, including git-http-fetch segfault
From: Marco Costalba @ 2006-05-20 14:26 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20060520125804.GG6535@nowhere.earth>
On 5/20/06, Yann Dirson <ydirson@altern.org> wrote:
> With "master" branch pointing to tags/qgit-1.2~17 and "origin" to
> 0a327c900530d9dd293cd252894a24913d4172c3, with no patch applied on
> "master" stack, using stgit 0.9 and git 1.3.2:
>
Please reclone qgit repo and try again.
The public repository was broken by a my mistake few days ago. So you
need to reclone.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH] include header to define uint32_t, necessary on Mac OS X
From: Alex Riesen @ 2006-05-20 14:41 UTC (permalink / raw)
To: Ben Clifford; +Cc: Junio C Hamano, Linus Torvalds, Dennis Stosberg, git
In-Reply-To: <Pine.LNX.4.64.0605142057220.10680@mundungus.clifford.ac>
Ben Clifford, Sun, May 14, 2006 22:58:33 +0200:
> From: Ben Clifford <benc@hawaga.org.uk>
> Date: Sun, 14 May 2006 21:34:56 +0100
> Subject: [PATCH] include header to define uint32_t, necessary on Mac OS X
>
> ---
>
> pack-objects.c | 1 +
> sha1_file.c | 1 +
> 2 files changed, 2 insertions(+), 0 deletions(-)
>
> 2ee926ab9da67ef2a6ca28bb70954a33d65ba466
> diff --git a/pack-objects.c b/pack-objects.c
> index 1b9e7a1..5466b15 100644
> --- a/pack-objects.c
> +++ b/pack-objects.c
> @@ -10,6 +10,7 @@ #include "csum-file.h"
> #include "tree-walk.h"
> #include <sys/time.h>
> #include <signal.h>
> +#include <stdint.h>
>
BTW, Ben, how did you produce this patch? It has some unusual
indentations...
^ permalink raw reply
* Re: gitk highlight feature
From: Linus Torvalds @ 2006-05-20 16:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17518.24000.952384.563448@cargo.ozlabs.ibm.com>
On Sat, 20 May 2006, Paul Mackerras wrote:
>
> I just pushed some changes to the "new" branch of the gitk.git
> repository which change the way we do highlighting. There is now a
> row of controls across the middle of the window, just below the row
> containing the sha1 ID, "Find" button, etc., which controls the
> highlighting.
Ok, this is much nicer, I think this ends up being much closer to what I
really wanted, even if I didn't know quite how I wanted it.
I think the "Find" field should highlight things too. Right now there's no
way to get highlighting for somebody having signed-off on a patch, for
example, even though you can _search_ for it.
Also, right now it says "Author/committer", but it actually only triggers
on author. Which may be the right thing to do (it's certainly what I'd
normally want to see), but it doesn't match the description.
Linus
^ permalink raw reply
* Re: [PATCH] include header to define uint32_t, necessary on Mac OS X
From: Linus Torvalds @ 2006-05-20 16:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: Ben Clifford, Junio C Hamano, Dennis Stosberg, git
In-Reply-To: <20060520144111.GA5798@steel.home>
On Sat, 20 May 2006, Alex Riesen wrote:
> Ben Clifford, Sun, May 14, 2006 22:58:33 +0200:
> > #include <sys/time.h>
> > #include <signal.h>
> > +#include <stdint.h>
> >
>
> BTW, Ben, how did you produce this patch? It has some unusual
> indentations...
I don't think it's the patch producer. It's some mail-mangler. Some broken
mailers seem to add an extra space at the beginning of a line that already
begins with a space - I've seen this before.
The headers would seem to say "Pine":
Message-ID: <Pine.LNX.4.64.0605142057220.10680@mundungus.clifford.ac>
but that makes no sense, because mine certainly doesn't. But pine does
have a few config options to mangle whitespace, so who knows..
It could also be the actual send path, of course.
Linus
^ permalink raw reply
* Re: [PATCH] fmt-patch: Support --attach
From: Johannes Schindelin @ 2006-05-20 17:10 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e4n8b3$ari$1@sea.gmane.org>
Hi,
On Sat, 20 May 2006, Jakub Narebski wrote:
> Johannes Schindelin wrote:
>
> > - printf("From %s Thu Apr 7 15:13:13 2005\n",
> > - sha1_to_hex(commit->object.sha1));
> > + printf("From %s Mon Sep 17 00:00:00 2001\n", sha1);
>
> What's with the date?
Does not matter. This is not part of the mail header (the date is
displayed as a "Date:" line).
I only changed the "From " line (note the missing ":") to match the output
from git-format-patch.sh.
Ciao,
Dscho
^ permalink raw reply
* irc usage..
From: Linus Torvalds @ 2006-05-20 17:26 UTC (permalink / raw)
To: Git Mailing List
I hate irc.
I'm reading the irc logs, and seeing that people have problems, but (a) it
was while I was asleep and (b) irc use doesn't encourage people to
actually explain what the problems _are_, so I have no clue.
So now I know that "spyderous" has problems importing some 1GB gentoo CVS
archive, but that's pretty much it. Grr.
Are people afraid to post to git@vger.kernel.org, or what?
I saw that people tried to suggest posting to the git mailing list, but
can any of you who are active on irc be a bit more forceful? And perhaps
we don't make this mailing list address well enough known?
As far as I'm aware, the git mailing list isn't closed, so people should
be able to post here without even subscribing. I can well understand that
you might not want to subscribe and prefer to look ove rthe list through
some archive setup (the way I look at the irc logs), and maybe we should
just make the git mailing list address more obvious.
Right now, the "community" page at http://git.or.cz/community.html doesn't
even mention the git mailing list address directly, it just tells you how
you can subscribe and read the archives.
Can we perhaps fix that, and the people who are active on irc please also
make it clear to people that if they have some real problems that don't
get an immediate answer, the git mailing list ends up where a lot of
people can actually look more closely at it.. And tell them what the
address is.
Linus
^ permalink raw reply
* Re: [PATCH] fmt-patch: Support --attach
From: Junio C Hamano @ 2006-05-20 17:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0605201904320.31887@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I only changed the "From " line (note the missing ":") to match the output
> from git-format-patch.sh.
Not a big deal, but I was hoping you would keep the inception
date of git (April one) in the final version ;-). The September
date is totally a random date and does not have any
significance.
Anyway, with this change (and a lot of testing ;-) I think we
can replace the script with built-in. Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox