* [PATCH] gitk: Honor encoding conversion in a sole place for all possible cases
From: Alexey Shumkin @ 2011-02-03 16:42 UTC (permalink / raw)
To: git; +Cc: Alexey Shumkin
Previously every bug concerning encoding conversion
was fixed with a particular patch in a particular line of code
(e.g. 1f2cecfd53137b76d39b2dcd7bcf7e918cd745b3)
regardless other similar situations.
This patch centralizes reencoding of displayed text
considering all the cases where non-latin encoding may be used:
filenames, submodule names, rename/copy files, diffs (hunks),
commits comparison
Also cleaned up global "diffencoding" variable
Tested on Cygwin 1.5 and Cygwin 1.7
Still buggy on Cygwin 1.7: on a clear working copy shows
non-latin named files as removed and not indexed
Signed-off-by: Alexey Shumkin <zapped@mail.ru>
---
gitk | 24 ++++++++++--------------
1 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/gitk b/gitk
index 9cbc09d..1f9627d 100755
--- a/gitk
+++ b/gitk
@@ -5047,7 +5047,8 @@ proc dodiffindex {} {
proc readdiffindex {fd serial inst} {
global viewmainheadid nullid nullid2 curview commitinfo commitdata lserial
global vfilelimit
-
+ global gui_encoding
+
set isdiff 1
if {[gets $fd line] < 0} {
if {![eof $fd]} {
@@ -5069,6 +5070,9 @@ proc readdiffindex {fd serial inst} {
}
set fd [open $cmd r]
fconfigure $fd -blocking 0
+ if {$gui_encoding != {}} {
+ fconfigure $fd -encoding $gui_encoding
+ }
set i [reg_instance $fd]
filerun $fd [list readdifffiles $fd $serial $i]
@@ -7541,7 +7545,7 @@ proc getblobdiffs {ids} {
global ignorespace
global worddiff
global limitdiffs vfilelimit curview
- global diffencoding targetline diffnparents
+ global targetline diffnparents
global git_version currdiffsubmod
set textconv {}
@@ -7570,7 +7574,7 @@ proc getblobdiffs {ids} {
set diffnparents 0
set diffinhdr 0
set diffencoding [get_path_encoding {}]
- fconfigure $bdf -blocking 0 -encoding binary -eofchar {}
+ fconfigure $bdf -blocking 0 -encoding $diffencoding -eofchar {}
set blobdifffd($ids) $bdf
set currdiffsubmod ""
filerun $bdf [list getblobdiffline $bdf $diffids]
@@ -7618,11 +7622,9 @@ proc setinlist {var i val} {
}
proc makediffhdr {fname ids} {
- global ctext curdiffstart treediffs diffencoding
+ global ctext curdiffstart treediffs
global ctext_file_names jump_to_here targetline diffline
- set fname [encoding convertfrom $fname]
- set diffencoding [get_path_encoding $fname]
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
@@ -7643,7 +7645,7 @@ proc getblobdiffline {bdf ids} {
global diffnexthead diffnextnote difffilestart
global ctext_file_names ctext_file_lines
global diffinhdr treediffs mergemax diffnparents
- global diffencoding jump_to_here targetline diffline currdiffsubmod
+ global jump_to_here targetline diffline currdiffsubmod
global worddiff
set nr 0
@@ -7655,7 +7657,6 @@ proc getblobdiffline {bdf ids} {
}
if {![string compare -length 5 "diff " $line]} {
if {![regexp {^diff (--cc|--git) } $line m type]} {
- set line [encoding convertfrom $line]
$ctext insert end "$line\n" hunksep
continue
}
@@ -7715,7 +7716,6 @@ proc getblobdiffline {bdf ids} {
} elseif {![string compare -length 2 "@@" $line]} {
regexp {^@@+} $line ats
- set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" hunksep
if {[regexp { \+(\d+),\d+ @@} $line m nl]} {
set diffline $nl
@@ -7745,11 +7745,9 @@ proc getblobdiffline {bdf ids} {
}
} elseif {![string compare -length 3 " >" $line]} {
set $currdiffsubmod ""
- set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" dresult
} elseif {![string compare -length 3 " <" $line]} {
set $currdiffsubmod ""
- set line [encoding convertfrom $diffencoding $line]
$ctext insert end "$line\n" d0
} elseif {$diffinhdr} {
if {![string compare -length 12 "rename from " $line]} {
@@ -7757,7 +7755,6 @@ proc getblobdiffline {bdf ids} {
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
}
- set fname [encoding convertfrom $fname]
set i [lsearch -exact $treediffs($ids) $fname]
if {$i >= 0} {
setinlist difffilestart $i $curdiffstart
@@ -7779,8 +7776,7 @@ proc getblobdiffline {bdf ids} {
$ctext insert end "$line\n" filesep
} else {
- set line [string map {\x1A ^Z} \
- [encoding convertfrom $diffencoding $line]]
+ set line [string map {\x1A ^Z} $line]
# parse the prefix - one ' ', '-' or '+' for each parent
set prefix [string range $line 0 [expr {$diffnparents - 1}]]
set tag [expr {$diffnparents > 1? "m": "d"}]
--
1.7.4
^ permalink raw reply related
* [PATCH] Add case insensitive support in matching pathspec
From: Nguyễn Thái Ngọc Duy @ 2011-02-03 16:38 UTC (permalink / raw)
To: git, Junio C Hamano, Joshua Jensen; +Cc: Nguyễn Thái Ngọc Duy
Commit 21444f1 (Add case insensitivity support when using git ls-files
- 2010-10-03) teaches match_pathspec() to ignore case when
core.ignorecase=true.
match_pathspec_depth() is developed independently and does not have
this feature. Teach it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On top of nd/struct-pathspec, but requires jj/icase-directory. I can
rebase the series on top of master if it causes too many conflicts.
dir.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dir.c b/dir.c
index b1407a5..2597f81 100644
--- a/dir.c
+++ b/dir.c
@@ -192,7 +192,7 @@ static int match_pathspec_item(const struct pathspec_item *item, int prefix,
if (!*match)
return MATCHED_RECURSIVELY;
- if (matchlen <= namelen && !strncmp(match, name, matchlen)) {
+ if (matchlen <= namelen && !strncmp_icase(match, name, matchlen)) {
if (matchlen == namelen)
return MATCHED_EXACTLY;
@@ -200,7 +200,7 @@ static int match_pathspec_item(const struct pathspec_item *item, int prefix,
return MATCHED_RECURSIVELY;
}
- if (item->has_wildcard && !fnmatch(match, name, 0))
+ if (item->has_wildcard && !fnmatch_icase(match, name, 0))
return MATCHED_FNMATCH;
return 0;
--
1.7.2.2
^ permalink raw reply related
* Re: [msysGit] [PATCH] some test fixes for msysGit
From: Johannes Schindelin @ 2011-02-03 16:29 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Git Mailing List, msysGit, Junio C Hamano
In-Reply-To: <1296747105-1663-1-git-send-email-patthoyts@users.sourceforge.net>
Hi,
On Thu, 3 Feb 2011, Pat Thoyts wrote:
> The following patches resolve some issues for msysGit running the v1.7.4
> tests
>
> t/t3509-cherry-pick-merge-df.sh | 6 ++++--
> t/t4120-apply-popt.sh | 9 +++++++--
> t/t5526-fetch-submodules.sh | 32 ++++++++++++++++++--------------
> t/t7407-submodule-foreach.sh | 4 ++++
> 4 files changed, 33 insertions(+), 18 deletions(-)
I looked at the first three and think they are obviously fine.
As I mentioned, I would like to have a fix for the order in git-submodule.
If you do not have the time, I will try to push aside some of the work I
have to do here and investigate myself.
Ciao,
Dscho
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Nguyen Thai Ngoc Duy @ 2011-02-03 15:48 UTC (permalink / raw)
To: Santi Béjar
Cc: Johan Herland, git, Sverre Rabbelier, Jeff King, Nicolas Pitre
In-Reply-To: <AANLkTindnAFix+u3HKW0V-ArkzjyrDhpmN6gf9PSj0_G@mail.gmail.com>
On Thu, Feb 3, 2011 at 9:10 PM, Santi Béjar <santi@agolina.net> wrote:
>> On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:
>>> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net>
>> wrote:
>>> > Migration plan:
>>> > ...
>>> > In v1.8.0, we should default to the new default refspecs when
>>> > creating new remotes. However, existing remotes (created
>>> > pre-v1.8.0) must continue to work as before, so we cannot simply
>>> > remove the implicit refspecs (or tag auto-following). Instead we
>>> > need to make sure that the implicit refspecs is NOT applied to the
>>> > new-style remotes. Identifying new-style vs. old-style remotes can
>>> > be done by looking at the refspec itself (old-style:
>>> > "refs/remotes/$remote/*", new-style:
>>> > "refs/remotes/$remote/heads/*"), or (worst case) by introducing a
>>> > config variable specifying the desired behavior (defaulting to
>>> > old-style).
>>>
>>> I'd prefer config var (remote.*.implicitRules, maybe). We don't
>>> reserve heads, tags... in remote namespace for ourselves. Some users
>>> might have already have branches heads/ant, heads/bee... making new
>>> style detection unreliable.
>
> I don't quite follow the argument. For me the question is how likely
> an old-time user has modified the refspec to read
> "refs/remotes/$remote/heads/* (new-style). I think this is very, very
> unlikely and thus the "heuristic" to detect old/new style works most
> of the time and there is no need for a new config/compatibility key.
Personally I don't have any repos that weird, so it's no problem to
me. Maybe I'm overengineering.
--
Duy
^ permalink raw reply
* [PATCH 4/4] t5526: avoid dependency on submodule order
From: Pat Thoyts @ 2011-02-03 15:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: msysGit, Junio C Hamano, Pat Thoyts
In-Reply-To: <1296747105-1663-1-git-send-email-patthoyts@users.sourceforge.net>
When running tests on msysGit the actual results appear in the reverse
order. Added a test_cmp_unordered to test that each expected line is
present in the output without depending upon the order of lines.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
t/t5526-fetch-submodules.sh | 32 ++++++++++++++++++--------------
1 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodules.sh
index 884a5e5..d218845 100755
--- a/t/t5526-fetch-submodules.sh
+++ b/t/t5526-fetch-submodules.sh
@@ -32,6 +32,10 @@ add_upstream_commit() {
)
}
+test_cmp_unordered() {
+ grep --line-regexp -f "$@" >&3
+}
+
test_expect_success setup '
mkdir deepsubmodule &&
(
@@ -67,8 +71,8 @@ test_expect_success "fetch --recurse-submodules recurses into submodules" '
cd downstream &&
git fetch --recurse-submodules >../actual.out 2>../actual.err
) &&
- test_cmp expect.out actual.out &&
- test_cmp expect.err actual.err
+ test_cmp_unordered expect.out actual.out &&
+ test_cmp_unordered expect.err actual.err
'
test_expect_success "fetch alone only fetches superproject" '
@@ -96,8 +100,8 @@ test_expect_success "using fetchRecurseSubmodules=true in .gitmodules recurses i
git config -f .gitmodules submodule.submodule.fetchRecurseSubmodules true &&
git fetch >../actual.out 2>../actual.err
) &&
- test_cmp expect.out actual.out &&
- test_cmp expect.err actual.err
+ test_cmp_unordered expect.out actual.out &&
+ test_cmp_unordered expect.err actual.err
'
test_expect_success "--no-recurse-submodules overrides .gitmodules config" '
@@ -127,8 +131,8 @@ test_expect_success "--recurse-submodules overrides fetchRecurseSubmodules setti
git config -f --unset .gitmodules submodule.submodule.fetchRecurseSubmodules true &&
git config --unset submodule.submodule.fetchRecurseSubmodules
) &&
- test_cmp expect.out actual.out &&
- test_cmp expect.err actual.err
+ test_cmp_unordered expect.out actual.out &&
+ test_cmp_unordered expect.err actual.err
'
test_expect_success "--quiet propagates to submodules" '
@@ -146,14 +150,14 @@ test_expect_success "--dry-run propagates to submodules" '
cd downstream &&
git fetch --recurse-submodules --dry-run >../actual.out 2>../actual.err
) &&
- test_cmp expect.out actual.out &&
- test_cmp expect.err actual.err &&
+ test_cmp_unordered expect.out actual.out &&
+ test_cmp_unordered expect.err actual.err &&
(
cd downstream &&
git fetch --recurse-submodules >../actual.out 2>../actual.err
) &&
- test_cmp expect.out actual.out &&
- test_cmp expect.err actual.err
+ test_cmp_unordered expect.out actual.out &&
+ test_cmp_unordered expect.err actual.err
'
test_expect_success "recurseSubmodules=true propagates into submodules" '
@@ -163,8 +167,8 @@ test_expect_success "recurseSubmodules=true propagates into submodules" '
git config fetch.recurseSubmodules true
git fetch >../actual.out 2>../actual.err
) &&
- test_cmp expect.out actual.out &&
- test_cmp expect.err actual.err
+ test_cmp_unordered expect.out actual.out &&
+ test_cmp_unordered expect.err actual.err
'
test_expect_success "--recurse-submodules overrides config in submodule" '
@@ -177,8 +181,8 @@ test_expect_success "--recurse-submodules overrides config in submodule" '
) &&
git fetch --recurse-submodules >../actual.out 2>../actual.err
) &&
- test_cmp expect.out actual.out &&
- test_cmp expect.err actual.err
+ test_cmp_unordered expect.out actual.out &&
+ test_cmp_unordered expect.err actual.err
'
test_expect_success "--no-recurse-submodules overrides config setting" '
--
1.7.4.msysgit.0
^ permalink raw reply related
* [PATCH 1/4] t3509: use unconstrained initial test to setup repository.
From: Pat Thoyts @ 2011-02-03 15:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: msysGit, Junio C Hamano, Pat Thoyts
In-Reply-To: <1296747105-1663-1-git-send-email-patthoyts@users.sourceforge.net>
The first test did not run on msysGit due to the SYMLINKS constraint and
so subsequent tests failed because the test repository was not initialized.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
t/t3509-cherry-pick-merge-df.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/t3509-cherry-pick-merge-df.sh b/t/t3509-cherry-pick-merge-df.sh
index 948ca1b..df921d1 100755
--- a/t/t3509-cherry-pick-merge-df.sh
+++ b/t/t3509-cherry-pick-merge-df.sh
@@ -3,12 +3,14 @@
test_description='Test cherry-pick with directory/file conflicts'
. ./test-lib.sh
-test_expect_success SYMLINKS 'Setup rename across paths each below D/F conflicts' '
+test_expect_success 'Initialize repository' '
mkdir a &&
>a/f &&
git add a &&
- git commit -m a &&
+ git commit -m a
+'
+test_expect_success SYMLINKS 'Setup rename across paths each below D/F conflicts' '
mkdir b &&
ln -s ../a b/a &&
git add b &&
--
1.7.4.msysgit.0
^ permalink raw reply related
* [PATCH 2/4] t4120-apply-popt: help systems with core.filemode=false
From: Pat Thoyts @ 2011-02-03 15:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: msysGit, Junio C Hamano, Johannes Sixt, Pat Thoyts
In-Reply-To: <1296747105-1663-1-git-send-email-patthoyts@users.sourceforge.net>
From: Johannes Sixt <j6t@kdbg.org>
A test case verifies that filemode-only patches work as expected. Help
systems where "test -x" does not work by applying the test patch also to
the index, where the effects can be verified even on such systems.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
t/t4120-apply-popt.sh | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/t/t4120-apply-popt.sh b/t/t4120-apply-popt.sh
index 579c9e6..a33d510 100755
--- a/t/t4120-apply-popt.sh
+++ b/t/t4120-apply-popt.sh
@@ -6,6 +6,7 @@
test_description='git apply -p handling.'
. ./test-lib.sh
+. "$TEST_DIRECTORY"/lib-prereq-FILEMODE.sh
test_expect_success setup '
mkdir sub &&
@@ -62,8 +63,12 @@ test_expect_success 'apply (-p2) diff, mode change only' '
old mode 100644
new mode 100755
EOF
- chmod 644 file1 &&
- git apply -p2 patch.chmod &&
+ test_chmod -x file1 &&
+ git apply --index -p2 patch.chmod &&
+ case $(git ls-files -s file1) in 100755*) : good;; *) false;; esac
+'
+
+test_expect_success FILEMODE 'file mode was changed' '
test -x file1
'
--
1.7.4.msysgit.0
^ permalink raw reply related
* [PATCH 3/4] t7407: fix line endings for mingw build
From: Pat Thoyts @ 2011-02-03 15:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: msysGit, Junio C Hamano, Pat Thoyts
In-Reply-To: <1296747105-1663-1-git-send-email-patthoyts@users.sourceforge.net>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
t/t7407-submodule-foreach.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 1d67ef5..4c84764 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -254,6 +254,10 @@ test_expect_success 'ensure "status --cached --recursive" preserves the --cached
) &&
git submodule status --cached --recursive -- nested1 > ../actual
) &&
+ if test_have_prereq MINGW
+ then
+ dos2unix actual
+ fi &&
test_cmp expect actual
'
--
1.7.4.msysgit.0
^ permalink raw reply related
* [PATCH] some test fixes for msysGit
From: Pat Thoyts @ 2011-02-03 15:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: msysGit, Junio C Hamano
The following patches resolve some issues for msysGit running the v1.7.4 tests
t/t3509-cherry-pick-merge-df.sh | 6 ++++--
t/t4120-apply-popt.sh | 9 +++++++--
t/t5526-fetch-submodules.sh | 32 ++++++++++++++++++--------------
t/t7407-submodule-foreach.sh | 4 ++++
4 files changed, 33 insertions(+), 18 deletions(-)
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Geert Bosch @ 2011-02-03 14:38 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Shawn Pearce, Nguyen Thai Ngoc Duy, Jakub Narebski,
Jonathan Nieder, Dmitry S. Kravtsov, git
In-Reply-To: <alpine.LFD.2.00.1102011647000.8580@xanadu.home>
On Feb 1, 2011, at 16:51, Nicolas Pitre wrote:
> Also... people interested in Narrow clones are likely to be shallow
> clone users too, right?
Not necessarily. Many corporate repositories are huge (caused by
the concept of 1 central repository with everything in it) and have
tons of crud (like marketing materials, media-heavy powerpoint
presentations). Here you really want a narrow clone (such as the
sources of the project you're working on), but don't mind having
the whole history.
Looking at it from another angle: typically the whole history of a
project is not much bigger than a check out, so it is fine to have
a deep history. On the other hand, for these monster repositories
one would typically do a narrow clone of only a single subdirectory
that may be more than an order of magnitude smaller.
These narrow clones are especially important for imports of unwieldy
svn repositories where there is a large amount of unstructured
branching.
Regards,
-Geert
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Santi Béjar @ 2011-02-03 14:10 UTC (permalink / raw)
To: Johan Herland
Cc: Nguyen Thai Ngoc Duy, git, Sverre Rabbelier, Jeff King,
Nicolas Pitre
In-Reply-To: <201102031410.58623.johan@herland.net>
> On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:
>> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net>
> wrote:
>> > Migration plan:
>> > ...
>> > In v1.8.0, we should default to the new default refspecs when
>> > creating new remotes. However, existing remotes (created
>> > pre-v1.8.0) must continue to work as before, so we cannot simply
>> > remove the implicit refspecs (or tag auto-following). Instead we
>> > need to make sure that the implicit refspecs is NOT applied to the
>> > new-style remotes. Identifying new-style vs. old-style remotes can
>> > be done by looking at the refspec itself (old-style:
>> > "refs/remotes/$remote/*", new-style:
>> > "refs/remotes/$remote/heads/*"), or (worst case) by introducing a
>> > config variable specifying the desired behavior (defaulting to
>> > old-style).
>>
>> I'd prefer config var (remote.*.implicitRules, maybe). We don't
>> reserve heads, tags... in remote namespace for ourselves. Some users
>> might have already have branches heads/ant, heads/bee... making new
>> style detection unreliable.
I don't quite follow the argument. For me the question is how likely
an old-time user has modified the refspec to read
"refs/remotes/$remote/heads/* (new-style). I think this is very, very
unlikely and thus the "heuristic" to detect old/new style works most
of the time and there is no need for a new config/compatibility key.
HTH,
Santi
^ permalink raw reply
* git to p4 conversion
From: Endre Czirbesz @ 2011-02-03 13:52 UTC (permalink / raw)
To: git
Hi,
My company is introducing perforce, and the policy is that all source
codes should be kept there.
I have some small (and flat) git repos, which I would like to migrate
into a perforce depot keeping their histories. I tried git-p4 without
any success, and I did not find a good manual for it.
Is there any step-by-step tutorial out there? Is there any living human
who ever made a successful conversion in this direction?
Thanks for your help in advance.
Endre Czirbesz
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-03 13:10 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Sverre Rabbelier, Jeff King, Nicolas Pitre
In-Reply-To: <AANLkTinrqCaD_vg7Ah4Tjgoa-njEBEmiYt15ojtsazKw@mail.gmail.com>
On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:
> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net>
wrote:
> > Migration plan:
> > ...
> > In v1.8.0, we should default to the new default refspecs when
> > creating new remotes. However, existing remotes (created
> > pre-v1.8.0) must continue to work as before, so we cannot simply
> > remove the implicit refspecs (or tag auto-following). Instead we
> > need to make sure that the implicit refspecs is NOT applied to the
> > new-style remotes. Identifying new-style vs. old-style remotes can
> > be done by looking at the refspec itself (old-style:
> > "refs/remotes/$remote/*", new-style:
> > "refs/remotes/$remote/heads/*"), or (worst case) by introducing a
> > config variable specifying the desired behavior (defaulting to
> > old-style).
>
> I'd prefer config var (remote.*.implicitRules, maybe). We don't
> reserve heads, tags... in remote namespace for ourselves. Some users
> might have already have branches heads/ant, heads/bee... making new
> style detection unreliable.
>
> So I propose add remote.*.implicitRules = false since 1.8.0 for new
> remotes as a way to detect new/old style. The default value would be
> true.
>
> But I don't want to keep adding remote.*.implicitRules on new remotes
> forever. I suppose one year after 1.8.0, the new behavior is
> widespread enough. We can then annoy users to add
> remote.*.implicitRules for all old remotes. There should be no more
> default value after 1-2 years. We then flip the default value and
> won't automatically add remote.*.implicitRules = false on new
> remotes.
I don't have a problem with this, other than bikeshedding over the
variable name: I find remote.*.implicitFetchRefspecs more descriptive.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [1.8.0] Support quoting in .gitattributes, .gitignore
From: Nguyen Thai Ngoc Duy @ 2011-02-03 11:51 UTC (permalink / raw)
To: Git Mailing List
Proposal:
There's already a patch for .gitattributes [1].
To summarize: .gitattributes separates pattern and attributes by
spaces, therefore spaces could not be present in patterns. There are
tricks to overcome (e.g. substitute spaces with dots) but it's well..
tricky. The patch adds support for quoting full patterns.
While .gitignore does not have the same problem, it'd be nice to
support quoting too for a few reasons:
- Keep differences between gitattr and gitignore to minimum. A
hero(ine) might come and unify them some day. Don't make his/her work
harder.
- Is ability to put \n in patterns counted as a good point?
Risks:
Current patterns with leading double quote mark will be
misinterpreted. Though chances are really small.
Migration plan:
I think a release note mentioning this is enough. No migration needed.
But to be safe, we can make post-1.7.5 warn users about patterns with
leading double quote. By 1.8.0, the new behavior will be used.
[1] http://article.gmane.org/gmane.comp.version-control.git/160867
--
Duy
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Nguyen Thai Ngoc Duy @ 2011-02-03 11:35 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Sverre Rabbelier, Jeff King, Nicolas Pitre
In-Reply-To: <201102020322.00171.johan@herland.net>
On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> wrote:
> Migration plan:
> ...
> In v1.8.0, we should default to the new default refspecs when creating new
> remotes. However, existing remotes (created pre-v1.8.0) must continue to
> work as before, so we cannot simply remove the implicit refspecs (or tag
> auto-following). Instead we need to make sure that the implicit refspecs is
> NOT applied to the new-style remotes. Identifying new-style vs. old-style
> remotes can be done by looking at the refspec itself (old-style:
> "refs/remotes/$remote/*", new-style: "refs/remotes/$remote/heads/*"), or
> (worst case) by introducing a config variable specifying the desired
> behavior (defaulting to old-style).
I'd prefer config var (remote.*.implicitRules, maybe). We don't
reserve heads, tags... in remote namespace for ourselves. Some users
might have already have branches heads/ant, heads/bee... making new
style detection unreliable.
So I propose add remote.*.implicitRules = false since 1.8.0 for new
remotes as a way to detect new/old style. The default value would be
true.
But I don't want to keep adding remote.*.implicitRules on new remotes
forever. I suppose one year after 1.8.0, the new behavior is
widespread enough. We can then annoy users to add
remote.*.implicitRules for all old remotes. There should be no more
default value after 1-2 years. We then flip the default value and
won't automatically add remote.*.implicitRules = false on new remotes.
--
Duy
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Yann Dirson @ 2011-02-03 11:07 UTC (permalink / raw)
To: git list
Jonathan wrote:
>What might make git nice as an interoperability tool is that it tracks
>the _relevant_ information for the history of a software project.
>Example of what is not relevant information and why that matters:
>
> http://thread.gmane.org/gmane.comp.version-control.git/53494
Hell, that message seems to even suggest a potential solution:
use .gitattributes for tracking empty dirs. That way a post-change
"git checkout-index" could find the info (from .gitattribute in the index)
without confusing any pre-change tool.
For ease of use, some porcelain could possibly be taught to add empty
directories into $GIT_DIR/.gitattribute (as well as checking whether an
empty-dir entry has turned useless because it now has content, and any
other administrative stuff we could want).
But that idea is linked to another issue, which could be the subject
of a 1.8 proposal of its own: the handling of .gitattribute, for which
only the checked-out version is taken into account:
http://marc.info/?l=git&m=126458888515166
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Matthieu Moy @ 2011-02-03 10:07 UTC (permalink / raw)
To: Wesley J. Landaker
Cc: David Aguilar, Jay Soffian, Jakub Narebski, git@vger.kernel.org
In-Reply-To: <201102021921.53755.wjl@icecavern.net>
"Wesley J. Landaker" <wjl@icecavern.net> writes:
> 2) One of git's best strengths is that it's so easy to interact with other
> SCM software, primarily because git's features are a SUPERSET of other SCMs.
> However, almost every other SCM can track empty directories, except
> git,
[...]
> 4) On many projects I work on with a huge number of people, the workflow
> is to create a very, very intricate directory hierarchy skeleton, so that
> it's clear to everyone where everything goes and how it is organized, even
> before any work is started.
Just adding my 2 cents: my first clash with Git's non-management of
empty directories was a combination of both. A colleague created an
SVN project with several empty directories, along the lines of "Here
it is. Now, put your stuff in there".
git-svn didn't import these empty directories (I think I actually
could have worked around this with "git svn mkdirs"). Adding
.gitignore files would have been a really dirty workaround since I
didn't want to put Git stuff in the SVN repo.
I don't think my colleague did anything wrong, I did want to use Git,
and that was still frustrating to see such a simple scenario not
managed by my favorite tool.
So, yes, I can clearly leave without empty directory support, but that
would be a nice addition to Git.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-03 8:46 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Sverre Rabbelier, Jeff King, Nicolas Pitre
In-Reply-To: <AANLkTi=tMq18mKqr0cp9rXqtDApKu3P_AZGyX6fA3hsx@mail.gmail.com>
On Thursday 03 February 2011, Nguyen Thai Ngoc Duy wrote:
> On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> wrote:
> > Migration plan:
> > ...
> > In v1.8.0, we should default to the new default refspecs when creating
> > new remotes. However, existing remotes (created pre-v1.8.0) must
> > continue to work as before, so we cannot simply remove the implicit
> > refspecs (or tag auto-following). Instead we need to make sure that
> > the implicit refspecs is NOT applied to the new-style remotes.
> > Identifying new-style vs. old-style remotes can be done by looking at
> > the refspec itself (old-style: "refs/remotes/$remote/*", new-style:
> > "refs/remotes/$remote/heads/*"), or (worst case) by introducing a
> > config variable specifying the desired behavior (defaulting to
> > old-style).
>
> How about convert old style remotes to new style? Should it be done
> automatically when new git detects old style remotes, or done by
> command, or manually?
I don't think we want to mess with existing remote refs without the user's
consent, especially since the user might have all kinds of repo-specific
practices tied to the old layout of remote refs.
Providing a command to do it (git remote renew?) is a much better way to go
about it, IMHO. Still, it is vitally important that new git keeps working
with old-style remotes.
Another issue is whether we should automatically make the old-style implicit
refspecs into _explicit_ (but still old-style) refspecs. I.e. when
encountering an old-style remote, new git could automatically add the
following refspecs to the remote:
+HEAD:refs/remotes/origin/HEAD
~refs/tags/*:refs/tags/*
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Miles Bader @ 2011-02-03 8:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: George Spelvin, git
In-Reply-To: <alpine.LFD.2.00.1102030036420.12104@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
>> But just moving the whole existing pile into a subdirectory "because
>> everyone else does it" is not a reason; that's superstition.
>
> There is no superstition here, simply basic elegance.
"basic elegance" is hardly well-defined, and although there are probably
issues on which there's general agreement, this doesn't appear to be one
of them.
>> Having to type "src/" a lot more often is definitely a downside.
>
> Come on. This is a rather egocentric argument without much substance.
It certainly has more substance than hand-waving like "basic elegance"
though...
Some slightly more concrete arguments have been:
Pro-src: Big top-level dir scares newbs
Anti-src: Extra typing is annoying
I'm not really against a "src/" subdir, but it seems mostly a matter of
taste, and I've seen plenty of projects where the src/ directory seemed
pretty pointless...
-Miles
--
Politics, n. A strife of interests masquerading as a contest of
principles. The conduct of public affairs for private advantage.
^ permalink raw reply
* Re: Q: does index-pack work in place on windows?
From: Junio C Hamano @ 2011-02-03 7:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Erik Faye-Lund, Johannes Sixt, git, Shawn O. Pearce
In-Reply-To: <alpine.LFD.2.00.1102030026430.12104@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
>> $ git index-pack
>> .git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.pack
>> Unlink of file '.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx'
>> failed. Should I try again? (y/n)? n
>> fatal: unable to create
>> '.git/objects/pack/pack-d634271f4d7ca70c00148e967a343c3c46cd7705.idx':
>> File exists
>
> Why would you do such thing in the first place?
>
> If the pack exists along with its index on disk, there is no point
> recreating it. Maybe index-pack should just bail out early in that
> case.
I am trying to see if an index-pack with slight modification would be a
good replacement for verify-pack.
^ permalink raw reply
* Re: big files in git was: Re: Features from GitSurvey 2010
From: Nicolas Pitre @ 2011-02-03 6:25 UTC (permalink / raw)
To: david; +Cc: Jakub Narebski, Jonathan Nieder, Dmitry S. Kravtsov, git
In-Reply-To: <alpine.DEB.2.00.1102011443380.10088@asgard.lang.hm>
On Tue, 1 Feb 2011, david@lang.hm wrote:
> On Tue, 1 Feb 2011, Jakub Narebski wrote:
>
> > There is also, supposedly stalled, git-bigfiles project.
>
> why is the clean/smudge approach that came through the list a week or two ago
> not acceptable?
No idea.
I suppose that's because it is not complicated enough to actually be
interesting. This is like my suggestion for simply distributing bundles
with BitTorrent.
> If nobody else has time to take those e-mails and create a set of clean/smudge
> scripts, I'll do so later this week (unless there is some reason why they
> wouldn't be acceptable)
Please do so. The contrib directory would be a pretty good place to put
them.
> I guess the only question is how to tell what files need to be handled this
> way, but can't we have something in .gitattributes about the file size?
Surely. There is even a core.bigFileThreshold config variable already
which could be reused right away for this purpose.
Nicolas
^ permalink raw reply
* [PATCH] diff: support --cached on unborn branches
From: Nguyễn Thái Ngọc Duy @ 2011-02-03 6:23 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <20101031032413.GA27346@do>
"git diff --cached" (without revision) used to mean "git diff --cached
HEAD" (i.e. the user was too lazy to type HEAD). This "correctly"
failed when there was no commit yet. But was that correctness useful?
This patch changes the definition of what particular command means.
It is a request to show what _would_ be committed without further "git
add". The internal implementation is still the same "git diff
--cached HEAD" when HEAD exists, but when there is no commit yet, it
compares the index with an empty tree object to achieve the desired
result.
(Written by Junio)
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
(Good) old stuff. I think it wasn't accepted because I was lazy in
updating docs. Resend (with doc updates).
Documentation/git-diff.txt | 2 +
builtin/diff.c | 7 ++++-
t/t4013-diff-various.sh | 11 ++++++++++
t/t4013/diff.diff_--cached | 38 +++++++++++++++++++++++++++++++++++
t/t4013/diff.diff_--cached_--_file0 | 15 +++++++++++++
5 files changed, 71 insertions(+), 2 deletions(-)
create mode 100644 t/t4013/diff.diff_--cached
create mode 100644 t/t4013/diff.diff_--cached_--_file0
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index f6ac847..4910510 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -38,6 +38,8 @@ directories. This behavior can be forced by --no-index.
commit relative to the named <commit>. Typically you
would want comparison with the latest commit, so if you
do not give <commit>, it defaults to HEAD.
+ If HEAD does not exist (e.g. unborned branches) and
+ <commit> is not given, it shows all staged changes.
--staged is a synonym of --cached.
'git diff' [--options] <commit> [--] [<path>...]::
diff --git a/builtin/diff.c b/builtin/diff.c
index 945e758..42822cd 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -330,8 +330,11 @@ int cmd_diff(int argc, const char **argv, const char *prefix)
else if (!strcmp(arg, "--cached") ||
!strcmp(arg, "--staged")) {
add_head_to_pending(&rev);
- if (!rev.pending.nr)
- die("No HEAD commit to compare with (yet)");
+ if (!rev.pending.nr) {
+ struct tree *tree;
+ tree = lookup_tree((const unsigned char*)EMPTY_TREE_SHA1_BIN);
+ add_pending_object(&rev, &tree->object, "HEAD");
+ }
break;
}
}
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 9a66520..b8f81d0 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -290,4 +290,15 @@ test_expect_success 'log -S requires an argument' '
test_must_fail git log -S
'
+test_expect_success 'diff --cached on unborn branch' '
+ echo ref: refs/heads/unborn >.git/HEAD &&
+ git diff --cached >result &&
+ test_cmp "$TEST_DIRECTORY/t4013/diff.diff_--cached" result
+'
+
+test_expect_success 'diff --cached -- file on unborn branch' '
+ git diff --cached -- file0 >result &&
+ test_cmp "$TEST_DIRECTORY/t4013/diff.diff_--cached_--_file0" result
+'
+
test_done
diff --git a/t/t4013/diff.diff_--cached b/t/t4013/diff.diff_--cached
new file mode 100644
index 0000000..ff16e83
--- /dev/null
+++ b/t/t4013/diff.diff_--cached
@@ -0,0 +1,38 @@
+diff --git a/dir/sub b/dir/sub
+new file mode 100644
+index 0000000..992913c
+--- /dev/null
++++ b/dir/sub
+@@ -0,0 +1,8 @@
++A
++B
++C
++D
++E
++F
++1
++2
+diff --git a/file0 b/file0
+new file mode 100644
+index 0000000..10a8a9f
+--- /dev/null
++++ b/file0
+@@ -0,0 +1,9 @@
++1
++2
++3
++4
++5
++6
++A
++B
++C
+diff --git a/file1 b/file1
+new file mode 100644
+index 0000000..b1e6722
+--- /dev/null
++++ b/file1
+@@ -0,0 +1,3 @@
++A
++B
++C
diff --git a/t/t4013/diff.diff_--cached_--_file0 b/t/t4013/diff.diff_--cached_--_file0
new file mode 100644
index 0000000..b9bb858
--- /dev/null
+++ b/t/t4013/diff.diff_--cached_--_file0
@@ -0,0 +1,15 @@
+diff --git a/file0 b/file0
+new file mode 100644
+index 0000000..10a8a9f
+--- /dev/null
++++ b/file0
+@@ -0,0 +1,9 @@
++1
++2
++3
++4
++5
++6
++A
++B
++C
--
1.7.3.4.878.g439c7
^ permalink raw reply related
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Nicolas Pitre @ 2011-02-03 6:16 UTC (permalink / raw)
To: George Spelvin; +Cc: git
In-Reply-To: <20110202022909.30644.qmail@science.horizon.com>
On Tue, 1 Feb 2011, George Spelvin wrote:
> For what it's worth, I don't see the "cleanup".
>
> If it significantly reduced the size of the largest directory,
> that would be a win. But moving everything into src/ doesn't
> do that.
>
> If there's a way to divide the source into cohesive subunits, that
> would be great. A programmer could ignore whole subdirectories
> when working on something.
>
> But just moving the whole existing pile into a subdirectory "because
> everyone else does it" is not a reason; that's superstition.
There is no superstition here, simply basic elegance.
When you pick up a book from a shelf, do you see the actual content of
the book printed right from the inside of the cover page, and the table
of content tossed in the margin? Would you construct a book yourself
that way?
A nice source tree should be organized with a minimum of hierarchical
structure. To a newbie wanting to contribute to Git, it is rather
frightening to cd into the git directory and see that ls generates more
than 280 entries. That simply looks sloppy. And this gets much worse
after a make.
The top directory should make different things stand out much more
clearly, like a preface and a table of content. You have the
documentation here, the source there, the tests there, a clearly visible
README file, etc. If the src directory has about the same relative
number of files after a move that's fine. At least you should expect
_only_ source files in there (and possibly their by-products), and not
other types of data buried into the mix.
> Having to type "src/" a lot more often is definitely a downside.
Come on. This is a rather egocentric argument without much substance.
> Heck, that's one thing I actively dislike about GNU autoconf conventions.
This has _nothing_ about any autoconf convention. GNU autoconf requires
stupid things like having a bunch of files such as CREDITS, INSTALL,
CHANGELOG, and other whatnots even if you have nothing to put in them,
in which case they still have to be there but empty. It also dictates
the exact name your directories must have, etc.
I'm not proposing a tree reorganization because GNU autoconf commands
it, but rather because this is a sensible thing to do.
> If there's a compelling reason to change, could someone please describe it?
It's about the third time I'm putting forward arguments for this.
Please see the list archive.
P.S. the netiquette on busy mailing lists recommends that you preserve
all the email addresses that were listed as recipients on the message
you reply to. That would be highly appreciated.
Nicolas
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Jonathan Nieder @ 2011-02-03 5:53 UTC (permalink / raw)
To: Wesley J. Landaker
Cc: David Aguilar, Jay Soffian, Jakub Narebski, git@vger.kernel.org
In-Reply-To: <201102021921.53755.wjl@icecavern.net>
Wesley J. Landaker wrote:
> 1) Why WOULDN'T you want to track empty directories? We track empty files:
> isn't that just as pointless?
See http://thread.gmane.org/gmane.comp.version-control.git/52875
> 2) One of git's best strengths is that it's so easy to interact with other
> SCM software, primarily because git's features are a SUPERSET of other SCMs.
Not really. For example, many other SCMs can store per-file comments,
arbitrary revision properties, a detailed provenance of a file, and
detailed permissions for each directory entry.
What might make git nice as an interoperability tool is that it tracks
the _relevant_ information for the history of a software project.
Example of what is not relevant information and why that matters:
http://thread.gmane.org/gmane.comp.version-control.git/53494
All that said, I do want support for explicitly[1] tracking empty
directories, mostly for the sake of the ability to clone an svn repo
with empty directories in a simple way.
The aforementioned "share a project skeleton" use case is just a nice
bonus.
Hope that helps,
Jonathan
[1] Part of the value of the "explicitly" is to make it explicit that
early adopters are asking for trouble. :) FWIW I imagine a transition
like this:
1. Teach "git read-tree" and "git checkout-index" to honor empty
directories (but not "git update-index" or "git write-tree").
2. Teach "git write-tree" to accept empty directories.
3. Teach "git update-index" to accept empty directories if a
configuration item indicates so. That configuration would
default to false.
4. (Maybe) add porcelain support for tracking of empty directories.
Also teach "git diff-tree" and "git apply" about empty
directories.
5. Change the default to true.
An orthogonal question is how the empty directories would be stored.
I do not like the idea of a ".empty-directory" file, since what
happens when you try to import a repository with a genuine
".empty-directory" file?
Based on a quick test, currently read-tree _ignores_ empty tree
entries. Would it be okay to say that anyone who turns on the switch
from step (3) has declared he is willing to write tree objects that
git fsck versions before v1.5.5-rc0~63 (fsck.c: fix bogus "empty tree"
check, 2008-03-04) will reject and current git might mishandle?
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Nguyen Thai Ngoc Duy @ 2011-02-03 5:33 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Sverre Rabbelier, Jeff King, Nicolas Pitre
In-Reply-To: <201102020322.00171.johan@herland.net>
On Wed, Feb 2, 2011 at 9:21 AM, Johan Herland <johan@herland.net> wrote:
> Migration plan:
> ...
> In v1.8.0, we should default to the new default refspecs when creating new
> remotes. However, existing remotes (created pre-v1.8.0) must continue to
> work as before, so we cannot simply remove the implicit refspecs (or tag
> auto-following). Instead we need to make sure that the implicit refspecs is
> NOT applied to the new-style remotes. Identifying new-style vs. old-style
> remotes can be done by looking at the refspec itself (old-style:
> "refs/remotes/$remote/*", new-style: "refs/remotes/$remote/heads/*"), or
> (worst case) by introducing a config variable specifying the desired
> behavior (defaulting to old-style).
How about convert old style remotes to new style? Should it be done
automatically when new git detects old style remotes, or done by
command, or manually?
--
Duy
^ 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