* Re: [PATCH] Support for configurable git command aliases (v2)
From: Martin Mares @ 2006-06-04 22:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20060604212050.GV10488@pasky.or.cz>
Hello, world!
> And I forgot to mention that it also adds the interactivity test
> requested by Janek - aliases are now interpreted only when stdout is a
> tty.
Does this really make sense? Why should an alias stop working
if I happen to redirect its output? Or am I missing something?
Have a nice fortnight
--
Martin `MJ' Mares <mj@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
God is real, unless declared integer.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Robin Rosenberg (list subscriber) @ 2006-06-04 22:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <200606042325.58884.robin.rosenberg.lists@dewire.com>
Just forget this post... @_@ (except the last line)
söndag 04 juni 2006 23:25 skrev Robin Rosenberg (list subscriber):
> söndag 04 juni 2006 22:00 skrev Linus Torvalds:
> > On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
> > > Other version control systems simply treat text and binary files
> > > differently. No smart(ass) logic doing the wrong thing.
> >
> > Treating text and binary file differently _is_ the "smart(ass) logic
> > doing the wrong thing".
> >
> > Git really shouldn't do that. The patch was meant to show how you really
> > don't need to - the internal objects would never be "binary vs text",
> > there would be a way to just basically map one onto another.
>
> Your patch assumes all files are text and the transformation doesn't
> corrupt the file, which isn't true. CR-LF combinations cannot be translated
> to LF and vice verse in all files, simply becuase what looks like CR LF
> isn't two characters, but something else. Looking for a nul byte and
> possibly some other magic byte would make you right more often, but not
> always.
>
> [...]
>
> > If you can't be civil, at least be quiet, ok?
> >
> > Linus
>
> A bad joke, I'm sorry. It wasn't ment to be offensive.
>
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Robin Rosenberg (list subscriber) @ 2006-06-04 21:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0606041256480.5498@g5.osdl.org>
söndag 04 juni 2006 22:00 skrev Linus Torvalds:
> On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
> > Other version control systems simply treat text and binary files
> > differently. No smart(ass) logic doing the wrong thing.
>
> Treating text and binary file differently _is_ the "smart(ass) logic doing
> the wrong thing".
>
> Git really shouldn't do that. The patch was meant to show how you really
> don't need to - the internal objects would never be "binary vs text",
> there would be a way to just basically map one onto another.
Your patch assumes all files are text and the transformation doesn't corrupt
the file, which isn't true. CR-LF combinations cannot be translated to LF and
vice verse in all files, simply becuase what looks like CR LF isn't two
characters, but something else. Looking for a nul byte and possibly some
other magic byte would make you right more often, but not always.
[...]
> If you can't be civil, at least be quiet, ok?
>
> Linus
A bad joke, I'm sorry. It wasn't ment to be offensive.
-- robin
^ permalink raw reply
* Re: [PATCH] Support for configurable git command aliases (v2)
From: Petr Baudis @ 2006-06-04 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060604211931.10117.82695.stgit@machine.or.cz>
Dear diary, on Sun, Jun 04, 2006 at 11:19:31PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> This patch adds support for configurable aliases for git commands -
> "alias.WHATEVER = which ever" will kick in when you do "git WHATEVER"
> and substitute WHATEVER with "which ever" (splitted to arguments at
> whitespaces).
>
> The second version does all the work in handle_aliases() which was
> inspired by Johannes Schindelin's patch.
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>
And I forgot to mention that it also adds the interactivity test
requested by Janek - aliases are now interpreted only when stdout is a
tty.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
A person is just about as big as the things that make them angry.
^ permalink raw reply
* [PATCH] Support for configurable git command aliases (v2)
From: Petr Baudis @ 2006-06-04 21:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch adds support for configurable aliases for git commands -
"alias.WHATEVER = which ever" will kick in when you do "git WHATEVER"
and substitute WHATEVER with "which ever" (splitted to arguments at
whitespaces).
The second version does all the work in handle_aliases() which was
inspired by Johannes Schindelin's patch.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/config.txt | 5 ++++
Documentation/git.txt | 3 ++
git.c | 60 ++++++++++++++++++++++++++++++++++++++++++++--
3 files changed, 65 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c861c6c..aaaa33d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -91,6 +91,11 @@ core.warnAmbiguousRefs::
If true, git will warn you if the ref name you passed it is ambiguous
and might match multiple refs in the .git/refs/ tree. True by default.
+alias.*::
+ Command aliases for the gitlink:git[1] command wrapper - e.g.
+ after defining "alias.last = cat-file commit HEAD", the invocation
+ "git last" is equivalent to "git cat-file commit HEAD".
+
apply.whitespace::
Tells `git-apply` how to handle whitespaces, in the same way
as the '--whitespace' option. See gitlink:git-apply[1].
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 24ca55d..e474bdf 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -21,6 +21,9 @@ link:everyday.html[Everyday Git] for a u
"man git-commandname" for documentation of each command. CVS users may
also want to read link:cvs-migration.html[CVS migration].
+The COMMAND is either a name of a Git command (see below) or an alias
+as defined in the configuration file (see gitlink:git-repo-config[1]).
+
OPTIONS
-------
--version::
diff --git a/git.c b/git.c
index bc463c9..50850fb 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
#include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
+#include "cache.h" /* setup_git_directory_gently() */
#include "builtin.h"
@@ -88,13 +89,65 @@ static void handle_internal_command(int
}
}
+static const char *cmd;
+static char *cmdalias;
+
+int git_alias_config(const char *var, const char *value)
+{
+ if (strncmp(var, "alias.", 6))
+ return 0;
+ var += /* strlen("alias.") */ 6;
+ if (!strcmp(var, cmd))
+ cmdalias = strdup(value);
+ return 0;
+}
+
+void handle_alias(int *argc, const char ***argv)
+{
+ /* XXX: We do a redundant git directory detection. */
+ int nongit = 0;
+ const char *subdir;
+
+ if (!isatty(1))
+ return;
+
+ subdir = setup_git_directory_gently(&nongit);
+ if (!nongit) {
+ git_config(git_alias_config);
+ if (cmdalias) {
+ /* More than the worst case: */
+ const char **argv2 = malloc((strlen(cmdalias) + *argc) * sizeof(char*));
+ int argc2 = 0, i = 1;
+
+ while (cmdalias && *cmdalias) {
+ argv2[argc2++] = strsep(&cmdalias, " \t");
+ if (cmdalias)
+ while (*cmdalias == ' ' || *cmdalias == '\t')
+ cmdalias++;
+ }
+ while (i < *argc) {
+ argv2[argc2++] = (*argv)[i++];
+ }
+ argv2[argc2] = NULL;
+ *argv = argv2;
+ *argc = argc2;
+ }
+ }
+
+ /* Go back so that the commands start with clean table */
+ if (subdir)
+ chdir(subdir);
+}
+
+
int main(int argc, const char **argv, char **envp)
{
- const char *cmd = argv[0];
- char *slash = strrchr(cmd, '/');
+ char *slash = strrchr(argv[0], '/');
char git_command[PATH_MAX + 1];
const char *exec_path = NULL;
+ cmd = argv[0];
+
/*
* Take the basename of argv[0] as the command
* name, and the dirname as the default exec_path
@@ -121,6 +174,7 @@ int main(int argc, const char **argv, ch
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
argv[0] = cmd;
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
die("cannot handle %s internally", cmd);
}
@@ -178,7 +232,7 @@ int main(int argc, const char **argv, ch
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
- /* See if it's an internal command */
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
/* .. then try the external ones */
^ permalink raw reply related
* Re: Gitk feature - show nearby tags
From: Junio C Hamano @ 2006-06-04 20:58 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Paul Mackerras, git
In-Reply-To: <20060603151240.GA4024@diku.dk>
Jonas Fonseca <fonseca@diku.dk> writes:
> The problem is of course to come up with some ascii-art which is both
> readable and dense. Below is my mockup of something not using line
> graphics, however using line graphics it might be possible to get
> something more unambiguos but also more "edgy".
I do not necessarily think an ascii-art is needed, nor an
appropriate way to present it to the curses user. When the user
wants to "view" a commit, you could show from which branch heads
and from which tags the commit is reachable, and perhaps which
tag is the latest among the ones reachable from that commit, as
part of the commit detail information you display on the lower
pane (log/diff view).
I may not be using tig in the way it was intended to, but I
often find it frustrating having to do the following:
- start tig, which shows list of one-line logs. Wonderful.
- browsing around by UP or DOWN and stop at one particular commit
I want to view closely. Press Enter and the screen split
into two and I see what I want to see. Again, wonderful.
- I want to see the neighbouring commits, but UP or DOWN
does not do what I naïvely expect. It scrolls the lower
pane. I say TAB to go up.
- Press UP or DOWN and I can move the highlight to
neighbouring commits. This is wonderful, but the lower
pane does not follow this -- it keeps showing the original
commit, and I have to say ENTER again.
It might make sense to make the log/diff view follow what
happens on the main view when both are on-screen.
^ permalink raw reply
* [PATCH] Makefile: make customization of installation locations easier.
From: Junio C Hamano @ 2006-06-04 20:38 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git, Junio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index a7ff69b..d20f823 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,8 @@
-PREFIX = $(HOME)
+prefix = $(HOME)
+bindir= $(prefix)/bin
+mandir = $(prefix)/man
+# DESTDIR=
+
LDLIBS = -lcurses
CFLAGS = -Wall -O2
DFLAGS = -g -DDEBUG -Werror
@@ -19,14 +23,15 @@ doc: $(DOCS)
install: all
for prog in $(PROGS); do \
- install $$prog $(PREFIX)/bin; \
+ install $$prog $(DESTDIR)$(bindir); \
done
install-doc: doc
+ mkdir -p $(DESTDIR)$(mandir)/man1 $(DESTDIR)$(mandir)/man5
for doc in $(DOCS); do \
case "$$doc" in \
- *.1) install $$doc $(PREFIX)/man/man1 ;; \
- *.5) install $$doc $(PREFIX)/man/man5 ;; \
+ *.1) install $$doc $(DESTDIR)$(mandir)/man1 ;; \
+ *.5) install $$doc $(DESTDIR)$(mandir)/man5 ;; \
esac \
done
--
1.3.3.gb266
^ permalink raw reply related
* Re: [PATCH] git: handle aliases defined in $GIT_DIR/config
From: Junio C Hamano @ 2006-06-04 20:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0606042047160.1598@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> For me, short cuts have to be easy to type, so they never
> include digits, and they are never case sensitive, so I do not
> need any fancy config stuff...
Fair enough, and the spirit is the same as what Pasky suggested
earlier, I think.
However, I am not sure about some parts of the code. I started
mucking with it myself, but realized it is far easier for me to
just let the original submitter, especially the capable one like
you, do a bit more work ;-).
> +#define MAX_ALIAS_ARGS 32
> +
> +static int handle_alias(int *argcp, const char **argv, char **envp)
> +{
> + int i, i2, j = 0;
Please name them src, dst and cnt.
> + char *new_argv[MAX_ALIAS_ARGS];
> +
> + alias_command = argv[0];
> + git_config(git_alias_config);
> + if (!alias_string)
> + return 0;
> +
> + /* split alias_string */
> + new_argv[j++] = alias_string;
> + for (i = i2 = 0; alias_string[i]; i++, i2++) {
> + if (isspace(alias_string[i])) {
> + alias_string[i2] = 0;
> + while (alias_string[++i] && isspace(alias_string[i]));
Please make empty loops easier to read by saying:
while (alias_string[++src] && isspace(alias_string[src]))
; /* skip */
> + new_argv[j++] = alias_string + i;
> + i2 = i;
Do we need to reset dst here? I suspect starting the next
parsed string immediately after the terminating NUL might be
cleaner.
> + if (j >= MAX_ALIAS_ARGS)
> + die("too many args in alias %s",
> + alias_command);
> + } else {
> + if (alias_string[i] == '\\')
> + i++;
Barf when the config line ends with a lone backslash, perhaps?
Since the configuration file parser uses backslash for quoting
itself, the user would need to have double backslashes, I
suspect. We might want to support single/double quote pairs in
this parser as well. I would further suggest separating this
"split single string into a pair of (argc, argv)" into a helper
function, so we can reuse it in other parts of the system later.
> + if (i != i2)
> + alias_string[i2] = alias_string[i];
Doing this unconditionally is probably more readable (i.e. lose
the if condition) -- this is not performance critical part of
the system.
> + }
> + }
> +
> + if (j < 1)
> + die("empty alias: %s", alias_command);
> +
> + /* insert after command name */
> + if (j > 1)
> + memmove(argv + j, argv + 1, (*argcp - 1) * sizeof(char*));
> + memcpy(argv, new_argv, j * sizeof(char*));
Who guarantees the original argv array main() received is big
enough to hold (j-1) additional pointers, I wonder? I think you
would need to allocate a new array, and muck with both argc and
argv of the caller by passing the pointers to them, not just
argc.
> @@ -121,6 +176,7 @@ int main(int argc, const char **argv, ch
> if (!strncmp(cmd, "git-", 4)) {
> cmd += 4;
> argv[0] = cmd;
> + handle_alias(&argc, argv, envp);
Hence probably "handle_alias(&argc, &argv, envp)" is needed here.
> handle_internal_command(argc, argv, envp);
> die("cannot handle %s internally", cmd);
> }
> @@ -178,6 +234,8 @@ int main(int argc, const char **argv, ch
> exec_path = git_exec_path();
> prepend_to_path(exec_path, strlen(exec_path));
>
> + handle_alias(&argc, argv, envp);
> +
... and here.
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-04 20:00 UTC (permalink / raw)
To: Robin Rosenberg (list subscriber); +Cc: Jakub Narebski, git
In-Reply-To: <200606042144.45385.robin.rosenberg.lists@dewire.com>
On Sun, 4 Jun 2006, Robin Rosenberg (list subscriber) wrote:
>
> Other version control systems simply treat text and binary files differently.
> No smart(ass) logic doing the wrong thing.
Treating text and binary file differently _is_ the "smart(ass) logic doing
the wrong thing".
Git really shouldn't do that. The patch was meant to show how you really
don't need to - the internal objects would never be "binary vs text",
there would be a way to just basically map one onto another.
> > I'm absolutely _not_ suggesting merging that patch as-is or even in any
> > form very close to it. It clearly needs a config file entry with filename
> > patterns etc at a minimum.
>
> Do people apply your patches right away, like it's some god-like commandments?
What's your problem here, exactly?
I was just trying to point out that my patch was an example, where
somebody who cares (not me) can use it as a starting point.
If you can't be civil, at least be quiet, ok?
Linus
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Robin Rosenberg (list subscriber) @ 2006-06-04 19:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.64.0606041050010.5498@g5.osdl.org>
söndag 04 juni 2006 19:55 skrev Linus Torvalds:
> On Sun, 4 Jun 2006, Jakub Narebski wrote:
> > > And that shouldn't actually be that hard to do. The most trivial
> > > approach is to have just a pre-trigger on commits, but let's face it,
> > > that would not be a good "full" solution. A better one is to just make
> > > the whole "git update-index" thing just have a "automatically ignore
> > > CR/LF" mode.
> >
> > Why wouldn't it be good solution?
>
> The pre-commit filter thing should work fine, and hey, maybe it's worth
> doing that way. I just worry/think that it will result in tons of noise
> when you do a "git diff" and "git update-index --refresh" on a file that
> has been changed, but then the change reverted.
>
> But I didn't really think it through very deeply, it was just an idle "I
> think the pre-commit hook will fall down when X happens that is a
> non-commit event" thought. I suspect this is one of those things where
> somebody actually working in that kind of environment will figure out what
> the problems are, and what the righ solution is.
>
> > BTW. wouldn't Mercurial encode/decode filters
> >
> > http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter
> >
> > be a better solution than modifying files by "git update-index",
> > with all problems it can cause (not detected binary files, text files
> > which have to be in CR/LF line ending,...).
>
> Please do realize that the patch I sent out was absolutely _not_ meant to
> be taken seriously. It was more a "somebody could try this in a windows
> environment, and if it works as an approach, we can try to do it right".
Other version control systems simply treat text and binary files differently.
No smart(ass) logic doing the wrong thing. A text file gets processed on
check-in AND checkout depending on it's type and the client setting.
Some heuristics may be applied when adding files. i.e look-up according to
magic cookies or looking for bytes that simply do not occur in text files
(e..g a nul byte). Those few systems that I know about treat the type as a
file (as opposed to a version specific) attribute. Some systems have lots of
file types, not just text and binary. Encoding is about the only thing that
would interest me, although not terribly important (except the file name),
but that may be off topic for this thread.
The hash-on-the whole-tree might be a reason for making the attribute
version-specific.
Mercurial's filters sounds like a good way to implement file types in a
generic way as long as git's excellent performance isn't hurt.
> I'm absolutely _not_ suggesting merging that patch as-is or even in any
> form very close to it. It clearly needs a config file entry with filename
> patterns etc at a minimum.
Do people apply your patches right away, like it's some god-like commandments?
-- robin
^ permalink raw reply
* Re: Clean up sha1 file writing
From: H. Peter Anvin @ 2006-06-04 19:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606041139310.5498@g5.osdl.org>
Linus Torvalds wrote:
>
> On Sun, 4 Jun 2006, Linus Torvalds wrote:
>> On Sun, 4 Jun 2006, H. Peter Anvin wrote:
>>> Or if you're getting a SIGWINCH in the middle of it.
>>>
>>> Any POSIX system will interrupt the transfer and return a short read on
>>> receiving a signal.
>> Only for interruptible fd's, though, which normally a real "file" won't
>> be.
>
> And _usually_ only if you actually have a SIGWINCH handler.
>
> Although older Linux kernels were broken in this regard. They'd interrupt
> a socket/pipe read or write even for a signal that ended up being ignored.
>
> So it's absolutely the case that having the loop is always the safer thing
> to do, and it's never the _wrong_ thing to do.
>
Right. I tend to think of it as implementation-defined the cases where
it happen to be safe, with the one exception of transactions which are
smaller than PIPE_BUF that are directed to a pipe.
-hpa
^ permalink raw reply
* [PATCH] git: handle aliases defined in $GIT_DIR/config
From: Johannes Schindelin @ 2006-06-04 18:47 UTC (permalink / raw)
To: git, junkio
If you have a config containing something like this:
[alias]
l = "log --stat -M ORIG_HEAD.."
you can call
git l
and it will do the same as
git log --stat -M ORIG_HEAD..
This also works with hard links.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
For me, short cuts have to be easy to type, so they never
include digits, and they are never case sensitive, so I do not
need any fancy config stuff...
git.c | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index bc463c9..846062f 100644
--- a/git.c
+++ b/git.c
@@ -10,6 +10,7 @@ #include <limits.h>
#include <stdarg.h>
#include "git-compat-util.h"
#include "exec_cmd.h"
+#include "cache.h"
#include "builtin.h"
@@ -32,6 +33,60 @@ static void prepend_to_path(const char *
setenv("PATH", path, 1);
}
+static const char *alias_command;
+static char *alias_string = NULL;
+
+static int git_alias_config(const char *var, const char *value)
+{
+ if (!strncmp(var, "alias.", 6) && !strcmp(var + 6, alias_command)) {
+ alias_string = strdup(value);
+ }
+ return 0;
+}
+
+#define MAX_ALIAS_ARGS 32
+
+static int handle_alias(int *argcp, const char **argv, char **envp)
+{
+ int i, i2, j = 0;
+ char *new_argv[MAX_ALIAS_ARGS];
+
+ alias_command = argv[0];
+ git_config(git_alias_config);
+ if (!alias_string)
+ return 0;
+
+ /* split alias_string */
+ new_argv[j++] = alias_string;
+ for (i = i2 = 0; alias_string[i]; i++, i2++) {
+ if (isspace(alias_string[i])) {
+ alias_string[i2] = 0;
+ while (alias_string[++i] && isspace(alias_string[i]));
+ new_argv[j++] = alias_string + i;
+ i2 = i;
+ if (j >= MAX_ALIAS_ARGS)
+ die("too many args in alias %s",
+ alias_command);
+ } else {
+ if (alias_string[i] == '\\')
+ i++;
+ if (i != i2)
+ alias_string[i2] = alias_string[i];
+ }
+ }
+
+ if (j < 1)
+ die("empty alias: %s", alias_command);
+
+ /* insert after command name */
+ if (j > 1)
+ memmove(argv + j, argv + 1, (*argcp - 1) * sizeof(char*));
+ memcpy(argv, new_argv, j * sizeof(char*));
+ *argcp += j - 1;
+
+ return 1;
+}
+
const char git_version_string[] = GIT_VERSION;
static void handle_internal_command(int argc, const char **argv, char **envp)
@@ -121,6 +176,7 @@ int main(int argc, const char **argv, ch
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
argv[0] = cmd;
+ handle_alias(&argc, argv, envp);
handle_internal_command(argc, argv, envp);
die("cannot handle %s internally", cmd);
}
@@ -178,6 +234,8 @@ int main(int argc, const char **argv, ch
exec_path = git_exec_path();
prepend_to_path(exec_path, strlen(exec_path));
+ handle_alias(&argc, argv, envp);
+
/* See if it's an internal command */
handle_internal_command(argc, argv, envp);
--
1.3.3.ga182-dirty
^ permalink raw reply related
* Re: Clean up sha1 file writing
From: Linus Torvalds @ 2006-06-04 18:40 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606041136180.5498@g5.osdl.org>
On Sun, 4 Jun 2006, Linus Torvalds wrote:
>
> On Sun, 4 Jun 2006, H. Peter Anvin wrote:
> >
> > Or if you're getting a SIGWINCH in the middle of it.
> >
> > Any POSIX system will interrupt the transfer and return a short read on
> > receiving a signal.
>
> Only for interruptible fd's, though, which normally a real "file" won't
> be.
And _usually_ only if you actually have a SIGWINCH handler.
Although older Linux kernels were broken in this regard. They'd interrupt
a socket/pipe read or write even for a signal that ended up being ignored.
So it's absolutely the case that having the loop is always the safer thing
to do, and it's never the _wrong_ thing to do.
Linus
^ permalink raw reply
* Re: Clean up sha1 file writing
From: Linus Torvalds @ 2006-06-04 18:39 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <4483259A.7090806@zytor.com>
On Sun, 4 Jun 2006, H. Peter Anvin wrote:
>
> Or if you're getting a SIGWINCH in the middle of it.
>
> Any POSIX system will interrupt the transfer and return a short read on
> receiving a signal.
Only for interruptible fd's, though, which normally a real "file" won't
be.
Linus
^ permalink raw reply
* Re: Clean up sha1 file writing
From: H. Peter Anvin @ 2006-06-04 18:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Lederhofer, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0606021416040.5498@g5.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 2 Jun 2006, H. Peter Anvin wrote:
>> Linus Torvalds wrote:
>>> Any POSIX-conformant OS/filesystem should always do a full write for a
>>> regular file, unless a serious error happens.
>>>
>> Actually, at least Linux won't, if the object is larger than 2 GB on a 64-bit
>> system :)
>
> Yeah, true.
>
> In the end, you should always have the loop. That way, you never have to
> worry about what kind of file descriptor it is, what kind of filesystem
> you're running on, and what the limits of ssize_t might be.
>
Or if you're getting a SIGWINCH in the middle of it.
Any POSIX system will interrupt the transfer and return a short read on
receiving a signal.
-hpa
^ permalink raw reply
* gitview: Add some useful keybindings.
From: Aneesh Kumar K.V @ 2006-06-04 18:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitview-Add-some-useful-keybindings.txt --]
[-- Type: text/plain, Size: 1873 bytes --]
gitview: Add some useful keybindings.
key binding for maximize, fullscreen, unfullscreen
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 15 +++++++++++++++
contrib/gitview/gitview.txt | 6 ++++++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index b836047..3b6bdce 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -450,6 +450,9 @@ class GitView:
self.accel_group = gtk.AccelGroup()
self.window.add_accel_group(self.accel_group)
self.accel_group.connect_group(0xffc2, 0, gtk.ACCEL_LOCKED, self.refresh);
+ self.accel_group.connect_group(0xffc1, 0, gtk.ACCEL_LOCKED, self.maximize);
+ self.accel_group.connect_group(0xffc8, 0, gtk.ACCEL_LOCKED, self.fullscreen);
+ self.accel_group.connect_group(0xffc9, 0, gtk.ACCEL_LOCKED, self.unfullscreen);
self.window.add(self.construct())
@@ -461,6 +464,18 @@ class GitView:
self.window.show()
return True
+ def maximize(self, widget, event=None, *arguments, **keywords):
+ self.window.maximize()
+ return True
+
+ def fullscreen(self, widget, event=None, *arguments, **keywords):
+ self.window.fullscreen()
+ return True
+
+ def unfullscreen(self, widget, event=None, *arguments, **keywords):
+ self.window.unfullscreen()
+ return True
+
def get_bt_sha1(self):
""" Update the bt_sha1 dictionary with the
respective sha1 details """
diff --git a/contrib/gitview/gitview.txt b/contrib/gitview/gitview.txt
index e3bc4f4..6924df2 100644
--- a/contrib/gitview/gitview.txt
+++ b/contrib/gitview/gitview.txt
@@ -26,8 +26,14 @@ OPTIONS
<args>
All the valid option for git-rev-list(1)
Key Bindings:
+ F4:
+ To maximize the window
F5:
To reread references.
+ F11:
+ Full screen
+ F12:
+ Leave full screen
EXAMPLES
------
--
1.3.3.g16a4-dirty
^ permalink raw reply related
* Re: [PATCH 0/27] Documentation: Spelling fixes
From: Nikolai Weibull @ 2006-06-04 17:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst.H.von.Brand, git
In-Reply-To: <7vk67xenfe.fsf@assigned-by-dhcp.cox.net>
On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> Most do not seem to be typoes, depending on where you learned
> the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.).
Where do you write "ie" instead of "i.e."?
In Swedish, there has been a trend to remove dots from abbreviated
expressions, but it seems people are returning to use dots.
Personally, I find that dots make things a lot clearer.
nikolai
^ permalink raw reply
* Re: Importing Mozilla CVS into git
From: Linus Torvalds @ 2006-06-04 17:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <e5u0o0$3rm$1@sea.gmane.org>
On Sun, 4 Jun 2006, Jakub Narebski wrote:
> >
> > And that shouldn't actually be that hard to do. The most trivial approach
> > is to have just a pre-trigger on commits, but let's face it, that would
> > not be a good "full" solution. A better one is to just make the whole
> > "git update-index" thing just have a "automatically ignore CR/LF" mode.
>
> Why wouldn't it be good solution?
The pre-commit filter thing should work fine, and hey, maybe it's worth
doing that way. I just worry/think that it will result in tons of noise
when you do a "git diff" and "git update-index --refresh" on a file that
has been changed, but then the change reverted.
But I didn't really think it through very deeply, it was just an idle "I
think the pre-commit hook will fall down when X happens that is a
non-commit event" thought. I suspect this is one of those things where
somebody actually working in that kind of environment will figure out what
the problems are, and what the righ solution is.
> BTW. wouldn't Mercurial encode/decode filters
>
> http://www.selenic.com/mercurial/wiki/index.cgi/EncodeDecodeFilter
>
> be a better solution than modifying files by "git update-index",
> with all problems it can cause (not detected binary files, text files
> which have to be in CR/LF line ending,...).
Please do realize that the patch I sent out was absolutely _not_ meant to
be taken seriously. It was more a "somebody could try this in a windows
environment, and if it works as an approach, we can try to do it right".
I'm absolutely _not_ suggesting merging that patch as-is or even in any
form very close to it. It clearly needs a config file entry with filename
patterns etc at a minimum.
Linus
^ permalink raw reply
* Re: git clone takes ages on a slow link
From: Linus Torvalds @ 2006-06-04 17:48 UTC (permalink / raw)
To: Anton Blanchard; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20060604010145.GC986@krispykreme>
On Sun, 4 Jun 2006, Anton Blanchard wrote:
>
> I think the ticker is over anxious.
It is indeed. It's _meant_ to only tick once a second or when the
percentage changes, but I think it forgot to clear the "once a second
happened" flag, so instead of updates the percentage output for every
file it checks out after the first second has passed.
So something like this should help... Can you verify?
Linus
---
diff --git a/builtin-read-tree.c b/builtin-read-tree.c
index 716f792..80c9320 100644
--- a/builtin-read-tree.c
+++ b/builtin-read-tree.c
@@ -336,6 +336,7 @@ static void check_updates(struct cache_e
fprintf(stderr, "%4u%% (%u/%u) done\r",
percent, cnt, total);
last_percent = percent;
+ progress_update = 0;
}
}
}
^ permalink raw reply related
* Re: Using subversion tools on Mozilla CVS
From: Jon Smirl @ 2006-06-04 15:48 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP08068F9BD23CF4FA8A1BDBAE970@CEZ.ICE>
On 6/4/06, Sean <seanlkml@sympatico.ca> wrote:
> On Sat, 3 Jun 2006 23:09:00 -0400
> "Jon Smirl" <jonsmirl@gmail.com> wrote:
>
> > I found this tool written in Python for importing CVS into Subversion.
> > It seems to be handling the Mozilla CVS repository with fewer problems
> > than parsecvs.
> >
> > http://cvs2svn.tigris.org/cvs2svn.html
> >
> > Since I'm not a native Python speaker, anyone else want to give a try
> > at changing it to support git?
>
> Hi Jon,
>
> If you haven't tried to import into git with a recent version of
> git-cvsimport, it would be worth a shot.
I tried it a couple of weeks ago and it barely made it into the
conversion. This repository is massive so if the tool doesn't scale
extremely well it quickly collapses.
I can't get it to run all the way, but I estimate that the git
parsecvs tool will need 11GB of RAM to import Mozilla CVS. Each time I
try to import the repository it runs 8-10 hours before failing. 11GB
process means you need a 64b machine.
> As for the tool you've referenced above, it does look pretty good.
> It makes multiple passes and saves to a temp file after each, letting
> you resume from that point and means it can use less memory overall.
This tool imported the Mozilla repository to SVN on the first try. It
needs about 10GB of temp disk space but it never took over 100MB of
RAM while running. It is much more advanced than anything git has. I'd
recommend reworking it to become git's main CVS import tool.
> It can produce a pretty straight forward looking dump file if you
> pass it the "--dump-only" option, rather than it pushing the results
> into svn; for instance:
>
> $ cvs2svn --dump-only --dumpfile DUMPFILE <cvs directory>
>
> It shouldn't be too hard to write a script that imports the revisions
> found in the resulting DUMPFILE into git.
I haven't learned enough about GIT yet to figure out how to import the
change sets.
The cvs2svn tool uses eight passes to convert CVS into something SVN can use.
In the last pass it has turned everything into change sets and it
pipes them to a SVN process that commits them. Mozilla has 205,787
change sets. It would be best if there was some way to pipe things
into git, I suspect the dumpfile for Mozilla would be huge.
This command imports Mozilla CVS, I had to add --use-cvs since the RCS
tools can't handle all the strange options used in Mozilla CVS files.
cvs2svn --use-cvs -s svntest \
--force-tag=THUNDERBIRD_0_7_RELEASE --force-tag=CVS \
--force-branch=JAVADEV_RTM_20001102 \
--force-branch=XPCOM_BRANCH_LANDING_981104 \
--force-branch=MOZILLA_1_3_BRANCH \
--force-branch=N3 \
--force-branch=SeaMonkey_M4_BRANCH \
--force-branch=NORMANDY_BRANCH \
--force-branch=FASTLOAD_20010529_BRANCH \
--force-branch=MozillaSourceClassic_19981026_BRANCH \
--force-branch=RDF_19981124_BRANCH \
--force-branch=OTIS_TEST_BRANCH \
--force-branch=Netscape61_PR1_Mini_BRANCH \
--force-branch=XPCOM20_BRANCH \
--force-branch=XPC_IDISP_20020417_BRANCH \
--force-branch=RDF_122898_BRANCH \
--force-branch=MOZILLA_1_4_BRANCH \
--force-branch=Netscape_20000922_BRANCH \
--force-branch=NETSCAPE_7_0_OEM_BRANCH \
--force-branch=RDF_19990407_BRANCH \
--force-branch=ALERT_SERVICE_BRANCH \
--force-branch=SeaMonkey_M12_BRANCH \
--force-branch=SpiderMonkey140_NES40Rtm_Branch \
mozilla/mozilla
It takes about 16 hours to convert MozCVS with this command on my
machine. Once you have done the full conversion you can rerun the last
pass without rerunning the others. That makes it easier to develop GIT
support since you don't have to do the entire conversion each time.
cvs2svn -p 8 --use-cvs -s svntest \
--force-tag=THUNDERBIRD_0_7_RELEASE --force-tag=CVS \
--force-branch=JAVADEV_RTM_20001102 \
--force-branch=XPCOM_BRANCH_LANDING_981104 \
--force-branch=MOZILLA_1_3_BRANCH \
--force-branch=N3 \
--force-branch=SeaMonkey_M4_BRANCH \
--force-branch=NORMANDY_BRANCH \
--force-branch=FASTLOAD_20010529_BRANCH \
--force-branch=MozillaSourceClassic_19981026_BRANCH \
--force-branch=RDF_19981124_BRANCH \
--force-branch=OTIS_TEST_BRANCH \
--force-branch=Netscape61_PR1_Mini_BRANCH \
--force-branch=XPCOM20_BRANCH \
--force-branch=XPC_IDISP_20020417_BRANCH \
--force-branch=RDF_122898_BRANCH \
--force-branch=MOZILLA_1_4_BRANCH \
--force-branch=Netscape_20000922_BRANCH \
--force-branch=NETSCAPE_7_0_OEM_BRANCH \
--force-branch=RDF_19990407_BRANCH \
--force-branch=ALERT_SERVICE_BRANCH \
--force-branch=SeaMonkey_M12_BRANCH \
--force-branch=SpiderMonkey140_NES40Rtm_Branch \
mozilla/mozilla
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Using subversion tools on Mozilla CVS
From: Sean @ 2006-06-04 15:20 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910606032009p252ff5fai7401401427ae3ec3@mail.gmail.com>
On Sat, 3 Jun 2006 23:09:00 -0400
"Jon Smirl" <jonsmirl@gmail.com> wrote:
> I found this tool written in Python for importing CVS into Subversion.
> It seems to be handling the Mozilla CVS repository with fewer problems
> than parsecvs.
>
> http://cvs2svn.tigris.org/cvs2svn.html
>
> Since I'm not a native Python speaker, anyone else want to give a try
> at changing it to support git?
Hi Jon,
If you haven't tried to import into git with a recent version of
git-cvsimport, it would be worth a shot.
As for the tool you've referenced above, it does look pretty good.
It makes multiple passes and saves to a temp file after each, letting
you resume from that point and means it can use less memory overall.
It can produce a pretty straight forward looking dump file if you
pass it the "--dump-only" option, rather than it pushing the results
into svn; for instance:
$ cvs2svn --dump-only --dumpfile DUMPFILE <cvs directory>
It shouldn't be too hard to write a script that imports the revisions
found in the resulting DUMPFILE into git.
Sean
^ permalink raw reply
* [PATCH] Preliminary branch-import support for git in tailor
From: Yann Dirson @ 2006-06-04 14:59 UTC (permalink / raw)
To: lele, tailor; +Cc: GIT list
[-- Attachment #1: Type: text/plain, Size: 2367 bytes --]
Here is my first try at working with branches with tailor.
This patch applies to current tailor from the darcs repo.
Attached: the patch, and the sample config I used to test it against a
public repo.
Possible improvements:
- the parent-repo parameter is probably generic enough to be useful
for other targets, but it is currently a git-target parameter only
- the change to tailor.py to avoid loosing the initial commit log on
the imported branch probably breaks all other targets because of the
previous issue
- autodetection of the branchpoint would be great, but that surely
deserves to be done in core tailor
- I'll have a try next to add support for pushing git branches to cvs
ones: that will give us a real 2-way sync between cvs and git
Generic problems noticed:
- not all tags from the cvs repo I tested against were imported
(problem specific to the cvs source ?)
- I could not make the cvsps source work to verify it fetches tags
better than the cvs one
- the "projects" parameter has to be specified explicitely to force
the ordering of branch imports - I would have expected the declaration
order to be used.
- it would probably be cleaner to have the *Repository classes in
repository.py moved into their own files: currently we have to modify
a generic file to add backend-specific options, that's not really
generic. What about loading the necessary class when it is found
mentionned in the config ?
Comparison with git-cvsimport
- tailor can give strange results in some cases, but I believe it is
more correct than git-cvsimport. An example is when the cvs branch
you import does not exist in some files for any reason (I had a branch
only for the src/ dir - corrected that now): in that case tailor
correctly shows deletions for those files in the branch initial
commit, whereas git-cvsimport only works on changes, and does not do
anything special (this may be cvsps doing magic behind his back).
- run against a local copy of the repository, tailor is orders of
magnitude slower than git-cvsimport (git-cvsimport returned instantly
on my repo), some profiling has to be done.
--
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/>
[-- Attachment #2: darcs.diff --]
[-- Type: text/plain, Size: 4521 bytes --]
diff -rN -u old-tailor/README new-tailor/README
--- old-tailor/README 2006-06-04 16:42:52.000000000 +0200
+++ new-tailor/README 2006-06-04 16:42:52.000000000 +0200
@@ -661,7 +661,21 @@
git
%%%
-.. no specific options
+parent-repo : string
+ Relative path to a git directory to use as a parent. This is useful
+ to import repository branches. If this parameter is empty, the
+ branch has no parent (default behaviour).
+
+parent-rev : string
+ A reference to the git commit which is the parent for the first
+ revision on the branch to be imported (ie, the branch point). It
+ can be a tag name or any syntax acceptable by git (eg. something
+ like "tag~2", if you want to correct the idea of where the
+ branchpoint is.
+
+ Since tailor generates mostly-stable SHA1 revisions, you can also
+ use a SHA1 as branchpoint. Just import your trunk first, find the
+ correct SHA1, and setup and import your branch.
hg
%%
diff -rN -u old-tailor/vcpx/git.py new-tailor/vcpx/git.py
--- old-tailor/vcpx/git.py 2006-06-04 16:42:52.000000000 +0200
+++ new-tailor/vcpx/git.py 2006-06-04 16:42:52.000000000 +0200
@@ -298,19 +298,39 @@
def _prepareTargetRepository(self):
"""
- Execute ``git init-db``.
+ Initialize .git through ``git init-db`` or ``git-clone``.
"""
+ from os import renames
from os.path import join, exists
if not exists(join(self.basedir, self.repository.METADIR)):
- init = ExternalCommand(cwd=self.basedir,
- command=self.repository.command("init-db"))
- init.execute()
-
- if init.exit_status:
- raise TargetInitializationFailure(
- "%s returned status %s" % (str(init), init.exit_status))
+ if self.repository.PARENT_REPO == '':
+ cmd = self.repository.command("init-db")
+ init = ExternalCommand(cwd=self.basedir, command=cmd)
+ init.execute()
+ if init.exit_status:
+ raise TargetInitializationFailure(
+ "%s returned status %s" % (str(init), init.exit_status))
+ else:
+ cmd = self.repository.command("clone", "--shared", "-n",
+ self.repository.PARENT_REPO, 'tmp')
+ clone = ExternalCommand(cwd=self.basedir, command=cmd)
+ clone.execute()
+ if clone.exit_status:
+ raise TargetInitializationFailure(
+ "%s returned status %s" % (str(clone), clone.exit_status))
+
+ renames('%s/%s/tmp/.git' % (self.repository.rootdir, self.repository.subdir),
+ '%s/%s/.git' % (self.repository.rootdir, self.repository.subdir))
+
+ cmd = self.repository.command("reset", "--soft", self.repository.PARENT_REV)
+ reset = ExternalCommand(cwd=self.basedir, command=cmd)
+ reset.execute()
+ if reset.exit_status:
+ raise TargetInitializationFailure(
+ "%s returned status %s" % (str(reset), reset.exit_status))
+
def _prepareWorkingDirectory(self, source_repo):
"""
diff -rN -u old-tailor/vcpx/repository.py new-tailor/vcpx/repository.py
--- old-tailor/vcpx/repository.py 2006-06-04 16:42:52.000000000 +0200
+++ new-tailor/vcpx/repository.py 2006-06-04 16:42:52.000000000 +0200
@@ -287,6 +287,8 @@
def _load(self, project):
Repository._load(self, project)
self.EXECUTABLE = project.config.get(self.name, 'git-command', 'git')
+ self.PARENT_REPO = project.config.get(self.name, 'parent-repo', '')
+ self.PARENT_REV = project.config.get(self.name, 'parent-rev', 'HEAD')
class HgRepository(Repository):
diff -rN -u old-tailor/vcpx/tailor.py new-tailor/vcpx/tailor.py
--- old-tailor/vcpx/tailor.py 2006-06-04 16:42:52.000000000 +0200
+++ new-tailor/vcpx/tailor.py 2006-06-04 16:42:52.000000000 +0200
@@ -74,7 +74,9 @@
raise
try:
- dwd.importFirstRevision(self.source, actual, 'INITIAL'==revision)
+ dwd.importFirstRevision(self.source, actual,
+ self.target.PARENT_REPO != '' or
+ 'INITIAL'==revision)
except:
self.log.critical('Could not import checked out tree in "%s"!',
self.rootdir)
[-- Attachment #3: bigdiesel.tailor --]
[-- Type: text/plain, Size: 895 bytes --]
[DEFAULT]
#verbose=yes
patch-name-format=%(firstlogline)s
remove-first-log-line=True
# that one seems necessary to force ordering
projects = trunk-pull, branch-pull
[trunk-pull]
root-directory = /export/work/yann/tailor/test/root
source = cvs:bigdiesel
target = git:bigdiesel
start-revision = INITIAL
state-file = trunk-pull.state
subdir = trunk
[branch-pull]
root-directory = /export/work/yann/tailor/test/root
source = cvs:bigdiesel
target = git:bigdiesel-branch
start-revision = bigloo-parser INITIAL
state-file = branch-pull.state
subdir = bigloo-parser
[cvs:bigdiesel]
repository = :pserver:anonymous@cvs.savannah.nongnu.org:/sources/dsssl-utils
#repository = /export/work/yann/tailor/test/cvsroot
module = dsssl-utils/bigdiesel
[git:bigdiesel]
[git:bigdiesel-branch]
parent-repo = ../trunk
#parent-rev = 0bbd4b84fce498793db7fdf01388dcb5ed9ada88
parent-rev = bigloo-parser_branchpoint
^ permalink raw reply
* Re: [PATCH] A Perforce importer for git.
From: Sean @ 2006-06-04 14:04 UTC (permalink / raw)
To: Alex Riesen; +Cc: fork0, git
In-Reply-To: <20060602212005.GA7801@steel.home>
On Fri, 2 Jun 2006 23:20:05 +0200
fork0@t-online.de (Alex Riesen) wrote:
> Well, I'm not quite sure it's at all possible... Perforce has a
> strange ways for doing history: it is kept for each file (as in CVS),
> but you can bundle changes in many files into one "change".
> Perforce also has no branches (in the GIT's meaning of the term).
> These by Perforce are just server-side directories, without any
> relevance to the source whatsoever (just copies).
Yes, each Perforce change records a new file revision level
for each of the files involved in the changeset.
> I'm rather looking for a ability to manage a single branch where
> import "sync" events appear as a merge of changes to the files
> involved in the sync. I just haven't figured out yet how to "break" a
> Perforce change into changes to single files and import that broken up
> commit into git as a merge.
Ahh, so what you're really asking is for a way to maintain the perforce
merge history within git. Whereas the current p4import script just
shows a linear history without any merges.
The problem is that Perforce doesn't merge at the commit level. It
allows changes from other branches to be pulled one file at a time and
from any rev level.
Now, even if you break those changes into one git commit per file per
revision level (yuck!), you still couldn't use them to record Perforce
merges. Git would still merge the entire history of such commits from
the other branch whenever you tried to merge just one.
AFAICS, the best you could do would be to create cherry-picks, plucking
just the commits from the other branch you want. However at that point
you're not getting a git merge anyway and it doesn't seem to be any
benefit beyond what the importer already does. Well, the importer
_could_ make a comment in the commit message describing where each
file change originated (ie. from which branch/rev). Would that help?
Sean
^ permalink raw reply
* Re: Gitk feature - show nearby tags
From: Marco Costalba @ 2006-06-04 13:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3belcicq.fsf@assigned-by-dhcp.cox.net>
On 6/4/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> >> Sorry, in the example time flows from left to right. If you
> >> exclude g then you are excluding everything that is reachable
> >> from g so you would not see "f".
> >>
> > From today git:
> >
> > tag list is:
> >
> > v1.3.3 1b9bc5a7b7434d771726011613a00cb202bd9f44
> > v1.3.2 7abd7117ec57b8c3c2a469db62c7811fdac5c655
> > v1.3.1 7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
> > v1.3.0 4baff50551545e2b6825973ec37bcaf03edb95fe
> >
> > selected sha is ccb365047a1081455b767867f0887e7b4334f9d8
> > (Allow "git repack" users to specify repacking window/depth)
> >
> > $ git-rev-list --topo-order ccb365047a1081455b767867f0887e7b4334f9d8
> > ^1b9bc5a7b7434d771726011613a00cb202bd9f44
> > ^7abd7117ec57b8c3c2a469db62c7811fdac5c655
> > ^7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019
> > ^4baff50551545e2b6825973ec37bcaf03edb95fe
> >
> > ccb365047a1081455b767867f0887e7b4334f9d8
> > ...
> > cd2bdc5309461034e5cc58e1d3e87535ed9e093b
> >
> > Parent of cd2bdc5309461034e5cc58e1d3e87535ed9e093b is
> >
> > 4baff50551545e2b6825973ec37bcaf03edb95fe
> >
> > aka tag v1.3.0
> >
> > Am I missing something?
>
> No, just that I am not getting what you are trying to prove
> here. The tags are all older than your chosen commit.
>
> $ git-rev-list --topo-order ^v1.3.0 ^v1.3.1 ^v1.3.2 ^v1.3.3 e923eff
>
> would show nothing -- and you propose to find out that commit is
> between v1.3.1 and v1.3.2 by using the information that the
> command gives an empty result but I do not know how?
>
OK. Now I understand.
I was erroneously thinking that in
$ git-rev-list --topo-order e923eff ^v1.3.0 ^v1.3.1 ^v1.3.2 ^v1.3.3
the listing (and searching) was _starting_ from e923eff, i.e. all the
previous stuff, in our case v1.3.2 and v1.3.3 was never seen neither
filtered out.
Following an extract from git-rev-list documentation.
DESCRIPTION
-----------
Lists commit objects in reverse chronological order *starting at the
given commit(s)*, taking ancestry relationship into account. This is
useful to produce human-readable log output.
Commits which are stated with a preceding '{caret}' *cause listing to stop at
that point*. Their parents are implied. "git-rev-list foo bar {caret}baz" thus
means "list all the commits which are included in 'foo' and 'bar', but
not in 'baz'".
Perhaps it's me, but I really don't found clear from documentation
that git-rev-list anySha ^HEAD gives _always_ an empty result.
What I understand is that git-rev-list lists _first_ the given commit,
then his parents, then his grandparents and so on _until_ a commit
which is stated with a preceding '{caret}' is found.
So everything that is between the given commit and HEAD is never found
and ignored.
Is it a problem to change the git-rev-list behaviour to reflect (my
understanding of) documentation or it breaks something?
If I have understood correctly with this change the above proposed
algorithm should work.
Marco
^ permalink raw reply
* Re: [PATCH 25/27] Documentation: Spelling fixes
From: Ben Clifford @ 2006-06-04 10:42 UTC (permalink / raw)
To: Horst.H.von.Brand; +Cc: git, Junio C Hamano, Horst H. von Brand
In-Reply-To: <1149366517875-git-send-email->
Horst,
> The default post-update hook, when enabled, runs
> `git-update-server-info` to keep the information used by dumb
> -transports (eg, http) up-to-date. If you are publishing
> +transports (e.g.,, http) up-to-date. If you are publishing
> a git repository that is accessible via http, you should
> probably enable this hook.
just one extra , there
(btw private mail to you keeps bouncing here with various declarations
that you do not exist)
--
^ 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