* Re: cmd_cherry in builtin/log.c?
From: René Scharfe @ 2010-12-09 21:14 UTC (permalink / raw)
Cc: Junio C Hamano, Jonathan Nieder, Thiago Farina, Git Mailing List
In-Reply-To: <7vaakhpbq2.fsf@alter.siamese.dyndns.org>
Am 07.12.2010 21:30, schrieb Junio C Hamano:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> Am 07.12.2010 18:39, schrieb Jonathan Nieder:
>>> while the core of the builtin version is
>>>
>>> get_patch_ids(&revs, &patch_id_opts, prefix);
>>>
>>> The latter function is static, introduced by v1.4.1~12^2~5
>>> (format-patch: introduce "--ignore-if-in-upstream", 2006-06-25).
>>>
>>> So the answer is that "git cherry" is considered a variant on
>>> "git log" (like format-patch, show, and whatchanged) and that it uses
>>> "git log" internals.
>>
>> That's right. get_patch_ids() could be moved into patch-ids.c now and
>> then cmd_cherry() could get its own file in builtin/, though.
>
> Right, but the key word is "could". Is it hurting _anything_ to have it
> in the current place? I doubt it.
Indeed. Moving cherry's code into its own file is be a code clean up.
There would be no benefit to users, future developers should have a
somewhat easier time navigating the code while any developers currently
working on the code would get it pulled from under them.
Such a clean up can be useful to include at the start of a patch series
that contains actual user visible improvements.
René
^ permalink raw reply
* Re: [PATCH] get_sha1: support relative path "<obj>:<sth>" syntax
From: Junio C Hamano @ 2010-12-09 21:10 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, jnareb, dirson, kevin, peff
In-Reply-To: <1289407021-30287-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Currently :path and ref:path can be used to refer to a specific object
> in index or ref respectively. "path" component is absolute path. This
> patch allows "path" to be written as "./path" or "../path", which is
> relative to user's original cwd.
>
> This does not work in commands that startup_info is NULL
> (i.e. non-builtin ones).
> ---
> On Wed, Nov 10, 2010 at 07:26:20AM -0800, Jakub Narebski wrote:
> > The <obj>:<sth> is (with single exception of ':/<regexp>') about
> > selecting subitem (path): <tree-ish>:<path>, [:<stage>]:<path>
>
> I feel the urge of keeping ':./path' and ':../path' out of this
> competition.
>
> The idea is old although I don't remember if anybody has made any
> attempt to realize it: use './' and '../' to specify the given path
> is relative, not absolute.
I've had this queued for some time, with help from Jonathan, and am happy
about it in general, but after taking another look at it, noticed one
minor thing.
> diff --git a/sha1_name.c b/sha1_name.c
> index 484081d..791608d 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -1060,25 +1060,35 @@ int get_sha1_with_context_1(const char *name, unsigned char *sha1,
> if (!ret)
> return ret;
> /* sha1:path --> object name of path in ent sha1
> - * :path -> object name of path in index
> + * :path -> object name of absolute path in index
> + * :./path -> object name of path relative to cwd in index
> * :[0-3]:path -> object name of path in index at stage
> * :/foo -> recent commit matching foo
> */
> if (name[0] == ':') {
> int stage = 0;
> struct cache_entry *ce;
> + char *new_path = NULL;
> int pos;
> if (namelen > 2 && name[1] == '/')
> return get_sha1_oneline(name + 2, sha1);
> if (namelen < 3 ||
> name[2] != ':' ||
> - name[1] < '0' || '3' < name[1])
> + name[1] < '0' || '3' < name[1]) {
> cp = name + 1;
> + if (startup_info && cp[0] == '.' &&
> + (cp[1] == '/' || (cp[1] == '.' && cp[2] == '/'))) {
> + new_path = prefix_path(startup_info->prefix,
> + strlen(startup_info->prefix),
> + cp);
> + cp = new_path;
> + }
> + }
This deals with ":$foo" (path $foo in the index), which is a shorthand for
":0:$foo" (the path $foo at stage #0 in the index). However...
> else {
> stage = name[1] - '0';
> cp = name + 3;
... this side does not do anything about it, so:
$ cd Documentation
... working for a while ...
$ git merge another_branch
... oops, got conflicts at ../Makefile
$ git show :2:../Makefile
won't work.
Besides, it is a bad idea to make ":../Makefile" work while leaving
its longhand ":0:../Makefile" not.
I think it is just the matter of moving "if (startup-info)..." logic
outside the "is the :$path lacking an explicit stage number" block and
having it after that if/else, no?
^ permalink raw reply
* [PATCH 7/8] git-gui: handle special content lines only in the diff header section
From: Bert Wesarg @ 2010-12-09 20:47 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, git, Bert Wesarg
In-Reply-To: <babc4fe91e54e3923baa6f08cc92ee8ea494e704.1291927657.git.bert.wesarg@googlemail.com>
These two also stop the diff header.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/diff.tcl | 15 +++++++++------
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 91ed7c6..4eaf7e7 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -400,7 +400,14 @@ proc read_diff {fd conflict_size cont_info} {
if {[string match {@@@ *} $line]} {set is_3way_diff 1}
if {$::current_diff_inheader} {
- append current_diff_header $line "\n"
+
+ # -- These two lines stop a diff header and shouldn't be in there
+ if { [string match {Binary files * and * differ} $line]
+ || [regexp {^\* Unmerged path } $line]} {
+ set ::current_diff_inheader 0
+ } else {
+ append current_diff_header $line "\n"
+ }
# -- Cleanup uninteresting diff header lines.
#
@@ -418,16 +425,12 @@ proc read_diff {fd conflict_size cont_info} {
regsub {^(deleted|new) file mode 120000} $line {\1 symlink} line
}
-
-
if {[string match {new file *} $line]
|| [regexp {^(old|new) mode *} $line]
|| [string match {deleted file *} $line]
|| [string match {deleted symlink} $line]
|| [string match {new symlink} $line]
- || [string match {Binary files * and * differ} $line]
- || $line eq {\ No newline at end of file}
- || [regexp {^\* Unmerged path } $line]} {
+ || $line eq {\ No newline at end of file}} {
} elseif {$is_3way_diff} {
set op [string range $line 0 1]
switch -- $op {
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 8/8] git-gui: handle meta diff header lines only in the header section
From: Bert Wesarg @ 2010-12-09 20:47 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, git, Bert Wesarg
In-Reply-To: <babc4fe91e54e3923baa6f08cc92ee8ea494e704.1291927657.git.bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/diff.tcl | 9 ++-------
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 4eaf7e7..cf8a95e 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -423,14 +423,9 @@ proc read_diff {fd conflict_size cont_info} {
# -- Name it symlink, not 120000
# Note, that the original line is in $current_diff_header
regsub {^(deleted|new) file mode 120000} $line {\1 symlink} line
- }
- if {[string match {new file *} $line]
- || [regexp {^(old|new) mode *} $line]
- || [string match {deleted file *} $line]
- || [string match {deleted symlink} $line]
- || [string match {new symlink} $line]
- || $line eq {\ No newline at end of file}} {
+ } elseif { $line eq {\ No newline at end of file}} {
+ # -- Handle some special lines
} elseif {$is_3way_diff} {
set op [string range $line 0 1]
switch -- $op {
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 5/8] git-gui: move 3way diff autodetect up
From: Bert Wesarg @ 2010-12-09 20:47 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, git, Bert Wesarg
In-Reply-To: <babc4fe91e54e3923baa6f08cc92ee8ea494e704.1291927657.git.bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/diff.tcl | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 20f50dd..2290919 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -393,6 +393,10 @@ proc read_diff {fd conflict_size cont_info} {
#
if {[regexp {^@@+ } $line]} {set ::current_diff_inheader 0}
+ # -- Automatically detect if this is a 3 way diff.
+ #
+ if {[string match {@@@ *} $line]} {set is_3way_diff 1}
+
if {$::current_diff_inheader} {
append current_diff_header $line "\n"
@@ -413,9 +417,6 @@ proc read_diff {fd conflict_size cont_info} {
}
- # -- Automatically detect if this is a 3 way diff.
- #
- if {[string match {@@@ *} $line]} {set is_3way_diff 1}
if {[string match {new file *} $line]
|| [regexp {^(old|new) mode *} $line]
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 6/8] git-gui: always reset the current tag
From: Bert Wesarg @ 2010-12-09 20:47 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, git, Bert Wesarg
In-Reply-To: <babc4fe91e54e3923baa6f08cc92ee8ea494e704.1291927657.git.bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/diff.tcl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 2290919..91ed7c6 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -382,6 +382,8 @@ proc read_diff {fd conflict_size cont_info} {
foreach {line markup} [parse_color_line $line] break
set line [string map {\033 ^} $line]
+ set tags {}
+
# -- Check for start of diff header.
if { [string match {diff --git *} $line]
|| [string match {diff --cc *} $line]
@@ -426,7 +428,6 @@ proc read_diff {fd conflict_size cont_info} {
|| [string match {Binary files * and * differ} $line]
|| $line eq {\ No newline at end of file}
|| [regexp {^\* Unmerged path } $line]} {
- set tags {}
} elseif {$is_3way_diff} {
set op [string range $line 0 1]
switch -- $op {
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 1/8] git-gui: rework handling of diff header
From: Bert Wesarg @ 2010-12-09 20:47 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, git, Bert Wesarg, Johannes Sixt
The fix in ca53c3f (Fix diff parsing for lines starting with "--" or "++",
2008-09-05) got a bug report from Johannes Sixt, that new files in the
index now looks like:
new file mode 100644
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo
The introduced problem was that the 'in-diff-header'-flag was unconditially
disabled. Now it is only disabled when a hunk line is detected. And also
re-enabled when we encounter a new diff header.
The second part solves also the issue reported by me for diffs with file
type changes (i.e. the ''error: Unhandled 2 way diff marker: {d}"', which
comes from the second 'diff --git' line).
Reported-by: Johannes Sixt <j.sixt@viscovery.net>
Reported-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
Cc: Johannes Sixt <j.sixt@viscovery.net>
---
foo | 1 +
lib/diff.tcl | 18 +++++++++++++++---
2 files changed, 16 insertions(+), 3 deletions(-)
create mode 100644 foo
diff --git a/foo b/foo
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/foo
@@ -0,0 +1 @@
+foo
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 9d0dc07..dae6ca6 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -382,23 +382,35 @@ proc read_diff {fd conflict_size cont_info} {
foreach {line markup} [parse_color_line $line] break
set line [string map {\033 ^} $line]
- # -- Cleanup uninteresting diff header lines.
+ # -- Check for start of diff header.
+ if { [string match {diff --git *} $line]
+ || [string match {diff --cc *} $line]
+ || [string match {diff --combined *} $line]} {
+ set ::current_diff_inheader 1
+ }
+
+ # -- Check for end of diff header (any hunk line will do this).
#
+ if {[regexp {^@@+ } $line]} {set ::current_diff_inheader 0}
+
if {$::current_diff_inheader} {
+ append current_diff_header $line "\n"
+
+ # -- Cleanup uninteresting diff header lines.
+ #
if { [string match {diff --git *} $line]
|| [string match {diff --cc *} $line]
|| [string match {diff --combined *} $line]
|| [string match {--- *} $line]
|| [string match {+++ *} $line]} {
- append current_diff_header $line "\n"
continue
}
}
+
if {[string match {index *} $line]} continue
if {$line eq {deleted file mode 120000}} {
set line "deleted symlink"
}
- set ::current_diff_inheader 0
# -- Automatically detect if this is a 3 way diff.
#
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 4/8] git-gui: there is no "mode *" diff header line
From: Bert Wesarg @ 2010-12-09 20:47 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, git, Bert Wesarg
In-Reply-To: <babc4fe91e54e3923baa6f08cc92ee8ea494e704.1291927657.git.bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/diff.tcl | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index aa30089..20f50dd 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -417,8 +417,7 @@ proc read_diff {fd conflict_size cont_info} {
#
if {[string match {@@@ *} $line]} {set is_3way_diff 1}
- if {[string match {mode *} $line]
- || [string match {new file *} $line]
+ if {[string match {new file *} $line]
|| [regexp {^(old|new) mode *} $line]
|| [string match {deleted file *} $line]
|| [string match {deleted symlink} $line]
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 3/8] git-gui: name also new symlinks so
From: Bert Wesarg @ 2010-12-09 20:47 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, git, Bert Wesarg
In-Reply-To: <babc4fe91e54e3923baa6f08cc92ee8ea494e704.1291927657.git.bert.wesarg@googlemail.com>
and rename them only in the diff header
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/diff.tcl | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index 0b72924..aa30089 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -406,12 +406,13 @@ proc read_diff {fd conflict_size cont_info} {
|| [string match {index *} $line]} {
continue
}
- }
- if {$line eq {deleted file mode 120000}} {
- set line "deleted symlink"
+ # -- Name it symlink, not 120000
+ # Note, that the original line is in $current_diff_header
+ regsub {^(deleted|new) file mode 120000} $line {\1 symlink} line
}
+
# -- Automatically detect if this is a 3 way diff.
#
if {[string match {@@@ *} $line]} {set is_3way_diff 1}
@@ -421,6 +422,7 @@ proc read_diff {fd conflict_size cont_info} {
|| [regexp {^(old|new) mode *} $line]
|| [string match {deleted file *} $line]
|| [string match {deleted symlink} $line]
+ || [string match {new symlink} $line]
|| [string match {Binary files * and * differ} $line]
|| $line eq {\ No newline at end of file}
|| [regexp {^\* Unmerged path } $line]} {
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 2/8] git-gui: handle index lines only in the diff header
From: Bert Wesarg @ 2010-12-09 20:47 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, git, Bert Wesarg
In-Reply-To: <babc4fe91e54e3923baa6f08cc92ee8ea494e704.1291927657.git.bert.wesarg@googlemail.com>
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/diff.tcl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/diff.tcl b/lib/diff.tcl
index dae6ca6..0b72924 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -402,12 +402,12 @@ proc read_diff {fd conflict_size cont_info} {
|| [string match {diff --cc *} $line]
|| [string match {diff --combined *} $line]
|| [string match {--- *} $line]
- || [string match {+++ *} $line]} {
+ || [string match {+++ *} $line]
+ || [string match {index *} $line]} {
continue
}
}
- if {[string match {index *} $line]} continue
if {$line eq {deleted file mode 120000}} {
set line "deleted symlink"
}
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 3/3] git-gui: learn more type change states
From: Bert Wesarg @ 2010-12-09 20:46 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, Gustaf Hendeby, git, Bert Wesarg
In-Reply-To: <c373e73fb114ebc580c36bc494dc62f80a19ece9.1291927374.git.bert.wesarg@googlemail.com>
Support the following states with type change in git-gui: AT, MT, TD, TM
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
Cc: Gustaf Hendeby <hendeby@isy.liu.se>
---
git-gui.sh | 8 ++++++--
lib/commit.tcl | 6 +++++-
lib/index.tcl | 10 ++++++++--
3 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 3ef9129..f50a5fc 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1993,7 +1993,11 @@ foreach i {
{MD {mc "Staged for commit, missing"}}
{_T {mc "File type changed, not staged"}}
+ {MT {mc "File type changed, old type staged for commit"}}
+ {AT {mc "File type changed, old type staged for commit"}}
{T_ {mc "File type changed, staged"}}
+ {TM {mc "File type change staged, modification not staged"}}
+ {TD {mc "File type change staged, file missing"}}
{_O {mc "Untracked, not staged"}}
{A_ {mc "Staged for commit"}}
@@ -3535,8 +3539,8 @@ proc popup_diff_menu {ctxm ctxmmg ctxmsm x y X Y} {
|| $current_diff_path eq {}
|| {__} eq $state
|| {_O} eq $state
- || {_T} eq $state
- || {T_} eq $state
+ || [string match {?T} $state]
+ || [string match {T?} $state]
|| [has_textconv $current_diff_path]} {
set s disabled
} else {
diff --git a/lib/commit.tcl b/lib/commit.tcl
index 83b3d9d..5ce4687 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -166,7 +166,7 @@ The rescan will be automatically started now.
_? {continue}
A? -
D? -
- T_ -
+ T? -
M? {set files_ready 1}
_U -
U? {
@@ -453,7 +453,11 @@ A rescan will be automatically started now.
}
AM -
AD -
+ AT -
+ TM -
+ TD -
MM -
+ MT -
MD {
set file_states($path) [list \
_[string index $m 1] \
diff --git a/lib/index.tcl b/lib/index.tcl
index e9db0c4..5d7bbf2 100644
--- a/lib/index.tcl
+++ b/lib/index.tcl
@@ -103,8 +103,11 @@ proc write_update_indexinfo {fd pathList totalCnt batch after} {
set s $file_states($path)
switch -glob -- [lindex $s 0] {
A? {set new _O}
- M? {set new _M}
+ MT -
+ TM -
T_ {set new _T}
+ M? {set new _M}
+ TD -
D_ {set new _D}
D? {set new _?}
?? {continue}
@@ -167,7 +170,10 @@ proc write_update_index {fd pathList totalCnt batch after} {
AD {set new __}
?D {set new D_}
_O -
+ AT -
AM {set new A_}
+ TM -
+ MT -
_T {set new T_}
_U -
U? {
@@ -261,7 +267,7 @@ proc unstage_helper {txt paths} {
switch -glob -- [lindex $file_states($path) 0] {
A? -
M? -
- T_ -
+ T? -
D? {
lappend pathList $path
if {$path eq $current_diff_path} {
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 2/3] git-gui: remove 'no such variable' for s error when encounter unknown file states
From: Bert Wesarg @ 2010-12-09 20:46 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, Gustaf Hendeby, git, Bert Wesarg
In-Reply-To: <c373e73fb114ebc580c36bc494dc62f80a19ece9.1291927374.git.bert.wesarg@googlemail.com>
$s will be referenced in the error message. Which was broken since
"git-gui: Automatically update-index all included files before commit"
(bbe3b3b, 2006-11-16).
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
lib/commit.tcl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/lib/commit.tcl b/lib/commit.tcl
index 7f459cd..83b3d9d 100644
--- a/lib/commit.tcl
+++ b/lib/commit.tcl
@@ -161,7 +161,8 @@ The rescan will be automatically started now.
#
set files_ready 0
foreach path [array names file_states] {
- switch -glob -- [lindex $file_states($path) 0] {
+ set s $file_states($path)
+ switch -glob -- [lindex $s 0] {
_? {continue}
A? -
D? -
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* [PATCH 1/3] git-gui: fix typo in image data
From: Bert Wesarg @ 2010-12-09 20:46 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Shawn O. Pearce, Gustaf Hendeby, git, Bert Wesarg
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
---
git-gui.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index c85a53c..3ef9129 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1958,8 +1958,8 @@ static unsigned char file_merge_bits[] = {
} -maskdata $filemask
image create bitmap file_statechange -background white -foreground green -data {
-#define file_merge_width 14
-#define file_merge_height 15
+#define file_statechange_width 14
+#define file_statechange_height 15
static unsigned char file_statechange_bits[] = {
0xfe, 0x01, 0x02, 0x03, 0x02, 0x05, 0x02, 0x09, 0x02, 0x1f, 0x62, 0x10,
0x62, 0x10, 0xba, 0x11, 0xba, 0x11, 0x62, 0x10, 0x62, 0x10, 0x02, 0x10,
--
1.7.3.2.1200.ge4bf6
^ permalink raw reply related
* Re: Tonight's pushout
From: Jonathan Nieder @ 2010-12-09 20:01 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git, Junio C Hamano
In-Reply-To: <idotn7$9o7$1@dough.gmane.org>
Neal Kreitzinger wrote:
> "prerelease freeze" is not in the git-workflows manpage. I'm interested in
> how you-all do this because I use the git-workflows mangpage to help me
> figure out my workflows. Can someone explain?
See http://en.wikipedia.org/wiki/Freeze_(software_engineering)
In git's incarnation of it, presumably the idea is that new features
do not get merged to 'master' (while they still would be merged to
'pu' and perhaps 'next').
See also <http://sites.google.com/site/maintnotes/> for some direct
discussion of the branches used by git.git.
Hope that helps,
Jonathan [1]
[1] Unrelated note: please try to preserve the cc list in replies
(i.e., "reply-to-all-by-mail" rather than "followup").
^ permalink raw reply
* [PATCH] t9143: do not fail when unhandled.log.gz is not created
From: Torsten Bögershausen @ 2010-12-09 19:53 UTC (permalink / raw)
To: normalperson, git; +Cc: tboegi
Do not depend on internal implementation details of svn,
which right now uses perl to create a .gz file.
So this test case will even work in the future,
when svn changes its implementation.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t9143-git-svn-gc.sh | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/t/t9143-git-svn-gc.sh b/t/t9143-git-svn-gc.sh
index 337ea59..4594e1a 100755
--- a/t/t9143-git-svn-gc.sh
+++ b/t/t9143-git-svn-gc.sh
@@ -37,13 +37,11 @@ test_expect_success 'git svn gc runs' 'git svn gc'
test_expect_success 'git svn index removed' '! test -f
.git/svn/refs/remotes/git-svn/index'
-if perl -MCompress::Zlib -e 0 2>/dev/null
+if test -r .git/svn/refs/remotes/git-svn/unhandled.log.gz
then
test_expect_success 'git svn gc produces a valid gzip file' '
gunzip .git/svn/refs/remotes/git-svn/unhandled.log.gz
'
-else
- say "# Perl Compress::Zlib unavailable, skipping gunzip test"
fi
test_expect_success 'git svn gc does not change unhandled.log files' '
--
1.6.6
^ permalink raw reply related
* Re: Push to all repositories
From: Jonathan Nieder @ 2010-12-09 19:52 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Kevin Sheedy, git, Nguyen Thai Ngoc Duy
In-Reply-To: <AANLkTik9CxVD9A-2QEyD_tZiyYoCOitfViWucGCudzh-@mail.gmail.com>
Martin von Zweigbergk wrote:
> However, rather than trying to make Git behave just like ClearCase
> dynamic views (there are many other things to consider than automatic
> updates), I think you would be better off if you actually use
> ClearCase dynamic views instead.
Yes. Or a network filesystem + unionfs. Or a wiki.
The part I did not mention is why git does not work this way out of
the box. It has something to do with the nature of projects it has
been used on traditionally (computer programs that occasionally undergo
global changes in API).
Consider a project in a patches+tarballs workflow. It begins like
this:
1. Acquire a tarball with the version you want to base your work on.
2. Untar.
3. Copy the result to save the current state.
4. Test it.
5. Fix a bug or add a feature.
6. Make a patch with "diff -pruN"
7. Return to step 3.
...
8. Looks good; email out the patches to get some feedback.
Now another person wants to test the patches; so she tries:
1. Acquire a tarball with the version you want to test against.
2. Untar.
3. Apply patches with "patch -p1".
Wait a second --- the patches don't apply! Or worse, they
apply but the result is broken. Okay:
4. Complain to the patch author.
Finally the patch author has more work to do:
9. Acquire a newer tarball, and use either "patch --reject-file"
or rcs "merge" to reconcile the differences. Email out the
result.
The result is a sequence of snapshots that have been _tested_ to work
correctly. Now compare the svn workflow I briefly used at work:
1. svn update
2. hack hack hack
3. svn update
4. hack hack hack
5. svn update
6. hack hack hack
7. send out a patch for feedback
Now another person wants to test the patch. So she tries:
1. svn update
2. Apply patch with "patch -p1".
The result applies okay and works great. So:
8. svn update
9. ... test ...
10. svn commit
Unfortunately, the version committed (1) does not reflect the
development history and (2) is not even tested, if changes
happened in trunk between step 9 and step 10.
That is, letting projects briefly diverge from upstream
- avoids unnecessary interruptions to work;
- allows the development history to be published, even when that was
"first write some code, then tweak it to match the new API";
- increases the likelihood that each commited revision actually
works, making later mining for the code that introduced a feature
or bug ("git bisect") much easier.
Of course in the opposite direction is
- changes to workflow can be hard for a team to adjust to
(i.e., "don't fix what isn't broken").
Sorry, that ended up more longwinded than I hoped. Still,
hope that helps.
Regards,
Jonathan
^ permalink raw reply
* Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning
From: Erik Faye-Lund @ 2010-12-09 19:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramsay Jones, Jonathan Nieder, Johannes Sixt, Sebastian Schuberth,
GIT Mailing-list
In-Reply-To: <7vmxoeg3wp.fsf@alter.siamese.dyndns.org>
On Thu, Dec 9, 2010 at 8:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
>
>> Junio, could you please drop patches 5-14 from the series; the first four patches
>> are the important ones and I'd rather they didn't get held up. Thanks!
>
> Have these four patches been Acked by interested parties?
>
> I think I saw 1/N and 2/N acked by Erik and 4/N acked by SSchuberth and
> J6t, but any words on 3/N?
>
> Not that I deeply care nor have environment to test changes to [3/N], but
> I am wondering if these need conditional definition to futureproof (e.g.
> what happens when the header you are using the definition _I64_MIN from,
> or some other headers, started defining these constats?).
I'm not sure if I follow this entirely. _I64_MIN is defined by
limits.h on Windows, and limits.h has a header-guard (or "#pragma
once" as Microsoft-code tends to prefer).
Oh, right. You mean if someone else starts defining INTMAX_MAX etc? If
someone includes an stdint/inttypes-implementation while including
git-compat-util.h, we're going to have a boat-load of similar issues
anyway. I think guarding them is something that's better left to when
we encounter the problem (if ever).
All in all, patch 1 though 4 looks good to me. And thanks to Ramsay
for cleaning up my mess :)
^ permalink raw reply
* Re: [PATCH 03/14] msvc: Fix build by adding missing INTMAX_MAX define
From: Erik Faye-Lund @ 2010-12-09 19:19 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, Johannes Sixt, GIT Mailing-list
In-Reply-To: <4CFA8F1A.3040402@ramsay1.demon.co.uk>
On Sat, Dec 4, 2010 at 7:57 PM, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>
> Commit c03c831 (do not depend on signed integer overflow,
> 05-10-2010) provokes an msvc build failure. The cause of the
> failure is a missing definition of the INTMAX_MAX constant,
> used in the new maximum_signed_value_of_type(a) macro, which
> would normally be defined in the C99 <stdint.h> header file.
>
> In order the fix the compilation error, we add an appropriate
> definition of the INTMAX_MAX constant, along with INTMAX_MIN
> and UINTMAX_MAX, to an msvc compat header file.
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
> compat/vcbuild/include/unistd.h | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/compat/vcbuild/include/unistd.h b/compat/vcbuild/include/unistd.h
> index 2a4f276..b14fcf9 100644
> --- a/compat/vcbuild/include/unistd.h
> +++ b/compat/vcbuild/include/unistd.h
> @@ -45,6 +45,10 @@ typedef unsigned long long uintmax_t;
>
> typedef int64_t off64_t;
>
> +#define INTMAX_MIN _I64_MIN
> +#define INTMAX_MAX _I64_MAX
> +#define UINTMAX_MAX _UI64_MAX
> +
> #define STDOUT_FILENO 1
> #define STDERR_FILENO 2
>
Looks good. You only really need to define INTMAX_MAX, but INTMAX_MIN
and UINTMAX_MAX are nice additions for future code. I guess you
*could* have added UINTMAX_MIN for completeness, but I doubt anyone
will ever bother to use it, as it's always 0. So for what it's worth:
Acked-by: Erik Faye-Lund <kusmabite@gmail.com>
In case someone is curious of the definitions; they are documented at
http://msdn.microsoft.com/en-us/library/k15zsh48.aspx
^ permalink raw reply
* Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning
From: Junio C Hamano @ 2010-12-09 19:08 UTC (permalink / raw)
To: Ramsay Jones
Cc: Jonathan Nieder, Johannes Sixt, Erik Faye-Lund,
Sebastian Schuberth, GIT Mailing-list
In-Reply-To: <4D011D30.4070405@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Junio, could you please drop patches 5-14 from the series; the first four patches
> are the important ones and I'd rather they didn't get held up. Thanks!
Have these four patches been Acked by interested parties?
I think I saw 1/N and 2/N acked by Erik and 4/N acked by SSchuberth and
J6t, but any words on 3/N?
Not that I deeply care nor have environment to test changes to [3/N], but
I am wondering if these need conditional definition to futureproof (e.g.
what happens when the header you are using the definition _I64_MIN from,
or some other headers, started defining these constats?).
^ permalink raw reply
* Re: [PATCH 3/3] config: add core.sharedconfig
From: Jonathan Nieder @ 2010-12-09 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vwrnig6gr.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> I originally liked what the first two tried to do, but think about the use
> case. How would this whole thing work?
>
> - The user clones from the project to get a repository with a working
> tree;
>
> - The user somehow learns that s/he can run one command to get
> project-wide preference of the project:
>
> $ git config core.sharedconfig refs/remotes/origin/config:git.config
>
> - Everything hopefully should work the way project wishes in that blob,
> unless the end user later overrides them by adding different settings
> to .git/config.
>
> How is that different from:
>
> - The user clones from the project to get a repository with a working
> tree;
>
> - The user somehow learns that s/he can run one command to get
> project-wide preference of the project:
>
> $ ./setup-project-preference.sh
>
> Typically, such a ./setup-project-preference.sh script would only
> consist of a series of "git config $foo $bar", so any user who can say
> "git config core.sharedconfig $foo" should be able to use it as well.
Wouldn't this ./setup-project-preference.sh have to set up a post-fetch hook
to update the configuration when the project's preferences change?
^ permalink raw reply
* Re: [PATCH 14/14] wt-status.c: Initialise variable to suppress msvc warning
From: Ramsay Jones @ 2010-12-09 18:17 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Johannes Sixt, GIT Mailing-list
In-Reply-To: <20101204205206.GB3170@burratino>
Jonathan Nieder wrote:
>
> Just for the record (I assume you are already aware of this):
>
> http://thread.gmane.org/gmane.comp.version-control.git/133278/focus=133422
> http://thread.gmane.org/gmane.comp.version-control.git/124676/focus=124803
Yes
> I personally feel lukewarm about this kind of change.
OK.
Junio, could you please drop patches 5-14 from the series; the first four patches
are the important ones and I'd rather they didn't get held up. Thanks!
ATB,
Ramsay Jones
^ permalink raw reply
* Re: [PATCH 3/3] config: add core.sharedconfig
From: Junio C Hamano @ 2010-12-09 18:13 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1291907388-9068-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> core.sharedconfig can take anything that resolves to a blob.
> $GIT_DIR/config will override the shared config. Nested shared
> config is not allowed.
>
> No protection is provided. It's up to the project to maintain good
> config. The config could be in a separate branch that only a few
> people are allowed to push, for example. To be safest, just put SHA-1
> there.
>
> git-fsck and git-prune should learn about this key and protect it from
> being pruned.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Hopefully nobody sets core.sharedconfig = :path/to/config or similar
>
> And I should not open $GIT_DIR/config twice. Well, it does not hurt
> much.
That kind of sloppy thinking adds up, though.
> @@ -910,6 +918,12 @@ int git_config(config_fn_t fn, void *data)
>
> repo_config = git_pathdup("config");
> if (!access(repo_config, R_OK)) {
> + git_config_from_file(get_shared_config, repo_config, NULL);
> + if (core_shared_config) {
> + ret += git_config_from_sha1(fn, core_shared_config, data);
> + found += 1;
> + }
> +
What is the point of this "found++" when you will increment it for finding
the repository-local configuration anyway?
> ret += git_config_from_file(fn, repo_config, data);
> found += 1;
> }
I originally liked what the first two tried to do, but think about the use
case. How would this whole thing work?
- The user clones from the project to get a repository with a working
tree;
- The user somehow learns that s/he can run one command to get
project-wide preference of the project:
$ git config core.sharedconfig refs/remotes/origin/config:git.config
- Everything hopefully should work the way project wishes in that blob,
unless the end user later overrides them by adding different settings
to .git/config.
How is that different from:
- The user clones from the project to get a repository with a working
tree;
- The user somehow learns that s/he can run one command to get
project-wide preference of the project:
$ ./setup-project-preference.sh
Typically, such a ./setup-project-preference.sh script would only
consist of a series of "git config $foo $bar", so any user who can say
"git config core.sharedconfig $foo" should be able to use it as well.
- Everything should work the way project wishes with the settings made to
.git/config by the script, unless the end user later overrides them by
modifying settings in .git/config.
One minor difference is that some configuration variables are additive,
and you cannot subtract from them with your approach.
^ permalink raw reply
* Re: file names
From: Thiago Farina @ 2010-12-09 18:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v39q6hm14.fsf@alter.siamese.dyndns.org>
On Thu, Dec 9, 2010 at 3:51 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
>> So it seems from this data, there is a preference for naming files
>> using dash over underline.
>
> Yes.
>
>> So the question is, should the files using underline be converted to
>> use dash instead?
>
> If this were before v1.0.0, it might have made some sense, but not at this
> moment. So the answer to "should?" (or "could?") is a firm "no", which is
> always different from the answer to "wouldn't it have been nicer if they
> were named differently?"
>
Right.
What about documenting it? Is it worth, but only on version 1.8.0?
^ permalink raw reply
* Re: Intermittent failures in t9119
From: Eric Wong @ 2010-12-09 17:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David D. Kilzer, git
In-Reply-To: <7vd3pesb99.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> > Junio C Hamano <gitster@pobox.com> wrote:
> >> (2) Nobody uses the value from "Text Last Updated" field in practice, so
> >> that bug has been unnoticed so far;
> >>
> >> (3) And it is not worth fixing it ;-)
> >>
> >> For now, I would suggest fixing the failing test to ignore the "Text Last
> >> Updated" field while comparing, and if somebody is inclined to, we would
> >> update the code to match what "svn info" does.
> >
> > Agreed on both points. I consider "git svn log" and "git svn info" to
> > be reasonable approximations of svn behavior, not exact replicas.
> > Exactly matching would be extremely difficult given variations between
> > different svn versions, and also svn requiring network access while
> > git svn does not.
>
> Ok, here is a minimum patch to do that.
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks, Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: file names
From: Junio C Hamano @ 2010-12-09 17:51 UTC (permalink / raw)
To: Thiago Farina; +Cc: Git Mailing List
In-Reply-To: <AANLkTikeAFj68Rr35gcf4dxXXHU+au9wA7wd+-WB3BSS@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> So it seems from this data, there is a preference for naming files
> using dash over underline.
Yes.
> So the question is, should the files using underline be converted to
> use dash instead?
If this were before v1.0.0, it might have made some sense, but not at this
moment. So the answer to "should?" (or "could?") is a firm "no", which is
always different from the answer to "wouldn't it have been nicer if they
were named differently?"
Or just after a large version bump (say 1.8.0), perhaps.
^ 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