* 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: [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: 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: [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: 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: 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: 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: 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: 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
* [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
* [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) 3/3] Windows: Make OpenSSH properly detect tty detachment.
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-3-git-send-email-angavrilov@gmail.com>
Apparently, CREATE_NO_WINDOW makes the OS tell the process
that it has a console, but without actually creating the
window. As a result, when git is started from GUI, ssh
tries to ask its questions on the invisible console.
This patch uses DETACHED_PROCESS instead, which clearly
means that the process should be left without a console.
The downside is that if the process manually calls
AllocConsole, the window will appear. A similar thing
might occur if it calls another console executable.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
---
compat/mingw.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 1e29b88..b6fcf69 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -586,12 +586,16 @@ static pid_t mingw_spawnve(const char *cmd, const char **argv, char **env,
* would normally create a console window. But
* since we'll be redirecting std streams, we do
* not need the console.
+ * It is necessary to use DETACHED_PROCESS
+ * instead of CREATE_NO_WINDOW to make ssh
+ * recognize that it has no console.
*/
- flags = CREATE_NO_WINDOW;
+ flags = DETACHED_PROCESS;
} else {
/* There is already a console. If we specified
- * CREATE_NO_WINDOW here, too, Windows would
+ * DETACHED_PROCESS here, too, Windows would
* disassociate the child from the console.
+ * The same is true for CREATE_NO_WINDOW.
* Go figure!
*/
flags = 0;
--
1.6.0.2.1256.ga12f0
^ permalink raw reply related
* [PATCH (GIT-GUI,MINGW) 2/3] git-gui: Add a simple implementation of SSH_ASKPASS.
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-2-git-send-email-angavrilov@gmail.com>
OpenSSH allows specifying an external program to use
for direct user interaction. While most Linux systems
already have such programs, some environments, for
instance, msysgit, lack it. This patch adds a simple
fallback Tcl implementation of the tool.
In msysgit it is also necessary to set a fake value of
the DISPLAY variable, because otherwise ssh won't even
try to use SSH_ASKPASS handlers.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
Makefile | 2 ++
git-gui.sh | 12 ++++++++++++
git-gui--askpass | 59 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 73 insertions(+), 0 deletions(-)
create mode 100755 git-gui--askpass
diff --git a/Makefile b/Makefile
index 55765c8..0ee47bf 100644
--- a/Makefile
+++ b/Makefile
@@ -285,6 +285,7 @@ all:: $(GITGUI_MAIN) lib/tclIndex $(ALL_MSGFILES)
install: all
$(QUIET)$(INSTALL_D0)'$(DESTDIR_SQ)$(gitexecdir_SQ)' $(INSTALL_D1)
$(QUIET)$(INSTALL_X0)git-gui $(INSTALL_X1) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
+ $(QUIET)$(INSTALL_X0)git-gui--askpass $(INSTALL_X1) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(QUIET)$(foreach p,$(GITGUI_BUILT_INS), $(INSTALL_L0)'$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' $(INSTALL_L1)'$(DESTDIR_SQ)$(gitexecdir_SQ)/git-gui' $(INSTALL_L2)'$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' $(INSTALL_L3) &&) true
ifdef GITGUI_WINDOWS_WRAPPER
$(QUIET)$(INSTALL_R0)git-gui.tcl $(INSTALL_R1) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
@@ -302,6 +303,7 @@ endif
uninstall:
$(QUIET)$(CLEAN_DST) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(QUIET)$(REMOVE_F0)'$(DESTDIR_SQ)$(gitexecdir_SQ)'/git-gui $(REMOVE_F1)
+ $(QUIET)$(REMOVE_F0)'$(DESTDIR_SQ)$(gitexecdir_SQ)'/git-gui--askpass $(REMOVE_F1)
$(QUIET)$(foreach p,$(GITGUI_BUILT_INS), $(REMOVE_F0)'$(DESTDIR_SQ)$(gitexecdir_SQ)'/$p $(REMOVE_F1) &&) true
ifdef GITGUI_WINDOWS_WRAPPER
$(QUIET)$(REMOVE_F0)'$(DESTDIR_SQ)$(gitexecdir_SQ)'/git-gui.tcl $(REMOVE_F1)
diff --git a/git-gui.sh b/git-gui.sh
index e4d1f70..5e04a7c 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -592,6 +592,11 @@ bind . <Visibility> {
if {[is_Windows]} {
wm iconbitmap . -default $oguilib/git-gui.ico
set ::tk::AlwaysShowSelection 1
+
+ # Spoof an X11 display for SSH
+ if {![info exists env(DISPLAY)]} {
+ set env(DISPLAY) :native
+ }
}
######################################################################
@@ -1071,6 +1076,13 @@ set nullid2 "0000000000000000000000000000000000000001"
set have_tk85 [expr {[package vcompare $tk_version "8.5"] >= 0}]
######################################################################
+
+# Suggest our implementation of askpass, if not already set
+if {![info exists env(SSH_ASKPASS)]} {
+ set env(SSH_ASKPASS) [gitexec git-gui--askpass]
+}
+
+######################################################################
##
## task management
diff --git a/git-gui--askpass b/git-gui--askpass
new file mode 100755
index 0000000..12e117e
--- /dev/null
+++ b/git-gui--askpass
@@ -0,0 +1,59 @@
+#!/bin/sh
+# Tcl ignores the next line -*- tcl -*- \
+exec wish "$0" -- "$@"
+
+# This is a trivial implementation of an SSH_ASKPASS handler.
+# Git-gui uses this script if none are already configured.
+
+set answer {}
+set yesno 0
+set rc 255
+
+if {$argc < 1} {
+ set prompt "Enter your OpenSSH passphrase:"
+} else {
+ set prompt [join $argv " "]
+ if {[regexp -nocase {\(yes\/no\)\?\s*$} $prompt]} {
+ set yesno 1
+ }
+}
+
+message .m -text $prompt -justify center -aspect 4000
+pack .m -side top -fill x -padx 20 -pady 20 -expand 1
+
+entry .e -textvariable answer -width 50
+pack .e -side top -fill x -padx 10 -pady 10
+
+if {!$yesno} {
+ .e configure -show "*"
+}
+
+frame .b
+button .b.ok -text OK -command finish
+button .b.cancel -text Cancel -command {destroy .}
+
+pack .b.ok -side left -expand 1
+pack .b.cancel -side right -expand 1
+pack .b -side bottom -fill x -padx 10 -pady 10
+
+bind . <Visibility> {focus -force .e}
+bind . <Key-Return> finish
+bind . <Key-Escape> {destroy .}
+bind . <Destroy> {exit $rc}
+
+proc finish {} {
+ if {$::yesno} {
+ if {$::answer ne "yes" && $::answer ne "no"} {
+ tk_messageBox -icon error -title "Error" -type ok \
+ -message "Only 'yes' or 'no' input allowed."
+ return
+ }
+ }
+
+ set ::rc 0
+ puts $::answer
+ destroy .
+}
+
+wm title . "OpenSSH"
+tk::PlaceWindow .
--
1.6.0.20.g6148bc
^ permalink raw reply related
* Re: Is XDL_MERGE_ZEALOUS too zealous (or maybe not zealous enough)?
From: Johannes Schindelin @ 2008-10-20 16:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matt McCutchen
In-Reply-To: <7v3ais5hb3.fsf_-_@gitster.siamese.dyndns.org>
Hi,
On Sun, 19 Oct 2008, Junio C Hamano wrote:
> <<<<<<< ours
> /* --track without -b should DWIM */
> if (0 < opts.track && !opts.new_branch) {
> const char *argv0 = argv[0];
> ...
> opts.new_branch = argv0 + 1;
> }
>
> if (opts.track == BRANCH_TRACK_UNSPECIFIED)
> opts.track = git_branch_track;
> =======
> if (conflict_style) {
> opts.merge = 1; /* implied */
> git_xmerge_config("merge.conflictstyle", conflict_style, NULL);
> }
>
> if (!opts.new_branch && (opts.track != git_branch_track))
> die("git checkout: --track and --no-track require -b");
> >>>>>>> theirs
This is that case that adjacent blocks A and B are changed to A' B and A
B' in the to-be-merged branches.
I could imagine that you would have this automerged to A' B', but I
actually advise against that.
My gut feeling tells me that a "for" statement as block "A" and some
change ("B") in the _body_ of the "for" loop that takes advantage of the
original version of the "for" statement would be _real_ hard to detect.
Better have trivial conflicts reported, but catch more non-trivial ones
(instead of mismerging them).
(Another possibility would be that block "B" is actually an "else". Also
in this case it is easy to think of cases that would wreak havoc; OTOH we
would mismerge them _already_ if at least 1 common line is unchanged
between the blocks. Tough.)
But I might be completely wrong.
Ciao,
Dscho "who is a little jet-lagged, so you should trust him even less than
normally"
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Andreas Ericsson @ 2008-10-20 16:11 UTC (permalink / raw)
To: Christian Jaeger; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48FCA1BC.3060300@jaeger.mine.nu>
Christian Jaeger wrote:
> 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".
"or end up transferring all objects on the wire anyway".
>
>> 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.
>
Then you'll be transferring all objects over the wire anyway, so there
goes that idea.
>> 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.
>
That's partially implemented, I think (google for Nguy (or something, I'm
not very god with asian names), but your original suggestion said to save
on transferring objects from one machine to another, which will play poorly
with git's object database and which you're now arguing against.
Please make up your mind.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-10-20 16:28 UTC (permalink / raw)
To: git; +Cc: gitster
After fixing clone -q I noticed that pull -q does not do what
it's supposed to do and implemented --quiet/--verbose by
adding it to builtin-merge and fixing two places in builtin-fetch.
I have not touched/adjusted contrib/completion/git-completion.bash
but can take a look if wanted. I think it already needs one or two
adjustments caused by recent --OPTIONS changes in master.
I've tested the following invocations with the below changes applied:
$ git pull
$ git pull -q
$ git pull -v
$ git fetch -q
$ git pull -q -v -q
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
Documentation/merge-options.txt | 8 ++++++++
builtin-fetch.c | 21 +++++++++++----------
builtin-merge.c | 22 +++++++++++++++-------
git-pull.sh | 11 ++++++++---
4 files changed, 42 insertions(+), 20 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 007909a..427cdef 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,3 +1,11 @@
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
+
--stat::
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.stat.
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ee93d3a..b067512 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -22,16 +22,17 @@ enum {
TAGS_SET = 2
};
-static int append, force, keep, update_head_ok, verbose, quiet;
+static int append, force, keep, update_head_ok;
static int tags = TAGS_DEFAULT;
static const char *depth;
static const char *upload_pack;
static struct strbuf default_rla = STRBUF_INIT;
static struct transport *transport;
+static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
static struct option builtin_fetch_options[] = {
- OPT__QUIET(&quiet),
- OPT__VERBOSE(&verbose),
+ OPT_SET_INT('v', "verbose", &verbosity, "be verbose", VERBOSE),
+ OPT_SET_INT('q', "quiet", &verbosity, "operate quietly", QUIET),
OPT_BOOLEAN('a', "append", &append,
"append to .git/FETCH_HEAD instead of overwriting"),
OPT_STRING(0, "upload-pack", &upload_pack, "PATH",
@@ -192,7 +193,6 @@ static int s_update_ref(const char *action,
static int update_local_ref(struct ref *ref,
const char *remote,
- int verbose,
char *display)
{
struct commit *current = NULL, *updated;
@@ -210,7 +210,7 @@ static int update_local_ref(struct ref *ref,
die("object %s not found", sha1_to_hex(ref->new_sha1));
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
- if (verbose)
+ if (verbosity == VERBOSE)
sprintf(display, "= %-*s %-*s -> %s", SUMMARY_WIDTH,
"[up to date]", REFCOL_WIDTH, remote,
pretty_ref);
@@ -366,18 +366,19 @@ static int store_updated_refs(const char *url, const char *remote_name,
note);
if (ref)
- rc |= update_local_ref(ref, what, verbose, note);
+ rc |= update_local_ref(ref, what, note);
else
sprintf(note, "* %-*s %-*s -> FETCH_HEAD",
SUMMARY_WIDTH, *kind ? kind : "branch",
REFCOL_WIDTH, *what ? what : "HEAD");
if (*note) {
- if (!shown_url) {
+ if (verbosity > QUIET && !shown_url) {
fprintf(stderr, "From %.*s\n",
url_len, url);
shown_url = 1;
}
- fprintf(stderr, " %s\n", note);
+ if (verbosity > QUIET)
+ fprintf(stderr, " %s\n", note);
}
}
fclose(fp);
@@ -622,9 +623,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
remote = remote_get(argv[0]);
transport = transport_get(remote, remote->url[0]);
- if (verbose >= 2)
+ if (verbosity == VERBOSE)
transport->verbose = 1;
- if (quiet)
+ if (verbosity == QUIET)
transport->verbose = -1;
if (upload_pack)
set_option(TRANS_OPT_UPLOADPACK, upload_pack);
diff --git a/builtin-merge.c b/builtin-merge.c
index 5e7910b..76e2890 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -50,6 +50,7 @@ static unsigned char head[20], stash[20];
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
+static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -152,6 +153,8 @@ static int option_parse_n(const struct option *opt,
}
static struct option builtin_merge_options[] = {
+ OPT_SET_INT('v', "verbose", &verbosity, "be verbose", VERBOSE),
+ OPT_SET_INT('q', "quiet", &verbosity, "operate quietly", QUIET),
{ OPTION_CALLBACK, 'n', NULL, NULL, NULL,
"do not show a diffstat at the end of the merge",
PARSE_OPT_NOARG, option_parse_n },
@@ -250,7 +253,8 @@ static void restore_state(void)
/* This is called when no merge was necessary. */
static void finish_up_to_date(const char *msg)
{
- printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
+ if (verbosity > QUIET)
+ printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
drop_save();
}
@@ -331,14 +335,15 @@ static void finish(const unsigned char *new_head, const char *msg)
if (!msg)
strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
else {
- printf("%s\n", msg);
+ if (verbosity > QUIET)
+ printf("%s\n", msg);
strbuf_addf(&reflog_message, "%s: %s",
getenv("GIT_REFLOG_ACTION"), msg);
}
if (squash) {
squash_message();
} else {
- if (!merge_msg.len)
+ if (verbosity > QUIET && !merge_msg.len)
printf("No merge message -- not updating HEAD\n");
else {
const char *argv_gc_auto[] = { "gc", "--auto", NULL };
@@ -872,6 +877,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, builtin_merge_options,
builtin_merge_usage, 0);
+ if (verbosity > QUIET)
+ show_diffstat = 0;
if (squash) {
if (!allow_fast_forward)
@@ -1013,10 +1020,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
- printf("Updating %s..%s\n",
- hex,
- find_unique_abbrev(remoteheads->item->object.sha1,
- DEFAULT_ABBREV));
+ if (verbosity > QUIET)
+ printf("Updating %s..%s\n",
+ hex,
+ find_unique_abbrev(remoteheads->item->object.sha1,
+ DEFAULT_ABBREV));
strbuf_addstr(&msg, "Fast forward");
if (have_message)
strbuf_addstr(&msg,
diff --git a/git-pull.sh b/git-pull.sh
index 75c3610..9c0a812 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,13 +16,17 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
+strategy_args= no_stat= no_commit= squash= no_ff= log_arg= verbosity=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
+ -q|--quiet)
+ verbosity="$verbosity -q" ;;
+ -v|--verbose)
+ verbosity="$verbosity -v" ;;
-n|--no-stat|--no-summary)
no_stat=-n ;;
--stat|--summary)
@@ -121,7 +125,7 @@ test true = "$rebase" && {
"refs/remotes/$origin/$reflist" 2>/dev/null)"
}
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
-git fetch --update-head-ok "$@" || exit 1
+git fetch $verbosity --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
@@ -181,5 +185,6 @@ merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
test true = "$rebase" &&
exec git-rebase $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
-exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
+exec git-merge $verbosity $no_stat $no_commit \
+ $squash $no_ff $log_arg $strategy_args \
"$merge_name" HEAD $merge_head
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: Usability of git stash
From: Brandon Casey @ 2008-10-20 16:33 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: David Kastrup, git
In-Reply-To: <87prly5k5r.fsf@cup.kalibalik.dk>
Anders Melchiorsen wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
>> In exchange for allowing new users to stub their toe on new commands, the
>> work flow of more experienced users is made a little easier.
>
> I wonder whether experienced users even use stash a lot. Personally,
> after getting my head around the DAG, and thus getting more
> comfortable with git reset, I tend to make "WIP" commits instead.
There is another use for stash, as has previously been described by someone
else on this list. That is for incrementally splitting up changes made to
the working directory into a series of commits, _and_ testing each commit.
This is what the 'git stash save --keep-index' functionality was invented for,
but I do not consider this single option to completely satisfy the
requirements. The idea is to be able to 'git add -i' commits to the index and
then stash away all of the remaining commits so that the commits in the index
can be tested alone. After testing, you may decide that you want to move
commits from the index into the stash set or vice versa as appropriate before
committing.
Easily performing the operations in the previous sentence is what is missing.
Additional hunks can be added easily, but they can not be un-staged easily.
Maybe the interactive mode of git-add needs a '-p' sub-command which will
allow selecting from the set of staged hunks, and un-staging individually in
the same way that the 'p' sub-command allows staging hunks.
There is an example of this workflow in the stash man page, but I think it
needs to be changed. It is suggested:
# ... hack hack hack ...
$ git add --patch foo # add just first part to the index
$ git stash save --keep-index # save all other changes to the stash
$ edit/build/test first part
$ git commit -m 'First part' # commit fully tested change
$ git stash pop # prepare to work on all other changes
# ... repeat above five steps until ...
The commit and pop currently need to be changed to something like:
# git reset --hard
# git stash pop --index
# git commit -m 'First part'
Otherwise you are prone to merge conflicts in the working directory which
are not straight-forward to reconcile. When there are merge conflicts,
the changes from the stash are staged for committing, and the files with
conflicts are 'Changed but not updated'. The user must reconcile the
conflicts and then 'git reset'.
I'm sure the user's reaction (as mine was) will be WTF!?. I initially
concluded that this work-flow was just broken. It is still usable, but far
from perfect.
> After having used "git stash clear" at a bad time once, I am wary of
> stashing work that I actually want to keep. I prefer workflows where
> my mistakes can be (easily) corrected.
There is now a 'git stash drop' which can be used to drop individual stashes,
and a 'git stash pop' to apply and then drop an individual stash.
> The primary thing that stash does for me is preserve the index state.
> Unfortunately, --index is not default for stash apply, so I often
> forget it.
The apply can always be redone.
git reset --hard && git stash apply --index
But, I wouldn't be against making --index the default.
-brandon
^ permalink raw reply
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-10-20 16:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy70k5las.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 19, 2008 at 11:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
>
>> 2) my adaption of the following two lines from
>> builtin-fetch.c to the new verbosity option:
>> if (verbosity == VERBOSE)
>> transport->verbose = 1;
>> if (verbosity == QUIET)
>> transport->verbose = -1;
>
> Hmm, what's wrong with it? Looks Ok to me...
Just wanted to be sure it's correct, that's all.
Actually I think the old code:
if (verbose >= 2)
transport->verbose = 1;
is wrong and probably a leftover from old days
as Shawn confirmed.
>> static struct option builtin_fetch_options[] = {
>> - OPT__QUIET(&quiet),
>> - OPT__VERBOSE(&verbose),
>> + { OPTION_CALLBACK, 'q', "quiet", NULL, NULL,
>> + "operate quietly",
>> + PARSE_OPT_NOARG, option_parse_quiet },
>> + { OPTION_CALLBACK, 'v', "verbose", NULL, NULL,
>> + "be verbose",
>> + PARSE_OPT_NOARG, option_parse_verbose },
>
> Isn't there a OPTION_FOO that assigns a constant to the given variable?
Yes, there is - OPT_SET_INT and I've used that in my next patch.
>> @@ -192,7 +211,6 @@ static int s_update_ref(const char *action,
>>
>> static int update_local_ref(struct ref *ref,
>> const char *remote,
>> - int verbose,
>> char *display)
>> {
>> struct commit *current = NULL, *updated;
>> ...
>> @@ -366,18 +384,19 @@ static int store_updated_refs(const char *url, const char
>> *remote_name,
>> note);
>>
>> if (ref)
>> - rc |= update_local_ref(ref, what, verbose, note);
>> + rc |= update_local_ref(ref, what, note);
>
> Hmph, in the existing code, do_fetch()->fetch_refs()->store_updated_refs()
> callchain relies on the "verbose" to be global anyway, so losing the
> ability to call update_local_ref() with verbosity as parameter is not a
> huge deal.
OK, I've kept the removal of the verbose param in the next patch.
> I however think it would be more beneficial in the longer term to keep
> "verbosity" as parameter so the caller can tweak what the callee does, and
> making large part of what cmd_fetch() does callable from outside. That
> would involve making the builtin_fetch_options[] on-stack, and passing
> verbosity (and possibly other variables currently used as file-scope
> global) as parameters, which is outside of the scope of your patch, but it
> is something to keep in mind.
>
>> diff --git a/git-pull.sh b/git-pull.sh
>> index 75c3610..dc613db 100755
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -16,6 +16,7 @@ cd_to_toplevel
>> test -z "$(git ls-files -u)" ||
>> die "You are in the middle of a conflicted merge."
>>
>> +verbosity=
>> strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
>> curr_branch=$(git symbolic-ref -q HEAD)
>> curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
>
> It would fit at the end of the next line just fine, wouldn't it?
>
>> @@ -23,6 +24,10 @@ rebase=$(git config --bool branch.$curr_branch_short.rebase)
>> while :
>> do
>> case "$1" in
>> + -q|--quiet)
>> + verbosity="$verbosity -q" ;;
>> + -v|--verbose)
>> + verbosity="$verbosity -v" ;;
>
> You know verbosity flags (-q and -v) are "the last one wins", so I do not
> see much point in this concatenation.
Without concatenation I would need to analyze the content
of the variable each time the option is passed to the shell
script. Do you know of a simpler/better way still keeping the
functionality that
$ git pull -q -v --quiet --verbose --quiet gives verbosity=QUIET
and
$ git pull -q -v --quiet --verbose --quiet -v yields verbosity=VERBOSE
?
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-20 16:50 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Michael J Gruber, Peter Harris, git
In-Reply-To: <48FC8624.9090807@fastmail.fm>
Thanks for the explicit instructions, but I think I'm still missing
something. Here's exactly what I'm trying, just to make sure I'm not
doing something odd.
First I set up the remote in the main repo:
main/$ git remote add -f ThingOne git://thing/ThingOne.git
main/$ git merge -s ours --no-commit ThingOne/master
main/$ git read-tree --prefix=thing-one/ -u ThingOne/master
main/$ git commit -m "Adding ThingOne"
Then I make a clone, fetch main's refs to ThingOne, and try to pull in
changes from ThingOne by using those refs:
$ git clone /path/to/main clone
$ cd clone
clone/$ git config remote.origin.fetch \
'+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'
clone/$ git fetch
From /path/to/main/
* [new branch] ThingOne/master -> ThingOne/master
clone/$ git pull -s subtree git://thing/ThingOne.git ThingOne/master
fatal: Couldn't find remote ref ThingOne/master
The config & fetch commands indeed add a
.git/refs/remotes/ThingOne/master file to the clone, but I'm missing the
magic words for how to use that ref.
Also:
Michael J Gruber wrote:
>
>> 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.
I can appreciate that, but the approach leads to two consequences that I
suggest should be avoidable:
1. A and B both have to set up the references to C themselves. A can't
just piggyback on whatever B has already set up. (This is the impetus
for my original message.)
2. Suppose B is just a repository that's being shared between A and D --
i.e. there's no B entity doing any work directly in B. In this case if
A (or D) wants to change B's reference to C (say, to track a new branch
in C), they can't: B has to be changed directly, and nothing can be done
in a clone to accomplish this.
I admit I'm picking at nits here -- obviously someone is able to access
the B repo and do whatever needs doing. I just feel that there are some
situations where you want the origin's remotes in your clone, and some
where you don't, and git should let you decide.
Marc
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Christian Jaeger @ 2008-10-20 16:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48FCADA0.4020008@op5.se>
Andreas Ericsson wrote:
> Christian Jaeger wrote:
>> 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.
>>
>
> Then you'll be transferring all objects over the wire anyway
Why? Again, care to differentiate between technical feasibility and
current implementation.
I did make a list of cases in my pre-previous email which tried to go
through the implications.
>>> 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.
>>
>
> That's partially implemented, I think (google for Nguy (or something, I'm
> not very god with asian names),
That's not enough information for me to find what you've had in mind.
"stump Nguy site:marc.info" doesn't yield a result with Google.
> but your original suggestion said to save
> on transferring objects from one machine to another,
Yes
> which will play poorly
> with git's object database
Why, if we seem to already have agreed that the object database would be
a "stump"? It may play poorly with the current implementation of the
database maintainance code, but I don't see why it would play poorly
with the database's data structure design.
> and which you're now arguing against.
I don't get this part of the sentence.
I did (3 mails ago) say, "(one) could additionally look into
implementing a kind of shallow cloning". When you said that the kind of
repository I'm "arguing" for would be a "stump", that sounded exactly
what I've meant, in the same sense that a shallow clone creates a
repository that is missing part of the tree (or maybe DAG is a better
term). So I said "That was my point, yes", maybe I should have said
"That's what I've meant when I was saying a 'kind of shallow cloning'."
Ok? I might miss some fine points in the english language as I'm not a
native speaker.
>
> Please make up your mind.
About what?
Do you mean whether I want to implement the idea? Then no, I don't see
myself contributing any code for this. I certainly don't have a use case
personally where it would pay off. My motivation to contributing to this
thread was to point out that there is, afaik, nothing inherent in the
Git design (at least the database) which would absolutely prevent one
from implementing subdirectory checkouts (including even saving on
bandwith by doing some kind of shallow / stump / lazy cloning).
Christian.
^ permalink raw reply
* Re: Feedback outside of the user survey
From: Christian Jaeger @ 2008-10-20 17:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Garry Dolley, Richard Hartmann, git
In-Reply-To: <48FCB87B.1080207@jaeger.mine.nu>
Christian Jaeger wrote:
> Andreas Ericsson wrote:
>> Christian Jaeger wrote:
>>> 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.
>>>
>>
>> Then you'll be transferring all objects over the wire anyway
>
> Why? Again, care to differentiate between technical feasibility and
> current implementation.
I think it was this detail:
> ... lazy cloning
which I have been leaving under the carpet in my previous mails; i.e.
when doing merges, Git may need additional objects which haven't been
fetched by just fetching the branches's subdirectory parts, so merges
can't generally be done offline anymore. This is certainly a departure
from the current idea; and if you don't want to depart from that, then
yes, you'd need basically the whole database in advance or merges
wouldn't be possible. So I think I understand why you said "Then you'll
be transferring all objects over the wire anyway", you did assume that
there would be no such thing as on-demand / lazy fetching of missing
objects.
Christian.
^ permalink raw reply
* [PATCH] bash completion: Add 'workflows' to 'git help'
From: Lee Marlow @ 2008-10-20 17:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
Completion for new workflow documentation introduced in f948dd8
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d192927..eebe734 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -881,6 +881,7 @@ _git_help ()
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
+ workflows
"
}
--
1.6.0.2.588.g3102
^ permalink raw reply related
* [PATCH] workflows documentation: fix link to git-request-pull[1]
From: Lee Marlow @ 2008-10-20 17:35 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Lee Marlow
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
Documentation/gitworkflows.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 7fe9f72..2b021e3 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -258,7 +258,7 @@ from.
=====================================
You will still have to tell people by other means, such as mail. (Git
-provides the linkgit:request-pull[1] to send preformatted pull
+provides the linkgit:git-request-pull[1] to send preformatted pull
requests to upstream maintainers to simplify this task.)
If you just want to get the newest copies of the integration branches,
--
1.6.0.2.588.g3102
^ permalink raw reply related
* Re: [BUG?] Fail to pull from kernel.org: pack has bad object
From: Nicolas Pitre @ 2008-10-20 17:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: Johan Herland, Jeff King, git
In-Reply-To: <200810201610.54427.trast@student.ethz.ch>
On Mon, 20 Oct 2008, Thomas Rast wrote:
> 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
Yes, except I can't resolve any of the deltas in there... Is it from
the Linux kernel repository?
Nicolas
^ permalink raw reply
* Re: bug: git-stash save and symbolic links
From: Jeff King @ 2008-10-20 17:55 UTC (permalink / raw)
To: Simon Strandgaard; +Cc: git
In-Reply-To: <df1390cc0810200839q5eddad1cp4bc14762724d8848@mail.gmail.com>
On Mon, Oct 20, 2008 at 05:39:31PM +0200, Simon Strandgaard wrote:
> mkdir test &&
> echo content >test/file2 &&
> git add test/file2 &&
> git commit -m two &&
> cd .. &&
> ln -s repo/test linked &&
Ah, OK. You have a symlink into a subdirectory of the repository. Git
correctly finds the repository's .git directory, but then when we
attempt to 'cd' to the top-level of the working tree, we end up outside
of the repository. The culprit is actually "git rev-parse --show-cdup".
This demonstrates it more simply:
mkdir repo &&
(cd repo && git init) &&
mkdir repo/dir &&
ln -s repo/dir linked &&
cd linked && git rev-parse --show-cdup
which prints "../". But that's not right; we actually need to go to
"../repo".
I think the right solution in this situation is that we should _not_ be
setting is_inside_work_tree in setup_git_directory_gently, so that we
chdir to its absolute path. But I don't think we ever actually detect
the symlink during this setup, so I'm not sure how best to realize we
are _in_ this situation.
-Peff
^ 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