* [ANNOUNCE] GIT 1.6.0.4
From: Junio C Hamano @ 2008-11-09 18:07 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.6.0.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.0.4.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.0.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.0.4.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided
as courtesy.
RPMS/$arch/git-*-1.6.0.4-1.fc9.$arch.rpm (RPM)
Fixes since v1.6.0.3
--------------------
* 'git add -p' said "No changes" when only binary files were changed.
* 'git archive' did not work correctly in bare repositories.
* 'git checkout -t -b newbranch' when you are on detached HEAD was broken.
* when we refuse to detect renames because there are too many new or
deleted files, 'git diff' did not say how many there are.
* 'git push --mirror' tried and failed to push the stash; there is no
point in sending it to begin with.
* 'git push' did not update the remote tracking reference if the corresponding
ref on the remote end happened to be already up to date.
* 'git pull $there $branch:$current_branch' did not work when you were on
a branch yet to be born.
* when giving up resolving a conflicted merge, 'git reset --hard' failed
to remove new paths from the working tree.
* 'git send-email' had a small fd leak while scanning directory.
* 'git status' incorrectly reported a submodule directory as an untracked
directory.
* 'git svn' used deprecated 'git-foo' form of subcommand invocaition.
* 'git update-ref -d' to remove a reference did not honor --no-deref option.
* Plugged small memleaks here and there.
* Also contains many documentation updates.
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Jakub Narebski @ 2008-11-09 17:54 UTC (permalink / raw)
To: Steven Grimm; +Cc: git, Shawn O. Pearce, Jeff King, Petr Baudis, Tim Ansell
In-Reply-To: <F0422D64-2A35-4755-BD28-782BFA634AAC@midwinter.com>
Steven Grimm wrote:
> On Nov 9, 2008, at 3:49 AM, Jakub Narebski wrote:
>>
>> Still missing (neither video, nor slides, nor description, nor email)
>> are the following talks from GitTogether'08
>>
>>> * Steven: Life with git-svn
>
> Here are the slides from David's and my talk:
>
> http://docs.google.com/Presentation?id=dhhs72s2_1wtzbnsnj&invite=v4t8kr
Thanks. Added to http://git.or.cz/gitwiki/GitTogether
(even if I cannot view them in my old web browser).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Steven Grimm @ 2008-11-09 16:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn O. Pearce, Jeff King, Petr Baudis, Tim Ansell
In-Reply-To: <200811091249.40735.jnareb@gmail.com>
On Nov 9, 2008, at 3:49 AM, Jakub Narebski wrote:
> Still missing (neither video, nor slides, nor description, nor email)
> are the following talks from GitTogether'08
>> * Steven: Life with git-svn
Here are the slides from David's and my talk:
http://docs.google.com/Presentation?id=dhhs72s2_1wtzbnsnj&invite=v4t8kr
-Steve
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Jakub Narebski @ 2008-11-09 16:31 UTC (permalink / raw)
To: Kai Blin; +Cc: David Symonds, git, Johannes Schindelin, Tim Ansell
In-Reply-To: <200811091636.55343.kai@samba.org>
On Sun, 9 Nov 2008, Kai Blin wrote:
> On Saturday 08 November 2008 16:31:04 Jakub Narebski wrote:
>>>> * Tim: Git as a Media Repository
>>>> http://www.thousandparsec.net/~tim/media+git.pdf
>>>
>>> This has kicked off some mailing list discussion; I think this can be
>>> a major weak point for git, since checking out only a subtree (and
>>> only the latest revision) is the common SVN way, which copes with
>>> media repositories and the like just fine.
>>
>> Well, you can workaround this weakness by (ab)using submodules...
>> ...and one should always remember that casual partial checkouts
>> interfere a bit with whole-tree commits.
>
> Interesting. How would you use submodules to work around the fact that binary
> file changes diff very bad and produce huge histories with basically no value
> for the user of the working copy? Can you do this from a GUI, easily? We're
> talking about media repositories here, so our users are artists.
What I meant here (but perhaps was not clear) was (ab)using submodules
to allow to have full working repository without large [media] files
both in object database (repository) and without them checked out.
The workaround is to put all large files for example in 'media/' folder,
and make this folder be submodule. Each clone of repository can have
this 'media' submodule either present (both in object database, although
usually separate from main project object database), or not present
(not cloned and not checked out).
As to submodules UI and GUI support for submodules... currently it is
unfortunately lacking.
Note that I explicitly mentioned that (ab)using submodules to better
deal with large files is _workaround_, and not _solution_. Lazy clone
in version proposed by Tim is IMHO correct solution.
P.S. Could anybody document at last `delta' gitattribute?
P.P.S. You can have separate diff driver for binary files, but I don't
know anyone who uses for example some such for images...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How it was at GitTogether'08 ?
From: Kai Blin @ 2008-11-09 15:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: David Symonds, git, Johannes Schindelin
In-Reply-To: <200811081631.06229.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]
On Saturday 08 November 2008 16:31:04 Jakub Narebski wrote:
> > > * Tim: Git as a Media Repository
> > > http://www.thousandparsec.net/~tim/media+git.pdf
> >
> > This has kicked off some mailing list discussion; I think this can be
> > a major weak point for git, since checking out only a subtree (and
> > only the latest revision) is the common SVN way, which copes with
> > media repositories and the like just fine.
>
> Well, you can workaround this weakness by (ab)using submodules...
> ...and one should always remember that casual partial checkouts
> interfere a bit with whole-tree commits.
Interesting. How would you use submodules to work around the fact that binary
file changes diff very bad and produce huge histories with basically no value
for the user of the working copy? Can you do this from a GUI, easily? We're
talking about media repositories here, so our users are artists.
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH (GIT-GUI)] git-gui: Request blame metadata in utf-8.
From: Alexander Gavrilov @ 2008-11-09 15:53 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
The blame builtin now supports automatic conversion of
metadata encoding. By default it is converted to the
character set specified by i18n.logoutputencoding.
Since gui blame expects the data in utf-8, it is
necessary to specify the desired encoding directly.
An old version of the blame command will simply
ignore the option.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
lib/blame.tcl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lib/blame.tcl b/lib/blame.tcl
index 8d60f12..4875804 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -559,7 +559,7 @@ method _read_file {fd jump} {
} ifdeleted { catch {close $fd} }
method _exec_blame {cur_w cur_d options cur_s} {
- lappend options --incremental
+ lappend options --incremental --encoding=utf-8
if {$commit eq {}} {
lappend options --contents $path
} else {
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GIT-GUI)] git-gui: Add the Show SSH Key item to the clone dialog.
From: Alexander Gavrilov @ 2008-11-09 15:51 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
The user might need to see the key before cloning a repository.
This patch makes the relevant menu item available in the Select
Repository/Clone dialog.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
git-gui.sh | 20 +++++++++++---------
lib/choose_repository.tcl | 6 ++++++
2 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 12b496b..cf9ef6e 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -999,6 +999,17 @@ citool {
######################################################################
##
+## execution environment
+
+set have_tk85 [expr {[package vcompare $tk_version "8.5"] >= 0}]
+
+# Suggest our implementation of askpass, if none is set
+if {![info exists env(SSH_ASKPASS)]} {
+ set env(SSH_ASKPASS) [gitexec git-gui--askpass]
+}
+
+######################################################################
+##
## repository setup
set picked 0
@@ -1073,15 +1084,6 @@ set selected_commit_type new
set nullid "0000000000000000000000000000000000000000"
set nullid2 "0000000000000000000000000000000000000001"
-set have_tk85 [expr {[package vcompare $tk_version "8.5"] >= 0}]
-
-######################################################################
-
-# Suggest our implementation of askpass, if none is set
-if {![info exists env(SSH_ASKPASS)]} {
- set env(SSH_ASKPASS) [gitexec git-gui--askpass]
-}
-
######################################################################
##
## task management
diff --git a/lib/choose_repository.tcl b/lib/choose_repository.tcl
index 9091316..f9ff62a 100644
--- a/lib/choose_repository.tcl
+++ b/lib/choose_repository.tcl
@@ -43,12 +43,18 @@ constructor pick {} {
$w.mbar.apple add command \
-label [mc "About %s" [appname]] \
-command do_about
+ $w.mbar.apple add command \
+ -label [mc "Show SSH Key"] \
+ -command do_ssh_key
} else {
$w.mbar add cascade -label [mc Help] -menu $w.mbar.help
menu $w.mbar.help
$w.mbar.help add command \
-label [mc "About %s" [appname]] \
-command do_about
+ $w.mbar.help add command \
+ -label [mc "Show SSH Key"] \
+ -command do_ssh_key
}
wm protocol $top WM_DELETE_WINDOW exit
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH (GIT-GUI)] git-gui: Fix focus transition in the blame viewer.
From: Alexander Gavrilov @ 2008-11-09 15:36 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
Now that the blame viewer has a search panel, it should be
taken into account by the focus transition code. Otherwise
showing a commit tip (by accidentally moving the mouse to
the text frame) causes the focus to transfer away from the
search field.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
lib/blame.tcl | 16 ++++++++++++----
lib/search.tcl | 14 +++++++++++---
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/lib/blame.tcl b/lib/blame.tcl
index 765d08c..642f5ca 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -321,7 +321,7 @@ constructor new {i_commit i_path i_jump} {
tk_popup $w.ctxm %X %Y
"
bind $i <Shift-Tab> "[list focus $w_cviewer];break"
- bind $i <Tab> "[list focus $w_cviewer];break"
+ bind $i <Tab> "[cb _focus_search $w_cviewer];break"
}
foreach i [concat $w_columns $w_cviewer] {
@@ -337,10 +337,10 @@ constructor new {i_commit i_path i_jump} {
bind $i <Control-Key-f> {catch {%W yview scroll 1 pages};break}
}
- bind $w_cviewer <Shift-Tab> "[list focus $w_file];break"
+ bind $w_cviewer <Shift-Tab> "[cb _focus_search $w_file];break"
bind $w_cviewer <Tab> "[list focus $w_file];break"
- bind $w_cviewer <Button-1> [list focus $w_cviewer]
- bind $w_file <Visibility> [list focus $w_file]
+ bind $w_cviewer <Button-1> [list focus $w_cviewer]
+ bind $w_file <Visibility> [cb _focus_search $w_file]
bind $top <F7> [list searchbar::show $finder]
bind $top <Escape> [list searchbar::hide $finder]
bind $top <F3> [list searchbar::find_next $finder]
@@ -382,6 +382,14 @@ constructor new {i_commit i_path i_jump} {
_load $this $i_jump
}
+method _focus_search {win} {
+ if {[searchbar::visible $finder]} {
+ focus [searchbar::editor $finder]
+ } else {
+ focus $win
+ }
+}
+
method _handle_destroy {win} {
if {$win eq $w} {
_kill $this
diff --git a/lib/search.tcl b/lib/search.tcl
index d292f20..32c8656 100644
--- a/lib/search.tcl
+++ b/lib/search.tcl
@@ -19,11 +19,11 @@ constructor new {i_w i_text args} {
frame $w
label $w.l -text [mc Find:]
+ entry $w.ent -textvariable ${__this}::searchstring -background lightgreen
button $w.bn -text [mc Next] -command [cb find_next]
button $w.bp -text [mc Prev] -command [cb find_prev]
checkbutton $w.cs -text [mc Case-Sensitive] \
-variable ${__this}::casesensitive -command [cb _incrsearch]
- entry $w.ent -textvariable ${__this}::searchstring -background lightgreen
pack $w.l -side left
pack $w.cs -side right
pack $w.bp -side right
@@ -40,19 +40,27 @@ constructor new {i_w i_text args} {
}
method show {} {
- if {![winfo ismapped $w]} {
+ if {![visible $this]} {
grid $w
}
focus -force $w.ent
}
method hide {} {
- if {[winfo ismapped $w]} {
+ if {[visible $this]} {
focus $ctext
grid remove $w
}
}
+method visible {} {
+ return [winfo ismapped $w]
+}
+
+method editor {} {
+ return $w.ent
+}
+
method _get_new_anchor {} {
# use start of selection if it is visible,
# or the bounds of the visible area
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH] git send-email: add --body option for --compose
From: Joe MacDonald @ 2008-11-09 15:29 UTC (permalink / raw)
To: spearce; +Cc: git
If the --compose option is specified, --body will allow you to specify a
file that should be included in the message body when the editor starts
up.
Signed-off-by: Joe MacDonald <joe.macdonald@gmail.com>
---
I use --compose with nearly all of my send-email bundles, but
immediately after I enter the editor I read in the contents of another
text file that contains boilerplate text. So I modified
git-send-email.perl to take a new option --body, which takes a filename
as an argument and appends the contents of that file to the standard
text that send-email normally puts into the .msg.$$ (or whatever file is
pointed to by $compose_filename).
I suppose this is even a step closer to having a batch version of
send-email that will include an introduction email in the patch thread,
but I don't know that such a thing is really useful to anyone. It would
be for me, but I might be a special case (or at least a minority) in
that.
git-send-email.perl | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 94ca5c8..17120d3 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -48,6 +48,7 @@ git send-email [options] <file | directory>...
--subject <str> * Email "Subject:"
--in-reply-to <str> * Email "In-Reply-To:"
--compose * Open an editor for introduction.
+ --body <str> * Initial body for the introduction.
Sending:
--envelope-sender <str> * Email envelope sender.
@@ -156,6 +157,7 @@ my ($smtp_server, $smtp_server_port,
$smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, @smtp_host_parts);
my ($validate);
my (@suppress_cc);
+my ($compose_body);
my %config_bool_settings = (
"thread" => [\$thread, 1],
@@ -222,6 +224,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"smtp-encryption=s" => \$smtp_encryption,
"identity=s" => \$identity,
"compose" => \$compose,
+ "body=s" => \$compose_body,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
@@ -483,7 +486,11 @@ if (!defined $smtp_server) {
if ($compose) {
# Note that this does not need to be secure, but we will make a small
# effort to have it be unique
- open(C,">",$compose_filename)
+ if ($compose_body) {
+ open(CB, "<",$compose_body)
+ or die "Failed to open $compose_body : ". $!;
+ }
+ open(C,">>",$compose_filename)
or die "Failed to open for writing $compose_filename: $!";
print C "From $sender # This line is ignored.\n";
printf C "Subject: %s\n\n", $initial_subject;
@@ -494,6 +501,11 @@ GIT: Consider including an overall diffstat or
table of contents
GIT: for the patch you are writing.
EOT
+ if ($compose_body) {
+ local $/;
+ print C <CB>;
+ close(CB);
+ }
close(C);
my $editor = $ENV{GIT_EDITOR} || Git::config(@repo, "core.editor")
|| $ENV{VISUAL} || $ENV{EDITOR} || "vi";
--
1.6.0.3.640.g6331a.dirty
^ permalink raw reply related
* force a merge conflict
From: Caleb Cushing @ 2008-11-09 15:09 UTC (permalink / raw)
To: git
is there any way to force a merge conflict?
there are 2 projects which have basically diverged becoming
incompatible, and both have updated since there common ancestry. I'm
working slowing on merging them back together.
in this case I have a dev branch and fork branch the fork is a copy of
dev except I committed one of the files from the fork. I need to merge
this file back into dev, but git thinks it's a fast forward, because
it really is for git, in reality it isn't, both files have newer
history than their common ancestry.
--
Caleb Cushing
^ permalink raw reply
* [PATCH (GITK)] gitk: Fix commit encoding support.
From: Alexander Gavrilov @ 2008-11-09 15:06 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras
This commit fixes two problems with commit encodings:
1) git-log actually uses i18n.logoutputencoding to generate
its output, and falls back to i18n.commitencoding only
when that option is not set. Thus, gitk should use its
value to read the results, if available.
2) The readcommit function did not process encodings at all.
This led to randomly appearing misconverted commits if
the commit encoding differed from the current locale.
Now commit messages should be displayed correctly, except
when logoutputencoding is set to an encoding that cannot
represent charecters in the message. For example, it is
impossible to convert Japanese characters from Shift-JIS
to CP-1251 (although the reverse conversion works).
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 25 +++++++++++++++++++++++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index ae775b1..3834fc0 100755
--- a/gitk
+++ b/gitk
@@ -1555,9 +1555,27 @@ proc chewcommits {} {
return 0
}
+proc do_readcommit {id} {
+ global tclencoding
+
+ # Invoke git-log to handle automatic encoding conversion
+ set fd [open [concat | git log --no-color --pretty=raw -1 $id] r]
+ # Read the results using i18n.logoutputencoding
+ fconfigure $fd -translation lf -eofchar {}
+ if {$tclencoding != {}} {
+ fconfigure $fd -encoding $tclencoding
+ }
+ set contents [read $fd]
+ close $fd
+ # Remove the heading line
+ regsub {^commit [0-9a-f]+\n} $contents {} contents
+
+ return $contents
+}
+
proc readcommit {id} {
- if {[catch {set contents [exec git cat-file commit $id]}]} return
- parsecommit $id $contents 0
+ if {[catch {set contents [do_readcommit $id]}]} return
+ parsecommit $id $contents 1
}
proc parsecommit {id contents listed} {
@@ -10565,6 +10583,9 @@ set gitencoding {}
catch {
set gitencoding [exec git config --get i18n.commitencoding]
}
+catch {
+ set gitencoding [exec git config --get i18n.logoutputencoding]
+}
if {$gitencoding == ""} {
set gitencoding "utf-8"
}
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* Re: [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Alexander Gavrilov @ 2008-11-09 14:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18708.11537.229423.296701@cargo.ozlabs.ibm.com>
On Friday 07 November 2008 14:57:05 Paul Mackerras wrote:
> Alexander Gavrilov writes:
>
> > For some reason, on Windows all transient windows are placed
> > in the upper left corner of the screen. Thus, it is necessary
> > to explicitly position the windows relative to their parent.
> > For simplicity this patch uses the function that is used
> > internally by Tk dialogs.
>
> Is there any reason to call tk::PlaceWindow under Linux or MacOS?
> If not I'd rather add an if statement so we only call it on Windows.
I don't know about MacOS, but in Linux it does seem unnecessary, so:
--- >8 ---
Subject: [PATCH] gitk: Explicitly position popup windows.
For some reason, on Windows all transient windows are placed
in the upper left corner of the screen. Thus, it is necessary
to explicitly position the windows relative to their parent.
For simplicity this patch uses the function that is used
internally by Tk dialogs.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 29 +++++++++++++++++++++++++++--
1 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 1363d20..d72412c 100755
--- a/gitk
+++ b/gitk
@@ -1739,7 +1739,17 @@ proc removehead {id name} {
unset headids($name)
}
-proc show_error {w top msg} {
+proc center_window {window origin} {
+ # Let platforms with a real window manager
+ # deal with it on their own
+ if {$::tcl_platform(platform) ne {windows}} return
+
+ # Use a handy function from Tk. Note that it
+ # calls 'update' to figure out dimensions.
+ tk::PlaceWindow $window widget $origin
+}
+
+proc show_error {w top msg {owner {}}} {
message $w.m -text $msg -justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
button $w.ok -text [mc OK] -command "destroy $top"
@@ -1748,6 +1758,9 @@ proc show_error {w top msg} {
bind $top <Key-Return> "destroy $top"
bind $top <Key-space> "destroy $top"
bind $top <Key-Escape> "destroy $top"
+ if {$owner ne {}} {
+ center_window $top $owner
+ }
tkwait window $top
}
@@ -1755,7 +1768,7 @@ proc error_popup {msg {owner .}} {
set w .error
toplevel $w
wm transient $w $owner
- show_error $w $w $msg
+ show_error $w $w $msg $owner
}
proc confirm_popup {msg {owner .}} {
@@ -1774,6 +1787,7 @@ proc confirm_popup {msg {owner .}} {
bind $w <Key-Return> "set confirm_ok 1; destroy $w"
bind $w <Key-space> "set confirm_ok 1; destroy $w"
bind $w <Key-Escape> "destroy $w"
+ center_window $w $owner
tkwait window $w
return $confirm_ok
}
@@ -2572,6 +2586,7 @@ Use and redistribute under the terms of the GNU General Public License"] \
bind $w <Visibility> "focus $w.ok"
bind $w <Key-Escape> "destroy $w"
bind $w <Key-Return> "destroy $w"
+ center_window $w .
}
proc keys {} {
@@ -2635,6 +2650,7 @@ proc keys {} {
bind $w <Visibility> "focus $w.ok"
bind $w <Key-Escape> "destroy $w"
bind $w <Key-Return> "destroy $w"
+ center_window $w .
}
# Procedures for manipulating the file list window at the
@@ -3687,6 +3703,7 @@ proc vieweditor {top n title} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid columnconfigure $top.buts 2 -weight 1 -uniform a
pack $top.buts -in $top -side top -fill x
+ center_window $top .
focus $top.t
}
@@ -7950,6 +7967,7 @@ proc mkpatch {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.fname
+ center_window $top .
}
proc mkpatchrev {} {
@@ -8024,6 +8042,7 @@ proc mktag {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.tag
+ center_window $top .
}
proc domktag {} {
@@ -8131,6 +8150,7 @@ proc writecommit {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.fname
+ center_window $top .
}
proc wrcomgo {} {
@@ -8181,6 +8201,7 @@ proc mkbranch {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - -pady 10 -sticky ew
focus $top.name
+ center_window $top .
}
proc mkbrgo {top} {
@@ -8341,6 +8362,7 @@ proc resethead {} {
bind $w <Key-Escape> [list destroy $w]
pack $w.cancel -side right -fill x -padx 20 -pady 20
bind $w <Visibility> "grab $w; focus $w"
+ center_window $w .
tkwait window $w
if {!$confirm_ok} return
if {[catch {set fd [open \
@@ -8526,6 +8548,7 @@ proc showrefs {} {
bind $top.list <ButtonRelease-1> {sel_reflist %W %x %y; break}
set reflist {}
refill_reflist
+ center_window $top .
}
proc sel_reflist {w x y} {
@@ -9878,6 +9901,7 @@ proc choosefont {font which} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
pack $top.buts -side bottom -fill x
trace add variable fontparam write chg_fontparam
+ center_window $top $prefstop
} else {
raise $top
$top.c itemconf text -text $which
@@ -10060,6 +10084,7 @@ proc doprefs {} {
grid columnconfigure $top.buts 1 -weight 1 -uniform a
grid $top.buts - - -pady 10 -sticky ew
bind $top <Visibility> "focus $top.buts.ok"
+ center_window $top .
}
proc choose_extdiff {} {
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* [PATCH] bisect: fix missing "exit"
From: Christian Couder @ 2008-11-09 14:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In my previous patch:
6a54d97 (2008-09-06 07:27:03 +0200 Christian Couder) bisect: remove "checkout_done" variable used when checking merge bases
I forgot to move '|| exit' to a line above.
This patch should fix that.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 79de701..0d0e278 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -455,7 +455,7 @@ bisect_next() {
good=$(git for-each-ref --format='^%(objectname)' \
"refs/bisect/good-*" | tr '\012' ' ') &&
skip=$(git for-each-ref --format='%(objectname)' \
- "refs/bisect/skip-*" | tr '\012' ' ') &&
+ "refs/bisect/skip-*" | tr '\012' ' ') || exit
# Maybe some merge bases must be tested first
check_good_are_ancestors_of_bad "$bad" "$good" "$skip"
--
1.6.0.3.614.g0f3b9
^ permalink raw reply related
* Re: [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Francis Galiegue @ 2008-11-09 14:13 UTC (permalink / raw)
To: Ian Hilt; +Cc: Git Mailing List, Pierre Habouzit
In-Reply-To: <1226235588-2997-1-git-send-email-ian.hilt@gmx.com>
Le Sunday 09 November 2008 13:59:48 Ian Hilt, vous avez écrit :
> Sometimes specifying the recipient addresses can be tedious on the
> command-line. This commit will allow the user to edit the recipient
> addresses in their editor of choice.
>
> Signed-off-by: Ian Hilt <ian.hilt@gmx.com>
> ---
[...]
> + if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
Greedy operators are only supported with perl 5.10 or more... I think it's a
bad idea to use them...
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 6 83 87 78 75
Tel : +33 (0) 1 78 94 55 52
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
^ permalink raw reply
* [PATCH] Documentation: bisect: change a few instances of "git-cmd" to "git cmd"
From: Christian Couder @ 2008-11-09 13:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/git-bisect.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index c7981ef..39034ec 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -26,7 +26,7 @@ on the subcommand:
git bisect log
git bisect run <cmd>...
-This command uses 'git-rev-list --bisect' to help drive the
+This command uses 'git rev-list --bisect' to help drive the
binary search process to find which change introduced a bug, given an
old "good" commit object name and a later "bad" commit object name.
@@ -101,7 +101,7 @@ $ git bisect visualize
to see the currently remaining suspects in 'gitk'. `visualize` is a bit
too long to type and `view` is provided as a synonym.
-If 'DISPLAY' environment variable is not set, 'git-log' is used
+If 'DISPLAY' environment variable is not set, 'git log' is used
instead. You can even give command line options such as `-p` and
`--stat`.
@@ -215,7 +215,7 @@ tweaks (e.g., s/#define DEBUG 0/#define DEBUG 1/ in a header file, or
work around other problem this bisection is not interested in")
applied to the revision being tested.
-To cope with such a situation, after the inner 'git-bisect' finds the
+To cope with such a situation, after the inner 'git bisect' finds the
next revision to test, with the "run" script, you can apply that tweak
before compiling, run the real test, and after the test decides if the
revision (possibly with the needed tweaks) passed the test, rewind the
--
1.6.0.3.614.g0f3b9
^ permalink raw reply related
* [PATCH] Documentation: rev-list: change a few instances of "git-cmd" to "git cmd"
From: Christian Couder @ 2008-11-09 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/rev-list-options.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index 966276b..68a253f 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -285,7 +285,7 @@ See also linkgit:git-reflog[1].
History Simplification
~~~~~~~~~~~~~~~~~~~~~~
-When optional paths are given, 'git-rev-list' simplifies commits with
+When optional paths are given, 'git rev-list' simplifies commits with
various strategies, according to the options you have selected.
Suppose you specified `foo` as the <paths>. We shall call commits
@@ -466,14 +466,14 @@ Limit output to the one commit object which is roughly halfway between
the included and excluded commits. Thus, if
-----------------------------------------------------------------------
- $ git-rev-list --bisect foo ^bar ^baz
+ $ git rev-list --bisect foo ^bar ^baz
-----------------------------------------------------------------------
outputs 'midpoint', the output of the two commands
-----------------------------------------------------------------------
- $ git-rev-list foo ^midpoint
- $ git-rev-list midpoint ^bar ^baz
+ $ git rev-list foo ^midpoint
+ $ git rev-list midpoint ^bar ^baz
-----------------------------------------------------------------------
would be of roughly the same length. Finding the change which
--
1.6.0.3.614.g0f3b9
^ permalink raw reply related
* [PATCH] git send-email: edit recipient addresses with the --compose flag
From: Ian Hilt @ 2008-11-09 12:59 UTC (permalink / raw)
To: Git Mailing List; +Cc: Pierre Habouzit
Sometimes specifying the recipient addresses can be tedious on the
command-line. This commit will allow the user to edit the recipient
addresses in their editor of choice.
Signed-off-by: Ian Hilt <ian.hilt@gmx.com>
---
This is on top of Pierre's most recent series. I'm not exactly happy
with the way it turned out, but it seems to function correctly.
Comments are most welcome.
[ This is a resend. I don't know what happened to the first mail I
sent to the list. ]
git-send-email.perl | 60 ++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index fd72127..3a22767 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -455,6 +455,9 @@ if ($compose) {
my $tpl_sender = $sender || $repoauthor || $repocommitter || '';
my $tpl_subject = $initial_subject || '';
my $tpl_reply_to = $initial_reply_to || '';
+ my $tpl_to = join(', ', @to);
+ my $tpl_cc = join(', ', @initial_cc);
+ my $tpl_bcc = join(', ', @bcclist);
print C <<EOT;
From $tpl_sender # This line is ignored.
@@ -464,6 +467,9 @@ GIT: for the patch you are writing.
GIT:
GIT: Clear the body content if you don't wish to send a summary.
From: $tpl_sender
+To: $tpl_to
+Cc: $tpl_cc
+Bcc: $tpl_bcc
Subject: $tpl_subject
In-Reply-To: $tpl_reply_to
@@ -487,9 +493,31 @@ EOT
open(C,"<",$compose_filename)
or die "Failed to open $compose_filename : " . $!;
+ local $/;
+ my $c_file = <C>;
+ $/ = "\n";
+ close(C);
+
+ my (@tmp_to, @tmp_cc, @tmp_bcc);
+
+ if ($c_file =~ /^To:\s*+(.+)\s*\nCc:/ism) {
+ @tmp_to = get_recipients($1);
+ }
+ if ($c_file =~ /^Cc:\s*+(.+)\s*\nBcc:/ism) {
+ @tmp_cc = get_recipients($1);
+ }
+ if ($c_file =~ /^Bcc:\s*+(.+)\s*\nSubject:/ism) {
+ @tmp_bcc = get_recipients($1);
+ }
+
+
my $need_8bit_cte = file_has_nonascii($compose_filename);
my $in_body = 0;
my $summary_empty = 1;
+
+ open(C,"<",$compose_filename)
+ or die "Failed to open $compose_filename : " . $!;
+
while(<C>) {
next if m/^GIT: /;
if ($in_body) {
@@ -518,15 +546,21 @@ EOT
} elsif (/^From:\s*(.+)\s*$/i) {
$sender = $1;
next;
- } elsif (/^(?:To|Cc|Bcc):/i) {
- print "To/Cc/Bcc fields are not interpreted yet, they have been ignored\n";
- next;
}
print C2 $_;
}
close(C);
close(C2);
+ if (@tmp_to) {
+ @to = @tmp_to;
+ }
+ if (@tmp_cc) {
+ @initial_cc = @tmp_cc;
+ }
+ if (@tmp_bcc) {
+ @bcclist = @tmp_bcc;
+ }
if ($summary_empty) {
print "Summary email is empty, skpping it\n";
$compose = -1;
@@ -1070,3 +1104,23 @@ sub file_has_nonascii {
}
return 0;
}
+
+sub get_recipients {
+ my $match = shift(@_);
+ my @recipients = split(/\s*,\s*/, $match);
+ for (my $i = 0; $i <= $#recipients; ++$i) {
+ if ($recipients[$i] eq "") {
+ splice(@recipients, $i, 1);
+ } elsif ($recipients[$i] =~ /"/) {
+ my $x = $i;
+ my $tmp;
+ while ($recipients[$i] !~ /</) {
+ $tmp = join(', ', $recipients[$i],$recipients[$i+1]);
+ ++$i;
+ splice(@recipients, $i, 1, $tmp);
+ }
+ splice(@recipients, $x, $i, $tmp);
+ }
+ }
+ return @recipients;
+}
--
1.6.0.3.523.g304d0
^ permalink raw reply related
* Re: How it was at GitTogether'08 ?
From: Jakub Narebski @ 2008-11-09 11:49 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Jeff King, Petr Baudis, Steven Grimm, Tim Ansell
In-Reply-To: <200811080254.53202.jnareb@gmail.com>
On Sat, 8 Nov 2008, Jakub Narębski wrote:
> GitTogether 2008, which took place October 27(Mon)-29(Wed), has ended more
> than week ago. Therefore I'd like to ask you impressions (while it is still
> fresh) from GitTogether, describe talks which are not described below,
> correct wrong information in below, etc.
>
> Please reply to this email while GitTogether is on front of your mind...
Still missing (neither video, nor slides, nor description, nor email)
are the following talks from GitTogether'08
> Talks at GitTogether 2008
> =========================
>
> Mon, Oct 27, 2008
> -----------------
> * Jeff: Helping new contributors join
> * Shawn: JGit
> Tue, Oct 28, 2008
> -----------------
> * Jeff: What needs refactoring?
> * Lighting Round Talks
> - Jeff: Portability autobuilders
> - Petr: Quick TopGit introduction, problems, future plans
> * Steven: Life with git-svn
> Wed, Oct 29, 2008
> -----------------
+ What was the difference between "Tim: Large media in Git (Repeat)"
from Wed, and earlier "Tim: Git as a Media Repository" from Tue?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH (GITK) v3 3/6] gitk: Add accelerators to frequently used menu commands.
From: Alexander Gavrilov @ 2008-11-09 11:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18708.11115.293282.71076@cargo.ozlabs.ibm.com>
On Friday 07 November 2008 14:50:03 Paul Mackerras wrote:
> Alexander Gavrilov writes:
>
> > - eval $m add $params [lrange $i 4 end]
> > + set tail [lrange $i 4 end]
> > + regsub -all {\$M1T\y} $tail $M1T tail
> > + eval $m add $params $tail
>
> This is solving the problem that the $M1T doesn't get expanded in the
> call below because it's inside {}. If we are going to have a magic
> string that gets expanded like this, I'd rather it didn't look like a
> variable reference, because that is confusing.
How about "Meta1" then?
> Alternatively, we could define a [meta] function that does this:
>
> proc meta {x} {
> if {[tk windowingsystem] eq "aqua"} {
> return Cmd-$x
> }
> return Ctrl-$x
> }
>
> and then use -accelerator [meta F5] in the makemenu call, and not have
> any magic string substitution in makemenu. That will work since the
> eval will evaluate the [].
For some reason it didn't work. Maybe I did something wrong.
--- >8 ---
Subject: [PATCH] gitk: Add accelerators to frequently used menu commands.
This commit documents keyboard accelerators used for menu
commands in the menu, as it is usually done, and adds some
more, e.g. F4 to invoke Edit View.
The changes include a workaround for handling Shift-F4 on
systems where XKB binds special XF86_Switch_VT_* symbols
to Ctrl-Alt-F* combinations. Tk often receives these codes
when Shift-F* is pressed, so it is necessary to bind the
relevant actions to them as well.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
gitk | 36 +++++++++++++++++++++++++++++-------
1 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/gitk b/gitk
index 41d3d2d..a9618dc 100755
--- a/gitk
+++ b/gitk
@@ -1801,6 +1801,11 @@ proc setoptions {} {
# command to invoke for command, or {variable value} for radiobutton
proc makemenu {m items} {
menu $m
+ if {[tk windowingsystem] eq {aqua}} {
+ set Meta1 Cmd
+ } else {
+ set Meta1 Ctrl
+ }
foreach i $items {
set name [mc [lindex $i 1]]
set type [lindex $i 2]
@@ -1826,7 +1831,9 @@ proc makemenu {m items} {
-value [lindex $thing 1]
}
}
- eval $m add $params [lrange $i 4 end]
+ set tail [lrange $i 4 end]
+ regsub -all {\yMeta1\y} $tail $Meta1 tail
+ eval $m add $params $tail
if {$type eq "cascade"} {
makemenu $m.$submenu $thing
}
@@ -1860,17 +1867,17 @@ proc makewindow {} {
makemenu .bar {
{mc "File" cascade {
{mc "Update" command updatecommits -accelerator F5}
- {mc "Reload" command reloadcommits}
+ {mc "Reload" command reloadcommits -accelerator Meta1-F5}
{mc "Reread references" command rereadrefs}
- {mc "List references" command showrefs}
- {mc "Quit" command doquit}
+ {mc "List references" command showrefs -accelerator F2}
+ {mc "Quit" command doquit -accelerator Meta1-Q}
}}
{mc "Edit" cascade {
{mc "Preferences" command doprefs}
}}
{mc "View" cascade {
- {mc "New view..." command {newview 0}}
- {mc "Edit view..." command editview -state disabled}
+ {mc "New view..." command {newview 0} -accelerator Shift-F4}
+ {mc "Edit view..." command editview -state disabled -accelerator F4}
{mc "Delete view" command delview -state disabled}
{xx "" separator}
{mc "All files" radiobutton {selectedview 0} -command {showview 0}}
@@ -2232,7 +2239,12 @@ proc makewindow {} {
bindkey <Key-Return> {dofind 1 1}
bindkey ? {dofind -1 1}
bindkey f nextfile
- bindkey <F5> updatecommits
+ bind . <F5> updatecommits
+ bind . <$M1B-F5> reloadcommits
+ bind . <F2> showrefs
+ bind . <Shift-F4> {newview 0}
+ catch { bind . <Shift-Key-XF86_Switch_VT_4> {newview 0} }
+ bind . <F4> edit_or_newview
bind . <$M1B-q> doquit
bind . <$M1B-f> {dofind 1 1}
bind . <$M1B-g> {dofind 1 0}
@@ -3483,6 +3495,16 @@ proc newview {ishighlight} {
vieweditor $top $nextviewnum [mc "Gitk view definition"]
}
+proc edit_or_newview {} {
+ global curview
+
+ if {$curview > 0} {
+ editview
+ } else {
+ newview 0
+ }
+}
+
proc editview {} {
global curview
global viewname viewperm newviewname newviewperm
--
1.6.0.3.15.gb8d36
^ permalink raw reply related
* Re: [PATCH (GITK) v3 6/6] gitk: Explicitly position popup windows.
From: Paul Mackerras @ 2008-11-09 11:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: Alexander Gavrilov, git
In-Reply-To: <81b0412b0811070639q47244bc4t10791781fb0ec43b@mail.gmail.com>
Alex Riesen writes:
> > Is there any reason to call tk::PlaceWindow under Linux or MacOS?
> > If not I'd rather add an if statement so we only call it on Windows.
> >
>
> Yes, please. I rather like the smart placement in compiz.
Do you mean "please add the if statement", i.e. don't call
tk::PlaceWindow under Linux? Like Johannes Sixt, I find your request
ambiguous. :)
Paul.
^ permalink raw reply
* Re: [PATCH 1/4] t5400: expect success for denying deletion
From: Jan Krüger @ 2008-11-09 10:38 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano, Sam Vilain
In-Reply-To: <20081107220955.GA16058@coredump.intra.peff.net>
Hi,
On Fri, 7 Nov 2008 17:09:55 -0500, Jeff King <peff@peff.net> wrote:
> Reading over the mailing list postings which led to a240de11, I think
> it is simply a case that Jan didn't fully understand what
> expect_failure meant
Yes, that's exactly what happened, and it won't likely happen again.
Thanks for fixing and for the Cc.
-Jan
^ permalink raw reply
* Re: libgit2 - a true git library
From: Andreas Ericsson @ 2008-11-09 10:17 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Steve Frécinaux, Shawn O. Pearce, git, Scott Chacon
In-Reply-To: <20081108172759.GA31655@artemis.corp>
Pierre Habouzit wrote:
> On Sat, Nov 08, 2008 at 02:35:55PM +0000, Andreas Ericsson wrote:
>> Steve Frécinaux wrote:
>>> Just a random question: is there a reason why you have put all the
>>> .h in a separate includes/ directory instead of relying on the
>>> install target to put the include files at the right place ?
>>> To me it makes it much harder to hack on the files as one is always
>>> required to switch between both directories...
>> I agree with this, but as I guess Shawn will do roughly 45 times more
>> work on it than me (according to current commit-count in git.git), I'll
>> live with it.
>
> I don't, modifying the public includes may break the ABI and the API.
>
> I believe it to be a good practice to put them in a separate directory
> so that people modifying them will know this particular header is
> public. Yes you can name your private headers differently, but it's not
> really the same, it doesn't make editing public headers hard, and it has
> to. People modifying them _have_ to thing "err why am I modifying this
> specific header in the first place" before doing anything in it.
>
Well, I suggested putting "src/public/public_header.h" quite early on,
with private headers next to the source. AFAIU, the private and public
headers both are now located in the same directory, and that directory is
separate from the .c files.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-09 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <ddb82bf60811061909m6f8a7b72o4b03ebcde8b9d188@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]
Same thing done the right way.
regards,
P.
On Fri, Nov 7, 2008 at 04:09, Piotr Findeisen <piotr.findeisen@gmail.com> wrote:
>
> Hello!
>
> I've been reading
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html till
> late night and found that "--" prefixing options names (like in "git
> diff --cached") are replaced by asciidoc with a single unicode
> character "—" which makes them unsuitable for pasting them to a
> terminal.
>
> I've cloned the git repository from
> git://git.kernel.org/pub/scm/git/git.git, made some changes to
> Documentation/user-manual.txt, tested the results and commited my work
> locally.
> The attached file is a result of running `git diff HEAD~1`.
>
> My local log message:
> ------------------
> asciidoc escaping of "--"
>
> Asciidoc replaces "--" with "—" when not in verbatim mode. This is
> sometimes unwanted -- especially when citing command line options like
> "git diff --cached". This commit includes proper quotes in user-manual.txt.
> ------------------
>
> Hope that's of any use.
>
> Best regards,
> Piotr
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: user-manual.txt.patch --]
[-- Type: text/x-diff; name=user-manual.txt.patch, Size: 6445 bytes --]
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 645d752..d200759 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -527,7 +527,7 @@ $ git reset --hard fb47ddb2db...
then test, run "bisect good" or "bisect bad" as appropriate, and
continue.
-Instead of "git bisect visualize" and then "git reset --hard
+Instead of "git bisect visualize" and then "git reset \--hard
fb47ddb2db...", you might just want to tell git that you want to skip
the current commit:
@@ -900,7 +900,7 @@ $ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
-------------------------------------------------
(See linkgit:git-rev-parse[1] for explanations of commit-selecting
-syntax such as `--not`.)
+syntax such as `\--not`.)
[[making-a-release]]
Creating a changelog and tarball for a software release
@@ -1024,7 +1024,7 @@ at step 3, git maintains a snapshot of the tree's contents in a
special staging area called "the index."
At the beginning, the content of the index will be identical to
-that of the HEAD. The command "git diff --cached", which shows
+that of the HEAD. The command "git diff \--cached", which shows
the difference between the HEAD and the index, should therefore
produce no output at that point.
@@ -1572,7 +1572,7 @@ Recovering lost changes
Reflogs
^^^^^^^
-Say you modify a branch with `linkgit:git-reset[1] --hard`, and then
+Say you modify a branch with `linkgit:git-reset[1] \--hard`, and then
realize that the branch was the only reference you had to that point in
history.
@@ -1701,7 +1701,7 @@ $ git pull
More generally, a branch that is created from a remote branch will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
-linkgit:git-config[1], and the discussion of the `--track` option in
+linkgit:git-config[1], and the discussion of the `\--track` option in
linkgit:git-checkout[1], to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
@@ -1978,8 +1978,8 @@ error: failed to push to 'ssh://yourserver.com/~you/proj.git'
This can happen, for example, if you:
- - use `git-reset --hard` to remove already-published commits, or
- - use `git-commit --amend` to replace already-published commits
+ - use `git-reset \--hard` to remove already-published commits, or
+ - use `git-commit \--amend` to replace already-published commits
(as in <<fixing-a-mistake-by-rewriting-history>>), or
- use `git-rebase` to rebase any already-published commits (as
in <<using-git-rebase>>).
@@ -2088,7 +2088,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
-the --track option to linkgit:git-branch[1]) to merge changes in from
+the \--track option to linkgit:git-branch[1]) to merge changes in from
Linus by default.
-------------------------------------------------
@@ -2468,7 +2468,7 @@ $ git rebase --continue
and git will continue applying the rest of the patches.
-At any point you may use the `--abort` option to abort this process and
+At any point you may use the `\--abort` option to abort this process and
return mywork to the state it had before you started the rebase:
-------------------------------------------------
@@ -2539,7 +2539,7 @@ $ gitk origin..mywork &
and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using `commit --amend`.
+cherry-pick, and possibly modifying them as you go using `commit \--amend`.
The linkgit:git-gui[1] command may also help as it allows you to
individually select diff hunks for inclusion in the index (by
right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
@@ -2897,7 +2897,7 @@ Commit Object
~~~~~~~~~~~~~
The "commit" object links a physical state of a tree with a description
-of how we got there and why. Use the --pretty=raw option to
+of how we got there and why. Use the \--pretty=raw option to
linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
commit:
@@ -3700,16 +3700,16 @@ i.e. it will normally just update existing cache entries.
To tell git that yes, you really do realize that certain files no
longer exist, or that new files should be added, you
-should use the `--remove` and `--add` flags respectively.
+should use the `\--remove` and `\--add` flags respectively.
-NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
+NOTE! A `\--remove` flag does 'not' mean that subsequent filenames will
necessarily be removed: if the files still exist in your directory
structure, the index will be updated with their new status, not
-removed. The only thing `--remove` means is that update-index will be
+removed. The only thing `\--remove` means is that update-index will be
considering a removed file to be a valid thing, and if the file really
does not exist any more, it will update the index accordingly.
-As a special case, you can also do `git update-index --refresh`, which
+As a special case, you can also do `git update-index \--refresh`, which
will refresh the "stat" information of each index to match the current
stat information. It will 'not' update the object status itself, and
it will only update the fields that are used to quickly test whether
@@ -3956,7 +3956,7 @@ entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
other tools before you can write out the result.
-You can examine such index state with `git ls-files --unmerged`
+You can examine such index state with `git ls-files \--unmerged`
command. An example:
------------------------------------------------
@@ -3967,7 +3967,7 @@ $ git ls-files --unmerged
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
------------------------------------------------
-Each line of the `git ls-files --unmerged` output begins with
+Each line of the `git ls-files \--unmerged` output begins with
the blob mode bits, blob SHA1, 'stage number', and the
filename. The 'stage number' is git's way to say which tree it
came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
^ permalink raw reply related
* Re: Git and Media repositories....
From: Nguyen Thai Ngoc Duy @ 2008-11-09 4:58 UTC (permalink / raw)
To: Santi Béjar; +Cc: Tim Ansell, git
In-Reply-To: <adf1fd3d0811070519qc54369vf0da3bc28182460a@mail.gmail.com>
On 11/7/08, Santi Béjar <santi@agolina.net> wrote:
> On Sun, Nov 2, 2008 at 8:50 PM, Tim Ansell <mithro@mithis.com> wrote:
> > Hey guys,
> >
>
> [...]
>
>
> >
> > The general idea is that we always clone the complete meta-data (tags,
> > commits and trees) and then only clone blobs when they are needed (using
> > something like alternates). This allows us to support shallow, narrow
> > and sparse checkouts while still being able to perform operations such
> > as committing and merging.
> >
>
>
> A related use case could be to remove a blob from a repo but being
> able to work normally with it, similar to:
>
> http://wiki.freebsd.org/VCSFeatureObliterate
Maybe another use case: encrypted blobs (those are generally
unavailable until corrected password is given, so they are "holes" in
checkout/clone). It could be used to store sensitive content (in $HOME
for example)
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] diffcore-rename: support rename cache
From: Jeff King @ 2008-11-09 2:04 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Yann Dirson, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0811080400h7ea5377cvaa8d658335811c23@mail.gmail.com>
On Sat, Nov 08, 2008 at 07:00:10PM +0700, Nguyen Thai Ngoc Duy wrote:
> > The downsides are:
> >
> > - your cache is potentially bigger, since you are caching the score of
> > every pair you look at, instead of just "good" pairs (OTOH, you are
> > not doing a per-commit cache, which helps reduce the size)
>
> It is huge if you accidentially add --find-copies-harder to your
> command, considering that every new file will be compared against
> every files in tree (about 25k).
Hmm, yeah. I was thinking you might be able to do some kind of cut-off
on the caching (i.e., don't bother storing anything that didn't come
close). But you can't safely assume that because an entry isn't there,
it isn't worth seeing (since it might also just not have been computed
yet). You could still organize by commit, and then each commit is either
fully computed or not. But then you still have a pathspec problem.
One thing you could do is just compute the rename score between all
pairs, even if a pathspec is given, limit it to values over "0.5" (or
something low, but that eliminates the totally uninteresting cases), and
then store that as the complete cache for that commit (or tree pair, if
you want to support that).
Then you would have the full information and could do an arbitrary
pathspec limit on it. If you wanted to set the rename threshold below
0.5, then we would have to recompute without the cache (but in practice,
that should be rare).
The real downside is that you pay for the whole-tree detection when you
have asked for a pathspec (but only the first time, after which you can
always generate from cache).
Just thinking out loud...
-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