* [PATCH (GIT-GUI,GITK) 4/8] git-gui: Optimize encoding name resolution using a lookup table.
From: Alexander Gavrilov @ 2008-09-17 21:07 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Paul Mackerras
In-Reply-To: <1221685659-476-4-git-send-email-angavrilov@gmail.com>
Encoding menu construction does almost a hundred of encoding
resolutions, which with the old implementation led to a
small but noticeable delay.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
lib/encoding.tcl | 82 +++++++++++++++++++++++++++++++++++-------------------
1 files changed, 53 insertions(+), 29 deletions(-)
diff --git a/lib/encoding.tcl b/lib/encoding.tcl
index b2ee38c..32668fc 100644
--- a/lib/encoding.tcl
+++ b/lib/encoding.tcl
@@ -286,39 +286,63 @@ set encoding_groups {
{"Symbol" Symbol Dingbats MacDingbats MacCentEuro}}
}
+proc build_encoding_table {} {
+ global encoding_aliases encoding_lookup_table
+
+ # Prepare the lookup list; cannot use lsort -nocase because
+ # of compatibility issues with older Tcl (e.g. in msysgit)
+ set names [list]
+ foreach item [encoding names] {
+ lappend names [list [string tolower $item] $item]
+ }
+ set names [lsort -ascii -index 0 $names]
+ # neither can we use lsearch -index
+ set lnames [list]
+ foreach item $names {
+ lappend lnames [lindex $item 0]
+ }
+
+ foreach grp $encoding_aliases {
+ set target {}
+ foreach item $grp {
+ set i [lsearch -sorted -ascii $lnames \
+ [string tolower $item]]
+ if {$i >= 0} {
+ set target [lindex $names $i 1]
+ break
+ }
+ }
+ if {$target eq {}} continue
+ foreach item $grp {
+ set encoding_lookup_table([string tolower $item]) $target
+ }
+ }
+
+ foreach item $names {
+ set encoding_lookup_table([lindex $item 0]) [lindex $item 1]
+ }
+}
+
proc tcl_encoding {enc} {
- global encoding_aliases
- set names [encoding names]
- set lcnames [string tolower $names]
- set enc [string tolower $enc]
- set i [lsearch -exact $lcnames $enc]
- if {$i < 0} {
- # look for "isonnn" instead of "iso-nnn" or "iso_nnn"
- if {[regsub {^(iso|cp|ibm|jis)[-_]} $enc {\1} encx]} {
- set i [lsearch -exact $lcnames $encx]
+ global encoding_lookup_table
+ if {$enc eq {}} {
+ return {}
+ }
+ if {![info exists encoding_lookup_table]} {
+ build_encoding_table
}
- }
- if {$i < 0} {
- foreach l $encoding_aliases {
- set ll [string tolower $l]
- if {[lsearch -exact $ll $enc] < 0} continue
- # look through the aliases for one that tcl knows about
- foreach e $ll {
- set i [lsearch -exact $lcnames $e]
- if {$i < 0} {
- if {[regsub {^(iso|cp|ibm|jis)[-_]} $e {\1} ex]} {
- set i [lsearch -exact $lcnames $ex]
- }
+ set enc [string tolower $enc]
+ if {![info exists encoding_lookup_table($enc)]} {
+ # look for "isonnn" instead of "iso-nnn" or "iso_nnn"
+ if {[regsub {^(iso|cp|ibm|jis)[-_]} $enc {\1} encx]} {
+ set enc $encx
}
- if {$i >= 0} break
- }
- break
}
- }
- if {$i >= 0} {
- return [lindex $names $i]
- }
- return {}
+ if {[info exists encoding_lookup_table($enc)]} {
+ return $encoding_lookup_table($enc)
+ } else {
+ return {}
+ }
}
proc force_path_encoding {path enc} {
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GIT-GUI,GITK) 5/8] git-gui: Support the encoding menu in gui blame.
From: Alexander Gavrilov @ 2008-09-17 21:07 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Paul Mackerras
In-Reply-To: <1221685659-476-5-git-send-email-angavrilov@gmail.com>
Allow dynamically changing the encoding from the blame
viewer as well.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
lib/blame.tcl | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/lib/blame.tcl b/lib/blame.tcl
index 84d55b5..eb61374 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -256,9 +256,16 @@ constructor new {i_commit i_path i_jump} {
$w.ctxm add command \
-label [mc "Copy Commit"] \
-command [cb _copycommit]
+ $w.ctxm add separator
+ menu $w.ctxm.enc
+ build_encoding_menu $w.ctxm.enc [cb _setencoding]
+ $w.ctxm add cascade \
+ -label [mc "Encoding"] \
+ -menu $w.ctxm.enc
$w.ctxm add command \
-label [mc "Do Full Copy Detection"] \
-command [cb _fullcopyblame]
+ $w.ctxm add separator
$w.ctxm add command \
-label [mc "Show History Context"] \
-command [cb _gitkcommit]
@@ -791,6 +798,16 @@ method _click {cur_w pos} {
_showcommit $this $cur_w $lno
}
+method _setencoding {enc} {
+ force_path_encoding $path $enc
+ _load $this [list \
+ $highlight_column \
+ $highlight_line \
+ [lindex [$w_file xview] 0] \
+ [lindex [$w_file yview] 0] \
+ ]
+}
+
method _load_commit {cur_w cur_d pos} {
upvar #0 $cur_d line_data
set lno [lindex [split [$cur_w index $pos] .] 0]
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GIT-GUI,GITK) 3/8] git-gui: Allow forcing display encoding for diffs using a submenu.
From: Alexander Gavrilov @ 2008-09-17 21:07 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Paul Mackerras
In-Reply-To: <1221685659-476-3-git-send-email-angavrilov@gmail.com>
Add a submenu to allow dynamically changing the encoding to use
for diffs. Encoding settings are remembered while git-gui runs.
The rules are:
1) Encoding set for a specific file overrides gitattributes.
2) Last explicitly set value of the encoding overrides gui.encoding
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
git-gui.sh | 8 ++++++++
lib/diff.tcl | 9 +++++++++
lib/encoding.tcl | 29 +++++++++++++++++++++++++++--
3 files changed, 44 insertions(+), 2 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 444990b..3bbb4f1 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -2937,6 +2937,14 @@ proc create_common_diff_popup {ctxm} {
-command {incr_font_size font_diff 1}
lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
$ctxm add separator
+ set emenu $ctxm.enc
+ menu $emenu
+ build_encoding_menu $emenu [list force_diff_encoding]
+ $ctxm add cascade \
+ -label [mc "Encoding"] \
+ -menu $emenu
+ lappend diff_actions [list $ctxm entryconf [$ctxm index last] -state]
+ $ctxm add separator
$ctxm add command -label [mc "Options..."] \
-command do_options
}
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 8fefc5d..b616296 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -40,6 +40,15 @@ proc reshow_diff {} {
}
}
+proc force_diff_encoding {enc} {
+ global current_diff_path
+
+ if {$current_diff_path ne {}} {
+ force_path_encoding $current_diff_path $enc
+ reshow_diff
+ }
+}
+
proc handle_empty_diff {} {
global current_diff_path file_states file_lists
diff --git a/lib/encoding.tcl b/lib/encoding.tcl
index 2c1eda3..b2ee38c 100644
--- a/lib/encoding.tcl
+++ b/lib/encoding.tcl
@@ -321,13 +321,38 @@ proc tcl_encoding {enc} {
return {}
}
+proc force_path_encoding {path enc} {
+ global path_encoding_overrides last_encoding_override
+
+ set enc [tcl_encoding $enc]
+ if {$enc eq {}} {
+ catch { unset last_encoding_override }
+ catch { unset path_encoding_overrides($path) }
+ } else {
+ set last_encoding_override $enc
+ if {$path ne {}} {
+ set path_encoding_overrides($path) $enc
+ }
+ }
+}
+
proc get_path_encoding {path} {
- set tcl_enc [tcl_encoding [get_config gui.encoding]]
+ global path_encoding_overrides last_encoding_override
+
+ if {[info exists last_encoding_override]} {
+ set tcl_enc $last_encoding_override
+ } else {
+ set tcl_enc [tcl_encoding [get_config gui.encoding]]
+ }
if {$tcl_enc eq {}} {
set tcl_enc [encoding system]
}
if {$path ne {}} {
- set enc2 [tcl_encoding [gitattr $path encoding $tcl_enc]]
+ if {[info exists path_encoding_overrides($path)]} {
+ set enc2 $path_encoding_overrides($path)
+ } else {
+ set enc2 [tcl_encoding [gitattr $path encoding $tcl_enc]]
+ }
if {$enc2 ne {}} {
set tcl_enc $enc2
}
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GIT-GUI,GITK) 2/8] git-gui: Add a menu of available encodings.
From: Alexander Gavrilov @ 2008-09-17 21:07 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Paul Mackerras
In-Reply-To: <1221685659-476-2-git-send-email-angavrilov@gmail.com>
To make encoding selection easier, add a menu that
lists available encodings to the Options window.
Menu structure is borrowed from Firefox.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
lib/encoding.tcl | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
lib/option.tcl | 13 +++++-
2 files changed, 142 insertions(+), 4 deletions(-)
diff --git a/lib/encoding.tcl b/lib/encoding.tcl
index e186b0c..2c1eda3 100644
--- a/lib/encoding.tcl
+++ b/lib/encoding.tcl
@@ -206,7 +206,7 @@ set encoding_aliases {
{ ISO-8859-16 iso-ir-226 ISO_8859-16:2001 ISO_8859-16 latin10 l10 }
{ GBK CP936 MS936 windows-936 }
{ JIS_Encoding csJISEncoding }
- { Shift_JIS MS_Kanji csShiftJIS }
+ { Shift_JIS MS_Kanji csShiftJIS ShiftJIS Shift-JIS }
{ Extended_UNIX_Code_Packed_Format_for_Japanese csEUCPkdFmtJapanese
EUC-JP }
{ Extended_UNIX_Code_Fixed_Width_for_Japanese csEUCFixWidJapanese }
@@ -240,6 +240,52 @@ set encoding_aliases {
{ Big5 csBig5 }
}
+set encoding_groups {
+ {"" ""
+ {"Unicode" UTF-8}
+ {"Western" ISO-8859-1}}
+ {we "West European"
+ {"Western" ISO-8859-15 CP-437 CP-850 MacRoman CP-1252 Windows-1252}
+ {"Celtic" ISO-8859-14}
+ {"Greek" ISO-8859-14 ISO-8859-7 CP-737 CP-869 MacGreek CP-1253 Windows-1253}
+ {"Icelandic" MacIceland MacIcelandic CP-861}
+ {"Nordic" ISO-8859-10 CP-865}
+ {"Portuguese" CP-860}
+ {"South European" ISO-8859-3}}
+ {ee "East European"
+ {"Baltic" CP-775 ISO-8859-4 ISO-8859-13 CP-1257 Windows-1257}
+ {"Central European" CP-852 ISO-8859-2 MacCE CP-1250 Windows-1250}
+ {"Croatian" MacCroatian}
+ {"Cyrillic" CP-855 ISO-8859-5 ISO-IR-111 KOI8-R MacCyrillic CP-1251 Windows-1251}
+ {"Russian" CP-866}
+ {"Ukrainian" KOI8-U MacUkraine MacUkrainian}
+ {"Romanian" ISO-8859-16 MacRomania MacRomanian}}
+ {ea "East Asian"
+ {"Generic" ISO-2022}
+ {"Chinese Simplified" GB2312 GB1988 GB12345 GB2312-RAW GBK EUC-CN GB18030 HZ ISO-2022-CN}
+ {"Chinese Traditional" Big5 Big5-HKSCS EUC-TW CP-950}
+ {"Japanese" EUC-JP ISO-2022-JP Shift-JIS JIS-0212 JIS-0208 JIS-0201 CP-932 MacJapan}
+ {"Korean" EUC-KR UHC JOHAB ISO-2022-KR CP-949 KSC5601}}
+ {sa "SE & SW Asian"
+ {"Armenian" ARMSCII-8}
+ {"Georgian" GEOSTD8}
+ {"Thai" TIS-620 ISO-8859-11 CP-874 Windows-874 MacThai}
+ {"Turkish" CP-857 CP857 ISO-8859-9 MacTurkish CP-1254 Windows-1254}
+ {"Vietnamese" TCVN VISCII VPS CP-1258 Windows-1258}
+ {"Hindi" MacDevanagari}
+ {"Gujarati" MacGujarati}
+ {"Gurmukhi" MacGurmukhi}}
+ {me "Middle Eastern"
+ {"Arabic" ISO-8859-6 Windows-1256 CP-1256 CP-864 MacArabic}
+ {"Farsi" MacFarsi}
+ {"Hebrew" ISO-8859-8-I Windows-1255 CP-1255 ISO-8859-8 CP-862 MacHebrew}}
+ {mi "Misc"
+ {"7-bit" ASCII}
+ {"16-bit" Unicode}
+ {"Legacy" CP-863 EBCDIC}
+ {"Symbol" Symbol Dingbats MacDingbats MacCentEuro}}
+}
+
proc tcl_encoding {enc} {
global encoding_aliases
set names [encoding names]
@@ -248,7 +294,7 @@ proc tcl_encoding {enc} {
set i [lsearch -exact $lcnames $enc]
if {$i < 0} {
# look for "isonnn" instead of "iso-nnn" or "iso_nnn"
- if {[regsub {^iso[-_]} $enc iso encx]} {
+ if {[regsub {^(iso|cp|ibm|jis)[-_]} $enc {\1} encx]} {
set i [lsearch -exact $lcnames $encx]
}
}
@@ -260,7 +306,7 @@ proc tcl_encoding {enc} {
foreach e $ll {
set i [lsearch -exact $lcnames $e]
if {$i < 0} {
- if {[regsub {^iso[-_]} $e iso ex]} {
+ if {[regsub {^(iso|cp|ibm|jis)[-_]} $e {\1} ex]} {
set i [lsearch -exact $lcnames $ex]
}
}
@@ -288,3 +334,84 @@ proc get_path_encoding {path} {
}
return $tcl_enc
}
+
+proc build_encoding_submenu {parent grp cmd} {
+ global used_encodings
+
+ set mid [lindex $grp 0]
+ set gname [mc [lindex $grp 1]]
+
+ set smenu {}
+ foreach subset [lrange $grp 2 end] {
+ set name [mc [lindex $subset 0]]
+
+ foreach enc [lrange $subset 1 end] {
+ set tcl_enc [tcl_encoding $enc]
+ if {$tcl_enc eq {}} continue
+
+ if {$smenu eq {}} {
+ if {$mid eq {}} {
+ set smenu $parent
+ } else {
+ set smenu "$parent.$mid"
+ menu $smenu
+ $parent add cascade \
+ -label $gname \
+ -menu $smenu
+ }
+ }
+
+ if {$name ne {}} {
+ set lbl "$name ($enc)"
+ } else {
+ set lbl $enc
+ }
+ $smenu add command \
+ -label $lbl \
+ -command [concat $cmd [list $tcl_enc]]
+
+ lappend used_encodings $tcl_enc
+ }
+ }
+}
+
+proc popup_btn_menu {m b} {
+ tk_popup $m [winfo pointerx $b] [winfo pointery $b]
+}
+
+proc build_encoding_menu {emenu cmd {nodef 0}} {
+ $emenu configure -postcommand \
+ [list do_build_encoding_menu $emenu $cmd $nodef]
+}
+
+proc do_build_encoding_menu {emenu cmd {nodef 0}} {
+ global used_encodings encoding_groups
+
+ $emenu configure -postcommand {}
+
+ if {!$nodef} {
+ $emenu add command \
+ -label [mc "Default"] \
+ -command [concat $cmd [list {}]]
+ }
+ set sysenc [encoding system]
+ $emenu add command \
+ -label [mc "System (%s)" $sysenc] \
+ -command [concat $cmd [list $sysenc]]
+
+ # Main encoding tree
+ set used_encodings [list identity]
+ $emenu add separator
+ foreach grp $encoding_groups {
+ build_encoding_submenu $emenu $grp $cmd
+ }
+
+ # Add unclassified encodings
+ set unused_grp [list [mc Other]]
+ foreach enc [encoding names] {
+ if {[lsearch -exact $used_encodings $enc] < 0} {
+ lappend unused_grp $enc
+ }
+ }
+ build_encoding_submenu $emenu [list other [mc Other] $unused_grp] $cmd
+}
diff --git a/lib/option.tcl b/lib/option.tcl
index 40af44e..c80c939 100644
--- a/lib/option.tcl
+++ b/lib/option.tcl
@@ -152,7 +152,7 @@ proc do_options {} {
{i-1..99 gui.diffcontext {mc "Number of Diff Context Lines"}}
{i-0..99 gui.commitmsgwidth {mc "Commit Message Text Width"}}
{t gui.newbranchtemplate {mc "New Branch Name Template"}}
- {t gui.encoding {mc "Default File Contents Encoding"}}
+ {c gui.encoding {mc "Default File Contents Encoding"}}
} {
set type [lindex $option 0]
set name [lindex $option 1]
@@ -182,6 +182,7 @@ proc do_options {} {
pack $w.$f.$optid.v -side right -anchor e -padx 5
pack $w.$f.$optid -side top -anchor w -fill x
}
+ c -
t {
frame $w.$f.$optid
label $w.$f.$optid.l -text "$text:"
@@ -194,6 +195,16 @@ proc do_options {} {
pack $w.$f.$optid.v -side left -anchor w \
-fill x -expand 1 \
-padx 5
+ if {$type eq {c}} {
+ menu $w.$f.$optid.m
+ build_encoding_menu $w.$f.$optid.m \
+ [list set ${f}_config_new($name)] 1
+ button $w.$f.$optid.b \
+ -text [mc "Change"] \
+ -command [list popup_btn_menu \
+ $w.$f.$optid.m $w.$f.$optid.b]
+ pack $w.$f.$optid.b -side left -anchor w
+ }
pack $w.$f.$optid -side top -anchor w -fill x
}
}
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GIT-GUI,GITK) 1/8] git-gui: Cleanup handling of the default encoding.
From: Alexander Gavrilov @ 2008-09-17 21:07 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Paul Mackerras
In-Reply-To: <1221685659-476-1-git-send-email-angavrilov@gmail.com>
- Make diffs and blame default to the system (locale)
encoding instead of hard-coding UTF-8.
- Add a gui.encoding option to allow overriding it.
- gitattributes still have the final word.
The rationale for this is Windows support:
1) Windows people are accustomed to using legacy encodings
for text files. For many of them defaulting to utf-8
will be counter-intuitive.
2) Windows doesn't support utf-8 locales, and switching
the system encoding is a real pain. Thus the option.
This patch also adds proper encoding conversion to Apply Hunk/Line.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
git-gui.sh | 1 +
lib/blame.tcl | 2 +-
lib/diff.tcl | 11 ++++++-----
lib/encoding.tcl | 14 ++++++++++++++
lib/option.tcl | 24 ++++++++++++++++++++++++
5 files changed, 46 insertions(+), 6 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 91457a2..444990b 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -678,6 +678,7 @@ set default_config(merge.verbosity) 2
set default_config(user.name) {}
set default_config(user.email) {}
+set default_config(gui.encoding) [encoding system]
set default_config(gui.matchtrackingbranch) false
set default_config(gui.pruneduringfetch) false
set default_config(gui.trustmtime) false
diff --git a/lib/blame.tcl b/lib/blame.tcl
index 7535adb..84d55b5 100644
--- a/lib/blame.tcl
+++ b/lib/blame.tcl
@@ -402,7 +402,7 @@ method _load {jump} {
fconfigure $fd \
-blocking 0 \
-translation lf \
- -encoding [tcl_encoding [gitattr $path encoding UTF-8]]
+ -encoding [get_path_encoding $path]
fileevent $fd readable [cb _read_file $fd $jump]
set current_fd $fd
}
diff --git a/lib/diff.tcl b/lib/diff.tcl
index b0ecfbc..8fefc5d 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -164,11 +164,10 @@ proc show_other_diff {path w m scroll_pos} {
set sz [string length $content]
}
file {
- set enc [gitattr $path encoding UTF-8]
set fd [open $path r]
fconfigure $fd \
-eofchar {} \
- -encoding [tcl_encoding $enc]
+ -encoding [get_path_encoding $path]
set content [read $fd $max_sz]
close $fd
set sz [file size $path]
@@ -282,7 +281,7 @@ proc start_show_diff {scroll_pos {add_opts {}}} {
set ::current_diff_inheader 1
fconfigure $fd \
-blocking 0 \
- -encoding [tcl_encoding [gitattr $path encoding UTF-8]] \
+ -encoding [get_path_encoding $path] \
-translation lf
fileevent $fd readable [list read_diff $fd $scroll_pos]
}
@@ -435,8 +434,9 @@ proc apply_hunk {x y} {
}
if {[catch {
+ set enc [get_path_encoding $current_diff_path]
set p [eval git_write $apply_cmd]
- fconfigure $p -translation binary -encoding binary
+ fconfigure $p -translation binary -encoding $enc
puts -nonewline $p $current_diff_header
puts -nonewline $p [$ui_diff get $s_lno $e_lno]
close $p} err]} {
@@ -604,8 +604,9 @@ proc apply_line {x y} {
set patch "@@ -$hln,$n +$hln,[eval expr $n $sign 1] @@\n$patch"
if {[catch {
+ set enc [get_path_encoding $current_diff_path]
set p [eval git_write $apply_cmd]
- fconfigure $p -translation binary -encoding binary
+ fconfigure $p -translation binary -encoding $enc
puts -nonewline $p $current_diff_header
puts -nonewline $p $patch
close $p} err]} {
diff --git a/lib/encoding.tcl b/lib/encoding.tcl
index 7f06b0d..e186b0c 100644
--- a/lib/encoding.tcl
+++ b/lib/encoding.tcl
@@ -274,3 +274,17 @@ proc tcl_encoding {enc} {
}
return {}
}
+
+proc get_path_encoding {path} {
+ set tcl_enc [tcl_encoding [get_config gui.encoding]]
+ if {$tcl_enc eq {}} {
+ set tcl_enc [encoding system]
+ }
+ if {$path ne {}} {
+ set enc2 [tcl_encoding [gitattr $path encoding $tcl_enc]]
+ if {$enc2 ne {}} {
+ set tcl_enc $enc2
+ }
+ }
+ return $tcl_enc
+}
diff --git a/lib/option.tcl b/lib/option.tcl
index 9b865f6..40af44e 100644
--- a/lib/option.tcl
+++ b/lib/option.tcl
@@ -1,6 +1,28 @@
# git-gui options editor
# Copyright (C) 2006, 2007 Shawn Pearce
+proc config_check_encodings {} {
+ global repo_config_new global_config_new
+
+ set enc $global_config_new(gui.encoding)
+ if {$enc eq {}} {
+ set global_config_new(gui.encoding) [encoding system]
+ } elseif {[tcl_encoding $enc] eq {}} {
+ error_popup [mc "Invalid global encoding '%s'" $enc]
+ return 0
+ }
+
+ set enc $repo_config_new(gui.encoding)
+ if {$enc eq {}} {
+ set repo_config_new(gui.encoding) [encoding system]
+ } elseif {[tcl_encoding $enc] eq {}} {
+ error_popup [mc "Invalid repo encoding '%s'" $enc]
+ return 0
+ }
+
+ return 1
+}
+
proc save_config {} {
global default_config font_descs
global repo_config global_config
@@ -130,6 +152,7 @@ proc do_options {} {
{i-1..99 gui.diffcontext {mc "Number of Diff Context Lines"}}
{i-0..99 gui.commitmsgwidth {mc "Commit Message Text Width"}}
{t gui.newbranchtemplate {mc "New Branch Name Template"}}
+ {t gui.encoding {mc "Default File Contents Encoding"}}
} {
set type [lindex $option 0]
set name [lindex $option 1]
@@ -275,6 +298,7 @@ proc do_restore_defaults {} {
}
proc do_save_config {w} {
+ if {![config_check_encodings]} return
if {[catch {save_config} err]} {
error_popup [strcat [mc "Failed to completely save options:"] "\n\n$err"]
}
--
1.6.0.20.g6148bc
^ permalink raw reply related
* [PATCH (GIT-GUI,GITK) 0/8] Encoding support in GUI
From: Alexander Gavrilov @ 2008-09-17 21:07 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Paul Mackerras
Currently GUI tools don't provide any support for
viewing files that contain non-ASCII characters. This set of
patches addresses that issue. The git-gui part of the series
is based on patches that are currently in the 'pu' branch
of the git-gui repository.
File encoding can be specified in the following ways:
1) It defaults to the current locale encoding.
2) It can be overridden by setting the gui.encoding option.
3) It can be further set on per-file basis by specifying
the 'encoding' attribute in gitattributes.
4) Finally, git-gui allows directly selecting encodings
through a popup menu.
The last item is a necessity to compensate for the fact that
now staging/unstaging hunks would not work, if the selected
encoding is incompatible with the actual data:
While most single-byte character sets are mutually compatible,
all multibyte encodings, including utf-8, have the concept
of invalid byte sequences, and thus are not completely
reversible. Because of this, git-gui won't be able to apply
hunks that contain such sequences, and the user would have to
specify the encoding correctly, or fallback to ISO-8859-1.
Since git apparently cannot work with filenames in non-locale
encodings anyway, I did not try to do anything about it apart
from fixing some obvious bugs.
There are also some bugs in handling of commit encodings in gitk,
but they are out of the scope of this series.
GIT-GUI:
git-gui: Cleanup handling of the default encoding.
---
git-gui.sh | 1 +
lib/blame.tcl | 2 +-
lib/diff.tcl | 11 ++++++-----
lib/encoding.tcl | 14 ++++++++++++++
lib/option.tcl | 24 ++++++++++++++++++++++++
5 files changed, 46 insertions(+), 6 deletions(-)
git-gui: Add a menu of available encodings.
---
lib/encoding.tcl | 133 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
lib/option.tcl | 13 +++++-
2 files changed, 142 insertions(+), 4 deletions(-)
git-gui: Allow forcing display encoding for diffs using a submenu.
---
git-gui.sh | 8 ++++++++
lib/diff.tcl | 9 +++++++++
lib/encoding.tcl | 29 +++++++++++++++++++++++++++--
3 files changed, 44 insertions(+), 2 deletions(-)
git-gui: Optimize encoding name resolution using a lookup table.
---
lib/encoding.tcl | 82 +++++++++++++++++++++++++++++++++++-------------------
1 files changed, 53 insertions(+), 29 deletions(-)
git-gui: Support the encoding menu in gui blame.
---
lib/blame.tcl | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
GITK:
gitk: Port new encoding logic from git-gui.
---
gitk | 50 +++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 47 insertions(+), 3 deletions(-)
gitk: Implement file contents encoding support.
---
gitk | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
gitk: Support filenames in the locale encoding.
---
gitk | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Junio C Hamano @ 2008-09-17 20:44 UTC (permalink / raw)
To: Jonathan del Strother
Cc: Miklos Vajna, Andreas Ericsson, git, Johannes.Schindelin
In-Reply-To: <57518fd10809171214u3b5b3b96yc432c1c410faf8b4@mail.gmail.com>
"Jonathan del Strother" <maillist@steelskies.com> writes:
> Johannes already convinced me to do it as a separate patch. Andreas
> seems to think that even if that change were in a separate patch, it
> is pure nonsense. I think it's pretty subjective - I was just making
> things consistent.
I think the discussion is getting into personal preference, but I do agree
making things consistent is good.
Short and simple ones can stay the same as before, but I'd actually prefer
doing ones on multiple lines like this:
{ "java",
/* Do not match these keywords */
"!^[ \t]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
"new\\|return\\|switch\\|throw\\|while\\)\n"
/* possibly indented "foo bar(..." */
"^[ \t]*\\(\\([ \t]*[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}[ \t]*([^;]*\\)$"
},
{ "objc",
/* Do not match with these C statements */
"!^[ \t]*\\(do\\|for\\|if\\|else\\|return\\|switch\\|while\\)\n"
/* Objective-C methods "-(fo*&^)%*&%$^" or "+(bar&^)%$#$%" */
"^[ \t]*\\([-+][ \t]*([ \t]*[A-Za-z_][A-Za-z_0-9]*.*).*\\)$"
"\\|" /* C functions "foo bar(..." */
"^[ \t]*\\(\\([ \t]*[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}[ \t]*([^;]*\\)$"
"\\|" /* Objective-C class/protocol definitions */
"^@\\(implementation\\|interface\\|protocol\\).*"
},
That is:
- The pattern string indented to align with the pattern name;
- Indent second and later lines of a single alternatives list that is
split over multiple physical lines;
Are you sure the regexp you have for Objective-C methods quotes a dot "."
correctly, by the way? It appears to match almost anything enclosed in a
pair of parentheses, as long as you have two alpha after open paren.
Also I am not sure if you can do the pattern alternates the way you did.
If you have this:
"...\\(A\\|B\\)$"
"\\|"
"...\\(C\\|D\\)$"
A and B will be captured as $1 but wouldn't C or D captured as $2?
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-09-17 19:14 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Andreas Ericsson, git, Johannes.Schindelin
In-Reply-To: <20080917155505.GH4829@genesis.frugalware.org>
On Wed, Sep 17, 2008 at 4:55 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Wed, Sep 17, 2008 at 04:31:17PM +0100, Jonathan del Strother <maillist@steelskies.com> wrote:
>> I was changing it to match the style in the existing java pattern (and
>> my objc pattern). You think the java one should be changed to match
>> the pascal one, then?
>
> The point is that it's unrelated, so you should not change that part in
> the same patch. Send a separate patch if you want to do something
> unrelated to Objective-C.
Johannes already convinced me to do it as a separate patch. Andreas
seems to think that even if that change were in a separate patch, it
is pure nonsense. I think it's pretty subjective - I was just making
things consistent.
^ permalink raw reply
* Re: keep a subversion mirror in sync
From: Gaspard Bucher @ 2008-09-17 19:04 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130809171052q4e32e353ld3fdd109d0d34b00@mail.gmail.com>
I am the only one writing to the subversion repository. It's just a
public "read-only" mirror.
After I dcommit, I get a merge commit that's added to the master
branch. The "origin/master" does not have this merge commit. When I
pull from origin/master, I get a conflict
for all modified files. Reading the docs, it says "Running git-merge
or git-pull is NOT recommended on a branch you plan to dcommit from".
I think I will use svk to handle this sync problem.
SETUP:
1. svk mirror svn://... //mirror/foo
2. svk sync //mirror/foo
3. svk co //mirror/foo
4. cd foo
5. svk ps svn:ignore ".git" .
6. cd ..
4. rm -rf foo
5. git clone git@... foo
6. cd foo
SYNC:
1. get the last commit message from git and use it to sync back
"git log -1 --pretty=short --no-color > /tmp/git_svk_msg && svk ci --
import -F /tmp/git_svk_msg && rm /tmp/git_svk_msg"
I have tried this setup and it works fine. The fact that svk and git
totally ignore each other is really nice in this situation.
I thought there would be an easier path, but finally the solution here
seems good, as long as the "master" branch does not contain uncommited
content.
Gaspard
> On Wed, Sep 17, 2008 at 7:58 AM, Gaspard Bucher <gaspard@teti.ch>
> wrote:
>> I have been trying different strategies to keep subversion
>> repository in
>> sync with a git repository (on github).
>>
>> Some details with pictures can be found here:
>> http://zenadmin.org/en/documentation/page439.html.
>>
>> I have tried to use a single database to pull/push from github and
>> dcommit
>> to the old subversion repository but I get lots of conflicts and
>> duplicates
>> (see link above).
>>
>> I have then tried to create a "pull" only clone to dcommit, but it
>> looses
>> the commit messages and replaces then with a merge message. At
>> least this
>> solution keeps the github repository clean.
>>
>> What is the canonical way to do this ?
>
> The bad news is that a fully automatic two-way sync with svn is pretty
> much impossible, AFAIK. The act of committing to svn adds a
> git-svn-id line to your commit, so your old commit object needs to be
> thrown away and replaced with a new commit object. This makes
> everybody else's git commits totally confused. It's possible that the
> svn.noMetaData option will avoid this problem, but I've never tried
> it, and it's dangerous: if you lose your svn rev-map database, you
> can't get it back.
>
> As for dcommits losing commit messages... yes. There is no way to
> represent the idea of parallel development in svn without creating
> branches. For example, if we fetch from svn at point A, and person #1
> commits to svn based on point A producing point B, and person #2
> commits to git based on point A producing point C, then in order to
> have git-svn send point C back into svn, it will have to merge points
> B and C.
>
> Git can do the merge with no problem, but now it has to commit the
> changes from the merged version into svn. It doesn't make sense to
> commit *each* of the commits from A to C, because it would have to do
> it *on top of* B. The best it can do it commit the entire set of
> changes as a merge commit.
>
> You have two options:
>
> 1) Manually git-rebase the changes from A..C onto B, then hurry up and
> dcommit them before someone else commits to svn before you (otherwise
> you'd have to rebase again). git svn dcommit will then be smart
> enough to commit each one separately.
>
> 2) Accept the merge commit. The good news is that in the git repo,
> history will still have all the interesting information; svn's history
> isn't wrong, it's just incomplete.
>
> You could also try to modify git-svn to implement a third solution:
>
> 3) Create a temporary branch in svn by copying commit A. Commit each
> of the changes from A..C in that branch one by one, then create a
> merge back on the real branch that merges your temporary branch in,
> using the commit message and files from your git merge commit.
>
> Option #3 sounds hairy and gross, so it would be a lot of work and
> there's no guarantee your patch would be accepted.
>
> Basically, svn's limited ability to express history is preventing you
> from committing your "full" git history back into svn.
>
> At work, I currently use option #2. As long as the full history is
> available *somewhere*, the world is an okay place.
>
> Have fun,
>
> Avery
^ permalink raw reply
* Re: keep a subversion mirror in sync
From: Avery Pennarun @ 2008-09-17 17:52 UTC (permalink / raw)
To: Gaspard Bucher; +Cc: git
In-Reply-To: <B529992F-3C09-4708-A3F4-645DB23DF158@teti.ch>
On Wed, Sep 17, 2008 at 7:58 AM, Gaspard Bucher <gaspard@teti.ch> wrote:
> I have been trying different strategies to keep subversion repository in
> sync with a git repository (on github).
>
> Some details with pictures can be found here:
> http://zenadmin.org/en/documentation/page439.html.
>
> I have tried to use a single database to pull/push from github and dcommit
> to the old subversion repository but I get lots of conflicts and duplicates
> (see link above).
>
> I have then tried to create a "pull" only clone to dcommit, but it looses
> the commit messages and replaces then with a merge message. At least this
> solution keeps the github repository clean.
>
> What is the canonical way to do this ?
The bad news is that a fully automatic two-way sync with svn is pretty
much impossible, AFAIK. The act of committing to svn adds a
git-svn-id line to your commit, so your old commit object needs to be
thrown away and replaced with a new commit object. This makes
everybody else's git commits totally confused. It's possible that the
svn.noMetaData option will avoid this problem, but I've never tried
it, and it's dangerous: if you lose your svn rev-map database, you
can't get it back.
As for dcommits losing commit messages... yes. There is no way to
represent the idea of parallel development in svn without creating
branches. For example, if we fetch from svn at point A, and person #1
commits to svn based on point A producing point B, and person #2
commits to git based on point A producing point C, then in order to
have git-svn send point C back into svn, it will have to merge points
B and C.
Git can do the merge with no problem, but now it has to commit the
changes from the merged version into svn. It doesn't make sense to
commit *each* of the commits from A to C, because it would have to do
it *on top of* B. The best it can do it commit the entire set of
changes as a merge commit.
You have two options:
1) Manually git-rebase the changes from A..C onto B, then hurry up and
dcommit them before someone else commits to svn before you (otherwise
you'd have to rebase again). git svn dcommit will then be smart
enough to commit each one separately.
2) Accept the merge commit. The good news is that in the git repo,
history will still have all the interesting information; svn's history
isn't wrong, it's just incomplete.
You could also try to modify git-svn to implement a third solution:
3) Create a temporary branch in svn by copying commit A. Commit each
of the changes from A..C in that branch one by one, then create a
merge back on the real branch that merges your temporary branch in,
using the commit message and files from your git merge commit.
Option #3 sounds hairy and gross, so it would be a lot of work and
there's no guarantee your patch would be accepted.
Basically, svn's limited ability to express history is preventing you
from committing your "full" git history back into svn.
At work, I currently use option #2. As long as the full history is
available *somewhere*, the world is an okay place.
Have fun,
Avery
^ permalink raw reply
* Re: git-svn checksum mismatch importing large file
From: Avery Pennarun @ 2008-09-17 17:39 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Pascal Obry, git list, Eric Wong
In-Reply-To: <20080917082506.GA8849@atjola.homenet>
On Wed, Sep 17, 2008 at 4:25 AM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2008.09.17 09:53:34 +0200, Pascal Obry wrote:
>> I get this error:
>>
>> Checksum mismatch: trunk/data
>> expected: 7c59e4dd67b5a9fde6c61cada070537b
>> got: 3fcd9d077a5aa51a784a452c9d78d6e0
>>
>> To reproduce launch run.sh in attached archive.
>>
>> I have had this problem since some time now and I finally got some time
>> to create a reproducer. I have reproduced this problem with yesterday
>> master Git version.
>
> Your /tmp is probably to small to hold the temporary file that git-svn
> creates. At least it doesn't fail for me unless I fill my /tmp first.
>
> This should be fixed since 29c70e0b3e3183f86f93500882177d0c74069988, at
> least it got me a useful error message when I tested it back then.
> Avery, any ideas?
It is possible that before my patch, you wouldn't have gotten that
error message - instead you would have gotten a corrupt repository,
which might have been caught later with an even more obscure-sounding
error. It does appear that there's a write() call somewhere in
git-svn that still isn't protected by an "or die", however, because
we're getting an invalid checksum without getting a write error first.
In any case, if the problem is a giant file that won't fit in /tmp,
the best we could do in git-svn is produce a better error message.
/tmp is still the "right" place to put temp files. I agree with the
suggestion to try pointing the TMPDIR environment variable somewhere
else... or else make your /tmp bigger.
Have fun,
Avery
^ permalink raw reply
* Re: Mismatch between "git status" and "git ls-files" [was Re: Teach git status to do "git diff --name-status HEAD"]
From: Jeff King @ 2008-09-17 17:31 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, Martin Langhoff, Git Mailing List
In-Reply-To: <48D11F40.4000307@drmicha.warpmail.net>
On Wed, Sep 17, 2008 at 05:16:16PM +0200, Michael J Gruber wrote:
> Following up on the discussion about "git status" versus
> "youknowwhichscm status" and suggestions to use "git diff --name-status"
> or "git ls-files -d -m -o -t" I made a little test case, see the
> attached script and output (git version 1.6.0.2.249.g97d7f).
> Observations:
You could also do something like the patch below. It produces output
like this:
$ git status --terse
# On branch next
# Your branch is ahead of 'origin/next' by 1 commit.
#
# Changes to be committed:
M wt-status.c
# Changed but not updated:
M builtin-commit.c
M wt-status.c
M wt-status.h
# Untracked files:
? untracked_file
nothing added to commit but untracked files present (use "git add" to track)
Though there are a few gotchas that make this unsuitable for applying:
- replacing the callbacks with DIFF_FORMAT_NAME_STATUS isn't quite
right. You lose the custom colorization, and it fails to set the "we
have stuff to commit" flag (note in my example that the "nothing
added to commit" isn't correct). Instead, we would need to do our
own NAME_STATUS output from the callback (possibly it could be
factored from diff.c into a general function).
- The format has lines that don't start with a '#', so it is not
suitable for a commit message template. So "git commit --terse"
should be disallowed.
- There might be other lines that can be stripped.
I personally don't see any real advantage of this format over the
existing status format, so I won't push this patch any further. But if
somebody wants to pick it up and get it into shape, feel free.
---
diff --git a/builtin-commit.c b/builtin-commit.c
index 917f638..e75b508 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -52,6 +52,7 @@ static char *edit_message, *use_message;
static char *author_name, *author_email, *author_date;
static int all, edit_flag, also, interactive, only, amend, signoff;
static int quiet, verbose, no_verify, allow_empty;
+static int terse_status;
static char *untracked_files_arg;
/*
* The default commit message cleanup mode will remove the lines
@@ -107,6 +108,8 @@ static struct option builtin_commit_options[] = {
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, "mode", "show untracked files, optional modes: all, normal, no. (Default: all)", PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
OPT_BOOLEAN(0, "allow-empty", &allow_empty, "ok to record an empty change"),
OPT_STRING(0, "cleanup", &cleanup_arg, "default", "how to strip spaces and #comments from message"),
+ OPT_BOOLEAN(0, "terse", &terse_status,
+ "use a more terse format to display status"),
OPT_END()
};
@@ -348,6 +351,7 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
s.amend = 1;
s.reference = "HEAD^1";
}
+ s.terse = terse_status;
s.verbose = verbose;
s.untracked = (show_untracked_files == SHOW_ALL_UNTRACKED_FILES);
s.index_file = index_file;
diff --git a/wt-status.c b/wt-status.c
index 7cf890f..fd3c2d5 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -87,8 +87,10 @@ static void wt_status_print_untracked_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER);
color_fprintf_ln(s->fp, c, "# Untracked files:");
- color_fprintf_ln(s->fp, c, "# (use \"git add <file>...\" to include in what will be committed)");
- color_fprintf_ln(s->fp, c, "#");
+ if (!s->terse) {
+ color_fprintf_ln(s->fp, c, "# (use \"git add <file>...\" to include in what will be committed)");
+ color_fprintf_ln(s->fp, c, "#");
+ }
}
static void wt_status_print_trailer(struct wt_status *s)
@@ -213,9 +215,16 @@ static void wt_status_print_updated(struct wt_status *s)
struct rev_info rev;
init_revisions(&rev, NULL);
setup_revisions(0, NULL, &rev, s->reference);
- rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
- rev.diffopt.format_callback = wt_status_print_updated_cb;
- rev.diffopt.format_callback_data = s;
+ if (s->terse) {
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER),
+ "# Changes to be committed:");
+ rev.diffopt.output_format = DIFF_FORMAT_NAME_STATUS;
+ }
+ else {
+ rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
+ rev.diffopt.format_callback = wt_status_print_updated_cb;
+ rev.diffopt.format_callback_data = s;
+ }
rev.diffopt.detect_rename = 1;
rev.diffopt.rename_limit = 200;
rev.diffopt.break_opt = 0;
@@ -227,9 +236,16 @@ static void wt_status_print_changed(struct wt_status *s)
struct rev_info rev;
init_revisions(&rev, "");
setup_revisions(0, NULL, &rev, NULL);
- rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
- rev.diffopt.format_callback = wt_status_print_changed_cb;
- rev.diffopt.format_callback_data = s;
+ if (s->terse) {
+ color_fprintf_ln(s->fp, color(WT_STATUS_HEADER),
+ "# Changed but not updated:");
+ rev.diffopt.output_format = DIFF_FORMAT_NAME_STATUS;
+ }
+ else {
+ rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;
+ rev.diffopt.format_callback = wt_status_print_changed_cb;
+ rev.diffopt.format_callback_data = s;
+ }
run_diff_files(&rev, 0);
}
@@ -300,7 +316,10 @@ static void wt_status_print_untracked(struct wt_status *s)
wt_status_print_untracked_header(s);
shown_header = 1;
}
- color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
+ if (s->terse)
+ color_fprintf(s->fp, color(WT_STATUS_UNTRACKED), "? ");
+ else
+ color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%s",
quote_path(ent->name, ent->len,
&buf, s->prefix));
diff --git a/wt-status.h b/wt-status.h
index 78add09..40fd132 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -23,6 +23,7 @@ struct wt_status {
char *branch;
const char *reference;
int verbose;
+ int terse;
int amend;
int untracked;
int nowarn;
^ permalink raw reply related
* Re: Project organisation and structure
From: Andreas Ericsson @ 2008-09-17 17:01 UTC (permalink / raw)
To: k wayne; +Cc: git
In-Reply-To: <bcf9fe2c0809170649x3f377c7erecc9f69a4a664d52@mail.gmail.com>
k wayne wrote:
> Hello,
> I'm new to git, and I hope this is the right mailinglist for what I'm
> going to ask; it was the only one I found on http://git.or.cz. Sorry
> if it's not or my question is remarkably stupid. I've read the git
> documentation, of course, but it wasn't always easy to wrap my head
> around all the concepts, so I might have missed an obvious solution to
> my problem.
>
This is the right place, and no you didn't miss anything obvious.
> I have a collection of libraries and programs, which aren't coupled
> too much, but aren't really independent either; for example, library X
> depends on Y, program Z on lib A and so forth. Since all of these libs
> and programs are logically connected to each other in some way, I
> would like to have them all in one central repository.
> So I heard that I could create kind of a "meta-repository" for the
> whole project, and have submodules for each library or program, which
> sounds exactly like what I want. However, I've been told that my
> current directory layout will not work this way with git.
>
> This is how my project root directory (say it's ~) looks like:
> ~/build - Build files which apply for the whole project, like doxygen
> build files.
> ~/include/$submodule - Each library/program has an own directory here,
> in which all header files go.
> ~/projects/$submodule - Files related to an individual project, like
> makefiles etc.
> ~/src/$submodule - Like the above two, but for source files.
> ~/test/$submodule - Again, a directory for each library/program,
> containing files for (unit)tests.
> ~/doc - Documentation files for the project as a whole.
> ~/doc/$submodule - Documentation files for individual libraries/programs.
>
> These are the directories I would like git to track for me. There are
> some other dirs not listed here (e.g. for object files,) but I can
> easily add them to .gitignore.
>
> So, the git structure as I imagine it would look like this: ~/.git
> contains the "meta-repository," in which all the submodules reside.
> Each submodule would have its .git directory in ~/projects/$submodule.
> Alternatively, ~/.git for the meta-repo and ~/.git-$subproject or
> something like this would be okay too.
>
> However, I have been told I cannot go to ~/projects/$submodule and do
> a "git add ../../{include,src,test,doc}/$submodule" there.
Right. That would break things rather horribly as you're trying to add
files below the root of your repository.
> I could add
> symlinks in ~/projects/$submodule to each of these dirs and add that
> link, but this would not work with windows, I guess (would it work
> with git, anyway?)
>
It would work with git, and it will work on windows, sort of. Git knows
that the symlink is a symlink, but it will check out a proper copy of
the actual file in its place on windows. You just have to be careful
when updating it, as tests and stuff before you've committed to git
might break with one file being the old revision still.
> So, how can I manage my code without having to restructure my tree?
>
Short answer; Lots of symlinks.
Longer answer:
Are you really sure that's the best structure for your code? I usually
find it absolutely simplest to bundle tests, buildrules and source
all in one directory (possibly with tests and documentation in a subdir),
but otherwise keep it all jumbled together. There's a very important
reason for this, and it's that your .cpp files shouldn't have to know
what some other buildsystem is doing with its header files, so you
should always be able to #include "header_for_this_api.hpp" and be
done with it.
If I were you, I'd do something like this:
/: top-level buildstuff
/doc: collection-wide documentation ("this suite of programs blahblah")
/t: integration tests
/lib/$library_subproject - holds library source/build/unit-tests/doc
/src/$program_subproject - holds program source/build/unit-tests/doc
After all, you're mostly updating one library or program at a time, right?
If you're not and all the API's are in wild flux, you should probably
just keep it jumbled in a single git repository for the moment and split
them later when things have calmed down a bit.
> I'd like to keep it that way, because it is convenient to have only
> one directory to pass to the compiler as an additional include dir,
> and can include my header files as "submodule/someheader.hpp" which
> is, in my opinion, helpful in organizing the code.
>
With the layout above, you just pass -I./lib as include dir and use
#include <$library/header.hpp>
in your cpp files, which is presumably what you'd use if you'd installed
the headers in the normal location too.
> If there should be no way I can keep my directory setup the way it is
> with the current git, would a feature request be a good idea (and
> possibly implemented),
A feature request to be able to track files outside the repository would
require some major surgery to the most basic of git objects, so I assume
such a feature wouldn't be too well received.
> or does my directory tree have a serious flaw I
> haven't stumbled across yet, which makes it unusable anyways?
>
I'd call it unusable to have to hop to several different directories to
add a single public function to a library, but perhaps that's just me?
Perhaps your programs contain mini-libraries that are shared at link-time
between applications? My advice in that case is to turn them into libraries
and make proper API's from them. That way the above directory structure
will give you everything you want while maintaining each individual
component separated in its own repository.
http://people.redhat.com/drepper/goodpractice.pdf holds a very nice and
concise writeup on how to create API's. I follow to the letter in most
of my library-like projects.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: combined diff, but not condensed, howto?
From: Junio C Hamano @ 2008-09-17 16:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <48D0B907.7040903@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> After a merge conflict, 'git diff' shows a combined diff, which presents
> only the parts that conflicted or where there are near-by changes from
> different parents (potential conflicts). Is there a command line switch so
> that *all* changes are shown, even non-conflicting ones?
Like "git diff HEAD"?
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Nguyen Thai Ngoc Duy @ 2008-09-17 16:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jakub Narebski, git
In-Reply-To: <48D13128.3000509@viscovery.net>
On 9/17/08, Johannes Sixt <j.sixt@viscovery.net> wrote:
> The still un-answered question was: In a full checkout, i.e. in a
> repository where the narrow/sparse checkout feature has never been used so
> far, is
>
> $ git checkout --add-path=foo
>
> a no-op, or is it equivalent to
>
> $ git checkout --path=foo
no-op.
--
Duy
^ permalink raw reply
* Re: [IRC/patches] Failed octopus merge does not clean up
From: Andreas Ericsson @ 2008-09-17 16:40 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Jakub Narebski, Junio C Hamano, Thomas Rast, git
In-Reply-To: <20080917155933.GI4829@genesis.frugalware.org>
Miklos Vajna wrote:
> On Wed, Sep 17, 2008 at 10:11:02AM +0200, Jakub Narebski <jnareb@gmail.com> wrote:
>>>> BTW. does it mean that "git merge a b" might be not the same as
>>>> "git merge b a"?
>>>>
>>> No. Git merges all the sub-things together and then merges the result
>>> of that jumble into the branch you're on.
>>>
>>> Someone might have to correct me on that, but that's as far as I've
>>> understood it.
>> From what I understand from above explanation, and from thread on git
>> mailing list about better implementation of and documenting finding
>> merge bases for multiple heads, I think octopus merge is done by merging
>> [reduced] heads one by one into given branch.
>>
>> This means that "git merge a b" does internally "git merge a; git merge b"
>> as I understand it.
>
> Sure, but given that both 'a' and 'b' merged (so none of them is subset
> of the other, for example so that reduce_heads() would drop one of them)
> the order of the parents will be different so the resulting commit will
> differ. The resulting tree will no, I think.
I got it wrong (not wrt reduced heads, but still). My apologies.
If octopus (the program/strategy/whatever) continues to merge after a
branch conflicting against the currently checked out branch (let's call
it "master"), the resulting tree may not differ, but then again, it might.
OTOH, if octopus quits the merge after having encountered a conflict, the
order the branches to merge were passed will always have an impact.
Let's say you have two branches, "clean" and "conflict". Which one is
which should be obvious here.
git merge clean conflict
will produce a tree with 'master', 'clean' and a conflicted merge of
'conflict', while
git merge conflict clean
will produce a tree with 'master' and a conflicted merge of 'conflict'.
In short, backing out the entire merge in case of a conflict is almost
certainly the only sane thing to do. If one branch depends on another
to merge cleanly, a different approach should have been taken (depending
branch should have been rebased onto the dependent one prior to merging),
but the merge *might* succeed depending on in which order the other
branches are given as arguments. It's not a very clever idea to merge
something like that though, as bisection will invariably have to mark the
entire depending branch as BAD, although the merge itself could obviously
be a good one.
Clearly, an octopus merge should not be undertaken without knowing very
well what it is one is merging in.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 15/16] checkout: add new options to support narrow checkout
From: Johannes Sixt @ 2008-09-17 16:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jakub Narebski, git
In-Reply-To: <fcaeb9bf0809170649w418f4af5x3055c04994c694dc@mail.gmail.com>
Nguyen Thai Ngoc Duy schrieb:
> Well I've been asking about the name on this list long enough. I'm
> going with 'sparse checkout' as svn' sparse directories does not look
> too different from git's.
FWIW, /me likes 'sparse checkout'.
> --path clears out all no-checkout bits and set again based on the
> given spec. --add-path adds more checkout entries based on the given
> spec, think of widening checkout area. --remove-path does narrow the
> checkout area. They are like '=', '+=' and '-=' operators
> respectively.
The still un-answered question was: In a full checkout, i.e. in a
repository where the narrow/sparse checkout feature has never been used so
far, is
$ git checkout --add-path=foo
a no-op, or is it equivalent to
$ git checkout --path=foo
Or stated differently: In the sequence
$ git checkout --full
$ git checkout --add-path=foo
is the second statement redundant?
-- Hannes
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Catalin Marinas @ 2008-09-17 16:09 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080916193647.GA12513@diana.vm.bytemark.co.uk>
2008/9/16 Karl Hasselström <kha@treskal.com>:
> On 2008-09-16 15:59:31 +0100, Catalin Marinas wrote:
>
>> 2008/9/16 Karl Hasselström <kha@treskal.com>:
>>
>> > iw is the index+worktree object. The idea is that you provide one
>> > if your branch is checked out, and not if not. Operations that
>> > have no need of index+worktree, like pop, and push in case
>> > automatic merging succeeds, will just work anyway, while
>> > operations that need index+worktree, such as a conflicting push,
>> > will cause the whole transaction to abort.
>>
>> Ah, that's the difference. I thought that even if iw isn't passed,
>> it uses the default one.
>
> It wouldn't be clean of it to do that -- it would be accessing
> non-local state it had no business knowing about. I try hard to avoid
> that kind of thing.
I'm still confused by this and I don't think your new flag would help.
The meaning of stop_before_conflict is that it won't push the
conflicting patch but actually leave the stack with several patches
pushed or popped.
What I want for sink (and float afterwards) is by default to cancel
the whole transaction if there is a conflict and revert the stack to
it's original state prior to the "stg sink" command. What I have in my
code:
iw = stack.repository.default_iw
trans = transaction.StackTransaction(stack, 'sink')
try:
trans.reorder_patches(applied, unapplied, hidden, iw)
except transaction.TransactionHalted:
if not options.conflict:
??? here it needs to check out the previous iw
raise
return trans.run(iw)
It runs as expected if --conflict is given but in the default case, if
there is a conflict, it keeps the original patchorder (as expected)
but the worktree isn't clean. What do I replace ??? with to clean the
work tree?
BTW, much shorter with reorder_patches.
--
Catalin
^ permalink raw reply
* Re: [StGit PATCH] Convert "sink" to the new infrastructure
From: Catalin Marinas @ 2008-09-17 16:01 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20080917130432.GA26365@diana.vm.bytemark.co.uk>
2008/9/17 Karl Hasselström <kha@treskal.com>:
> Have you tried the benchmarks I committed a while back?
No, I wanted to see how some real patches behave and I'm pretty
pleased with the result.
--
Catalin
^ permalink raw reply
* Re: [IRC/patches] Failed octopus merge does not clean up
From: Miklos Vajna @ 2008-09-17 15:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Andreas Ericsson, Junio C Hamano, Thomas Rast, git
In-Reply-To: <200809171011.06714.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
On Wed, Sep 17, 2008 at 10:11:02AM +0200, Jakub Narebski <jnareb@gmail.com> wrote:
> >> BTW. does it mean that "git merge a b" might be not the same as
> >> "git merge b a"?
> >>
> >
> > No. Git merges all the sub-things together and then merges the result
> > of that jumble into the branch you're on.
> >
> > Someone might have to correct me on that, but that's as far as I've
> > understood it.
>
> From what I understand from above explanation, and from thread on git
> mailing list about better implementation of and documenting finding
> merge bases for multiple heads, I think octopus merge is done by merging
> [reduced] heads one by one into given branch.
>
> This means that "git merge a b" does internally "git merge a; git merge b"
> as I understand it.
Sure, but given that both 'a' and 'b' merged (so none of them is subset
of the other, for example so that reduce_heads() would drop one of them)
the order of the parents will be different so the resulting commit will
differ. The resulting tree will no, I think.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Miklos Vajna @ 2008-09-17 15:55 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Andreas Ericsson, git, Johannes.Schindelin
In-Reply-To: <57518fd10809170831x6d84aeb0m9b0b2c4095a1de70@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 430 bytes --]
On Wed, Sep 17, 2008 at 04:31:17PM +0100, Jonathan del Strother <maillist@steelskies.com> wrote:
> I was changing it to match the style in the existing java pattern (and
> my objc pattern). You think the java one should be changed to match
> the pascal one, then?
The point is that it's unrelated, so you should not change that part in
the same patch. Send a separate patch if you want to do something
unrelated to Objective-C.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Jonathan del Strother @ 2008-09-17 15:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, vmiklos, Johannes.Schindelin
In-Reply-To: <48D11C3C.5070707@op5.se>
On Wed, Sep 17, 2008 at 4:03 PM, Andreas Ericsson <ae@op5.se> wrote:
> Jonathan del Strother wrote:
>> { "pascal", "^\\(\\(procedure\\|function\\|constructor\\|"
>> "destructor\\|interface\\|implementation\\|"
>> "initialization\\|finalization\\)[ \t]*.*\\)$"
>> "\\|"
>> - "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"
>> - },
>> + "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"},
>> +
>
> This last change is just pure nonsense. Please remove it altogether.
>
I was changing it to match the style in the existing java pattern (and
my objc pattern). You think the java one should be changed to match
the pascal one, then?
^ permalink raw reply
* Mismatch between "git status" and "git ls-files" [was Re: Teach git status to do "git diff --name-status HEAD"]
From: Michael J Gruber @ 2008-09-17 15:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <m3ej3jm3ux.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
Following up on the discussion about "git status" versus
"youknowwhichscm status" and suggestions to use "git diff --name-status"
or "git ls-files -d -m -o -t" I made a little test case, see the
attached script and output (git version 1.6.0.2.249.g97d7f). Observations:
- "git diff --name-status" and "git ls-files" use very similar form,
even the same status letters, but with completely different meaning for
C, M, R. That is highly confusing (this what I mean by mismatch).
- "git diff --name-status" has no way of showing ignored or untracked files
- "git status" has no way of showing ignored files
- "git ls-files -d -m -o -t" does not distinguish between ignored and
untracked (all is ?)
- "git ls-files" is plumbing, one should not need plumbing to get status
output.
I guess what's needed would be a porcelain that:
- shows state in concise form ("X filename" lines like --name-status or
ls-files -t)
- has options to show ignored and untracked file optionally
To me the most direct approach would be: If "git diff" compares with the
work-tree, teach it to include ignored resp. untracked files optionally.
I guess I wouldn't care about the mismatch then. Are there specific
reasons (other than evolution) for the conflicting status letters?
Michael
[-- Attachment #2: stats.out --]
[-- Type: text/plain, Size: 1559 bytes --]
Initialized empty Git repository in /tmp/mjg/stats/.git/
Created initial commit 345adf7: files to be changed
10 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 copied
create mode 100644 gitmoved
create mode 100644 gitremoved
create mode 100644 modified
create mode 100644 modifiedadded
create mode 100644 moved
create mode 100644 removed
create mode 100644 typechanged
create mode 100644 typechangedadded
create mode 100644 unchanged
rm 'gitremoved'
### git status ###
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: added
# new file: copiedadded
# renamed: gitmoved -> gitmoved2
# deleted: gitremoved
# modified: modifiedadded
# modified: typechangedadded
#
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# modified: modified
# deleted: moved
# deleted: removed
# modified: typechanged
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# copiedonly
# moved2
# untracked
### git diff ###
M modified
D moved
D removed
M typechanged
### git diff HEAD ###
A added
C100 copied copiedadded
R100 gitmoved gitmoved2
D gitremoved
M modified
M modifiedadded
D moved
D removed
M typechanged
M typechangedadded
### git diff --cached HEAD ###
A added
C100 copied copiedadded
R100 gitmoved gitmoved2
D gitremoved
M modifiedadded
M typechangedadded
### git ls-files
? copiedonly
? ignored
? moved2
? untracked
C modified
R moved
C moved
R removed
C removed
C typechanged
[-- Attachment #3: stats.sh --]
[-- Type: application/x-shellscript, Size: 943 bytes --]
^ permalink raw reply
* Re: [PATCH] Teach git diff about Objective-C syntax
From: Andreas Ericsson @ 2008-09-17 15:03 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: git, vmiklos, Johannes.Schindelin
In-Reply-To: <1221658141-75698-1-git-send-email-jon.delStrother@bestbefore.tv>
Jonathan del Strother wrote:
> Add support for recognition of Objective-C class & instance methods, C functions, and class implementation/interfaces.
>
> Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
> ---
> This version anchors the negated match to the beginning of the line, and shuffles the comments around to avoid the excessively long lines. Better?
>
Why do you insist on touching surrounding patterns? I've left them in
from your patch below so you can see where you're going wrong. Those
changes provide no value and make your patch harder to read. If you
want to make that cleanup, submit it separately, as it has nothing
to do with teaching git diff about objective C methods.
> diff --git a/diff.c b/diff.c
> index 998dcaa..e5ec503 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1398,17 +1398,31 @@ static struct builtin_funcname_pattern {
> } builtin_funcname_pattern[] = {
> { "bibtex", "\\(@[a-zA-Z]\\{1,\\}[ \t]*{\\{0,1\\}[ \t]*[^ \t\"@',\\#}{~%]*\\).*$" },
> { "html", "^\\s*\\(<[Hh][1-6]\\s.*>.*\\)$" },
> - { "java", "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
> +
> + { "java", "!^[ \t]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
> "new\\|return\\|switch\\|throw\\|while\\)\n"
> - "^[ ]*\\(\\([ ]*"
> + "^[ \t]*\\(\\([ \t]*"
> "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
> - "[ ]*([^;]*\\)$" },
> + "[ \t]*([^;]*\\)$" },
> +
The above should be in a separate patch.
> { "pascal", "^\\(\\(procedure\\|function\\|constructor\\|"
> "destructor\\|interface\\|implementation\\|"
> "initialization\\|finalization\\)[ \t]*.*\\)$"
> "\\|"
> - "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"
> - },
> + "^\\(.*=[ \t]*\\(class\\|record\\).*\\)$"},
> +
This last change is just pure nonsense. Please remove it altogether.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC/PATCH] Use compatibility regex library for OSX/Darwin
From: Boyd Lynn Gerber @ 2008-09-17 14:48 UTC (permalink / raw)
To: Brandon Casey
Cc: Jeff King, Arjen Laarhoven, git, Mike Ralphson, Johannes Sixt,
Junio C Hamano
In-Reply-To: <_MhavOIoKmx4_xVm-blejLMi-eFa1T8Huv94Uz9PxwJ3DyOMzuyUeg@cipher.nrlssc.navy.mil>
On Tue, 16 Sep 2008, Brandon Casey wrote:
> Boyd Lynn Gerber wrote:
>> So with path set so my /usr/gnu/bin/ is before any others this is what I
>> get as the next failure. After a long run...
>>
>> * FAIL 5: alternation in pattern
>>
>> git config diff.java.funcname "^[
>> ]*\(\(public\|static\).*\)$"
>> git diff --no-index Beer.java Beer-correct.java |
>> grep "^@@.*@@ public static void main("
>>
>>
>> * failed 1 among 5 test(s)
>> gmake[1]: *** [t4018-diff-funcname.sh] Error 1
>> gmake[1]: Leaving directory `/home/zenez/build/osr6/git-1.6.0.2/t'
>> gmake: *** [test] Error 2
>
> That's the one, thanks.
>
> And just so you know, this isn't a regression. It's just a new test that
> was designed to reveal a shortcoming that no one knew existed before Arjen
> discovered it.
Six of the 12 all have the same problem. I would say all 12 have it as my
experience has shown that if these have it then all have it. The fixes I
did were so generic that once I got these first 6 working the others just
worked. So I would say they all need the patch or fix. Sorry I did not
follow the whole thread. I read it from the archive what I could. It
seems the archive is about 2 days behind.
Good Luck,
--
Boyd Gerber <gerberb@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ 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