* Re: [PATCH] gitweb: ensure the default stylesheet is accessible
From: Giuseppe Bilotta @ 2009-01-26 11:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano
In-Reply-To: <200901260248.22120.jnareb@gmail.com>
On Mon, Jan 26, 2009 at 2:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 26 Jan 2009, Giuseppe Bilotta wrote:
>
>> On some installations the CSS fails to be linked correctly when
>> path_info is enabled, since the link refers to "gitweb.css", whereas it
>> should be "${my_uri}/gitweb.css". Fix by setting the appropriate default
>> in the Makefile.
>
> Why "on some installations"? What does "some" mean? I don't think it
> is something indeterministic: please spell when one can have problems
> with linking CSS file.
The truth is, I haven't the slightest idea. It works fine on my
machine, it doesn't without the patch on ruby-rbot.org, but I really
don't know why.
> Wouldn't it be simpler to deal with problem of base URL when using
> path_info gitweb URLs to add BASE element to HTML head if we use
> path_info? Something like:
>
> if ($ENV{'PATH_INFO'}) { # $path_info is unfortunately stripped
> print qq(<base href="$my_uri">\n);
> }
>
> somewhere in git_header_html() subroutine?
Ah, this might work. I'll test it.
> It is not the same case for git-logo.png and git-favicon.png as for
> gitweb.css? If it is not, please explain why in commit message.
> If it is, then your patch is only partial solution to path_info
> problem.
Oh, interesting, true, I hadn't noticed.
I'll look into the base thing.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH] gitweb: last-modified time should be commiter, not author
From: Giuseppe Bilotta @ 2009-01-26 11:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901260254.49919.jnareb@gmail.com>
On Mon, Jan 26, 2009 at 2:54 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 25 Jan 2009, Giuseppe Bilotta wrote:
>
>> Subject: [PATCH] gitweb: last-modified time should be commiter, not author
>
> Should be really either "[PATCH 1/2]" or "[PATCH 5/4]" or "[PATCH 5/6]"
> just in case for the next patch, because next patch _depends_ on this
> one, and just in case of threading problem it should be marked as it;
> it also makes easier to apply patches from emails saved as individual
> files each.
I'll resend the whole 6-patch series cc'ing Junio too
>> Use the committer time for the last-modified header to ensure a more
>> correct guess of the last time the repository was modified.
>
> Good catch, good thinking IMHO. Committer date has much better chance
> to be monotonic than author date, and is more close related to
> _publishing_ date (author date is more of _creation_ date).
BTW, it is still not good enough. Consider a remote repo to which you
just pushed some changes you commited last week. The last-modified
date would be last-week, even if you just pushed those changes.
This used to be a problem for us on ruby-rbot because even when
watching the feed we would get no updates on the irc channel (the bot
thought the feed could still be cached). the if-modified thing seems
to have fixed this though.
> Lack signoff; if Junio forges it (or you reply that it should be
> signed off), you can add from me
>
> Acked-by: Jakub Narebski <jnareb@gmail.com>
>
>
> P.S. I wonder what other web interfaces do, for example cgit. I guess
> that web interfaces for other SCMs like SVN::Web, ViewVC etc. do not
> have this problem because they have only one, single date.
HEAD'ing a cgit atom url gives a last-modified date one hour from the
request, it seems. This is actually a typical (and not nice) behaviour
of many CGI scripts.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCHv2 1/6] gitweb: channel image in rss feed
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-1-git-send-email-giuseppe.bilotta@gmail.com>
Define the channel image for the rss feed when the logo or favicon are
defined, preferring the former to the latter. As suggested in the RSS
2.0 specifications, the image's title and link as set to the same as the
channel's.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..f8a5d2e 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6075,6 +6075,16 @@ XML
"<link>$alt_url</link>\n" .
"<description>$descr</description>\n" .
"<language>en</language>\n";
+ if (defined $logo || defined $favicon) {
+ # prefer the logo to the favicon, since RSS
+ # doesn't allow both
+ my $img = esc_url($logo || $favicon);
+ print "<image>\n" .
+ "<url>$img</url>\n" .
+ "<title>$title</title>\n" .
+ "<link>$alt_url</link>\n" .
+ "</image>\n";
+ }
} elsif ($format eq 'atom') {
print <<XML;
<feed xmlns="http://www.w3.org/2005/Atom">
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 0/6] gitweb: feed metadata enhancements
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
This second revision adds two patches to improve client-side rss
caching: the last-modified header we output is based on commit rather
than creation time, and we now act on if-modified-since request headers.
The last patch requires either HTTP::Date (from libwww-perl) or
Time::ParseDate
Giuseppe Bilotta (6):
gitweb: channel image in rss feed
gitweb: feed generator metadata
gitweb: rss feed managingEditor
gitweb: rss channel date
gitweb: last-modified time should be commiter, not author
gitweb: check if-modified-since for feeds
gitweb/gitweb.perl | 40 ++++++++++++++++++++++++++++++++++++++--
1 files changed, 38 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCHv2 2/6] gitweb: feed generator metadata
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-2-git-send-email-giuseppe.bilotta@gmail.com>
Add <generator> tag to RSS and Atom feed. Versioning info (gitweb/git
core versions, separated by a literal slash) is stored in the
appropriate attribute for the Atom feed, and in the tag content for the
RSS feed.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index f8a5d2e..3d94f50 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6085,6 +6085,7 @@ XML
"<link>$alt_url</link>\n" .
"</image>\n";
}
+ print "<generator>gitweb v.$version/$git_version</generator>\n";
} elsif ($format eq 'atom') {
print <<XML;
<feed xmlns="http://www.w3.org/2005/Atom">
@@ -6111,6 +6112,7 @@ XML
} else {
print "<updated>$latest_date{'iso-8601'}</updated>\n";
}
+ print "<generator version='$version/$git_version'>gitweb</generator>\n";
}
# contents
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 3/6] gitweb: rss feed managingEditor
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-3-git-send-email-giuseppe.bilotta@gmail.com>
The RSS 2.0 specification allows an optional managingEditor tag for the
channel, containing the "email address for person responsible for editorial
content", which is basically the project owner.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3d94f50..cc6d0fb 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6074,7 +6074,9 @@ XML
print "<title>$title</title>\n" .
"<link>$alt_url</link>\n" .
"<description>$descr</description>\n" .
- "<language>en</language>\n";
+ "<language>en</language>\n" .
+ # project owner is responsible for 'editorial' content
+ "<managingEditor>$owner</managingEditor>\n";
if (defined $logo || defined $favicon) {
# prefer the logo to the favicon, since RSS
# doesn't allow both
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 4/6] gitweb: rss channel date
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-4-git-send-email-giuseppe.bilotta@gmail.com>
The RSS 2.0 specifications defines not one but _two_ dates for its
channel element! Woohoo! Luckily, it seems that consensus seems to be
that if both are present they should be equal, except for some very
obscure and discouraged cases. Since lastBuildDate would make more sense
for us and pubDate seems to be the most commonly used, we defined both
and make them equal.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index cc6d0fb..756868a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6087,6 +6087,10 @@ XML
"<link>$alt_url</link>\n" .
"</image>\n";
}
+ if (%latest_date) {
+ print "<pubDate>$latest_date{'rfc2822'}</pubDate>\n";
+ print "<lastBuildDate>$latest_date{'rfc2822'}</lastBuildDate>\n";
+ }
print "<generator>gitweb v.$version/$git_version</generator>\n";
} elsif ($format eq 'atom') {
print <<XML;
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 5/6] gitweb: last-modified time should be commiter, not author
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-5-git-send-email-giuseppe.bilotta@gmail.com>
The last-modified time header added by RSS to increase cache hits from
readers should be set to the date the repository was last modified. The
author time in this respect is not a good guess because the last commit
might come from a oldish patch.
Use the committer time for the last-modified header to ensure a more
correct guess of the last time the repository was modified.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 756868a..8c49c75 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6015,7 +6015,7 @@ sub git_feed {
}
if (defined($commitlist[0])) {
%latest_commit = %{$commitlist[0]};
- %latest_date = parse_date($latest_commit{'author_epoch'});
+ %latest_date = parse_date($latest_commit{'committer_epoch'});
print $cgi->header(
-type => $content_type,
-charset => 'utf-8',
--
1.5.6.5
^ permalink raw reply related
* [PATCHv2 6/6] gitweb: check if-modified-since for feeds
From: Giuseppe Bilotta @ 2009-01-26 11:50 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1232970616-21167-6-git-send-email-giuseppe.bilotta@gmail.com>
Offering Last-modified header for feeds is only half the work, even if
we bail out early on HEAD requests. We should also check that same date
against If-modified-since, and bail out early with 304 Not Modified if
that's the case.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8c49c75..f4defb0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6015,7 +6015,25 @@ sub git_feed {
}
if (defined($commitlist[0])) {
%latest_commit = %{$commitlist[0]};
- %latest_date = parse_date($latest_commit{'committer_epoch'});
+ my $latest_epoch = $latest_commit{'committer_epoch'};
+ %latest_date = parse_date($latest_epoch);
+ my $if_modified = $cgi->http('IF_MODIFIED_SINCE');
+ if (defined $if_modified) {
+ my $since;
+ if (eval { require HTTP::Date; 1; }) {
+ $since = HTTP::Date::str2time($if_modified);
+ } elsif (eval { require Time::ParseDate; 1; }) {
+ $since = Time::ParseDate::parsedate($if_modified, GMT => 1);
+ }
+ if (defined $since && $latest_epoch <= $since) {
+ print $cgi->header(
+ -type => $content_type,
+ -charset => 'utf-8',
+ -last_modified => $latest_date{'rfc2822'},
+ -status => '304 Not Modified');
+ return;
+ }
+ }
print $cgi->header(
-type => $content_type,
-charset => 'utf-8',
--
1.5.6.5
^ permalink raw reply related
* Emacs git-mode feature request: support fill-paragraph correctly
From: Peter Simons @ 2009-01-26 11:57 UTC (permalink / raw)
To: git
Hi,
when I choose to commit in Emacs' git mode, I'm prompted to enter a
commit message in a buffer that looks something like this:
Author: Joe Doe <joe.doe@example.org>
--- log message follows this line ---
foo.txt: lots of important changes
Now, when I hit M-q (fill-paragraph), Emacs doesn't recognize that
the "--- log message ..." line ought to be considered a paragraph
separator. As a result, the re-filled buffer is messed up:
Author: Joe Doe <joe.doe@example.org> --- log message follows
this line --- foo.txt: lots of important changes
Other modes, such as message-mode, do support that kind of thing
correctly, so apparently it is possible to configure what the editor
considers as a paragraph. Is there some Emacs wizard out there who'd
be kind enough to improve git-mode accordingly?
Take care,
Peter
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-26 11:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Keith Cascio, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901261220300.14855@racer>
On Mon, Jan 26, 2009 at 12:28:55PM +0100, Johannes Schindelin wrote:
> > Are you aware that gitweb no longer calls "git diff", exactly because
> > of problems caused by calling a porcelain from a script?
>
> As I said: do you really expect people not to forget to upgrade gitweb
> manually when they do "sudo make install" with a new Git version?
Yes.
But my point is that gitweb was _already_ broken, because it was calling
a porcelain, and there were _already_ features that could cause serious
breakage.
So yes, adding a new feature that a user can trigger causes one more
opportunity for breakage. But the solution isn't to never ever add more
features to "git diff". It's to close the avenue by which the new _and_
old breakages are triggered.
> > I don't want to break existing setups, either. But at some point you
> > have to say "this is porcelain, so don't rely on there not being any
> > user-triggered effects in its behavior". If porcelain is cast in stone,
> > then what is the point in differentiating plumbing from porcelain?
>
> Two points there:
>
> - with gitweb, we were the offenders ourselves. So we should give the
> users of gitweb at least _some_ slack.
I'm not sure I agree. I always assumed that since gitweb, git-gui, and
gitk are bundled with git during release that we have _more_ leeway in
making matching changes between them.
Are you sure that you can run random versions of gitweb with random
versions of git in the first place?
> - Concretely for the "porcelain" git diff: This workflow
>
> git diff > my-patch
> <attach and send to somebody>
>
> is probably pretty wide spread. And it is okay, a user is not a script,
> they are very much allowed to use porcelain. And we _would_ break
> expectations there.
Sorry, but what in the world are we supposed to do? Never ever allow the
user to specify diff options to a porcelain because they might impact
the output? A user who sets a config option or a command line option to
impact the output of "git diff" is responsible for how they use "git
diff".
There are already options like this in "git diff". I don't see how one
more changes anything.
> Now, I have another two, fundamental problems with the diff options
> defaults: you are restricting the thing to _one_ set of options, and when
> somebody wants to run without those options, she has to actively _undo_
> them.
Yep, that's what defaults are. And guess what: we _already_ have the
same thing. I have diff.renames set in my ~/.gitconfig. That does
_exactly_ what
git config --global diff.primer -M
would do. It's just a syntax that saves us from having to introduce a
boatload of new variables, one per command line option.
> Remember, sometimes you need another set of options. Like, when I send
> mail to a Git user, I want "-M -C -C", when I send mail to a non-Git user,
> I do not want any additional options (and try to undo "-M -C -C" on the
> command line, good luck), and sometimes it is much easier to see what
> happened with a word diff.
This is a strawman. You have described a scenario where an alias or a
wrapper script is a better fit. Great, then use that mechanism in this
scenario. But that doesn't mean there aren't other scenarios where a
different setup makes more sense (I think Keith's original goal was to
use "-w").
> So what I need are three different sets of diff options.
>
> Guess how well that works with aliases -- we are talking command line
> here after all, right?
Personally, I have always found the suggestion that users simply put
their preferences into an alias like "mydiff" to be a silly one: git has
already taken the obvious good names, so now I am stuck using "git
mydiff" forever and forgetting that "git diff" even exists.
But then, I don't have your "three sets of options" scenario. I just
want one set of defaults. So I don't have a need to name each one, and
having to choose a different name becomes a detriment rather than an
advantage.
However, there are two other drawbacks of aliases that I can think of:
1. They are tied to a specific command, whereas diff options are tied
to the concept of diffing. So now I have to write an alias (with a
new name) for each command:
git config alias.mylog 'log -w'
git config alias.mydiff 'diff -w'
git config alias.myshow 'show -w'
2. They can't change defaults based on the file to be diffed. One of
the things Keith mentioned (and I don't remember if this was
implemented in his patch series) was supporting this for
gitattributes diff drivers. How do I do
git config diff.tex.primer -w
using aliases?
But now you have me defending Keith's proposal, which he should be doing
himself ;P I actually am not that excited about it, and will probably
not use it for anything myself. But I think:
- it lets the user accomplish useful things that would not
otherwise be possible
- supporting it in "git diff" does not create any danger that was not
already there
which means that I have no objection to a clean version being applied.
-Peff
^ permalink raw reply
* Re: Emacs git-mode feature request: support fill-paragraph correctly
From: Bruce Stephens @ 2009-01-26 12:15 UTC (permalink / raw)
To: Peter Simons; +Cc: git
In-Reply-To: <87tz7mth3g.fsf@write-only.cryp.to>
Peter Simons <simons@cryp.to> writes:
[...]
> Other modes, such as message-mode, do support that kind of thing
> correctly, so apparently it is possible to configure what the editor
> considers as a paragraph. Is there some Emacs wizard out there who'd
> be kind enough to improve git-mode accordingly?
I suspect this doesn't directly relate to git-mode. What mode does
emacs say you're in at this point? I'm guessing the buffer name is
COMMIT_EDITMSG and the mode is fundamental-mode?
In that case you could stick this in your .emacs if you wanted to use
message-mode:
(setq auto-mode-alist (cons '("COMMIT_EDITMSG" . message-mode) auto-mode-alist))
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Jakub Narebski @ 2009-01-26 12:31 UTC (permalink / raw)
To: Dill; +Cc: git
In-Reply-To: <60646ee10901250941s34f7accem1b74fc201e895a41@mail.gmail.com>
Dill <sarpulhu@gmail.com> writes:
> Is there a plan to include translations of the Documentation within
> Git or should they exist outside of the project?
First, you should have mention that you are talking about translating
_Documentation_, because there are at least three areas which can be
translated:
* GUI (gtik and git-gui), which is being done
* Documentation, which leads to translated manpages and HTML docs
* git command messages (but only porcelain, as scripts parse
git command output)
Second, the problem with translating Documentation is twofold. There
is fundamental problem with translated documentation becoming out of
sync (stale) unless you have people ready to follow changes to main
documentation. This is less of a problem with GUI messages, as they
change less frequently, there are shorter, and there is less volume of
them.
And there is technical problem of how to organize translations. With
GUI translations we just use gettext conventions. I don't know any
such convention for docs: there is suffix convention used by Apache to
serve var language files (filename.txt.de, filename.txt.ja.euc-jp),
and there is gettext-like convention of separate directories used by
manpages (en/filename.txt, ja/filename.txt). And there is question
where to put untranslated original... And to enhance Makefile to put
translations in correct place. And possibly alter RPM .spec file to
put translations in separate packages.
So I am not sure if translated documentation should be not maintained
out of tree...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] contrib git-resurrect: find traces of a branch name and resurrect it
From: Thomas Rast @ 2009-01-26 11:54 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <200901231500.23182.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 1817 bytes --]
Hi Stephen,
Sorry for the long delay. I'm going to roll a v2 with two small
fixes. After that it's all yours ;-)
Boyd Stephen Smith Jr. wrote:
[...]
> 6. Try to resurrect branch from origin/pu, get local version I just deleted.
> 7. delete reflog for that branch
> 8. Try to resurrect branch from origin/pu, get local version I merged into
> master at some point.
> 9. Add new option.
>
> So, I added a couple of options locally: --only-merges, so it would only look
> at the first line of commit logs, ignoring my local reflogs entirely;
> and --revisions, to specify arguments to pass to rev-list so it wouldn't even
> see my local merges (I passed 'origin/pu origin/next').
>
> Yeah, my usage might be abusage, but it worked for me. :)
I'm fine with adding such an option, but I still wonder what was wrong
with the original scheme of asking 'git rev-list -1' for the newest
commit. I thought rev-list always listed by date, so that command
should always pick the newest candidate commit from all candidates
selected. Do you have an example where that breaks? Or did you just
have a use-case in which you wanted something other than the newest
candidate?
> In my local version, which I was going to try and clean up over the weekend, I
> was going to support both, by borrowing refspec syntax from fetch/push.
> Specifically. Resurrecting 'js/notes' as 'pu/js/notes' would look like:
> git-resurrect -H js/notes:pu/js/notes
>
> Would you object to a patch that dropped -b in favor of the refspec syntax?
No, that would be fine by me.
> There seems to be some needless redundancy between USAGE and OPTIONS_SPEC.
>
> Would you object to a patch that used $USAGE inside OPTIONS_SPEC?
Also a good idea.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v2] contrib git-resurrect: find traces of a branch name and resurrect it
From: Thomas Rast @ 2009-01-26 12:40 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <200901261254.39360.trast@student.ethz.ch>
Add a tool 'git-resurrect.sh <branch>' that tries to find traces of
the <branch> in the HEAD reflog and, optionally, all merge commits in
the repository. It can then resurrect the branch, pointing it at the
most recent of all candidate commits found.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Fixed the -h to upper-case in the short options summaries, and removed
a stray 'q' in the default assignment of new_name.
contrib/git-resurrect.sh | 140 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 140 insertions(+), 0 deletions(-)
create mode 100755 contrib/git-resurrect.sh
diff --git a/contrib/git-resurrect.sh b/contrib/git-resurrect.sh
new file mode 100755
index 0000000..3c1c946
--- /dev/null
+++ b/contrib/git-resurrect.sh
@@ -0,0 +1,140 @@
+#!/bin/sh
+
+USAGE="[-H] [-r] [-m] [-t] [-n] [-b <newname>] <name>"
+LONG_USAGE="git-resurrect attempts to find traces of a branch tip
+called <name>, and tries to resurrect it. Currently, the reflog is
+searched for checkout messages, and with -r also merge messages. With
+-m and -t, the history of all refs is scanned for Merge <name> into
+other/Merge <other> into <name> (respectively) commit subjects, which
+is rather slow but allows you to resurrect other people's topic
+branches."
+
+OPTIONS_SPEC="\
+git resurrect [-H] [-r] [-m] [-t] [-n] [-b <newname>] <name>
+--
+b,branch= save branch as <newname> instead of <name>
+H,try-hard same as -r -m -t
+r,reflog-merges scan for merges recorded in reflog
+m,merges scan for merges into other branches (slow)
+t,merge-targets scan for merges of other branches into <name>
+n,dry-run don't recreate the branch"
+
+. git-sh-setup
+cd_to_toplevel
+
+search_reflog () {
+ sed -n 's~^\([^ ]*\) .*\tcheckout: moving from '"$1"' .*~\1~p' \
+ < .git/logs/HEAD
+}
+
+search_reflog_merges () {
+ sed -n 's~^[^ ]* \([^ ]*\) .*\tmerge '"$1"':~\1~p' \
+ < .git/logs/HEAD
+}
+
+search_merges () {
+ git rev-list --pretty=tformat:"%h %p:%s" --all |
+ grep "Merge branch.*'$branch'.*into" |
+ while read sha rest; do
+ parents="$(echo "$rest" | cut -d: -f1)"
+ case "$parents" in
+ *' '*' '*)
+ warn "$branch took part in octopus merge $sha"
+ warn "check manually!"
+ ;;
+ *' '*)
+ echo "$parents" | cut -d' ' -f2
+ ;;
+ esac
+ done
+}
+
+search_merge_targets () {
+ git rev-list --pretty=tformat:"%h %s" --all |
+ grep "Merge branch '[^']*' into $branch$" |
+ cut -d' ' -f1
+}
+
+dry_run=
+scan_reflog_merges=
+scan_merges=
+scan_merge_targets=
+new_name=
+
+while test "$#" != 0; do
+ case "$1" in
+ -b|--branch)
+ shift
+ new_name="$1"
+ ;;
+ -n|--dry-run)
+ dry_run=t
+ ;;
+ -m|--merges)
+ scan_merges=t
+ ;;
+ -r|--reflog_merges)
+ scan_reflog_merges=t
+ ;;
+ -t|--merge-targets)
+ scan_merge_targets=t
+ ;;
+ -H|--try-hard)
+ scan_reflog_merges=t
+ scan_merges=t
+ scan_merge_targets=t
+ ;;
+ --)
+ shift
+ break
+ ;;
+ *)
+ usage
+ ;;
+ esac
+ shift
+done
+
+test "$#" = 1 || usage
+
+branch="$1"
+test -z "$new_name" && new_name="$branch"
+
+candidates="$(search_reflog $1)"
+if test ! -z "$scan_reflog_merges"; then
+ candidates="$candidates $(search_reflog_merges $1)"
+fi
+if test ! -z "$scan_merges"; then
+ candidates="$candidates $(search_merges $1)"
+fi
+if test ! -z "$scan_merge_targets"; then
+ candidates="$candidates $(search_merge_targets $1)"
+fi
+
+candidates="$(git rev-parse $candidates | sort -u)"
+
+if test -z "$candidates"; then
+ hint=
+ test "z$scan_merges$scan_reflog_merges$scan_merge_targets" != "zttt" \
+ && hint="(maybe try again with -H)"
+ die "no candidates for $branch found" $hint
+fi
+
+echo "** Candidates for $branch **"
+for cmt in $candidates; do
+ git --no-pager log --pretty=oneline --abbrev-commit -1 $cmt
+done
+
+newest="$(git rev-list -1 $candidates)"
+if test ! -z "$dry_run"; then
+ printf "Most recent: "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+elif ! git rev-parse --verify --quiet $new_name >/dev/null; then
+ printf "** Restoring $new_name to "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ git branch $new_name $newest
+else
+ printf "Most recent: "
+ git --no-pager log -1 --pretty=tformat:"%h %s" $newest
+ echo "** $new_name already exists, doing nothing"
+fi
--
1.6.1.469.g6f3d5
^ permalink raw reply related
* [PATCHv2] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-26 12:45 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
When PATH_INFO is defined, static files such as the defalt CSS or the
shortcut icon are not accessible beyond the summary page (e.g. in
shortlog or commit view).
Fix this by adding a <base> tag pointing to the script base URL.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
It's sick that $cgi->url() has no way to print the script base url
without path_info information (or that, if it has, it's very well
hidden).
gitweb/gitweb.perl | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..910da35 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,6 +2901,14 @@ sub git_header_html {
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
+# the stylesheet, favicon etc urls won't work correctly with path_info unless we set the appropriate base URL
+ if ($ENV{'PATH_INFO'}) {
+ my $base = $my_uri;
+ my $sname = $ENV{'SCRIPT_NAME'};
+ $base =~ s,\Q$sname\E$,,;
+ $base .= "/";
+ print "<base href=\"$base\"/>\n";
+ }
# print out each stylesheet that exist
if (defined $stylesheet) {
#provides backwards capability for those people who define style sheet in a config file
--
1.5.6.5
^ permalink raw reply related
* Re: Translations [of Documentation] in Git release?
From: Peter Krefting @ 2009-01-26 13:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Dill, Git Mailing List
In-Reply-To: <m3hc3mxn9d.fsf@localhost.localdomain>
Jakub Narebski:
> With GUI translations we just use gettext conventions. I don't know
> any such convention for docs:
There is a lot of documentation being translated using PO files. po4a -
http://po4a.alioth.debian.org/ - is a nice starting point for that.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Translations [of Documentation] in Git release?
From: Miklos Vajna @ 2009-01-26 13:34 UTC (permalink / raw)
To: Peter Krefting; +Cc: Jakub Narebski, Dill, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0901261426350.7798@ds9.cixit.se>
[-- Attachment #1: Type: text/plain, Size: 426 bytes --]
On Mon, Jan 26, 2009 at 02:27:17PM +0100, Peter Krefting <peter@softwolves.pp.se> wrote:
> There is a lot of documentation being translated using PO files. po4a -
> http://po4a.alioth.debian.org/ - is a nice starting point for that.
Actually it supports asciidoc files as well, but only the CVS version,
so probably the po4a version installed on most machines (as a distro
package) is not capable of managing asciidoc files.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Allow format-patch to create patches for merges
From: Nathan W. Panike @ 2009-01-26 14:04 UTC (permalink / raw)
To: git; +Cc: Nathan W. Panike, Johannes.Schindelin, gitster, aspotashev
The behavior for git format-patch is to ignore merge commits, producing an
empty patch. The code does not allow the user to change this behavior. This
patch changes that behavior by allowing the user to specify -c or -m at the
command line to produce a patch for a merge commit.
---
Hi:
I am sure there are good reasons for the current behavior of format-patch, but
it seems to me that if the user explicitly wants to produce a patch for a merge
commit, he should be allowed to do so. If merge_commit represents a merge,
then this patch allows the user to issue the command
git format-patch -m -1 $merge_commit
or
git format-patch -c -1 $merge_commit
and actually produce a patch. The current behavior is that neither command
will produce a patch. With or without the patch applied, the command
git format-patch -1 $merge_commit
does not produce a patch when merge_commit is a merge. Thus the patch does not
change the default behavior of ignoring merges, at least by the limited testing
I have done.
Thanks for your consideration.
Nathan Panike
builtin-log.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 2ae39af..ea4729d 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -994,10 +994,6 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
continue;
}
- /* ignore merges */
- if (commit->parents && commit->parents->next)
- continue;
-
if (ignore_if_in_upstream &&
has_commit_patch_id(commit, &ids))
continue;
--
1.6.1.1.GIT
^ permalink raw reply related
* [PATCH 2/3] Make has_commit non-static
From: Jake Goulding @ 2009-01-26 14:13 UTC (permalink / raw)
To: git; +Cc: gitster, Jake Goulding
In-Reply-To: <1232979205-17161-1-git-send-email-goulding@vivisimo.com>
Moving has_commit from branch to a common location in preparation for
using it in tag. Renaming it to commit_has_any_in_commit_list to be
more unique.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
Function renamed to less-generic name as suggested by Junio.
builtin-branch.c | 20 +++-----------------
commit.c | 16 ++++++++++++++++
commit.h | 1 +
3 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 82d6fb2..a30ef76 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -193,21 +193,6 @@ struct ref_list {
int kinds;
};
-static int has_commit(struct commit *commit, struct commit_list *with_commit)
-{
- if (!with_commit)
- return 1;
- while (with_commit) {
- struct commit *other;
-
- other = with_commit->item;
- with_commit = with_commit->next;
- if (in_merge_bases(other, &commit, 1))
- return 1;
- }
- return 0;
-}
-
static int append_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data)
{
struct ref_list *ref_list = (struct ref_list*)(cb_data);
@@ -231,7 +216,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
return error("branch '%s' does not point at a commit", refname);
/* Filter with with_commit if specified */
- if (!has_commit(commit, ref_list->with_commit))
+ if (!commit_has_any_in_commit_list(commit, ref_list->with_commit))
return 0;
/* Don't add types the caller doesn't want */
@@ -401,7 +386,8 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
detached = (detached && (kinds & REF_LOCAL_BRANCH));
- if (detached && head_commit && has_commit(head_commit, with_commit)) {
+ if (detached && head_commit &&
+ commit_has_any_in_commit_list(head_commit, with_commit)) {
struct ref_item item;
item.name = xstrdup("(no branch)");
item.kind = REF_LOCAL_BRANCH;
diff --git a/commit.c b/commit.c
index c99db16..97c8a8a 100644
--- a/commit.c
+++ b/commit.c
@@ -705,6 +705,22 @@ struct commit_list *get_merge_bases(struct commit *one, struct commit *two,
return get_merge_bases_many(one, 1, &two, cleanup);
}
+int commit_has_any_in_commit_list(struct commit *commit,
+ struct commit_list *with_commit)
+{
+ if (!with_commit)
+ return 1;
+ while (with_commit) {
+ struct commit *other;
+
+ other = with_commit->item;
+ with_commit = with_commit->next;
+ if (in_merge_bases(other, &commit, 1))
+ return 1;
+ }
+ return 0;
+}
+
int in_merge_bases(struct commit *commit, struct commit **reference, int num)
{
struct commit_list *bases, *b;
diff --git a/commit.h b/commit.h
index 3a7b06a..4084102 100644
--- a/commit.h
+++ b/commit.h
@@ -133,6 +133,7 @@ extern int is_repository_shallow(void);
extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
+int commit_has_any_in_commit_list(struct commit *, struct commit_list *);
int in_merge_bases(struct commit *, struct commit **, int);
extern int interactive_add(int argc, const char **argv, const char *prefix);
--
1.6.0.6
^ permalink raw reply related
* [PATCH 3/3] Add --contains flag to git tag
From: Jake Goulding @ 2009-01-26 14:13 UTC (permalink / raw)
To: git; +Cc: gitster, Jake Goulding
In-Reply-To: <1232979205-17161-2-git-send-email-goulding@vivisimo.com>
This functions similar to git branch --contains - it will show all
tags that contain the specified commit. Indeed, it uses the same
lookup mechanisms as git branch.
Also adding documentation and tests for new option.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
Updated error semantics as suggested by Junio.
Documentation/git-tag.txt | 5 ++-
builtin-tag.c | 30 +++++++++++-
t/t7004-tag.sh | 115 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 147 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index e44f543..533d18b 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
<name> [<commit> | <object>]
'git tag' -d <name>...
-'git tag' [-n[<num>]] -l [<pattern>]
+'git tag' [-n[<num>]] -l [--contains <commit>] [<pattern>]
'git tag' -v <name>...
DESCRIPTION
@@ -68,6 +68,9 @@ OPTIONS
List tags with names that match the given pattern (or all if no pattern is given).
Typing "git tag" without arguments, also lists all tags.
+--contains <commit>::
+ Only list tags which contain the specified commit.
+
-m <msg>::
Use the given tag message (instead of prompting).
If multiple `-m` options are given, their values are
diff --git a/builtin-tag.c b/builtin-tag.c
index a398499..17082de 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -26,6 +26,7 @@ static char signingkey[1000];
struct tag_filter {
const char *pattern;
int lines;
+ struct commit_list *with_commit;
};
#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----"
@@ -42,6 +43,17 @@ static int show_reference(const char *refname, const unsigned char *sha1,
char *buf, *sp, *eol;
size_t len;
+ if (filter->with_commit) {
+ struct commit *commit;
+
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit)
+ return 0;
+ if (!commit_has_any_in_commit_list(commit,
+ filter->with_commit))
+ return 0;
+ }
+
if (!filter->lines) {
printf("%s\n", refname);
return 0;
@@ -79,7 +91,8 @@ static int show_reference(const char *refname, const unsigned char *sha1,
return 0;
}
-static int list_tags(const char *pattern, int lines)
+static int list_tags(const char *pattern, int lines,
+ struct commit_list *with_commit)
{
struct tag_filter filter;
@@ -88,6 +101,7 @@ static int list_tags(const char *pattern, int lines)
filter.pattern = pattern;
filter.lines = lines;
+ filter.with_commit = with_commit;
for_each_tag_ref(show_reference, (void *) &filter);
@@ -360,6 +374,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
list = 0, delete = 0, verify = 0;
const char *msgfile = NULL, *keyid = NULL;
struct msg_arg msg = { 0, STRBUF_INIT };
+ struct commit_list *with_commit = NULL;
struct option options[] = {
OPT_BOOLEAN('l', NULL, &list, "list tag names"),
{ OPTION_INTEGER, 'n', NULL, &lines, NULL,
@@ -378,6 +393,14 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_STRING('u', NULL, &keyid, "key-id",
"use another key to sign the tag"),
OPT_BOOLEAN('f', NULL, &force, "replace the tag if exists"),
+
+ OPT_GROUP("Tag listing options"),
+ {
+ OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
+ "print only tags that contain the commit",
+ PARSE_OPT_LASTARG_DEFAULT,
+ parse_opt_with_commit, (intptr_t)"HEAD",
+ },
OPT_END()
};
@@ -402,9 +425,12 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
if (list + delete + verify > 1)
usage_with_options(git_tag_usage, options);
if (list)
- return list_tags(argv[0], lines == -1 ? 0 : lines);
+ return list_tags(argv[0], lines == -1 ? 0 : lines,
+ with_commit);
if (lines != -1)
die("-n option is only allowed with -l.");
+ if (with_commit)
+ die("--contains option is only allowed with -l.");
if (delete)
return for_each_tag_name(argv, delete_tag);
if (verify)
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index f377fea..69501e2 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1090,6 +1090,121 @@ test_expect_success 'filename for the message is relative to cwd' '
git cat-file tag tag-from-subdir-2 | grep "in sub directory"
'
+# create a few more commits to test --contains
+
+hash1=$(git rev-parse HEAD)
+
+test_expect_success 'creating second commit and tag' '
+ echo foo-2.0 >foo &&
+ git add foo &&
+ git commit -m second
+ git tag v2.0
+'
+
+hash2=$(git rev-parse HEAD)
+
+test_expect_success 'creating third commit without tag' '
+ echo foo-dev >foo &&
+ git add foo &&
+ git commit -m third
+'
+
+hash3=$(git rev-parse HEAD)
+
+# simple linear checks of --continue
+
+cat > expected <<EOF
+v0.2.1
+v1.0
+v1.0.1
+v1.1.3
+v2.0
+EOF
+
+test_expect_success 'checking that first commit is in all tags (hash)' "
+ git tag -l --contains $hash1 v* >actual
+ test_cmp expected actual
+"
+
+# other ways of specifying the commit
+test_expect_success 'checking that first commit is in all tags (tag)' "
+ git tag -l --contains v1.0 v* >actual
+ test_cmp expected actual
+"
+
+test_expect_success 'checking that first commit is in all tags (relative)' "
+ git tag -l --contains HEAD~2 v* >actual
+ test_cmp expected actual
+"
+
+cat > expected <<EOF
+v2.0
+EOF
+
+test_expect_success 'checking that second commit only has one tag' "
+ git tag -l --contains $hash2 v* >actual
+ test_cmp expected actual
+"
+
+
+cat > expected <<EOF
+EOF
+
+test_expect_success 'checking that third commit has no tags' "
+ git tag -l --contains $hash3 v* >actual
+ test_cmp expected actual
+"
+
+# how about a simple merge?
+
+test_expect_success 'creating simple branch' '
+ git branch stable v2.0 &&
+ git checkout stable &&
+ echo foo-3.0 > foo &&
+ git commit foo -m fourth
+ git tag v3.0
+'
+
+hash4=$(git rev-parse HEAD)
+
+cat > expected <<EOF
+v3.0
+EOF
+
+test_expect_success 'checking that branch head only has one tag' "
+ git tag -l --contains $hash4 v* >actual
+ test_cmp expected actual
+"
+
+test_expect_success 'merging original branch into this branch' '
+ git merge --strategy=ours master &&
+ git tag v4.0
+'
+
+cat > expected <<EOF
+v4.0
+EOF
+
+test_expect_success 'checking that original branch head has one tag now' "
+ git tag -l --contains $hash3 v* >actual
+ test_cmp expected actual
+"
+
+cat > expected <<EOF
+v0.2.1
+v1.0
+v1.0.1
+v1.1.3
+v2.0
+v3.0
+v4.0
+EOF
+
+test_expect_success 'checking that initial commit is in all tags' "
+ git tag -l --contains $hash1 v* >actual
+ test_cmp expected actual
+"
+
# mixing modes and options:
test_expect_success 'mixing incompatibles modes and options is forbidden' '
--
1.6.0.6
^ permalink raw reply related
* [PATCH 1/3] Make opt_parse_with_commit non-static
From: Jake Goulding @ 2009-01-26 14:13 UTC (permalink / raw)
To: git; +Cc: gitster, Jake Goulding
Moving opt_parse_with_commit from branch to a common location in
preparation for using it in tag. Renamed it to correspond to naming
convention of other option parsing functions.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
---
builtin-branch.c | 20 ++------------------
parse-options.c | 17 +++++++++++++++++
parse-options.h | 1 +
3 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 02fa38f..82d6fb2 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -466,22 +466,6 @@ static void rename_branch(const char *oldname, const char *newname, int force)
strbuf_release(&newsection);
}
-static int opt_parse_with_commit(const struct option *opt, const char *arg, int unset)
-{
- unsigned char sha1[20];
- struct commit *commit;
-
- if (!arg)
- return -1;
- if (get_sha1(arg, sha1))
- die("malformed object name %s", arg);
- commit = lookup_commit_reference(sha1);
- if (!commit)
- die("no such commit %s", arg);
- commit_list_insert(commit, opt->value);
- return 0;
-}
-
static int opt_parse_merge_filter(const struct option *opt, const char *arg, int unset)
{
merge_filter = ((opt->long_name[0] == 'n')
@@ -517,13 +501,13 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
"print only branches that contain the commit",
PARSE_OPT_LASTARG_DEFAULT,
- opt_parse_with_commit, (intptr_t)"HEAD",
+ parse_opt_with_commit, (intptr_t)"HEAD",
},
{
OPTION_CALLBACK, 0, "with", &with_commit, "commit",
"print only branches that contain the commit",
PARSE_OPT_HIDDEN | PARSE_OPT_LASTARG_DEFAULT,
- opt_parse_with_commit, (intptr_t) "HEAD",
+ parse_opt_with_commit, (intptr_t) "HEAD",
},
OPT__ABBREV(&abbrev),
diff --git a/parse-options.c b/parse-options.c
index 9eb55cc..4c5d09d 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -1,6 +1,7 @@
#include "git-compat-util.h"
#include "parse-options.h"
#include "cache.h"
+#include "commit.h"
#define OPT_SHORT 1
#define OPT_UNSET 2
@@ -506,6 +507,22 @@ int parse_opt_verbosity_cb(const struct option *opt, const char *arg,
return 0;
}
+int parse_opt_with_commit(const struct option *opt, const char *arg, int unset)
+{
+ unsigned char sha1[20];
+ struct commit *commit;
+
+ if (!arg)
+ return -1;
+ if (get_sha1(arg, sha1))
+ return error("malformed object name %s", arg);
+ commit = lookup_commit_reference(sha1);
+ if (!commit)
+ return error("no such commit %s", arg);
+ commit_list_insert(commit, opt->value);
+ return 0;
+}
+
/*
* This should really be OPTION_FILENAME type as a part of
* parse_options that take prefix to do this while parsing.
diff --git a/parse-options.h b/parse-options.h
index 034162e..9122905 100644
--- a/parse-options.h
+++ b/parse-options.h
@@ -151,6 +151,7 @@ extern int parse_options_end(struct parse_opt_ctx_t *ctx);
extern int parse_opt_abbrev_cb(const struct option *, const char *, int);
extern int parse_opt_approxidate_cb(const struct option *, const char *, int);
extern int parse_opt_verbosity_cb(const struct option *, const char *, int);
+extern int parse_opt_with_commit(const struct option *, const char *, int);
#define OPT__VERBOSE(var) OPT_BOOLEAN('v', "verbose", (var), "be verbose")
#define OPT__QUIET(var) OPT_BOOLEAN('q', "quiet", (var), "be quiet")
--
1.6.0.6
^ permalink raw reply related
* rerere: how to remove an erroneous resolution?
From: SZEDER Gábor @ 2009-01-26 14:42 UTC (permalink / raw)
To: git
Hi,
some time ago I mistakenly resolved a merge conflict incorrectly. Of
course, rerere noted the erroneous conflict resolution, and whenever
the same merge conflict occurs rerere offers me that erroneous
conflict resolution, even though I correct it each time.
So, the question is how could I make rerere forget that particular
merge conflict resolution? Is it at all possible?
Thanks,
Gábor
^ permalink raw reply
* Re: rerere: how to remove an erroneous resolution?
From: SZEDER Gábor @ 2009-01-26 15:13 UTC (permalink / raw)
To: git
In-Reply-To: <20090126144239.GA494@neumann>
On Mon, Jan 26, 2009 at 03:42:39PM +0100, SZEDER Gábor wrote:
> some time ago I mistakenly resolved a merge conflict incorrectly. Of
> course, rerere noted the erroneous conflict resolution, and whenever
> the same merge conflict occurs rerere offers me that erroneous
> conflict resolution, even though I correct it each time.
>
> So, the question is how could I make rerere forget that particular
> merge conflict resolution? Is it at all possible?
Ok, I should have investigated a little longer before sending that
email.
I thought that .git/rr-cache contains some kind of sha1-named objects,
and did not realize that those are indeed directories with just
plaintext pre- and postimage files in it. So, after some grepping I
could identify the sought conflict resolution fairly easily, and
correct it.
Best,
Gábor
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Jay Soffian @ 2009-01-26 15:29 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Keith Cascio, Junio C Hamano, git
In-Reply-To: <20090126111605.GB19993@coredump.intra.peff.net>
On Mon, Jan 26, 2009 at 6:16 AM, Jeff King <peff@peff.net> wrote:
> I don't want to break existing setups, either. But at some point you
> have to say "this is porcelain, so don't rely on there not being any
> user-triggered effects in its behavior". If porcelain is cast in stone,
> then what is the point in differentiating plumbing from porcelain?
>
> And when the line is blurred (as I think it is in several places)
Aside, AIX has commands that are run both directly or via smit (a
curses-based interface). When smit calls the commands, it passes a
switch to let said commands know that they are being run from smit.
e.g.:
-J
This flag is used when the installp command is executed from the
System Management Interface Tool (SMIT) menus.
Perhaps adding such a concept to those git commands which can be used
in both porcelain and plumbing contexts would be useful for git.
j.
^ 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