* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Junio C Hamano @ 2009-01-26 21:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin
In-Reply-To: <7veiyp4w2m.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thomas Rast <trast@student.ethz.ch> writes:
> ...
>> +sed 's/#/ /g' > expect-conflict-p <<'EOF'
>> +* Merge branch 'third' into other
>> +|\##
>> +| * 6
>> +* | Merge branch 'side' into other
>> +|\ \##
>> +| * | 5
>> +* | | 4
>> +|/ /##
>> +* | 3
>> +|/##
>> +* conflict
>> +* 2
>> +* 1
>> +EOF
>
> I do not like this very much. Future improvements of the graph drawing
> algorithm (one obvious "flaw" you are exposing by the above is that it has
> trailing whitespaces that can be trimmed, and somebody else may be
> inclined to fix) would break the expectation this test vector has.
>
> Do you have to compare the topology this way, or are there other more
> reliable ways?
Perhaps something like this.
t/t3412-rebase-root.sh | 36 +++++++++++++++++++++---------------
1 files changed, 21 insertions(+), 15 deletions(-)
diff --git i/t/t3412-rebase-root.sh w/t/t3412-rebase-root.sh
index 29bb6d0..2408cf8 100755
--- i/t/t3412-rebase-root.sh
+++ w/t/t3412-rebase-root.sh
@@ -240,19 +240,24 @@ test_expect_success 'rebase -i --root with conflict (second part)' '
'
sed 's/#/ /g' > expect-conflict-p <<'EOF'
-* Merge branch 'third' into other
-|\##
-| * 6
-* | Merge branch 'side' into other
-|\ \##
-| * | 5
-* | | 4
-|/ /##
-* | 3
-|/##
-* conflict
-* 2
-* 1
+commit conflict3 conflict3~1 conflict3^2
+Merge branch 'third' into other
+commit conflict3^2 conflict3~4
+6
+commit conflict3~1 conflict3~2 conflict3~1^2
+Merge branch 'side' into other
+commit conflict3~1^2 conflict3~3
+5
+commit conflict3~2 conflict3~3
+4
+commit conflict3~3 conflict3~4
+3
+commit conflict3~4 conflict3~5
+conflict
+commit conflict3~5 conflict3~6
+2
+commit conflict3~6
+1
EOF
test_expect_success 'rebase -i -p --root with conflict (first part)' '
@@ -268,8 +273,9 @@ test_expect_success 'fix the conflict' '
test_expect_success 'rebase -i -p --root with conflict (second part)' '
git rebase --continue &&
- git log --graph --topo-order --pretty=tformat:"%s" > conflict3 &&
- test_cmp expect-conflict-p conflict3
+ git rev-list --topo-order --parents --pretty="tformat:%s" HEAD |
+ git name-rev --stdin --name-only --refs=refs/heads/conflict3 >out &&
+ test_cmp expect-conflict-p out
'
test_done
^ permalink raw reply related
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Junio C Hamano @ 2009-01-26 22:08 UTC (permalink / raw)
To: Charles Bailey; +Cc: Hannu Koivisto, git, Theodore Tso
In-Reply-To: <7v7i4h4v19.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Charles Bailey <charles@hashpling.org> writes:
>
>> I suspect that the LF endings in the file is due to the fact that in
>> builtin-merge-file.c, the file is opened (fopen) in binary mode
>> ("wb"), but xdl_merge terminates all lines with a raw '\n'.
>>
>> The obvious fix would be to change fopen in builtin-file-merge.c to
>> use "w" instead, but this doesn't work in a number of scenarios. In
>> particular, it is wrong for repositories on windows with core.autocrlf
>> set to false, and would not fix non-windows repositories with
>> core.autocrlf set to true.
>>
>> Currently, I've no idea as to what the solution should be.
>
> "git file-merge" is designed to be a replacement for stock RCS merge, and
> unfortunately it does not call convert_to_working_tree(), nor has any way
> to know for which path it should take the attributes to apply to affect
> what convert_to_working_tree() should do even if it were to call it.
>
> I think we would need a new option to the command that says "pretend this
> is about merging this path, and use the gitattributes specified for it
> when writing out the result."
Perhaps something along this line to teach
$ git merge-file --attribute-path=frotz.c file1 orig_file file2
to merge what happened since orig_file to file2 into file1, and deposit
the result after converting it appropriately for path "frotz.c" obeying
core.autocrlf and gitattribute rules.
I see rerere.c::merge() has the exact same issue, but its breakage is half
hidden by its use of fopen(path, "w"). It should explicitly use
convert_to_working_tree() like this patch does, and write the results out
in binary mode.
builtin-merge-file.c | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git i/builtin-merge-file.c w/builtin-merge-file.c
index 96edb97..61d1092 100644
--- i/builtin-merge-file.c
+++ w/builtin-merge-file.c
@@ -5,7 +5,7 @@
#include "parse-options.h"
static const char *const merge_file_usage[] = {
- "git merge-file [options] [-L name1 [-L orig [-L name2]]] file1 orig_file file2",
+ "git merge-file [options] [-L name1 [-L orig [-L name2]]] [--attribute-path path] file1 orig_file file2",
NULL
};
@@ -30,10 +30,13 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
int merge_level = XDL_MERGE_ZEALOUS_ALNUM;
int merge_style = 0, quiet = 0;
int nongit;
+ char *attribute_path = NULL;
struct option options[] = {
OPT_BOOLEAN('p', "stdout", &to_stdout, "send results to standard output"),
OPT_SET_INT(0, "diff3", &merge_style, "use a diff3 based merge", XDL_MERGE_DIFF3),
+ OPT_STRING('a', "attribute-path", &attribute_path, "path",
+ "apply work-tree conversion for the path"),
OPT__QUIET(&quiet),
OPT_CALLBACK('L', NULL, names, "name",
"set labels for file1/orig_file/file2", &label_cb),
@@ -73,6 +76,19 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
for (i = 0; i < 3; i++)
free(mmfs[i].ptr);
+ if (ret >= 0 && attribute_path) {
+ struct strbuf buf = STRBUF_INIT;
+ ret = convert_to_working_tree(attribute_path,
+ result.ptr, result.size,
+ &buf);
+ free(result.ptr);
+ if (!ret) {
+ size_t len;
+ result.ptr = strbuf_detach(&buf, &len);
+ result.size = len;
+ }
+ }
+
if (ret >= 0) {
const char *filename = argv[0];
FILE *f = to_stdout ? stdout : fopen(filename, "wb");
^ permalink raw reply related
* Re: git 1.6.1 on AIX 5.3
From: Mike Ralphson @ 2009-01-26 22:32 UTC (permalink / raw)
To: Perry Smith; +Cc: git, Jeff King
In-Reply-To: <20090126210027.GG27604@coredump.intra.peff.net>
2009/1/26 Jeff King <peff@peff.net>:
> [cc-ing Mike Ralphson, our local AIX expert]
Bless you!
> On Mon, Jan 26, 2009 at 02:02:15PM -0600, Perry Smith wrote:
>
>> I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build and it
>> does not seem to be set up to do out of tree builds. If that is not
>> true, please let me know.
>>
>> The install process wants to call install with a -d option. AIX has two
>> install programs but they are pretty old -- neither takes a -d option.
>>
>> Is there a GNU install program I can get? I've not been able to locate
>> one.
>
> It's in GNU coreutils:
>
> http://www.gnu.org/software/coreutils/
>
> I don't know what Mike uses to install on AIX; you can see his config
> setup here:
>
> http://repo.or.cz/w/git/gitbuild.git?a=tree;f=mr/aix;hb=platform
>
> but I don't see any override of install.
I've got the AIX Toolbox for Linux applications[1] installed and ahead
of /bin and /usr/bin on my PATH. Beware that some of these don't
function as well as the stock AIX utilities and should normally be
removed. I've posted about this on what is ostensibly a blog but which
is really just a post-it note I'm less likely to lose[2].
Failing that, many programs which are primarily configured using
autoconf will ship with an install shell script which you can co-opt,
some apache stuff does too[3].
Any other questions, don't hesitate to ask.
Mike
[1] http://www-03.ibm.com/systems/power/software/aix/linux/index.html
[2] http://mermade.blogspot.com/2008/04/aix-toolbox.html
[3] http://svn.apache.org/repos/asf/tcl/websh/trunk/src/unix/install-sh
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Perry Smith @ 2009-01-26 22:57 UTC (permalink / raw)
To: Mike Ralphson; +Cc: git, Jeff King
In-Reply-To: <e2b179460901261432r601fa006iaf04fc42487e7235@mail.gmail.com>
On Jan 26, 2009, at 4:32 PM, Mike Ralphson wrote:
> 2009/1/26 Jeff King <peff@peff.net>:
>> [cc-ing Mike Ralphson, our local AIX expert]
>
> Bless you!
>
>> On Mon, Jan 26, 2009 at 02:02:15PM -0600, Perry Smith wrote:
>>
>>> I tried building git 1.6.1 on AIX 5.3 as an "out of tree" build
>>> and it
>>> does not seem to be set up to do out of tree builds. If that is not
>>> true, please let me know.
>>>
>>> The install process wants to call install with a -d option. AIX
>>> has two
>>> install programs but they are pretty old -- neither takes a -d
>>> option.
>>>
>>> Is there a GNU install program I can get? I've not been able to
>>> locate
>>> one.
>>
>> It's in GNU coreutils:
>>
>> http://www.gnu.org/software/coreutils/
>>
>> I don't know what Mike uses to install on AIX; you can see his config
>> setup here:
>>
>> http://repo.or.cz/w/git/gitbuild.git?a=tree;f=mr/aix;hb=platform
>>
>> but I don't see any override of install.
>
> I've got the AIX Toolbox for Linux applications[1] installed and ahead
> of /bin and /usr/bin on my PATH. Beware that some of these don't
> function as well as the stock AIX utilities and should normally be
> removed. I've posted about this on what is ostensibly a blog but which
> is really just a post-it note I'm less likely to lose[2].
>
> Failing that, many programs which are primarily configured using
> autoconf will ship with an install shell script which you can co-opt,
> some apache stuff does too[3].
>
> Any other questions, don't hesitate to ask.
>
> Mike
>
> [1] http://www-03.ibm.com/systems/power/software/aix/linux/index.html
>
> [2] http://mermade.blogspot.com/2008/04/aix-toolbox.html
>
> [3] http://svn.apache.org/repos/asf/tcl/websh/trunk/src/unix/install-
> sh
Thanks guys. I picked up coreutils version 7. I didn't
install them but just moved ginstall over to /usr/local/bin.
A few other comments: I had to add in the --without-tcltk flag. I
don't have
tcl installed but the config did not autodetect that it was not present.
I can't tell if make test is happy or not. The output looks like its
happy
but the exit code is 2.
Below is my "configure" script if anyone is interested.
#!/usr/bin/env bash
export CONFIG_SHELL=/usr/local/bin/bash
export LDFLAGS='-L/usr/local/lib -L/usr/local/ssl/lib'
export CFLAGS='-I/usr/local/include -I/usr/local/ssl/include'
export CC=gcc
echo CONFIG_SHELL set to ${CONFIG_SHELL}
${CONFIG_SHELL} ../../src/git-1.6.1/configure --without-tcltk
#
# Note that to install you need to do:
# make INSTALL=ginstall install
# to use GNU's install program
^ permalink raw reply
* Re: [PATCH] mergetool: respect autocrlf by using checkout-index
From: Junio C Hamano @ 2009-01-26 23:09 UTC (permalink / raw)
To: Charles Bailey; +Cc: Hannu Koivisto, git, Theodore Tso
In-Reply-To: <7vskn53em1.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Perhaps something along this line to teach
>
> $ git merge-file --attribute-path=frotz.c file1 orig_file file2
>
> to merge what happened since orig_file to file2 into file1, and deposit
> the result after converting it appropriately for path "frotz.c" obeying
> core.autocrlf and gitattribute rules.
>
> I see rerere.c::merge() has the exact same issue, but its breakage is half
> hidden by its use of fopen(path, "w"). It should explicitly use
> convert_to_working_tree() like this patch does, and write the results out
> in binary mode.
Second try. I forgot how convert_* worked X-<.
builtin-merge-file.c | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git i/builtin-merge-file.c w/builtin-merge-file.c
index 96edb97..edee815 100644
--- i/builtin-merge-file.c
+++ w/builtin-merge-file.c
@@ -5,7 +5,7 @@
#include "parse-options.h"
static const char *const merge_file_usage[] = {
- "git merge-file [options] [-L name1 [-L orig [-L name2]]] file1 orig_file file2",
+ "git merge-file [options] [-L name1 [-L orig [-L name2]]] [--attribute-path path] file1 orig_file file2",
NULL
};
@@ -30,10 +30,13 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
int merge_level = XDL_MERGE_ZEALOUS_ALNUM;
int merge_style = 0, quiet = 0;
int nongit;
+ char *attribute_path = NULL;
struct option options[] = {
OPT_BOOLEAN('p', "stdout", &to_stdout, "send results to standard output"),
OPT_SET_INT(0, "diff3", &merge_style, "use a diff3 based merge", XDL_MERGE_DIFF3),
+ OPT_STRING('a', "attribute-path", &attribute_path, "path",
+ "apply work-tree conversion for the path"),
OPT__QUIET(&quiet),
OPT_CALLBACK('L', NULL, names, "name",
"set labels for file1/orig_file/file2", &label_cb),
@@ -73,6 +76,21 @@ int cmd_merge_file(int argc, const char **argv, const char *prefix)
for (i = 0; i < 3; i++)
free(mmfs[i].ptr);
+ if (ret >= 0 && attribute_path) {
+ struct strbuf buf = STRBUF_INIT;
+ int st;
+ st = convert_to_working_tree(attribute_path,
+ result.ptr, result.size,
+ &buf);
+ if (st) {
+ size_t len;
+
+ free(result.ptr);
+ result.ptr = strbuf_detach(&buf, &len);
+ result.size = len;
+ }
+ }
+
if (ret >= 0) {
const char *filename = argv[0];
FILE *f = to_stdout ? stdout : fopen(filename, "wb");
^ permalink raw reply related
* Re: [PATCH v2] Change octal literals to be XEmacs friendly
From: Alexandre Julliard @ 2009-01-26 22:59 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: git
In-Reply-To: <874ozp79y4.fsf@Astalo.kon.iki.fi>
Kalle Olavi Niemitalo <kon@iki.fi> writes:
> Vassili Karpov <av1474@comtv.ru> writes:
>
>> #ooctal syntax on the other hand produces integers everywhere.
>
> GNU Emacs 20.7 doesn't support #o, but neither does it include
> the ewoc and log-edit libraries required by the current git.el.
>
> It would be nice to have a comment in git.el saying which
> versions of Emacs and XEmacs it is supposed to support, but I
> guess people wouldn't bother testing those on every commit.
I try to make sure that it still works with Emacs 21, but for older
versions you're on your own. Of course if you find problems patches are
welcome...
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* Re: [PATCH] rebase -i: correctly remember --root flag across --continue
From: Junio C Hamano @ 2009-01-27 0:29 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin
In-Reply-To: <200901262228.13104.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> It would certainly be possible to test the SHA1 of the resulting
> branch tip, but t/README says I shouldn't.
Correct. The test should convert the SHA-1 back to some symbolic form
that is stable for comparison.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Boyd Stephen Smith Jr. @ 2009-01-27 1:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200901212321.50526.bss@iguanasuicide.net>
[-- Attachment #1: Type: text/plain, Size: 951 bytes --]
On Wednesday 21 January 2009, "Boyd Stephen Smith Jr."
<bss@iguanasuicide.net> wrote about 'Re: What's cooking in git.git (Jan
2009, #05; Wed, 21)':
>On Wednesday 21 January 2009, Junio C Hamano <gitster@pobox.com> wrote
>about 'What's cooking in git.git (Jan 2009, #05; Wed, 21)':
>>* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
>>
>>It would be nice to hear a real world success story using the notes
>>mechanism before casting this design in stone.
>
>I'll see if I can't try to put this through some paces over the week.
Yeah, that's not gonna happen. I still want to play with this some, but
that's being pushed to the background, so I can't say when I'll really get
time to test it.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v1 0/3] Introduce config variable "diff.primer"
From: Keith Cascio @ 2009-01-27 1:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090125220756.GA18855@coredump.intra.peff.net>
On Sun, 25 Jan 2009, Jeff King wrote:
> let's say I have a gitattributes file like this:
> *.c diff=c
> and my config says:
> [diff]
> opt1 = val1_default
> opt2 = val2_default
> [diff "c"]
> opt1 = val1_c
>
> Now obviously if I want to use opt1 for my C files, it should be val1_c.
> But if I want to use opt2, what should it use? There are two reasonable
> choices, I think:
> 1. You use val2_default. The rationale is that the "c" diff driver did
> not define an opt2, so you fall back to the global default.
> 2. It is unset. The rationale is that you are using the "c" diff
> driver, and it has left the value unset. The default then means "if
> you have no diff driver setup".
I'm in favor of option (2), because [diff] a.k.a [diff ""] serving as the
fallback for [diff *] feels like a special case. If a full system of precedence
and fallbacks is desired for .git/config, we should adopt explicit grammar that
lets me define an arbitrary precedence tree over all sections. Once a powerful
concept is born, somewhere down the road, some user will desire its
universalization.
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort
From: Theodore Tso @ 2009-01-26 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Caleb Cushing, Charles Bailey, git
In-Reply-To: <7vwscmue5z.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 23, 2009 at 09:26:32AM -0800, Junio C Hamano wrote:
> Caleb Cushing <xenoterracide@gmail.com> writes:
>
> > so does my patch satisfy now? what's it take to get it included in the
> > next version of git?
>
> I do not use mergetool myself so I generally do not pay attention to
> patches on this tool, but I would want to pick up ones that people
> involved in mergetool discussion can agree to be good patches.
>
> There are a few mergetool updates in flight from various authors. How
> does your submission compare with others' in both form/presentation and
> clarity of logic (remember, I am not keeping track)?
I was the original author of mergetool, and for a while I was the
person that was reviewing and managing the mergetool patches for
Junio. Unfortunately, in the last couple of months I just haven't had
the time keep up with the various mergetool proposed patch updates.
So maybe it's time for me to hand it off to someone who has the time
and interest in continuing to hack mergetool, and has the necessary
"good taste" and such that Junio would be willing to trust that person
to be the git mergetool patch wrangler?
- Ted
^ permalink raw reply
* Valgrind updates
From: Johannes Schindelin @ 2009-01-27 2:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901212259420.3586@pacific.mpi-cbg.de>
Hi,
it is real late now, so I am uncomfortable sending off a new patch series
(I _know_ that I'll just introduce a stupid bug or forget to write a
commit message or whatever). In case you are interested in the current
progress, you know where my branches are.
The changes I made:
- added t/valgrind/templates to t/.gitignore, too,
- split out the valgrind-unrelated parts that Peff complained about,
- added some more suppressions I needed,
- added a mode whereby the tests' results are written to test-results/,
- provided a Makefile target for further convenience,
- added a script to coalesce the valgrind results by backtrace,
- split out a patch that lets --valgrind imply --verbose, and
- ran the scripts several times, which is a PITA because one run takes 5.5
hours (and the first time I forgot to redirect stderr, ouch, thus the
test-results/ patch).
I have an output from a previous full run, albeit it was done with an
earlier version of the valgrind patch series I was not comfortable with,
so I will not send it here. Besides, it is 300K (bzip2 -9 reduces that to
20K), and I am sure you don't want to have it.
Just that much, most of the backtraces are pretty repetitive. In fact, I
think most if not all of them touch xwrite.c (I got other errors from my
patches, as I expected).
==valgrind== Syscall param write(buf) points to uninitialised byte(s)
==valgrind== at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
==valgrind== by 0x4D0380: xwrite (wrapper.c:129)
==valgrind== by 0x4D046E: write_in_full (wrapper.c:159)
==valgrind== by 0x4C0697: write_buffer (sha1_file.c:2275)
==valgrind== by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
==valgrind== by 0x4C0C4F: write_sha1_file (sha1_file.c:2418)
==valgrind== by 0x46DBB8: update_one (cache-tree.c:348)
==valgrind== by 0x46D8CF: update_one (cache-tree.c:282)
==valgrind== by 0x46DCCA: cache_tree_update (cache-tree.c:373)
==valgrind== by 0x46E2B5: write_cache_as_tree (cache-tree.c:562)
==valgrind== by 0x4662D4: cmd_write_tree (builtin-write-tree.c:36)
==valgrind== by 0x404F37: run_command (git.c:243)
==valgrind== Address 0x713dc23 is 51 bytes inside a block of size 195 alloc'd
==valgrind== at 0x4C2273B: malloc (in /usr/local/lib/valgrind/amd64-linux/vgpreload_memcheck.so)
==valgrind== by 0x4CFFCC: xmalloc (wrapper.c:20)
==valgrind== by 0x4C0A33: write_loose_object (sha1_file.c:2362)
==valgrind== by 0x4C0C4F: write_sha1_file (sha1_file.c:2418)
==valgrind== by 0x46DBB8: update_one (cache-tree.c:348)
==valgrind== by 0x46D8CF: update_one (cache-tree.c:282)
==valgrind== by 0x46DCCA: cache_tree_update (cache-tree.c:373)
==valgrind== by 0x46E2B5: write_cache_as_tree (cache-tree.c:562)
==valgrind== by 0x4662D4: cmd_write_tree (builtin-write-tree.c:36)
==valgrind== by 0x404F37: run_command (git.c:243)
==valgrind== by 0x4050E4: handle_internal_command (git.c:387)
==valgrind== by 0x4051CA: run_argv (git.c:425)
which can be reproduced by running t0000-basic.out in valgrind mode.
Good night, Vietnam,
Dscho
^ permalink raw reply
* Re: backwards compatibility, was Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
From: Keith Cascio @ 2009-01-27 3:01 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090126115957.GA20558@coredump.intra.peff.net>
On Mon, 26 Jan 2009, Jeff King wrote:
> Yep, that's what defaults are. And guess what: we _already_ have the same
> thing. I have diff.renames set in my ~/.gitconfig. That does _exactly_ what
>
> git config --global diff.primer -M
>
> would do. It's just a syntax that saves us from having to introduce a boatload
> of new variables, one per command line option.
Great point, IOW, primer magnifies already existing pitfalls. I like that about
primer v1, however unsatisfying it is otherwise. Rather than stick a piece of
chewing gum in that chink in the dam, let's repair it and get the whole darn
thing ready for the 21st century while we're at it.
> However, there are two other drawbacks of aliases that I can think of:
> 1. They are tied to a specific command, whereas diff options are tied
> to the concept of diffing. So now I have to write an alias (with a
> new name) for each command:
> git config alias.mylog 'log -w'
> git config alias.mydiff 'diff -w'
> git config alias.myshow 'show -w'
> 2. They can't change defaults based on the file to be diffed. One of
> the things Keith mentioned (and I don't remember if this was
> implemented in his patch series) was supporting this for
> gitattributes diff drivers. How do I do
> git config diff.tex.primer -w
> using aliases?
This scenario was specifically part of my motivation for imagining primer v1 as
I did.
> But now you have me defending Keith's proposal
And well.
> which he should be doing himself ;P
True. I'm at the point here where I will demand of myself one of two outcomes.
Either I:
(1) Satisfy myself on a deep, foundational level why the inescapable structure
of not just this particularly well-constituted software project (Git!), but
software projects in general, since surely many a fearless development team has
braved this philosophical sticky place before us, prevents one from getting
everything one wants, i.e. forces a compromise, a.k.a. the "no silver bullet"
interpretation.
(2) Write primer patch v2 that somehow does THE RIGHT THING, also satisfying on
a deep level to at least myself, a.k.a. the silver bullet.
-- Keith
^ permalink raw reply
* Re: Valgrind updates
From: Linus Torvalds @ 2009-01-27 3:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901270327200.26199@intel-tinevez-2-302>
On Tue, 27 Jan 2009, Johannes Schindelin wrote:
>
> Just that much, most of the backtraces are pretty repetitive. In fact, I
> think most if not all of them touch xwrite.c (I got other errors from my
> patches, as I expected).
>
> ==valgrind== Syscall param write(buf) points to uninitialised byte(s)
> ==valgrind== at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
> ==valgrind== by 0x4D0380: xwrite (wrapper.c:129)
> ==valgrind== by 0x4D046E: write_in_full (wrapper.c:159)
> ==valgrind== by 0x4C0697: write_buffer (sha1_file.c:2275)
> ==valgrind== by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
Looks entirely bogus.
I suspect that valgrind for some reason doesn't see the writes made by
zlib as being initialization, possibly due to some incorrect valgrind
annotations on deflate(). We've just totally initialized that whole
buffer with deflate().
It definitely does not look like a git bug, but a valgrind run issue.
Linus
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Jeff King @ 2009-01-27 3:52 UTC (permalink / raw)
To: Perry Smith; +Cc: Mike Ralphson, git
In-Reply-To: <9E98493A-B17A-4905-8BEA-3E0B837961D6@gmail.com>
On Mon, Jan 26, 2009 at 04:57:16PM -0600, Perry Smith wrote:
> A few other comments: I had to add in the --without-tcltk flag. I
> don't have tcl installed but the config did not autodetect that it was
> not present.
Hmm. It looks like we respect --with[out]-tcltk, and without it we
always say "just use wish from the PATH" without detecting whether it
actually exists:
# No Tcl/Tk switches given. Do not check for Tcl/Tk, use bare
# 'wish'.
TCLTK_PATH=wish
AC_SUBST(TCLTK_PATH)
I'm sure the fix would be something along the lines of
if which wish; then
TCLTK_PATH=wish
else
NO_TCLTK=yes
fi
but I know for fact that is not portable and that there must be some
special autoconf way of doing the same thing.
> I can't tell if make test is happy or not. The output looks like its
> happy but the exit code is 2.
That doesn't sound very happy. You should see either a "command failed"
error from make, or some results like:
'/bin/sh' ./aggregate-results.sh test-results/t*-*
fixed 1
success 4026
failed 0
broken 3
total 4030
where "broken" is OK (it is a test that is marked as "we know this is
broken currently, but ideally it would be fixed in the future") but
"failed" is a problem.
But I believe unless you are using "make -k", that it won't even
aggregate the results if something fails, and you should just see make
complaining about the failed test script.
-Peff
^ permalink raw reply
* connecting existing local git repository to svn
From: Ittay Dror @ 2009-01-27 4:10 UTC (permalink / raw)
To: git
Hi,
I'd like to create a branch in a subversion repository so that I can
work with git-svn on it.
My git repository is already with a history, that I don't want to
replicate to subversion, I want to start with subversion having just the
latest revision and then continue from there normally (git svn
dcommit/rebase).
How can I do that?
Thanks,
Ittay
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-27 4:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0901261934450.3123@localhost.localdomain>
Hi,
On Mon, 26 Jan 2009, Linus Torvalds wrote:
> On Tue, 27 Jan 2009, Johannes Schindelin wrote:
> >
> > Just that much, most of the backtraces are pretty repetitive. In
> > fact, I think most if not all of them touch xwrite.c (I got other
> > errors from my patches, as I expected).
> >
> > ==valgrind== Syscall param write(buf) points to uninitialised byte(s)
> > ==valgrind== at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
> > ==valgrind== by 0x4D0380: xwrite (wrapper.c:129)
> > ==valgrind== by 0x4D046E: write_in_full (wrapper.c:159)
> > ==valgrind== by 0x4C0697: write_buffer (sha1_file.c:2275)
> > ==valgrind== by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
>
> Looks entirely bogus.
And it gets worse.
I suspected that zlib does something "cute" with alignments, i.e. that it
writes a possibly odd number of bytes, but then rounds up the buffer to
the next multiple of two of four bytes.
Yet, the buffer in question is 195 bytes, stream.total_count (which
totally agrees with size - stream.avail_out) says it is 58 bytes, and
valgrind says that the byte with offset 51 is uninitialized.
So it is definitely a zlib error. And a strange one at that. Even
allowing for a header, if we have 51 valid bytes in the buffer (remember:
the 52nd byte is reported uninitialized by valgrind), even on a 64-bit
machine, it should not be rounded up to 58 bytes reported by zlib. And
the address of the buffer seems to be even 16-byte aligned (that's
probably valgrind's doing).
Just for bullocks, I let valgrind check if offset 51 is the only
uninitialized byte (who knows what zlib is thinking that it's doing?), and
here's the rub: offset 51 is indeed the _only_ one which valgrind thinks
is uninitialized!
Wasn't there some zlib wizard in the kernel community? We could throw
that thing at him, to see why it behaves so strangely...
Of course, it could also be a valgrind issue, as you suggested. Hmpf.
Ciao,
Dscho
^ permalink raw reply
* Re: Valgrind updates
From: Johannes Schindelin @ 2009-01-27 4:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901270512171.14855@racer>
Hi,
On Tue, 27 Jan 2009, Johannes Schindelin wrote:
> On Mon, 26 Jan 2009, Linus Torvalds wrote:
>
> > On Tue, 27 Jan 2009, Johannes Schindelin wrote:
> > >
> > > Just that much, most of the backtraces are pretty repetitive. In
> > > fact, I think most if not all of them touch xwrite.c (I got other
> > > errors from my patches, as I expected).
> > >
> > > ==valgrind== Syscall param write(buf) points to uninitialised byte(s)
> > > ==valgrind== at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
> > > ==valgrind== by 0x4D0380: xwrite (wrapper.c:129)
> > > ==valgrind== by 0x4D046E: write_in_full (wrapper.c:159)
> > > ==valgrind== by 0x4C0697: write_buffer (sha1_file.c:2275)
> > > ==valgrind== by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
> >
> > Looks entirely bogus.
>
> And it gets worse.
>
> I suspected that zlib does something "cute" with alignments, i.e. that
> it writes a possibly odd number of bytes, but then rounds up the buffer
> to the next multiple of two of four bytes.
>
> Yet, the buffer in question is 195 bytes, stream.total_count (which
> totally agrees with size - stream.avail_out) says it is 58 bytes, and
> valgrind says that the byte with offset 51 is uninitialized.
>
> So it is definitely a zlib error. And a strange one at that. Even
> allowing for a header, if we have 51 valid bytes in the buffer
> (remember: the 52nd byte is reported uninitialized by valgrind), even on
> a 64-bit machine, it should not be rounded up to 58 bytes reported by
> zlib. And the address of the buffer seems to be even 16-byte aligned
> (that's probably valgrind's doing).
>
> Just for bullocks, I let valgrind check if offset 51 is the only
> uninitialized byte (who knows what zlib is thinking that it's doing?),
> and here's the rub: offset 51 is indeed the _only_ one which valgrind
> thinks is uninitialized!
>
> Wasn't there some zlib wizard in the kernel community? We could throw
> that thing at him, to see why it behaves so strangely...
>
> Of course, it could also be a valgrind issue, as you suggested. Hmpf.
FWIW this test was done with 3.4.0.SVN.
Just to be sure, I upgraded to 3.5.0.SVN, the very newest update (well, as
new as I could make my git svn mirror of valgrind and VEX deliver). Still
there.
Off to bed,
Dscho
^ permalink raw reply
* Re: Valgrind updates
From: Jeff King @ 2009-01-27 4:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0901261934450.3123@localhost.localdomain>
On Mon, Jan 26, 2009 at 07:38:56PM -0800, Linus Torvalds wrote:
> > ==valgrind== Syscall param write(buf) points to uninitialised byte(s)
> > ==valgrind== at 0x5609E40: __write_nocancel (in /lib/libpthread-2.6.1.so)
> > ==valgrind== by 0x4D0380: xwrite (wrapper.c:129)
> > ==valgrind== by 0x4D046E: write_in_full (wrapper.c:159)
> > ==valgrind== by 0x4C0697: write_buffer (sha1_file.c:2275)
> > ==valgrind== by 0x4C0B1C: write_loose_object (sha1_file.c:2387)
>
> Looks entirely bogus.
>
> I suspect that valgrind for some reason doesn't see the writes made by
> zlib as being initialization, possibly due to some incorrect valgrind
> annotations on deflate(). We've just totally initialized that whole
> buffer with deflate().
>
> It definitely does not look like a git bug, but a valgrind run issue.
Yes, this is exactly the issue I ran into when doing the valgrind stuff
a few months ago. I spent several hours looking carefully at the code
and came to the same conclusion. Anything zlib touches needs to be
manually suppressed for uninitialized writes (which I _thought_ was
covered in the suppressions I sent out originally, but maybe they need
to be tweaked for Dscho's system).
-Peff
^ permalink raw reply
* how to see full file with diff marks
From: Ittay Dror @ 2009-01-27 4:51 UTC (permalink / raw)
To: Git Mailing List
Hi,
I have a large file and I want to view the changes between two commits,
but in the context of the whole file, not just hunks. How can I do that?
Thanks
Ittay
^ permalink raw reply
* Re: [PATCH v1 0/3] Introduce config variable "diff.primer"
From: Jeff King @ 2009-01-27 4:54 UTC (permalink / raw)
To: Keith Cascio; +Cc: git
In-Reply-To: <alpine.GSO.2.00.0901261734360.16158@kiwi.cs.ucla.edu>
On Mon, Jan 26, 2009 at 05:47:54PM -0800, Keith Cascio wrote:
> > 2. It is unset. The rationale is that you are using the "c" diff
> > driver, and it has left the value unset. The default then means "if
> > you have no diff driver setup".
>
> I'm in favor of option (2), because [diff] a.k.a [diff ""] serving as
Nit: [diff] and [diff ""] are different. The "dotted" notation which we
use in the code and which git-config respects for a variable "foo" in
each section would look like "diff.foo" and "diff..foo", respectively.
> the fallback for [diff *] feels like a special case. If a full system
> of precedence
Yes, I think having a "this is the default driver whose driver-specific
options are used if you don't have a different driver" is semantically
simple and clear.
> and fallbacks is desired for .git/config, we should adopt explicit
> grammar that lets me define an arbitrary precedence tree over all
> sections. Once a powerful concept is born, somewhere down the road,
> some user will desire its universalization.
OK, now you're scaring me. :) I'm not sure I want to see the grammar you
would use to define an arbitrary precedence tree, or whether such
complexity has any real-world use in git config. I think you would have
to show a concrete example to prove the utility of something like that.
-Peff
^ permalink raw reply
* Re: how to see full file with diff marks
From: Jeff King @ 2009-01-27 4:57 UTC (permalink / raw)
To: Ittay Dror; +Cc: Git Mailing List
In-Reply-To: <497E92C1.80102@gmail.com>
On Tue, Jan 27, 2009 at 06:51:13AM +0200, Ittay Dror wrote:
> I have a large file and I want to view the changes between two commits,
> but in the context of the whole file, not just hunks. How can I do that?
git diff -U9999999 ?
-Peff
^ permalink raw reply
* Re: [PATCH] http-push: refactor request url creation
From: Junio C Hamano @ 2009-01-27 4:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ray Chuan, git
In-Reply-To: <alpine.DEB.1.00.0901261141070.14855@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> curl strdup's it, so this is safe.
>
> I might have mentioned that things like this _need_ to go into the commit
> message.
Yeah, and let's not forget advice from Daniel Stenberg.
I'm not sure what the oldest possibly libcurl version git can deal
with, but here's a related quote from the curl_easy_setopt man page:
NOTE: before 7.17.0 strings were not copied. Instead the user was
forced keep them available until libcurl no longer needed them.
^ permalink raw reply
* Re: how to see full file with diff marks
From: David Aguilar @ 2009-01-27 5:42 UTC (permalink / raw)
To: Ittay Dror; +Cc: Git Mailing List
In-Reply-To: <497E92C1.80102@gmail.com>
On 0, Ittay Dror <ittay.dror@gmail.com> wrote:
> Hi,
>
> I have a large file and I want to view the changes between two commits,
> but in the context of the whole file, not just hunks. How can I do that?
>
> Thanks
> Ittay
In git.git's contrib/difftool directory there's a script
called 'git-difftool' that can show you changes using our
good friends xxdiff, kdiff3, tkdiff, meld, vimdiff, emerge,
etc.
--
David
^ permalink raw reply
* Re: [topgit] shared topic branch
From: martin f krafft @ 2009-01-26 12:00 UTC (permalink / raw)
To: Fabien Thomas, git
In-Reply-To: <EFB70468-7900-4B22-925D-3FC5F05F951B@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]
also sprach Fabien Thomas <thomas.fabien@gmail.com> [2008.12.18.2102 +0100]:
> I'm testing topgit 0.5 in a shared env. (multiple user working on same
> patch).
Sorry for the late reply!
> My problem is that when i want to push my local work i'm doing
> "git push" that will force update the remote branch. The problem
> is that each time master is not up to date i will push my entire
> master or topic branch to the remote.
I do not understand what you mean. Could yo please try to give us
more detail? git push is intended to push all local changes to the
remote, so I don't understand what your problem is.
> [remote "origin"]
[...]
> push = +refs/top-bases/*:refs/top-bases/*
> push = +refs/heads/*:refs/heads/*
Those two lines ensure that git pushes all local heads as well as
all top-bases.
--
martin | http://madduck.net/ | http://two.sentenc.es/
it may look like i'm just sitting here doing nothing.
but i'm really actively waiting
for all my problems to go away.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 08/10] run test suite without dashed git-commands in PATH
From: Matthew Ogilvie @ 2009-01-27 6:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901261201470.14855@racer>
On Mon, Jan 26, 2009 at 12:06:08PM +0100, Johannes Schindelin wrote:
> So maybe I was wrong to assume that this is cvsserver specific, but then,
> you made that mistake rather easy to make.
Yes, in retrospect I probably should have split off patches 6, 7,
8, and maybe 5 (5-7 fix issues that patch 8 exposes in the test suite)
into a separate patch series. When or if a v2 is needed, should
I split them off then?
> > 4. The test-bin-wrapper.sh script does not actually need to set
> > environment variables (GIT_EXEC_DIT and templates) for purposes
> > of this patch. But my thought was that in this form you could
> > run things straight out of the test-bin directory to manually try
> > out new code without needing to actually install a build or mess
> > with the environment variables yourself. It could also be
> > extended to handle other global wrapper needs relatively easily,
> > such as valgrind.
>
> Umm.
>
> You missed the valgrind patch series.
Actually, I'm (poorly) alluding to some comments in the original patch
8 email, where I pointed out an expected conflict with the valgrind
patches. To briefly recap, there are at least 3 possible strategies
of resolving such a conflict, and I'm not sure which makes the most
sense: Keep valgrind design, and extend it with limited bindir
support. Keep limited bindir design and extend it with valgrind
support. Or keep both, and have the runtime setup logic make
them mutually exclusive.
--
Matthew Ogilvie [mmogilvi_git@miniinfo.net]
^ 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