* Re: [PATCH/RFC] "init-db" can really be just "init"
From: Johannes Schindelin @ 2006-11-27 23:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vmz6cfsuw.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 27 Nov 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Maybe that could be a good rule of thumb to have all porcelainish
> > commands not have any hyphen in their name, like "diff", "commit",
> > "add", etc. ?
>
> I was also hoping that would become the case except verify-tag,
> cherry-pick, and format-patch.
I agree it might make a good rule-of-thumb, but let's not be overzealous.
I have yet to see any better names for those three either, let alone
better names without a hyphen.
> Also I was wondering if it would make sense to give two dashes to the
> back-end ones that never get invoked by the end users directly (e.g.
> merge--recursive, upload--pack) but thought it was too ugly.
I think it would appeal mostly to our friends, the monotone users...
Ciao,
Dscho
^ permalink raw reply
* Re: SEGV when lookup_* returns NULL
From: Johannes Schindelin @ 2006-11-27 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, git
In-Reply-To: <7vu00kftbq.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 27 Nov 2006, Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
>
> > All the lookup_{blob,tree,commit} functions check that the object
> > really is of the requested type and return NULL otherwise.
> > However this NULL pointer is not checked in the calling functions.
> >
> > Should we make lookup_* to just die when invoked on another object-type?
>
> Making lookup_{specific type} die when they see unexpected type
> would not hurt that much, I think, aside from the possibility
> that some callers may check NULL to see if object already
> exists, but they should be using has_sha1_file() instead.
And it would totally clobber the long term goal of libifying git.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] shortlog: use pager
From: Johannes Schindelin @ 2006-11-27 23:29 UTC (permalink / raw)
To: git, torvalds, junkio
On request of the kingpenguin, shortlog now uses the pager if output
goes to a tty.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git.c b/git.c
index 9bcb17c..63a4747 100644
--- a/git.c
+++ b/git.c
@@ -265,7 +265,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
{ "rev-parse", cmd_rev_parse, RUN_SETUP },
{ "rm", cmd_rm, RUN_SETUP },
{ "runstatus", cmd_runstatus, RUN_SETUP },
- { "shortlog", cmd_shortlog, RUN_SETUP },
+ { "shortlog", cmd_shortlog, RUN_SETUP | USE_PAGER },
{ "show-branch", cmd_show_branch, RUN_SETUP },
{ "show", cmd_show, RUN_SETUP | USE_PAGER },
{ "stripspace", cmd_stripspace },
--
1.4.4.1.ga3a78-dirty
^ permalink raw reply related
* [PATCH] sha1_object_info(): be consistent with read_sha1_file()
From: Johannes Schindelin @ 2006-11-27 23:18 UTC (permalink / raw)
To: git, junkio
We used to try loose objects first with sha1_object_info(), but packed
objects first with read_sha1_file(). Now, prefer packed objects over loose
ones with sha1_object_info(), too.
Usually the old behaviour would pose no problem, but when you tried to fix
a fscked up repository by inserting a known-good pack,
git cat-file $(git cat-file -t <sha1>) <sha1>
could fail, even when
git cat-file blob <sha1>
would _not_ fail. Worse, a repack would fail, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
sha1_file.c | 35 ++++++++++++++++++++---------------
1 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 09456d2..63f416b 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1261,7 +1261,7 @@ struct packed_git *find_sha1_pack(const unsigned char *sha1,
}
-int sha1_object_info(const unsigned char *sha1, char *type, unsigned long *sizep)
+static int sha1_loose_object_info(const unsigned char *sha1, char *type, unsigned long *sizep)
{
int status;
unsigned long mapsize, size;
@@ -1270,20 +1270,8 @@ int sha1_object_info(const unsigned char *sha1, char *type, unsigned long *sizep
char hdr[128];
map = map_sha1_file(sha1, &mapsize);
- if (!map) {
- struct pack_entry e;
-
- if (!find_pack_entry(sha1, &e, NULL)) {
- reprepare_packed_git();
- if (!find_pack_entry(sha1, &e, NULL))
- return error("unable to find %s", sha1_to_hex(sha1));
- }
- if (use_packed_git(e.p))
- die("cannot map packed file");
- status = packed_object_info(e.p, e.offset, type, sizep);
- unuse_packed_git(e.p);
- return status;
- }
+ if (!map)
+ return error("unable to find %s", sha1_to_hex(sha1));
if (unpack_sha1_header(&stream, map, mapsize, hdr, sizeof(hdr)) < 0)
status = error("unable to unpack %s header",
sha1_to_hex(sha1));
@@ -1299,6 +1287,23 @@ int sha1_object_info(const unsigned char *sha1, char *type, unsigned long *sizep
return status;
}
+int sha1_object_info(const unsigned char *sha1, char *type, unsigned long *sizep)
+{
+ int status;
+ struct pack_entry e;
+
+ if (!find_pack_entry(sha1, &e, NULL)) {
+ reprepare_packed_git();
+ if (!find_pack_entry(sha1, &e, NULL))
+ return sha1_loose_object_info(sha1, type, sizep);
+ }
+ if (use_packed_git(e.p))
+ die("cannot map packed file");
+ status = packed_object_info(e.p, e.offset, type, sizep);
+ unuse_packed_git(e.p);
+ return status;
+}
+
static void *read_packed_sha1(const unsigned char *sha1, char *type, unsigned long *size)
{
struct pack_entry e;
--
1.4.4.1.gfac7-dirty
^ permalink raw reply related
* Hyphens and hiding core commands (was: "init-db" can really be just "init")
From: Carl Worth @ 2006-11-27 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vmz6cfsuw.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3444 bytes --]
On Mon, 27 Nov 2006 14:05:27 -0800, Junio C Hamano wrote:
> > Maybe that could be a good rule of thumb to have all porcelainish
> > commands not have any hyphen in their name, like "diff", "commit",
> > "add", etc. ?
I like the proposed rule-of-thumb very much. (Particularly if
"update-index" could be included on the list of things to eliminate,
in favor of a new "git resolve" for resolving merges.)
There's another rule-of-thumb I would like to propose that's a bit
harder to state, but I think is just as important (if not more):
For introductory documentation it should never make sense to
introduce a command with specific command-line options before
the same command without options.
As examples, both "commit -a" and "cat-file -p" fail that test and
both appear in the git tutorial here:
http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
My proposals to fix those two are:
commit -a
Change "commit" to commit the working tree. The current "commit
index" option would be made available with a new "-i" or "--index"
option, which could easily be made the default in a config file for
any users that always want it. For merging, commit would also use
the working tree, but would balk at any unmerged paths in the
index, (which would have to be fixed with "git resolve" first).
cat-file -p
Add new "cat" command with the functionality of "cat-file -p",
(also succeeds in removing a hyphenated command from the
tutorial).
> I was also hoping that would become the case except verify-tag,
> cherry-pick, and format-patch.
Here are some none-too-considered options for even cleaning up those:
verify-tag
A new "git verify" which would accept any object specifier and do a
restricted fsck on it, or a tag verification. Of course, the output
should clearly indicate whether a signed-tag had been verified or
just a tree object. [Perhaps the semantic mixing of signature
verification and object integrity verification makes this a bad
idea. I don't know.]
cherry-pick
The name "cherry" is promising, but problematic in that it's
already used for another command, (which is definitely at a
lower-level in functionality, so would violate the rule-of-thumb
being considered here).
format-patch
I mentioned before that I'd like to see "export" and "import" as
commands to replace the functionality of "format-patch" and
"am". [These new names suggest something slightly different than
formatting a patch for mailing and applying an email message, and
perhaps even that difference should be taken advantage of.]
> Also I was wondering if it would
> make sense to give two dashes to the back-end ones that never
> get invoked by the end users directly (e.g. merge--recursive,
> upload--pack) but thought it was too ugly.
If you're willing to consider breaking backwards compatibility for
these, why not hide them even further? An idea I just had that would
hide them quite well would be to tuck them away as sub-commands of a
new "core" command. That is:
git core merge-recursive
git core http-fetch
etc.
That would bury these away from tab-completion of "git-" and even
"git " with the completion scripts. It would still leave them
available with "git core " with the completion scripts of course.
It would also make things much more clear if these commands ever
slipped into an introductory tutorial, etc.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Mozilla, git and Windows
From: Petr Baudis @ 2006-11-27 22:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: Andy Whitcroft, Git Mailing List
In-Reply-To: <9e4733910611270813g4ff982b0tbe6b57d1d49ca9f7@mail.gmail.com>
On Mon, Nov 27, 2006 at 05:13:10PM CET, Jon Smirl wrote:
> The SVN version of the Mozilla repository is about 3GB. It takes
> around a week of CPU time for svnimport to process it.
Is there a reason why a SVN importer would _have_ to take _longer_ than
a CVS importer? I'd expect the opposite from an optimized importer since
you don't have to guess the changesets...
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Michael Haggerty @ 2006-11-27 22:09 UTC (permalink / raw)
To: Markus Schiltknecht; +Cc: Jon Smirl, Git Mailing List, dev, Shawn Pearce
In-Reply-To: <456AD137.8060209@bluegap.ch>
Markus Schiltknecht wrote:
> Michael Haggerty wrote:
>> Jon, I wish you wouldn't portray as obstinacy what is simply a lack of
>> resources. I would like very much to support other cvs2svn output
>> formats. I think it would be great if other projects could benefit from
>> our work. Most of the work I've been doing on cvs2svn lately has been
>> towards supporting other output SCMs.
>
> Really? Hm. I'm somehow sorry for not joining cvs2svn but running my own
> thing with monotone. But I really think it took me less time. OTOH, I'm
> far from finished, yet...
There's still time to join forces :-) "Far from finished" on a project
of this messiness can equal quite a bit of time.
But even if you want to pursue your own converter, consider visiting
#cvs2svn on irc.freenode.net if you want to discuss things.
> Anyway, I've made an attempt at solving the 'picking better sources for
> symbols'-problem:
Let me try to understand this...
> During parsing of all the *,v files, where I'm collecting events
> (commits, branching and tagging) into blobs, I do also remember
> 'possible parent branches' for all the symbols (tag and branch events).
This is the part that can get quite expensive for large repositories, as
there can be orders of magnitude more symbol creations than revisions.
According to Daniel Jacobowitz:
> [...] at one point I believe the GCC repository was gaining up
> to four tags a day (head, two supported release branches, and one
> vendor branch). I've been using the principal that the number of tags
> might be unworkable, but the number of branches generally is not.
This means that the number of tag events is O(number-of-days *
total-number-of-files-in-repo), where the gcc repo has about 50000
files. By contrast, only a small fraction of files is typically touched
in any day.
I've been trying to find a solution that doesn't require quite so much
space. I think that if you allow yourself this much space, the problem
is not very difficult.
> After that and *before* the blob sorting, I check all blobs and try to
> find one single parent branch for them. In the best case, those symbol
> blobs do have exactly one possible parent branch, then I just pick that
> one. If there are multiple possible parents, I try to pick the deepest.
> As branches are symbols themselves, I have to run that multiple times
> until all symbols are resolved.
>
> An example: having branches ROOT -> A -> B -> C (branched in that order)
> plus a branch D derived from branch A.
I assume that you are talking about a situation for which CVS is
ambiguous, like a file with
A = 1.2.2
B = 1.2.4
C = 1.2.6
D = 1.2.2.5.2
> The symbol blob for branch A: has only one possible parent: ROOT. Thus I
> assign A->parent_branch = ROOT.
>
> Next comes the blob for branch C: it has two possible parents: branch B
> and branch A.
Why is ROOT not considered as a possible parent of C?
> At that point we know that A is derived from ROOT, but we
> don't have assigned a parent to B, yet. Thus we can not resolve C this
> time.
>
> Then comes branch B: one parent: A. Mark it.
>
> Next round, we process C again: this time, we know B is branched from A.
> Thus we can remove the possible parent A. Leaving only one possible
> parent branch: B.
But the fact that B preceded C chronologically does not mean that C is
derived from B. If I branch from ROOT or A after creating branch B, the
result as stored in CVS looks exactly the same as if I branch from B
(unless a file was modified between the creation of the parent branch
and the creation of the child branch).
> Now, say we have a tag 'X', which ended up in a blob having A, B, C and
> D as possible parent branches. I currently remove A and B, as they are
> parents of C. But C and D still remain and conflict. I'm unable to
> resolve that symbol. I'm thinking about leaving such conflicts to the
> user to resolve.
From your description, this sounds like a tag that cannot be created
from a single parent branch. Therefore it would have to be cobbled
together from multiple parents.
> I've not yet tested this algorithm extensively. Most larger repositories
> seem to fail somewhere, but not necessarily because of that symbol
> resolving algorithm... :-(
>
> Any comments? Questions? Ideas? I hope to have explained clearly...
>
> And I wish you all a lot of time for your open source projects and your
> families, friends, wifes, girl-friends, etc...! ;-)
:-) Thanks. The same to you!
^ permalink raw reply
* Re: [PATCH/RFC] "init-db" can really be just "init"
From: Junio C Hamano @ 2006-11-27 22:05 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611271622260.9647@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> This should make first GIT impression a little less intimidating.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
I was not sure about this for quite some time, thinking that it
might make sense to default the behaviour of init-db for bare
repositories and give init as a user-level wrapper to drive
init-db to add customization suitable for repositories with
working trees. List?
> Maybe that could be a good rule of thumb to have all porcelainish
> commands not have any hyphen in their name, like "diff", "commit",
> "add", etc. ?
I was also hoping that would become the case except verify-tag,
cherry-pick, and format-patch. Also I was wondering if it would
make sense to give two dashes to the back-end ones that never
get invoked by the end users directly (e.g. merge--recursive,
upload--pack) but thought it was too ugly.
^ permalink raw reply
* Re: SEGV when lookup_* returns NULL
From: Junio C Hamano @ 2006-11-27 21:55 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061127211315.GC18810@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> All the lookup_{blob,tree,commit} functions check that the object
> really is of the requested type and return NULL otherwise.
> However this NULL pointer is not checked in the calling functions.
>
> Should we make lookup_* to just die when invoked on another object-type?
Making lookup_{specific type} die when they see unexpected type
would not hurt that much, I think, aside from the possibility
that some callers may check NULL to see if object already
exists, but they should be using has_sha1_file() instead.
^ permalink raw reply
* [PATCH/RFC] "init-db" can really be just "init"
From: Nicolas Pitre @ 2006-11-27 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This should make first GIT impression a little less intimidating.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
Maybe that could be a good rule of thumb to have all porcelainish
commands not have any hyphen in their name, like "diff", "commit",
"add", etc. ?
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 9677671..ee9ddee 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -25,7 +25,7 @@ Basic Repository[[Basic Repository]]
Everybody uses these commands to maintain git repositories.
- * gitlink:git-init-db[1] or gitlink:git-clone[1] to create a
+ * gitlink:git-init[1] or gitlink:git-clone[1] to create a
new repository.
* gitlink:git-fsck-objects[1] to check the repository for errors.
@@ -106,7 +106,7 @@ Use a tarball as a starting point for a new repository:
------------
$ tar zxf frotz.tar.gz
$ cd frotz
-$ git-init-db
+$ git-init
$ git add . <1>
$ git commit -m 'import of frotz source tree.'
$ git tag v2.43 <2>
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index ca7d09d..bc3ba14 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -74,6 +74,7 @@ Running `git-init-db` in an existing repository is safe. It will not overwrite
things that are already there. The primary reason for rerunning `git-init-db`
is to pick up newly added templates.
+Note that `git-init` is the same as `git-init-db`.
EXAMPLES
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
new file mode 100644
index 0000000..36838c7
--- /dev/null
+++ b/Documentation/git-init.txt
@@ -0,0 +1 @@
+include::git-init-db.txt[]
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 619d656..5501ae0 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -347,6 +347,7 @@ gitlink:git-hash-object[1]::
gitlink:git-index-pack[1]::
Build pack idx file for an existing packed archive.
+gitlink:git-init[1]::
gitlink:git-init-db[1]::
Creates an empty git object database, or reinitialize an
existing one.
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
index 6389de5..13a1878 100644
--- a/Documentation/tutorial-2.txt
+++ b/Documentation/tutorial-2.txt
@@ -17,7 +17,7 @@ Let's start a new project and create a small amount of history:
------------------------------------------------
$ mkdir test-project
$ cd test-project
-$ git init-db
+$ git init
defaulting to local storage area
$ echo 'hello world' > file.txt
$ git add .
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 35af81a..978d4bd 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -20,7 +20,7 @@ can place it under git revision control as follows.
------------------------------------------------
$ tar xzf project.tar.gz
$ cd project
-$ git init-db
+$ git init
------------------------------------------------
Git will reply
diff --git a/Makefile b/Makefile
index e547e2a..c307324 100644
--- a/Makefile
+++ b/Makefile
@@ -203,7 +203,7 @@ EXTRA_PROGRAMS =
BUILT_INS = \
git-format-patch$X git-show$X git-whatchanged$X git-cherry$X \
- git-get-tar-commit-id$X \
+ git-get-tar-commit-id$X git-init$X \
$(patsubst builtin-%.o,git-%$X,$(BUILTIN_OBJS))
# what 'all' will build and 'install' will install, in gitexecdir
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 235a0ee..408b51a 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -242,7 +242,7 @@ static void create_default_files(const char *git_dir, const char *template_path)
}
static const char init_db_usage[] =
-"git-init-db [--template=<template-directory>] [--shared]";
+"git-init [--template=<template-directory>] [--shared]";
/*
* If you want to, you can share the DB area with any number of branches.
diff --git a/git.c b/git.c
index f97de60..5ae5afc 100644
--- a/git.c
+++ b/git.c
@@ -241,6 +241,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)
{ "get-tar-commit-id", cmd_get_tar_commit_id },
{ "grep", cmd_grep, RUN_SETUP },
{ "help", cmd_help },
+ { "init", cmd_init_db },
{ "init-db", cmd_init_db },
{ "log", cmd_log, RUN_SETUP | USE_PAGER },
^ permalink raw reply related
* [PATCH] git-svn: use ~/.subversion config files when using SVN:: libraries
From: Eric Wong @ 2006-11-27 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
This allows users to use HTTP proxy information (among other settings)
from ~/.subversion/servers and ~/.subversion/config
--config-dir (as before) may be passed to git-svn to override the
default choice of '~/.subversion' for the configuration directory.
Thanks to tko on #git for pointing this out.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index de4e74a..d5d9c49 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2822,7 +2822,9 @@ sub libsvn_connect {
SVN::Client::get_username_prompt_provider(
\&_username_prompt, 2),
]);
+ my $config = SVN::Core::config_get_config($_config_dir);
my $ra = SVN::Ra->new(url => $url, auth => $baton,
+ config => $config,
pool => SVN::Pool->new,
auth_provider_callbacks => $callbacks);
$ra->{svn_path} = $url;
@@ -2834,8 +2836,8 @@ sub libsvn_connect {
sub libsvn_dup_ra {
my ($ra) = @_;
- SVN::Ra->new(map { $_ => $ra->{$_} }
- qw/url auth auth_provider_callbacks repos_root svn_path/);
+ SVN::Ra->new(map { $_ => $ra->{$_} } qw/config url
+ auth auth_provider_callbacks repos_root svn_path/);
}
sub libsvn_get_file {
--
1.4.4.1.g36f2
^ permalink raw reply related
* SEGV when lookup_* returns NULL
From: Martin Waitz @ 2006-11-27 21:13 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 571 bytes --]
hoi :)
When trying to an unmodified GIT on a repository with submodules
it segfaults a lot.
All the lookup_{blob,tree,commit} functions check that the object
really is of the requested type and return NULL otherwise.
However this NULL pointer is not checked in the calling functions.
Should we make lookup_* to just die when invoked on another object-type?
Or modify all the callers?
Is there a sane error-handling strategy besides dying in this case?
Really checking all the return values in the whole chain would be
a lot of work.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 9/10] Allow completion of --committer and --author arguments to git log.
From: Shawn Pearce @ 2006-11-27 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7pwfxp8.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > This is just a cute hack, but we can (easily) complete the parameter
> > to --author or --committer in bash by asking for all possible authors
> > or committers in this project from git log and offering them up as
> > valid choices.
>
> Easily but slowly ;-). Try this in the kernel repository
>
> git log --author=Andre<TAB>
>
> and watch the paint dry. You might want to have an extra shell
> to run top before you hit the TAB key.
When I put that in there I was thinking about how slowly that would
run on the kernel repository. But I think its useful for git commit
--author, even if it is a tad turtleish. I'm considering creating
a cache of names under .git/ and only dynamically generate the log
entries which are newer than the cache head. That way we're only
wading through the most recent commits to build up the completion
set.
Apparently the bottleneck is bash. If I add in | sort | uniq to
the end of the sed then I can generate author completions in about 7
seconds for the kernel repository. Without them it is taking about
30 seconds. (Both approximate as I just counted it out in my head.)
You can also see this in top. We spend a bit of time in both git
and sed, then suddenly bash takes over for a while as it makes the
resulting list unique.
Using perl (instead of sed | sort | uniq) appears to improve things
slightly, but I'm getting some odd results that I don't have time
to debug right now.
> It indeed is cute, but I think most people would wonder if the
> terminal went dead, especially without any progress indicators.
Yes. And in completion support mode you cannot give progress. :-(
--
^ permalink raw reply
* Re: [PATCH 9/10] Allow completion of --committer and --author arguments to git log.
From: Junio C Hamano @ 2006-11-27 20:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061127084228.GI19745@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> This is just a cute hack, but we can (easily) complete the parameter
> to --author or --committer in bash by asking for all possible authors
> or committers in this project from git log and offering them up as
> valid choices.
Easily but slowly ;-). Try this in the kernel repository
git log --author=Andre<TAB>
and watch the paint dry. You might want to have an extra shell
to run top before you hit the TAB key.
It indeed is cute, but I think most people would wonder if the
terminal went dead, especially without any progress indicators.
^ permalink raw reply
* Re: [PATCH 1/10] Teach git-completion.bash how to complete git-merge.
From: Shawn Pearce @ 2006-11-27 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlklwhffb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > +__git_merge_strategies ()
> > +{
> > + sed -n "/^all_strategies='/{
> > + s/^all_strategies='//
> > + s/'//
> > + p
> > + q
> > + }" "$(git --exec-path)/git-merge"
> > +}
> > +
>
> Shouldn't we load and compute this once and keep the result in a
> variable (say $__git_merge_strategies)?
Sure. See my latest 4 patch series. :-)
--
^ permalink raw reply
* [PATCH 4/4] Teach bash about git-am/git-apply and their whitespace options.
From: Shawn O. Pearce @ 2006-11-27 20:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <139669072795537547ec26b69115509100dcd7ec.1164658223.git.spearce@spearce.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 53 ++++++++++++++++++++++++++++++++
1 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index ba3adb6..5b7d9d3 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -307,6 +307,54 @@ __git_aliased_command ()
done
}
+__git_whitespacelist="nowarn warn error error-all strip"
+
+_git_am ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ if [ -d .dotest ]; then
+ COMPREPLY=($(compgen -W "
+ --skip --resolved
+ " -- "$cur"))
+ return
+ fi
+ case "$cur" in
+ --whitespace=*)
+ COMPREPLY=($(compgen -W "$__git_whitespacelist" \
+ -- "${cur##--whitespace=}"))
+ return
+ ;;
+ --*)
+ COMPREPLY=($(compgen -W "
+ --signoff --utf8 --binary --3way --interactive
+ --whitespace=
+ " -- "$cur"))
+ return
+ esac
+ COMPREPLY=()
+}
+
+_git_apply ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --whitespace=*)
+ COMPREPLY=($(compgen -W "$__git_whitespacelist" \
+ -- "${cur##--whitespace=}"))
+ return
+ ;;
+ --*)
+ COMPREPLY=($(compgen -W "
+ --stat --numstat --summary --check --index
+ --cached --index-info --reverse --reject --unidiff-zero
+ --apply --no-add --exclude=
+ --whitespace= --inaccurate-eof --verbose
+ " -- "$cur"))
+ return
+ esac
+ COMPREPLY=()
+}
+
_git_branch ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -760,6 +808,8 @@ _git ()
[ "$expansion" ] && command="$expansion"
case "$command" in
+ am) _git_am ;;
+ apply) _git_apply ;;
branch) _git_branch ;;
cat-file) _git_cat_file ;;
checkout) _git_checkout ;;
@@ -795,6 +845,8 @@ _gitk ()
complete -o default -o nospace -F _git git
complete -o default -F _gitk gitk
+complete -o default -F _git_am git-am
+complete -o default -F _git_apply git-apply
complete -o default -F _git_branch git-branch
complete -o default -o nospace -F _git_cat_file git-cat-file
complete -o default -F _git_checkout git-checkout
@@ -824,6 +876,7 @@ complete -o default -o nospace -F _git_log git-whatchanged
# included the '.exe' suffix.
#
if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
+complete -o default -F _git_apply git-apply.exe
complete -o default -o nospace -F _git git.exe
complete -o default -F _git_branch git-branch.exe
complete -o default -o nospace -F _git_cat_file git-cat-file.exe
--
^ permalink raw reply related
* [PATCH 3/4] Cache the list of merge strategies and available commands during load.
From: Shawn O. Pearce @ 2006-11-27 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <139669072795537547ec26b69115509100dcd7ec.1164658223.git.spearce@spearce.org>
Since the user's git installation is not likely to grow a new command
or merge strategy in the lifespan of the current shell process we can
save time during completion operations by caching these lists during
sourcing of the completion support.
If the git executable is not available or we run into errors while
caching at load time then we defer these to runtime and generate
the list on the fly. This might happen if the user doesn't put git
into their PATH until after the completion script gets sourced.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This is by request of Junio. :-)
contrib/completion/git-completion.bash | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d4eb138..ba3adb6 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -18,7 +18,13 @@
# 2) Added the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) Consider changing your PS1 to also show the current branch:
+# 3) You may want to make sure the git executable is available
+# in your PATH before this script is sourced, as some caching
+# is performed while the script loads. If git isn't found
+# at source time then all lookups will be done on demand,
+# which may be slightly slower.
+#
+# 4) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -150,6 +156,10 @@ __git_remotes ()
__git_merge_strategies ()
{
+ if [ -n "$__git_merge_strategylist" ]; then
+ echo "$__git_merge_strategylist"
+ return
+ fi
sed -n "/^all_strategies='/{
s/^all_strategies='//
s/'//
@@ -157,6 +167,8 @@ __git_merge_strategies ()
q
}" "$(git --exec-path)/git-merge"
}
+__git_merge_strategylist=
+__git_merge_strategylist="$(__git_merge_strategies 2>/dev/null)"
__git_complete_file ()
{
@@ -214,6 +226,10 @@ __git_complete_revlist ()
__git_commands ()
{
+ if [ -n "$__git_commandlist" ]; then
+ echo "$__git_commandlist"
+ return
+ fi
local i IFS=" "$'\n'
for i in $(git help -a|egrep '^ ')
do
@@ -263,6 +279,8 @@ __git_commands ()
esac
done
}
+__git_commandlist=
+__git_commandlist="$(__git_commands 2>/dev/null)"
__git_aliases ()
{
--
1.4.4.1.ge3fb
^ permalink raw reply related
* [PATCH 2/4] Teach bash about git-commit's options.
From: Shawn O. Pearce @ 2006-11-27 20:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <139669072795537547ec26b69115509100dcd7ec.1164658223.git.spearce@spearce.org>
Not only can we complete the long options for git-commit, but now we
can also complete author strings by looking up all prior author names
in all branches and offering them up as possible completions. This
is similiar to the support used by the --author= option to git-log.
Unfortunately this changes names which use ' within their string.
It seems to be bash's fault here, the ' is being passed out by sed
but is getting removed during the completion generation. Fortunately
' appears in only one name in git.git so the damage is likely to be
rather low.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e53f040..d4eb138 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -332,6 +332,32 @@ _git_cherry_pick ()
esac
}
+_git_commit ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --author=*)
+ local IFS=$'\n'
+ cur="${cur##--author=}"
+ COMPREPLY=($(compgen -P \' -S \' \
+ -W "$(git log --pretty=raw --all \
+ | sed -n -e "/^author /{
+ s/^author //
+ s/>.*/>/
+ p
+ }")" -- "${cur##\'}"))
+ return
+ ;;
+ --*)
+ COMPREPLY=($(compgen -W "
+ --all --author=\' --signoff --verify --no-verify
+ --edit --amend --include --only
+ " -- "$cur"))
+ return
+ esac
+ COMPREPLY=()
+}
+
_git_diff ()
{
__git_complete_file
@@ -720,6 +746,7 @@ _git ()
cat-file) _git_cat_file ;;
checkout) _git_checkout ;;
cherry-pick) _git_cherry_pick ;;
+ commit) _git_commit ;;
diff) _git_diff ;;
diff-tree) _git_diff_tree ;;
fetch) _git_fetch ;;
@@ -754,6 +781,7 @@ complete -o default -F _git_branch git-branch
complete -o default -o nospace -F _git_cat_file git-cat-file
complete -o default -F _git_checkout git-checkout
complete -o default -F _git_cherry_pick git-cherry-pick
+complete -o default -F _git_commit git-commit
complete -o default -o nospace -F _git_diff git-diff
complete -o default -F _git_diff_tree git-diff-tree
complete -o default -o nospace -F _git_fetch git-fetch
--
1.4.4.1.ge3fb
^ permalink raw reply related
* [PATCH 1/4] Support --strategy=x completion in addition to --strategy x.
From: Shawn O. Pearce @ 2006-11-27 20:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Because git-merge and git-rebase both accept -s, --strategy or --strategy=
we should recognize all three formats in the bash completion functions and
issue back all merge strategies on demand.
I also moved the prior word testing to be before the current word testing,
as the current word cannot be completed with -- if the prior word was an
option which requires a parameter, such as -s or --strategy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 30 ++++++++++++++++++++----------
1 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a957165..e53f040 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -455,18 +455,23 @@ _git_log ()
_git_merge ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "${COMP_WORDS[COMP_CWORD-1]}" in
+ -s|--strategy)
+ COMPREPLY=($(compgen -W "$(__git_merge_strategies)" -- "$cur"))
+ return
+ esac
case "$cur" in
+ --strategy=*)
+ COMPREPLY=($(compgen -W "$(__git_merge_strategies)" \
+ -- "${cur##--strategy=}"))
+ return
+ ;;
--*)
COMPREPLY=($(compgen -W "
--no-commit --no-summary --squash --strategy
" -- "$cur"))
return
esac
- case "${COMP_WORDS[COMP_CWORD-1]}" in
- -s|--strategy)
- COMPREPLY=($(compgen -W "$(__git_merge_strategies)" -- "$cur"))
- return
- esac
COMPREPLY=($(compgen -W "$(__git_refs)" -- "$cur"))
}
@@ -543,18 +548,23 @@ _git_rebase ()
" -- "$cur"))
return
fi
+ case "${COMP_WORDS[COMP_CWORD-1]}" in
+ -s|--strategy)
+ COMPREPLY=($(compgen -W "$(__git_merge_strategies)" -- "$cur"))
+ return
+ esac
case "$cur" in
+ --strategy=*)
+ COMPREPLY=($(compgen -W "$(__git_merge_strategies)" \
+ -- "${cur##--strategy=}"))
+ return
+ ;;
--*)
COMPREPLY=($(compgen -W "
--onto --merge --strategy
" -- "$cur"))
return
esac
- case "${COMP_WORDS[COMP_CWORD-1]}" in
- -s|--strategy)
- COMPREPLY=($(compgen -W "$(__git_merge_strategies)" -- "$cur"))
- return
- esac
COMPREPLY=($(compgen -W "$(__git_refs)" -- "$cur"))
}
--
1.4.4.1.ge3fb
^ permalink raw reply related
* [PATCH] Update documentation to remove incorrect GIT_DIFF_OPTS example.
From: Sean @ 2006-11-27 19:37 UTC (permalink / raw)
To: git
Git no longer calls an external diff program to generate patches.
Remove the documentation which suggests that you can pass
arbitrary diff options via the GIT_DIFF_OPTS environment variable.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
---
Documentation/diff-format.txt | 57 ++++------------------------------------
Documentation/git.txt | 32 ++++++++++++++++++++---
2 files changed, 34 insertions(+), 55 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index e4520e2..883c1bb 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -65,62 +65,17 @@ Generating patches with -p
When "git-diff-index", "git-diff-tree", or "git-diff-files" are run
with a '-p' option, they do not produce the output described above;
-instead they produce a patch file.
+instead they produce a patch file. You can customize the creation
+of such patches via the GIT_EXTERNAL_DIFF and the GIT_DIFF_OPTS
+environment variables.
-The patch generation can be customized at two levels.
-
-1. When the environment variable 'GIT_EXTERNAL_DIFF' is not set,
- these commands internally invoke "diff" like this:
-
- diff -L a/<path> -L b/<path> -pu <old> <new>
-+
-For added files, `/dev/null` is used for <old>. For removed
-files, `/dev/null` is used for <new>
-+
-The "diff" formatting options can be customized via the
-environment variable 'GIT_DIFF_OPTS'. For example, if you
-prefer context diff:
-
- GIT_DIFF_OPTS=-c git-diff-index -p HEAD
-
-
-2. When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
- program named by it is called, instead of the diff invocation
- described above.
-+
-For a path that is added, removed, or modified,
-'GIT_EXTERNAL_DIFF' is called with 7 parameters:
-
- path old-file old-hex old-mode new-file new-hex new-mode
-+
-where:
-
- <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
- contents of <old|new>,
- <old|new>-hex:: are the 40-hexdigit SHA1 hashes,
- <old|new>-mode:: are the octal representation of the file modes.
-
-+
-The file parameters can point at the user's working file
-(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
-when a new file is added), or a temporary file (e.g. `old-file` in the
-index). 'GIT_EXTERNAL_DIFF' should not worry about unlinking the
-temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits.
-
-For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
-parameter, <path>.
-
-
-git specific extension to diff format
--------------------------------------
-
-What -p option produces is slightly different from the
-traditional diff format.
+What the -p option produces is slightly different from the traditional
+diff format.
1. It is preceded with a "git diff" header, that looks like
this:
- diff --git a/file1 b/file2
+ diff --git a/file1 b/file2
+
The `a/` and `b/` filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 619d656..6382ef0 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -639,11 +639,35 @@ git Commits
git Diffs
~~~~~~~~~
'GIT_DIFF_OPTS'::
+ Only valid setting is "--unified=??" or "-u??" to set the
+ number of context lines shown when a unified diff is created.
+ This takes precedence over any "-U" or "--unified" option
+ value passed on the git diff command line.
+
'GIT_EXTERNAL_DIFF'::
- see the "generating patches" section in :
- gitlink:git-diff-index[1];
- gitlink:git-diff-files[1];
- gitlink:git-diff-tree[1]
+ When the environment variable 'GIT_EXTERNAL_DIFF' is set, the
+ program named by it is called, instead of the diff invocation
+ described above. For a path that is added, removed, or modified,
+ 'GIT_EXTERNAL_DIFF' is called with 7 parameters:
+
+ path old-file old-hex old-mode new-file new-hex new-mode
++
+where:
+
+ <old|new>-file:: are files GIT_EXTERNAL_DIFF can use to read the
+ contents of <old|new>,
+ <old|new>-hex:: are the 40-hexdigit SHA1 hashes,
+ <old|new>-mode:: are the octal representation of the file modes.
+
++
+The file parameters can point at the user's working file
+(e.g. `new-file` in "git-diff-files"), `/dev/null` (e.g. `old-file`
+when a new file is added), or a temporary file (e.g. `old-file` in the
+index). 'GIT_EXTERNAL_DIFF' should not worry about unlinking the
+temporary file --- it is removed when 'GIT_EXTERNAL_DIFF' exits.
++
+For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
+parameter, <path>.
other
~~~~~
--
1.4.4.1
^ permalink raw reply related
* Re: Show remote branches on gitweb
From: Jakub Narebski @ 2006-11-27 19:26 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20061127T200958-750@post.gmane.org>
Pazu wrote:
> Jakub Narebski <jnareb <at> gmail.com> writes:
>
>> > Is there any way to do it? I'm using git-svn to track a remote
>> > subversion repository, and it would be very nice to browse the
>> > history for a remote branch for which I didn't start a local
>> >branch yet.
>>
>> Planned, not implemented yet.
>
> Probably not a technically correct solution, but the following changes did the
> trick for me.
>
>
> --- a/gitweb.cgi 2006-11-23 11:02:34.000000000 -0200
> +++ b/gitweb.cgi 2006-11-27 10:09:56.000000000 -0200
> @@ -1428,8 +1431,7 @@
>
> open my $fd, '-|', git_cmd(), 'for-each-ref',
> ($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
> - '--format=%(objectname) %(refname) %(subject)%00%(committer)',
> - 'refs/heads'
> + '--format=%(objectname) %(refname) %(subject)%00%(committer)'
> or return;
> while (my $line = <$fd>) {
> my %ref_item;
> @@ -1440,6 +1442,7 @@
> my ($committer, $epoch, $tz) =
> ($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
> $name =~ s!^refs/heads/!!;
> + $name =~ s!^refs/remotes/!!;
>
> $ref_item{'name'} = $name;
> $ref_item{'id'} = $hash;
>
>
>
> I've just changed the git_get_heads_list function to let 'for-each-ref'
> return all top refs instead of just those in refs/heads, and added a line to
> remove 'refs/remotes/' from the remote branch names.
>
> Again, probably not the right solution, but now I have remote branches listed
> under "heads", and that's all I really need.
What about tags (refs/tags/), which shouldn't be here?
Besides, it is quick'n'dirty solution; I'm not against having it as a patch
in git mailing list archives, but I'd rather not have it there.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Show remote branches on gitweb
From: Pazu @ 2006-11-27 19:20 UTC (permalink / raw)
To: git
In-Reply-To: <ek7jsp$j83$1@sea.gmane.org>
Jakub Narebski <jnareb <at> gmail.com> writes:
> > Is there any way to do it? I'm using git-svn to track a remote
> > subversion repository, and it would be very nice to browse the
> > history for a remote branch for which I didn't start a local
> >branch yet.
>
> Planned, not implemented yet.
Probably not a technically correct solution, but the following changes did the
trick for me.
--- a/gitweb.cgi 2006-11-23 11:02:34.000000000 -0200
+++ b/gitweb.cgi 2006-11-27 10:09:56.000000000 -0200
@@ -1428,8 +1431,7 @@
open my $fd, '-|', git_cmd(), 'for-each-ref',
($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
- '--format=%(objectname) %(refname) %(subject)%00%(committer)',
- 'refs/heads'
+ '--format=%(objectname) %(refname) %(subject)%00%(committer)'
or return;
while (my $line = <$fd>) {
my %ref_item;
@@ -1440,6 +1442,7 @@
my ($committer, $epoch, $tz) =
($committerinfo =~ /^(.*) ([0-9]+) (.*)$/);
$name =~ s!^refs/heads/!!;
+ $name =~ s!^refs/remotes/!!;
$ref_item{'name'} = $name;
$ref_item{'id'} = $hash;
I've just changed the git_get_heads_list function to let 'for-each-ref'
return all top refs instead of just those in refs/heads, and added a line to
remove 'refs/remotes/' from the remote branch names.
Again, probably not the right solution, but now I have remote branches listed
under "heads", and that's all I really need.
-- Pazu
^ permalink raw reply
* Re: git: how to produce context diffs?
From: Junio C Hamano @ 2006-11-27 19:18 UTC (permalink / raw)
To: Bruno Haible; +Cc: git
In-Reply-To: <200611271516.30425.bruno@clisp.org>
There are a few things to note:
* Obviously diff.c::builtin_diff() needs to be taught to
generate the new format, both in the patch text and also in
the patch and hunk header part.
* Corresponding changes to builtin-apply.c need to be made;
most of the functions in the callchain that starts at
apply_patch() down to apply_one_fragment() need to be taught
about the copied context format. Also code to count diffstat
in builtin-apply.c needs to be adjusted. This part should be
done first before diff.c if we were to support copied context
diff, because we should not be generating what we cannot
apply.
* I do not think of a sane way to show a combined diff from
multiple preimages in copied context format; combine-diff.c
can probably be left as it is.
I too find larger hunks easier to read with copied context than
with unified context, but what needs to be done listed above is
a nontrivial amount of work. Since the beginning, git has only
supported unified context format and not copied context format,
and apparently people who lived with git for the last 18 months
have survived without copied context format, so it is of very
low priority even for me right now.
I am not opposed to adding the copied context format as long as
somebody else does the work ;-).
^ permalink raw reply
* Re: [PATCH 1/10] Teach git-completion.bash how to complete git-merge.
From: Junio C Hamano @ 2006-11-27 19:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20061127084047.GA19745@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> +__git_merge_strategies ()
> +{
> + sed -n "/^all_strategies='/{
> + s/^all_strategies='//
> + s/'//
> + p
> + q
> + }" "$(git --exec-path)/git-merge"
> +}
> +
Shouldn't we load and compute this once and keep the result in a
variable (say $__git_merge_strategies)?
^ permalink raw reply
* Re: Mozilla, git and Windows
From: Robin Rosenberg @ 2006-11-27 16:37 UTC (permalink / raw)
To: Jon Smirl; +Cc: Andy Whitcroft, Git Mailing List
In-Reply-To: <9e4733910611270813g4ff982b0tbe6b57d1d49ca9f7@mail.gmail.com>
måndag 27 november 2006 17:13 skrev Jon Smirl:
> On 11/27/06, Andy Whitcroft <apw@shadowen.org> wrote:
> > I think you are more likely to win letting them convert over to SVN.
> > From there people naturally start using git mirrors from the SVN trunk.
> > Cirtainly I have two projects which do not use git, one in CVS and one
> > in SVN. I just svnimport that and work in git. I am confident with
> > time the project will migrate, but I am happy other git users are happy
> > all without it being the tool of choice.
>
> The SVN version of the Mozilla repository is about 3GB. It takes
> around a week of CPU time for svnimport to process it.
You can track parts of an SVN repo using git-svn. You rarely need the
whole history to start working on a project.
In addition some nice soul with too much hardware will probably make an import
and publish it and track it so everybody won't have to. We see a lot of
git-tracked repos SVN/CVS already.
^ 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