* [PATCH (GIT-GUI,MINGW) 0/3] Fix OpenSSH & Git-Gui integration in msysgit
From: Alexander Gavrilov @ 2008-10-20 16:02 UTC (permalink / raw)
To: git; +Cc: msysgit, Johannes Sixt, Shawn O. Pearce, Junio C Hamano
It is a well known problem on msysgit that when ssh is started
from git-gui during a fetch, any situations where it normally
displays a prompt to the user cause it to hang silently. It is
even worse than the situation on Linux, where the prompts appear
on the terminal that started the GUI.
This combination of 3 patches aims to eliminate this problem. One
of them changes a flag that is used to spawn the ssh executable,
to make it recognize that it does not have a valid controlling
console. The other two add features to git-gui that make ssh
usage more convenient, including a simple implementation of an
SSH_ASKPASS program.
When the patches are applied, all SSH prompts in msysgit
appear in a GUI dialog box in the middle of the screen.
Additionally, it is possible to view or create an OpenSSH
key pair directly from git-gui.
Note: This was already posted to the msysgit list. The only differences
are that git-gui now sets a more evidently fake value for DISPLAY,
and the last patch has been acked.
GIT-GUI:
git-gui: Add a dialog that shows the OpenSSH public key.
---
git-gui.sh | 4 ++
lib/sshkey.tcl | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 130 insertions(+), 0 deletions(-)
create mode 100644 lib/sshkey.tcl
git-gui: Add a simple implementation of SSH_ASKPASS.
---
Makefile | 2 ++
git-gui.sh | 12 ++++++++++++
git-gui--askpass | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 73 insertions(+), 0 deletions(-)
create mode 100755 git-gui--askpass
CORE(MINGW):
Windows: Make OpenSSH properly detect tty detachment.
---
compat/mingw.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCH (GIT-GUI,MINGW) 1/3] git-gui: Add a dialog that shows the OpenSSH public key.
From: Alexander Gavrilov @ 2008-10-20 16:02 UTC (permalink / raw)
To: git; +Cc: msysgit, Johannes Sixt, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <1224518540-23782-1-git-send-email-angavrilov@gmail.com>
Generating a new SSH key or finding an existing one may
be a difficult task for non-technical users, especially
on Windows.
This commit adds a new dialog that shows the public key,
or allows the user to generate a new one if none were found.
Since this is a convenience/informational feature for new
users, and the dialog is mostly read-only, it is located
in the Help menu.
The command line used to invoke ssh-keygen is designed to
force it to use SSH_ASKPASS if available, or accept empty
passphrases, but _never_ wait for user response on the tty.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
git-gui.sh | 4 ++
lib/sshkey.tcl | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 130 insertions(+), 0 deletions(-)
create mode 100644 lib/sshkey.tcl
diff --git a/git-gui.sh b/git-gui.sh
index 4f95139..e4d1f70 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2536,6 +2536,10 @@ proc start_browser {url} {
.mbar.help add command -label [mc "Online Documentation"] \
-command [list start_browser $doc_url]
+
+.mbar.help add command -label [mc "Show SSH Key"] \
+ -command do_ssh_key
+
unset doc_path doc_url
# -- Standard bindings
diff --git a/lib/sshkey.tcl b/lib/sshkey.tcl
new file mode 100644
index 0000000..82a1a80
--- /dev/null
+++ b/lib/sshkey.tcl
@@ -0,0 +1,126 @@
+# git-gui about git-gui dialog
+# Copyright (C) 2006, 2007 Shawn Pearce
+
+proc find_ssh_key {} {
+ foreach name {~/.ssh/id_dsa.pub ~/.ssh/id_rsa.pub ~/.ssh/identity.pub} {
+ if {[file exists $name]} {
+ set fh [open $name r]
+ set cont [read $fh]
+ close $fh
+ return [list $name $cont]
+ }
+ }
+
+ return {}
+}
+
+proc do_ssh_key {} {
+ global sshkey_title have_tk85 sshkey_fd
+
+ set w .sshkey_dialog
+ if {[winfo exists $w]} {
+ raise $w
+ return
+ }
+
+ toplevel $w
+ wm transient $w .
+
+ set finfo [find_ssh_key]
+ if {$finfo eq {}} {
+ set sshkey_title [mc "No keys found."]
+ set gen_state normal
+ } else {
+ set sshkey_title [mc "Found a public key in: %s" [lindex $finfo 0]]
+ set gen_state disabled
+ }
+
+ frame $w.header -relief flat
+ label $w.header.lbl -textvariable sshkey_title -anchor w
+ button $w.header.gen -text [mc "Generate Key"] \
+ -command [list make_ssh_key $w] -state $gen_state
+ pack $w.header.lbl -side left -expand 1 -fill x
+ pack $w.header.gen -side right
+ pack $w.header -fill x -pady 5 -padx 5
+
+ text $w.contents -width 60 -height 10 -wrap char -relief sunken
+ pack $w.contents -fill both -expand 1
+ if {$have_tk85} {
+ $w.contents configure -inactiveselectbackground darkblue
+ }
+
+ frame $w.buttons
+ button $w.buttons.close -text [mc Close] \
+ -default active -command [list destroy $w]
+ pack $w.buttons.close -side right
+ button $w.buttons.copy -text [mc "Copy To Clipboard"] \
+ -command [list tk_textCopy $w.contents]
+ pack $w.buttons.copy -side left
+ pack $w.buttons -side bottom -fill x -pady 5 -padx 5
+
+ if {$finfo ne {}} {
+ $w.contents insert end [lindex $finfo 1] sel
+ }
+ $w.contents configure -state disabled
+
+ bind $w <Visibility> "grab $w; focus $w.buttons.close"
+ bind $w <Key-Escape> "destroy $w"
+ bind $w <Key-Return> "destroy $w"
+ bind $w <Destroy> kill_sshkey
+ wm title $w [mc "Your OpenSSH Public Key"]
+ tk::PlaceWindow $w widget .
+ tkwait window $w
+}
+
+proc make_ssh_key {w} {
+ global sshkey_title sshkey_output sshkey_fd
+
+ set sshkey_title [mc "Generating..."]
+ $w.header.gen configure -state disabled
+
+ set cmdline [list sh -c {echo | ssh-keygen -q -t rsa -f ~/.ssh/id_rsa 2>&1}]
+
+ if {[catch { set sshkey_fd [_open_stdout_stderr $cmdline] } err]} {
+ error_popup [mc "Could not start ssh-keygen:\n\n%s" $err]
+ return
+ }
+
+ set sshkey_output {}
+ fconfigure $sshkey_fd -blocking 0
+ fileevent $sshkey_fd readable [list read_sshkey_output $sshkey_fd $w]
+}
+
+proc kill_sshkey {} {
+ global sshkey_fd
+ if {![info exists sshkey_fd]} return
+ catch { kill_file_process $sshkey_fd }
+ catch { close $sshkey_fd }
+}
+
+proc read_sshkey_output {fd w} {
+ global sshkey_fd sshkey_output sshkey_title
+
+ set sshkey_output "$sshkey_output[read $fd]"
+ if {![eof $fd]} return
+
+ fconfigure $fd -blocking 1
+ unset sshkey_fd
+
+ $w.contents configure -state normal
+ if {[catch {close $fd} err]} {
+ set sshkey_title [mc "Generation failed."]
+ $w.contents insert end $err
+ $w.contents insert end "\n"
+ $w.contents insert end $sshkey_output
+ } else {
+ set finfo [find_ssh_key]
+ if {$finfo eq {}} {
+ set sshkey_title [mc "Generation succeded, but no keys found."]
+ $w.contents insert end $sshkey_output
+ } else {
+ set sshkey_title [mc "Your key is in: %s" [lindex $finfo 0]]
+ $w.contents insert end [lindex $finfo 1] sel
+ }
+ }
+ $w.contents configure -state disable
+}
--
1.6.0.20.g6148bc
^ permalink raw reply related
* Re: bug: git-stash save and symbolic links
From: Simon Strandgaard @ 2008-10-20 15:39 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <df1390cc0810200832i4fa974fx1d70ed489aa1be02@mail.gmail.com>
On Mon, Oct 20, 2008 at 5:32 PM, Simon Strandgaard <neoneye@gmail.com> wrote:
> On Mon, Oct 20, 2008 at 5:17 PM, Jeff King <peff@peff.net> wrote:
>> On Mon, Oct 20, 2008 at 10:34:53AM +0200, Simon Strandgaard wrote:
> [snip]
>> What version of git are you running (though I tried a few different
>> ones, and all passed my test)?
>
>
> I have made some changes, so it can be reproduced
[snip]
Sorry, forget the other run.sh I forgot to add the dir to the repository.
Here the linked dir is included in the repository.
prompt> sh run.sh
Initialized empty Git repository in /Users/neoneye/Desktop/test/repo/.git/
Created initial commit b904776: one
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
Created commit 19746b5: two
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 test/file2
before stash
fatal: Not a git repository
fatal: Not a git repository
fatal: Not a git repository
You do not have the initial commit yet
prompt> cat run.sh
rm -rf repo &&
rm -f linked &&
mkdir repo &&
cd repo &&
git init &&
echo content >file &&
git add file &&
git commit -m one &&
mkdir test &&
echo content >test/file2 &&
git add test/file2 &&
git commit -m two &&
cd .. &&
ln -s repo/test linked &&
cd linked &&
echo cruft >>file &&
echo before stash &&
git stash &&
echo after stash
prompt> pwd
/Users/neoneye/Desktop/test
prompt>
[snip]
> This is my computer
>
> prompt> git --version
> git version 1.5.6.2
> prompt> uname -a
> Darwin Macintosh.local 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3
> 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386
> prompt>
>
>
> --
> Simon Strandgaard
> http://toolboxapp.com/
>
--
Simon Strandgaard
http://toolboxapp.com/
^ permalink raw reply
* Re: bug: git-stash save and symbolic links
From: Simon Strandgaard @ 2008-10-20 15:32 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081020151715.GA13553@coredump.intra.peff.net>
On Mon, Oct 20, 2008 at 5:17 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 20, 2008 at 10:34:53AM +0200, Simon Strandgaard wrote:
[snip]
> What version of git are you running (though I tried a few different
> ones, and all passed my test)?
I have made some changes, so it can be reproduced
prompt> sh run.sh
Initialized empty Git repository in /Users/neoneye/Desktop/test/repo/.git/
Created initial commit a2a7d6f: one
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
before stash
fatal: Not a git repository
fatal: Not a git repository
fatal: Not a git repository
You do not have the initial commit yet
prompt> cat run.sh
rm -rf repo &&
rm -f linked &&
mkdir repo &&
cd repo &&
git init &&
echo content >file &&
git add file &&
git commit -m one &&
mkdir test &&
cd .. &&
ln -s repo/test linked &&
cd linked &&
echo cruft >>file &&
echo before stash &&
git stash &&
echo after stash
prompt> pwd
/Users/neoneye/Desktop/test
prompt>
This is my computer
prompt> git --version
git version 1.5.6.2
prompt> uname -a
Darwin Macintosh.local 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3
11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386
prompt>
--
Simon Strandgaard
http://toolboxapp.com/
^ permalink raw reply
* Re: Git graph on GitHub
From: Pedro Melo @ 2008-10-20 15:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tom Werner, git
In-Reply-To: <m3zll1ipw6.fsf@localhost.localdomain>
Hi,
On Oct 18, 2008, at 9:56 PM, Jakub Narebski wrote:
> By the way, it might be not relevant because while (if I understand
> correctly) graphs are ordered by commit date they are not aligned on
> time axis, but the timeline of commits for given author on Ohloh looks
> quite nice. (Unfortunately this part of Ohloh is not open source,
> although AFAIK it is also in Ruby). Example:
> https://www.ohloh.net/projects/git/contributors/1194000913727
> (but it doesn't use Flash).
The timeline code is open source. They are using project timeline (http://simile.mit.edu/timeline/
).
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Christian Jaeger @ 2008-10-20 15:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48FC9D87.3010303@op5.se>
Andreas Ericsson wrote:
> Christian Jaeger wrote:
>> Andreas Ericsson wrote:
>>> Christian Jaeger wrote:
>>>> If you really wanted, I suppose you could additionally look into
>>>> implementing a kind of shallow cloning that only copies objects
>>>> over the wire which are necessary for representing the subdirectory
>>>> you're interested in.
>>>>
>>>
>>> So what do you do when one such commit also affects something outside
>>> the subdirectory?
>>
>> You haven't said what you mean with "affect".
>>
>
> I mean "how would you handle a commit (and its tree-object) that updates
> all Makefiles in, for example, the Linux kernel project?". Those files
> are spread far and wide, and you'd want that change to *your* tree, but
> getting it into your tree either means you need to rewrite the tree (and
> thereby the commit) itself to get rid of uninteresting blob's from the
> tree, and you'd also have to prune the tree to not reveal the directory
> layout of the rest of the repository.
You have said "either" but not "or".
> I take it parentage could be resolved by a ridiculously large
> grafts-file.
Hm, not sure whether you mean to rescue the situation with rewritten
commits here -- but hell no, I certainly don't mean to have different
commit objects for different clones/checkouts.
> What you'd end up with wouldn't be a git repository at all anymore. It
> would be a "stump", as it'd be missing large parts of the tree entirely.
That was my point, yes.
> I'm unsure just how much you'd have to compute to be able to use such a
> stump to incorporate your changes with other users again, but I doubt it
> would be trivial to implement. Good thing it's not my itch, really.
I've been suggesting it to Garry :)
Maybe whoever writes up something on the wiki regarding subdirectory
checkouts in SVN versus Git could still care about what the "fundamental
technical" limits are versus what the current implementation (or
practicalness) imposes. It will be both a more enlightening and
potentially more future-proof explanation then.
Christian.
^ permalink raw reply
* Re: bug: git-stash save and symbolic links
From: Jeff King @ 2008-10-20 15:17 UTC (permalink / raw)
To: Simon Strandgaard; +Cc: git
In-Reply-To: <df1390cc0810200134x68a8eb1fyc7f24650c8c9c5d3@mail.gmail.com>
On Mon, Oct 20, 2008 at 10:34:53AM +0200, Simon Strandgaard wrote:
> git-stash cannot find the repository when the path is a symbolic link.
> solution for me was to cd to the absolute path and then do git-stash.
Sorry, I can't reproduce here, using this test:
mkdir repo &&
cd repo &&
git init &&
echo content >file &&
git add file &&
git commit -m one &&
cd .. &&
ln -s repo linked &&
cd repo &&
echo cruft >>file &&
git stash &&
echo non-linked directory stashed ok &&
cd ../linked &&
echo cruft >>file &&
git stash &&
echo linked directory stashed ok
What version of git are you running (though I tried a few different
ones, and all passed my test)?
-Peff
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-20 15:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <48FC5F1B.1050608@op5.se>
On 10/20/08, Andreas Ericsson <ae@op5.se> wrote:
> [..snip..]]
> Will this still play nicely with
>
> git clone foo.git
>
> ?
>
> Otherwise, please also fix the fallout from this patch.
>
> --
Andreas,
thanks for the comment. I have been testing this patch for over two
weeks already and so far encountered no problems. I routinely perform
"git clone foo.git" and it works correctly creating new repo "foo" and
properly populating it.
--Leo--
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Andreas Ericsson @ 2008-10-20 15:02 UTC (permalink / raw)
To: Christian Jaeger; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48FC9927.5030903@jaeger.mine.nu>
Christian Jaeger wrote:
> Andreas Ericsson wrote:
>> Christian Jaeger wrote:
>>> If you really wanted, I suppose you could additionally look into
>>> implementing a kind of shallow cloning that only copies objects over
>>> the wire which are necessary for representing the subdirectory you're
>>> interested in.
>>>
>>
>> So what do you do when one such commit also affects something outside
>> the subdirectory?
>
> You haven't said what you mean with "affect".
>
I mean "how would you handle a commit (and its tree-object) that updates
all Makefiles in, for example, the Linux kernel project?". Those files
are spread far and wide, and you'd want that change to *your* tree, but
getting it into your tree either means you need to rewrite the tree (and
thereby the commit) itself to get rid of uninteresting blob's from the
tree, and you'd also have to prune the tree to not reveal the directory
layout of the rest of the repository.
I take it parentage could be resolved by a ridiculously large grafts-file.
What you'd end up with wouldn't be a git repository at all anymore. It
would be a "stump", as it'd be missing large parts of the tree entirely.
I'm unsure just how much you'd have to compute to be able to use such a
stump to incorporate your changes with other users again, but I doubt it
would be trivial to implement. Good thing it's not my itch, really.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCHv6 5/5] gitweb: generate parent..current URLs
From: Giuseppe Bilotta @ 2008-10-20 14:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200810201249.14426.jnareb@gmail.com>
On Mon, Oct 20, 2008 at 12:49 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> - # - hash or hash_base:/filename
>> + # - hash_parent or hash_parent_base:/file_parent
>> + # - hash or hash_base:/file_name
>
> Minor nit: this contain independent change 'filename' -> 'file_name',
> but I think it is not worth separating...
Oopsie. Oh well, I was getting so used to all those _ that it felt
strange without
>> # When the script is the root DirectoryIndex for the domain,
>> # $href here would be something like http://gitweb.example.com/
>> @@ -778,17 +779,36 @@ sub href (%) {
>> delete $params{'action'};
>> }
>>
>> - # Finally, we put either hash_base:/file_name or hash
>> + # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
>> + # stripping nonexistent or useless pieces
>> + $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
>> + || $params{'hash_parent'} || $params{'hash'});
>
> Nice trick (and required change).
>
>> if (defined $params{'hash_base'}) {
>> - $href .= "/".esc_url($params{'hash_base'});
>> - if (defined $params{'file_name'}) {
>> + if (defined $params{'hash_parent_base'}) {
>> + $href .= esc_url($params{'hash_parent_base'});
>> + # skip the file_parent if it's the same as the file_name
>> + delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
>> + if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
>> + $href .= ":/".esc_url($params{'file_parent'});
>> + delete $params{'file_parent'};
>> + }
>
> Side note: I wonder if we should use esc_url or esc_param here...
esc_url, I would say, allowing us to build RFC-compliant URLs. Isn't
esc_param for CGI?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCHv6 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-20 14:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200810201118.44654.jnareb@gmail.com>
On Mon, Oct 20, 2008 at 11:18 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
>
>> This patch makes it possible to use an URL such as
>> $project/somebranch..otherbranch:/filename to get a diff between
>> different version of a file. Paths like
>> $project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
>> as well.
>
> Just a nitpick: why '$project' and '$action', but 'somebranch',
> 'otherbranch' and 'filename'?
Good question ... I think I got distracted along the way.
>> All '*diff' actions and in general actions that use $hash_parent[_base]
>> and $file_parent can now get all of their parameters from PATH_INFO
>
> Which currently mean 'shortlog', and I guess in the future would mean
> also all other log-like views: 'log', 'history', 'search' (the commit
> message kind, not the pickaxe kind), and perhaps also 'rss'/'atom'.
I'm not sure rss/atom makes sense, but the others were already in my
todo list after the shortlog patch, so I'll try to get them ready as
soon as I have the time to refactor them as we discussed on IRC.
> Side note: the regexp below allow for $parentpathname to contain
> '..', but we don't want to rely on such minute detail of implementation
> detail (because it depends on whether we use greedy or non-greedy
> matching there).
>
>> + my ($parentrefname, $parentpathname, $refname, $pathname) =
>> + ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
Hm, actually it might be a better idea to make the first pathname
match non-greedy.
>> - $input_params{'action'} ||= "blob_plain";
>> + # the default action depends on whether we had parent info
>> + # or not
>> + if ($parentrefname) {
>> + $input_params{'action'} ||= "blobdiff_plain";
>> + } else {
>> + $input_params{'action'} ||= "blob_plain";
>> + }
>
> Nice.
>
> I was wondering about 'project/hash_parent..hash' syntax, but then I have
> realized that it doesn't change action (as in 'blob_plain' -> 'blobdiff_plain'),
> but is always 'shortlog'.
>
> By the way, I wonder if it should be 'blobdiff_plain' or just 'blobdiff'.
> the 'blob_plain' was here to use gitweb as a kind of versioned web
> server; there is no such equivalent for 'p/hbp..hb:f' syntax. On the
> other hand it is consistent behavior, always using *_plain...
Moreover, it allows sending shorter URLs for patches, which are the
ones you usually write by hand.
>> +
>> + # next, handle the 'parent' part, if present
>> + if (defined $parentrefname) {
>> + # a missing pathspec defaults to the 'current' filename, allowing e.g.
>> + # someproject/blobdiff/oldrev..newrev:/filename
>> + if ($parentpathname) {
>> + $parentpathname =~ s,^/+,,;
>> + $parentpathname =~ s,/$,,;
>
> Hmmm... should we strip trailing '/' here?
I must confess I don't remember why I decided that was needed.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Christian Jaeger @ 2008-10-20 14:43 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48FC55F9.3060509@op5.se>
Andreas Ericsson wrote:
> Christian Jaeger wrote:
>> If you really wanted, I suppose you could additionally look into
>> implementing a kind of shallow cloning that only copies objects over
>> the wire which are necessary for representing the subdirectory you're
>> interested in.
>>
>
> So what do you do when one such commit also affects something outside
> the subdirectory?
You haven't said what you mean with "affect".
Since the point is that you do not want to see any effect to be made nor
described if it is about something outside the subdirectory, the program
would just not look at those?
Did you mean, new commits to be made from changed subdirectory contents?
The stuff outside the subdirectory would just be kept the same and thus
again doesn't need to be present locally.
Did you mean merging branches where one or more of the branches have
changes outside the working directory? As long as the changes from the
branches don't touch any of the same files (outside the
subworkingdirectory), there's no need to fetch the files' contents, the
program is only interested in the changes in the directory listings
(thus directory objects). Now if there *are* changes to the same files
(and outside the subworkingdirectory), the program would certainly need
to fetch those contents, too, to be able to create the new contents.
Would it require a place in the working directory? Yes if there are
conflicts which need to be resolved manually, since it needs a place to
put the conflicts to ask the user to resolve. So I guess it boils down
to SVN having a different notion of what a merge entails?
Christian.
^ permalink raw reply
* git add --patch newfile doesn't add newfile to cache ?
From: Marc Weber @ 2008-10-20 14:36 UTC (permalink / raw)
To: git
Is this desired behaviour?
Testcase:
#!/bin/sh
# this script creates testGitAddPatch and will run the testcase there
rm -fr testGitAddPatch
mkdir testGitAddPatch
cd testGitAddPatch
git init
echo test > test
git add --patch test
echo "running status, nothing has been added"
git status
git --version
My output
marc@mail: /tmp/git ]$ sh test.sh
Initialized empty Git repository in /tmp/git/testGitAddPatch/.git/
No changes.
running status, nothing has been added
# On branch master
#
# Initial commit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# test
nothing added to commit but untracked files present (use "git add" to
track)
git version 1.6.0.2.GIT
Marc Weber
^ permalink raw reply
* Re: Archiving tags/branches?
From: Jakub Narebski @ 2008-10-20 14:35 UTC (permalink / raw)
To: Pete Harlan; +Cc: Johan Herland, git, SZEDER Gabor
In-Reply-To: <48FC26DA.10508@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> Johan Herland wrote:
> > BTW, the best way IMHO to archive old refs is to clone your repo
> > (with all tags/branches) to a backup disk, and then regularly push
> > (git push --all && git push --tags) your new tags/branches to this
> > backup. You are now free to delete these tags/branches from your
> > work repo (they will not be deleted from the backup unless you use
> > "git push --mirror"). And if you ever need to retrieve an old
> > tag/branch, it's just a matter of pulling it from the backup
> > repo. Nice, clean, flexible, and requires no changes to git.
>
> Thank you; that indeed seems to work and solves the problem of managing
> refs/archived-tags manually.
>
> Using a secondary repo solely to overcome a flat tag/branch namespace
> feels hackish. Perhaps git will benefit someday from work in this area,
> but until I come up with a patch your suggestion should work fine. Just
> knowing I didn't overlook an existing feature helps a lot.
I don't quite understand what you mean by _flat_ namespace for tags
and branches.
First, it is not unusual to have hierarchical branch names, at least
for short-term topic branches. For example in git.git history (and in
"What's cooking..." announcements on git mailing list) you can find
branch names such as rs/alloc-ref, nd/narrow, tr/workflow-doc.
Additionally remote-tracking branch names have inherently hierarchical
names: refs/remotes/<remote>/<remote branch>. While tag names usually
are of the type x.y.z, it is not mandated by some technological
limitation.
Second, you can always put your archived refs in another namespace,
beside 'heads', 'tags', and 'remotes'. I for example use
refs/tags/Attic for lightweigth tags to some interesting abandoned
experiments, but it could have been refs/deleted/tags, or
refs/Attic/tags.
Last, please remember that there exists something like packed refs
format (see git-pack-refs(1)... oops, it dies not describe
.git/packed-refs format, unfortunately).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH, RFC] diff: add option to show context between close chunks
From: Johannes Sixt @ 2008-10-20 14:32 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List, Davide Libenzi
In-Reply-To: <48FB757B.9030105@lsrfire.ath.cx>
René Scharfe schrieb:
> This patch adds a new diff option, --inter-chunk-context. It can be
> used to show the context in gaps between chunks, thereby creating a
> big chunk out of two close chunks, in order to have an unbroken
> context, making reviews easier.
>
> With --inter-chunk-context=1, patches have the same number of lines
> as without the option, as only the chunk header is replaced by the
> context line it was shadowing.
>
> You can use commit b0b44bc7b26c8c4b4221a377ce6ba174b843cb8d in the
> git repo to try out this option; there's a chunk in transport.c
> which is just one line away from the next. (I found this option
> helpful in reviewing my own patch before sending. :)
>
> I think it makes sense to make 1, or even 3, the default for this
> option for all commands that create patches intended for human
> consumption. The patch keeps the default at 0, though.
>
> There are downsides, of course: values higher than 1 potentially make
> the resulting patch longer. More context means a higher probability
> of (perhaps unnecessary) merge conflicts.
>
> Comments?
Why can't you just use -U6 instead instead of --inter-chunk-context=3? If
this is intended for human consumption anyway, then you can just as well
increase the overall number of context lines: You get extra context lines
in the places where hunks are not fused, but this cannot be a disadvantage
for the targeted audience.
-- Hannes
^ permalink raw reply
* Re: [BUG?] Fail to pull from kernel.org: pack has bad object
From: Thomas Rast @ 2008-10-20 14:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johan Herland, Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0810200955250.26244@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 327 bytes --]
Nicholas Pitre wrote:
> When index-pack dies like that, a temporary (and incomplete) pack file
> is left in .git/objects/pack/ with tmp in the file name. I'd need only
> that to reproduce the issue.
Like this?
http://n.ethz.ch/~trast/download/tmp_pack_NMj69p
--
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
* Re: [BUG?] Fail to pull from kernel.org: pack has bad object
From: Nicolas Pitre @ 2008-10-20 13:59 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Johan Herland, git
In-Reply-To: <20081020121533.GA2177@coredump.intra.peff.net>
On Mon, 20 Oct 2008, Jeff King wrote:
> I am getting it, too, but I remembered to save my repo. :) The 'next'
> branch is broken, but master works fine. The bisect points to
>
> commit 9441b61dc5c3f1f984114ec8bd470dc20c55dfe0
> Author: Nicolas Pitre <nico@cam.org>
> Date: Fri Oct 17 15:57:57 2008 -0400
>
> index-pack: rationalize delta resolution code
Dammit... I'm growing a habit of breaking things lately.
> but I don't have time to look further right now (there is a small child
> who apparently thinks coloring with crayons is more interesting than
> bisecting bugs).
>
> I can make my broken repo available if need be (though given the number
> of us seeing the problem, I doubt it is hard to reproduce).
It certainly is... to me at least.
When index-pack dies like that, a temporary (and incomplete) pack file
is left in .git/objects/pack/ with tmp in the file name. I'd need only
that to reproduce the issue.
Nicolas
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Nguyen Thai Ngoc Duy @ 2008-10-20 13:59 UTC (permalink / raw)
To: Jeff King; +Cc: Maciej Pasternacki, git
In-Reply-To: <20081019131745.GA8643@coredump.intra.peff.net>
On 10/19/08, Jeff King <peff@peff.net> wrote:
> I'm not sure if the actual problem is related to the oft-discussed,
> unresolved work-tree startup woes, or is something much simpler to fix.
> I'll try to look closer later today.
I think all commands should be able to jump to worktree even if you
are outside work-tree. git-pull and similar commands are easy because
they don't take pathnames. The way pathnames are handled in git does
not make it easy for outside current working directory, because if old
cwd is outside worktree, the parameter "prefix" sent to those commands
become "../../blah/", not a real prefix anymore. If a command expects
an index pathname, then that prefix should be rejected. If they expect
a filesystem pathname, it can be used with care.
--
Duy
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Michael J Gruber @ 2008-10-20 13:22 UTC (permalink / raw)
To: Marc Branchaud; +Cc: Michael J Gruber, Peter Harris, git
In-Reply-To: <48F8ECA2.3040208@xiplink.com>
Marc Branchaud venit, vidit, dixit 17.10.2008 21:50:
> Michael J Gruber wrote:
>> "pull -s strategy repo master" does a fetch followed by "merge -s
>> strategy repomaster", where repomaster is the ref for master on repo.
>> So, if you got that branch (repomaster=ThingOne/master) by cloning from
>> main you can do the merge (subtree or other) on your clone, even without
>> the remote repo config for ThingOne on clone.
>
> I'm afraid I'm having trouble translating what you're saying into actual
> git commands (or are you proposing some new git functionality?). How
> would I get the ThingOne/master branch into the clone?
Sorry for being cryptic. What I meant was: The clones don't need the
full remote config of main in order to get main's remote branches for
the ThingOne remote. Say, main stores the remote tracking branches for
ThingOne in "refs/remotes/ThingOne", using an appropriate remote config.
Then a clone could use the refspec
"refs/remotes/ThingOne/*:refs/remotes/ThingOne/*" (when fetching from
main) in order to fetch those branches, without having a remote config
for ThingOne on the clone. Concretely:
git config remote.main.fetch
'+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'
on a clone which has a remote config "main" for the main repo.
> After some more thought I realized that the clone can just pull directly
> from the ThingOne repository:
>
> clone/$ git pull -s subtree git://thing/ThingOne.git master
I thought that's what you were trying to avoid...
> (I'm still getting used to git's ability to match commit IDs from
> anywhere -- it's magic! :) )
... but this explains everything ;)
> This goes a long way to where we want to be, in that we don't have to do
> our merging work in the original main repository.
>
> It would be nice, though, if the clone were able to use the main
> repository's definition of the ThingOne remote. I can think of some
> plausible scenarios where a person could get confused about which
> repo/branch they're supposed to pull. It's easy to recover from that
> kind of mistake, but there'd be less chance of a mistake if one could
> tell git to "pull from X as defined in the origin repository".
I think the approach I outlined above could solve this: main prepares
everything to be pulled under refs/remotes/ThingOne, and clones (i.e.
clone users) are told to fetch with a refspec like above. This way they
get a copy of main's remote tracking branches for ThingOne. (Maybe you
use one branch only, then the refspec is even simpler.)
> And actually, git's remote functionality feels a bit crippled if clones
> can't make some use of the origin's remotes. Is there a reason for
> keeping remote definitions out of a clone?
Say A and B are working on a project C. Then, typically, A is interested
in B's work on C, i.e. some of B's local branches, but not on B's remote
tracking branches: A tracks a "central" C already, just like B does,
and remote tracking branches don't carry any "value adding" by the
cloner, they're just a local unmodified copy of the remote.
But you can always add a refspec like above.
Michael
^ permalink raw reply
* Re: [PATCH] -C/--chdir command line option
From: Michael J Gruber @ 2008-10-20 12:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Maciej Pasternacki, git
In-Reply-To: <7vr66b50gy.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 20.10.2008 06:55:
> Jeff King <peff@peff.net> writes:
>
>> On Sun, Oct 19, 2008 at 03:47:04PM +0200, Maciej Pasternacki wrote:
>>
>>> As for -C being superfluous: --git-dir and --work-tree seem to support
>>> weird usage patterns (like work tree separate from git-dir), but it seems
>> Hmm. Yeah, thinking about it more, -C is not really superfluous with
>> respect to those options. You don't want to say "here is the work-tree,
>> and here is the git-dir". You want to say "find the work-tree and
>> git-dir for me using the usual rules, as if I were in this directory."
>
> I think that interpretation of -C, if the option existed, makes sense, but
> I do not understand why the tool that drives git refuses to chdir to the
> repository for itself in the first place.
>
> The only excuse I remember seeing in the thread was that "make has '-C'
> option, so let's have it, because it is similar", which does not justfiy
> addition of that option to git at all to me.
I want to have '-j2' ;)
Seriously:
git -C elsewhere command opts
is shorther and more direct than
(cd elsewhere && git command opts)
which is the true equivalent, or
pushd elsewhere; git command opts; popd
And much shorter than using --git-dir and --work-tree, which are
semi-broken right now.
I just think it's very useful to be able to peek into a repo somewhere
else quickly; or for transferral of objects between unrelated objects
(run rev-parse elsewhere etc.).
Michael
^ permalink raw reply
* Re: [BUG?] Fail to pull from kernel.org: pack has bad object
From: Jeff King @ 2008-10-20 12:15 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nicolas Pitre, Johan Herland, git
In-Reply-To: <200810201026.57306.trast@student.ethz.ch>
On Mon, Oct 20, 2008 at 10:26:55AM +0200, Thomas Rast wrote:
> > Currently I get the following error when trying to pull from git.git at
> > kernel.org:
> >
> > $ git pull
> > remote: Counting objects: 279, done.
> > remote: Compressing objects: 100% (78/78), done.
> > remote: Total 177 (delta 136), reused 135 (delta 99)
> > Receiving objects: 100% (177/177), 66.59 KiB | 59 KiB/s, done.
> > fatal: pack has bad object at offset 53487: failed to apply delta
> > fatal: index-pack failed
>
> I just had the same, panicked, then compiled 'maint' and the fetch
> worked. Unfortunately I wasn't awake enough to make a copy of the
> repo. Maybe you can make one, then use it to bisect the problem
> between maint and next...
I am getting it, too, but I remembered to save my repo. :) The 'next'
branch is broken, but master works fine. The bisect points to
commit 9441b61dc5c3f1f984114ec8bd470dc20c55dfe0
Author: Nicolas Pitre <nico@cam.org>
Date: Fri Oct 17 15:57:57 2008 -0400
index-pack: rationalize delta resolution code
but I don't have time to look further right now (there is a small child
who apparently thinks coloring with crayons is more interesting than
bisecting bugs).
I can make my broken repo available if need be (though given the number
of us seeing the problem, I doubt it is hard to reproduce).
-Peff
^ permalink raw reply
* Re: need help stripping a repo to one file
From: Baz @ 2008-10-20 11:53 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0810190327i7842d346g4c20f5816e8a9eda@mail.gmail.com>
2008/10/19 Caleb Cushing <xenoterracide@gmail.com>:
> here's what I've done so far (note: this is a public repo if anyone
> wants to take a look)
>
> git clone git@github.com:xenoterracide/dot_usr.git sql_iabbr
> cd sql_iabbr/
> git checkout db3c5ffb180f10dde8e539a81a6644760e098dcd
> git branch -D master
> git checkout -b master
> git filter-branch --subdirectory-filter vim/ftplugin/ -- --all
>
>
> that leaves me with this
> html sgml sh tex vim xhtml xml sql_iabbr.vim xml.vim
>
> all I want left is sql_iabbr.vim and it's history
So you just want the history for a single file?
git log -p --reverse --pretty=email -- sql_iabbr.vim
That outputs a patch history for sql_iabbr.vim in mbox format, you can
import that into an empty repo with git-am.
(I had a look at the project, the history is simple with no merges
etc, so nothing like --first-parent is needed)
Cheers,
Baz
>
> I've used stuff like
> git filter-branch --tree-filter 'rm -rf xml.vim' HEAD
>
> to remove the files... but I notice that leaves the logs.
>
> I'm thinking I could do that and then remove those commits but I
> haven't figured out how to remove the commits, and even then I'm not
> sure the repo would be in the state I want.
>
> can anyone help me get to where I want to be? also is there an easier
> way to do what I've done so far?
> --
> Caleb Cushing
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] rebase-i-p: only list commits that require rewriting in todo
From: Jeff King @ 2008-10-20 11:50 UTC (permalink / raw)
To: Stephen Haberman; +Cc: gitster, git
In-Reply-To: <0977b23f6c709d4aea76de7a88e9fe17272b31ea.1224055978.git.stephen@exigencecorp.com>
On Wed, Oct 15, 2008 at 02:44:38AM -0500, Stephen Haberman wrote:
> + cat "$TODO" | grep -v "${rev:0:7}" > "${TODO}2" ; mv "${TODO}2" "$TODO"
Substring expansion (like ${rev:0:7}) is not portable. At least it
doesn't work on FreeBSD /bin/sh, and "it's not even in POSIX", I
believe.
-Peff
^ permalink raw reply
* Re: [PATCHv6 5/5] gitweb: generate parent..current URLs
From: Jakub Narebski @ 2008-10-20 10:49 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-6-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> If use_pathinfo is enabled, href now creates links that contain paths in
> the form $project/$action/oldhash:/oldname..newhash:/newname for actions
> that use hash_parent etc.
>
> If any of the filename contains two consecutive dots, it's kept as a CGI
> parameter since the resulting path would otherwise be ambiguous.
Note that this part is _required_ after previous patch, because
otherwise gitweb could generate path_info links which point to
different view than intended, when filename contains '..' in it,
like for example some test vectors in git test suite, for example
files in t/t5515
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
For what is worth:
Acked-by: Jakub Narebski <jnareb@gmail.com>
BTW. I wanted to test this using gitweb-Mechanize test from Lea Wiemann
GSoC 2008 work on gitweb caching, but I couldn't make it run as single
individual test (cd t && ./t9503-gitweb-Mechanize.sh); it requires to
run as "make test" and I didn't want that. I could have resurrected my
initial version of Test::WWW::Mechanize::CGI test...
> ---
> gitweb/gitweb.perl | 30 +++++++++++++++++++++++++-----
> 1 files changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 1a7b0b9..f4642e7 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -759,7 +759,8 @@ sub href (%) {
> # try to put as many parameters as possible in PATH_INFO:
> # - project name
> # - action
> - # - hash or hash_base:/filename
> + # - hash_parent or hash_parent_base:/file_parent
> + # - hash or hash_base:/file_name
Minor nit: this contain independent change 'filename' -> 'file_name',
but I think it is not worth separating...
>
> # When the script is the root DirectoryIndex for the domain,
> # $href here would be something like http://gitweb.example.com/
> @@ -778,17 +779,36 @@ sub href (%) {
> delete $params{'action'};
> }
>
> - # Finally, we put either hash_base:/file_name or hash
> + # Next, we put hash_parent_base:/file_parent..hash_base:/file_name,
> + # stripping nonexistent or useless pieces
> + $href .= "/" if ($params{'hash_base'} || $params{'hash_parent_base'}
> + || $params{'hash_parent'} || $params{'hash'});
Nice trick (and required change).
> if (defined $params{'hash_base'}) {
> - $href .= "/".esc_url($params{'hash_base'});
> - if (defined $params{'file_name'}) {
> + if (defined $params{'hash_parent_base'}) {
> + $href .= esc_url($params{'hash_parent_base'});
> + # skip the file_parent if it's the same as the file_name
> + delete $params{'file_parent'} if $params{'file_parent'} eq $params{'file_name'};
> + if (defined $params{'file_parent'} && $params{'file_parent'} !~ /\.\./) {
> + $href .= ":/".esc_url($params{'file_parent'});
> + delete $params{'file_parent'};
> + }
Side note: I wonder if we should use esc_url or esc_param here...
> + $href .= "..";
> + delete $params{'hash_parent'};
> + delete $params{'hash_parent_base'};
> + } elsif (defined $params{'hash_parent'}) {
> + $href .= esc_url($params{'hash_parent'}). "..";
> + delete $params{'hash_parent'};
> + }
> +
> + $href .= esc_url($params{'hash_base'});
> + if (defined $params{'file_name'} && $params{'file_name'} !~ /\.\./) {
> $href .= ":/".esc_url($params{'file_name'});
> delete $params{'file_name'};
> }
> delete $params{'hash'};
> delete $params{'hash_base'};
> } elsif (defined $params{'hash'}) {
> - $href .= "/".esc_url($params{'hash'});
> + $href .= esc_url($params{'hash'});
> delete $params{'hash'};
> }
> }
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCHv6 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Jakub Narebski @ 2008-10-20 9:18 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224188831-17767-5-git-send-email-giuseppe.bilotta@gmail.com>
On Thu, 16 Oct 2008, Giuseppe Bilotta wrote:
> This patch makes it possible to use an URL such as
> $project/somebranch..otherbranch:/filename to get a diff between
> different version of a file. Paths like
> $project/$action/somebranch:/somefile..otherbranch:/otherfile are parsed
> as well.
Just a nitpick: why '$project' and '$action', but 'somebranch',
'otherbranch' and 'filename'?
>
> All '*diff' actions and in general actions that use $hash_parent[_base]
> and $file_parent can now get all of their parameters from PATH_INFO
Which currently mean 'shortlog', and I guess in the future would mean
also all other log-like views: 'log', 'history', 'search' (the commit
message kind, not the pickaxe kind), and perhaps also 'rss'/'atom'.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
For what is worth:
Acked-by: Jakub Narebski <jnareb@gmail.com>
> ---
> gitweb/gitweb.perl | 36 ++++++++++++++++++++++++++++++++++--
> 1 files changed, 34 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 49730f3..1a7b0b9 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -548,7 +548,12 @@ sub evaluate_path_info {
> 'history',
> );
>
> - my ($refname, $pathname) = split(/:/, $path_info, 2);
> + # horrible regexp to catch
> + # [$hash_parent_base[:$file_parent]..]$hash_parent[:$file_name]
This comment is really nice here, to explain what we try to catch.
Is it really "horrible"... let others decide.
Note: this (as also previous code) makes use of the fact that refname
cannot contain ':' as per git-check-ref-format(1), and the fact that
gitweb limits $hash* parameters to simple revision syntax, allowing
only SHA1 and refnames, and not allowing (see validate_refname() used
in $hash* validation) extended SHA1 syntax like <commit-ish>:<path>
for $hash ('h') param for 'blob' view: gitweb uses $hash_base and
$file_name for that.
(But I guess it is too long explanation to put it in comment)
Side note: the regexp below allow for $parentpathname to contain
'..', but we don't want to rely on such minute detail of implementation
detail (because it depends on whether we use greedy or non-greedy
matching there).
> + my ($parentrefname, $parentpathname, $refname, $pathname) =
> + ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
> +
> + # first, analyze the 'current' part
> if (defined $pathname) {
> # we got "branch:filename" or "branch:dir/"
> # we could use git_get_type(branch:pathname), but it needs $git_dir
> @@ -557,7 +562,13 @@ sub evaluate_path_info {
> $input_params{'action'} ||= "tree";
> $pathname =~ s,/$,,;
> } else {
> - $input_params{'action'} ||= "blob_plain";
> + # the default action depends on whether we had parent info
> + # or not
> + if ($parentrefname) {
> + $input_params{'action'} ||= "blobdiff_plain";
> + } else {
> + $input_params{'action'} ||= "blob_plain";
> + }
Nice.
I was wondering about 'project/hash_parent..hash' syntax, but then I have
realized that it doesn't change action (as in 'blob_plain' -> 'blobdiff_plain'),
but is always 'shortlog'.
By the way, I wonder if it should be 'blobdiff_plain' or just 'blobdiff'.
the 'blob_plain' was here to use gitweb as a kind of versioned web
server; there is no such equivalent for 'p/hbp..hb:f' syntax. On the
other hand it is consistent behavior, always using *_plain...
> }
> $input_params{'hash_base'} ||= $refname;
> $input_params{'file_name'} ||= $pathname;
> @@ -577,6 +588,27 @@ sub evaluate_path_info {
> $input_params{'hash'} ||= $refname;
> }
> }
> +
> + # next, handle the 'parent' part, if present
> + if (defined $parentrefname) {
> + # a missing pathspec defaults to the 'current' filename, allowing e.g.
> + # someproject/blobdiff/oldrev..newrev:/filename
> + if ($parentpathname) {
> + $parentpathname =~ s,^/+,,;
> + $parentpathname =~ s,/$,,;
Hmmm... should we strip trailing '/' here?
> + $input_params{'file_parent'} ||= $parentpathname;
> + } else {
> + $input_params{'file_parent'} ||= $input_params{'file_name'};
> + }
> + # we assume that hash_parent_base is wanted if a path was specified,
> + # or if the action wants hash_base instead of hash
Nice comment.
> + if (defined $input_params{'file_parent'} ||
> + grep {$input_params{'action'} eq $_} @wants_base) {
My preference of style would be to use here:
+ grep { $input_params{'action'} eq $_ } @wants_base) {
> + $input_params{'hash_parent_base'} ||= $parentrefname;
> + } else {
> + $input_params{'hash_parent'} ||= $parentrefname;
> + }
> + }
> }
> evaluate_path_info();
>
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ 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