* 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
* Re: [BUG?] Fail to pull from kernel.org: pack has bad object
From: Jeff King @ 2008-10-20 17:56 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Thomas Rast, Johan Herland, git
In-Reply-To: <alpine.LFD.2.00.0810201112360.26244@xanadu.home>
On Mon, Oct 20, 2008 at 01:49:33PM -0400, Nicolas Pitre wrote:
> > 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?
I don't know about Thomas's example, but this one is from git.git:
http://peff.net/tmp_pack_c7KnC6
-Peff
^ permalink raw reply
* Re: [PATCH, RFC] diff: add option to show context between close chunks
From: René Scharfe @ 2008-10-20 18:06 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Davide Libenzi
In-Reply-To: <48FC9685.8030704@viscovery.net>
Johannes Sixt schrieb:
> 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.
The extra lines _are_ a disadvantage for me, since each chunk gets them
while only close ones need them -- that's wasted space. The intent is
to save time by not having to apply and rediff a patch on a mailing list
in order to see the hidden text; part of the savings would be lost if
the reader had to skip over extra lines.
Besides, this option is probably most useful if set by default on
machines not controlled by me. E.g. I wouldn't want to change an option
on a gitweb page, I'd want to get fused chunks by default. I wouldn't
want to write "best viewed with -U6" in a patch description, I'd want it
to just work (e.g. for gitk users).
I have to admit my main motivation was that one line gap, where a chunk
header hid an interesting line of context. Showing it didn't change the
length of the patch, so I found this to be a sad wastage.
Optimizing patches for readability makes sense since they are such an
important part of our communication here. I think --i-c-c=1 results in
an obvious win without much of a downside. I was surprised to find that
almost 4% of the chunks in git 1.6.0 would be eliminated by that option:
$ git log -p v1.6.0 | grep -c '^@@ '
60544
$ git log -p v1.6.0 --inter-chunk-context=1 | grep -c '^@@ '
58471
But perhaps a higher value would be even better?
$ git log v1.6.0 | wc -l
225441
$ git log -p v1.6.0 | wc -l
1736188
$ git log -p --inter-chunk-context=10 v1.6.0 | wc -l
1779048
$ git log -p -U8 v1.6.0 | wc -l
2214448
Well, I don't know if those patches are easier to read (haven't looked
at them), but I imagine that some related changes are presented with the
full context between them (e.g. changes to loop header and footer,
function signature and body). The numbers only show that it's
affordable (3% more lines with -i-c-c=10, 30% more lines with the
comparable -U8).
(Why 10? With the default of -U3, a chunk is 6 lines of context plus at
least one line of actual change. Two chunks are at least 14 lines long,
thus only 10 more fit into 24 lines, i.e. a terminal window..)
René
^ permalink raw reply
* [PATCH] fix for "index-pack: rationalize delta resolution code"
From: Nicolas Pitre @ 2008-10-20 18:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
My bad. A small detail went through the crack: the real_type of
a delta object is the real_type of its base object.
Without this, the created index will be wrong as the actual object SHA1
won't match the object.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
If you got a corrupted .idx file because of this ('git verify-pack'
should tell) then just toss it and recreate with a fixed 'git
index-pack'.
Could anyone having problems fetching from kernel.org with git from the
next branch confirm that this also fixes that? Thanks.
diff --git a/index-pack.c b/index-pack.c
index 0a917d7..8287ebf 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -517,7 +517,7 @@ static void resolve_delta(struct object_entry *delta_obj,
void *delta_data;
unsigned long delta_size;
- delta_obj->real_type = base->obj->type;
+ delta_obj->real_type = base->obj->real_type;
delta_data = get_data_from_pack(delta_obj);
delta_size = delta_obj->size;
result->obj = delta_obj;
^ permalink raw reply related
* How to push to http(s) repository with authentication?
From: Josef Wolf @ 2008-10-20 18:25 UTC (permalink / raw)
To: git
Hello,
I have set up a repository as described in
http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt
over SSL with basic authentication. DAV access works fine with konqueror,
cadaver and and curl, using this .curlrc:
$ cat ~/.curlrc
--cacert /etc/cacerts/myca.pem
--user user
$ curl https://repo.host.org/git/test/HEAD
Enter host password for user 'user':
ref: refs/heads/master
$
But when called from git, this file seems to be ignored. I have checked
google, but the only hint I could find was to put credentials into
~/.netrc. IMHO, this is a bad workaround, since this implies to have
unencrypted passwords lying around on the disk.
Any hints?
PS: I have asked a similar question a couple of days ago. Here is a link
to my original mail with more information how I set up the server:
http://marc.info/?l=git&m=122426078301793&w=2
^ permalink raw reply
* Re: [PATCH] fix for "index-pack: rationalize delta resolution code"
From: Harvey Harrison @ 2008-10-20 18:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <alpine.LFD.2.00.0810201357340.26244@xanadu.home>
On Mon, Oct 20, 2008 at 11:12 AM, Nicolas Pitre <nico@cam.org> wrote:
> My bad. A small detail went through the crack: the real_type of
> a delta object is the real_type of its base object.
>
> Without this, the created index will be wrong as the actual object SHA1
> won't match the object.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
This fixes it for me, thanks for the quick fix.
Tested-by: Harvey Harrison <harvey.harrison@gmail.com>
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Junio C Hamano @ 2008-10-20 18:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: SLONIK.AZ, git
In-Reply-To: <48FC5F1B.1050608@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>>...
>>
>> builtin-fetch--tool.c | 2 --
>> builtin-fetch.c | 2 --
>> 2 files changed, 0 insertions(+), 4 deletions(-)
>>
>> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
>> index 7460ab7..5d0b95f 100644
>> --- a/builtin-fetch--tool.c
>> +++ b/builtin-fetch--tool.c
>> @@ -160,8 +160,6 @@ static int append_fetch_head(FILE *fp,
>> for (i = remote_len - 1; remote[i] == '/' && 0 <= i; i--)
>> ;
>> remote_len = i + 1;
>> - if (4 < i && !strncmp(".git", remote + i - 3, 4))
>> - remote_len = i - 3;
>>
>> note_len = 0;
>> if (*what) {
>> diff --git a/builtin-fetch.c b/builtin-fetch.c
>> index ee93d3a..28123a5 100644
>> --- a/builtin-fetch.c
>> +++ b/builtin-fetch.c
>> @@ -348,8 +348,6 @@ static int store_updated_refs(const char *url,
>> const char *remote_name,
>> for (i = url_len - 1; url[i] == '/' && 0 <= i; i--)
>> ;
>> url_len = i + 1;
>> - if (4 < i && !strncmp(".git", url + i - 3, 4))
>> - url_len = i - 3;
>>
>
> Will this still play nicely with
>
> git clone foo.git
>
> ?
I think it would.
As far as I can tell, the only thing the patch changes is to disable the
long established "repository name clean-up" feature in the autogenerated
merge messages (iow, input to "fmt-merge-msg").
^ permalink raw reply
* [EGIT PATCH] git property page for project properties.
From: Tomi Pakarinen @ 2008-10-20 19:06 UTC (permalink / raw)
To: spearce; +Cc: git, Tomi Pakarinen
Show git property page in project's properties, if project
has git repository provider.
Signed-off-by: Tomi Pakarinen <tomi.pakarinen@iki.fi>
---
This is similar to CVS's property page. Current
information on page is very limited and non editable.
Tomi.
org.spearce.egit.ui/plugin.properties | 2 +
org.spearce.egit.ui/plugin.xml | 13 ++
.../preferences/GitProjectPropertyPage.java | 147 ++++++++++++++++++++
3 files changed, 162 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.egit.ui/src/org/spearce/egit/ui/internal/preferences/GitProjectPropertyPage.java
diff --git a/org.spearce.egit.ui/plugin.properties b/org.spearce.egit.ui/plugin.properties
index da91e48..fa043f1 100644
--- a/org.spearce.egit.ui/plugin.properties
+++ b/org.spearce.egit.ui/plugin.properties
@@ -1,6 +1,8 @@
plugin_name=Git Team Provider (UI)
provider_name=spearce.org
+Git=Git
+
Git_clone_category=Git
Git_clone_wizard=Git Repository
Git_clone_description=Clone an existing Git repository.
diff --git a/org.spearce.egit.ui/plugin.xml b/org.spearce.egit.ui/plugin.xml
index ee8a5a0..e6e3762 100644
--- a/org.spearce.egit.ui/plugin.xml
+++ b/org.spearce.egit.ui/plugin.xml
@@ -194,6 +194,19 @@
id="org.spearce.egit.ui.internal.preferences.WindowCachePreferencePage" />
</extension>
+ <extension point="org.eclipse.ui.propertyPages">
+ <page
+ objectClass="org.eclipse.core.resources.IProject"
+ adaptable="true"
+ name="%Git"
+ class="org.spearce.egit.ui.internal.preferences.GitProjectPropertyPage"
+ id="org.spearce.egit.ui.preferences.GitProjectPropertyPage">
+ <filter
+ name="projectPersistentProperty"
+ value="org.eclipse.team.core.repository=org.spearce.egit.core.GitProvider">
+ </filter>
+ </page>
+ </extension>
<extension point="org.eclipse.ui.decorators">
<decorator
lightweight="true"
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/preferences/GitProjectPropertyPage.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/preferences/GitProjectPropertyPage.java
new file mode 100644
index 0000000..fd7e14a
--- /dev/null
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/preferences/GitProjectPropertyPage.java
@@ -0,0 +1,147 @@
+/*******************************************************************************
+ * Copyright (C) 2008, Tomi Pakarinen <tomi.pakarinen@iki.fi>
+ *
+ * All rights reserved. This program and the accompanying materials
+ * are made available under the terms of the Eclipse Public License v1.0
+ * See LICENSE for the full license text, also available.
+ *******************************************************************************/
+package org.spearce.egit.ui.internal.preferences;
+
+import java.io.IOException;
+
+import org.eclipse.core.resources.IProject;
+import org.eclipse.core.runtime.IAdaptable;
+import org.eclipse.swt.SWT;
+import org.eclipse.swt.layout.GridData;
+import org.eclipse.swt.layout.GridLayout;
+import org.eclipse.swt.widgets.Composite;
+import org.eclipse.swt.widgets.Control;
+import org.eclipse.swt.widgets.Display;
+import org.eclipse.swt.widgets.Label;
+import org.eclipse.swt.widgets.Text;
+import org.eclipse.ui.dialogs.PropertyPage;
+import org.spearce.egit.core.project.RepositoryMapping;
+import org.spearce.jgit.lib.ObjectId;
+import org.spearce.jgit.lib.Repository;
+
+/**
+ * Property page to be shown in project properties, if project is shared using
+ * git provider. Currently there aren't any modifiable element.
+ */
+public class GitProjectPropertyPage extends PropertyPage {
+
+ Text gitDir;
+
+ Text branch;
+
+ Text id;
+
+ Text state;
+
+ Text workDir;
+
+ @Override
+ protected Control createContents(Composite parent) {
+ final Composite composite = new Composite(parent, SWT.NULL);
+
+ composite.setLayoutData(new GridData(SWT.FILL, SWT.FILL, true, true));
+ final GridLayout layout = new GridLayout();
+ layout.numColumns = 2;
+ layout.marginHeight = 0;
+ layout.marginWidth = 0;
+ layout.horizontalSpacing = 0;
+ layout.verticalSpacing = 0;
+ composite.setLayout(layout);
+
+ gitDir = createLabeledReadOnlyText(composite, "Git directory:");
+ workDir = createLabeledReadOnlyText(composite, "Working directory:");
+ branch = createLabeledReadOnlyText(composite, "Branch:");
+ id = createLabeledReadOnlyText(composite, "Id:");
+ state = createLabeledReadOnlyText(composite, "Current state:");
+
+ // Get the project that is the source of this property page
+ IProject project = null;
+ final IAdaptable element = getElement();
+ if (element instanceof IProject) {
+ project = (IProject) element;
+ } else {
+ Object adapter = element.getAdapter(IProject.class);
+ if (adapter instanceof IProject) {
+ project = (IProject) adapter;
+ }
+ }
+
+ Repository repository = RepositoryMapping.getMapping(project)
+ .getRepository();
+
+ if (repository != null) {
+ try {
+ fillValues(repository);
+ } catch (IOException e) {
+ e.printStackTrace();
+ }
+ }
+
+ return composite;
+ }
+
+ private void fillValues(Repository repository) throws IOException {
+ gitDir.setText(repository.getDirectory().getAbsolutePath());
+ branch.setText(repository.getBranch());
+ workDir.setText(repository.getWorkDir().getAbsolutePath());
+
+ switch (repository.getRepositoryState()) {
+ case BISECTING:
+ state.setText("Bisecting");
+ break;
+ case MERGING:
+ state.setText("Merging");
+ break;
+ case REBASING:
+ state.setText("Rebasing");
+ break;
+ case REBASING_INTERACTIVE:
+ state.setText("Rebasing interactive");
+ break;
+ case REBASING_MERGE:
+ state.setText("Rebasing merge");
+ break;
+ case SAFE:
+ state.setText("Safe");
+ break;
+ }
+
+ final ObjectId objectId = repository
+ .resolve(repository.getFullBranch());
+ id.setText(objectId.name());
+ }
+
+ /**
+ * Create a read only text field with a label
+ *
+ * @param parent
+ * the parent composite for new widgets
+ * @param labelText
+ * text for label
+ * @return the new read only text field
+ */
+ protected Text createLabeledReadOnlyText(Composite parent,
+ final String labelText) {
+ Label label = new Label(parent, SWT.LEFT);
+ label.setText(labelText);
+ GridData data = new GridData();
+ data.horizontalSpan = 1;
+ data.horizontalAlignment = GridData.FILL;
+ label.setLayoutData(data);
+
+ Text text = new Text(parent, SWT.LEFT | SWT.READ_ONLY);
+ text.setBackground(Display.getDefault().getSystemColor(
+ SWT.COLOR_WIDGET_BACKGROUND));
+ data = new GridData();
+ data.horizontalSpan = 1;
+ data.horizontalAlignment = GridData.FILL;
+ text.setLayoutData(data);
+ return text;
+ }
+
+}
--
1.6.0.2
^ permalink raw reply related
* Re: [PATCH] fix for "index-pack: rationalize delta resolution code"
From: Harvey Harrison @ 2008-10-20 19:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <590657100810201137m477b834cr9c940851b1a599d8@mail.gmail.com>
On Mon, Oct 20, 2008 at 11:37 AM, Harvey Harrison
<harvey.harrison@gmail.com> wrote:
> On Mon, Oct 20, 2008 at 11:12 AM, Nicolas Pitre <nico@cam.org> wrote:
>> My bad. A small detail went through the crack: the real_type of
>> a delta object is the real_type of its base object.
>>
>> Without this, the created index will be wrong as the actual object SHA1
>> won't match the object.
>>
>> Signed-off-by: Nicolas Pitre <nico@cam.org>
>
> This fixes it for me, thanks for the quick fix.
>
> Tested-by: Harvey Harrison <harvey.harrison@gmail.com>
>
Scratch that, it's back to failing again on my next update.
Harvey
^ 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