* Re: current git kernel has strange problems during bisect
From: Christian Couder @ 2009-01-12 4:51 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Alexey Zaytsev, Sam Ravnborg, Linus Torvalds,
Christian Borntraeger, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <20090111230240.GA27489@artemis.corp>
Le lundi 12 janvier 2009, Pierre Habouzit a écrit :
> On Sun, Jan 11, 2009 at 07:47:18PM +0000, Alexey Zaytsev wrote:
> > On Sun, Jan 11, 2009 at 22:42, Sam Ravnborg <sam@ravnborg.org> wrote:
> > >> For bisect, it's indeed somewhat annoying, and we could have perhaps
> > >> done some things a bit differently, but it's about the closest you
> > >> can get to "real history" without making the first btrfs merge-point
> > >> a _total_ disaster.
> > >>
> > >> For bisect purposes, if you know you're not chasing down a btrfs
> > >> issue, you can do
> > >>
> > >> git bisect good 34353029534a08e41cfb8be647d734b9ce9ebff8
> > >>
> > >> where that commit 34353029 is the last one which has _just_ the
> > >> btrfs files. The next commit is when it does "Merge Btrfs into
> > >> fs/btrfs", and that one has the whole kernel tree again.
> > >
> > > The cost of moving this piece of history from one git tree to another
> > > git tree is that we make it harder to debug the kernel for the
> > > advanced user that knows how to do bisect.
> >
> > And wasn't is trivial to avoid? Just exporting the commits as
> > patches and importing them into the kernel tree would preserve
> > the history, and not break bisection.
>
> And would have brought a whole history of totally irrelevant stuff that
> never exited for real, with probably a lot of non-compiling sub-steps
> which would be even worse.
>
> No, the two possible choices were to squash the whole stuff at once, or
> do what has been done IMNSHO. People have to grok how to take shortcuts
> with git-bisect. I know that git-bisect puts people on the brainless
> course of actions where they git-bisect; configure; compile; boot; test;
> mark as good/bad and retry. And that's what I sometimes don't like with
> it. Because people trust git-bisect too much and forget how to think
> right.
Well "git bisect" can be more usefull if it can be fully automated (with git
bisect run) because then you can make the computer do all the boring work.
So I think putting people on the "brainless course of actions" can often be
a good thing.
Anyway it looks to me that this kind of problem could be avoided if one
could "replace" some commits only when bisecting. In this case what could
be done is that one could "replace" the commit where btrfs is merged with
one commit that cuts off the btrfs history. If the merge commit is only
replaced when bisecting, then you get the best of both worlds:
_ when you bisect, you don't see the btrfs history that breaks the kernel
build,
_ when you don't bisect, you see the full real history.
Of course if the bisection process finds out that the "replaced" commit is
the culprit, then you need to understand what this means...
Regards,
Christian.
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Christian Couder @ 2009-01-12 5:03 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Pierre Habouzit, Alexey Zaytsev, Sam Ravnborg, Linus Torvalds,
Johannes Schindelin, git, Linux Kernel Mailing List
In-Reply-To: <200901120551.56791.chriscool@tuxfamily.org>
I wrote:
>
> Anyway it looks to me that this kind of problem could be avoided if one
> could "replace" some commits only when bisecting. In this case what could
> be done is that one could "replace" the commit where btrfs is merged with
> one commit that cuts off the btrfs history.
By the way, it possible right now to cut off the btrfs history in one's own
repository using a graft. One don't need to wait for me to finish the
replace stuff I am slowly working on. But on the other hand it will have
all the restrictions of the current graft mechanism.
Regards,
Christian.
^ permalink raw reply
* Re: git-svn: File was not found in commit
From: Eric Wong @ 2009-01-12 5:14 UTC (permalink / raw)
To: Morgan Christiansson; +Cc: git
In-Reply-To: <20090112023211.GA21462@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> Morgan Christiansson <git@mog.se> wrote:
> > The "Ignoring path" message appears to be coming from git which is
> > refusing to commit the .git directory. Which leads to git-svn being
> > unaware of the files being ignored and giving an error when it can't
> > find them.
>
> > I'm personally fine with these files being ignored by git, but git-svn
> > needs to be aware that they are not added to the repository.
>
> Hi Morgan,
> Can you try the following rough patch and see it it fixes things
> for you? Thanks!
Actually, I think this patch is broken (my quickly put together test
case was insufficient)...
> From 559f4b673592f364e9773f2ba65caf09b138521b Mon Sep 17 00:00:00 2001
> From: Eric Wong <normalperson@yhbt.net>
> Date: Sun, 11 Jan 2009 18:23:38 -0800
> Subject: [PATCH/RFC] git-svn: avoid importing nested repos
>
> Some SVN repositories contain .git repositories within them
> (hopefully accidentally checked in). Since git refuses to
> check in ".git" repositories, this can be a problem when
> fetching updates from SVN.
>
> This seems to repull the entire blob from SVN everytime a user
> changes something inside the ".git" directory on the SVN side,
> but hopefully this will be a rare case and the SVN users will
> correct the error quickly.
>
> The test could probably be expanded to be more thorough...
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
^ permalink raw reply
* Re: [PATCH] Cleanup of unused symcache variable inside diff-lib.c
From: Junio C Hamano @ 2009-01-12 5:39 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <1231699002-5316-1-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
> diff --git a/diff-lib.c b/diff-lib.c
> index ae96c64ca209f4df9008198e8a04b160bed618c7..e6d1d2b34147a13aadb5019e0c8336ef5f56ee39 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> ...
> @@ -344,8 +334,7 @@ static void do_oneway_diff(struct unpack_trees_options *o,
> struct cache_entry *idx,
> struct cache_entry *tree)
> {
> - struct oneway_unpack_data *cbdata = o->unpack_data;
> - struct rev_info *revs = cbdata->revs;
> + struct rev_info *revs = o->unpack_data;;
Thanks; I'll clean-up the extra semicolon and apply.
^ permalink raw reply
* Re: [PATCH] git-svn: add --authors-file test
From: Junio C Hamano @ 2009-01-12 5:40 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20090111234406.GA22763@yp-box.dyndns.org>
Eric Wong <normalperson@yhbt.net> writes:
> I'm not sure how often this functionality is used, but in case
> it's not, having an extra test here will help catch breakage
> sooner.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
>
> This was posted over a year ago and forgotten about. Updated and
> cleaned up a bit to work with the new test suite.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 4/3] Add example git-vcs-p4
From: Daniel Barkalow @ 2009-01-12 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6xhl1i7.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Hmm...
>
> CC vcs-p4.o
> cc1: warnings being treated as errors
> vcs-p4.c: In function 'output_data':
> vcs-p4.c:253: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
> vcs-p4.c: In function 'p4_where':
> vcs-p4.c:291: warning: ISO C90 forbids mixed declarations and code
> vcs-p4.c: In function 'p4_submit':
> vcs-p4.c:363: warning: ISO C90 forbids mixed declarations and code
> vcs-p4.c: In function 'p4_print':
> vcs-p4.c:433: warning: format '%d' expects type 'int', but argument 2 has type 'size_t'
> vcs-p4.c: In function 'p4_change':
> vcs-p4.c:453: warning: ISO C90 forbids mixed declarations and code
> vcs-p4.c: In function 'p4_filelog':
> vcs-p4.c:504: warning: ISO C90 forbids mixed declarations and code
> make: *** [vcs-p4.o] Error 1
I haven't been over the 4/3 stuff for coding style yet. But how do you get
these warnings? My gcc 4.1.2 doesn't seem to want to complain about
non-C90 usage except in strict C90 mode, where it gets more upset about
"inline" all over the place.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC PATCH 3/3] Support fetching from foreign VCSes
From: Daniel Barkalow @ 2009-01-12 5:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxjpmhow.fsf@gitster.siamese.dyndns.org>
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > This supports a useful subset of the usual fetch logic, mostly in the
> > config file.
> >
> > Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
>
> I like the direction this series is going. In the longer term, it would
> be nice if we can have git-svn and git-cvsimport replaced with something
> like this.
That was my goal, although the only foreign system I currently use is
Perforce.
> Is the current foreign vcs interface sufficiently rich to support git as a
> foreign scm by using fast-import and fast-export?
I think so, although it would be pretty strange, since it would generally
have a whole lot of local data (a complete clone of any remote
repository).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 0/4] refactor the --color-words to make it more hackable
From: Thomas Rast @ 2009-01-12 6:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901112351050.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1530 bytes --]
Johannes Schindelin wrote:
> On Sun, 11 Jan 2009, Thomas Rast wrote:
> > However, the final result segfaults and/or prints garbage (on
> > apparently every commit except very small changes) when using the regex
> > '\S+', which IMHO should give exactly the same result as not using a
> > regex at all.
>
> No, it should not. The correct regex is '^\S+'.
>
> As it happens, your regex matches _anything_ + non-whitespace.
It definitely doesn't(*).
Given ' word rest', '^\S+' would not match at all, and '\S+' would
match 'word'. No space there. However, at a cursory glance your
patch seems to ignore the rm_so member of match[0], so it'll never
know the difference.
While it might arguably make sense to enforce that only isspace()
characters are whitespace and !isspace() is at least part of _some_
(possibly one-character) word, I do not think it is a good idea to
require the anchoring of the user. If we need it, we must anchor the
match ourselves.
> Unfortunately, this includes a newline which utterly confuses the
> diff,
I do agree that matching a newline as part of a word is bad because we
need it for its diff separator semantics. Consider passing
REG_NEWLINE to regcomp() to reduce the risk of matching newlines via
things like [^\[:space:]].
(*) Well, modulo Junio's objection in the other thread that \S is
actually a PCRE extension. Substitute [^[:space:]] if your local
flavour doesn't understand it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 4/3] Add example git-vcs-p4
From: Junio C Hamano @ 2009-01-12 6:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.1.00.0901120026290.19665@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
>> vcs-p4.c:504: warning: ISO C90 forbids mixed declarations and code
>> make: *** [vcs-p4.o] Error 1
>
> I haven't been over the 4/3 stuff for coding style yet. But how do you get
> these warnings?
I thought I have mentioned this already, but...
I compile with (at least) these:
-Wno-pointer-to-int-cast
-Wold-style-definition
-Wdeclaration-after-statement
explicitly specified.
I also run kernel's checkpatch.pl script (but ignoring "more than 80-col
is too long" rule) from time to time.
I consider these are good ways to check style-discipline.
^ permalink raw reply
* [PATCH] git-am: add --directory=<dir> option
From: Junio C Hamano @ 2009-01-12 6:33 UTC (permalink / raw)
To: git; +Cc: Simon 'corecode' Schubert, Kevin Ballard
Thanks to a200337 (git-am: propagate -C<n>, -p<n> options as well,
2008-12-04) and commits around it, "git am" is equipped to correctly
propagate the command line flags such as -C/-p/-whitespace across a patch
failure and restart.
It is trivial to support --directory option now, resurrecting previous
attempts by Kevin and Simon.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
"What's cooking" has listed kb/am-directory in "Stalled" category for too
long a time and I dropped it entirely. This resurrects the feature.
git-am.sh | 17 +++++++++++++----
t/t4252-am-options.sh | 8 ++++++++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git c/git-am.sh w/git-am.sh
index 4b157fe..7e6329b 100755
--- c/git-am.sh
+++ w/git-am.sh
@@ -16,6 +16,7 @@ s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
whitespace= pass it through git-apply
+directory= pass it through git-apply
C= pass it through git-apply
p= pass it through git-apply
resolvemsg= override error message when patch failure occurs
@@ -33,6 +34,14 @@ cd_to_toplevel
git var GIT_COMMITTER_IDENT >/dev/null ||
die "You need to set your committer info first"
+sq () {
+ for sqarg
+ do
+ printf "%s" "$sqarg" |
+ sed -e 's/'\''/'\''\'\'''\''/g' -e 's/.*/ '\''&'\''/'
+ done
+}
+
stop_here () {
echo "$1" >"$dotest/next"
exit 1
@@ -155,10 +164,10 @@ do
;;
--resolvemsg)
shift; resolvemsg=$1 ;;
- --whitespace)
- git_apply_opt="$git_apply_opt $1=$2"; shift ;;
+ --whitespace|--directory)
+ git_apply_opt="$git_apply_opt $(sq "$1=$2")"; shift ;;
-C|-p)
- git_apply_opt="$git_apply_opt $1$2"; shift ;;
+ git_apply_opt="$git_apply_opt $(sq "$1$2")"; shift ;;
--)
shift; break ;;
*)
@@ -459,7 +468,7 @@ do
case "$resolved" in
'')
- git apply $git_apply_opt --index "$dotest/patch"
+ eval 'git apply '"$git_apply_opt"' --index "$dotest/patch"'
apply_status=$?
;;
t)
diff --git c/t/t4252-am-options.sh w/t/t4252-am-options.sh
index 3ab9e8e..e91a6da 100755
--- c/t/t4252-am-options.sh
+++ w/t/t4252-am-options.sh
@@ -50,4 +50,12 @@ test_expect_success 'interrupted am -C1 -p2' '
grep "^Three$" file-2
'
+test_expect_success 'interrupted am --directory="frotz nitfol"' '
+ rm -rf .git/rebase-apply &&
+ git reset --hard initial &&
+ test_must_fail git am --directory="frotz nitfol" "$tm"/am-test-5-? &&
+ git am --skip &&
+ grep One "frotz nitfol/file-5"
+'
+
test_done
^ permalink raw reply related
* Re: Recent annoying problem with Linus's git repository?
From: Marco Roeland @ 2009-01-12 7:59 UTC (permalink / raw)
To: walt; +Cc: git, rmk
In-Reply-To: <alpine.LNX.2.00.0901111615500.4963@x9.ybpnyarg>
On Sunday January 11th 2009 at 16:42 walt wrote:
> I've been tracking Junio's git.git and Linus's kernel.git for ages,
> and just in the last two weeks or so I've been having a recurring
> problem with the file "arch/arm/mach-integrator/clock.h" from Linus.
>
> Any time I check out an old kernel version (e.g. during a bisect)
> and then do a "checkout master" when I'm done fiddling, git thinks
> my repository is "dirty".
>
> This is the reason for my impurity:
>
> # git status
> # On branch master
> # Changed but not updated:
> # (use "git add/rm <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working directory)
> #
> # deleted: arch/arm/mach-integrator/clock.h
>
> It's always that same damned clock.h that remains in my working
> directory after doing the "checkout master" but it shouldn't be
> there -- it has indeed been deleted from branch master.
>
> When I then do a "git reset --hard" I Am Purified! and no longer
> considered dirty. But why should that extra reset step be needed?
>
> Only that one file is involved in this recurring annoyance. Can
> anyone figure out why, or at least reproduce the problem?
It is because commit d72fbdf01fc77628c0b837d0dd2fd564fa26ede6 "[ARM]
integrator: convert to clkdev and lookup clocks by device name" didn't
really _delete_ file arch/arm/mach-integrator/clock.h but only made it
empty. So the file still exists in the repository, but with size 0.
Cleanup scripts within the kernel build environment however always
consider empty files leftover products from the build and so delete
them.
That's why you get this result, after cleaning up.
The file should probably just be really deleted. Adding Russell to the
Cc. ;-)
At the moment (git describe gives v2.6.29-rc1-1-gae04d14) this is the
only "empty" file in the kernel repository. We've had these cases
before.
--
Marco Roeland
^ permalink raw reply
* Re: Minimum required version of subversion for git-svn?
From: Tom G. Christensen @ 2009-01-12 8:03 UTC (permalink / raw)
To: Eric Wong; +Cc: git@vger.kernel.org
In-Reply-To: <20090112010354.GB23377@yp-box.dyndns.org>
Eric Wong wrote:
> "Tom G. Christensen" <tgc@statsbiblioteket.dk> wrote:
>> Hello,
>>
>> With git 1.6.0.5 I was able to run git-svn with subversion 1.1.4 on
>> RHEL4/i386 but with 1.6.0.6 and 1.6.1 the testsuite now fails in the new
>> test t9104.10:
>
> ...
>
>> With 1.6.1 I also see t9129.10-12 failing with subversion 1.1.4:
>> * FAIL 10: ISO-8859-1 should match UTF-8 in svn
>
> ...
>
>> * failed 3 among 12 test(s)
>> make[2]: Leaving directory `/builddir/build/BUILD/git-1.6.1/t'
>> make[2]: *** [t9129-git-svn-i18n-commitencoding.sh] Error 1
>>
>> I see in git-svn.perl that only SVN::Core 1.1.0 is required. Is it still
>> the intention that git-svn should work with subversion 1.1.x?
>>
>> If you're going to bump the minimum requirement I would ask that you
>> atleast keep 1.3.x as supported. This is the last release of subversion
>> where RHEL3 can satisfy the dependencies out of the box and I've
>> verified that the testsuite will pass with 1.3.2.
>
> It's still my intention that SVN 1.1.x is supported; but I haven't had
> the chance to test those versions in a while.
>
> Can you rerun the tests that failed with "sh -x t91..." ?
>
I've run the tests from 1.6.1 with -v, sh -x and sh -x + -v and dumped
the results at http://jupiterrise.com/tmp
You'll find results from one more test (t9106) which I didn't mention
and which is also giving me problems but only with rhel4/x86_64 and svn
1.1.4. It should be noted that this test has never worked for me with
this config.
-tgc
^ permalink raw reply
* Re: [RFC PATCH 2/3] Add specification of git-vcs helpers
From: Johannes Sixt @ 2009-01-12 8:13 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.LNX.1.00.0901110334350.19665@iabervon.org>
Daniel Barkalow schrieb:
> +NAME
> +----
> +git-vcs-* - Helper programs for interoperation with foreign systems
> +
> +SYNOPSIS
> +--------
> +'git vcs-<system>' <command> [options] [arguments]
The current rule is that helper programs have double-dash in the name:
git-rebase--interactive, git-web--browse, etc.
-- Hannes
^ permalink raw reply
* "git add sub1/ sub2/" doesn't work as expected when sub1 and sub2 has .git under them
From: Ping Yin @ 2009-01-12 8:36 UTC (permalink / raw)
To: Git Mailing List
Assume directories sub1 and sub2 have .git under them. "git add sub1/"
works as expected (files under sub1/ are added), howerver "git add
sub1/ sub2/" doesn't work as expeced (sub1 and sub2 are added as
submoudle).
$ git --version git version 1.6.0.4.617.g2baf1
# create repo super
$ mkdir super && cd super && git init && git commit --allow-empty -m
"Initial commit"
# create repo super/sub1 with file sub1-file
$ mkdir sub1 && cd sub1 && touch sub1-file
$ git init && git add . && git commit -m "Initial commit" && cd ..
# create repo super/sub2 with file sub2-file
$ mkdir sub2 && cd sub2 && touch sub2-file
$ git init && git add . && git commit -m "Initial commit" && cd ..
# to intend to add files under sub1 and sub2, but submodules are added
$ git add sub1/ sub2/
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: sub1
# new file: sub2
#
$ git rm --cached sub1 sub2
# to intend add files under sub1, ok
$ gtad sub1/
$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: sub1/sub1-file
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# sub2/
Ping Yin
^ permalink raw reply
* Re: Recent annoying problem with Linus's git repository?
From: Marco Roeland @ 2009-01-12 8:29 UTC (permalink / raw)
To: walt; +Cc: git, rmk
In-Reply-To: <20090112075942.GB29673@fiberbit.xs4all.nl>
On Monday January 12th 2009 at 08:59 Marco Roeland wrote:
> The file should probably just be really deleted. Adding Russell to the
> Cc. ;-)
Andrew Price already reported the issue and sent a patch last Wednesday:
http://marc.info/?l=linux-kernel&m=123134235028543&w=2
--
Marco Roeland, who should check all his mailing lists before answering
^ permalink raw reply
* Re: [PATCH 3/4] color-words: refactor to allow for 0-character word boundaries
From: Thomas Rast @ 2009-01-12 8:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901112059340.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 3629 bytes --]
As a side remark, this patch makes a good use-case for --patience, and
is not isomorphic to the other edit-and-move examples; rather it's a
delete-and-edit.
Johannes Schindelin wrote:
> Subject: [PATCH 3/4] color-words: refactor to allow for 0-character word boundaries
I do not think the term "refactor" is accurate. Wikipedia roughly
defines it as a code change that preserves all external semantics by
some standard method, and lists methods such as variable renaming,
common code extraction, etc. You are actually completely replacing
the algorithm "under the hood" with a new one, so no such standard
method applies.
And there is also a tiny semantic change: compare
A: a b c
B: x y z
^^
The old version implicitly generated an empty line at the double
spaces (marked ^^), which subsequently became context and caused the
words to be printed as follows, where <..> is old and [..] is new:
<a b >[x y ] <c>[z]
Your patched version does not generate empty lines for any space
whatsoever, not even for newlines. Thus the result is
<a b c>[x y z]
I think this is actually a good change, since it results in longer
chunks for "entirely rewritten" parts of the diff. It also answers
Junio's question in the other thread:
Junio C Hamano wrote:
>>
>> What happens if the input "language" does not have any inter-word spacing
>> but its words can still be expressed by regexp patterns?
>>
>> ImagineALanguageThatAllowsYouToWriteSomethingLikeThis. Does the mechanism
>> help users who want to do word-diff files written in such a language by
>> outputting:
>>
>> ImagineALanguage<red>That</red><green>Which</green>AllowsYou...
>>
>> when '[A-Z][a-z]*' is given by the word pattern?
Your patch handles this as a side-effect *even if the lines are
indented*, since no sequence of spaces whatsoever is special. (Mine
would have given hard-to-predict results based on the number of
newlines between them, and xdiff's decision whether the newlines or
the words are more valuable as context.)
So I think this is actually an improvement, but the commit message
should point out the change in semantics.
> +static void fn_out_diff_words_aux(void *priv, char *line, unsigned long len)
> {
> + if (line[0] != '@' || parse_hunk_header(line, len,
> + &minus_first, &minus_len, &plus_first, &plus_len))
It would be nice to have a comment here that points out that this
method crucially relies on having context length 0 (just as the old
one crucially relied on having the full text in a single hunk).
> + for (i = 0; i < buffer->text.size; i++) {
> + if (isspace(buffer->text.ptr[i]))
> + continue;
I think it is this coupling of the loops to find a word, and to find a
word _beginning_, that comes back to haunt you in 4/4. If the outer
loop was strictly about the words, you could use the regex match info
to find the beginning in the regex case. This is probably cleaner
than attempting to force an anchored match, since at least the 'grep'
on my system takes '^^foo' to mean 'a "^foo" at the beginning of a
line', so you cannot just unconditionally insert a ^. (Conditionally
inserting one seems even harder.)
These remarks aside (and the last one is the only one of relevance to
the code), this patch would be a vast improvement of the code even if
we weren't discussing it in the context of the regex feature. So FWIW
Acked-by: Thomas Rast <trast@student.ethz.ch>
up to here. I hope we can agree on some sane regex semantics for
4/4...
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: grammar patches not best use of talent
From: jdelstrother @ 2009-01-12 8:54 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87bpudp77t.fsf_-_@jidanni.org>
Wait, "a handful X" is now a legitimate form of "a handful of X"? I
assumed they were due to non-native speakers.
On 1/12/09, jidanni@jidanni.org <jidanni@jidanni.org> wrote:
> I've decided to back out of my plan to patch grammar.
> $ perl -nwle '/\w+\s+handful.*/i&& print $&' Documentation/*|sort -uf
> a handful commits on top of that,
> A handful documentation fixes.
> A handful documentation updates.
> a handful example hooks are copied in the
> a handful fixes to run it
> a handful of examples:
> A handful of sample hooks are installed when
> a handful pack-objects changes to help you cope better
> a handful small fixes to gitweb.
> a handful the real changes in non-zero
> first handful of characters, show the full
> only handful hexdigits prefix.
> only handful hexdigits prefix. Non default number of
> only handful hexdigits prefix. This is
>
> At first some of the above lines irritated me, but who am I to say
> that English must be said like my mom says it, and is never allowed to
> evolve further. Nope, I'll stick to correcting 2+2=3 type things.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* patches in context format ?
From: Christian MICHON @ 2009-01-12 9:00 UTC (permalink / raw)
To: git list
I'm maintaining a git tree of the vim project: this work can be seen
at http://github.com/cmichon/vim
vim patches do not come as unified format, but only as context format
instead (from a "diff -c").
The current solution I have is to use the original patch command,
stage modifications and add new files. I do not like this solution,
because I have to work out the commit messages out of the mbox and I
lose reproducibility. I'm basically maintaining a subset of shell
scripts, the original patches and an artificial way (ugly) to get
timestamps of modifications (for the commit dates).
Instead of this complicated procedure, I'd like to use "git apply" or
"git am", provided I can get git to support "context output format" as
input for patches ?
I guess the answer is no, but has anyone on the list been working on
this ? is there another way to translate from "context" to "unified"
format ?
TIA
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [RFC/PATCH 1/3] tree.c: add support for traversal of submodules
From: Lars Hjemli @ 2009-01-12 9:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr639kyf0.fsf@gitster.siamese.dyndns.org>
On Mon, Jan 12, 2009 at 04:15, Junio C Hamano <gitster@pobox.com> wrote:
> Lars Hjemli <hjemli@gmail.com> writes:
>
>> If the commit referenced by a gitlink is available in the (possibly
>> alternate) object database, read_tree_recursive() is now able to descend
>> into the tree of the linked commit if the flag 'traverse_gitlinks' is
>> turned on.
>>
>> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
>> ---
>> tree.c | 20 +++++++++++++++++---
>> tree.h | 1 +
>> 2 files changed, 18 insertions(+), 3 deletions(-)
>>
>> diff --git a/tree.c b/tree.c
>> index 03e782a..1468e10 100644
>> --- a/tree.c
>> +++ b/tree.c
>> @@ -7,6 +7,7 @@
>> #include "tree-walk.h"
>>
>> const char *tree_type = "tree";
>> +int traverse_gitlinks = 0;
>
> I think we tend to put these global settings that will affect everybody in
> environment.c. You do not have to initialize variable to zero; BSS will
> take care of it.
Ok, I'll add a proper interface in environment.c for this setting.
> When the user explicitly asks you to traverse into submodules and the
> necessary commit is not available in a submodule, the code goes on without
> complaining. I am not saying it is bad, but I wonder if we would want to
> distinguish these three cases:
>
> (1) the submodule is initialized and the necessary commit is there.
>
> (2) the submodule is initialized, but the necessary commit is missing.
>
> (3) the submodule is not even initialized (aka "the user is not
> interested in it"); there is only an empty directory.
>
> I think it is perfectly fine not to say anything for (3) but I am unsure
> about the second case.
Do we want to impose the porcelainish rules of git-submodule
(.gitmodules, .git/config) in read_tree_recursive()?
If so, I guess a new submodule.h might provide something like this
(disclaimer: coded in gmail):
struct submodule {
int interesting:1;
char *name;
char *url;
char **objectdirs;
char **paths;
}
typedef int (*submodule_cb)(struct submodule *submodule, void *data);
int load_submodule_config();
struct submodule *get_submodule_from_path(char *path);
int add_submodule_objectdb(struct submodule *item);
int for_each_submodule(submodule_cb cb, void *data);
Then, in read_tree_recursive(), we could check submodule->interesting
to decide if we should follow the gitlink. Also, for bare
repositories, we'd need to support something like
'submodule.<name>.objectdir' in the config file (and .gitmodules must
obviously be read from the objectdb).
If we don't want to impose these rules, the current patch should be
minimally sufficient (the user has to edit
.git/objects/info/alternates by hand and missing submodule commits are
treated as if the submodule is not interesting).
--
larsh
^ permalink raw reply
* [PATCH next] bash completion: refactor diff options
From: Thomas Rast @ 2009-01-12 9:16 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
In-Reply-To: <1231679663-31907-1-git-send-email-trast@student.ethz.ch>
diff, log and show all take the same diff options. Refactor them from
__git_diff and __git_log into a variable, and complete them in
__git_show too.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
js/patience-diff is now in next, so here's a version on top of that.
contrib/completion/git-completion.bash | 38 ++++++++++++++++++-------------
1 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index dee75b5..39ae7a3 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -759,25 +759,30 @@ _git_describe ()
__gitcomp "$(__git_refs)"
}
-_git_diff ()
-{
- __git_has_doubledash && return
-
- local cur="${COMP_WORDS[COMP_CWORD]}"
- case "$cur" in
- --*)
- __gitcomp "--cached --stat --numstat --shortstat --summary
+__git_diff_common_options="--stat --numstat --shortstat --summary
--patch-with-stat --name-only --name-status --color
--no-color --color-words --no-renames --check
--full-index --binary --abbrev --diff-filter=
- --find-copies-harder --pickaxe-all --pickaxe-regex
+ --find-copies-harder
--text --ignore-space-at-eol --ignore-space-change
--ignore-all-space --exit-code --quiet --ext-diff
--no-ext-diff
--no-prefix --src-prefix= --dst-prefix=
- --base --ours --theirs
--inter-hunk-context=
--patience
+ --raw
+"
+
+_git_diff ()
+{
+ __git_has_doubledash && return
+
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--cached --pickaxe-all --pickaxe-regex
+ --base --ours --theirs
+ $__git_diff_common_options
"
return
;;
@@ -960,17 +965,16 @@ _git_log ()
--relative-date --date=
--author= --committer= --grep=
--all-match
- --pretty= --name-status --name-only --raw
+ --pretty=
--not --all
--left-right --cherry-pick
--graph
- --stat --numstat --shortstat
- --decorate --diff-filter=
- --color-words --walk-reflogs
+ --decorate
+ --walk-reflogs
--parents --children --full-history
--merge
--inter-hunk-context=
- --patience
+ $__git_diff_common_options
"
return
;;
@@ -1475,7 +1479,9 @@ _git_show ()
return
;;
--*)
- __gitcomp "--pretty="
+ __gitcomp "--pretty=
+ $__git_diff_common_options
+ "
return
;;
esac
--
tg: (f5cbdbb..) t/bash-complete-show (depends on: origin/next)
^ permalink raw reply related
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Alex Riesen @ 2009-01-12 9:17 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis
In-Reply-To: <200901120246.28364.jnareb@gmail.com>
2009/1/12 Jakub Narebski <jnareb@gmail.com>:
> Do you have any suggestions to bypass this block for git? I have access
> to Linux shell account (no root access, though) which doesn't have
> problems with repo.or.cz, so I think I could set up SSH tunnel: but
> how? And what to do with access via git:// - move to SSH too?
See man ssh, look for -L. It works for arbitrary ports, so you can redirect
git:// port to anywhere. Same for push over ssh, just give another port when
connecting.
^ permalink raw reply
* Re: Lightweight tag ?
From: Francis Moreau @ 2009-01-12 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v63klsgf5.fsf@gitster.siamese.dyndns.org>
Hello,
Junio C Hamano <gitster@pobox.com> writes:
> Don't use explicit --tags blindly. It says "no matter what kind of tag,
> transfer everything under refs/tags". Otherwise you won't see a
> difference.
Well:
$ git --version
git version 1.6.0.4
$ mkdir test-tag
$ cd test-tag/
$ date > A
$ git init
Initialized empty Git repository in
/home/fmoreau/tmp/git/test-tag/.git/
$ git add .
$ git commit -a -s -m "Init"
Created initial commit be8750e: Init
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 A
$ cd ..
$ git clone --bare test-tag test-tag.git
Initialized empty Git repository in /home/fmoreau/tmp/git/test-tag.git/
$ cd test-tag
$ git tag light
$ git tag -a -m "Annoted tag" annoted
$ git push ../test-tag.git
Everything up-to-date
$ git push --tags ../test-tag.git
Counting objects: 1, done.
Writing objects: 100% (1/1), 166 bytes, done.
Total 1 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (1/1), done.
To ../test-tag.git
* [new tag] annoted -> annoted
* [new tag] light -> light
It looks like they're no difference for git-push...
That said the documentation about this is rather cryptic IMHO:
,----[ man git-push ]
| --tags
| All refs under $GIT_DIR/refs/tags are pushed, in
| addition to refspecs explicitly listed on the command
| line.
`----
>From a user point of view, the word lightweight is missing here. Why
not simply saying:
,----
| All kind of tags are pushed with this option _otherwise_ only annoted
| tags are pushed
`----
thanks
--
Francis
^ permalink raw reply
* Re: Help! My ISP blocks repo.or.cz. How to push changes?
From: Asheesh Laroia @ 2009-01-12 9:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200901120246.28364.jnareb@gmail.com>
This is a little off-topic, but you CC:d the git list first. (-;
On Mon, 12 Jan 2009, Jakub Narebski wrote:
> The ISP I use (Telekomunikacja Polska S.A., aka TP) made some
> unannounced changes for ADSL service (Neostrada) which made it block
> repo.or.cz (and of course its aliases, including git.or.cz where git
> wiki resides). It blocks also gimp.org and some Polish IRC servers
> (irc.freenode.org on which #git resides works O.K.). People speculate
> that this blocking was based on MAPS (Mail Abuse Prevention System,
> which is SPAM backwards) lists to fight SPAM and/or to block botnets,
> and uses null routing (IP based) blocking. I have no idea why repo.or.cz
> is blocked: gimp.org is supposedly blocked because it hosts
> irc.gimp.org on the same IP. By block I mean that even ping doesn't
> work (no reply at all).
That's horrifying.
> I can access git wiki via one of many free HTTP proxies; currently I use
> http://www.4proxy.de so there are only slight problems there.
>
> The problems is with fetching (via git:// protocol) of forks of git
> repository on repo.or.cz, and pushing (via SSH) to a few of my git
> repositories hosted on repo.or.cz.
>
> Do you have any suggestions to bypass this block for git? I have access
> to Linux shell account (no root access, though) which doesn't have
> problems with repo.or.cz, so I think I could set up SSH tunnel: but
> how? And what to do with access via git:// - move to SSH too?
$ ssh -D 1080 user@host
In a a separate terminal:
$ cat > /tmp/tsocks.conf
# Here we have a config for tsocks that uses localhost:1080 as SOCKS5.
server = 127.0.0.1
# Server type defaults to 4 so we need to specify it as 5 for this one
server_type = 5
# The port defaults to 1080 but I've stated it here for clarity
server_port = 1080
^D
$ export TSOCKS_CONF_FILE=/tmp/tsocks.conf
$ tsocks lynx http://repo.or.cz/
You would need the 'tsocks' tool for your client system. Note that the
remote system doesn't need any configuration this way. Just prefix any
command-line operations that involve repo.or.cz with 'tsocks' and be sure
to set TSOCKS_CONF_FILE. (On a Windows machine, use putty's graphical SSH
client and FreeCap <http://www.freecap.ru/eng/>.
Once you have the 'ssh -D' tunnel running, you can use it in Firefox as a
SOCKS proxy: host = localhost, port = 1080.
-- Asheesh.
--
Don't relax! It's only your tension that's holding you together.
^ permalink raw reply
* Re: patches in context format ?
From: Junio C Hamano @ 2009-01-12 9:28 UTC (permalink / raw)
To: Christian MICHON; +Cc: git list
In-Reply-To: <46d6db660901120100g7f62a0c2k68c96cbfc23dab5@mail.gmail.com>
"Christian MICHON" <christian.michon@gmail.com> writes:
> I'm maintaining a git tree of the vim project: this work can be seen
> at http://github.com/cmichon/vim
>
> vim patches do not come as unified format, but only as context format
> instead (from a "diff -c").
> ...
> I guess the answer is no, but has anyone on the list been working on
> this ? is there another way to translate from "context" to "unified"
> format ?
Not that I know of.
If you want to add support for the copied context format patches to your
workflow, I think the first step (and easiest one) would be to find an
external program that lets you convert from the copied context format to
the unified context format. Perhaps "interdiff /dev/null copied >unified"
would suffice (but I haven't tested this).
Then find the place that feeds "git apply" with a patch, and add an option
to "git am" to instead do something like this:
- git apply --index "$dotest/patch"
+ case "$input_is_in_the_copied_context_format"
+ yes)
+ interdiff /dev/null "$dotest/patch" | git apply --index
+ ;;
+ *)
+ # unified context as before...
+ git apply --index "$dotest/patch"
+ ;;
+ esac
In the longer term, if we were to update "git-apply" to support the copied
context format, I think we should take the same approach.
Inside read_patch_file(), you detect that the patch is in the copied
context format, and convert it to the unified context format and return
the result. All the rest of the program can then be left alone and you
will have little chance of regression.
^ permalink raw reply
* Re: patches in context format ?
From: Teemu Likonen @ 2009-01-12 9:34 UTC (permalink / raw)
To: Christian MICHON; +Cc: git list
In-Reply-To: <46d6db660901120100g7f62a0c2k68c96cbfc23dab5@mail.gmail.com>
Christian MICHON (2009-01-12 10:00 +0100) wrote:
> is there another way to translate from "context" to "unified" format ?
Well, this is not exactly the best solution for a Vim user but this is
the only way I know. Emacs can convert diffs between the formats. You
don't even need to launch Emacs, just run it in batch mode:
$ emacs --batch -Q --file input.diff \
--eval '(diff-context->unified (point-min) (point-max))' \
--eval '(save-buffer)'
^ 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