* Re: Git graph with branch labels for all paths in text environment
From: Jonas Fonseca @ 2009-11-21 17:50 UTC (permalink / raw)
To: rhlee; +Cc: git
In-Reply-To: <1258373038892-4011651.post@n2.nabble.com>
On Mon, Nov 16, 2009 at 07:03, rhlee <richard@webdezign.co.uk> wrote:
> Is there anyway to to view a text based git grah that shows all paths with
> the branch labels? Like a on gitk but ncurses based?
>
> [...]
> I can get all branch labels in tig, but only for the current branch.
You can browse all branches by using: tig --all
However, the graph drawing is rather poor for complex git histories.
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-21 17:43 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
Some MTAs make smart decisions based on the 'from' envelope (i.e. msmtp)
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
git-send-email.perl | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..92bf491 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -140,6 +140,7 @@ my (@to,@cc,@initial_cc,@bcclist,@xh,
$author,$sender,$smtp_authpass,$annotate,$compose,$time);
my $envelope_sender;
+my $envelope_from;
# Example reply to:
#$initial_reply_to = ''; #<20050203173208.GA23964@foobar.com>';
@@ -208,6 +209,7 @@ my %config_settings = (
"aliasesfile" => \@alias_files,
"suppresscc" => \@suppress_cc,
"envelopesender" => \$envelope_sender,
+ "envelopefrom" => \$envelope_from,
"multiedit" => \$multiedit,
"confirm" => \$confirm,
"from" => \$sender,
@@ -265,6 +267,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"confirm=s" => \$confirm,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
+ "envelope-from" => \$envelope_from,
"thread!" => \$thread,
"validate!" => \$validate,
"format-patch!" => \$format_patch,
@@ -861,10 +864,13 @@ X-Mailer: git-send-email $gitversion
my @sendmail_parameters = ('-i', @recipients);
my $raw_from = $sanitized_sender;
- $raw_from = $envelope_sender if (defined $envelope_sender);
+ if (defined $envelope_sender) {
+ $raw_from = $envelope_sender;
+ $envelope_from = 1;
+ }
$raw_from = extract_valid_address($raw_from);
unshift (@sendmail_parameters,
- '-f', $raw_from) if(defined $envelope_sender);
+ '-f', $raw_from) if(defined $envelope_from);
if ($needs_confirm && !$dry_run) {
print "\n$header\n";
--
1.6.5.3.1.ga9388c
^ permalink raw reply related
* Re: How to make git diff-* ignore some patterns?
From: Michael J Gruber @ 2009-11-21 17:31 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: Git Mailing List
In-Reply-To: <4B0817EE.1040000@dirk.my1.cc>
Dirk Süsserott venit, vidit, dixit 21.11.2009 17:40:
> Hi list,
>
> is there a way to tell "git diff-index" to ignore some special patterns,
> such that /^-- Dump completed on .*$/ is NOT recognized as a difference
> and "git diff-index" returns 0 if that's the only difference?
>
> -- Dirk
>
> <Background>
> I have a mySQL database which I backup daily using mysqldump (cronjob).
> The result is a text file (*.sql) with all the "create" and "insert"
> statements and some metadata.
> I used to use tar and gzip to backup these files and got a huge
> collection of backups in the last tree years (500+ MB).
> Then I switched to Git and recorded only the diffs between day X and day
> X-1. My repository shrunk to 16 MB for the very same data, which was great!
>
> My database doesn't change every day, but I backup it anway and store
> the backup files with Git and a cronjob. It does:
>
> ---------------
> mysqldump ... -r <backupfile> # that's the output file ;-)
> git add <backupfile>
> if ! git diff-index --quiet HEAD --; then
> git commit -m "Backup of <database> at <timestamp>"
> fi
> ---------------
>
> This way, a new commit is only done when the backupfile has changed. So
> far, so perfect.
> A few days ago my web hoster (where the database actually resides)
> changed the mySQL version.
> mysqldump now writes "-- Dump completed on <timestamp>" to the file and
> Git correctly recognizes this as a change and my script creates a new
> commit. Every day, even if only that line has changed.
>
> I'd like to skip these commits if only the "Dump completed" line has
> changed.
> </Background>
Is the dump guaranteed to be in a specific order? If yes then this
procedure makes sense. (pdfs etc. are problematic because of reordering.)
You can either egrep -v through the output of git diff-index, or define
a diff driver: set an attribute, say "dumpdiff", for dump files (see
gitattributes) and define diff driver as
git config diff.dumpdiff.textconv = dumpdiff.sh
where dumpdiff.sh is "egrep -v ...". You may need to call diff-index
with --ext-diff. I haven't tried, though ;)
Cheers,
Michael
^ permalink raw reply
* How to make git diff-* ignore some patterns?
From: Dirk Süsserott @ 2009-11-21 16:40 UTC (permalink / raw)
To: Git Mailing List
Hi list,
is there a way to tell "git diff-index" to ignore some special patterns,
such that /^-- Dump completed on .*$/ is NOT recognized as a difference
and "git diff-index" returns 0 if that's the only difference?
-- Dirk
<Background>
I have a mySQL database which I backup daily using mysqldump (cronjob).
The result is a text file (*.sql) with all the "create" and "insert"
statements and some metadata.
I used to use tar and gzip to backup these files and got a huge
collection of backups in the last tree years (500+ MB).
Then I switched to Git and recorded only the diffs between day X and day
X-1. My repository shrunk to 16 MB for the very same data, which was great!
My database doesn't change every day, but I backup it anway and store
the backup files with Git and a cronjob. It does:
---------------
mysqldump ... -r <backupfile> # that's the output file ;-)
git add <backupfile>
if ! git diff-index --quiet HEAD --; then
git commit -m "Backup of <database> at <timestamp>"
fi
---------------
This way, a new commit is only done when the backupfile has changed. So
far, so perfect.
A few days ago my web hoster (where the database actually resides)
changed the mySQL version.
mysqldump now writes "-- Dump completed on <timestamp>" to the file and
Git correctly recognizes this as a change and my script creates a new
commit. Every day, even if only that line has changed.
I'd like to skip these commits if only the "Dump completed" line has
changed.
</Background>
^ permalink raw reply
* Re: Help creating script that mass-pulls Git(Hub) repos
From: Kumar Appaiah @ 2009-11-21 15:18 UTC (permalink / raw)
To: git
In-Reply-To: <dc191bcd0911210225k3cf946c6k54f1287c818af5a8@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 273 bytes --]
On Sat, Nov 21, 2009 at 11:25:20AM +0100, Tony Maserati wrote:
> Hi,
>
> I got a bunch of repos I've cloned off GitHub and I'm looking for the
> best way to keep them all up to date.
Would mr help?
http://kitenet.net/~joey/code/mr/
Kumar
--
Kumar Appaiah
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] jn/gitweb-blame fixes
From: Jakub Narebski @ 2009-11-21 14:56 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <200911210132.44649.jnareb@gmail.com>
On Sat, 21 Nov 2009, Jakub Narebski wrote:
> * Testing it with IE8 (Internet Explorer 8.0.6001.18702) page loading stops
> at 0%, at the very beginning on startBlame() function
>
> IE8 shows that it finds the following errors:
>
> * "firstChild is null or not an object"
> line: 565, char:4
>
> a_sha1.firstChild.data = commit.sha1.substr(0, 8);
>
> It might be caused by the fact that firstChild for this case should be
> text node containing of pure whitespace:
> <a href=""> </a>
> Perhaps IE8 simplifies it in "compatibility view" mode
This bug (be it in gitweb.js or in IE8) is fixed by the following patch:
-- 8< --
diff --git i/gitweb/gitweb.js w/gitweb/gitweb.js
index 200ec5a..c1e425c 100644
--- i/gitweb/gitweb.js
+++ w/gitweb/gitweb.js
@@ -562,7 +562,12 @@ function handleLine(commit, group) {
td_sha1.rowSpan = group.numlines;
a_sha1.href = projectUrl + 'a=commit;h=' + commit.sha1;
- a_sha1.firstChild.data = commit.sha1.substr(0, 8);
+ if (a_sha1.firstChild) {
+ a_sha1.firstChild.data = commit.sha1.substr(0, 8);
+ } else {
+ a_sha1.appendChild(
+ document.createTextNode(commit.sha1.substr(0, 8)));
+ }
if (group.numlines >= 2) {
var fragment = document.createDocumentFragment();
var br = document.createElement("br");
-- >8 --
>
> * "Unspecified error" (twice)
> line: 777, char:2
>
> if (xhr.readyState === 3 && xhr.status !== 200) {
> return;
> }
>
> I don't know what might be the source of error here; I suspect that the
> error position mentioned by IE8 is bogus.
But I have no idea how to fix this. "Unspecified error" isn't very
helpful...
--
Jakub Narebski
Poland
^ permalink raw reply related
* Re: [ANNOUNCE] tig-0.15
From: Jonas Fonseca @ 2009-11-21 13:59 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091121035858.GC3919@debian.b2j>
On Fri, Nov 20, 2009 at 22:58, bill lam <cbill.lam@gmail.com> wrote:
> On Fri, 20 Nov 2009, Jonas Fonseca wrote:
>> On Fri, Nov 20, 2009 at 11:25, bill lam <cbill.lam@gmail.com> wrote:
>> > On Fri, 20 Nov 2009, Jonas Fonseca wrote:
>> >> install-release-doc-man:
>> >> for doc in $(MANDOC); do \
>> >> git checkout origin/release $$doc; \
>> >> done
>> >> $(MAKE) install-doc-man
>> >
>> > Thanks it works. Could you also commit this to git?
>>
>> Done, but using git-checkout-index ...
> the line
> git read-tree release
> raised error perhaps I didn't checkout a branch for it, replacing it
> with
> git read-tree origin/relase
> or
> git read-tree remotes/origin/relase
>
> seems working.
Ah, stupid me.
> Another question, while it can open a file with editor in tree-view, I
> cannot find in tigmanual how to directly save a file. Any idea?
There is no such action/keybinding. I guess it should be easy to
extend the current functionality to query for a file name and save to
that instead of a temporary file.
--
Jonas Fonseca
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Sitaram Chamarty @ 2009-11-21 13:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Intland Software, git
In-Reply-To: <20091120074702.GW12890@machine.or.cz>
On Fri, Nov 20, 2009 at 1:17 PM, Petr Baudis <pasky@suse.cz> wrote:
> I brought Gitosis/Gitolite up because I got the impression that MR was
> marketed primarily as a Git ACL tool, the other things being sort of
> mirror; maybe my impession was wrong, but I still think the comparison
> in ACL capabilities is useful.
Sorry; didn't mean to imply you were wrong about that...
But the bulk of MR is probably the web based stuff, wiki, issues etc.,
which means gitolite is way on the other side of the spectrum, so it
felt like any comparision is moot, and used the code/binary sizes to
highlight that.
But you said just the ACL capabilities... set me thinking...
Intland: do you have a page that describes your role based ACL stuff a
little more? I have a feeling that, modulo it all being in one text
file, gitolite can probably come close :-)
>> You should stick to gitorious, github, and -- here's a new
>> one for you -- indefero.
>
> Hmm, I didn't even know about this one, thanks for the pointer. Looks
> like this suddenly is a very popular area. High competition is good!
Oh yeah, and indefero is actually looking pretty good -- I know some
guys at $DAYJOB looking at it very seriously.
> (BTW, if you don't care about wikis and issue tracking, but you do care
> about simplicity and light-weightness, you should best stick to Girocco!
> ;-)
:-) yes it is nice, but again, at $DAYJOB access control (even to
view projects) is a big deal. A very big deal, actually...!
^ permalink raw reply
* Help creating script that mass-pulls Git(Hub) repos
From: Tony Maserati @ 2009-11-21 10:25 UTC (permalink / raw)
To: git
Hi,
I got a bunch of repos I've cloned off GitHub and I'm looking for the
best way to keep them all up to date.
I got a working zsh script, but it lacks some stuff. For instance I
think it'd be neat if it could output the difference between the
commit dates as oppose to those long hashes. And if it could initiate
the pull only when necessary. Other ideas are welcome.
Does anybody have any suggestions to how I might complete or otherwise
improve the below scripts? Thanks in advance.
Here's the working version:
abletony84$ cat pull_all.sh
#!/usr/bin/env zsh
for folder in $PWD/**/.git(:h); do
cd $folder
git pull
done
-
This script lacks a proper if clause, and shows hashes instead of dates:
abletony84$ cat pull_all2.sh
#!/usr/bin/env zsh
for folder in $PWD/**/.git(:h); do
cd $folder
if this repo needs an update; then # git ls-remote has been suggested
old=$(git rev-parse HEAD)
git pull >& /dev/null
new=$(git rev-parse HEAD)
echo "$folder: $old -> $new"
else
echo "$folder: nothing to do"
fi
done
-
A slightly different approach, even more incomplete than the previous:
abletony84$ cat pull_all3.sh
#!/usr/bin/env zsh
for folder in $PWD/**/.git(:h); do
cd $folder
if repo still exists at github; then
git fetch >& /dev/null
if a merge is needed; then
git merge >& /dev/null
echo "$folder: date_of_last_current_commit -> date_of_last_new_comit"
else
echo "$folder: nothing to do"
fi
fi
done
-
Thanks again!
Tony
^ permalink raw reply
* Re: Default history simplification
From: Junio C Hamano @ 2009-11-21 6:37 UTC (permalink / raw)
To: Jan Krüger; +Cc: Tommy Wang, git
In-Reply-To: <20091120095537.1909f6b6@perceptron>
Jan Krüger <jk@jk.gs> writes:
> Tommy Wang <subscription@august8.net> wrote:
>> [...] I would love to simply use the rev-list built-in to
>> do my work for me; but I fear that I may have much too many path
>> limiters than the linux command-line can handle (which if I'm correct,
>> can only take so many arguments).
>
> On my system, "only so many arguments" means about two megabytes worth
> of command line.
Good point.
The command line limitation, even if it is very small, shouldn't be a
problem if Tommy is interested in recreating exactly what rev-list does.
If his tool that drives rev-list or log from the command line cannot work
because his request overflows the command line, the same request will
overflow the command line for rev-list or log, so they wouldn't work
either.
For a more serious answer, see the other thread ;-).
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: bill lam @ 2009-11-21 4:10 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30911201829i52ffa022qff827bdf317ad447@mail.gmail.com>
Sorry, typo 's/relase/release/'
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: bill lam @ 2009-11-21 3:58 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30911201829i52ffa022qff827bdf317ad447@mail.gmail.com>
On Fri, 20 Nov 2009, Jonas Fonseca wrote:
> On Fri, Nov 20, 2009 at 11:25, bill lam <cbill.lam@gmail.com> wrote:
> > On Fri, 20 Nov 2009, Jonas Fonseca wrote:
> >> install-release-doc-man:
> >> for doc in $(MANDOC); do \
> >> git checkout origin/release $$doc; \
> >> done
> >> $(MAKE) install-doc-man
> >
> > Thanks it works. Could you also commit this to git?
>
> Done, but using git-checkout-index ...
the line
git read-tree release
raised error perhaps I didn't checkout a branch for it, replacing it
with
git read-tree origin/relase
or
git read-tree remotes/origin/relase
seems working.
Another question, while it can open a file with editor in tree-view, I
cannot find in tigmanual how to directly save a file. Any idea?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: Jonas Fonseca @ 2009-11-21 2:29 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091120162543.GB3919@debian.b2j>
On Fri, Nov 20, 2009 at 11:25, bill lam <cbill.lam@gmail.com> wrote:
> On Fri, 20 Nov 2009, Jonas Fonseca wrote:
>> install-release-doc-man:
>> for doc in $(MANDOC); do \
>> git checkout origin/release $$doc; \
>> done
>> $(MAKE) install-doc-man
>
> Thanks it works. Could you also commit this to git?
Done, but using git-checkout-index ...
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH 0/2] jn/gitweb-blame fixes
From: Jakub Narebski @ 2009-11-21 0:32 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <4B06157B.10203@gmail.com>
On Fri, 20 Nov 2009, Stephen Boyd wrote:
> Stephen Boyd wrote:
> > Jakub Narebski wrote:
> > >
> > > Thanks for working on this. Also it is nice to have incremental blame
> > > tested for another browser, beside Mozilla 1.17.2 and Konqueror 3.5.3
> >
> > For those following along, Opera-10.10 has been tested and works.
>
> Ok. I tried using the version of incremental blame that's in next
> (e206d62 gitweb: Colorize 'blame_incremental' view during processing,
> 2009-09-01) on IE8 with no success. The page loads and the file is shown
> with line numbers, but the progress is stuck at 0% (with the
> showing too).
>
> I then tried with my two patches applied on top of e206d62 on IE8 and
> still no success. The page loads and the file is show with the line
> numbers but still stuck at 0%, but the is gone at least.
>
> Do you have access to IE8 to confirm?
I have tested gitweb with both of your patches applied, serving gitweb
as CGI script using Apache 2.0.54 on Linux, and viewing from separate
computer on MS Windows XP, with the following results:
* For the following browsers blame_incremental view on gitweb/gitweb.perl
file produces correct output, but for progress info which instead of
( 1%) -> ( 29%) -> (100%) looks more like ( 1%) -> (29%) -> (100%)
+ Firefox 3.5.5 (rv:1.9.1.5 Gecko/20091102)
+ Opera 10.01
+ Google Chrome 3.0.195.33
* Testing it with IE8 (Internet Explorer 8.0.6001.18702) page loading stops
at 0%, at the very beginning on startBlame() function
IE8 shows that it finds the following errors:
* "firstChild is null or not an object"
line: 565, char:4
a_sha1.firstChild.data = commit.sha1.substr(0, 8);
It might be caused by the fact that firstChild for this case should be
text node containing of pure whitespace:
<a href=""> </a>
Perhaps IE8 simplifies it in "compatability view" mode
* "Unspecified error" (twice)
line: 777, char:2
if (xhr.readyState === 3 && xhr.status !== 200) {
return;
}
I don't know what might be the source of error here; I suspect that the
error position mentioned by IE8 is bogus.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v5] git remote: Separate usage strings for subcommands
From: Tim Henigan @ 2009-11-20 23:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nanako Shiraishi, jrnieder
When the usage string for a subcommand must be printed,
only print the information relevant to that command.
This commit also removes the complete options list from
the first line of the subcommand usage string. Instead,
individual options are documented in the detailed
description following the general usage line.
Signed-off-by: Tim Henigan <tim.henigan@gmail.com>
---
This patch is based on:
http://article.gmane.org/gmane.comp.version-control.git/132953
After some misunderstanding on my part, this version of the patch
should be correct. The following snippet [1] explains the intent:
> Junio C Hamano wrote:
>> Tim Henigan <tim.henigan@gmail.com> writes:
>>
>> Using the 'add' subcommand as an example, the desired output is:
>>
>> Output of 'git remote -h':
>> "git remote [-v | --verbose]"
>> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
>> etc.
>>
>> Output of 'git remote add -h':
>> "git remote add [<options>...] <name> <url>"
>> followed by the detailed description given by 'parse_options()'.
>>
>> Text in 'man git-remote':
>> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
>> with the options explained in detail later in the file.
>>
>> Thanks for your patience,
>
> I think the above looks good;
[1]: http://thread.gmane.org/gmane.comp.version-control.git/133209/focus=133243
Documentation/git-remote.txt | 7 ++--
builtin-remote.c | 66 ++++++++++++++++++++++++++++++-----------
2 files changed, 52 insertions(+), 21 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 82a3d29..c272c92 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -13,10 +13,10 @@ SYNOPSIS
'git remote add' [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>
'git remote rename' <old> <new>
'git remote rm' <name>
-'git remote set-head' <name> [-a | -d | <branch>]
-'git remote show' [-n] <name>
+'git remote set-head' <name> (-a | -d | <branch>)
+'git remote' [-v | --verbose] 'show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
-'git remote update' [-p | --prune] [group | remote]...
+'git remote' [-v | --verbose] 'update' [-p | --prune] [group | remote]...
DESCRIPTION
-----------
@@ -30,6 +30,7 @@ OPTIONS
-v::
--verbose::
Be a little more verbose and show remote url after name.
+ NOTE: This must be placed between `remote` and `subcommand`.
COMMANDS
diff --git a/builtin-remote.c b/builtin-remote.c
index 0777dd7..4f4cba4 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -12,13 +12,48 @@ static const char * const builtin_remote_usage[] = {
"git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>",
"git remote rename <old> <new>",
"git remote rm <name>",
- "git remote set-head <name> [-a | -d | <branch>]",
- "git remote show [-n] <name>",
+ "git remote set-head <name> (-a | -d | <branch>)",
+ "git remote [-v | --verbose] show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
"git remote [-v | --verbose] update [-p | --prune] [group]",
NULL
};
+static const char * const builtin_remote_add_usage[] = {
+ "git remote add [<options>] <name> <url>",
+ NULL
+};
+
+static const char * const builtin_remote_rename_usage[] = {
+ "git remote rename <old> <new>",
+ NULL
+};
+
+static const char * const builtin_remote_rm_usage[] = {
+ "git remote rm <name>",
+ NULL
+};
+
+static const char * const builtin_remote_sethead_usage[] = {
+ "git remote set-head <name> (-a | -d | <branch>])",
+ NULL
+};
+
+static const char * const builtin_remote_show_usage[] = {
+ "git remote show [<options>] <name>",
+ NULL
+};
+
+static const char * const builtin_remote_prune_usage[] = {
+ "git remote prune [<options>] <name>",
+ NULL
+};
+
+static const char * const builtin_remote_update_usage[] = {
+ "git remote update [<options>] [<group> | <remote>]...",
+ NULL
+};
+
#define GET_REF_STATES (1<<0)
#define GET_HEAD_NAMES (1<<1)
#define GET_PUSH_REF_STATES (1<<2)
@@ -70,7 +105,6 @@ static int add(int argc, const char **argv)
int i;
struct option options[] = {
- OPT_GROUP("add specific options"),
OPT_BOOLEAN('f', "fetch", &fetch, "fetch the remote branches"),
OPT_CALLBACK('t', "track", &track, "branch",
"branch(es) to track", opt_parse_track),
@@ -79,11 +113,11 @@ static int add(int argc, const char **argv)
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_add_usage,
0);
if (argc < 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_add_usage, options);
name = argv[0];
url = argv[1];
@@ -540,7 +574,7 @@ static int mv(int argc, const char **argv)
int i;
if (argc != 3)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rename_usage, options);
rename.old = argv[1];
rename.new = argv[2];
@@ -681,7 +715,7 @@ static int rm(int argc, const char **argv)
int i, result;
if (argc != 2)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_rm_usage, options);
remote = remote_get(argv[1]);
if (!remote)
@@ -976,7 +1010,6 @@ static int show(int argc, const char **argv)
{
int no_query = 0, result = 0, query_flag = 0;
struct option options[] = {
- OPT_GROUP("show specific options"),
OPT_BOOLEAN('n', NULL, &no_query, "do not query remotes"),
OPT_END()
};
@@ -984,7 +1017,7 @@ static int show(int argc, const char **argv)
struct string_list info_list = { NULL, 0, 0, 0 };
struct show_info info;
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_show_usage,
0);
if (argc < 1)
@@ -1081,14 +1114,13 @@ static int set_head(int argc, const char **argv)
char *head_name = NULL;
struct option options[] = {
- OPT_GROUP("set-head specific options"),
OPT_BOOLEAN('a', "auto", &opt_a,
"set refs/remotes/<name>/HEAD according to remote"),
OPT_BOOLEAN('d', "delete", &opt_d,
"delete refs/remotes/<name>/HEAD"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_sethead_usage,
0);
if (argc)
strbuf_addf(&buf, "refs/remotes/%s/HEAD", argv[0]);
@@ -1114,7 +1146,7 @@ static int set_head(int argc, const char **argv)
if (delete_ref(buf.buf, NULL, REF_NODEREF))
result |= error("Could not delete %s", buf.buf);
} else
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_sethead_usage, options);
if (head_name) {
unsigned char sha1[20];
@@ -1138,16 +1170,15 @@ static int prune(int argc, const char **argv)
{
int dry_run = 0, result = 0;
struct option options[] = {
- OPT_GROUP("prune specific options"),
OPT__DRY_RUN(&dry_run),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_prune_usage,
0);
if (argc < 1)
- usage_with_options(builtin_remote_usage, options);
+ usage_with_options(builtin_remote_prune_usage, options);
for (; argc; argc--, argv++)
result |= prune_remote(*argv, dry_run);
@@ -1228,13 +1259,12 @@ static int update(int argc, const char **argv)
struct string_list list = { NULL, 0, 0, 0 };
static const char *default_argv[] = { NULL, "default", NULL };
struct option options[] = {
- OPT_GROUP("update specific options"),
OPT_BOOLEAN('p', "prune", &prune,
"prune remotes after fetching"),
OPT_END()
};
- argc = parse_options(argc, argv, NULL, options, builtin_remote_usage,
+ argc = parse_options(argc, argv, NULL, options, builtin_remote_update_usage,
PARSE_OPT_KEEP_ARGV0);
if (argc < 2) {
argc = 2;
@@ -1334,7 +1364,7 @@ static int show_all(void)
int cmd_remote(int argc, const char **argv, const char *prefix)
{
struct option options[] = {
- OPT__VERBOSE(&verbose),
+ OPT_BOOLEAN('v', "verbose", &verbose, "be verbose; must be placed before a subcommand"),
OPT_END()
};
int result;
--
1.6.5.2.186.g3ccc3
^ permalink raw reply related
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Markus Heidelberg @ 2009-11-20 23:33 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Paul Mackerras, peff, sam, git
In-Reply-To: <20091120185522.GC56351@gmail.com>
David Aguilar, 2009-11-20:
> The argument in favor of difftool is one of user
> expectations. From a user's POV it ~seems~ desirable for
> gitk to honor difftool configurations.
In general I absolutely like the idea. There are however problems you
can encounter.
I use vimdiff for git-difftool and gvimdiff for gitk. When testing gitk
with your patch, I wondered where the editor is, because nothing popped
up. I then found vim on the terminal from where I started gitk. Even
worse: when started with "gitk &", the vim process runs somewhere in the
background and gitk freezes.
To overcome this problem maybe we need a second config variable like
diff.guitool.
Markus
^ permalink raw reply
* Re: [RFC PATCH 0/6] Second round of committag series
From: Jakub Narebski @ 2009-11-20 23:24 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: git, Petr Baudis, Giuseppe Bilotta, Francis Galiegue
In-Reply-To: <1258525350-5528-1-git-send-email-marcel@oak.homeunix.org>
On Wed, 18 Nov 2009, Marcel M. Cary wrote:
> Thanks for the feedback. I've added four more patches to the end of
> the series and updated the first two. My replies are below.
>
> On Mon, 22 Jun 2009, Jakub Narebski wrote:
> > On Fri, 19 June 2009, Marcel M. Cary wrote:
Thanks for working on this. I'll try to reply soon.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] let core.excludesfile default to ~/.gitignore.
From: Junio C Hamano @ 2009-11-20 22:49 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1258723430-31684-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> It seems this is the value most users set, so let's make it the default.
Maybe in 1.7.0, but I think using .gitignore will conflict with people who
put the entire $HOME under git (I think they are misguided, but that is
besides the point), so it should use some different name.
^ permalink raw reply
* Re: [PATCH/resend] CVS Server: Support reading base and roots from environment
From: Junio C Hamano @ 2009-11-20 22:42 UTC (permalink / raw)
To: Phil Miller; +Cc: Git Mailing List
In-Reply-To: <81f018ac0911200805g55bd1607u651334c1ed7f1303@mail.gmail.com>
Phil Miller <mille121@illinois.edu> writes:
> The Gitosis single-account Git/ssh hosting system runs git commands
> through git-shell after confirming that the connecting user is
> authorized to access the requested repository. This works well for
> upload-pack and receive-pack, which take a repository argument through
> git-shell. This doesn't work so well for `cvs server', which is passed
> through literally, with no arguments. Allowing arguments risks
> sneaking in `--export-all', so that restriction should be maintained.
>
> Despite that, passing a list of repository roots is necessary for
> per-user access control by the hosting software, and passing a base
> path improves usability without weakening security. Thus,
> git-cvsserver needs to come up with these values at runtime by some
> other means. Since git-shell preserves the environment for other
> purposes, the environment can carry these arguments as well.
>
> Thus, modify git-cvsserver to read $GIT_CVSSERVER_{BASE_PATH,ROOTS} in
> the absence of equivalent command line arguments.
>
> Signed-off-by: Phil Miller <mille121@illinois.edu>
> ---
Thanks.
Any comments from cvsserver users?
> git-cvsserver.perl | 21 ++++++++++++++++++++-
> 1 files changed, 20 insertions(+), 1 deletions(-)
>
> diff --git a/git-cvsserver.perl b/git-cvsserver.perl
> index 6dc45f5..9e58d2a 100755
> --- a/git-cvsserver.perl
> +++ b/git-cvsserver.perl
> @@ -104,6 +104,7 @@ $log->info("--------------- STARTING -----------------");
> my $usage =
> "Usage: git cvsserver [options] [pserver|server] [<directory> ...]\n".
> " --base-path <path> : Prepend to requested CVSROOT\n".
> + " Can be read from GIT_CVSSERVER_BASE_PATH\n".
> " --strict-paths : Don't allow recursing into subdirectories\n".
> " --export-all : Don't check for gitcvs.enabled in config\n".
> " --version, -V : Print version information and exit\n".
> @@ -111,7 +112,8 @@ my $usage =
> "\n".
> "<directory> ... is a list of allowed directories. If no directories\n".
> "are given, all are allowed. This is an additional restriction, gitcvs\n".
> - "access still needs to be enabled by the gitcvs.enabled config option.\n";
> + "access still needs to be enabled by the gitcvs.enabled config option.\n".
> + "Alternately, these directories may be specified in
> GIT_CVSSERVER_ROOTS.\n";
When you introduce a single variable holding multiple values, you need to
document how to cram the values into it. Maybe such a detail isn't
necessary in this usage text, but definitely in the documentation.
Documentation/git-cvsserver.txt needs to be updated to describe the
features added by this patch.
By the way, this patch is line-wrapped. Here, and...
> my @opts = ( 'help|h|H', 'version|V',
> 'base-path=s', 'strict-paths', 'export-all' );
> @@ -148,6 +150,23 @@ if ($state->{'export-all'} &&
> !@{$state->{allowed_roots}}) {
... also here.
> die "--export-all can only be used together with an explicit whitelist\n";
> }
>
> +# Environment handling for running under git-shell
> +if ($ENV{GIT_CVSSERVER_BASE_PATH}) {
It probably is more kosher to say
if (exists $ENV{...})
as the base_path _could_ be '0' that evaluates to false. When the path
does not begin with a '/', what will it be relative to? Do we want to
document it (not a rhetorical question)?
> + if ($state->{'base-path'}) {
> + die "Cannot specify base path both ways.\n";
> + }
> + my $base_path = $ENV{GIT_CVSSERVER_BASE_PATH};
> + $state->{'base-path'} = $base_path;
> + $log->debug("Picked up base path '$base_path' from environment.\n");
> +}
> +if ($ENV{GIT_CVSSERVER_ROOTS}) {
> + if (@{$state->{allowed_roots}}) {
> + die "Cannot specify roots both ways: @ARGV\n";
> + }
> + my @allowed_root = split(',', $ENV{GIT_CVSSERVER_ROOTS});
> + $state->{allowed_roots} = [ @allowed_root ];
Even though a comma is probably rare in pathname components, I do not know
if this is good.
How much thought went into choosing comma for this purpose? Is there a
particular reason you chose ',' as the separator? That should be
documented in the commit log message.
Logical alternative choices are "split at whitespace" (mimics the way how
command line argument splitting works) and "colon" (mimics the way how
$PATH is split into component paths).
If a pathname component with whitespaces (Windows and Macs?) is not an
issue, I would imagine "split at whitespace" is much more natural way to
handle this, but probably many people have "My Programs" and such.
Especially because it is hard, if not impossible, to have a pathname
component that contains a colon on Windows, I suspect that a colon is much
rare compared to whitespaces and commas in the name of people's
directories and files. It might be better to split at colon like $PATH is
handled than using a comma, if you are not going to give any escape
mechanism to .
^ permalink raw reply
* Re: GIT 1.5.4.2 installation on Solaris 8 problems
From: Brandon Casey @ 2009-11-20 21:46 UTC (permalink / raw)
To: Derek; +Cc: git
In-Reply-To: <loom.20091120T201341-834@post.gmane.org>
On Fri, Nov 20, 2009 at 07:15:40PM +0000, Derek wrote:
> Unfortunately I need 1.5.4.2 version specifically as I want it to work with
> gibak - http://eigenclass.org/hiki/gibak-backup-system-introduction
I didn't see anywhere on that page that says git version 1.5.4.2
specifically must be used. Did I miss it? or is it possible that a more
recent version of git would be compatible with that backup system?
The latest release is v1.6.5.3
-brandon
^ permalink raw reply
* Re: [PATCH v3] gitk: add --no-replace-objects option
From: Christian Couder @ 2009-11-20 21:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Michael J Gruber, Jakub Narebski, Johannes Sixt, bill lam,
Andreas Schwab, Paul Mackerras
In-Reply-To: <7v1vjsx6f5.fsf@alter.siamese.dyndns.org>
On vendredi 20 novembre 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> >> I wonder if this switch deserves run-time flippability, though...
> >
> > The following patch in master added run-time flippability to many
> > commands:
>
> What I meant was not that. I was wondering if the user wants to flip
> from the gitk GUI without restarting gitk.
Ah ok, yes this would be nice. But anyway I think the current patch is a
first good step.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Junio C Hamano @ 2009-11-20 20:56 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: Tarmigan, git, peff, jaysoffian, spearce
In-Reply-To: <20091120201116.GA19131@localhost>
Clemens Buchacher <drizzd@aon.at> writes:
> On Fri, Nov 20, 2009 at 11:03:13AM -0800, Tarmigan wrote:
>
>> Here's a patch (cut-n-paste so it will probably be munged) for
>> discussion of the port-fallback idea. If httpd cannot bind to 5541,
>> it tries 15541 etc.
>
> I would prefer if we skip the test right away.
Retrying is a different issue, and when tests are enabled I think it is Ok
to retry all you want.
But I don't want to see them enabled unless the user explicitly told us
to.
^ permalink raw reply
* Re: [PATCH v3] gitk: add --no-replace-objects option
From: Junio C Hamano @ 2009-11-20 20:55 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Michael J Gruber, Jakub Narebski,
Johannes Sixt, bill lam, Andreas Schwab, Paul Mackerras
In-Reply-To: <200911202142.39520.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
>> I wonder if this switch deserves run-time flippability, though...
>
> The following patch in master added run-time flippability to many commands:
What I meant was not that. I was wondering if the user wants to flip from
the gitk GUI without restarting gitk.
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Junio C Hamano @ 2009-11-20 20:54 UTC (permalink / raw)
To: Tarmigan; +Cc: git, peff, jaysoffian, drizzd, spearce
In-Reply-To: <905315640911201103w6d1da86duf41a53537672be8e@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> writes:
> On Fri, Nov 20, 2009 at 12:03 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Tarmigan <tarmigan+git@gmail.com> writes:
>>
>>> With smart http, git over http is likely to become much more common.
>>> To increase testing of smart http, enable the http tests by default.
>>
>> Sorry, but no test that listens to network ports should be enabled by
>> default; otherwise it will break automated, unattended tests people have
>> already set up randomly, depending on when the port happens to be
>> available for use by the tests.
>
> Is this the only concern or are there security or other issues as well?
I thought security was too obvious to mention.
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Junio C Hamano @ 2009-11-20 20:51 UTC (permalink / raw)
To: David Aguilar; +Cc: Paul Mackerras, peff, sam, git
In-Reply-To: <20091120185522.GC56351@gmail.com>
David Aguilar <davvid@gmail.com> writes:
>> > Also, I don't think we should remove the ability for the user to
>> > choose which external diff tool to use.
>>
>> This is a larger concern. Does "difftool" allow use of an arbitrary tool
>> like how gitk does (I have a suspicion that it is not as flexible)?
>
> difftool supports arbitrary tools through configuration.
> For arbitrary tools we set difftool.$name.cmd and
> diff.tool = $name.
So it is not as flexible as just giving a command line template for
one-shot invocation, but that is Ok.
Don't get me wrong. I think the longer term direction should be to reduce
code from gitk without making lifes harder to existing users, and just
like built-in "diff --cc" stripped the combined-diff implemented in Tcl
from gitk, use of "difftool" would be a good way to unify the "diffing"
experience for a user who uses both command line and gitk at the same
time.
I do not read Tcl very well but I am guessing that in gitk you specify
what tool to run (e.g. "frobanodiff -z"), gitk feeds you two temporary
files on the filesystem to compare (e.g. "frobanodiff -z $tmp1 $tmp2"),
and your command line is responsible for giving satisfying diff experience
to the end user.
I see three possible approaches:
* Teach "git-difftool" a mode to compare two arbitrary files on the
filesytem, and set that as "External Diff" command that takes the
filenames as extra two parameters, just like any other "External Diff"
programs given to gitk does. This is the least palatable, as it won't
solve the read-only repository issue at all (it only allows you the
logic to choose the configured difftool backend program).
* Instead of disabling the traditional "External Diff" and taking it over
like your patch did, add a new codepath for "Difftool" that feeds the
commit IDs and paths the way git-difftool expects. The user can use
both, and the issue of read-only repository is solved when "Difftool"
is used (but not "External Diff").
* Take over "External Diff" codepath exactly like your patch did, but
teach "git-difftool" a new command line option to name an unconfigured
external program that takes two filenames. When "External Diff"
program is *not* configured in gitk, the command line to invoke
difftool would be exactly as in your patch, i.e. "difftool --no-prompt
$from $to -- $path". Otherwise, when gitk is configured to use an
external program, e.g. "frobanodiff -z", for "External Diff", you pass
that command line to "git-difftool" via that new option, e.g.
difftool --no-prompt --extcmd="frobanodiff -z" $from $to -- $path
Then difftool is responsible for preparing the two necessary temporary
files out of the given information ($from/$to/$path) and feeding them
to "frobanodiff -z" command line.
Maybe such --extcmd support already exists in difftool, in which case
my earlier suspicion that difftool is not as flexible would be false.
I think the last one would be the way to go in the longer term.
^ 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