* Re: Dangerous "git am --abort" behavior
From: Junio C Hamano @ 2010-12-21 0:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <AANLkTinP4SArMkjvTXOEG=tf=8EcEdP9fPAB7F=iitSc@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I just noticed this, and I wonder if it has bitten me before without
> me noticing: "git am --abort" can be really dangerous.
>
> What happened today was that I had been doing a pull or two, and then
> applied an emailed patch with "git am" as usual. But as sometimes
> happens, I actually had a previous "git am" that had failed - in fact,
> it was the same patch that I applied today that had had an earlier
> version that no longer applied.
I never got into this as I use bash completion in my PS1 in the real life,
but I've seen this happen while playing around, and I can see myself
easily getting hurt by this behaviour without status in PS1.
> Maybe "git am" should actually save the last commit ID that it did,
> and only do the "reset" if the current HEAD matches the rebase-apply
> state and warns if it doesn't? Or maybe we could just introduce a new
> "git am --clean" that just flushes any old pending state (ie does that
> "clean_abort" thing, which is basically just the "rm -rf" I've done by
> hand). Or both?
I sometimes wanted "--clean" myself, so it is a no-brainer to decide that
it would be a good thing to add.
The last time I thought about this issue, I wasn't sure about "compare
with the last commit"---mostly because it wasn't clear what ramifications
it would have. When you get refusal from "am --abort", how would you
recover from it?
Back then my tentative conclusion was actually to get rid of "am --abort"
and give "am --clean", making the final "reset HEAD~$n" the responsiblity
of the user. But I forgot to pursue it.
^ permalink raw reply
* Re: [PATCH] trace.c: mark file-local function static
From: Thiago Farina @ 2010-12-21 0:28 UTC (permalink / raw)
To: Drew Northup; +Cc: Vasyl', git
In-Reply-To: <1292863989.19322.27.camel@drew-northup.unet.maine.edu>
On Mon, Dec 20, 2010 at 2:53 PM, Drew Northup <drew.northup@maine.edu> wrote:
>
> On Mon, 2010-12-20 at 13:17 -0200, Thiago Farina wrote:
>> On Mon, Dec 20, 2010 at 10:00 AM, Drew Northup <drew.northup@maine.edu> wrote:
>> >
>> > On Thu, 2010-12-16 at 21:43 -0200, Thiago Farina wrote:
>> >> On Thu, Dec 16, 2010 at 8:38 PM, Vasyl' <vvavrychuk@gmail.com> wrote:
>> >> > Signed-off-by: Vasyl' Vavrychuk <vvavrychuk@gmail.com>
>> >> > ---
>> >> > trace.c | 2 +-
>> >> > 1 files changed, 1 insertions(+), 1 deletions(-)
>> >> >
>> >> > diff --git a/trace.c b/trace.c
>> >> > index 1e560cb..62586fa 100644
>> >> > --- a/trace.c
>> >> > +++ b/trace.c
>> >> > @@ -25,7 +25,7 @@
>> >> > #include "cache.h"
>> >> > #include "quote.h"
>> >> >
>> >> > -void do_nothing(size_t unused)
>> >> > +static void do_nothing(size_t unused)
>> >> > {
>> >> > }
>> >> >
>> >> If it means something, this looks sane to me.
>> >>
>> >> Acked-by: Thiago Farina <tfransosi@gmail.com>
>> >
>> > It may be sane, but why should we trust that it is without a commit
>> > message?
>>
>> Why such trivial thing needs further explanation?
>
> Because even trivial fixes may break non-trivial things.
> In addition, without justification we'd just as soon have somebody come
> back with another patch six months down the road that changes it back to
> the original code. Now that wouldn't make a whole lot of sense, now
> would it?
I don't think so, it's making the function private, because the
function is used only in that file and as such if you see a function
marked as static you know that and doesn't need further explanation in
my pov (but it seems you don't think like that).
> Alas the best way to avoid such a situation is to explain why a change
> was made to begin with.
>
So, you are welcome to contribute and suggest such description for
this trivial (that may break non-trivial things) patch. So we can
please you and others in the future.
Thanks.
^ permalink raw reply
* Re: [PATCH] gitweb: Include links to feeds in HTML header only for '200 OK' response
From: Jakub Narebski @ 2010-12-20 23:59 UTC (permalink / raw)
To: J.H.; +Cc: git, Junio C Hamano
In-Reply-To: <4D0D2D52.9000108@eaglescrag.net>
On Sat, 18 Dec 2010, J.H. wrote:
> On 12/18/2010 01:48 PM, Jakub Narebski wrote:
>> J.H. wrote:
>>
>>> I've no objection, you can add a sign-off from me.
>>
>> Errr... sign-off or ack? Signed-off-by is about provenance of code...
>
> Considering this has already been running on kernel.org - sign-off.
>
> http://git.kernel.org/?p=git/warthog9/gitweb.git;a=commit;h=41d9c63ad27a8d3c95bf8bb1ec5876483d39fbd6
>From Documentation/SubmittingPatches:
The sign-off is a simple line at the end of the explanation for
the patch, which certifies that you wrote it or otherwise have
the right to pass it on as a open-source patch.
So sign-off is about code provenance. As I don't think that code goes
into official git/git.git repository managed by Junio via your
git/warthog9/gitweb.git repository, I don't quite see why it is *sign-off*
from you, and not ack (Acked-by:).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: decorate a bit more remotes
From: Jakub Narebski @ 2010-12-20 23:11 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git
In-Reply-To: <1292871681-4818-3-git-send-email-sylvain@abstraction.fr>
Sylvain Rabot <sylvain@abstraction.fr> writes:
> - $urls_table .= format_repo_url("URL", $fetch);
> + $urls_table .= format_repo_url("<span class=\"bold\">URL:</span>", $fetch);
[...]
> diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
> index 79d7eeb..ce902f5 100644
> --- a/gitweb/static/gitweb.css
> +++ b/gitweb/static/gitweb.css
> @@ -579,6 +579,10 @@ div.remote {
> display: inline-block;
> }
>
> +.bold {
> + font-weight: bold;
> +}
<span class="bold"> is not much different from <strong> or <b>;
I'd rather you use some semantic name for the class, describing
what content it contains rather than what style it uses.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: decorate a bit more remotes
From: Jakub Narebski @ 2010-12-20 23:06 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Sylvain Rabot, git, John 'Warthog9' Hawley
In-Reply-To: <20101220200203.GA24163@burratino>
On Mon, 20 Dec 2010, Jonathan Nieder wrote:
> diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
> index 79d7eeb..feb09e5 100644
> --- a/gitweb/static/gitweb.css
> +++ b/gitweb/static/gitweb.css
> @@ -579,6 +579,19 @@ div.remote {
> display: inline-block;
> }
>
> +/*
> + * <b>URL:</b> http://www.example.com/
> + * <b>Fetch URL:</b> http://www.example.com/
> + * <b>Push URL:</b> http://www.example.com/
> + */
> +table.remote_urls tr.metadata_url td.metadata_tag:after {
> + content: ":"
> +}
I'd rather not use 'content' (pseudo-)property, as not all web
browsers implement it,... unless of course not having it doesn't
make view worse.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Dangerous "git am --abort" behavior
From: Adam Monsen @ 2010-12-20 22:04 UTC (permalink / raw)
To: Drew Northup; +Cc: git, Junio C Hamano, Linus Torvalds
In-Reply-To: <1292881979.23145.5.camel@drew-northup.unet.maine.edu>
Another thing a pal just showed me is the awesome Git Bash/Zsh
completion stuff in contrib/completion/ . That's a good way to keep
tabs on whether you're in the middle of a rebase or am (as well as
many other statuses).
Drew Northup wrote:
> Please don't cull the CC list...
I didn't, I replied at
http://thread.gmane.org/gmane.comp.version-control.git/164002 (by
clicking "--Action--" and selecting "Followup".
^ permalink raw reply
* Re: Dangerous "git am --abort" behavior
From: Drew Northup @ 2010-12-20 21:52 UTC (permalink / raw)
To: Adam Monsen; +Cc: git, Junio C Hamano, Linus Torvalds
In-Reply-To: <loom.20101220T203122-271@post.gmane.org>
On Mon, 2010-12-20 at 19:35 +0000, Adam Monsen wrote:
> Linus Torvalds writes:
> > What happened today was that I had been doing a pull or two, and then
> > applied an emailed patch with "git am" as usual. But as sometimes
> > happens, I actually had a previous "git am" that had failed - in fact,
> > it was the same patch that I applied today that had had an earlier
> > version that no longer applied.
>
> It would be helpful if "git status" mentioned if a rebase or am operation is in
> progress... this might have helped you avoid the situation described.
Adam,
Please don't cull the CC list...
In any case, are there any other mult-part operations for which we might
want to report "In Progress" in the "git status" output? How do we best
harvest and present this information to the user? This sounds like a
more general-purpose project than Linus' original scope.
--
-Drew Northup N1XIM
AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: cvsimport still not working with cvsnt
From: Jonathan Nieder @ 2010-12-20 21:36 UTC (permalink / raw)
To: Guy Rouillier
Cc: git, Emil Medve, Pascal Obry, Clemens Buchacher, Martin Langhoff
In-Reply-To: <4D0ED5EC.9020402@burntmail.com>
(+cc: Emil, some cvsimport people)
Guy Rouillier wrote:
> I'm going to try sending this blind, as the mailing list has sent me
> the promised authorization key after 24 hrs.
No problem. Actually a subscription is not required --- the
convention on this list is to always reply-to-all.
> I finally found the problems, both of which were reported in 2008
> here:
>
> http://kerneltrap.org/mailarchive/git/2008/3/13/1157364
Seems to have received no replies[1].
> I do see one possible issue with the supplied modifications. At
> work, we upgraded from CVS to CVSNT. So, my home directory has both
> .cvspass (from the original CVS) and .cvs/cvspass (after the
> conversion to CVSNT.) Sloppy housekeeping on my part, I admit, but
> probably not uncommon. The supplied patch would pick up the
> original CVS file and would fail. (BTW, this is true only of the
> git-cvsimport.perl script itself; cvsps must shell out to the
> installed CVS client (in my case, cvsnt), because when I invoked
> that manually, it worked.)
>
> So, I would advise checking to see if both files exist, and if so
> exit with an error. Unless cvsimport wants to get real fancy and
> shell out to the installed cvs client to try to figure out what is
> installed, there is no way to tell which cvspass file is actively
> being used. I don't recommend trying to figure this out, as the
> user's intent is unclear.
Thanks, sounds sane to me. Care to write a patch?
Regards,
Jonathan
[1] http://thread.gmane.org/gmane.comp.version-control.git/77109
^ permalink raw reply
* Re: [PATCH v2] completion: add missing configuration variables
From: Jeff King @ 2010-12-20 21:20 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git, Junio C Hamano
In-Reply-To: <1292858305-7679-1-git-send-email-martin.von.zweigbergk@gmail.com>
On Mon, Dec 20, 2010 at 04:18:25PM +0100, Martin von Zweigbergk wrote:
> Quite a few configuration variables have been added since 226b343
> (completion: add missing configuration variables to _git_config(),
> 2009-05-03). Add these variables to the Bash completion script.
>
> Also remove the obsolete 'add.ignore-errors' and
> 'color.grep.external', as well as 'diff.renameLimit.', which never
> existed and rename the misspelled 'sendemail.aliasesfiletype'.
>
> Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
> ---
> Changes since previous version:
>
> Removed 'add.ignore-errors' and 'color.grep.external'.
>
> Added 'fetch.recurseSubmodules', which has entered master since last
> round.
>
> (Still based on master.)
Based on our prior discussion, I think this can go in, and all of the
other issues can be left for future patches if somebody wants to address
them.
Acked-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* [PATCH v2] completion: add missing configuration variables
From: Martin von Zweigbergk @ 2010-12-20 15:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Martin von Zweigbergk
In-Reply-To: <1292395613-12859-1-git-send-email-martin.von.zweigbergk@gmail.com>
Quite a few configuration variables have been added since 226b343
(completion: add missing configuration variables to _git_config(),
2009-05-03). Add these variables to the Bash completion script.
Also remove the obsolete 'add.ignore-errors' and
'color.grep.external', as well as 'diff.renameLimit.', which never
existed and rename the misspelled 'sendemail.aliasesfiletype'.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
Changes since previous version:
Removed 'add.ignore-errors' and 'color.grep.external'.
Added 'fetch.recurseSubmodules', which has entered master since last
round.
(Still based on master.)
contrib/completion/git-completion.bash | 70 ++++++++++++++++++++++++++++++--
1 files changed, 66 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 604fa79..25c4314 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1864,30 +1864,50 @@ _git_config ()
;;
esac
__gitcomp "
- add.ignore-errors
+ add.ignoreErrors
+ advice.commitBeforeMerge
+ advice.detachedHead
+ advice.implicitIdentity
+ advice.pushNonFastForward
+ advice.resolveConflict
+ advice.statusHints
alias.
+ am.keepcr
apply.ignorewhitespace
apply.whitespace
branch.autosetupmerge
branch.autosetuprebase
+ browser.
clean.requireForce
color.branch
color.branch.current
color.branch.local
color.branch.plain
color.branch.remote
+ color.decorate.HEAD
+ color.decorate.branch
+ color.decorate.remoteBranch
+ color.decorate.stash
+ color.decorate.tag
color.diff
color.diff.commit
color.diff.frag
+ color.diff.func
color.diff.meta
color.diff.new
color.diff.old
color.diff.plain
color.diff.whitespace
color.grep
- color.grep.external
+ color.grep.context
+ color.grep.filename
+ color.grep.function
+ color.grep.linenumber
color.grep.match
+ color.grep.selected
+ color.grep.separator
color.interactive
+ color.interactive.error
color.interactive.header
color.interactive.help
color.interactive.prompt
@@ -1901,21 +1921,29 @@ _git_config ()
color.status.untracked
color.status.updated
color.ui
+ commit.status
commit.template
+ core.abbrevguard
+ core.askpass
+ core.attributesfile
core.autocrlf
core.bare
+ core.bigFileThreshold
core.compression
core.createObject
core.deltaBaseCacheLimit
core.editor
+ core.eol
core.excludesfile
core.fileMode
core.fsyncobjectfiles
core.gitProxy
core.ignoreCygwinFSTricks
core.ignoreStat
+ core.ignorecase
core.logAllRefUpdates
core.loosecompression
+ core.notesRef
core.packedGitLimit
core.packedGitWindowSize
core.pager
@@ -1925,6 +1953,7 @@ _git_config ()
core.repositoryFormatVersion
core.safecrlf
core.sharedRepository
+ core.sparseCheckout
core.symlinks
core.trustctime
core.warnAmbiguousRefs
@@ -1932,15 +1961,17 @@ _git_config ()
core.worktree
diff.autorefreshindex
diff.external
+ diff.ignoreSubmodules
diff.mnemonicprefix
+ diff.noprefix
diff.renameLimit
- diff.renameLimit.
diff.renames
diff.suppressBlankEmpty
diff.tool
diff.wordRegex
difftool.
difftool.prompt
+ fetch.recurseSubmodules
fetch.unpackLimit
format.attach
format.cc
@@ -1952,6 +1983,8 @@ _git_config ()
format.subjectprefix
format.suffix
format.thread
+ format.to
+ gc.
gc.aggressiveWindow
gc.auto
gc.autopacklimit
@@ -1989,15 +2022,20 @@ _git_config ()
http.lowSpeedLimit
http.lowSpeedTime
http.maxRequests
+ http.minSessions
http.noEPSV
+ http.postBuffer
http.proxy
http.sslCAInfo
http.sslCAPath
http.sslCert
+ http.sslCertPasswordProtected
http.sslKey
http.sslVerify
+ http.useragent
i18n.commitEncoding
i18n.logOutputEncoding
+ imap.authMethod
imap.folder
imap.host
imap.pass
@@ -2006,6 +2044,7 @@ _git_config ()
imap.sslverify
imap.tunnel
imap.user
+ init.templatedir
instaweb.browser
instaweb.httpd
instaweb.local
@@ -2013,19 +2052,29 @@ _git_config ()
instaweb.port
interactive.singlekey
log.date
+ log.decorate
log.showroot
mailmap.file
man.
man.viewer
+ merge.
merge.conflictstyle
merge.log
merge.renameLimit
+ merge.renormalize
merge.stat
merge.tool
merge.verbosity
mergetool.
mergetool.keepBackup
+ mergetool.keepTemporaries
mergetool.prompt
+ notes.displayRef
+ notes.rewrite.
+ notes.rewrite.amend
+ notes.rewrite.rebase
+ notes.rewriteMode
+ notes.rewriteRef
pack.compression
pack.deltaCacheLimit
pack.deltaCacheSize
@@ -2036,31 +2085,42 @@ _git_config ()
pack.window
pack.windowMemory
pager.
+ pretty.
pull.octopus
pull.twohead
push.default
+ rebase.autosquash
rebase.stat
+ receive.autogc
receive.denyCurrentBranch
+ receive.denyDeleteCurrent
receive.denyDeletes
receive.denyNonFastForwards
receive.fsckObjects
receive.unpackLimit
+ receive.updateserverinfo
+ remotes.
repack.usedeltabaseoffset
rerere.autoupdate
rerere.enabled
+ sendemail.
sendemail.aliasesfile
- sendemail.aliasesfiletype
+ sendemail.aliasfiletype
sendemail.bcc
sendemail.cc
sendemail.cccmd
sendemail.chainreplyto
sendemail.confirm
sendemail.envelopesender
+ sendemail.from
+ sendemail.identity
sendemail.multiedit
sendemail.signedoffbycc
+ sendemail.smtpdomain
sendemail.smtpencryption
sendemail.smtppass
sendemail.smtpserver
+ sendemail.smtpserveroption
sendemail.smtpserverport
sendemail.smtpuser
sendemail.suppresscc
@@ -2071,6 +2131,8 @@ _git_config ()
showbranch.default
status.relativePaths
status.showUntrackedFiles
+ status.submodulesummary
+ submodule.
tar.umask
transfer.unpackLimit
url.
--
1.7.3.2.864.gbbb96
^ permalink raw reply related
* Re: [PATCH 2/3] gitweb: decorate a bit more remotes
From: Jonathan Nieder @ 2010-12-20 20:02 UTC (permalink / raw)
To: Sylvain Rabot; +Cc: git, Jakub Narebski, John 'Warthog9' Hawley
In-Reply-To: <1292871681-4818-3-git-send-email-sylvain@abstraction.fr>
Sylvain Rabot wrote:
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -5127,13 +5127,13 @@ sub git_remote_block {
>
> if (defined $fetch) {
> if ($fetch eq $push) {
> - $urls_table .= format_repo_url("URL", $fetch);
> + $urls_table .= format_repo_url("<span class=\"bold\">URL:</span>", $fetch);
> } else {
> - $urls_table .= format_repo_url("Fetch URL", $fetch);
> - $urls_table .= format_repo_url("Push URL", $push) if defined $push;
> + $urls_table .= format_repo_url("<span class=\"bold\">Fetch URL:</span>", $fetch);
> + $urls_table .= format_repo_url("<span class=\"bold\">Push URL:</span>", $push) if defined $push;
This makes the formatting of the remote URLs table inconsistent with
the other projects_list table (namely the
description ...
homepage URL ...
repository URL ...
owner ...
last change ...
table on a repository's summary page). Is that the right thing
to do?
If so, maybe something like the following would make sense.
-- 8< --
From: Sylvain Rabot <sylvain@abstraction.fr>
Date: Mon, 20 Dec 2010 20:01:20 +0100
Subject: gitweb: decorate a bit more remotes
Put the text "URL" introducing a remote's url in bold and follow it
with a colon. This makes the url list easier to visually scan.
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
The justification above is totally made up; I have not checked to
see whether it makes the table easier or harder to read. Also:
untested.
Maybe the $url part should be esc_url($url)?
gitweb/gitweb.perl | 16 ++++++++++------
gitweb/static/gitweb.css | 13 +++++++++++++
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d521c93..b870b56 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3862,7 +3862,11 @@ sub git_print_header_div {
sub format_repo_url {
my ($name, $url) = @_;
- return "<tr class=\"metadata_url\"><td>$name</td><td>$url</td></tr>\n";
+ my $row = "<tr class=\"metadata_url\">";
+ $row .= ($name eq "" ? "<td></td>" : "<td class=\"metadata_tag\">$name</td>");
+ $row .= "<td>$url</td>";
+ $row .= "</tr>\n";
+ return $row;
}
# Group output by placing it in a DIV element and adding a header.
@@ -5122,7 +5126,7 @@ sub git_remote_block {
my $fetch = $rdata->{'fetch'};
my $push = $rdata->{'push'};
- my $urls_table = "<table class=\"projects_list\">\n" ;
+ my $urls_table = "<table class=\"remote_urls\">\n" ;
if (defined $fetch) {
if ($fetch eq $push) {
@@ -5368,10 +5372,10 @@ sub git_summary {
print "<div class=\"title\"> </div>\n";
print "<table class=\"projects_list\">\n" .
- "<tr id=\"metadata_desc\"><td>description</td><td>" . esc_html($descr) . "</td></tr>\n" .
- "<tr id=\"metadata_owner\"><td>owner</td><td>" . esc_html($owner) . "</td></tr>\n";
+ "<tr id=\"metadata_desc\"><td class=\"metadata_tag\">description</td><td>" . esc_html($descr) . "</td></tr>\n" .
+ "<tr id=\"metadata_owner\"><td class=\"metadata_tag\">owner</td><td>" . esc_html($owner) . "</td></tr>\n";
if (defined $cd{'rfc2822'}) {
- print "<tr id=\"metadata_lchange\"><td>last change</td><td>$cd{'rfc2822'}</td></tr>\n";
+ print "<tr id=\"metadata_lchange\"><td class=\"metadata_tag\">last change</td><td>$cd{'rfc2822'}</td></tr>\n";
}
# use per project git URL list in $projectroot/$project/cloneurl
@@ -5390,7 +5394,7 @@ sub git_summary {
if ($show_ctags) {
my $ctags = git_get_project_ctags($project);
my $cloud = git_populate_project_tagcloud($ctags);
- print "<tr id=\"metadata_ctags\"><td>Content tags:<br />";
+ print "<tr id=\"metadata_ctags\"><td class=\"metadata_tag\">Content tags:<br />";
print "</td>\n<td>" unless %$ctags;
print "<form action=\"$show_ctags\" method=\"post\"><input type=\"hidden\" name=\"p\" value=\"$project\" />Add: <input type=\"text\" name=\"t\" size=\"8\" /></form>";
print "</td>\n<td>" if %$ctags;
diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
index 79d7eeb..feb09e5 100644
--- a/gitweb/static/gitweb.css
+++ b/gitweb/static/gitweb.css
@@ -579,6 +579,19 @@ div.remote {
display: inline-block;
}
+/*
+ * <b>URL:</b> http://www.example.com/
+ * <b>Fetch URL:</b> http://www.example.com/
+ * <b>Push URL:</b> http://www.example.com/
+ */
+table.remote_urls tr.metadata_url td.metadata_tag:after {
+ content: ":"
+}
+
+table.remote_urls tr.metadata_url td.metadata_tag {
+ font-weight: bold;
+}
+
/* Style definition generated by highlight 2.4.5, http://www.andre-simon.de/ */
/* Highlighting theme definition: */
--
1.7.2.3.554.gc9b5c.dirty
^ permalink raw reply related
* Re: Dangerous "git am --abort" behavior
From: Adam Monsen @ 2010-12-20 19:35 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTinP4SArMkjvTXOEG=tf=8EcEdP9fPAB7F=iitSc@mail.gmail.com>
Linus Torvalds writes:
> What happened today was that I had been doing a pull or two, and then
> applied an emailed patch with "git am" as usual. But as sometimes
> happens, I actually had a previous "git am" that had failed - in fact,
> it was the same patch that I applied today that had had an earlier
> version that no longer applied.
It would be helpful if "git status" mentioned if a rebase or am operation is in
progress... this might have helped you avoid the situation described.
^ permalink raw reply
* Re: [PATCH 2/2] fill_textconv(): Don't get/put cache if sha1 is not valid
From: Kirill Smelkov @ 2010-12-20 19:28 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, git, Axel Bonnet, Cl??ment Poulain,
Diane Gasselin
In-Reply-To: <20101220044655.GB5942@sigill.intra.peff.net>
On Sun, Dec 19, 2010 at 11:46:56PM -0500, Jeff King wrote:
> On Sun, Dec 19, 2010 at 06:41:22PM -0800, Junio C Hamano wrote:
>
> > > I'm not that familiar with git internals involved, so here is updated
> > > patch with added paragraph about "df->sha1_valid=0 means files from
> > > worktree with unknown sha1", and appropriate excerpt from Jeff's post.
> > > That's the most reasonable I could come up with.
> > [...]
> > Here is how I would describe it.
> >
> > commit 87bb04bb760659dd33d7a173333329cd900620a9
> > Author: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> > Date: Sat Dec 18 17:54:12 2010 +0300
> >
> > fill_textconv(): Don't get/put cache if sha1 is not valid
> >
> > When blaming files in the working tree, the filespec is marked with
> > !sha1_valid, as we have not given the contents an object name yet. The
> > function to cache textconv results (keyed on the object name), however,
> > didn't check this condition, and ended up on storing the cached result
> > under a random object name.
> >
> > Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>
>
> FWIW, I think that is a good description.
Junio, Jeff, thanks for re-wording it. Though I think my v2 text was
saying the same, only with more info + examples. My english is pretty
bad this days, so I kind of understand why it was tempting to be redone :)
Thanks anyway, and for picking this into next,
Kirill
P.S. somehow 'Acked-by: Jeff King <peff@peff.net>' was dropped.
^ permalink raw reply
* Re: Basic Git Questions
From: George Spelvin @ 2010-12-20 19:21 UTC (permalink / raw)
To: paragkalra; +Cc: git, linux
> 1. I generally add the files in my working directory using "git add
> .". But sometimes you want to add all the files except 1 or 2 file. Is
> there a shortcut way we can tell git to add all the files but exclude
> a particular file.
Others have pointed out the general techniques, but a few additional
things that may be useful in some situations:
1) .gitignore. If the files are such that you never want git to pay
attention to them, you can add them to the .gitignore file.
2) "git add -u". This adds only files that git is already tracking,
and ignores truly new files.
3) "git add -i". This lets you pick the files to be added from a list.
4) "git gui". This lets you click on the files to be added.
It's my preferred way to do a selective commit.
^ permalink raw reply
* [PATCH 2/3] gitweb: decorate a bit more remotes
From: Sylvain Rabot @ 2010-12-20 19:01 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1292871681-4818-1-git-send-email-sylvain@abstraction.fr>
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 8 ++++----
gitweb/static/gitweb.css | 4 ++++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index a37094e..c460f27 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5127,13 +5127,13 @@ sub git_remote_block {
if (defined $fetch) {
if ($fetch eq $push) {
- $urls_table .= format_repo_url("URL", $fetch);
+ $urls_table .= format_repo_url("<span class=\"bold\">URL:</span>", $fetch);
} else {
- $urls_table .= format_repo_url("Fetch URL", $fetch);
- $urls_table .= format_repo_url("Push URL", $push) if defined $push;
+ $urls_table .= format_repo_url("<span class=\"bold\">Fetch URL:</span>", $fetch);
+ $urls_table .= format_repo_url("<span class=\"bold\">Push URL:</span>", $push) if defined $push;
}
} elsif (defined $push) {
- $urls_table .= format_repo_url("Push URL", $push);
+ $urls_table .= format_repo_url("<span class=\"bold\">Push URL:</span>", $push);
} else {
$urls_table .= format_repo_url("", "No remote URL");
}
diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
index 79d7eeb..ce902f5 100644
--- a/gitweb/static/gitweb.css
+++ b/gitweb/static/gitweb.css
@@ -579,6 +579,10 @@ div.remote {
display: inline-block;
}
+.bold {
+ font-weight: bold;
+}
+
/* Style definition generated by highlight 2.4.5, http://www.andre-simon.de/ */
/* Highlighting theme definition: */
--
1.7.3.4.523.g72f0d.dirty
^ permalink raw reply related
* [PATCH 3/3] gitweb: remove test when closing file descriptor
From: Sylvain Rabot @ 2010-12-20 19:01 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1292871681-4818-1-git-send-email-sylvain@abstraction.fr>
it happens that closing file descriptor fails whereas
the blob is perfectly readable. According to perlman
the reasons could be:
If the file handle came from a piped open, "close" will additionally
return false if one of the other system calls involved fails, or if the
program exits with non-zero status. (If the only problem was that the
program exited non-zero, $! will be set to 0.) Closing a pipe also waits
for the process executing on the pipe to complete, in case you want to
look at the output of the pipe afterwards, and implicitly puts the exit
status value of that command into $?.
Prematurely closing the read end of a pipe (i.e. before the process writ-
ing to it at the other end has closed it) will result in a SIGPIPE being
delivered to the writer. If the other end can't handle that, be sure to
read all the data before closing the pipe.
In this case we don't mind that close fails.
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c460f27..8f0d00e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3450,8 +3450,7 @@ sub run_highlighter {
my ($fd, $highlight, $syntax) = @_;
return $fd unless ($highlight && defined $syntax);
- close $fd
- or die_error(404, "Reading blob failed");
+ close $fd;
open $fd, quote_command(git_cmd(), "cat-file", "blob", $hash)." | ".
quote_command($highlight_bin).
" --xhtml --fragment --syntax $syntax |"
--
1.7.3.4.523.g72f0d.dirty
^ permalink raw reply related
* [PATCH 0/3 v2] minor gitweb modifications
From: Sylvain Rabot @ 2010-12-20 19:01 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
here a three patch serie with minor updates for gitweb based on master.
This serie has been improved regarding the comments of Jakub Narebski <jnareb@gmail.com>
Regards.
Sylvain Rabot (3):
gitweb: add extensions to highlight feature
gitweb: decorate a bit more remotes
gitweb: remove test when closing file descriptor
gitweb/gitweb.perl | 18 +++++++++---------
gitweb/static/gitweb.css | 4 ++++
2 files changed, 13 insertions(+), 9 deletions(-)
--
1.7.3.4.523.g72f0d.dirty
^ permalink raw reply
* [PATCH 1/3] gitweb: add extensions to highlight feature
From: Sylvain Rabot @ 2010-12-20 19:01 UTC (permalink / raw)
To: git; +Cc: Sylvain Rabot
In-Reply-To: <1292871681-4818-1-git-send-email-sylvain@abstraction.fr>
added: sql, php5, phps, bash, zsh, ksh, mk, make
Signed-off-by: Sylvain Rabot <sylvain@abstraction.fr>
---
gitweb/gitweb.perl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index d521c93..a37094e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -250,13 +250,14 @@ our %highlight_ext = (
# main extensions, defining name of syntax;
# see files in /usr/share/highlight/langDefs/ directory
map { $_ => $_ }
- qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl),
+ qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make),
# alternate extensions, see /etc/highlight/filetypes.conf
'h' => 'c',
+ map { $_ => 'sh' } qw(bash zsh ksh),
map { $_ => 'cpp' } qw(cxx c++ cc),
- map { $_ => 'php' } qw(php3 php4),
+ map { $_ => 'php' } qw(php3 php4 php5 phps),
map { $_ => 'pl' } qw(perl pm), # perhaps also 'cgi'
- 'mak' => 'make',
+ map { $_ => 'make'} qw(mak mk),
map { $_ => 'xml' } qw(xhtml html htm),
);
--
1.7.3.4.523.g72f0d.dirty
^ permalink raw reply related
* Dangerous "git am --abort" behavior
From: Linus Torvalds @ 2010-12-20 18:31 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
I just noticed this, and I wonder if it has bitten me before without
me noticing: "git am --abort" can be really dangerous.
What happened today was that I had been doing a pull or two, and then
applied an emailed patch with "git am" as usual. But as sometimes
happens, I actually had a previous "git am" that had failed - in fact,
it was the same patch that I applied today that had had an earlier
version that no longer applied.
So I just did "git am --abort" to get rid of the old stale 'am' state,
but that actually also ended up aborting my "git pull". Oops.
Happily, I noticed, and did a "git reset --hard @{1}" to get things
back, but at no point did "git am" warn about the implicit "reset" it
did, that threw away non-am state.
I suspect I've avoided this in the past because my normal approach to
getting rid of stale am state tends to be just the manual "rm -rf
.git/rebase-apply", but it's also possible that I've simply not
noticed before.
Maybe "git am" should actually save the last commit ID that it did,
and only do the "reset" if the current HEAD matches the rebase-apply
state and warns if it doesn't? Or maybe we could just introduce a new
"git am --clean" that just flushes any old pending state (ie does that
"clean_abort" thing, which is basically just the "rm -rf" I've done by
hand). Or both?
Comments?
Linus
^ permalink raw reply
* Re: 'show' pretty %B without a diff
From: Junio C Hamano @ 2010-12-20 18:05 UTC (permalink / raw)
To: Peter Vereshagin; +Cc: git
In-Reply-To: <20101220111214.GD10354@external.screwed.box>
Peter Vereshagin <peter@vereshagin.org> writes:
> JCH> Especially if you are doing a script, you probably should be using
> JCH> "cat-file commit" anyway, no?
>
> cat-file doesn't seem to support formatting option?
That is exactly why I suggested "cat-file", as you are scripting. We
reserve the right to change the human-visible formatting output from
Porcelain commands like "show" any time to make it "prettier" (we may
start coloring strings that look like object names in the commit log
message in "git show" output, for example), while giving scripts more
stable output through the plumbing commands like "cat-file" so that they
can parse and process without having to worry about the output format
changing under them.
If your script is _not_ parsing the git command output, but is just
blindly spewing it out to the invoking user, it is Ok to use "show",
though. Check "-s" option to the "show" command in that case.
^ permalink raw reply
* Re: [PATCH v2] convert filter: supply path to external driver
From: Junio C Hamano @ 2010-12-20 17:59 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git, Jeff King, Johannes Sixt
In-Reply-To: <20101220160911.GA32136@honk.padd.com>
Pete Wyckoff <pw@padd.com> writes:
> This version of the patch handles quoting of shell
> meta-characters, as pointed out by Hannes. I decided to invoke
> sq_quote_buf directly on the path before expanding %s, rather
> than writing a dict entry to understand %'s.
Ahh, that's much more preferable than my horrible suggestion ;-) If the
user wants to have concatenation with other parameters, that can be left
to the shell that is invoked, e.g. "--clean foo/%s" for "hello world.c"
would expand to "--clean foo/'hello world.c'" and does what we want.
Another nitpick is if 's' is the right letter to use for the pathname
information. I think you took 's' after "string", but if this is to be
extensible, you should anticipate that later there will be other kinds of
information you may want to throw at the filters, and expect that some of
them also will be of type "string", and you will have painted the person
who wants to add that new information into a tight corner as you already
took the valuable 's'.
Which would suggest that you shouldn't be naming the placeholder after the
type but after what the placeholder means, no? Perhaps %f (for filename)
would be a better choice?
^ permalink raw reply
* Re: [PATCH] trace.c: mark file-local function static
From: Drew Northup @ 2010-12-20 16:53 UTC (permalink / raw)
To: Thiago Farina; +Cc: Vasyl', git
In-Reply-To: <AANLkTimkxJHvTAvra+B-0bAQopd8s21ZrFCPG_ALbZZ9@mail.gmail.com>
On Mon, 2010-12-20 at 13:17 -0200, Thiago Farina wrote:
> On Mon, Dec 20, 2010 at 10:00 AM, Drew Northup <drew.northup@maine.edu> wrote:
> >
> > On Thu, 2010-12-16 at 21:43 -0200, Thiago Farina wrote:
> >> On Thu, Dec 16, 2010 at 8:38 PM, Vasyl' <vvavrychuk@gmail.com> wrote:
> >> > Signed-off-by: Vasyl' Vavrychuk <vvavrychuk@gmail.com>
> >> > ---
> >> > trace.c | 2 +-
> >> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >> >
> >> > diff --git a/trace.c b/trace.c
> >> > index 1e560cb..62586fa 100644
> >> > --- a/trace.c
> >> > +++ b/trace.c
> >> > @@ -25,7 +25,7 @@
> >> > #include "cache.h"
> >> > #include "quote.h"
> >> >
> >> > -void do_nothing(size_t unused)
> >> > +static void do_nothing(size_t unused)
> >> > {
> >> > }
> >> >
> >> If it means something, this looks sane to me.
> >>
> >> Acked-by: Thiago Farina <tfransosi@gmail.com>
> >
> > It may be sane, but why should we trust that it is without a commit
> > message?
>
> Why such trivial thing needs further explanation?
Because even trivial fixes may break non-trivial things.
In addition, without justification we'd just as soon have somebody come
back with another patch six months down the road that changes it back to
the original code. Now that wouldn't make a whole lot of sense, now
would it?
Alas the best way to avoid such a situation is to explain why a change
was made to begin with.
--
-Drew Northup N1XIM
AKA RvnPhnx on OPN
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* [PATCH v2] convert filter: supply path to external driver
From: Pete Wyckoff @ 2010-12-20 16:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Johannes Sixt
In-Reply-To: <7vzks1e84p.fsf@alter.siamese.dyndns.org>
Filtering to support keyword expansion may need the name of
the file being filtered. In particular, to support p4 keywords
like
$File: //depot/product/dir/script.sh $
the smudge filter needs to know the name of the file it is
smudging.
Add a "%s" conversion specifier to the gitattribute for filter.
It will be expanded with the path name to the file when invoking
the external filter command. The path name is quoted and
special characters are escaped to prevent the shell from splitting
incorrectly.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
gitster@pobox.com wrote on Sun, 19 Dec 2010 13:59 -0800:
> This is not backward compatible for people who wanted to use '%' literal
> on their filter command line for whatever reason, so please do not
> advertise as such. A fair argument you could make is "Even though this is
> not strictly backward compatible, it is very unlikely that people passed a
> literal % to their filter command line, and the benefit of being able to
> give the pathname information would outweigh the downside of not being
> compatible", and people can agree or disagree.
I overlooked that, but agree it is unlikely anyone was using % in
filter definitions. Putting the path in an environment variable
is the other option I considered.
> I am personally moderately negative about $any expansion$ (I don't use it
> myself, and I don't think sane people use it either). As far as I can
> tell, this should has no impact on the correctness and very little impact
> on the performance for people who do not use $any expansion$, so I am Ok
> with the patch.
Keyword expansion is indeed nasty. My only motivation is to
support working with an upstream that relies on it.
This version of the patch handles quoting of shell
meta-characters, as pointed out by Hannes. I decided to invoke
sq_quote_buf directly on the path before expanding %s, rather
than writing a dict entry to understand %'s. There is no
requirement for users to use single-quotes around %s in their
config files, this way, either.
Also added a test case to make sure %s and quoting works as
advertised.
-- Pete
Documentation/gitattributes.txt | 12 ++++++++++
convert.c | 22 +++++++++++++++++-
t/t0021-conversion.sh | 47 +++++++++++++++++++++++++++++++++++++++
3 files changed, 80 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 564586b..9ac2138 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -317,6 +317,18 @@ command is "cat").
smudge = cat
------------------------
+If your filter needs the path of the file it is working on,
+you can use the "%s" conversion specification. It will be
+replaced with the relative path to the file. This is important
+for keyword substitution that depends on the name of the
+file. Like this:
+
+------------------------
+[filter "p4"]
+ clean = git-p4-filter --clean %s
+ smudge = git-p4-filter --smudge %s
+------------------------
+
Interaction between checkin/checkout attributes
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/convert.c b/convert.c
index e41a31e..1ef83a0 100644
--- a/convert.c
+++ b/convert.c
@@ -317,6 +317,7 @@ struct filter_params {
const char *src;
unsigned long size;
const char *cmd;
+ const char *path;
};
static int filter_buffer(int in, int out, void *data)
@@ -329,7 +330,23 @@ static int filter_buffer(int in, int out, void *data)
int write_err, status;
const char *argv[] = { NULL, NULL };
- argv[0] = params->cmd;
+ /* replace optional %s with path */
+ struct strbuf cmd = STRBUF_INIT;
+ struct strbuf path = STRBUF_INIT;
+ struct strbuf_expand_dict_entry dict[] = {
+ "s", NULL,
+ NULL, NULL,
+ };
+
+ /* quote the path to preserve spaces, etc. */
+ sq_quote_buf(&path, params->path);
+ dict[0].value = path.buf;
+
+ /* expand all %s with the quoted path */
+ strbuf_expand(&cmd, params->cmd, strbuf_expand_dict_cb, &dict);
+ strbuf_release(&path);
+
+ argv[0] = cmd.buf;
memset(&child_process, 0, sizeof(child_process));
child_process.argv = argv;
@@ -349,6 +366,8 @@ static int filter_buffer(int in, int out, void *data)
status = finish_command(&child_process);
if (status)
error("external filter %s failed %d", params->cmd, status);
+
+ strbuf_release(&cmd);
return (write_err || status);
}
@@ -376,6 +395,7 @@ static int apply_filter(const char *path, const char *src, size_t len,
params.src = src;
params.size = len;
params.cmd = cmd;
+ params.path = path;
fflush(NULL);
if (start_async(&async))
diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
index 828e35b..c5c394d 100755
--- a/t/t0021-conversion.sh
+++ b/t/t0021-conversion.sh
@@ -93,4 +93,51 @@ test_expect_success expanded_in_repo '
cmp expanded-keywords expected-output
'
+cat <<EOF >argc.sh
+#!$SHELL_PATH
+echo argc: \$# "\$@"
+echo argc running >&2
+EOF
+chmod +x argc.sh
+
+#
+# The use of %s in a filter definition is expanded to the path to
+# the filename being smudged or cleaned. It must be shell escaped.
+#
+test_expect_success 'shell-escaped filenames' '
+ norm=name-no-magic &&
+ spec=$(echo name:sgl\"dbl\ spc!bang | tr : \\047) &&
+ echo some test text > test
+ cat test > $norm &&
+ cat test > "$spec" &&
+ git add $norm &&
+ git add "$spec" &&
+ git commit -m "add files" &&
+
+ echo "name* filter=argc" > .gitattributes &&
+
+ # delete the files and check them out again, using the smudge filter
+ git config filter.argc.smudge "./argc.sh %s" &&
+ rm $norm "$spec" &&
+ git checkout -- $norm "$spec" &&
+
+ # make sure argc.sh counted the right number of args
+ echo "argc: 1 $norm" > res &&
+ cmp res $norm &&
+ echo "argc: 1 $spec" > res &&
+ cmp res "$spec" &&
+
+ # %s with other args
+ git config filter.argc.smudge "./argc.sh %s --myword" &&
+ rm $norm "$spec" &&
+ git checkout -- $norm "$spec" &&
+
+ # make sure argc.sh counted the right number of args
+ echo "argc: 2 $norm --myword" > res &&
+ cmp res $norm &&
+ echo "argc: 2 $spec --myword" > res &&
+ cmp res "$spec" &&
+ :
+'
+
test_done
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] trace.c: mark file-local function static
From: Thiago Farina @ 2010-12-20 15:17 UTC (permalink / raw)
To: Drew Northup; +Cc: Vasyl', git
In-Reply-To: <1292846433.19322.1.camel@drew-northup.unet.maine.edu>
On Mon, Dec 20, 2010 at 10:00 AM, Drew Northup <drew.northup@maine.edu> wrote:
>
> On Thu, 2010-12-16 at 21:43 -0200, Thiago Farina wrote:
>> On Thu, Dec 16, 2010 at 8:38 PM, Vasyl' <vvavrychuk@gmail.com> wrote:
>> > Signed-off-by: Vasyl' Vavrychuk <vvavrychuk@gmail.com>
>> > ---
>> > trace.c | 2 +-
>> > 1 files changed, 1 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/trace.c b/trace.c
>> > index 1e560cb..62586fa 100644
>> > --- a/trace.c
>> > +++ b/trace.c
>> > @@ -25,7 +25,7 @@
>> > #include "cache.h"
>> > #include "quote.h"
>> >
>> > -void do_nothing(size_t unused)
>> > +static void do_nothing(size_t unused)
>> > {
>> > }
>> >
>> If it means something, this looks sane to me.
>>
>> Acked-by: Thiago Farina <tfransosi@gmail.com>
>
> It may be sane, but why should we trust that it is without a commit
> message?
Why such trivial thing needs further explanation?
^ permalink raw reply
* Re: [PATCH] convert filter: supply path to external driver
From: Pete Wyckoff @ 2010-12-20 14:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <4D0F0DFB.20502@viscovery.net>
j.sixt@viscovery.net wrote on Mon, 20 Dec 2010 09:04 +0100:
> Am 12/19/2010 22:29, schrieb Pete Wyckoff:
> > Filtering to support keyword expansion may need the name of
> > the file being filtered. In particular, to support p4 keywords
> > like
> >
> > $File: //depot/product/dir/script.sh $
> >
> > the smudge filter needs to know the name of the file it is
> > smudging.
> >
> > Add a "%s" conversion specifier to the gitattribute for filter.
> > It will be expanded with the path name to the file when invoking
> > the external filter command.
>
> What happens if there are any shell special characters in the path name
> (or spaces, for that matter). Does this shell-escape the substituted path
> name anywhere in the call chain?
Good catch---it doesn't. I'll see if running everything through
sq_quote_buf will help.
Incidentally there appears to be no way to quote spaces in
filenames listed in .gitattributes, although fnmatch wildcards
can be used to work around that.
-- Pete
^ 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