* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-19 8:11 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, git
In-Reply-To: <20071019080755.GO14735@spearce.org>
On Fri, Oct 19, 2007 at 04:07:55AM -0400, Shawn O. Pearce wrote:
> Then you get linewrap on smaller terminals, and bigger ones don't
> line up the right side. *shrug*
Bigger ones will line up, just not on the far right side of the
terminal. I guess we ought to support smaller terminals, though).
> > > + show_update("* branch", note, "->", "FETCH_HEAD", NULL);
> > Hrm, btw, I can't seem to get this one to show (I was curious how ugly
> > the FETCH_HEAD would look).
> Yea, I can't easily see how to get this to generate.
I thought "git-fetch bare_url" would do it, since then we have no
remote fetchspec to look up, but it doesn't.
> > Also, I was unable to generate a test case that showed this one. Did
> > you?
> git fetch -v jc
Ah, thanks.
-Peff
^ permalink raw reply
* Re: [PATCH resend again] gitk: Do not pick up file names of "copy from" lines
From: Johannes Sixt @ 2007-10-19 8:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Paul Mackerras, git
In-Reply-To: <20071019073253.GM14735@spearce.org>
Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Would you mind putting this one into your queue, too? I haven't seen it
>> appear in Paul's repo.
>
> I think it is already in Paul's repo:
No, it's not. I checked both Paul's master and dev, and also your own
gitk branch. Would you mind cherry-picking from the tip of
git://repo.or.cz/git/mingw.git mob
Thanks,
-- Hannes
^ permalink raw reply
* Re: [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Johannes Sixt @ 2007-10-19 7:33 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <20071019065931.GB1463@srparish.net>
Scott R Parish schrieb:
> + check PATH for git_exec_path after other locations but before builtin
> + prepend MANPATH and PERL5LIB in addition to PATH
This says *what* the patch does, but not *why*. Care to explain?
And then your explanation should go into the commit message.
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Shawn O. Pearce @ 2007-10-19 8:07 UTC (permalink / raw)
To: Jeff King; +Cc: David Symonds, git
In-Reply-To: <20071019075725.GA29436@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Oct 19, 2007 at 03:39:39AM -0400, Shawn O. Pearce wrote:
>
> > What about this on top of Jeff's patch?
> >
> > $ git fetch jc
> > ...
> > ==> git://repo.or.cz/alt-git.git
> > * tag junio-gpg-pub ......................... (new)
> > * tag v1.5.0 .......................... (tag moved)
>
> Ugh. I strongly suspect that it would look ugly on anything bigger than
> about 80 columns, anyway. You are probably better off just not worrying
> about the terminal width, and always using an 80-ish column total. And
> then you don't have to worry about the ugly ioctl call.
Then you get linewrap on smaller terminals, and bigger ones don't
line up the right side. *shrug*
> > + show_update("* branch", note, "->", "FETCH_HEAD", NULL);
>
> Hrm, btw, I can't seem to get this one to show (I was curious how ugly
> the FETCH_HEAD would look).
Yea, I can't easily see how to get this to generate.
> > if (verbose)
> > - fprintf(stderr, " - %s == %s\n",
> > - note, pretty_ref);
> > + show_update("-", note, "==", pretty_ref, "unchanged");
> > return 0;
>
> Also, I was unable to generate a test case that showed this one. Did
> you?
git fetch -v jc
> > +static void determine_window_size(void)
> > +{
> > + struct winsize ws;
> > + if (!ioctl(2, TIOCGWINSZ, &ws))
> > + ws_cols = ws.ws_col;
> > +}
> > +
>
> Ugh. How portable is this?
No clue. It compiles fine here on Mac OS X and on Linux, but those
are both reasonably modern UNIX systems. Older systems like Solaris
8 or an ancient OpenBSD might have an issue. I suspect though that
this is a reasonably standard thing but its not in POSIX so uh,
probably a bad thing to do.
--
Shawn.
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-19 7:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Symonds, git
In-Reply-To: <20071019073938.GN14735@spearce.org>
On Fri, Oct 19, 2007 at 03:39:39AM -0400, Shawn O. Pearce wrote:
> What about this on top of Jeff's patch?
>
> $ git fetch jc
> ...
> ==> git://repo.or.cz/alt-git.git
> * tag junio-gpg-pub ......................... (new)
> * tag v1.5.0 .......................... (tag moved)
Honestly, I find it a bit ugly with the dots.
> $ git fetch me
> ...
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk -> spearce/gitk ............... (new)
> * branch maint -> spearce/maint
> * branch master -> spearce/master
> * branch next -> spearce/next
> * branch pu -> spearce/pu ......... (forced update)
> * branch todo -> spearce/todo ............... (new)
More so with the ragged right of the branch names. I think it would
probably look better to line up the columns, but that will eventually
look ugly when somebody tries to fetch sp/totally-annoying-branchname.
I also think having the dots for some lines and others looks awkward.
> The width of the terminal is computed to produce the ... padding.
> I used a very narrow terminal to produce the above so it doesn't
> linewrap badly in email. If we cannot get the terminal width then
> we just don't produce the padding.
Ugh. I strongly suspect that it would look ugly on anything bigger than
about 80 columns, anyway. You are probably better off just not worrying
about the terminal width, and always using an 80-ish column total. And
then you don't have to worry about the ugly ioctl call.
> We also only show the URL once now, and only if at least one ref
> was somehow changed. This way we avoid showing the URL on a no-op
> or twice when we are fetching tags too.
Much nicer, and I like the refactoring into a separate show_update
function (especially if somebody ends up adding color later).
> + show_update("* branch", note, "->", "FETCH_HEAD", NULL);
Hrm, btw, I can't seem to get this one to show (I was curious how ugly
the FETCH_HEAD would look).
> if (verbose)
> - fprintf(stderr, " - %s == %s\n",
> - note, pretty_ref);
> + show_update("-", note, "==", pretty_ref, "unchanged");
> return 0;
Also, I was unable to generate a test case that showed this one. Did
you?
> - msg = "storing tag";
> [...]
> + msg = "storing new tag";
Nice.
> + show_update("- branch", note, "->", pretty_ref, "non-fast forward, refused");
Line wrap?
> +static void determine_window_size(void)
> +{
> + struct winsize ws;
> + if (!ioctl(2, TIOCGWINSZ, &ws))
> + ws_cols = ws.ws_col;
> +}
> +
Ugh. How portable is this?
-Peff
^ permalink raw reply
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Jan Wielemaker @ 2007-10-19 7:43 UTC (permalink / raw)
To: pete
Cc: Johannes Schindelin, Marco Costalba, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <4717F8CF.9060103@bluelane.com>
On Friday 19 October 2007 02:22, Pete/Piet Delaney wrote:
> We are definitely not fine with CVS, the branch merging isn't
> comfortable. I'm just wondering about maintaining the existing
> CVS browsers and the build scripts if it's not a big deal. I'll
> try the git-cvsserver path. If anyone has any war stories to share
> on the path this would be an ideal time to share them.
As for web browsing the history, our project was quickly convinced
gitweb is a lot better than cvsweb. We are starting to get use to
basic git. One developer works on CVS. This is a bit handicapped,
but workable after a few patches to git-shell and git-cvsserver.
In another project I use git-cvsserver to do the Windows builds.
All development except for minor typos and compatibility things is
done on linux and cvs <-> git works just fine for that model.
--- Jan
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Shawn O. Pearce @ 2007-10-19 7:39 UTC (permalink / raw)
To: David Symonds, Jeff King; +Cc: git
In-Reply-To: <ee77f5c20710182339g30d025f0tfe74479d672ae36e@mail.gmail.com>
David Symonds <dsymonds@gmail.com> wrote:
> On 19/10/2007, Jeff King <peff@peff.net> wrote:
> > This makes the fetch output much more terse. It is likely to
> > be very controversial. Here's an example of the new output:
> >
> > Indexing objects: 100% (1061/1061), done.
> > Resolving deltas: 100% (638/638), done.
> > ==> git://repo.or.cz/git/spearce.git
> > * branch gitk -> origin/gitk
> > * branch maint -> origin/maint (fast forward)
> > * branch master -> origin/master (fast forward)
> > * branch next -> origin/next (fast forward)
> > - branch pu -> origin/pu (non-fast forward, refused)
> > * branch todo -> origin/todo (fast forward)
> > ==> git://repo.or.cz/git/spearce.git
> > * tag v1.5.3.2 -> v1.5.3.2
>
> What about making it even more terse so it's even easier to visually
> scan: (mainly thinking that fast-forwarding is so common it could be
> considered the "default")
What about this on top of Jeff's patch?
$ git fetch jc
...
==> git://repo.or.cz/alt-git.git
* tag junio-gpg-pub ......................... (new)
* tag v1.5.0 .......................... (tag moved)
$ git fetch me
...
==> git://repo.or.cz/git/spearce.git
* branch gitk -> spearce/gitk ............... (new)
* branch maint -> spearce/maint
* branch master -> spearce/master
* branch next -> spearce/next
* branch pu -> spearce/pu ......... (forced update)
* branch todo -> spearce/todo ............... (new)
The width of the terminal is computed to produce the ... padding.
I used a very narrow terminal to produce the above so it doesn't
linewrap badly in email. If we cannot get the terminal width then
we just don't produce the padding.
We also only show the URL once now, and only if at least one ref
was somehow changed. This way we avoid showing the URL on a no-op
or twice when we are fetching tags too.
--8>--
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 35fbfae..9d48f06 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -14,6 +14,7 @@ static const char fetch_usage[] = "git-fetch [-a | --append] [--upload-pack <upl
static int append, force, tags, no_tags, update_head_ok, verbose, quiet;
static char *default_rla = NULL;
static struct transport *transport;
+static int ws_cols, shown_url;
static void unlock_pack(void)
{
@@ -143,6 +144,50 @@ static int s_update_ref(const char *action,
return 0;
}
+static void show_update(const char *status,
+ const char *remote_name,
+ const char *op,
+ const char *local_name,
+ const char *reason)
+{
+ if (!shown_url) {
+ fprintf(stderr, "==> %s\n", transport->url);
+ shown_url = 1;
+ }
+
+ fputc(' ', stderr);
+ fputs(status, stderr);
+
+ fputc(' ', stderr);
+ fputs(remote_name, stderr);
+
+ if (op) {
+ fputc(' ', stderr);
+ fputs(op, stderr);
+ }
+
+ if (local_name) {
+ fputc(' ', stderr);
+ fputs(local_name, stderr);
+ }
+
+ if (reason) {
+ if (ws_cols) {
+ size_t n = strlen(status) + strlen(remote_name) + 2;
+ if (op)
+ n += 1 + strlen(op);
+ if (local_name)
+ n += 1 + strlen(local_name);
+ n = ws_cols - n - strlen(reason) - 4;
+ fputc(' ', stderr);
+ while (n--)
+ fputc('.', stderr);
+ }
+ fprintf(stderr, " (%s)", reason);
+ }
+ fputc('\n', stderr);
+}
+
static int update_local_ref(struct ref *ref,
const char *note,
int verbose)
@@ -164,14 +209,13 @@ static int update_local_ref(struct ref *ref,
if (!*ref->name) {
/* Not storing */
if (verbose)
- fprintf(stderr, " * branch %s -> FETCH_HEAD\n", note);
+ show_update("* branch", note, "->", "FETCH_HEAD", NULL);
return 0;
}
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
if (verbose)
- fprintf(stderr, " - %s == %s\n",
- note, pretty_ref);
+ show_update("-", note, "==", pretty_ref, "unchanged");
return 0;
}
@@ -183,16 +227,14 @@ static int update_local_ref(struct ref *ref,
* If this is the head, and it's not okay to update
* the head, and the old value of the head isn't empty...
*/
- fprintf(stderr,
- " - %s: Cannot fetch into the current branch.\n",
- pretty_ref);
+ show_update("-", pretty_ref, NULL, NULL,
+ "Cannot fetch into the current branch.");
return 1;
}
if (!is_null_sha1(ref->old_sha1) &&
!prefixcmp(ref->name, "refs/tags/")) {
- fprintf(stderr, " * tag %s -> %s\n",
- note, pretty_ref);
+ show_update("* tag", note, NULL, NULL, "tag moved");
return s_update_ref("updating tag", ref, 0);
}
@@ -200,17 +242,13 @@ static int update_local_ref(struct ref *ref,
updated = lookup_commit_reference(ref->new_sha1);
if (!current || !updated) {
const char *msg;
- const char *what;
if (!strncmp(ref->name, "refs/tags/", 10)) {
- msg = "storing tag";
- what = "tag";
- }
- else {
- msg = "storing head";
- what = "branch";
+ msg = "storing new tag";
+ show_update("* tag", note, NULL, NULL, "new");
+ } else {
+ msg = "storing new head";
+ show_update("* branch", note, "->", pretty_ref, "new");
}
- fprintf(stderr, " * %s %s -> %s\n",
- what, note, pretty_ref);
return s_update_ref(msg, ref, 0);
}
@@ -218,19 +256,14 @@ static int update_local_ref(struct ref *ref,
strcpy(newh, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));
if (in_merge_bases(current, &updated, 1)) {
- fprintf(stderr, " * branch %s -> %s (fast forward)\n",
- note, pretty_ref);
+ show_update("* branch", note, "->", pretty_ref, NULL);
return s_update_ref("fast forward", ref, 1);
}
if (!force && !ref->force) {
- fprintf(stderr,
- " - branch %s -> %s (non-fast forward, refused)\n",
- note, pretty_ref);
+ show_update("- branch", note, "->", pretty_ref, "non-fast forward, refused");
return 1;
}
- fprintf(stderr,
- " * branch %s -> %s (non-fast forward)\n",
- note, pretty_ref);
+ show_update("* branch", note, "->", pretty_ref, "forced update");
return s_update_ref("forced-update", ref, 1);
}
@@ -243,8 +276,6 @@ static void store_updated_refs(const char *url, struct ref *ref_map)
const char *what, *kind;
struct ref *rm;
- fprintf(stderr, "==> %s\n", url);
-
fp = fopen(git_path("FETCH_HEAD"), "a");
for (rm = ref_map; rm; rm = rm->next) {
struct ref *ref = NULL;
@@ -440,6 +471,13 @@ static void set_option(const char *name, const char *value)
name, transport->url);
}
+static void determine_window_size(void)
+{
+ struct winsize ws;
+ if (!ioctl(2, TIOCGWINSZ, &ws))
+ ws_cols = ws.ws_col;
+}
+
int cmd_fetch(int argc, const char **argv, const char *prefix)
{
struct remote *remote;
@@ -565,6 +603,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
ref_nr = j;
}
+ determine_window_size();
signal(SIGINT, unlock_pack_on_signal);
atexit(unlock_pack);
return do_fetch(transport, parse_ref_spec(ref_nr, refs), ref_nr);
diff --git a/git-compat-util.h b/git-compat-util.h
index f23d934..e823aca 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -44,6 +44,7 @@
#include <limits.h>
#include <sys/param.h>
#include <sys/types.h>
+#include <sys/ioctl.h>
#include <dirent.h>
#include <sys/time.h>
#include <time.h>
--
Shawn.
^ permalink raw reply related
* Re: [PATCH resend again] gitk: Do not pick up file names of "copy from" lines
From: Shawn O. Pearce @ 2007-10-19 7:32 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Paul Mackerras, git
In-Reply-To: <47185BCC.9010307@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Would you mind putting this one into your queue, too? I haven't seen it
> appear in Paul's repo.
I think it is already in Paul's repo:
Applying gitk: Do not pick up file names of "copy from" lines
error: patch failed: gitk:5216
error: gitk: patch does not apply
fatal: sha1 information is lacking or useless (gitk).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.
When you have resolved this problem run "git-am -3 --resolved".
If you would prefer to skip this patch, instead run "git-am -3 --skip".
> diff --git a/gitk b/gitk
> index b3ca704..1306382 100755
> --- a/gitk
> +++ b/gitk
> @@ -5216,8 +5216,7 @@ proc getblobdiffline {bdf ids} {
> set diffinhdr 0
>
> } elseif {$diffinhdr} {
> - if {![string compare -length 12 "rename from " $line] ||
> - ![string compare -length 10 "copy from " $line]} {
> + if {![string compare -length 12 "rename from " $line]} {
> set fname [string range $line [expr 6 + [string first " from
> " $line] ] end]
> if {[string index $fname 0] eq "\""} {
> set fname [lindex $fname 0]
--
Shawn.
^ permalink raw reply
* [PATCH] allow git to use the PATH for finding subcommands and help docs
From: Scott R Parish @ 2007-10-19 6:59 UTC (permalink / raw)
To: git
+ check PATH for git_exec_path after other locations but before builtin
+ prepend MANPATH and PERL5LIB in addition to PATH
Signed-off-by: Scott R Parish <srp@srparish.net>
---
exec_cmd.c | 50 ++++++++++++++++++++++++++++++++++++++-
git.c | 76 +++++++++++++++++++++++++++++++++++++++++------------------
2 files changed, 102 insertions(+), 24 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 9b74ed2..c6ecca9 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -13,19 +13,67 @@ void git_set_exec_path(const char *exec_path)
}
+/* Return the first path in PATH that git is found in or NULL if not found */
+char *git_path_from_env(void)
+{
+ const char *env_paths = getenv("PATH");
+ const char *git = "/git";
+ int git_len = strlen(git);
+ char *paths, *path, *colon, *git_path;
+ int path_len;
+ struct stat st;
+
+ if (!env_paths)
+ return NULL;
+
+ path_len = strlen(env_paths);
+ path = paths = xmalloc(path_len + 1);
+ memcpy(paths, env_paths, path_len + 1);
+
+ while ((char *)1 != path) {
+ if ((colon = strchr(path, ':')))
+ *colon = 0;
+
+ path_len = strlen(path);
+ git_path = xmalloc(path_len + git_len + 1);
+ memcpy(git_path, path, path_len);
+ memcpy(git_path + path_len, git, git_len + 1);
+
+ if (!stat(git_path, &st)) { /* found */
+ free(paths);
+ git_path[path_len] = 0;
+ return git_path;
+ }
+
+ free(git_path);
+ path = colon + 1;
+ }
+
+ free(paths);
+ return NULL;
+}
+
+
/* Returns the highest-priority, location to look for git programs. */
const char *git_exec_path(void)
{
- const char *env;
+ const char *env, *path;
if (current_exec_path)
return current_exec_path;
env = getenv(EXEC_PATH_ENVIRONMENT);
if (env && *env) {
+ current_exec_path = env;
return env;
}
+ if ((path = git_path_from_env())) {
+ current_exec_path = path;
+ return path;
+ }
+
+ current_exec_path = builtin_exec_path;
return builtin_exec_path;
}
diff --git a/git.c b/git.c
index 9eaca1d..252ee7c 100644
--- a/git.c
+++ b/git.c
@@ -6,26 +6,56 @@
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
-static void prepend_to_path(const char *dir, int len)
+static void prepend_to_env(const char *env, const char *basedir,
+ const char *subdir, const char *env_default)
{
- const char *old_path = getenv("PATH");
- char *path;
- int path_len = len;
-
- if (!old_path)
- old_path = "/usr/local/bin:/usr/bin:/bin";
-
- path_len = len + strlen(old_path) + 1;
-
- path = xmalloc(path_len + 1);
+ const char *old = getenv(env);
+ int basedir_len = strlen(basedir);
+ int subdir_len = strlen(subdir);
+ char *new;
+ int old_len;
+
+ if (!old)
+ old = env_default;
+
+ old_len = strlen(old);
+
+ new = xmalloc(basedir_len + subdir_len + old_len + 1);
+
+ memcpy(new, basedir, basedir_len);
+ memcpy(new + basedir_len, subdir, subdir_len);
+ memcpy(new + basedir_len + subdir_len, old, old_len + 1);
+
+ if (setenv(env, new, 1))
+ fprintf(stderr, "Setenv failed: %s\n", strerror(errno));
+
+ free(new);
+}
- memcpy(path, dir, len);
- path[len] = ':';
- memcpy(path + len + 1, old_path, path_len - len);
+static void prepend_to_envs(const char *dir, int len)
+{
+ char *slash;
+ char *basedir;
+
+ /* basedir is dir with "/bin" stripped off */
+ basedir = xmalloc(len + 1);
+ memcpy(basedir, dir, len + 1);
+
+ if ((slash = strrchr(basedir, '/'))) {
+ *slash = 0;
+ while (slash == basedir + --len) /* found trailing slash */
+ if ((slash = strrchr(basedir, '/')))
+ *slash = 0;
+ }
- setenv("PATH", path, 1);
+ prepend_to_env("PATH", basedir, "/bin:",
+ "/usr/local/bin:/usr/bin:/bin");
+ prepend_to_env("MANPATH", basedir, "/share/man:",
+ "/usr/local/share/man:/usr/share/man");
+ prepend_to_env("PERL5LIB", basedir, "/lib/perl5:",
+ "/usr/lib/perl5");
- free(path);
+ free(basedir);
}
static int handle_options(const char*** argv, int* argc, int* envchanged)
@@ -414,8 +444,7 @@ int main(int argc, const char **argv)
*/
if (slash) {
*slash++ = 0;
- if (*cmd == '/')
- exec_path = cmd;
+ exec_path = cmd;
cmd = slash;
}
@@ -453,14 +482,15 @@ int main(int argc, const char **argv)
/*
* We execute external git command via execv_git_cmd(),
* which looks at "--exec-path" option, GIT_EXEC_PATH
- * environment, and $(gitexecdir) in Makefile while built,
- * in this order. For scripted commands, we prepend
- * the value of the exec_path variable to the PATH.
+ * environment, PATH environment, and $(gitexecdir) in
+ * Makefile while built, in this order. For scripted
+ * commands, we prepend the value of the exec_path
+ * variable to the PATH.
*/
if (exec_path)
- prepend_to_path(exec_path, strlen(exec_path));
+ prepend_to_envs(exec_path, strlen(exec_path));
exec_path = git_exec_path();
- prepend_to_path(exec_path, strlen(exec_path));
+ prepend_to_envs(exec_path, strlen(exec_path));
while (1) {
/* See if it's an internal command */
--
1.5.3.4.206.g58ba4-dirty
^ permalink raw reply related
* [PATCH resend again] gitk: Do not pick up file names of "copy from" lines
From: Johannes Sixt @ 2007-10-19 7:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Paul Mackerras, git
In-Reply-To: <20071019052823.GI14735@spearce.org>
From: Johannes Sixt <johannes.sixt@telecom.at>
A file copy would be detected only if the original file was modified in the
same commit. This implies that there will be a patch listed under the
original file name, and we would expect that clicking the original file
name in the file list warps the patch window to that file's patch. (If the
original file was not modified, the copy would not be detected in the first
place, the copied file would be listed as "new file", and this whole matter
would not apply.)
However, if the name of the copy is sorted after the original file's patch,
then the logic introduced by commit d1cb298b0b (which picks up the link
information from the "copy from" line) would overwrite the link
information that is already present for the original file name, which was
parsed earlier. Hence, this patch reverts part of said commit.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Shawn O. Pearce schrieb:
> I'm carrying these in my pu branch but would like to move them up
> into master.
Would you mind putting this one into your queue, too? I haven't seen it
appear in Paul's repo.
-- Hannes
gitk | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index b3ca704..1306382 100755
--- a/gitk
+++ b/gitk
@@ -5216,8 +5216,7 @@ proc getblobdiffline {bdf ids} {
set diffinhdr 0
} elseif {$diffinhdr} {
- if {![string compare -length 12 "rename from " $line] ||
- ![string compare -length 10 "copy from " $line]} {
+ if {![string compare -length 12 "rename from " $line]} {
set fname [string range $line [expr 6 + [string first " from " $line] ] end]
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
--
1.5.3.722.gccbb1
^ permalink raw reply related
* Re: Qgit performance and maintain CVS environment with GIT repository
From: Andreas Ericsson @ 2007-10-19 7:14 UTC (permalink / raw)
To: pete
Cc: Marco Costalba, Johannes Schindelin, Robin Rosenberg,
piet.delaney, Linus Torvalds, VMiklos, free cycle, git,
piet.delaney, Piet Delaney
In-Reply-To: <4717EF40.6000509@bluelane.com>
Pete/Piet Delaney wrote:
> Johannes:
> I read somewhere in the past week that it was possible to maintain
> our existing CVS environment with git. I though it was a separate
> package to export git back to cvs but I just noticed a git-cvsserver
> and as a std part of git and was wondering about using that.
>
> We have a number of build machines with flamebox perl scripts pulling
> out CVS branches for builds. I was wondering what is the best way to
> use git and it's nicer pull/push model and merge facility and possibly
> maintain CVS exports for scripts doing builds if possible the cvsweb
> and bonsai (CVS Query Form) that a number of engineers are currently
> using. I started looking over out flamebox scripts with the intent
> up converting them over to git but I mentioned the git to cvs
> coexistence and we are wondering if that's a better route than
> upgrading the flamebox scripts. Having our existing cvsweb, bonsai,
> and gitweb along with the git utilities seems at least desirable.
> Any thoughts or suggestions?
>
If you do convert them to git, you can fairly easily do an automatic
bisect on build-errors, and the developer can (after some time) get
an email of what machines they broke the code on and what the bad
commit was.
Besides that, it's not a black-and-white scenario. If I were you I'd set
up git-cvsserver and make sure that works for all the scripts, and then
pick one or two auto-build things to convert to git. Preferrably on a
separate machine, so everything keeps working the same as always while
you're fiddling with the auto-build stuff.
Just my two cents.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-19 6:46 UTC (permalink / raw)
To: David Symonds; +Cc: git, Shawn O. Pearce
In-Reply-To: <ee77f5c20710182339g30d025f0tfe74479d672ae36e@mail.gmail.com>
On Fri, Oct 19, 2007 at 04:39:56PM +1000, David Symonds wrote:
> What about making it even more terse so it's even easier to visually
> scan: (mainly thinking that fast-forwarding is so common it could be
> considered the "default")
Reasonable. I think it would be easier to scan if the fields were
column-aligned, but that requires making a few passes, which would
change the current code quite a bit. Or we could just fake it and give
it 20 characters for a branch name, padded with spaces.
> > ==> git://repo.or.cz/git/spearce.git
> * gitk -> origin/gitk (new)
I miss the "branch" designator, personally. I do like the "new" to
differentiate from fast-forward.
> * maint -> origin/maint
> * master -> origin/master
> * next -> origin/next
> - pu -> origin/pu (refused)
I think this needs to explain why it was refused (non-fast forward,
refused). And you may still have:
* pu -> origin/pu (non-fast forward)
for forced updates.
> ==> git://repo.or.cz/git/spearce.git
> * tag v1.5.3.2
I am fine with that, as long as there aren't cases where we lose
information (i.e., where the local and remote tag names differ).
> Also, perhaps the trailing notes (fast forward, refused, etc.) should
> be significantly indented to the right to stand out even further from
> branch names that might be quite long.
Again, we could probably fake that by fixing the minimum column width of
the other fields.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] git-fetch: mega-terse fetch output
From: David Symonds @ 2007-10-19 6:39 UTC (permalink / raw)
To: Jeff King; +Cc: git, Shawn O. Pearce
In-Reply-To: <20071019062219.GA28499@coredump.intra.peff.net>
On 19/10/2007, Jeff King <peff@peff.net> wrote:
> This makes the fetch output much more terse. It is likely to
> be very controversial. Here's an example of the new output:
>
> Indexing objects: 100% (1061/1061), done.
> Resolving deltas: 100% (638/638), done.
> ==> git://repo.or.cz/git/spearce.git
> * branch gitk -> origin/gitk
> * branch maint -> origin/maint (fast forward)
> * branch master -> origin/master (fast forward)
> * branch next -> origin/next (fast forward)
> - branch pu -> origin/pu (non-fast forward, refused)
> * branch todo -> origin/todo (fast forward)
> ==> git://repo.or.cz/git/spearce.git
> * tag v1.5.3.2 -> v1.5.3.2
What about making it even more terse so it's even easier to visually
scan: (mainly thinking that fast-forwarding is so common it could be
considered the "default")
> ==> git://repo.or.cz/git/spearce.git
* gitk -> origin/gitk (new)
* maint -> origin/maint
* master -> origin/master
* next -> origin/next
- pu -> origin/pu (refused)
* todo -> origin/todo
==> git://repo.or.cz/git/spearce.git
* tag v1.5.3.2
Also, perhaps the trailing notes (fast forward, refused, etc.) should
be significantly indented to the right to stand out even further from
branch names that might be quite long.
Dave.
^ permalink raw reply
* [RFC/PATCH] git-fetch: mega-terse fetch output
From: Jeff King @ 2007-10-19 6:22 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
This makes the fetch output much more terse. It is likely to
be very controversial. Here's an example of the new output:
Indexing objects: 100% (1061/1061), done.
Resolving deltas: 100% (638/638), done.
==> git://repo.or.cz/git/spearce.git
* branch gitk -> origin/gitk
* branch maint -> origin/maint (fast forward)
* branch master -> origin/master (fast forward)
* branch next -> origin/next (fast forward)
- branch pu -> origin/pu (non-fast forward, refused)
* branch todo -> origin/todo (fast forward)
==> git://repo.or.cz/git/spearce.git
* tag v1.5.3.2 -> v1.5.3.2
Particular changes include:
- rather than each updated ref stating the remote url, the
url is printed once before any refs
- refs which did not update get a '-' rather than a '*'
- the order is changed from "$to: storing $from" to
"$from -> $to"
- we abbreviate the local refs (chopping refs/heads,
refs/tags, refs/remotes). This means we're losing
information, but hopefully it is obvious when storing
"origin/master" that it is in refs/remotes.
- fast forward information goes at the end
- cut out "Auto-following ..." text
What do people think? Some changes? All?
Other questions:
- Is the "==>" too ugly? It needs to be short (many urls
are almost 80 characters already), and it needs to stand
out from the "resolving deltas" line, so I think some
symbol is reasonable.
- Should we omit "(fast forward)" since it is the usual
case?
- Should refs/remotes/* keep the "remotes/" part?
- If you read the patch, there are a few cases covered
that I don't show in the example. Are they ugly or
better? I can't even figure out how to
get the '==' case to show up.
- Should tags always just say "tag $foo". Do we ever
actually map the tags when following?
- How annoying is the doubled '==> $url' line? It comes
from the fact that we fetch the tags separately.
Somebody mentioned colorization on irc. I think that is reasonable but
should definitely wait for another patch.
---
builtin-fetch.c | 73 +++++++++++++++++++++++++------------------------------
1 files changed, 33 insertions(+), 40 deletions(-)
It drops more lines than it adds, so it _must_ be good!
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 3442f3d..4440521 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -123,12 +123,6 @@ static struct ref *get_ref_map(struct transport *transport,
return ref_map;
}
-static void show_new(enum object_type type, unsigned char *sha1_new)
-{
- fprintf(stderr, " %s: %s\n", typename(type),
- find_unique_abbrev(sha1_new, DEFAULT_ABBREV));
-}
-
static int s_update_ref(const char *action,
struct ref *ref,
int check_old)
@@ -157,6 +151,11 @@ static int update_local_ref(struct ref *ref,
struct commit *current = NULL, *updated;
enum object_type type;
struct branch *current_branch = branch_get(NULL);
+ const char *pretty_ref = ref->name + (
+ !prefixcmp(ref->name, "refs/heads/") ? 11 :
+ !prefixcmp(ref->name, "refs/tags/") ? 10 :
+ !prefixcmp(ref->name, "refs/remotes/") ? 13 :
+ 0);
type = sha1_object_info(ref->new_sha1, NULL);
if (type < 0)
@@ -164,19 +163,15 @@ static int update_local_ref(struct ref *ref,
if (!*ref->name) {
/* Not storing */
- if (verbose) {
- fprintf(stderr, "* fetched %s\n", note);
- show_new(type, ref->new_sha1);
- }
+ if (verbose)
+ fprintf(stderr, " * branch %s -> FETCH_HEAD\n", note);
return 0;
}
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
- if (verbose) {
- fprintf(stderr, "* %s: same as %s\n",
- ref->name, note);
- show_new(type, ref->new_sha1);
- }
+ if (verbose)
+ fprintf(stderr, " - %s == %s\n",
+ note, pretty_ref);
return 0;
}
@@ -189,30 +184,33 @@ static int update_local_ref(struct ref *ref,
* the head, and the old value of the head isn't empty...
*/
fprintf(stderr,
- " * %s: Cannot fetch into the current branch.\n",
- ref->name);
+ " - %s: Cannot fetch into the current branch.\n",
+ pretty_ref);
return 1;
}
if (!is_null_sha1(ref->old_sha1) &&
!prefixcmp(ref->name, "refs/tags/")) {
- fprintf(stderr, "* %s: updating with %s\n",
- ref->name, note);
- show_new(type, ref->new_sha1);
+ fprintf(stderr, " * tag %s -> %s\n",
+ note, pretty_ref);
return s_update_ref("updating tag", ref, 0);
}
current = lookup_commit_reference(ref->old_sha1);
updated = lookup_commit_reference(ref->new_sha1);
if (!current || !updated) {
- char *msg;
- if (!strncmp(ref->name, "refs/tags/", 10))
+ const char *msg;
+ const char *what;
+ if (!strncmp(ref->name, "refs/tags/", 10)) {
msg = "storing tag";
- else
+ what = "tag";
+ }
+ else {
msg = "storing head";
- fprintf(stderr, "* %s: storing %s\n",
- ref->name, note);
- show_new(type, ref->new_sha1);
+ what = "branch";
+ }
+ fprintf(stderr, " * %s %s -> %s\n",
+ what, note, pretty_ref);
return s_update_ref(msg, ref, 0);
}
@@ -220,23 +218,19 @@ static int update_local_ref(struct ref *ref,
strcpy(newh, find_unique_abbrev(ref->new_sha1, DEFAULT_ABBREV));
if (in_merge_bases(current, &updated, 1)) {
- fprintf(stderr, "* %s: fast forward to %s\n",
- ref->name, note);
- fprintf(stderr, " old..new: %s..%s\n", oldh, newh);
+ fprintf(stderr, " * branch %s -> %s (fast forward)\n",
+ note, pretty_ref);
return s_update_ref("fast forward", ref, 1);
}
if (!force && !ref->force) {
fprintf(stderr,
- "* %s: not updating to non-fast forward %s\n",
- ref->name, note);
- fprintf(stderr,
- " old...new: %s...%s\n", oldh, newh);
+ " - branch %s -> %s (non-fast forward, refused)\n",
+ note, pretty_ref);
return 1;
}
fprintf(stderr,
- "* %s: forcing update to non-fast forward %s\n",
- ref->name, note);
- fprintf(stderr, " old...new: %s...%s\n", oldh, newh);
+ " * branch %s -> %s (non-fast forward)\n",
+ note, pretty_ref);
return s_update_ref("forced-update", ref, 1);
}
@@ -249,6 +243,8 @@ static void store_updated_refs(const char *url, struct ref *ref_map)
const char *what, *kind;
struct ref *rm;
+ fprintf(stderr, "==> %s\n", url);
+
fp = fopen(git_path("FETCH_HEAD"), "a");
for (rm = ref_map; rm; rm = rm->next) {
struct ref *ref = NULL;
@@ -308,7 +304,7 @@ static void store_updated_refs(const char *url, struct ref *ref_map)
note);
if (ref)
- update_local_ref(ref, note, verbose);
+ update_local_ref(ref, what, verbose);
}
fclose(fp);
}
@@ -368,9 +364,6 @@ static struct ref *find_non_local_tags(struct transport *transport,
if (!path_list_has_path(&existing_refs, ref_name) &&
!path_list_has_path(&new_refs, ref_name) &&
lookup_object(ref->old_sha1)) {
- fprintf(stderr, "Auto-following %s\n",
- ref_name);
-
path_list_insert(ref_name, &new_refs);
rm = alloc_ref(strlen(ref_name) + 1);
--
1.5.3.4.1252.g21baf-dirty
^ permalink raw reply related
* Re: [PATCH] Avoid invoking diff drivers during git-stash
From: Shawn O. Pearce @ 2007-10-19 6:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <471849D7.1020303@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> wrote:
> Shawn O. Pearce schrieb:
> > Johannes Sixt <j.sixt@viscovery.net> wrote:
> > > (1) Looking at git-stash.sh I see a few uses of 'git diff' in
> > > apply_stash(). Shouldn't these use one of git-diff-{tree,index,files)?
> > The
> > > reason is that porcelain 'git diff' invokes custom diff drivers (that
> > in my > case run a UI program), whereas the plumbing does not.
> > >
> > > Is there a particular reason to use porcelain 'git diff'?
> >
> > Does this fix the problem?
>
> It does!
>
> >@@ -110,7 +110,7 @@ show_stash () {
> >
> > w_commit=$(git rev-parse --verify "$s") &&
> > b_commit=$(git rev-parse --verify "$s^") &&
> >- git diff $flags $b_commit $w_commit
> >+ git diff-tree $flags $b_commit $w_commit
>
> However, this porcelain 'git diff' should actually remain because it's part
> of show_stash().
Heh. Damn. I was just starting to prepare my evening push and
this patch is in maint, which I just merged to master, and I just
rebased all of my pu topic branches over that. Junio's Meta toolkit
doesn't have an "unrebase" so I can go back and amend that damn
commit before pushing.
I'm feeling lazy and don't want to create an unRB right now.
I'll probably just throw another commit into maint to fix the
above hunk. Thanks for catching it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Avoid invoking diff drivers during git-stash
From: Johannes Sixt @ 2007-10-19 6:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20071019013350.GA14020@spearce.org>
Shawn,
thanks for the fast response with a patch.
Shawn O. Pearce schrieb:
> Johannes Sixt <j.sixt@viscovery.net> wrote:
> > (1) Looking at git-stash.sh I see a few uses of 'git diff' in
> > apply_stash(). Shouldn't these use one of git-diff-{tree,index,files)? The
> > reason is that porcelain 'git diff' invokes custom diff drivers (that in my
> > case run a UI program), whereas the plumbing does not.
> >
> > Is there a particular reason to use porcelain 'git diff'?
>
> Does this fix the problem?
It does!
> @@ -110,7 +110,7 @@ show_stash () {
>
> w_commit=$(git rev-parse --verify "$s") &&
> b_commit=$(git rev-parse --verify "$s^") &&
> - git diff $flags $b_commit $w_commit
> + git diff-tree $flags $b_commit $w_commit
However, this porcelain 'git diff' should actually remain because it's part
of show_stash().
-- Hannes
^ permalink raw reply
* Re: git on afs
From: Shawn O. Pearce @ 2007-10-19 6:06 UTC (permalink / raw)
To: Linus Torvalds, Todd T. Fries; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710181543380.26902@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, 18 Oct 2007, Todd T. Fries wrote:
> >
> > 2) git presumes that DTYPE(de) != DT_DIR .. means the dirent is not a dir
> > this is not true for afs
>
> That's a major bug, and has nothing to do with AFS. Oops.
>
> If you look just a bit lower, you'll see that just a few lines down, git
> handles DT_UNKNOWN correctly, and just does a lstat() on it as required. I
> guess that logic should be moved up, or alternatively the exclude logic
> should be moved down.
>
> Your patch looks ok, but at the same time, I don't think it's really the
> right thing to do, since it now does that lstat() twice.
What about this instead? It avoids the double lstat() of Todd's
original patch but seems like it would fix the issue here. Or did
I misunderstand the problem?
--8>--
From f290fc5f6ec5042b7c0393a300e4d3738b9090b8 Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Fri, 19 Oct 2007 02:03:55 -0400
Subject: [PATCH] Correctly scan directories when DTYPE(de) is unknown
We have been presuming that if DTYPE(de) != DT_DIR than the item we
obtained from readdir() isn't a directory. This is actually not
true, it could still be a directory, especially if the underlying
system we were compiled for doesn't have the d_type member of struct
dirent and we have enabled our compatability definition of DTYPE(de)
to always be DT_UNKNOWN.
If DTYPE(de) == DT_UNKNOWN we need to fall through and perform an
actual lstat() call to determine what the type of this item is so
we know how to proceed with our scanning.
Reported by Todd T. Fries while trying to use Git on AFS, which
apparently has DTYPE(de) != DT_DIR for directories.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
dir.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index eb6c3ab..d2597ff 100644
--- a/dir.c
+++ b/dir.c
@@ -487,9 +487,10 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
&& in_pathspec(fullname, baselen + len, simplify))
dir_add_ignored(dir, fullname, baselen + len);
if (exclude != dir->show_ignored) {
- if (!dir->show_ignored || DTYPE(de) != DT_DIR) {
+ if (!dir->show_ignored)
+ continue;
+ else if (DTYPE(de) != DT_DIR && DTYPE(de) != DT_UNKNOWN)
continue;
- }
}
switch (DTYPE(de)) {
--
1.5.3.4.1249.g895be
--
Shawn.
^ permalink raw reply related
* Re: git on afs
From: Shawn O. Pearce @ 2007-10-19 5:48 UTC (permalink / raw)
To: Todd T. Fries; +Cc: git, Brandon Casey
In-Reply-To: <20071018203106.GA13518@fries.net>
There's two different issues here so I'm going to split the thread
into two to simplify the discussion. Well, for me anyway. ;-)
"Todd T. Fries" <todd@fries.net> wrote:
> 1) git presumes that link() works fine across subdirs; in afs land,
> hardlinks do not succeed ever
...
> diff --git a/sha1_file.c b/sha1_file.c
> index 83a06a7..1b93322 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1961,7 +1961,7 @@ static int link_temp_to_file(const char *tmpfile, const char *filename)
> int ret;
> char *dir;
>
> - if (!link(tmpfile, filename))
> + if (!rename(tmpfile, filename))
> return 0;
>
> /*
> @@ -1980,7 +1980,7 @@ static int link_temp_to_file(const char *tmpfile, const char *filename)
> return -2;
> }
> *dir = '/';
> - if (!link(tmpfile, filename))
> + if (!rename(tmpfile, filename))
> return 0;
> ret = errno;
> }
These cases should already be handled lower, see l.1997-2012 of
sha1_file.c:
/*
* Coda hack - coda doesn't like cross-directory links,
* so we fall back to a rename, which will mean that it
* won't be able to check collisions, but that's not a
* big deal.
*
* The same holds for FAT formatted media.
*
* When this succeeds, we just return 0. We have nothing
* left to unlink.
*/
if (ret && ret != EEXIST) {
if (!rename(tmpfile, filename))
> Brandon Casey <casey@nrlssc.navy.mil> wrote:
> On Thu, 18 Oct 2007, Todd T. Fries wrote:
>
> > link() returns -1 errno 17 File exists on afs.
> >
> > To further muddy the waters, linking within the same dir is ok,
> > linking outside the same dir is not:
> >
> > todd@ispdesk/p6 ~/tmp=A661$ mkdir dir
> > todd@ispdesk/p6 ~/tmp=A662$ touch a
> > todd@ispdesk/p6 ~/tmp=A663$ ln a b
> > todd@ispdesk/p6 ~/tmp=A664$ ls -l a b
> > -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 a
> > -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 b
> > todd@ispdesk/p6 ~/tmp=A665$ ls -li a b
> > 2068032 -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 a
> > 2068032 -rw-r--r-- 2 4 wheel 0 Oct 18 17:09 b
> > todd@ispdesk/p6 ~/tmp=A666$ ln a dir/b
> > ln: dir/b: File exists
> > todd@ispdesk/p6 ~/tmp=A667$ echo $?
>
> That error is just bogus on afs. If it returned a sane
> error, things would just work.
>
> But, looks like afs only supports linking within the same
> directory: http://www.angelfire.com/hi/plutonic/afs-faq.html
So according to that error message from "ln" we really should have
fallen into that Coda hack I just mentioned. Did we instead get
a different errno here and not use that hack?
We probably could just use rename as you do above but then we would
want to remove the unlink(tmpfile) call on l.2013 in sha1_file.c.
Otherwise we're always incurring a syscall for no reason. I'm not
against a change here, I just want to make sure we make the right
change for AFS. :-)
--
Shawn.
^ permalink raw reply
* gitk patch collection pull request
From: Shawn O. Pearce @ 2007-10-19 5:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
The following changes since commit 719c2b9d926bf2be4879015e3620d27d32f007b6:
Paul Mackerras (1):
gitk: Fix bug causing undefined variable error when cherry-picking
are available in the git repository at:
git://repo.or.cz:/git/spearce.git gitk
Jonathan del Strother (2):
gitk: Added support for OS X mouse wheel
Fixing gitk indentation
Sam Vilain (1):
gitk: disable colours when calling git log
gitk | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
I'm carrying these in my pu branch but would like to move them up
into master. My gitk branch is actually forked off your own gitk
repository and doesn't contain the git.git history so you should
be able to do a direct pull.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Shawn O. Pearce @ 2007-10-19 5:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.0.9999.0710182340550.19446@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 18 Oct 2007, Jeff King wrote:
> > Also, why do we abbreviate "refs/heads/master" from the remote, but we
> > don't abbreviate refs/heads/origin for the local? Maybe something like:
> >
> > * local heads/origin -> remote heads/master (fast forward)
> >
> > or for separate remote
> >
> > * local remotes/origin/master -> remote heads/master (fast forward)
>
> That looks fine for a push. I'd say "remote foo -> local bar" for a
> fetch.
The fetch side is easy to change on top of the db/fetch-pack series
that is currently in next.
What's hard is the remote side. receive-pack on the remote side
doesn't have the local's refname but it prints its own message upon
a successful update.
--
Shawn.
^ permalink raw reply
* [PATCH] Stop displaying "Pack pack-$ID created." during git-gc
From: Shawn O. Pearce @ 2007-10-19 5:03 UTC (permalink / raw)
To: Nicolas Pitre, Jeff King; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0710182251110.19446@xanadu.home>
Discussion on the list tonight came to the conclusion that showing
the name of the packfile we just created during git-repack is not
a very useful message for any end-user. For the really technical
folk who need to have the name of the newest packfile they can use
something such as `ls -t .git/objects/pack | head -2` to find the
most recently created packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 18 Oct 2007, Jeff King wrote:
> > Can we get rid of total statistics (I think this is useful for some
> > power users, but perhaps there should be a verbosity level), the
> > name of the pack file (same deal), and the totally useless "Done."?
>
> Agreed for the pack name. Certainly no one cares.
This makes it so.
git-repack.sh | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index e72adc4..7220635 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -83,9 +83,6 @@ for name in $names ; do
fullbases="$fullbases pack-$name"
chmod a-w "$PACKTMP-$name.pack"
chmod a-w "$PACKTMP-$name.idx"
- if test "$quiet" != '-q'; then
- echo "Pack pack-$name created."
- fi
mkdir -p "$PACKDIR" || exit
for sfx in pack idx
--
1.5.3.4.1249.g895be
^ permalink raw reply related
* Re: [PATCH 2/2] Documentation/git-gc: improve description of --auto
From: Jeff King @ 2007-10-19 4:45 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Steven Grimm, Brian Gernhardt
In-Reply-To: <20071019023850.GD8298@coredump.intra.peff.net>
On Thu, Oct 18, 2007 at 10:38:50PM -0400, Jeff King wrote:
> I am hunting this down right now. asciidoc _does_ generate
> XML <literal>foo</literal> for `foo`, but it looks like docbook is
> throwing that away when converting to manpages. Hopefully there is an
> easy tweak...
Ugh. Looks like Junio came up with a solution to this in 524e5ffc
(although it was for literallayout sections, I think the same technique
could be applied). However, it had problems with docbook 1.69, and was
reverted in 63c21c49.
Julian Phillips added monospacing of listingblocks in 281a53bb, but that
technique is only applicable to asciidoc "blocks", which I think won't
work in this instance.
It really seems silly that docbook doesn't monospace <literal>s when
converting to manpages. Perhaps somebody who knows more about docbook
than I do can say more.
-Peff
^ permalink raw reply
* Re: Proposed git mv behavioral change
From: lmage11 @ 2007-10-19 4:41 UTC (permalink / raw)
To: git
Uh... wow. Ok, this thread has really taken off. Sorry, but I can't be
involved with it right now, I'll get back into it sometime tomorrow. Try
not to get too far ahead of me! :)
Also sorry about the crazy line breaking, I'm using a crappy webmail
client at the moment...
Thanks,
Ari
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Jeff King @ 2007-10-19 4:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Nicolas Pitre, Shawn O. Pearce, git
In-Reply-To: <alpine.LFD.0.999.0710182111030.26902@woody.linux-foundation.org>
On Thu, Oct 18, 2007 at 09:21:55PM -0700, Linus Torvalds wrote:
> I'd love it, but the way our current SHA1 parser works, I don't think it
> can really do it.
>
> Basically, we currently assume that a SHA1 expression always expands to a
> *single* SHA1.
Ah, right. I hadn't thought of that. While it would be a nice
convenience feature, it's probably not worth the deep internal hackery
that would be required.
-Peff
^ permalink raw reply
* Re: [PATCH] Change 'Deltifying objects' to 'Delta compressing objects'
From: Linus Torvalds @ 2007-10-19 4:21 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, Shawn O. Pearce, git
In-Reply-To: <20071019035647.GA18717@coredump.intra.peff.net>
On Thu, 18 Oct 2007, Jeff King wrote:
>
> As for a shortcut notation, what about allowing '..' notation inside a
> reflog. I.e., <ref>@{a..b} is the same as <ref>@{a}..<ref>@{b}? So you
> could perhaps do origin/master@{1..}?
I'd love it, but the way our current SHA1 parser works, I don't think it
can really do it.
Basically, we currently assume that a SHA1 expression always expands to a
*single* SHA1.
And then, on top of that SHA1 expression parser, we then have a totally
separate logic (which is *not* part of the SHA1 expression parser itself)
that handles the "a..b" and "a...b" cases.
In other words, all the magic "head@{xyz}" logic is all in sha1_name.c,
but that never handles any ranges at all.
And then the range handling is a separate thing in revision.c and
builtin-rev-parse.c.
So I think your syntax is wonderful, but it would require moving the
complex range handling into sha1_name.c, and would also require that file
to get a more complex interface (right now all the sha1_name.c routines
just take the "fill in this one SHA1 hash" approach, but ".." and "..."
means that you have multiple objects *and* you can mark one of them as
being "negated" etc..)
> I'm not sure if there are syntactic issues with parsing out the '..' (or
> '...') operator.
See above: I don't think we have syntax problems per se: it's just that
right now the "complex" parser (the one that knows about ^, ~, and @{x}
etc) simply cannot do anything but a single SHA1 due to internal interface
issues.
Linus
^ 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