* Re: recent patch breaks the build ?
From: Andreas Ericsson @ 2005-11-16 20:18 UTC (permalink / raw)
To: Andrew Wozniak; +Cc: git
In-Reply-To: <437B8CEC.8040002@mc.com>
Andrew Wozniak wrote:
> Yes, that suggestion worked - it is similar to other code fragments and
> ifdefs within the same file.
>
> Unfortunately, now there are other failures:
>
> gcc -o http-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>'
> http-push.c
> http-push.c: In function `start_mkcol':
> http-push.c:479: `CURLOPT_HTTPGET' undeclared (first use in this function)
>
....
> I grep'd for these defines and they are nowhere to be found! Is some
> other package needed to resolve these undefines on my RH7.2 build host?
>
curl and curl-devel. Or you can build with
make NO_CURL=YesPlease
which just means you won't have http and https transports available.
This shouldn't be much of a problem on a server though.
> I'm really surprised that the unmodified tarball source fails to build.
> Just curious, is the git project rebuilt on a "nightly" basis to verify
> recent patches?
>
I have no idea, but since it's a developer tool in pre-1.0 I think the
general consensus is that user-friendliness in the build-process comes
somewhere between "not so important" and "what? users? oh, those living
in the *other* land!"
Perhaps you should try the RPM's at
http://www.kernel.org/pub/software/scm/git-core/ ?
If nothing else it will tell you what other packages you need.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Junio C Hamano @ 2005-11-16 20:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, Lukas Sandström, git, junkio
In-Reply-To: <Pine.LNX.4.64.0511151552400.11232@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Tue, 15 Nov 2005, Alex Riesen wrote:
>>
>> Sorry, it doesn't. The code loops here:
>>
>> 401 /* find the permutations which contain all missing objects */
>> 402 perm_all = perm = get_all_permutations(non_unique);
>
> Looks like the whole thing is exponential.
This reminds me of one thing I have been meaning to remove.
The $GIT_OBJECT_DIRECTORY/info/pack file produced by
update-server-info records not just the packs (P lines), but its
dependencies (D lines) and top objects (T lines). If there are
more than one packs, D lines are meant to help the downloader to
figure out what other packs are needed to complete.
"meant to" is the keyword here. The original heuristics was
very bad (still correct but way suboptimal) and it has never
been updated. I do not use that information myself in http
fetch, and I do not think any Porcelain uses it.
Top objects are tags and commits in the pack that are not
reachable from any other object in the same pack. This can be
useful if you obtain just a packfile -- you can run server-info
to produce info/pack file, and resurrect the branch heads and
tags by using them --- you would not know what they are called,
though. I have been thinking it may be worthwhile to also
record bottom objects (B lines, naturally) --- tags and commits
in the pack that refer to tags or commits not present in the
same pack. This would help commit walkers to decide which pack
is more efficient to slurp when faced with multiple choices. If
you see a pack all whose bottom objects you have in your
repository, fetching that would complete the commit walking, so
the choice would become the matter of choosing such a pack among
multiple that has smallest number of objects you do not have
locally -- you would have the index file for each pack at that
point.
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Linus Torvalds @ 2005-11-16 20:10 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Franck, git
In-Reply-To: <46a038f90511161201h54c5fa73l20b5dcf3b5c19399@mail.gmail.com>
On Thu, 17 Nov 2005, Martin Langhoff wrote:
>
> cg-clone already does this. One tricky thing with the selective
> cloning is that you want to pull the named head plus all its related
> objects, and then pull only the _relevant_ tags.
Well, if you keep to native git protocols, you can trivially do that by
just fetching the required heads, and then fetching only the tags for
which you have the pointed-to object (ie look for the ^{} thing in
git-ls-remote, and check if you have that object, then get those tags).
For rsync, since you get all objects anyway, there's no point to limiting
the branches. Might as well just delete them and prune them.
Linus
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Martin Langhoff @ 2005-11-16 20:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck, git
In-Reply-To: <7vveys8n8q.fsf@assigned-by-dhcp.cox.net>
On 11/17/05, Junio C Hamano <junkio@cox.net> wrote:
> The underlying network transfer program, 'git-clone-pack', can
> be told to clone only specified branches. If somebody is
> interested, updating the 'git-clone' wrapper to use it should
> not be too hard -- obviously this needs to be done for other
> transports as well, though.
cg-clone already does this. One tricky thing with the selective
cloning is that you want to pull the named head plus all its related
objects, and then pull only the _relevant_ tags. There's been
discussion of pulling tagsrefs+related tag objects and then pruning
any tagrefs+tagobjects where the commit is unreachable with the
objects you already have. You surely remember my 'git-rev-parse is
crashing' thread.
If you just pull tagrefs and all the objects needed for them, chances
are you'll get the whole repo anyway ;-)
cheers,
martin
^ permalink raw reply
* Re: [PATCH] symref support for import scripts
From: Matthias Urlichs @ 2005-11-16 19:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pavel Roskin, git, Martin Langhoff
In-Reply-To: <7vu0ec7502.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 960 bytes --]
Hi,
Junio C Hamano:
> Martin and Matthias, are these OK with you two? All of the
> changes look trivially correct, so I'll take them.
>
IMHO: That code needs to vanish anyway.
The only reason we have to read HEAD is that, at the end of the
day^Wimport, whatever HEAD points to may have been updated. Thus,
we need to merge forward, to get the index back into sync.
The only thing we want to do with HEAD, in order to accomplish that,
is to find the SHA1 it points to, before and after the import.
No use of git-symbolic-ref is necessary for that.
All the deref code was a good idea when we actually modified the
checked-out index and/or tree while importing, but that does not happen
any more.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
A good supervisor can step on your toes without messing up your shine.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Andrew Wozniak @ 2005-11-16 19:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nick Hengeveld
In-Reply-To: <7v64qs8kuo.fsf@assigned-by-dhcp.cox.net>
Yes, that suggestion worked - it is similar to other code fragments and
ifdefs within the same file.
Unfortunately, now there are other failures:
gcc -o http-push.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>'
http-push.c
http-push.c: In function `start_mkcol':
http-push.c:479: `CURLOPT_HTTPGET' undeclared (first use in this function)
http-push.c:479: (Each undeclared identifier is reported only once
http-push.c:479: for each function it appears in.)
http-push.c: In function `start_move':
http-push.c:581: `CURLOPT_HTTPGET' undeclared (first use in this function)
http-push.c: In function `refresh_lock':
http-push.c:615: `CURLOPT_HTTPGET' undeclared (first use in this function)
http-push.c: In function `fetch_index':
http-push.c:890: `CURLOPT_HTTPGET' undeclared (first use in this function)
http-push.c: In function `lock_remote':
http-push.c:1215: `CURLOPT_HTTPGET' undeclared (first use in this function)
http-push.c: In function `main':
I grep'd for these defines and they are nowhere to be found! Is some
other package needed to resolve these undefines on my RH7.2 build host?
I'm really surprised that the unmodified tarball source fails to build.
Just curious, is the git project rebuilt on a "nightly" basis to verify
recent patches?
Thanks again, Andrew
Junio C Hamano wrote:
> Andrew Wozniak <awozniak@mc.com> writes:
>
>> Have just started using git for u-boot related development. After
>> downloading git-snapshot-20051116 tarball and attempting a build under
>> RH7.2, I get the following failure:
>
> Would this help?
>
> -- >8 --
>
> diff --git a/http-fetch.c b/http-fetch.c
> index 21cc1b9..45e97f9 100644
> --- a/http-fetch.c
> +++ b/http-fetch.c
> @@ -902,16 +902,18 @@ static void fetch_alternates(char *base)
> char *data;
> struct active_request_slot *slot;
> static struct alt_request alt_req;
> - int num_transfers;
>
> +#ifdef USE_CURL_MULTI
> /* If another request has already started fetching alternates,
> wait for them to arrive and return to processing this request's
> curl message */
> while (got_alternates == 0) {
> + int num_transfers;
> curl_multi_perform(curlm, &num_transfers);
> process_curl_messages();
> process_request_queue();
> }
> +#endif
>
> /* Nothing to do if they've already been fetched */
> if (got_alternates == 1)
>
>
^ permalink raw reply
* Re: [PATCH] symref support for import scripts
From: Junio C Hamano @ 2005-11-16 19:43 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, Martin Langhoff, Matthias Urlichs
In-Reply-To: <1132165648.4024.6.camel@dv>
Pavel Roskin <proski@gnu.org> writes:
> Fix git import script not to assume that .git/HEAD is a symlink.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
Thanks.
Martin and Matthias, are these OK with you two? All of the
changes look trivially correct, so I'll take them.
> diff --git a/git-cvsimport.perl b/git-cvsimport.perl
> index 7bd9136..efe1934 100755
> --- a/git-cvsimport.perl
> +++ b/git-cvsimport.perl
> @@ -437,7 +437,11 @@ unless(-d $git_dir) {
> "Either use the correct '-o branch' option,\n".
> "or import to a new repository.\n";
>
> - $last_branch = basename(readlink("$git_dir/HEAD"));
> + open(F, "git-symbolic-ref HEAD |") or
> + die "Cannot run git-symbolic-ref: $!\n";
> + chomp ($last_branch = <F>);
> + $last_branch = basename($last_branch);
> + close(F);
> unless($last_branch) {
> warn "Cannot read the last branch name: $! -- assuming 'master'\n";
> $last_branch = "master";
This part, before or after Pavel's fixes, seems to refuse a
branch named 'topic/#1'. This is not a problem for import
scripts that name their own branches based on what is in the
foreign SCM and flatten their the branch namespaces, but I'd
prefer a comment about the issue somewhere around this code, to
prevent people from copying and pasting the use of "basename()".
There is a corresponding piece in svnimport as well.
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Junio C Hamano @ 2005-11-16 19:15 UTC (permalink / raw)
To: Andrew Wozniak; +Cc: git, Nick Hengeveld
In-Reply-To: <437B6997.8010903@mc.com>
Andrew Wozniak <awozniak@mc.com> writes:
> Have just started using git for u-boot related development. After
> downloading git-snapshot-20051116 tarball and attempting a build under
> RH7.2, I get the following failure:
Would this help?
-- >8 --
diff --git a/http-fetch.c b/http-fetch.c
index 21cc1b9..45e97f9 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -902,16 +902,18 @@ static void fetch_alternates(char *base)
char *data;
struct active_request_slot *slot;
static struct alt_request alt_req;
- int num_transfers;
+#ifdef USE_CURL_MULTI
/* If another request has already started fetching alternates,
wait for them to arrive and return to processing this request's
curl message */
while (got_alternates == 0) {
+ int num_transfers;
curl_multi_perform(curlm, &num_transfers);
process_curl_messages();
process_request_queue();
}
+#endif
/* Nothing to do if they've already been fetched */
if (got_alternates == 1)
^ permalink raw reply related
* Re: Sourceforge doesn't like git cvsimport
From: H. Peter Anvin @ 2005-11-16 19:09 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90511161100x4263ac01iaf3c0497db5021f6@mail.gmail.com>
Martin Langhoff wrote:
> Unpossible!
>
> I run git-cvsimport against Moodle's cvs repo on SF.net at least twice
> a day over SSH. I did it several times with anon cvs too. SF.net cvs
> servers have been up, down and unreliable the last week, but that's
> bad with the plain old cvs client too.
>
> Can we get more info on what's happening?
>
No idea. I used it as late as earlier this week, but now I'm getting
the error seen in the message.
It also frequently connects and immediately disconnects, which I
attribute to the unreliability you describe.
-hpa
^ permalink raw reply
* [PATCH] Documentation/git-log.txt: trivial typo fix.
From: Alecs King @ 2005-11-16 19:06 UTC (permalink / raw)
To: git
Signed-off-by: Alecs King <alecsk@gmail.com>
---
Documentation/git-log.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
applies-to: 1e3fcf60526c196a46433e6947c9104ca236f230
c9c64ee3f4e333a7c3626da45b38105e67c6517f
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 9cac088..e995d1b 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -20,7 +20,7 @@ This manual page describes only the most
OPTIONS
-------
---pretty=<format>:
+--pretty=<format>::
Controls the way the commit log is formatted.
--max-count=<n>::
---
0.99.9.GIT
--
Alecs King
^ permalink raw reply related
* Re: Cogito and --exclude vs --exclude-per-directory
From: Junio C Hamano @ 2005-11-16 19:01 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20051116093630.GA2783@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> [Note: this experiment was done with git 0.99.9g and Cogito 0.15.1, so ]
>
> It seems that --exclude patterns always take precedence over
> --exclude-per-directory patterns.
>
> Is this the intended behavior?
Yes, we had a lengthy discussion on this before ls-files
acquired the exclude patterns.
Documentation/git-ls-files.txt "Exclude Patterns" summarizes the
precedence rule, and it was done that way to allow command line
users to override what are in individual per-directory pattern
files per-invocation basis. That is, --exclude-per-directory is
to store project defaults, and --exclude is for end-users to
specify override per-invocation. --exclude-from has the lowest
precedence to give overall default. The example in the
documetation has a a good illustration.
* --exclude-from contains '*.[oa]' to catch generic
"uninteresting" files.
* --exclude-per-directory files contain patterns to
catch files that are built by the Makefile in the
directory.
* --exclude specifies whatever the user feels like for
the particular invocation.
If I were writing a Porcelain, I would probably install default
exclude list in /usr/lib/MyPorcelain/exclude file and point at
the file with --exclude-from. I may also be tempted to check
$HOME/.MyPorcelain/exclude file and add it to give defaults per
user, but I do not do Porcelains, so...
^ permalink raw reply
* Re: Sourceforge doesn't like git cvsimport
From: Martin Langhoff @ 2005-11-16 19:00 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <437B7416.8030704@zytor.com>
Unpossible!
I run git-cvsimport against Moodle's cvs repo on SF.net at least twice
a day over SSH. I did it several times with anon cvs too. SF.net cvs
servers have been up, down and unreliable the last week, but that's
bad with the plain old cvs client too.
Can we get more info on what's happening?
martin
^ permalink raw reply
* Re: stgit truncates binary files to zero length when applying patches
From: Junio C Hamano @ 2005-11-16 18:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0511160311k725526d8v@mail.gmail.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> ... When pushing a patch, if
> a merge is needed (like in your case, the base of the foo patch has
> changed), StGIT first tries "git-diff-tree | git-apply" for speed
> reasons. If this fails, it falls back to a three-way merge.
I think many of the scripts rely on git-apply failing reliably
for unapplicable patches. I'll do a new test script in git.git/t
and if it fails on binary files, try to fix it today.
Incidentally, for the last couple of days, I was working on
adding a very limited binary file diff support to "diff piped to
apply" pattern, and the result has been posted as "reworked
rebase" patches. It is very limited in the sense that the diff
output does not attempt to be useful if the patch consumer does
not have both pre- and post-image blob, but for the use of
StGIT's internal patch replaying purposes that is not a concern,
so you might be interested in taking a look.
^ permalink raw reply
* [PATCH] symref support for import scripts
From: Pavel Roskin @ 2005-11-16 18:27 UTC (permalink / raw)
To: git
Fix git import script not to assume that .git/HEAD is a symlink.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/git-archimport.perl b/git-archimport.perl
index e22c816..23becb7 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -410,8 +410,7 @@ foreach my $ps (@psets) {
open HEAD, ">$git_dir/refs/heads/$ps->{branch}";
print HEAD $commitid;
close HEAD;
- unlink ("$git_dir/HEAD");
- symlink("refs/heads/$ps->{branch}","$git_dir/HEAD");
+ system('git-update-ref', 'HEAD', "$ps->{branch}");
# tag accordingly
ptag($ps->{id}, $commitid); # private tag
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 7bd9136..efe1934 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -437,7 +437,11 @@ unless(-d $git_dir) {
"Either use the correct '-o branch' option,\n".
"or import to a new repository.\n";
- $last_branch = basename(readlink("$git_dir/HEAD"));
+ open(F, "git-symbolic-ref HEAD |") or
+ die "Cannot run git-symbolic-ref: $!\n";
+ chomp ($last_branch = <F>);
+ $last_branch = basename($last_branch);
+ close(F);
unless($last_branch) {
warn "Cannot read the last branch name: $! -- assuming 'master'\n";
$last_branch = "master";
@@ -829,8 +833,7 @@ if($orig_branch) {
print "DONE; creating $orig_branch branch\n" if $opt_v;
system("cp","$git_dir/refs/heads/$opt_o","$git_dir/refs/heads/master")
unless -f "$git_dir/refs/heads/master";
- unlink("$git_dir/HEAD");
- symlink("refs/heads/$orig_branch","$git_dir/HEAD");
+ system('git-update-ref', 'HEAD', "$orig_branch");
unless ($opt_i) {
system('git checkout');
die "checkout failed: $?\n" if $?;
diff --git a/git-svnimport.perl b/git-svnimport.perl
index af13fdd..45d77c5 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -216,7 +216,11 @@ unless(-d $git_dir) {
-f "$git_dir/svn2git"
or die "'$git_dir/svn2git' does not exist.\n".
"You need that file for incremental imports.\n";
- $last_branch = basename(readlink("$git_dir/HEAD"));
+ open(F, "git-symbolic-ref HEAD |") or
+ die "Cannot run git-symbolic-ref: $!\n";
+ chomp ($last_branch = <F>);
+ $last_branch = basename($last_branch);
+ close(F);
unless($last_branch) {
warn "Cannot read the last branch name: $! -- assuming 'master'\n";
$last_branch = "master";
@@ -766,8 +770,7 @@ if($orig_branch) {
print "DONE; creating $orig_branch branch\n" if $opt_v and (not defined $opt_l or $opt_l > 0);
system("cp","$git_dir/refs/heads/$opt_o","$git_dir/refs/heads/master")
unless -f "$git_dir/refs/heads/master";
- unlink("$git_dir/HEAD");
- symlink("refs/heads/$orig_branch","$git_dir/HEAD");
+ system('git-update-ref', 'HEAD', "$orig_branch");
unless ($opt_i) {
system('git checkout');
die "checkout failed: $?\n" if $?;
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [QUESTION] Access to a huge GIT repository.
From: Junio C Hamano @ 2005-11-16 18:24 UTC (permalink / raw)
To: Franck; +Cc: git
In-Reply-To: <cda58cb80511160424j1acac7c6j@mail.gmail.com>
Franck <vagabon.xyz@gmail.com> writes:
> I'm trying to clone a small part of a big repository.
What Linus has already said...
This is the second time this week the issue came up, so maybe
"large bundled repository, whose users typically are interested
in only one branch" may not be so uncommon as I first expected.
An optional form of 'git-clone' that clones only from a limited
subset of branches might be useful.
The underlying network transfer program, 'git-clone-pack', can
be told to clone only specified branches. If somebody is
interested, updating the 'git-clone' wrapper to use it should
not be too hard -- obviously this needs to be done for other
transports as well, though.
^ permalink raw reply
* Sourceforge doesn't like git cvsimport
From: H. Peter Anvin @ 2005-11-16 18:01 UTC (permalink / raw)
To: Git Mailing List
die "Socket to $serv: $!\n" unless defined $s;
$s->write("BEGIN AUTH REQUEST\n$repo\n$user\n$pass\nEND AUTH REQUEST\n")
or die "Write to $serv: $!\n";
$s->flush();
my $rep = <$s>;
if($rep ne "I LOVE YOU\n") {
$rep="<unknown>" unless $rep;
die "AuthReply: $rep\n";
}
-------
: tazenda 23 ; telnet cvs.sourceforge.net 2401
Trying 66.35.250.207...
Connected to cvs.sourceforge.net.
Escape character is '^]'.
BEGIN AUTH REQUEST
/cvsroot/bochs
anonymous
END AUTH REQUEST
cvs [pserver aborted]: descramble: unknown scrambling method
Connection closed by foreign host.
^ permalink raw reply
* Re: [RFC] git email submissions
From: Jeff Garzik @ 2005-11-16 18:01 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <437B7213.2020406@zytor.com>
H. Peter Anvin wrote:
> Linus Torvalds wrote:
>
>>
>> On Wed, 16 Nov 2005, Jeff Garzik wrote:
>>
>>> For people without _any_ hosting, it would be nice to give them a
>>> method to
>>> submit some git changes via email.
>>
>>
>> Well, as long as you don't expect me to take those things..
>>
>> BK had it with "bk send"/"bk receive", I used it a couple of times and
>> refuse to do it again.
>>
>
> Personally I think it would be nice if you could do an augmented
> patchset so that the end result is the same (with the same SHA1 IDs) as
> if one had merged a pull, while still being a human-readable patchset.
> The advantage with that is that once merged it'll do the right thing on
> the author's end. I think that's pretty much my answer to Jeff's
> question :)
Agreed.
Though as a disclaimer to Linus and others, I don't plan to use this in
my own submissions to Linus. Just thinking it would be a nice thing to
have, because there are definitely users out there who don't (for
whatever reason) have git-capable hosting.
I would presume an email body would look like
overall description of changes
git log master..HEAD | git shortlog
git diff master..HEAD | diffstat -p1
git diff master..HEAD
<pack file MIME attachment>
Smarter programs would send the overall description and pack file as
"[patch 0/N]", and then post the for-review patches in separate emails
as "[patch M/N]".
Jeff
^ permalink raw reply
* Re: [RFC] git email submissions
From: H. Peter Anvin @ 2005-11-16 17:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0511160847250.13959@g5.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 16 Nov 2005, Jeff Garzik wrote:
>
>>For people without _any_ hosting, it would be nice to give them a method to
>>submit some git changes via email.
>
> Well, as long as you don't expect me to take those things..
>
> BK had it with "bk send"/"bk receive", I used it a couple of times and
> refuse to do it again.
>
Personally I think it would be nice if you could do an augmented
patchset so that the end result is the same (with the same SHA1 IDs) as
if one had merged a pull, while still being a human-readable patchset.
The advantage with that is that once merged it'll do the right thing on
the author's end. I think that's pretty much my answer to Jeff's
question :)
-hpa
^ permalink raw reply
* Disallow empty pattern in "git grep"
From: Linus Torvalds @ 2005-11-16 17:38 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
For some reason I've done a "git grep" twice with no pattern, which is
really irritating, since it just grep everything. If I actually wanted
that, I could do "git grep ^" or something.
So add a "usage" message if the pattern is empty.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Yeah, maybe we should allow an empty pattern, and just check the number of
arguments instead. However, the argument parsing isn't set up that way, so
this was the simple and ugly approach.
So this will warn even for
git grep ""
which might be otherwise be considered legal (but stupid).
diff --git a/git-grep.sh b/git-grep.sh
index e7a35eb..44c1613 100755
--- a/git-grep.sh
+++ b/git-grep.sh
@@ -39,5 +39,9 @@ while : ; do
esac
shift
done
+[ "$pattern" ] || {
+ echo >&2 "usage: 'git grep <pattern> [pathspec*]'"
+ exit 1
+}
git-ls-files -z "${git_flags[@]}" "$@" |
xargs -0 grep "${flags[@]}" -e "$pattern"
^ permalink raw reply related
* [PATCH] Add short help to Cogito commands
From: Jonas Fonseca @ 2005-11-16 17:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051115221756.GX30496@pasky.or.cz>
Captions for all 74 Cogito options are added to the script headers on
the same line as the option being documented. The preferred syntax is
now:
# <option>:: <caption>
# <description>
The old help message (the complete user manual) is moved to --long-help
and -h and --help both will now show the short help message. Output of
cg-help <cmd> is untouched. In the progress, rewrite cg-Xlib's
print_help to use one built-in type -P instead of multiple which's.
Documentation scripts (to generate cg-manpages and the long help
messages) has been updated to ignore the option captions.
Missing description of cg-admin-ls -t option was added.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Petr Baudis <pasky@suse.cz> wrote Tue, Nov 15, 2005:
> Hi,
>
> Dear diary, on Tue, Nov 15, 2005 at 01:55:16PM CET, I got a letter
> where Jonas Fonseca <fonseca@diku.dk> said that...
> > I hope I am not the only one feeling that -h can sometimes be a little
> > too verbose when you want to have a quick overview of a Cogito command.
> > I'd like to make -h show only a short summary of the available options
> > and keep the longer help text for --help. I have attached a patch that
> > does something like this. Example:
>
> Good idea. Perhaps even make this default for --help as well and offer
> --long-help. cg-help would still default to the long help, unless -s or
> something would be passed to it.
Agree, I didn't do the cg-help -s switch. The patch is overloaded as it
is. ;)
> > - Add a special line with the caption. Since we already 'filters' the
> > help text in the script headers this could go after the '::'.
> > Example:
> >
> > # ...
> > #
> > # -r FROM_ID[..TO_ID]:: Specify revisions to diff
> > # Specify the revisions to diff using either '-r rev1
> > # ...
> >
> > So that it will be easy to remove from the --help output and from the
> > generated manpages.
> >
> > The last option is less intrusive, but does make the syntax of the
> > script headers less clean. Comments?
>
> I prefer the second option and don't think it's much less clean. I think
> it would be actually uglier the other way - strange without separating
> empty line, too long with the separating line.
It is easier to sed out too. Although it would be nice for it to "fall
back" to what ever was on the first line if somebody didn't write an
option caption. Sort of the best of both. Anyway here goes...
diff --git a/Documentation/make-cg-asciidoc b/Documentation/make-cg-asciidoc
index 7ea5c23..00e4ce7 100755
--- a/Documentation/make-cg-asciidoc
+++ b/Documentation/make-cg-asciidoc
@@ -42,7 +42,7 @@ CAPTION=$(echo "$HEADER" | head -n 1 | t
# were referenced as "`cg-command`". This way references from cg-* combos in
# code listings will be ignored.
BODY=$(echo "$HEADER" | sed '0,/^$/d' \
- | sed 's/`\(cg-[a-z-]\+\)`/gitlink:\1[1]/')
+ | sed 's/`\(cg-[a-z-]\+\)`/gitlink:\1[1]/;s/^\(-.*\)::.*/\1::/')
DESCRIPTION=
OPTIONS=
@@ -100,7 +100,10 @@ OPTIONS
$OPTIONS
-h, --help::
- Print usage help.
+ Print usage summary.
+
+--long-help::
+ Print user manual. The same as found in $TITLE.
$MISC
diff --git a/Documentation/make-cogito-asciidoc b/Documentation/make-cogito-asciidoc
index fbd88ff..3bd0e9f 100755
--- a/Documentation/make-cogito-asciidoc
+++ b/Documentation/make-cogito-asciidoc
@@ -83,7 +83,7 @@ individual commands, do e.g.
or
- cg-log --help
+ cg-log --long-help
Regular commands
~~~~~~~~~~~~~~~~
diff --git a/cg b/cg
index f501fb4..08aaf22 100755
--- a/cg
+++ b/cg
@@ -18,7 +18,7 @@
#
# OPTIONS
# -------
-# --version::
+# --version:: Show the Cogito toolkit version
# Show the version of the Cogito toolkit. Equivalent to the output
# of `cg-version`.
diff --git a/cg-Xlib b/cg-Xlib
index fa3a059..dedbb62 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -347,18 +347,41 @@ deprecated_alias()
print_help()
{
- which "cg-$1" >/dev/null 2>&1 || exit 1
+ _cg_cmd=$(type -P "cg-$2")
+ [ -n "$_cg_cmd" ] || exit 1
+
sed -n '/^USAGE=/,0s/.*"\(.*\)"/Usage: \1/p;
- /^deprecated_alias/,0s/^deprecated_alias \([^ ]*\)/\1 is the new name for/p' < $(which cg-$1)
+ /^deprecated_alias/,0s/^deprecated_alias \([^ ]*\)/\1 is the new name for/p' < "$_cg_cmd"
echo
- sed -n '3,/^$/s/^# *//p' < $(which cg-$1)
+ if [ x"$1" = xlong ]; then
+ # TODO: Reduce this to just one sed if possible.
+ sed -n '3,/^$/s/^# *//p' < "$_cg_cmd" | sed 's/^\(-.*\)::.*/\1::/'
+ exit
+ fi
+
+ echo "Options:"
+ _cg_fmt=" %-20s %s\n"
+ sed -n 's/# \(-.*\)::[^A-Za-z0-9]\(.*\)/\1\n\2/p' < "$_cg_cmd" | while read line; do
+ case "$line" in
+ -*)
+ _cg_option="$line"
+ ;;
+ *)
+ printf "$_cg_fmt" "$_cg_option" "$line"
+ ;;
+ esac
+ done
+ printf "$_cg_fmt" "-h, --help" "Print usage summary"
+ printf "$_cg_fmt" "--long-help" "Print user manual"
exit
}
for option in "$@"; do
[ x"$option" = x-- ] && break
- if [ x"$option" = x"-h" -o x"$option" = x"--help" ]; then
- print_help ${_cg_cmd##cg-}
+ if [ x"$option" = x"-h" ] || [ x"$option" = x"--help" ]; then
+ print_help short ${_cg_cmd##cg-}
+ elif [ x"$option" = x"--long-help" ]; then
+ print_help long ${_cg_cmd##cg-}
fi
done
diff --git a/cg-add b/cg-add
index fda4500..a50c0ac 100755
--- a/cg-add
+++ b/cg-add
@@ -17,11 +17,12 @@
#
# OPTIONS
# -------
-# -N::
+# -N:: Update the lowlevel cache file
# Only update the cache: do not copy the data into the object database.
# This is for special purposes when you might not actually _have_ any
# object database. This option is normally not interesting.
-# -r::
+#
+# -r:: Add files recursively
# If you pass cg-add this flag and any directory names, it will try
# to add files in those directories recursively (with regard to your
# ignore rules - see cg-status documentation for more detailed
diff --git a/cg-admin-cat b/cg-admin-cat
index 8435bf2..89016d9 100755
--- a/cg-admin-cat
+++ b/cg-admin-cat
@@ -8,7 +8,7 @@
#
# OPTIONS
# -------
-# -r TREE_ID::
+# -r TREE_ID:: Look for file in the given revision or tree
# ID of the revision or tree where to look for the file, instead of
# HEAD.
diff --git a/cg-admin-ls b/cg-admin-ls
index 57e3ffb..240d927 100755
--- a/cg-admin-ls
+++ b/cg-admin-ls
@@ -6,6 +6,13 @@
# Optionally takes a commit or tree ID as a parameter, defaulting to
# 'HEAD'.
#
+# OPTIONS
+# -------
+# -t TREE_ID:: List content of the given TREE_ID
+# List the content of the given TREE_ID.
+#
+# OUTPUT FORMAT
+# -------------
# Each line in the output has the following format:
#
# <mode> <type> <sha1> <name>
diff --git a/cg-admin-setuprepo b/cg-admin-setuprepo
index 5affa7f..34d387f 100755
--- a/cg-admin-setuprepo
+++ b/cg-admin-setuprepo
@@ -28,7 +28,7 @@
#
# OPTIONS
# -------
-# -g GROUP::
+# -g GROUP:: Specify group ownership for the repository
# Name of the UNIX group covering the users authorized to push into
# the repository. If unspecified, only you (who ran this command) will
# have write (push) access.
diff --git a/cg-admin-uncommit b/cg-admin-uncommit
index 9357394..cc67ec2 100755
--- a/cg-admin-uncommit
+++ b/cg-admin-uncommit
@@ -11,7 +11,7 @@
#
# OPTIONS
# -------
-# -t::
+# -t:: Restore the working copy of the previous commit
# This optional parameter makes `cg-admin-uncommit` to roll back
# the tree as well to the previous commit. Without this option
# (by default) 'Cogito' keeps the tree in its current state,
diff --git a/cg-clean b/cg-clean
index 1cc1ae8..6e2d1df 100755
--- a/cg-clean
+++ b/cg-clean
@@ -9,16 +9,16 @@
#
# OPTIONS
# -------
-# -d::
+# -d:: Clean directories
# Also clean directories and their contents.
#
-# -D::
+# -D:: Clean directories more thoroughly
# Same as -d but try harder (change permissions first).
#
-# -q::
+# -q:: Silence progress reporting
# Quiet - don't report what's being cleaned.
#
-# -x::
+# -x:: Clean files ignored by cg-status
# Also clean files ignored by cg-status, such as object files.
USAGE="cg-clean [-d] [-D] [-q] [-x]"
diff --git a/cg-clone b/cg-clone
index c677ecd..f9f3f22 100755
--- a/cg-clone
+++ b/cg-clone
@@ -13,7 +13,7 @@
#
# OPTIONS
# -------
-# -l::
+# -l:: Symlink the object database when cloning locally
# Symlink the object database when cloning locally, instead of
# hardlinking all the objects. This is suitable for very fast
# cloning of arbitrarily big repositories, but might be a trouble
@@ -23,7 +23,8 @@
# as well. The choice is yours.
# Note that you MUST NOT prune repository containing a symlink
# or being symlinked to.
-# -s::
+#
+# -s:: Clone into the current directory
# Clone in the current directory instead of creating a new one.
# Specifying both -s and a destination directory makes no sense.
diff --git a/cg-commit b/cg-commit
index 33bb17d..f413396 100755
--- a/cg-commit
+++ b/cg-commit
@@ -17,44 +17,44 @@
#
# OPTIONS
# -------
-# -c COMMIT_ID::
+# -c COMMIT_ID:: Copy author info and commit message from COMMIT_ID
# Copy the commit from a given commit ID (that is the author information
# and the commit message - NOT committer information). This option
# is typically used when replaying commits from one lineage or
# repository to another.
#
-# -C::
+# -C:: Ignore cache
# Make `cg-commit` ignore the cache and just commit the thing as-is.
# Note, this is used internally by 'Cogito' when merging, and it is
# also useful when you are performing the initial commit manually. This
# option does not make sense when files are given on the command line.
#
-# -m MESSAGE::
+# -m MESSAGE:: Specify commit message
# Specify the commit message, which is used instead of starting
# up an editor (if the input is not `stdin`, the input is appended
# after all the '-m' messages). Multiple '-m' parameters are appended
# to a single commit message, each as separate paragraph.
#
-# -e::
+# -e:: Force message editing of messages given with -m
# Force the editor to be brought up even when '-m' parameters were
# passed to `cg-commit`.
#
-# -E::
+# -E:: Force message editing and commit the result
# Force the editor to be brought up and do the commit even if
# the default commit message is not changed.
#
-# -f::
+# -f:: Force commit when no changes has been made
# Force the commit even when there's "nothing to commit", that is
# the tree is the same as the last time you committed, no changes
# happened.
#
-# -N::
+# -N:: Only update the cache
# Don't add the files to the object database, just update the caches
# and the commit information. This is for special purposes when you
# might not actually _have_ any object database. This option is
# normally not interesting.
#
-# -q::
+# -q:: Be very very quiet
# Be quiet in case there's "nothing to commit", and silently exit
# returning success. In a sense, this is the opposite to '-f'.
#
diff --git a/cg-diff b/cg-diff
index 628be53..0572170 100755
--- a/cg-diff
+++ b/cg-diff
@@ -10,26 +10,26 @@
#
# OPTIONS
# -------
-# -c::
+# -c:: Colorize
# Colorize the diff output
#
-# -p::
+# -p:: Use ID parent
# Show diff to the parent of the current commit (or the commit
# specified by the -r parameter).
#
-# -s::
+# -s:: Summarize and show diff stat
# Summarize the diff by showing a histogram for removed and added
# lines (similar to the output of diffstat(1)) and information
# about added and renamed files and mode changes.
#
-# -r FROM_ID[..TO_ID]::
+# -r FROM_ID[..TO_ID]:: Limit to revision range
# Specify the revisions to diff using either '-r rev1..rev2' or
# '-r rev1 -r rev2'. If no revision is specified, the current
# working tree is implied. Note that no revision is different from
# empty revision which means '-r rev..' compares between 'rev' and
# 'HEAD', while '-r rev' compares between 'rev' and working tree.
#
-# -m::
+# -m:: Base the diff at the merge base
# Base the diff at the merge base of the -r arguments (defaulting
# to HEAD and origin).
#
diff --git a/cg-fetch b/cg-fetch
index c406c9a..5a2039f 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -25,10 +25,10 @@
#
# OPTIONS
# -------
-# -f::
+# -f:: Force the complete fetch even if the heads are the same.
# Force the complete fetch even if the heads are the same.
#
-# -v::
+# -v:: Enable verbosity
# Display more verbose output.
#
# ENVIRONMENT
diff --git a/cg-help b/cg-help
index ddec1b9..6ba7657 100755
--- a/cg-help
+++ b/cg-help
@@ -13,7 +13,7 @@
#
# OPTIONS
# -------
-# -c::
+# -c:: Colorize
# Colorize the output.
USAGE="cg-help [-c] [cg-COMMAND | COMMAND]"
@@ -33,6 +33,7 @@ setup_colors()
local copyright="$(tput setaf 4)"
apply_colors="
+ s/^\(-.*\)::.*/$desclist\1$color_none:/
s/^\(.*\)::/$desclist\1$color_none:/
s/\`\(cg-[a-z-]*\)\`/$cgcmd\1$color_none/g
s/\`\([^\`]*\)\`/$codesnippet&$color_none/g
@@ -90,7 +91,7 @@ elif [ "$ARGS" = "tag" ]; then
exit
elif [ "$ARGS" ]; then
cmd=$(echo "${ARGS[0]}" | sed 's/^cg-//')
- print_help $cmd | colorize
+ print_help long $cmd | colorize
[ "${PIPESTATUS[0]}" -eq 0 ] && exit
echo "cg-help: no help available for command \"${ARGS[0]}\""
echo "Call cg-help without any arguments for the list of available commands"
@@ -126,6 +127,6 @@ These expressions can be used interchang
For details on individual commands, do e.g.:
cg-help cg-log
- cg-log --help
+ cg-log --long-help
(both variants are equivalent)
__END__
diff --git a/cg-init b/cg-init
index 0ee264e..a0a7372 100755
--- a/cg-init
+++ b/cg-init
@@ -13,22 +13,22 @@
#
# OPTIONS
# -------
-# -e EXCLUDEPATTERN::
+# -e EXCLUDEPATTERN:: Ignore files matching EXCLUDEPATTERN
# Ignore files matching this pattern when importing files for the
# initial commit. Note that if you are importing any .gitignore
# files, they will be considered as well. If you want to make
# en even more custom choice of files to be imported, use the -I
# parameter and add and perform the initial commit manually.
#
-# -I::
+# -I:: No initial commit
# Do not perform the initial commit. You can perform the initial commit
# manually later, but you will need to pass cg-commit the -C parameter.
#
-# -m MESSAGE::
+# -m MESSAGE:: Specify initial commit message
# Specify the commit message for the initial commit. See `cg-commit`
# documentation for details.
#
-# -N::
+# -N:: Only update the cache
# Only update the cache: do not copy the data into the object database.
# This is for special purposes when you might not actually _have_ any
# object database. This option is normally not interesting.
diff --git a/cg-log b/cg-log
index 710ce7b..89fe063 100755
--- a/cg-log
+++ b/cg-log
@@ -13,7 +13,7 @@
# Arguments not interpreted as options will be interpreted as filenames;
# cg-log then displays only changes in those files.
#
-# -c::
+# -c:: Colorize
# Colorize the output. The used colors are listed below together
# with information about which log output (summary, full or both)
# they apply to:
@@ -26,10 +26,10 @@
# - `date`: 'green' (summary)
# - `trim_mark`: 'magenta' (summary)
#
-# -f::
+# -f:: List affected files
# List affected files. (No effect when passed along `-s`.)
#
-# -r FROM_ID[..TO_ID]::
+# -r FROM_ID[..TO_ID]:: Limit to a set of revisions
# Limit the log information to a set of revisions using either
# '-r FROM_ID[..TO_ID]' or '-r FROM_ID -r TO_ID'. In both cases the
# option expects IDs which resolve to commits and will include the
@@ -37,31 +37,31 @@
# to the initial commit is shown. If no revisions is specified,
# the log information starting from 'HEAD' will be shown.
#
-# -d DATE::
+# -d DATE:: Limit to revisions newer than given DATE
# Limit the log information to revisions newer than given DATE,
# and on second time further restrain it to revisions older than
# given date. Therefore, '-d "2 days ago" -d "yesterday"' will
# show all the commits from the day before yesterday.
#
-# -m::
+# -m:: End the log at the merge base of the revision set
# End the log listing at the merge base of the -r arguments
# (defaulting to HEAD and origin).
#
-# -M, --no-merges::
+# -M, --no-merges:: Ignore merge commits
# Don't display merge commits in the log.
#
-# -s::
+# -s:: Summarize the log entries
# Show a one line summary for each log entry. The summary contains
# information about the commit date, the author, the first line
# of the commit log and the commit ID. Long author names and commit
# IDs are trimmed and marked with an ending tilde (~).
#
-# --summary::
+# --summary:: Group commits by title
# Generate the changes summary, listing the commit titles grouped
# by their author. This is also known as a "shortlog", suitable
# e.g. for contribution summaries of announcements.
#
-# -uUSERNAME::
+# -uUSERNAME:: Limit to commit where author/committer matches USERNAME
# List only commits where author or committer contains 'USERNAME'.
# The search for 'USERNAME' is case-insensitive.
#
diff --git a/cg-merge b/cg-merge
index 0e6066d..1087951 100755
--- a/cg-merge
+++ b/cg-merge
@@ -34,17 +34,17 @@
#
# OPTIONS
# -------
-# -b BASE_COMMIT::
+# -b BASE_COMMIT:: Specify the base commit for the merge
# Parameter specifies the base commit for the merge. Otherwise, the
# least common ancestor is automatically selected.
#
-# -c::
+# -c:: Disable autocommitting
# Parameter specifies that you want to have tree merge never
# autocommitted, but want to review and commit it manually. This will
# basically make cg-merge always behave like there were conflicts
# during the merge.
#
-# -j::
+# -j:: Join current branch with BRANCH_NAME
# Join the current branch and BRANCH_NAME together. This makes sense
# when the branches have no common history, meaning they are actually
# not branches related at all as far as GIT is concerned. Merging such
@@ -52,7 +52,7 @@
# you do not want; but equally likely, you may actually WANT to join
# the projects together, which is what this option does.
#
-# --squash::
+# --squash:: Use "squash" merge to record pending commits as a single merge commit
# "Squash" merge - condense all the to-be-merged commits to a single
# merge commit. This means "throw away history of the branch I'm
# merging", essentially like in CVS or SVN, with the same problem -
diff --git a/cg-mkpatch b/cg-mkpatch
index afaeff1..8982056 100755
--- a/cg-mkpatch
+++ b/cg-mkpatch
@@ -13,14 +13,14 @@
#
# OPTIONS
# -------
-# -d DIRNAME::
+# -d DIRNAME:: Create patches in the DIRNAME directory
# Split the patches to separate files with their names in the
# format "%02d.patch", created in directory DIRNAME (will be
# created if non-existent). Note that this makes sense only
# when generating patch series, that is when you use the -r
# argument.
#
-# -f FORMAT::
+# -f FORMAT:: Specify patch file name format
# Format string used for generating the patch filename when
# outputting the split-out patches (that is, passed the -d
# option). This is by default "%s/%02d-%s.patch". The first %s
@@ -28,11 +28,11 @@
# sequence number. The last %s is mangled first line of the
# commit message - kind of patch title.
#
-# -m::
+# -m:: Base the diff at the merge base
# Base the patches at the merge base of the -r arguments
# (defaulting to HEAD and origin).
#
-# -r FROM_ID[..TO_ID]::
+# -r FROM_ID[..TO_ID]:: Limit to revision range
# Specify a set of commits to make patches from using either
# '-r FROM_ID[..TO_ID]' or '-r FROM_ID -r TO_ID'. In both cases the
# option expects IDs which resolve to commits and will include the
@@ -40,7 +40,7 @@
# from 'FROM_ID' to the initial commit will be generated. If no
# `-r` option is given the commit ID defaults to 'HEAD'.
#
-# -s::
+# -s:: Omit patch header
# Specify whether to print a short version of the patch without
# a patch header with meta info such as author and committer.
#
diff --git a/cg-object-id b/cg-object-id
index fde2e2b..f2cb54e 100755
--- a/cg-object-id
+++ b/cg-object-id
@@ -8,22 +8,22 @@
#
# OPTIONS
# -------
-# -c::
+# -c:: Get commit ID
# Get ID of commit matching the object ID (error out if it is not
# a commit). This is the default if you do not pass any parameter
# as well, but that is only for the human usage. For clarity, all
# scripted usage of cg-object-id should use -c explicitly if it
# wants a commit.
#
-# -n::
+# -n:: Disable object type checking
# Normalize only - don't check the object type.
#
-# -p::
+# -p:: Get parent commit ID(s)
# Get ID of the first parent commit of a given revision or HEAD.
# NOTE: Multiple SHA1s separated by newlines will be returned for
# commits with multiple parents.
#
-# -t::
+# -t:: Get tree ID
# Get ID of tree associated with given commit or HEAD.
#
# OBJECT_ID::
diff --git a/cg-patch b/cg-patch
index 153376e..d567b8e 100755
--- a/cg-patch
+++ b/cg-patch
@@ -12,7 +12,7 @@
#
# OPTIONS
# -------
-# -R::
+# -R:: Apply in reverse
# Applies the patch in reverse (therefore effectively unapplies it)
#
# Takes the diff on stdin.
diff --git a/cg-push b/cg-push
index d63fb65..b4361e3 100755
--- a/cg-push
+++ b/cg-push
@@ -14,7 +14,7 @@
#
# OPTIONS
# -------
-# -t TAG::
+# -t TAG:: Push the given TAG
# Tells cg-push to also push the given tag. Note that in the
# future, cg-push should push tags automatically. Also note
# that even if you pass `cg-push` the '-t' arguments, your
diff --git a/cg-reset b/cg-reset
index f2e92eb..eb25fb1 100755
--- a/cg-reset
+++ b/cg-reset
@@ -16,7 +16,7 @@
#
# OPTIONS
# -------
-# --adds-removes::
+# --adds-removes:: Only reset info about added and removed files
# Reset ONLY the so-called "index" file. This effectively means that
# any adds and removes you did will be unrecorded (but if you removed
# the file physically as well, that will not be undone - run
diff --git a/cg-restore b/cg-restore
index f864b64..348f552 100755
--- a/cg-restore
+++ b/cg-restore
@@ -23,12 +23,13 @@
#
# OPTIONS
# -------
-# -f::
+# -f:: Undo local changes since last commit
# Restore even locally modified files to the version as of
# the last commit. Take care!
-# -r COMMIT_ID::
-# -r TREE_ID::
-# -r BLOB_ID::
+#
+# -r COMMIT_ID:: Restore files to given COMMIT_ID
+# -r TREE_ID:: Restore files to given TREE_ID
+# -r BLOB_ID:: Restore files to given BLOB_ID
# Restore the file to the state appropriate to the given ID.
# The list of files to recover is mandatory in this case.
diff --git a/cg-rm b/cg-rm
index 4b7e5ee..2fea342 100755
--- a/cg-rm
+++ b/cg-rm
@@ -8,9 +8,10 @@
#
# OPTIONS
# -------
-# -f::
+# -f:: Force removal of the physical files
# Also delete the files from the tree physically.
-# -n::
+#
+# -n:: Keep the physical files
# Do not delete the files from the tree physically, if they are
# still there. So it effectively just makes Cogito to stop caring
# about the file. This is the default.
diff --git a/cg-status b/cg-status
index 2cb86be..61c41c8 100755
--- a/cg-status
+++ b/cg-status
@@ -34,21 +34,21 @@
# If neither -g or -w is passed, both is shown; otherwise, only the
# corresponding parts are shown.
#
-# -g::
+# -g:: Show the GIT repository information
# Show the GIT repository information.
#
-# -n::
+# -n:: Do not show status flags
# Do not show status flags. This is probably useful only when you filter
# the flags for a single specific flag using the '-s' option.
#
-# -s STATUS::
+# -s STATUS:: Limit to files matching the STATUS flags
# Show only files with the given status flag, e.g. '-s D'. You can list
# multiple flags ('-s MmA') to filter for all of them.
#
-# -w::
+# -w:: Show working files
# Show the working tree file list.
#
-# -x::
+# -x:: Disable file exclusion
# Don't exclude any files from listing.
#
# DIRPATH::
diff --git a/cg-switch b/cg-switch
index 4f7994b..4ab160c 100755
--- a/cg-switch
+++ b/cg-switch
@@ -11,19 +11,19 @@
#
# OPTIONS
# -------
-# -f::
+# -f:: Enable overwriting of existing branches
# Force the branch's head pointer update even if the branch
# already exists. WARNING: The pointer to the original contents
# of the branch will be lost! The contents itself will not be
# deleted, `git-fsck-objects --unreachable` might help you to
# find it.
#
-# -n::
+# -n:: No switch; only create and update the branch
# Do not switch your current branch to the given branch. This
# will make cg-switch to only create or update the branch, but
# leave your working copy alone.
#
-# -r COMMIT_ID::
+# -r COMMIT_ID:: Branch off the given COMMIT_ID
# Point the branch at the given commit. Defaults to the current
# commit when creating a new branch; when switching to an existing
# branch, the branch pointer is not modified if no '-r' is passed.
diff --git a/cg-tag b/cg-tag
index 00ce8d4..da4f2d5 100755
--- a/cg-tag
+++ b/cg-tag
@@ -13,12 +13,15 @@
#
# OPTIONS
# -------
-# -d DESCRIPTION::
+# -d DESCRIPTION:: Specify tag description
# Description of the tag.
-# -k KEYNAME::
+#
+# -k KEYNAME:: Use the given KEYNAME to sign the tag
# Use the given key to sign the tag, instead of the default one.
-# -s::
+#
+# -s:: Sign the tag by your private key using GPG.
# Sign the tag by your private key using GPG.
+#
# OBJECT_ID::
# This is most usually the ID of the commit to tag. Tagging
# other objects than commits is possible, but rather "unusual".
diff --git a/cg-update b/cg-update
index aaed291..39b1949 100755
--- a/cg-update
+++ b/cg-update
@@ -18,10 +18,10 @@
#
# OPTIONS
# -------
-# -f::
+# -f:: Force the complete fetch even if the heads are the same.
# Force the complete fetch even if the heads are the same.
#
-# --squash::
+# --squash:: Use "squash" merge to record pending commits as a single merge commit
# "Squash" merge - condense all the to-be-merged commits to a single
# merge commit. This is not to be used lightly; see the cg-merge
# documenation for further details.
--
Jonas Fonseca
^ permalink raw reply related
* recent patch breaks the build ?
From: Andrew Wozniak @ 2005-11-16 17:17 UTC (permalink / raw)
To: git
Hello,
Have just started using git for u-boot related development. After
downloading git-snapshot-20051116 tarball and attempting a build under
RH7.2, I get the following failure:
gcc -o http-fetch.o -c -g -O2 -Wall -DSHA1_HEADER='<openssl/sha.h>'
http-fetch.c
http-fetch.c: In function `fetch_alternates':
http-fetch.c:911: warning: implicit declaration of function
`curl_multi_perform'
http-fetch.c:911: `curlm' undeclared (first use in this function)
<snip>
It appears that a recent patch "Fix for multiple alternates requests in
http" references curlm without the necessary #ifdef USE_CURL_MULTI
I'm not that familiar with the git architecture and codebase, so any
suggestions for a workaround are much appreciated.
Thank you
^ permalink raw reply
* Re: [RFC] git email submissions
From: Linus Torvalds @ 2005-11-16 16:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <437B4472.1080401@pobox.com>
On Wed, 16 Nov 2005, Jeff Garzik wrote:
>
> For people without _any_ hosting, it would be nice to give them a method to
> submit some git changes via email.
Well, as long as you don't expect me to take those things..
BK had it with "bk send"/"bk receive", I used it a couple of times and
refuse to do it again.
> - what form would the emails take? MIME-attach a .pack file, plus a
> GPG-signed sha1sum in a separate attachment?
Yes, that sounds sane. You also need to specify the head(s) of the
pack-file (maybe that's what you meant by the GPG-signed sha1sum).
> - what's the easiest user interface for selecting the changes? for my usage,
> it would be
>
> GIT_GPG_AUTHOR=jgarzik... \
> GIT_DEF_HEADERS=./email.headers \
> git-mkmail --sign master..upstream > email.rfc822
> Enter GPG passphrase:
Sounds sane.
> - what user interface does a kernel maintainer use, to merge changes submitted
> using this method?
As long as it's not me, I'd suggest doing something like
git getmail <path-to-git-repo> < raw-email
Why? Because a lot of email clients know how to pipe the email to a
program, so you might use this from within the email client by just doing
| git getmail myrepo
and please also have an option to make it do the equivalent of a "fetch"
rather than a "pull" (ie to "get" it as a separate branch without the
merge):
| git getmail -b garzik myrepo
or something.
More importantly, the "git-getmail" (or whatever) scipt must absolutely be
anal and verify that the pack is "complete". Since you don't have the git
protocol to do the interactive "find the common parent" thing, it's easy
for the other end to specify a commit you don't actually have, and make a
pack that is perfectly valid, but which wouldn't have full connectivity to
what the person that pulls is trying to get.
The minimal thing to do is to run a "git-fsck-cache" after the fetch and
before the merge (if any). If the destination repo is regularly packed, it
should even be fast (for example, since I repack my repo pretty regularly,
a non-full fsck usually takes just a fraction of a second for me).
Linus
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Linus Torvalds @ 2005-11-16 16:46 UTC (permalink / raw)
To: Franck; +Cc: Git Mailing List
In-Reply-To: <cda58cb80511160424j1acac7c6j@mail.gmail.com>
On Wed, 16 Nov 2005, Franck wrote:
>
> I'm trying to clone a small part of a big repository. This repository
> contains several branchs that are useless for me. Actually this
> repository is the linux-mips one, and branchs are used to track each
> kernel minor version. That is to say it contains 4 branchs which are
> linux-2.0, linux-2.2, linux-2.4 and master (linux-2.6).
>
> I'd like to clone this repository without grabbing linux-2.0,
> linux-2.2, linux-2.4 branchs. I tried several things like:
>
> $ git init-db
> $ git fetch rsync://ftp.linux-mips.org/git/linux.git master
First off, "rsync://" will never do what you want. It uses rsync
(surprised surprise) to grab the objects, so since it has no clue what the
objects are, it has no choice but to just grab them all.
> But all tries download every objects of each branchs. I believe that's
> because of (a) the protocol used to access of the remote repo
Yes. Note that ftp.linux-mips.org does run the git daemon, so you can use
"git://" instead of "rsync://" (that's how I pull from them when I sync).
> (b) the
> master branch has been created from linux-2.4 branch so its first
> commit object contains a branch 2.4 commit obj as parent object (let's
> call it the "father" object). Is that correct ?
Not having looked at that particular repo, I don't know. git can do it
either way - either one long common history, or branches with totally
unrelated histories.
The fact that _some_ of the linux-mips repositories are based on mine
makes me suspect that all their 2.6-based ones are rooted like mine is,
but that may or may not be true.
Just try your above command line with "git://" instead.
(NOTE! Doing a full clone like the above is pretty expensive with git for
the server side, so it might take a while before it starts feeding you
stuff if it is under heavy load)
> So I downloaded the whole thing, and try to remove "father" object and
> right after run a 'git prune'. But unfortunately I can't find it
> anywhere in .git directory. I did:
>
> $ git-verify-pack < .git/objects/pack/*.idx
> $ git-unpack-objects < .git/objects/pack/*.pack
>
> But I can't find "father object" anywhere in .git/objects directory.
> Still it's referenced by .git/objects/pack/pack-....idx file.
>
> Can anybody give me some advices ?
If you want to get rid of other branches, do:
# Remove the branches
git branch -D linux-2.0
git branch -D linux-2.2
git branch -D linux-2.4
.. whatever other branches you don't want ..
# Repack the repo
git repack -a -d
# Prune it all down
git prune-packed
git prune
and you should have a nice single pack that only contains the branch(es)
that you're interested in.
Linus
^ permalink raw reply
* Re: [RFC] git email submissions
From: Petr Baudis @ 2005-11-16 14:51 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <437B4472.1080401@pobox.com>
Dear diary, on Wed, Nov 16, 2005 at 03:38:42PM CET, I got a letter
where Jeff Garzik <jgarzik@pobox.com> said that...
> For people without _any_ hosting, it would be nice to give them a method
> to submit some git changes via email.
What kind of people have no hosting whatsoever? There is plenty of free
web hosting sites, and that should be enough...?
> - is this all pointless, since the submittor could just email patches?
> [IMO no, git trees are better merges than emailed patches]
Couldn't you just look at the applies-to string of the first patch in
the series, branch up from that commit, and at the end of the series do
the merge?
No special tool required, just a bit smarter applier.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [RFC] git email submissions
From: Jeff Garzik @ 2005-11-16 14:38 UTC (permalink / raw)
To: Git Mailing List
For people without _any_ hosting, it would be nice to give them a method
to submit some git changes via email.
It seems like most of the necessary stuff is already present in git to
bundle up a set of changes. The open questions in my mind are
- what form would the emails take? MIME-attach a .pack file, plus a
GPG-signed sha1sum in a separate attachment?
- what's the easiest user interface for selecting the changes? for my
usage, it would be
GIT_GPG_AUTHOR=jgarzik... \
GIT_DEF_HEADERS=./email.headers \
git-mkmail --sign master..upstream > email.rfc822
Enter GPG passphrase:
- what user interface does a kernel maintainer use, to merge changes
submitted using this method?
- is this all pointless, since the submittor could just email patches?
[IMO no, git trees are better merges than emailed patches]
Overall, I was thinking it would be nice to have some way to safely
transmit a small part of a git tree, including all history information,
since its easier to merge git trees than patches.
And for someone without the resources to obtain hosting, email may be
the only way to publish a git sub-tree.
Jeff
^ 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