* Re: [PATCH] doc: enhance git describe --tags help
From: Shawn O. Pearce @ 2008-09-29 15:01 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Erez Zilber, git@vger.kernel.org, open-iscsi, Junio C Hamano
In-Reply-To: <20080928151259.GJ5302@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> index c4dbc2a..9cc8c2f 100644
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -30,7 +30,8 @@ OPTIONS
>
> --tags::
> Instead of using only the annotated tags, use any tag
> - found in `.git/refs/tags`.
> + found in `.git/refs/tags`. Though if an annotated tag is found in the
> + ancestry, it will always be preferred to lightweight tags.
As technically correct as the statement is, I read this and go
"why do we even have --tags?".
If I read builtin-describe.c right we only honor --tags on an exact
match, or if there are no annotated tags at all in the history.
I wonder if docs like this aren't better for --tags:
--tags::
If a lightweight tag exactly matches, output it. If no
annotated tag is found in the ancestry but a lightweight
tag is found, output the lightweight tag.
?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: Miklos Vajna @ 2008-09-29 15:07 UTC (permalink / raw)
To: Jakub Narebski
Cc: SZEDER Gábor, git, Shawn O. Pearce, Johannes.Schindelin
In-Reply-To: <200809270151.51785.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1167 bytes --]
On Sat, Sep 27, 2008 at 01:51:47AM +0200, Jakub Narebski <jnareb@gmail.com> wrote:
> > Actually I think this would be ugly. MERGE_HEAD is about you can see
> > what will be merged once you commit the merge, but once you include HEAD
> > there, you can't easily check that. Maybe it's just me who sometimes
> > have a look at that file myself directly... :-)
>
> The new semantic would be very simple. If there is no MERGE_HEAD, it
> is an ordinary no-merge commit, and its only parent would be previous
> (current) version of HEAD. If there is MERGE_HEAD it contains _all_
> parents in a merge commit, and only those heads which will be parents
> (_reduced_ heads); if HEAD is symref, we modify given branch so it
> points to newly created merge commit.
>
> Currently parents of merge commits are 'reduce(HEAD + MERGE_HEAD)'
> in symbolic equation; I propose they would be simply 'MERGE_HEAD'.
> then we set this branch to new commit
Yes. Currently - after a merge conflict - you are able to check what
heads caused were merged, which caused the conflict, but with this
approach you would not be able to. I think this would be a step back...
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix typo in release notes for 1.6.0.3
From: Shawn O. Pearce @ 2008-09-29 15:08 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1222700288-29717-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> diff --git a/Documentation/RelNotes-1.6.0.3.txt b/Documentation/RelNotes-1.6.0.3.txt
> index 46e13a4..a374690 100644
> --- a/Documentation/RelNotes-1.6.0.3.txt
> +++ b/Documentation/RelNotes-1.6.0.3.txt
> @@ -16,7 +16,7 @@ Fixes since v1.6.0.2
> * Behaviour of "git diff --quiet" was inconsistent with "diff --exit-code"
> with the output redirected to /dev/null.
>
> -* "git stash apply sash@{1}" was fixed to error out. Prior versions
> +* "git stash apply stash@{1}" was fixed to error out. Prior versions
> would have applied stash@{0} incorrectly.
Actually maybe that typo was a good thing. The commit was about
erroring out on typos rather than silently applying stash@{0}.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] TopGit v0.3
From: Jan Nieuwenhuizen @ 2008-09-29 10:53 UTC (permalink / raw)
To: Petr Baudis; +Cc: martin f krafft, git, Jan Holesovsky
In-Reply-To: <20080923132728.GV10360@machine.or.cz>
On di, 2008-09-23 at 15:27 +0200, Petr Baudis wrote:
> what we can't make to work is just the
> most generic case, but e.g. if master is a *leaf* branch nothing else
> depends on and it can't get the branch through multiple paths, you can
> do the dependency removal rather easily (if it can get through multiple
> paths, you can still do it but you might have to deal with big
> conflicts).
This already would be very nice and would probably remove the last
technical hurdle to switch. Is it also easy to detect if a branch is
a leaf node?
> But if you scenario indeed is totally generic, I'm afraid I don't know
> how to make TopGit remove dependencies, except perhaps for the price of
> massive complexity and massive slowdown (pretty much redoing all the
> history walking etc.). Maybe someone else comes by with a genial
> solution...
Ah, so the problem is about branches depending on a branch from which
a dependency is removed. What is it that we need to be looking for
by history walking? Can't we possibly keep/cache that info in a
special topgit file?
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* [PATCHv3] gitweb path info enhancements
From: Giuseppe Bilotta @ 2008-09-29 15:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
Third run for the PATH_INFO handling enhancements in gitweb. A
trivial but important bugfix was sent as a separate patch, and the
other patches were rearranged a little, reducing the total number of
patches to four, paired in parsing and generation of the enhanced
PATH_INFO URLs.
The first two patches deal with the inclusion of action and hash or
the hash_base:filename pair in the URL, while still keeping support
for old-style PATH_INFO URLs whenever possible.
The other two patches extend the URL format to also include parent
hash/filename information when possible.
Giuseppe Bilotta (4):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: parse parent..current syntax from pathinfo
gitweb: generate parent..current URLs
gitweb/gitweb.perl | 167 +++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 126 insertions(+), 41 deletions(-)
^ permalink raw reply
* [PATCHv3] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Giuseppe Bilotta @ 2008-09-29 15:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <1222702017-4496-1-git-send-email-giuseppe.bilotta@gmail.com>
This patch enables gitweb to parse URLs with more information embedded
in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
path is now $project/$action/$hash_base:$file_name or
$project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
except when $project/$branch was used to access a branch whose name
matches a gitweb action.
---
gitweb/gitweb.perl | 90 +++++++++++++++++++++++++++++++---------------------
1 files changed, 54 insertions(+), 36 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ffe3dbf..a3076bd 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -495,6 +495,37 @@ if (defined $searchtext) {
$search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
}
+# dispatch
+my %actions = (
+ "blame" => \&git_blame,
+ "blobdiff" => \&git_blobdiff,
+ "blobdiff_plain" => \&git_blobdiff_plain,
+ "blob" => \&git_blob,
+ "blob_plain" => \&git_blob_plain,
+ "commitdiff" => \&git_commitdiff,
+ "commitdiff_plain" => \&git_commitdiff_plain,
+ "commit" => \&git_commit,
+ "forks" => \&git_forks,
+ "heads" => \&git_heads,
+ "history" => \&git_history,
+ "log" => \&git_log,
+ "rss" => \&git_rss,
+ "atom" => \&git_atom,
+ "search" => \&git_search,
+ "search_help" => \&git_search_help,
+ "shortlog" => \&git_shortlog,
+ "summary" => \&git_summary,
+ "tag" => \&git_tag,
+ "tags" => \&git_tags,
+ "tree" => \&git_tree,
+ "snapshot" => \&git_snapshot,
+ "object" => \&git_object,
+ # those below don't need $project
+ "opml" => \&git_opml,
+ "project_list" => \&git_project_list,
+ "project_index" => \&git_project_index,
+);
+
# now read PATH_INFO and use it as alternative to parameters
sub evaluate_path_info {
return if defined $project;
@@ -519,9 +550,19 @@ sub evaluate_path_info {
# do not change any parameters if an action is given using the query string
return if $action;
$path_info =~ s,^\Q$project\E/*,,;
+
+ # next comes the action
+ $action = $path_info;
+ $action =~ s,/.*$,,;
+ if (exists $actions{$action}) {
+ $path_info =~ s,^$action/*,,;
+ } else {
+ $action = undef;
+ }
+
my ($refname, $pathname) = split(/:/, $path_info, 2);
if (defined $pathname) {
- # we got "project.git/branch:filename" or "project.git/branch:dir/"
+ # we got "project.git/action/branch:filename" or "project.git/action/branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
$pathname =~ s,^/+,,;
if (!$pathname || substr($pathname, -1) eq "/") {
@@ -534,8 +575,9 @@ sub evaluate_path_info {
$file_name ||= validate_pathname($pathname);
} elsif (defined $refname) {
# we got "project.git/branch"
- $action ||= "shortlog";
- $hash ||= validate_refname($refname);
+ $action ||= "shortlog";
+ $hash ||= validate_refname($refname);
+ $hash_base ||= validate_refname($refname);
}
}
evaluate_path_info();
@@ -544,37 +586,6 @@ evaluate_path_info();
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
-# dispatch
-my %actions = (
- "blame" => \&git_blame,
- "blobdiff" => \&git_blobdiff,
- "blobdiff_plain" => \&git_blobdiff_plain,
- "blob" => \&git_blob,
- "blob_plain" => \&git_blob_plain,
- "commitdiff" => \&git_commitdiff,
- "commitdiff_plain" => \&git_commitdiff_plain,
- "commit" => \&git_commit,
- "forks" => \&git_forks,
- "heads" => \&git_heads,
- "history" => \&git_history,
- "log" => \&git_log,
- "rss" => \&git_rss,
- "atom" => \&git_atom,
- "search" => \&git_search,
- "search_help" => \&git_search_help,
- "shortlog" => \&git_shortlog,
- "summary" => \&git_summary,
- "tag" => \&git_tag,
- "tags" => \&git_tags,
- "tree" => \&git_tree,
- "snapshot" => \&git_snapshot,
- "object" => \&git_object,
- # those below don't need $project
- "opml" => \&git_opml,
- "project_list" => \&git_project_list,
- "project_index" => \&git_project_index,
-);
-
if (!defined $action) {
if (defined $hash) {
$action = git_get_type($hash);
@@ -631,8 +642,15 @@ sub href (%) {
if ($params{-replay}) {
while (my ($name, $symbol) = each %mapping) {
if (!exists $params{$name}) {
- # to allow for multivalued params we use arrayref form
- $params{$name} = [ $cgi->param($symbol) ];
+ # the parameter we want to recycle may be either part of the
+ # list of CGI parameter, or recovered from PATH_INFO
+ if ($cgi->param($symbol)) {
+ # to allow for multivalued params we use arrayref form
+ $params{$name} = [ $cgi->param($symbol) ];
+ } else {
+ no strict 'refs';
+ $params{$name} = $$name if $$name;
+ }
}
}
}
--
1.5.6.5
^ permalink raw reply related
* [PATCHv3] gitweb: generate project/action/hash URLs
From: Giuseppe Bilotta @ 2008-09-29 15:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <1222702017-4496-2-git-send-email-giuseppe.bilotta@gmail.com>
When generating path info URLs, reduce the number of CGI parameters by
embedding action and hash_parent:filename or hash in the path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 32 +++++++++++++++++++++++++++++---
1 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a3076bd..75d4178 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -657,14 +657,40 @@ sub href (%) {
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
- # use PATH_INFO for project name
+ # try to put as many parameters as possible in PATH_INFO:
+ # - project name
+ # - action
+ # - hash or hash_base:filename
+
+ # Strip any trailing / from $href, or we might get double
+ # slashes when the script is the DirectoryIndex
+ #
+ $href =~ s,/$,,;
+
+ # Then add the project name, if present
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
- # Summary just uses the project path URL
- if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ # Summary just uses the project path URL, any other action is
+ # added to the URL
+ if (defined $params{'action'}) {
+ $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
delete $params{'action'};
}
+
+ # Finally, we put either hash_base:/file_name or hash
+ if (defined $params{'hash_base'}) {
+ $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'file_name'}) {
+ $href .= ":/".esc_url($params{'file_name'});
+ delete $params{'file_name'};
+ }
+ delete $params{'hash'};
+ delete $params{'hash_base'};
+ } elsif (defined $params{'hash'}) {
+ $href .= "/".esc_url($params{'hash'});
+ delete $params{'hash'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ permalink raw reply related
* [PATCHv3] gitweb: parse parent..current syntax from pathinfo
From: Giuseppe Bilotta @ 2008-09-29 15:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <1222702017-4496-3-git-send-email-giuseppe.bilotta@gmail.com>
This makes it possible to use an URL such as
$project/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
$project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 26 ++++++++++++++++++++++++--
1 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 75d4178..7b4f2d3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -560,7 +560,9 @@ sub evaluate_path_info {
$action = undef;
}
- my ($refname, $pathname) = split(/:/, $path_info, 2);
+ $path_info =~ /^((.+?)(:(.+))?\.\.)?(.+?)(:(.+))?$/;
+ my ($parentrefname, $parentpathname, $refname, $pathname) = (
+ $2, $4, $5, $7);
if (defined $pathname) {
# we got "project.git/action/branch:filename" or "project.git/action/branch:dir/"
# we could use git_get_type(branch:pathname), but it needs $git_dir
@@ -569,7 +571,11 @@ sub evaluate_path_info {
$action ||= "tree";
$pathname =~ s,/$,,;
} else {
- $action ||= "blob_plain";
+ if ($parentrefname) {
+ $action ||= "blobdiff_plain";
+ } else {
+ $action ||= "blob_plain";
+ }
}
$hash_base ||= validate_refname($refname);
$file_name ||= validate_pathname($pathname);
@@ -579,6 +585,22 @@ sub evaluate_path_info {
$hash ||= validate_refname($refname);
$hash_base ||= validate_refname($refname);
}
+ # the parent part might be missing the pathname, in which case we use the $file_name, if present
+ if (defined $parentrefname) {
+ $hash_parent_base ||= validate_refname($parentrefname);
+ if ($parentpathname) {
+ $parentpathname =~ s,^/+,,;
+ $parentpathname =~ s,/$,,;
+ $file_parent ||= validate_pathname($parentpathname);
+ } else {
+ $file_parent ||= $file_name
+ }
+ if (defined $file_parent) {
+ $hash_parent ||= git_get_hash_by_path($hash_parent_base, $file_parent);
+ } else {
+ $hash_parent ||= validate_refname($parentrefname);
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv3] gitweb: generate parent..current URLs
From: Giuseppe Bilotta @ 2008-09-29 15:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Shawn O. Pearce, Giuseppe Bilotta
In-Reply-To: <1222702017-4496-4-git-send-email-giuseppe.bilotta@gmail.com>
If use_pathinfo is enabled, href now creates links that contain paths in
the form $project/$action/oldhash:/oldname..newhash:/newname for actions
that use hash_parent etc.
If any of the filename contains two consecutive dots, it's kept as a CGI
parameter since the resulting path would otherwise be ambiguous.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 27 +++++++++++++++++++++++----
1 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 7b4f2d3..4fa4364 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -700,17 +700,36 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:/file_name or hash
+ # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
+ # stripping nonexistent or useless pieces
+ $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
+ || $params{'hash_parent'} || $params{'hash'});
if (defined $params{'hash_base'}) {
- $href .= "/".esc_url($params{'hash_base'});
- if (defined $params{'file_name'}) {
+ if (defined $params{'hash_parent_base'}) {
+ $href .= esc_url($params{'hash_parent_base'});
+ # skip the file_parent if it's the same as the file_name
+ delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
+ if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
+ $href .= ":/".esc_url($params{'file_parent'});
+ delete $params{'file_parent'};
+ }
+ $href .= "..";
+ delete $params{'hash_parent'};
+ delete $params{'hash_parent_base'};
+ } elsif (defined $params{'hash_parent'}) {
+ $href .= esc_url($params{'hash_parent'}). "..";
+ delete $params{'hash_parent'};
+ }
+
+ $href .= esc_url($params{'hash_base'});
+ if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
$href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
delete $params{'hash_base'};
} elsif (defined $params{'hash'}) {
- $href .= "/".esc_url($params{'hash'});
+ $href .= esc_url($params{'hash'});
delete $params{'hash'};
}
}
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH 4/4] cygwin: Use native Win32 API for stat
From: Shawn O. Pearce @ 2008-09-29 15:34 UTC (permalink / raw)
To: Johannes Sixt
Cc: Dmitry Potapov, git, Junio C Hamano, Alex Riesen, Marcus Griep
In-Reply-To: <200809281124.08364.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> wrote:
> On Samstag, 27. September 2008, Dmitry Potapov wrote:
> > On Sat, Sep 27, 2008 at 08:35:03PM +0200, Johannes Sixt wrote:
> > > > +core.cygwinNativeStat::
> > >
> > > This name is *really* odd, for two reasons:
> ...
> > It was Shawn's suggestion. I don't care much about the name as long as
> > it is explained in the documentation... Therefore, I accepted what Shawn
> > said without giving it any thought.
>
> Shawn is an importen git-o-maniac, but it's certainly not blasphemy to
> question his words of wisdom ;)
As Hannes points out, blindly accepting anything I say might not
be a good idea. I have my moments of sanity, but I'm far, far
from perfect. ;-)
> My point is that emphasis on "stat" in the name is wrong: That's about
> implementation, but not about the effect. Why wouldn't 'ignoreCygwinFSTricks'
> be specific enough?
I like this a lot better. I could see us also bypassing other Cygwin
functions like open() in order to get faster system calls for Git.
Since it would be byassing the same Cygwin path name translation
code it should be controlled by the same flag.
> (And the length of the name doesn't
> worry me, considering how many people would want to change the default.)
Agreed. Most people setting it would copy and paste from the
documentation anyway.
I wonder though if we can't automatically implement it by grabbing
a copy of the Cygwin mount table and comparing those paths to
$GIT_DIR or $GIT_WORK_TREE. If any mount table entry is contained
within either of them then we know we can't use the native stat.
Its rather common for neither of these to contain a mount point,
and it is therefore easy to enable the native stat.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/3] Prepare for non-interactive merge-preserving rebase
From: Shawn O. Pearce @ 2008-09-29 16:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Stephen Haberman, Git Mailing List, Junio C Hamano
In-Reply-To: <48DE7386.2080808@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
>
> Shawn, I haven't seen this in any of your branches. Overlooked or
> dropped? I think 1-2 are probably master material, while I'm not
> so sure about 3/3. Would you prefer a re-send that turns it into
> a 2-patch series, adding each test with the functionality it tests?
Thanks for the reminder. It just got lost in the shuffle. I dragged
them out of the archives and will queue into this morning's update,
so no need for a resend.
--
Shawn.
^ permalink raw reply
* [PATCH] Clarify commit error message for unmerged files
From: Rafael Garcia-Suarez @ 2008-09-29 16:04 UTC (permalink / raw)
To: git; +Cc: Rafael Garcia-Suarez
Currently, trying to use git-commit with unmerged files in the index
will show the message "Error building trees", which can be a bit
obscure to the end user. This patch makes the error message clearer, and
consistent with what git-write-tree reports in a similar situation.
Signed-off-by: Rafael Garcia-Suarez <rgarciasuarez@gmail.com>
---
builtin-commit.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 8165bb3..6b23143 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -639,7 +639,7 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
active_cache_tree = cache_tree();
if (cache_tree_update(active_cache_tree,
active_cache, active_nr, 0, 0) < 0) {
- error("Error building trees");
+ error("Error building trees; the index is unmerged?");
return 0;
}
--
1.6.0.2.307.gc4275.dirty
^ permalink raw reply related
* Re: [PATCH 1/3] Prepare for non-interactive merge-preserving rebase
From: Andreas Ericsson @ 2008-09-29 16:04 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Stephen Haberman, Git Mailing List, Junio C Hamano
In-Reply-To: <20080929160153.GK17584@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn, I haven't seen this in any of your branches. Overlooked or
>> dropped? I think 1-2 are probably master material, while I'm not
>> so sure about 3/3. Would you prefer a re-send that turns it into
>> a 2-patch series, adding each test with the functionality it tests?
>
> Thanks for the reminder. It just got lost in the shuffle. I dragged
> them out of the archives and will queue into this morning's update,
> so no need for a resend.
>
Hold off on that if you haven't already applied them. I just noticed
something strange in passing 15 minutes ago that I need to investigate
a bit more. I need to get home now though, so I won't have time to
test it further until later tonight.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/3] Prepare for non-interactive merge-preserving rebase
From: Shawn O. Pearce @ 2008-09-29 16:11 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Stephen Haberman, Git Mailing List, Junio C Hamano
In-Reply-To: <48E0FC86.3040001@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Shawn O. Pearce wrote:
>> Andreas Ericsson <ae@op5.se> wrote:
>>> Shawn, I haven't seen this in any of your branches. Overlooked or
>>> dropped?
>>
>> Thanks for the reminder. It just got lost in the shuffle.
>
> Hold off on that if you haven't already applied them. I just noticed
> something strange in passing 15 minutes ago that I need to investigate
> a bit more. I need to get home now though, so I won't have time to
> test it further until later tonight.
Its only in a topic branch right now. I'll schedule them into 'pu'
today just so they are available, but I'll be happy to replace any
(or all) of the patches when you come up with something better.
--
Shawn.
^ permalink raw reply
* Re: [RFC 8/9] Docs: send-email: Create logical groupings for --help text
From: Jeff King @ 2008-09-29 16:25 UTC (permalink / raw)
To: Michael Witten; +Cc: jnareb, git
In-Reply-To: <1222664892-55810-3-git-send-email-mfwitten@mit.edu>
On Mon, Sep 29, 2008 at 12:08:11AM -0500, Michael Witten wrote:
> The options are partitioned into more digestible groups.
With patches 6, 8, and 9, the output is much improved. I'm not sure I
agree with all of the heading classification choices, but I first read
those options long enough ago that I no longer have any idea where I
would _expect_ to find them. So I will let others comment on that if
they want.
-Peff
^ permalink raw reply
* Re: [RFC 7/9] send-email: Completely replace --signed-off-cc with --signed-off-by-cc
From: Jeff King @ 2008-09-29 16:29 UTC (permalink / raw)
To: Michael Witten; +Cc: jnareb, git
In-Reply-To: <1222664781-55763-2-git-send-email-mfwitten@mit.edu>
On Mon, Sep 29, 2008 at 12:06:19AM -0500, Michael Witten wrote:
> This breaks backwards compatibility, but so what---get off your
> lazy arses and remove the cruft.
Sorry, but try to be a lot more careful than that about breaking
compatibility. The right sequence is:
1. Introduce new option (which has already been done for the command
line, but it looks like you are adding a new config variable).
Mention the new option in the documentation as the "right way".
Possibly mention the old version as "deprecated".
2. Wait a long time, possibly forever. This gives people a chance to
adjust, and it lets us wait for a major version bump where such an
incompatibility might be more expected.
3. Remove the old option.
So I think you are skipping straight to '3' here. However, I think your
real purpose is to simply clean up the documentation, so why not just do
that? We can still support the old options for historical setups, and
just advertise the new ones in the docs.
-Peff
^ permalink raw reply
* Re: [PATCH] parse-opt: migrate fmt-merge-msg.
From: Shawn O. Pearce @ 2008-09-29 16:35 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster
In-Reply-To: <1222595139-32087-2-git-send-email-madcoder@debian.org>
Pierre Habouzit <madcoder@debian.org> wrote:
> Also fix an inefficient printf("%s", ...) where we can use write_in_full.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> builtin-fmt-merge-msg.c | 50 +++++++++++++++++++++-------------------------
> 1 files changed, 23 insertions(+), 27 deletions(-)
Near as I can tell, this is based upon a merge commit in next.
We can't do that. Patches need to be based on master, or worst-case
on a topic head that is in next or pu (in which case the name of
the topic, or its tip commit, is helpful in the note).
--
Shawn.
^ permalink raw reply
* [PATCH] make prune report removed objects on -v
From: Michael J Gruber @ 2008-09-29 16:49 UTC (permalink / raw)
To: git; +Cc: Michael J Gruber
This adds an option "-v" which makes "git prune" more verbose:
It outputs all removed objects while removing them.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Documentation/git-prune.txt | 5 ++++-
builtin-prune.c | 10 +++++++---
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt
index 54f1dab..da6055d 100644
--- a/Documentation/git-prune.txt
+++ b/Documentation/git-prune.txt
@@ -8,7 +8,7 @@ git-prune - Prune all unreachable objects from the object database
SYNOPSIS
--------
-'git-prune' [-n] [--expire <expire>] [--] [<head>...]
+'git-prune' [-n] [-v] [--expire <expire>] [--] [<head>...]
DESCRIPTION
-----------
@@ -34,6 +34,9 @@ OPTIONS
Do not remove anything; just report what it would
remove.
+-v::
+ Report all removed objects.
+
\--::
Do not interpret any more arguments as options.
diff --git a/builtin-prune.c b/builtin-prune.c
index 1663f8b..7b4ec80 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -7,10 +7,11 @@
#include "parse-options.h"
static const char * const prune_usage[] = {
- "git prune [-n] [--expire <time>] [--] [<head>...]",
+ "git prune [-n] [-v] [--expire <time>] [--] [<head>...]",
NULL
};
static int show_only;
+static int verbose;
static unsigned long expire;
static int prune_tmp_object(const char *path, const char *filename)
@@ -39,11 +40,12 @@ static int prune_object(char *path, const char *filename, const unsigned char *s
if (st.st_mtime > expire)
return 0;
}
- if (show_only) {
+ if (show_only || verbose) {
enum object_type type = sha1_object_info(sha1, NULL);
printf("%s %s\n", sha1_to_hex(sha1),
(type > 0) ? typename(type) : "unknown");
- } else
+ }
+ if (!show_only)
unlink(fullpath);
return 0;
}
@@ -135,6 +137,8 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
const struct option options[] = {
OPT_BOOLEAN('n', NULL, &show_only,
"do not remove, show only"),
+ OPT_BOOLEAN('v', NULL, &verbose,
+ "report pruned objects"),
OPT_DATE(0, "expire", &expire,
"expire objects older than <time>"),
OPT_END()
--
1.6.0.2.287.g3791f
^ permalink raw reply related
* [RFC2 9/9] send-email: signedoffcc -> signedoffbycc, but handle both
From: Michael Witten @ 2008-09-29 17:41 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <1222710066-57768-1-git-send-email-mfwitten@mit.edu>
The documentation now mentions sendemail.signedoffbycc instead
of sendemail.signedoffcc in order to match with the options
--signed-off-by-cc; the code has been updated to reflect this
as well, but sendemail.signedoffcc is still handled.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 2 +-
git-send-email.perl | 9 +++++----
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index d566c34..82f5056 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -144,7 +144,7 @@ Automating
--[no-]signed-off-by-cc::
If this is set, add emails found in Signed-off-by: or Cc: lines to the
- cc list. Default is the value of 'sendemail.signedoffcc' configuration
+ cc list. Default is the value of 'sendemail.signedoffbycc' configuration
value; if that is unspecified, default to --signed-off-by-cc.
--suppress-cc::
diff --git a/git-send-email.perl b/git-send-email.perl
index 80dae88..bdbfac6 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -151,7 +151,7 @@ if ($@) {
my ($quiet, $dry_run) = (0, 0);
# Variables with corresponding config settings
-my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
+my ($thread, $chain_reply_to, $suppress_from, $signed_off_by_cc, $cc_cmd);
my ($smtp_server, $smtp_server_port, $smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
my ($validate);
@@ -161,7 +161,8 @@ my %config_bool_settings = (
"thread" => [\$thread, 1],
"chainreplyto" => [\$chain_reply_to, 1],
"suppressfrom" => [\$suppress_from, undef],
- "signedoffcc" => [\$signed_off_cc, undef],
+ "signedoffbycc" => [\$signed_off_by_cc, undef],
+ "signedoffcc" => [\$signed_off_by_cc, undef], # Deprecated
"validate" => [\$validate, 1],
);
@@ -225,7 +226,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
"suppress-cc=s" => \@suppress_cc,
- "signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
+ "signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
@@ -301,7 +302,7 @@ if ($suppress_cc{'all'}) {
# If explicit old-style ones are specified, they trump --suppress-cc.
$suppress_cc{'self'} = $suppress_from if defined $suppress_from;
-$suppress_cc{'sob'} = !$signed_off_cc if defined $signed_off_cc;
+$suppress_cc{'sob'} = !$signed_off_by_cc if defined $signed_off_by_cc;
# Debugging, print out the suppressions.
if (0) {
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* [RFC2 8/9] Docs: send-email: Create logical groupings for man text
From: Michael Witten @ 2008-09-29 17:41 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20080929162935.GA2628@coredump.intra.peff.net>
The options are partitioned into more digestible groups.
Within these groups, the options are sorted alphabetically.
Signed-off-by: Michael Witten <mfwitten@mit.edu>
---
Documentation/git-send-email.txt | 119 ++++++++++++++++++++++----------------
1 files changed, 69 insertions(+), 50 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 0d6ac4a..d566c34 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -19,9 +19,12 @@ The header of the email is configurable by command line options. If not
specified on the command line, the user will be prompted with a ReadLine
enabled interface to provide the necessary information.
+
OPTIONS
-------
-The options available are:
+
+Composing
+~~~~~~~~~
--bcc::
Specify a "Bcc:" value for each email. Default is the value of
@@ -34,46 +37,15 @@ The --bcc option must be repeated for each user you want on the bcc list.
+
The --cc option must be repeated for each user you want on the cc list.
---cc-cmd::
- Specify a command to execute once per patch file which
- should generate patch file specific "Cc:" entries.
- Output of this command must be single email address per line.
- Default is the value of 'sendemail.cccmd' configuration value.
-
---[no-]chain-reply-to::
- If this is set, each email will be sent as a reply to the previous
- email sent. If disabled with "--no-chain-reply-to", all emails after
- the first will be sent as replies to the first email sent. When using
- this, it is recommended that the first file given be an overview of the
- entire patch series. Default is the value of the 'sendemail.chainreplyto'
- configuration value; if that is unspecified, default to --chain-reply-to.
-
--compose::
Use $GIT_EDITOR, core.editor, $VISUAL, or $EDITOR to edit an
introductory message for the patch series.
---dry-run::
- Do everything except actually send the emails.
-
---envelope-sender::
- Specify the envelope sender used to send the emails.
- This is useful if your default address is not the address that is
- subscribed to a list. If you use the sendmail binary, you must have
- suitable privileges for the -f parameter. Default is the value of
- the 'sendemail.envelopesender' configuration variable; if that is
- unspecified, choosing the envelope sender is left to your MTA.
-
--from::
Specify the sender of the emails. This will default to
the value GIT_COMMITTER_IDENT, as returned by "git var -l".
The user will still be prompted to confirm this entry.
---identity::
- A configuration identity. When given, causes values in the
- 'sendemail.<identity>' subsection to take precedence over
- values in the 'sendemail' section. The default identity is
- the value of 'sendemail.identity'.
-
--in-reply-to::
Specify the contents of the first In-Reply-To header.
Subsequent emails will refer to the previous email
@@ -81,14 +53,30 @@ The --cc option must be repeated for each user you want on the cc list.
Only necessary if --compose is also set. If --compose
is not set, this will be prompted for.
---quiet::
- Make git-send-email less verbose. One line per email should be
- all that is output.
+--subject::
+ Specify the initial subject of the email thread.
+ Only necessary if --compose is also set. If --compose
+ is not set, this will be prompted for.
---[no-]signed-off-by-cc::
- If this is set, add emails found in Signed-off-by: or Cc: lines to the
- cc list. Default is the value of 'sendemail.signedoffcc' configuration
- value; if that is unspecified, default to --signed-off-by-cc.
+--to::
+ Specify the primary recipient of the emails generated. Generally, this
+ will be the upstream maintainer of the project involved. Default is the
+ value of the 'sendemail.to' configuration value; if that is unspecified,
+ this will be prompted for.
++
+The --to option must be repeated for each user you want on the to list.
+
+
+Sending
+~~~~~~~
+
+--envelope-sender::
+ Specify the envelope sender used to send the emails.
+ This is useful if your default address is not the address that is
+ subscribed to a list. If you use the sendmail binary, you must have
+ suitable privileges for the -f parameter. Default is the value of
+ the 'sendemail.envelopesender' configuration variable; if that is
+ unspecified, choosing the envelope sender is left to your MTA.
--smtp-encryption::
Specify the encryption to use, either 'ssl' or 'tls'. Any other
@@ -130,10 +118,34 @@ user is prompted for a password while the input is masked for privacy.
if a username is not specified (with '--smtp-user' or 'sendemail.smtpuser'),
then authentication is not attempted.
---subject::
- Specify the initial subject of the email thread.
- Only necessary if --compose is also set. If --compose
- is not set, this will be prompted for.
+
+Automating
+~~~~~~~~~~
+
+--cc-cmd::
+ Specify a command to execute once per patch file which
+ should generate patch file specific "Cc:" entries.
+ Output of this command must be single email address per line.
+ Default is the value of 'sendemail.cccmd' configuration value.
+
+--[no-]chain-reply-to::
+ If this is set, each email will be sent as a reply to the previous
+ email sent. If disabled with "--no-chain-reply-to", all emails after
+ the first will be sent as replies to the first email sent. When using
+ this, it is recommended that the first file given be an overview of the
+ entire patch series. Default is the value of the 'sendemail.chainreplyto'
+ configuration value; if that is unspecified, default to --chain-reply-to.
+
+--identity::
+ A configuration identity. When given, causes values in the
+ 'sendemail.<identity>' subsection to take precedence over
+ values in the 'sendemail' section. The default identity is
+ the value of 'sendemail.identity'.
+
+--[no-]signed-off-by-cc::
+ If this is set, add emails found in Signed-off-by: or Cc: lines to the
+ cc list. Default is the value of 'sendemail.signedoffcc' configuration
+ value; if that is unspecified, default to --signed-off-by-cc.
--suppress-cc::
Specify an additional category of recipients to suppress the
@@ -157,13 +169,16 @@ user is prompted for a password while the input is masked for privacy.
header set. Default is the value of the 'sendemail.thread' configuration
value; if that is unspecified, default to --thread.
---to::
- Specify the primary recipient of the emails generated. Generally, this
- will be the upstream maintainer of the project involved. Default is the
- value of the 'sendemail.to' configuration value; if that is unspecified,
- this will be prompted for.
-+
-The --to option must be repeated for each user you want on the to list.
+
+Administering
+~~~~~~~~~~~~~
+
+--dry-run::
+ Do everything except actually send the emails.
+
+--quiet::
+ Make git-send-email less verbose. One line per email should be
+ all that is output.
--[no-]validate::
Perform sanity checks on patches.
@@ -180,6 +195,7 @@ default to '--validate'.
CONFIGURATION
-------------
+
sendemail.aliasesfile::
To avoid typing long email addresses, point this to one or more
email aliases files. You must also supply 'sendemail.aliasfiletype'.
@@ -188,6 +204,7 @@ sendemail.aliasfiletype::
Format of the file(s) specified in sendemail.aliasesfile. Must be
one of 'mutt', 'mailrc', 'pine', or 'gnus'.
+
Author
------
Written by Ryan Anderson <ryan@michonline.com>
@@ -195,10 +212,12 @@ Written by Ryan Anderson <ryan@michonline.com>
git-send-email is originally based upon
send_lots_of_email.pl by Greg Kroah-Hartman.
+
Documentation
--------------
Documentation by Ryan Anderson
+
GIT
---
Part of the linkgit:git[1] suite
--
1.6.0.2.304.gdcf23.dirty
^ permalink raw reply related
* Re: [RFC2 9/9] send-email: signedoffcc -> signedoffbycc, but handle both
From: Jeff King @ 2008-09-29 17:44 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <1222710066-57768-2-git-send-email-mfwitten@mit.edu>
On Mon, Sep 29, 2008 at 12:41:06PM -0500, Michael Witten wrote:
> The documentation now mentions sendemail.signedoffbycc instead
> of sendemail.signedoffcc in order to match with the options
> --signed-off-by-cc; the code has been updated to reflect this
> as well, but sendemail.signedoffcc is still handled.
This new series looks fine to me.
-Peff
^ permalink raw reply
* Re: [PATCH 6/6] gitweb: prevent double slashes in PATH_INFO hrefs
From: Jakub Narebski @ 2008-09-29 18:12 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Lea Wiemann, Junio C Hamano
In-Reply-To: <1222030663-22540-7-git-send-email-giuseppe.bilotta@gmail.com>
On Sun, 21 Sep 2008, Giuseppe Bilotta wrote:
> When using PATH_INFO in combination with a rewrite rule that hides the
> cgi script name, links to projects and/or actions without projects might
> be generated with a double slash.
>
You mean here that base URL ends with '/'?
> Fix by removing the trailing slash (if present) from $href before
> appending PATH_INFO data.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Acked-by: Jakub Narebski <jnareb@gmail.com>
This is a good change, and worth applying even before the rest of
series (which probably would go through a few rounds of review).
I'm not sure if it applies cleanly, but conceptually it does not
depend on the rest of patches in this series.
> ---
> gitweb/gitweb.perl | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 4a91d07..ebab86b 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -675,6 +675,8 @@ sub href (%) {
>
> my ($use_pathinfo) = gitweb_check_feature('pathinfo');
> if ($use_pathinfo) {
> + $href =~ s,/$,,;
> +
> # use PATH_INFO for project name
> $href .= "/".esc_url($params{'project'}) if defined $params{'project'};
> delete $params{'project'};
> --
> 1.5.6.5
>
>
Should not go wrong...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Fix typo in release notes for 1.6.0.3
From: Miklos Vajna @ 2008-09-29 18:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080929150858.GH17584@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 254 bytes --]
On Mon, Sep 29, 2008 at 08:08:58AM -0700, "Shawn O. Pearce" <spearce@spearce.org> wrote:
> Actually maybe that typo was a good thing. The commit was about
> erroring out on typos rather than silently applying stash@{0}.
Aah. Sorry for the noise, then.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] builtin-commit: avoid using reduce_heads()
From: Miklos Vajna @ 2008-09-29 18:18 UTC (permalink / raw)
To: Jakub Narebski
Cc: SZEDER Gábor, git, Shawn O. Pearce, Johannes.Schindelin
In-Reply-To: <20080929150722.GU23137@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 850 bytes --]
On Mon, Sep 29, 2008 at 05:07:22PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> > Currently parents of merge commits are 'reduce(HEAD + MERGE_HEAD)'
> > in symbolic equation; I propose they would be simply 'MERGE_HEAD'.
> > then we set this branch to new commit
>
> Yes. Currently - after a merge conflict - you are able to check what
> heads caused were merged, which caused the conflict, but with this
> approach you would not be able to. I think this would be a step back...
Uh, I should read my mail before sending it next time.
I just wanted to say that in case, for example, I merge A^ and A, but I
get a conflict after octopus tried to merge A^ then it can be a useful
info to see that A^ was a head. Putting reduce(HEAD + MERGE_HEAD) to
MERGE_HEAD would hide this info, which would make the situation worse,
IMHO.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] cygwin: Use native Win32 API for stat
From: Dmitry Potapov @ 2008-09-29 18:26 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Johannes Sixt, git, Junio C Hamano, Alex Riesen, Marcus Griep
In-Reply-To: <20080929153400.GJ17584@spearce.org>
On Mon, Sep 29, 2008 at 08:34:00AM -0700, Shawn O. Pearce wrote:
> Johannes Sixt <johannes.sixt@telecom.at> wrote:
>
> > My point is that emphasis on "stat" in the name is wrong: That's about
> > implementation, but not about the effect. Why wouldn't 'ignoreCygwinFSTricks'
> > be specific enough?
>
> I like this a lot better. I could see us also bypassing other Cygwin
> functions like open() in order to get faster system calls for Git.
If you think that it may be useful to bypass some other functions, and
you want to use the same option to control that then a general name like
that makes sense. Personally, I don't believe that we may want to bypass
something like open() as it is not performance critical, but I said
above I don't care about the name much, so I am going to change my patch
to use ignoreCygwinFSTricks.
Dmitry
^ 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