* Re: git diff
From: Jeff King @ 2011-01-17 22:30 UTC (permalink / raw)
To: Carter Lamb; +Cc: git
In-Reply-To: <AANLkTik7cfu_DS=GS5gz_Tu94NC=ZGi-eA8YXztyd9Ra@mail.gmail.com>
On Thu, Jan 13, 2011 at 04:46:16PM -0600, Carter Lamb wrote:
> I use git diff --summary --numstat <commit> to report the files
> modified, created, and deleted between the current commit and some
> prior commit. The --stat and --numstat options count the lines added
> and deleted for each file. Is there a way to report the lines modified
> for each file. For example:
Not really, because it's not well defined. Consider your example:
> Given content below for commit 1:
> aaaaa
> ccccc
>
> Given content below for commit 2:
> aaaaa
> bbbbb
> ccccc
>
> Given content below for commit 3:
> Aaaaa
> Bbbbb
> ccccc
> ddddd
How do we know that "Aaaaa" is a modification of line "aaaaa", and not
simply the deletion of the old line and the addition of a new one? It's
easy to come up with a case where that is more obvious:
-aaaaa
+ddddd
but there are many shades of gray in between. Is:
-aaaaa
+Aaada
the deletion of an old line and the introduction of a new one, or the
modification of an existing line? So fundamentally the diff format just
deals with added and removed lines, and modifications are represented as
a delete followed by an add.
Which isn't to say you couldn't think of many clever algorithms for
heuristically determining a modification, but git doesn't do that itself
in numstat.
-Peff
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: JT Olds @ 2011-01-18 3:55 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Erik Faye-Lund, Linus Torvalds, Tor Arntsen, git
In-Reply-To: <20110117222128.GA30869@sigill.intra.peff.net>
On Mon, Jan 17, 2011 at 3:21 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Jan 14, 2011 at 11:21:45AM -0500, Jeff King wrote:
>
>> So we should probably do one or both of:
>>
>> 1. Make an --allow-any-name option to mailinfo, and use it when we
>> invoke mailinfo internally for rebasing. That still doesn't solve
>> the emailed patch problem, but at least keeps purely internal
>> operations sane.
>
> So I wrote up a nice tidy patch series with mailinfo changes and tests,
> and then am/rebase changes and tests on top of that. And guess what I
> noticed? My rebase tests didn't actually fail with stock git.
>
> I bisected to 43c2325 (am: use get_author_ident_from_commit instead of
> mailinfo when rebasing, 2010-06-16), which was written to handle exactly
> this sort of thing.
>
> That commit made it into v1.7.2. JT, which version of git are you
> running? Do you still see any problems with v1.7.2 and above? I can't
> replicate your issue with more recent versions.
>
> So unless we want to do any sort of commit-time warning, I don't think
> there is anything left to be done on this topic.
>
> -Peff
>
Oh ho! No, I am running 1.7.1. I was so pleased to find out what the
root of the problem was, though, that I did go and add my last name
and haven't had any trouble since.
Thanks for all your help everyone.
-JT
^ permalink raw reply
* Re: [PATCH 2/3] git-gui: spelling fixes in russian translation
From: Alexey Shumkin @ 2011-01-18 7:40 UTC (permalink / raw)
To: git
In-Reply-To: <20110117210828.GC27029@blimp.localdomain>
change this
> #, tcl-format
> msgid "File %s seems to have unresolved conflicts, still stage?"
> msgstr ""
+"Файл %s кажется содержит необработанные конфликты.
Продолжить подготовку к "
"сохранению?"
to
+"Файл %s, кажется, содержит необработанные конфликты.
Продолжить подготовку к "
"сохранению?"
"Кажется" - вводное слово, обособляется запятыми
Translation to English:
"Кажется" - is parenthesis so must be isolated with commas
^ permalink raw reply
* Re: [PATCH 39/47] setup: limit get_git_work_tree()'s to explicit setup case only
From: Jonathan Nieder @ 2011-01-18 7:44 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1290785563-15339-40-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> get_git_work_tree() takes input as core.worktree, core.bare,
> GIT_WORK_TREE and decides correct worktree setting.
>
> Unfortunately it does not do its job well. core.worktree and
> GIT_WORK_TREE should only be taken into account, if GIT_DIR is set
As advertised, before this change
GIT_WORK_TREE=$path git add .
paid attention to $GIT_WORK_TREE (and set GIT_DIR=.git), and
afterwards the GIT_WORK_TREE setting has been ignored when GIT_DIR is
not set explicitly.
Unfortunately, that breaks some scripts. Example: using the "git
import-dsc" utility from git-buildpackage to import a source package:
debsnap libwpd 0.7.2-1
git clone git://libwpd.git.sourceforge.net/gitroot/libwpd/libwpd
git tag upstream/0.7.2 RELEASE-0-7-2^{commit}
git reset --keep origin/master
git import-dsc ../source-libwpd/libwpd_0.7.2-1.dsc
echo $?
git show --raw
echo done.
With git v1.7.4-rc2:
HEAD is now at d183cc6 Imported Debian patch 0.7.2-1
gbp:info: Everything imported under 'libwpd'
0
commit d183cc6c4b8dcaf22b1b0875aad0655846ed3b1b
Author: Masayuki Hatta (mhatta) <mhatta@debian.org>
Date: Tue Aug 10 00:37:47 2004 +0900
Imported Debian patch 0.7.2-1
done
versus v1.7.3.2:
HEAD is now at 735a8f2 Imported Debian patch 0.7.2-1
gbp:info: Everything imported under 'libwpd'
0
commit 735a8f21ea817417ecc035817f777bd2943d4efc
Author: Masayuki Hatta (mhatta) <mhatta@debian.org>
Date: Tue Aug 10 00:37:47 2004 +0900
Imported Debian patch 0.7.2-1
:100644 000000 038cd09... 0000000... D .gitignore
:000000 100644 0000000... 0189791... A CHANGES
[...]
git-buildpackage uses the equivalent of
GIT_INDEX_FILE=$(pwd)/.git/gbp_index \
GIT_WORK_TREE=$unpack_dir \
git add -f .
when creating the commit, so with v1.7.4-rc0 and later it is taking
its content from the cwd, producing an incorrect result without
complaint.
How about something like this patch? It only concerns the
GIT_WORK_TREE variable and --work-tree command line option; the
semantics of core.worktree are unaffected.
(Sorry, no real patch yet. Updating the test to reflect the change is
a pain in the neck.)
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
diff --git a/setup.c b/setup.c
index 3d73269..28b2fef 100644
--- a/setup.c
+++ b/setup.c
@@ -419,6 +419,11 @@ static const char *setup_discovered_git_dir(const char *gitdir,
return NULL;
}
+ if (getenv(GIT_WORK_TREE_ENVIRONMENT)) {
+ warning("GIT_WORK_TREE without explicit GIT_DIR is deprecated");
+ return setup_explicit_git_dir(gitdir, cwd, offset, nongit_ok);
+ }
+
/* #0, #1, #5, #8, #9, #12, #13 */
set_git_work_tree(".");
if (strcmp(gitdir, DEFAULT_GIT_DIR_ENVIRONMENT))
@@ -443,6 +448,11 @@ static const char *setup_bare_git_dir(char *cwd, int offset, int len, int *nongi
if (check_repository_format_gently(".", nongit_ok))
return NULL;
+ if (getenv(GIT_WORK_TREE_ENVIRONMENT)) {
+ warning("GIT_WORK_TREE without explicit GIT_DIR is deprecated");
+ return setup_explicit_git_dir(".", cwd, offset, nongit_ok);
+ }
+
inside_git_dir = 1;
inside_work_tree = 0;
if (offset != len) {
^ permalink raw reply related
* Re: [PATCH 2/3] git-gui: spelling fixes in russian translation
From: Alex Riesen @ 2011-01-18 7:48 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <loom.20110118T083048-91@post.gmane.org>
2011/1/18 Alexey Shumkin <zapped@mail.ru>:
> change this
>> #, tcl-format
>> msgid "File %s seems to have unresolved conflicts, still stage?"
>> msgstr ""
> +"Файл %s кажется содержит необработанные конфликты.
> Продолжить подготовку к "
> "сохранению?"
> to
> +"Файл %s, кажется, содержит необработанные конфликты.
> Продолжить подготовку к "
> "сохранению?"
Maybe you can just submit the patch properly?
OTOH, I'll do it this evening, unless you do it first, of course.
^ permalink raw reply
* Re: git bisect problems/ideas
From: Christian Couder @ 2011-01-18 9:04 UTC (permalink / raw)
To: Aaron S. Meurer; +Cc: git@vger.kernel.org
In-Reply-To: <54DED602-0BA7-4462-AC00-1DDEEF83068C@gmail.com>
On Mon, Jan 17, 2011 at 7:23 PM, Aaron S. Meurer <asmeurer@gmail.com> wrote:
> On Jan 17, 2011, at 2:38 AM, Christian Couder <christian.couder@gmail.com>
> wrote:
>
>> Hi,
>>
>> On Sat, Jan 15, 2011 at 8:33 AM, Aaron S. Meurer <asmeurer@gmail.com>
>> wrote:
>>>
>>> First off, do you guys have an issue tracker?
>>
>> No, we don't. We use the mailing list.
>>
>
> Well that's amazing to me. How on Earth fo you manage stuff?
Well, bugs are usually fixed within days after they have been
reported. Otherwise they are usually documented in the code or in the
documentation or in the test suite (with test_expect_failure).
For the rest we rely on people remembering what happened and on
people's mailing list searching skills ;-)
>> If more people want it, yeah, we can create such a shortcut. But you
>> can also use a git alias for that.
>>
>
> Can you alias "git bisect stop", or would you have to alias "git
> bisect-stop"?
I think you have to alias "git bisect-stop".
I am not sure because when I use aliases I prefer to use shell aliases like:
alias gst='git status'
>> Yeah, many people find it difficult to reverse the meaning of "bad"
>> and "good" when looking for a fix. There were some suggestions at some
>> points to do something about it. Some of the suggestions were to use
>> some aliases for "good" and "bad", but there was no agreement. Other
>> suggestions had a patch attached but the patch was not good enough or
>> something.
>>
>> Anyway, the restriction is that the "bad" commit cannot be an ancestor
>> of a "good" commit. But the "good" commits need not be all ancestors
>> of the "bad" commit. For example if you have a "master" branch and a
>> "dev" branch that was forked from the "master" branch at one point,
>> like that:
>>
>> A-B-C-D-E <-- master
>> \F-G <-- dev
>>
>
> I don't understand how this can only be one way? Isn't this symmetric? In
> other words, how is it different from
>
> A-B-C-D-E <-- dev
> \F-G <-- master
>
> as far as bisect is concerned? Or maybe I am not entirely clear on what you
> are saying.
Yes, it is symmetric, so we cannot just automatically reverse the
meanning because there is no "after" or "before" relationship between
"dev" and "master".
Best regards,
Christian.
^ permalink raw reply
* Re: git bisect problems/ideas
From: Christian Couder @ 2011-01-18 9:05 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: SZEDER Gábor, Aaron S. Meurer, git
In-Reply-To: <20110117205542.GA21507@burratino>
2011/1/17 Jonathan Nieder <jrnieder@gmail.com>:
> SZEDER Gábor wrote:
>> On Mon, Jan 17, 2011 at 05:51:33AM -0600, Jonathan Nieder wrote:
>>> Christian Couder wrote:
>
>>>> Yeah, many people find it difficult to reverse the meaning of "bad"
>>>> and "good" when looking for a fix. There were some suggestions at some
>>>> points to do something about it. Some of the suggestions were to use
>>>> some aliases for "good" and "bad", but there was no agreement. Other
>>>> suggestions had a patch attached but the patch was not good enough or
>>>> something.
>>>
>>> Any pointers to such a discussion or patch? Maybe whatever small
>>> detail caused it to be forgotten could be fixed...
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/86063
Thanks for the link.
> A better link for those who are thinking of picking up the topic might
> be [1].
>
> The problems were:
>
> - error messages refer to "good" and "bad" with the original,
> unreversed meaning, which could be confusing (but see later in the
> thread!).
> - "git bisect visualize" doesn't get the memo about the new worldview.
> - it seems that some people lost interest after a while.
>
> None of these seems totally fatal --- as a new feature, it would not
> be breaking anyone's workflow, especially if the potentially confusing
> bits are clearly documented.
Yeah, some things have changed since that time, so it may be more
involved now, but otherwise I think it would be good to have.
Thanks,
Christian.
^ permalink raw reply
* git submodule vs git mergetool
From: Mathieu Malaterre @ 2011-01-18 9:04 UTC (permalink / raw)
To: git
Hi there,
not sure if this is the right place to report a problem. anyway I
have two branches (release and master) each one has a Testing/Data
submodule:
git submodule add git://gdcm.git.sourceforge.net/gitroot/gdcm/gdcmData
Testing/Data
During a merge those two submodules produced a conflict:
$ git mergetool
merge tool candidates: meld opendiff kdiff3 tkdiff xxdiff
tortoisemerge gvimdiff diffuse ecmerge p4merge araxis emerge vimdiff
Merging the files: Testing/Data
mv: cannot stat `Testing/Data': No such file or directory
cp: cannot stat `./Testing/Data.BACKUP.5251': No such file or directory
error: git checkout-index: cannot create temporary subproject
error: git checkout-index: cannot create temporary subproject
Normal merge conflict for 'Testing/Data':
{local}: created
{remote}: created
Hit return to start merge resolution tool (gvimdiff):
3 files to edit
Testing/Data seems unchanged.
Was the merge successful? [y/n] y
fatal: unable to stat 'Testing/Data': No such file or directory
I guess this is a minor issue, but I thought I should report it here.
Thanks for this tool !
--
Mathieu
^ permalink raw reply
* Re: [PATCH] gitk: Take only numeric version components when computing $git_version
From: Mathias Lafeldt @ 2011-01-18 9:12 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Anders Kaseorg, Paul Mackerras, Junio C Hamano, git
In-Reply-To: <20110113192243.GA20625@burratino>
Jonathan Nieder wrote:
> [...]
> So after building from a tarball generated with "git archive", "git version"
> produces v1.7.4-rc1, producing errors from gitk, but after building
> from the git repo or a tarball generated with "make dist", the version
> is v1.7.4.rc1 (which gitk accepts).
>
> Anders's fix looks good to me for robustness reasons anyway, so
>
> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
>
OK then. Junio? :)
> Maybe the substitution in GIT-VERSION-GEN should say something like
>
> VN=$(echo "$VN" | sed -e 's/-\([^r]\)/.\1/g')
>
> meaning the result for tagged rcs would not depend on whether git is
> present? Alternatively, DEF_VER could be set to v1.7.4.rc1, which
> does not seem as nice to me.
^ permalink raw reply
* Re: [PATCH 39/47] setup: limit get_git_work_tree()'s to explicit setup case only
From: Nguyen Thai Ngoc Duy @ 2011-01-18 13:59 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C Hamano
In-Reply-To: <20110118074400.GA4185@burratino>
2011/1/18 Jonathan Nieder <jrnieder@gmail.com>:
> How about something like this patch? It only concerns the
> GIT_WORK_TREE variable and --work-tree command line option; the
> semantics of core.worktree are unaffected.
Perhaps only activate your code if $GIT_WORK_TREE is absolute path?
Things may go wild if $GIT_WORK_TREE is relative. We can die() if
GIT_WORK_TREE is set but not used. Annoying, but better than leave the
errors unseen.
> (Sorry, no real patch yet. Updating the test to reflect the change is
> a pain in the neck.)
Yeah, I count on it to (over-)catch every mistakes in setup code :D
--
Duy
^ permalink raw reply
* Re: [PATCH] Documentation/fast-import: put explanation of M 040000 <dataref> "" in context
From: Junio C Hamano @ 2011-01-18 15:04 UTC (permalink / raw)
To: Jonathan Nieder
Cc: David Barr, Git Mailing List, Ramkumar Ramachandra,
Sverre Rabbelier, Gabriel Filion, Johannes Sixt
In-Reply-To: <20110116022234.GA28452@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Omit needless words ("Additionally ... <path> may also" is redundant).
> While at it, place the explanation of this special case after the
> general rules for paths to provide the reader with some context.
>
> diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> index f56dfca..e2a46a5 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -545,6 +542,9 @@ The value of `<path>` must be in canonical form. That is it must not:
> * contain the special component `.` or `..` (e.g. `foo/./bar` and
> `foo/../bar` are invalid).
>
> +In `040000` mode, `<path>` can be the empty string (`""`)
> +to specify the root of the tree.
> +
Thanks, but is "In x mode" an appropriate wording here in the first place?
I would expect x to be some action (e.g. In navigation mode, typing many
keys just beep, and in edit mode, typing most keys just insert -- vi) but
the word "mode" doesn't fit that pattern (unless we take a bitpattern "x"
to mean "the act of creating a path with mode bits x").
^ permalink raw reply
* Re: [PATCH 1/2] rebase -i: reword in-editor documentation of "exec"
From: Junio C Hamano @ 2011-01-18 15:05 UTC (permalink / raw)
To: Matthieu Moy
Cc: Jonathan Nieder, git, gitster, Kevin Ballard, Yann Dirson,
Eric Raible
In-Reply-To: <vpq39otrvmk.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> -# x <cmd>, exec <cmd> = Run a shell command <cmd>, and stop if it fails
>> +# x, exec = run command using shell, and stop if it fails
>
> I don't think this is a good change to remove the <cmd> part. All
> other commands are used with
>
> <command> <sha1> <subject line>
>
> and I don't think the user would be able to guess that exec is
> different without a hint.
I tend to agree with you here.
^ permalink raw reply
* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Yaroslav Halchenko @ 2011-01-18 16:02 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Elijah Newren
In-Reply-To: <20110111132710.GA14905@burratino>
On Tue, 11 Jan 2011, Jonathan Nieder wrote:
> ...
> a submodule might be another reason for a directory in the worktree.
> In any event, we get a spurious conflict.
> Thanks, that was interesting (no patch yet, alas).
is there a way to memorize this issue somewhere (bug tracking/TODO/etc)
where this issue could be recorded so it doesn't get forgotten? ;)
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
^ permalink raw reply
* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Andreas Ericsson @ 2011-01-18 16:08 UTC (permalink / raw)
To: Yaroslav Halchenko; +Cc: Jonathan Nieder, git, Elijah Newren
In-Reply-To: <20110118160222.GA23926@onerussian.com>
On 01/18/2011 05:02 PM, Yaroslav Halchenko wrote:
>
> On Tue, 11 Jan 2011, Jonathan Nieder wrote:
>> ...
>> a submodule might be another reason for a directory in the worktree.
>> In any event, we get a spurious conflict.
>> Thanks, that was interesting (no patch yet, alas).
>
> is there a way to memorize this issue somewhere (bug tracking/TODO/etc)
> where this issue could be recorded so it doesn't get forgotten? ;)
>
It will be stored in the hive-mind of the mailing list participants.
It's quite a bit better than it sounds actually.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: problem with cherry-picking a commit which comes before introducing a new submodule
From: Yaroslav Halchenko @ 2011-01-18 16:20 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jonathan Nieder, git, Elijah Newren
In-Reply-To: <4D35BAE1.6090204@op5.se>
On Tue, 18 Jan 2011, Andreas Ericsson wrote:
> > is there a way to memorize this issue somewhere (bug tracking/TODO/etc)
> > where this issue could be recorded so it doesn't get forgotten? ;)
> It will be stored in the hive-mind of the mailing list participants.
> It's quite a bit better than it sounds actually.
ok -- offload completed then, I am cleaning up my memory bank
--
=------------------------------------------------------------------=
Keep in touch www.onerussian.com
Yaroslav Halchenko www.ohloh.net/accounts/yarikoptic
^ permalink raw reply
* gitk "find commit adding/removing string"/possible pickaxe bug?
From: Sebastian Hahn @ 2011-01-18 16:16 UTC (permalink / raw)
To: git
Hi,
I quite like gitk and am a fan of the ability to easily locate commits
where a specific string was added/removed. If the string in question
was added in a merge commit as part of a conflicted/otherwise
changed merge, gitk doesn't display it.
(If you want to reproduce, the repository is git://git.torproject.org/
tor,
the string I'm looking for is "< DIGEST" and the first commit I hope to
find is ed87738ede789fb).
I presented the issue to #git, and it was suggested that it is probably
a pickaxe bug in that it doesn't display changes in merge commits if
they add strings that neither of their parents has.
Do you agree that this is a bug, or am I missing anything here?
Thanks for you consideration!
Sebastian
^ permalink raw reply
* filter-branch --env-filter GIT_AUTHOR_DATE
From: Tuncer Ayaz @ 2011-01-18 16:43 UTC (permalink / raw)
To: git
To fix invalid timezone info in a repo I ran
git filter-branch --env-filter '
GIT_AUTHOR_DATE=`echo ${GIT_AUTHOR_DATE}|sed s/+0000/-0800/`' HEAD
This fixed the invalid entries but the new timezone is -0700
instead of -0800. Is this expected?
git version 1.7.4.rc2
^ permalink raw reply
* Re: gitk "find commit adding/removing string"/possible pickaxe bug?
From: Thomas Rast @ 2011-01-18 16:44 UTC (permalink / raw)
To: git; +Cc: Sebastian Hahn
In-Reply-To: <514EB3AA-CD31-4BDB-B777-B7AAEEDF5663@sebastianhahn.net>
Sebastian Hahn wrote:
>
> I quite like gitk and am a fan of the ability to easily locate commits
> where a specific string was added/removed. If the string in question
> was added in a merge commit as part of a conflicted/otherwise
> changed merge, gitk doesn't display it.
[...]
> I presented the issue to #git, and it was suggested that it is probably
> a pickaxe bug
In particular, in a history where
$ git show HEAD:foo
quux
$ git show HEAD^:foo
bar
$ git show HEAD^2:foo
baz
the behaviour is:
git log -Squux # empty
git log -Squux -p # empty
git log -Squux --pickaxe-all # empty
git log -Squux -c # shows merge, but no diff
git log -Squux --cc # shows merge, but no diff
git log -Squux -c -p # shows merge, but no diff
git log -Squux -c --pickaxe-all # shows merge, but no diff
git log -Squux --pickaxe-all -c -p # shows merge & combined diff
So it only shows the diff with --pickaxe-all, even though the (only)
hunk clearly introduced the string.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re*: [PATCH 1/3] t4034: bulk verify builtin word regex sanity
From: Junio C Hamano @ 2011-01-18 18:00 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Thomas Rast, Scott Johnson, Michael J Gruber, Matthijs Kooijman,
git
In-Reply-To: <20110111214811.GB29133@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> From: Thomas Rast <trast@student.ethz.ch>
> Date: Sat, 18 Dec 2010 17:17:54 +0100
>
> The builtin word regexes should be tested with some simple examples
> against simple issues. Do this in bulk.
Thanks.
> diff --git a/t/t4034/bibtex/expect b/t/t4034/bibtex/expect
> new file mode 100644
> index 0000000..a157774
> --- /dev/null
> +++ b/t/t4034/bibtex/expect
> @@ -0,0 +1,15 @@
> +<BOLD>diff --git a/pre b/post<RESET>
> +<BOLD>index 95cd55b..ddcba9b 100644<RESET>
Having to change this line every time the test input (or output) has
changed is somewhat unfortunate.
Also I noticed that "word_diff" shell function has this:
test_must_fail git diff --no-index "$@" pre post >output &&
which solicits two comments:
- We do not seem to document that --no-index implies --exit-code, ever
since the latter option was introduced at 41bbf9d (Allow git-diff exit
with codes similar to diff(1), 2007-03-14). Probably we should.
- This assumes that no test vector would have identical pre/post pair
that expects no output, which feels somewhat limiting.
What we care about in this test is that "git diff --no-index" does not die
an uncontrolled death, so test_might_fail may be more appropriate.
Here is another that probably should be squashed to this patch together
with 3/3 to add tests for the perl driver (I noticed it only because 2/3
had trivial conflict due to recent addition of it).
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 18 Jan 2011 09:43:43 -0800
Subject: [PATCH] t4034 (diff --word-diff): add a minimum Perl drier test vector
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t4034-diff-words.sh | 1 +
t/t4034/perl/expect | 13 +++++++++++++
t/t4034/perl/post | 22 ++++++++++++++++++++++
t/t4034/perl/pre | 22 ++++++++++++++++++++++
4 files changed, 58 insertions(+), 0 deletions(-)
create mode 100644 t/t4034/perl/expect
create mode 100644 t/t4034/perl/post
create mode 100644 t/t4034/perl/pre
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index c3b1c48..37aeab0 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -301,6 +301,7 @@ test_language_driver html
test_language_driver java
test_language_driver objc
test_language_driver pascal
+test_language_driver perl
test_language_driver php
test_language_driver python
test_language_driver ruby
diff --git a/t/t4034/perl/expect b/t/t4034/perl/expect
new file mode 100644
index 0000000..a1deb6b
--- /dev/null
+++ b/t/t4034/perl/expect
@@ -0,0 +1,13 @@
+<BOLD>diff --git a/pre b/post<RESET>
+<BOLD>index f6610d3..e8b72ef 100644<RESET>
+<BOLD>--- a/pre<RESET>
+<BOLD>+++ b/post<RESET>
+<CYAN>@@ -4,8 +4,8 @@<RESET>
+
+package Frotz;<RESET>
+sub new {<RESET>
+ my <GREEN>(<RESET>$class<GREEN>, %opts)<RESET> = <RED>shift<RESET><GREEN>@_<RESET>;
+ return bless { <GREEN>xyzzy => "nitfol", %opts<RESET> }, $class;
+}<RESET>
+
+__END__<RESET>
diff --git a/t/t4034/perl/post b/t/t4034/perl/post
new file mode 100644
index 0000000..e8b72ef
--- /dev/null
+++ b/t/t4034/perl/post
@@ -0,0 +1,22 @@
+#!/usr/bin/perl
+
+use strict;
+
+package Frotz;
+sub new {
+ my ($class, %opts) = @_;
+ return bless { xyzzy => "nitfol", %opts }, $class;
+}
+
+__END__
+=head1 NAME
+
+frotz - Frotz
+
+=head1 SYNOPSIS
+
+ use frotz;
+
+ $nitfol = new Frotz();
+
+=cut
diff --git a/t/t4034/perl/pre b/t/t4034/perl/pre
new file mode 100644
index 0000000..f6610d3
--- /dev/null
+++ b/t/t4034/perl/pre
@@ -0,0 +1,22 @@
+#!/usr/bin/perl
+
+use strict;
+
+package Frotz;
+sub new {
+ my $class = shift;
+ return bless {}, $class;
+}
+
+__END__
+=head1 NAME
+
+frotz - Frotz
+
+=head1 SYNOPSIS
+
+ use frotz;
+
+ $nitfol = new Frotz();
+
+=cut
--
1.7.4.rc2.226.g63d9a
^ permalink raw reply related
* Re: git bisect problems/ideas
From: Junio C Hamano @ 2011-01-18 18:34 UTC (permalink / raw)
To: Christian Couder; +Cc: Aaron S. Meurer, git@vger.kernel.org
In-Reply-To: <AANLkTi=A2Twepg3Jo_VYxtvghkhx6ixcpRH3332BoRQo@mail.gmail.com>
Christian Couder <christian.couder@gmail.com> writes:
> Well, bugs are usually fixed within days after they have been
> reported. Otherwise they are usually documented in the code or in the
> documentation or in the test suite (with test_expect_failure).
>
> For the rest we rely on people remembering what happened and on
> people's mailing list searching skills ;-)
Not really.
What we do is to take advantage of the fact that issues people do care
about are important ones, and others that nobody cares about are not worth
pursuing.
In a sense, "people forgetting" is a lot more important than "people
remembering" to filter unimportant issues (issues that are so unimportant
that even the original complainer does not bother to come back and
re-raise it).
^ permalink raw reply
* Re: gitk "find commit adding/removing string"/possible pickaxe bug?
From: Junio C Hamano @ 2011-01-18 18:39 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Sebastian Hahn
In-Reply-To: <201101181744.18139.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> git log -Squux --pickaxe-all -c -p # shows merge & combined diff
>
> So it only shows the diff with --pickaxe-all, even though the (only)
> hunk clearly introduced the string.
Isn't it just because unless you ask for -m to get all the pairwise diff
between each parent and the merged child the diff machinery won't kick in
for merge commits? I didn't check the option defaulting logic, but there
may be something that changes the default setting of "-m" among your
examples.
^ permalink raw reply
* Re: gitk "find commit adding/removing string"/possible pickaxe bug?
From: Jeff King @ 2011-01-18 18:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Sebastian Hahn
In-Reply-To: <201101181744.18139.trast@student.ethz.ch>
On Tue, Jan 18, 2011 at 05:44:17PM +0100, Thomas Rast wrote:
> In particular, in a history where
>
> $ git show HEAD:foo
> quux
> $ git show HEAD^:foo
> bar
> $ git show HEAD^2:foo
> baz
I created a similar repo with:
commit() {
echo $1 >file && git add file && git commit -m $1
}
mkdir repo && cd repo && git init
commit base
commit master
git checkout -b other HEAD^
commit other
git merge master
commit resolved
which should be identical. But I get different results (see near the
end):
> the behaviour is:
>
> git log -Squux # empty
> git log -Squux -p # empty
All of which make sense to me. Pickaxe operates on diff filepairs, and
git by default doesn't seem to do merge diffing at all (but see below).
So those filepairs don't exist to consider.
> git log -Squux --pickaxe-all # empty
This doesn't help. It just loosens the actual diff shown from "just the
things that matched -S" to "everything in that commit". It doesn't
add to the filepairs that make it to pickaxe.
> git log -Squux -c # shows merge, but no diff
This "-c" does what you want, because we start looking at merge
filepairs. Although one thing leaves me confused. If I do:
git log -p
I get no diff for the merge commit. But in git-diff(1), it says:
COMBINED DIFF FORMAT
"git-diff-tree", "git-diff-files" and "git-diff" can take -c or --cc
option to produce combined diff. For showing a merge commit with
"git log -p", this is the default format; you can force showing full
diff with the -m option.
which implies to me that "-c" should be on by default if we selected
"-p" (or presumably -S).
I didn't bisect, but I wonder if the doc is wrong, or if we accidentally
lost this default at some point.
> git log -Squux --cc # shows merge, but no diff
Makes sense again, since you didn't ask for a patch, no patch.
> git log -Squux -c -p # shows merge, but no diff
Weird. Here I get a nice combined diff, which is what I expect.
> git log -Squux -c --pickaxe-all # shows merge, but no diff
Yep, no "-p" again.
> git log -Squux --pickaxe-all -c -p # shows merge & combined diff
The pickaxe-all shouldn't impact anything, at least not in my test repo,
as there is only one file. But of course I do get the diff, as I did
above. Can you show the steps to create your repo? I'm wondering what is
different.
-Peff
^ permalink raw reply
* Re: [PATCH 39/47] setup: limit get_git_work_tree()'s to explicit setup case only
From: Junio C Hamano @ 2011-01-18 19:41 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20110118074400.GA4185@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> diff --git a/setup.c b/setup.c
> index 3d73269..28b2fef 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -419,6 +419,11 @@ static const char *setup_discovered_git_dir(const char *gitdir,
> return NULL;
> }
>
> + if (getenv(GIT_WORK_TREE_ENVIRONMENT)) {
> + warning("GIT_WORK_TREE without explicit GIT_DIR is deprecated");
> + return setup_explicit_git_dir(gitdir, cwd, offset, nongit_ok);
> + }
> +
My knee-jerk reaction is that calling this "deprecated" is probably
confusing. git merely failed to notice misconfiguration so far and went
ahead to produce a random result when GIT_DIR is not set (hence the usual
rule is in effect to find out where the .git directory is, starting from
the assumption that you _are_ somewhere _inside_ the work tree, _and_ the
root of the work tree _is_ where that .git directory is found in) and at
the same time GIT_WORK_TREE is pointing at a random other location.
Unless that location happens to match the parent directory of the
discovered .git, this invalidates the assumption of the whole discovery
logic (iow, how you found .git to begin with). In other words, it is my
understanding that setting only GIT_WORK_TREE without setting GIT_DIR
wasn't meant to be supported at all, because there is no sane logic to
specify a consistent behaviour in such a case.
If "we first run discovery as if you were somewhere in your work tree to
find .git directory, but you are allowed to say that your working tree is
elsewhere, possibly completely unrelated to the tree hierarchy used to
find .git directory to begin with; we could accomodate these conflicting
wishes because hopefully the necessary set-up happens before we actually
need to touch anything in the work tree" were a sane specification, this
patch may start making sense. Not breaking existing scripts that rely on
the behaviour is a nice bonus. The "hopefully" part makes me worried
enough to keep me from saying that semantics is sane without thinking
though.
I notice that git(1) manual page discusses --work-tree=<path> (and
GIT_WORK_TREE) to a reasonable level of details (the most importantly, the
rule to determine where the root of the working tree is when nothing is
specified is given), but the corresponding description on --git-dir=<path>
(and GIT_DIR) is too sketchy to tell how the discovery works when nothing
is given. Perhaps that part needs to address what the semantics should be?
> /* #0, #1, #5, #8, #9, #12, #13 */
> set_git_work_tree(".");
> if (strcmp(gitdir, DEFAULT_GIT_DIR_ENVIRONMENT))
> @@ -443,6 +448,11 @@ static const char *setup_bare_git_dir(char *cwd, int offset, int len, int *nongi
> if (check_repository_format_gently(".", nongit_ok))
> return NULL;
>
> + if (getenv(GIT_WORK_TREE_ENVIRONMENT)) {
> + warning("GIT_WORK_TREE without explicit GIT_DIR is deprecated");
> + return setup_explicit_git_dir(".", cwd, offset, nongit_ok);
> + }
> inside_git_dir = 1;
> inside_work_tree = 0;
This is for people who do "cd .git && GIT_WORK_TREE=.. git cmd". I have to
wonder what happens to the pathspec given to the cmd---you are clearly
outside of your working tree.
A tangent.
Do we make sure that whatever GIT_WORK_TREE we end up with using is an
ancestor directory of the $CWD when we require us to be inside the working
tree? I think we should, as I don't think of a sane use case otherwise
(unless you call "cd ../neigh; GIT_WORK_TREE=../work git diff ../work/foo"
a sane way to futz with the file "foo" in the working tree "work" from a
directory "neigh" that is unrelated to the repository).
^ permalink raw reply
* Re: core.whitespace space-in-indent feature request
From: Drew Northup @ 2011-01-18 19:51 UTC (permalink / raw)
To: Victor Engmark; +Cc: git
In-Reply-To: <AANLkTikiHXofGVg9QECg9a4U4r4VGD1tb6oMV21nzd9W@mail.gmail.com>
On Fri, 2011-01-14 at 13:40 +0100, Victor Engmark wrote:
> Hi all,
>
> I couldn't find this mentioned anywhere, but it would be useful for
> languages where you typically want only tab characters in indentation,
> like makefiles. Would be equivalent or similar to indent-with-non-tab
> and tabwidth=1.
Victor,
What would the point of this be? Git doesn't change the layout of the
code when storing it--that's up to the thing between the chair and the
keyboard.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: core.whitespace space-in-indent feature request
From: Junio C Hamano @ 2011-01-18 20:31 UTC (permalink / raw)
To: Drew Northup; +Cc: Victor Engmark, git
In-Reply-To: <1295380297.3778.47.camel@drew-northup.unet.maine.edu>
Drew Northup <drew.northup@maine.edu> writes:
> On Fri, 2011-01-14 at 13:40 +0100, Victor Engmark wrote:
>> Hi all,
>>
>> I couldn't find this mentioned anywhere, but it would be useful for
>> languages where you typically want only tab characters in indentation,
>> like makefiles. Would be equivalent or similar to indent-with-non-tab
>> and tabwidth=1.
>
> Victor,
> What would the point of this be? Git doesn't change the layout of the
> code when storing it--that's up to the thing between the chair and the
> keyboard.
True, but I think Victor wants to be able to ask "diff --check" to
complain and diff --color to highlight when it sees a line that begins
with a SP (or a HT then SP) by setting:
* whitespace=space-in-indent
or something in the attributes file.
As "equivalence" exists, not very much interested in coding it myself,
though ;-)
^ 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