* Re: Removing a commit from a local branch
From: Sitaram Chamarty @ 2009-01-12 1:20 UTC (permalink / raw)
To: git
In-Reply-To: <a038bef50901111442y16695664y4fed7cdd9d8af27@mail.gmail.com>
On 2009-01-11, Chris Packham <judge.packham@gmail.com> wrote:
> Consider the following example. The maintainer has the
> following branch locally
>
> todeliver: A-B-C-D
>
> He is happy with commits A, C and D but wants to reject B. Ideally I
> want to be able to say
> git rebase --onto <parent of B> <child of B> todelvier
>
> and get
> todeliver: A-C'-D'
you have an off-by-one error here. You need B, not child of
B. Problem solved :-)
^ permalink raw reply
* [BUG/RFH] gitweb: Trouble with ref markers being hyperlinks because of illegally nested links
From: Jakub Narebski @ 2009-01-12 1:15 UTC (permalink / raw)
To: git; +Cc: Giuseppe Bilotta
Commit 4afbaef by Giuseppe Bilotta (gitweb: ref markers link to named
shortlogs) turned ref markers for tags and heads into links to
appropriate views for the ref name.
Unfortunately the code didn't take into account the fact that nesting
links (A elements) is illegal in (X)HTML:
12.2.2 Nested links are illegal
Links and anchors defined by the A element must not be nested;
an A element must not contain any other A elements.
(from http://www.w3.org/TR/html401/struct/links.html#h-12.2.2), and that
some browsers (e.g. Mozilla 1.17.2 I still use) in the very strict
conformance mode (application/xhtml+xml mimetype and XML + XHTML DTD)
_enforce_ this requirement by moving inner link immediately outside the
end of outer link, i.e. for the HTML source looking like the following
<a ...> some text <a ...>v1.5.1</a></a>
rendered HTML (which you can see using "View Selection Source") is
instead
<a ...> some text </a><a ...>v1.5.1</a>
And of course SPAN elements which wraps inner link (inner A element) is
_not_ moved.
This is quite easy to fix for hyperlinked ref markers in 'shortlog' and
'history' views: just close the "title" hyperlink before printing
$extra, i.e. ref markers. I have even made a patch doing that. Then
instead of incorrect
_Merge branch into maint_ [] _maint_
where _aaa_ means that 'aaa' is hyperlink, and [xxx] is a fer marker,
we will have correct:
_Merge branch into maint_ [_maint_]
See that we have two separate and not nested links...
What is more complicated is the issue of ref marker from
git_print_header_div e.g. in 'commit'/'commitdiff' view, and in 'log'
view. There link is made into block element using "display: block;"
CSS rule (div.title, a.title), so that you can click _anywhere_ on the
header block. This breaks layout even worse, making hyperlinked ref
marker text appear *below* header div:
-----------------------------------------------------------
|_Merge branch into maint_ [] |
-----------------------------------------------------------
_maint_
To preserve current layout and behavior it would be needed to do some
deep HTML + CSS positioning hackery, perhaps with additional link block
without any text... But I don't know exactly how to do this; all [few]
experiments I did failed.
I see possible the following alternate solutions:
* Ignore this issue (e.g. if it does not affect modern browsers)
* Revert 4afbaef (we lose feature, but how often used is it?)
* Always use quirks mode, or check browser and use quirks mode if it
would break layout
* Use extra divs and links and CSS positioning to make layout which
looks like current one, and behaves as current one, but is more
complicated.
P.S. From what I have checked neither kernel.org nor repo.or.cz
have this issue.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Minimum required version of subversion for git-svn?
From: Eric Wong @ 2009-01-12 1:03 UTC (permalink / raw)
To: Tom G. Christensen; +Cc: git
In-Reply-To: <496722CF.1060802@statsbiblioteket.dk>
"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..." ?
Thanks.
--
Eric Wong
^ permalink raw reply
* Recent annoying problem with Linus's git repository?
From: walt @ 2009-01-12 0:42 UTC (permalink / raw)
To: git
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?
Thanks!
^ permalink raw reply
* [RFC/PATCH 3/3] builtin-ls-tree: enable traversal of submodules
From: Lars Hjemli @ 2009-01-11 23:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1231717555-10559-3-git-send-email-hjemli@gmail.com>
The option '--submodules', which implies '-r', activates the traversal
of all submodules for which the linked commit is reachable.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
builtin-ls-tree.c | 23 ++++++++---------------
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index cb61717..8a1db54 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -23,7 +23,7 @@ static int chomp_prefix;
static const char *ls_tree_prefix;
static const char ls_tree_usage[] =
- "git ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] <tree-ish> [path...]";
+ "git ls-tree [-d] [-r] [-t] [-l] [-z] [--name-only] [--name-status] [--full-name] [--abbrev[=<n>]] [--submodules] <tree-ish> [path...]";
static int show_recursive(const char *base, int baselen, const char *pathname)
{
@@ -63,20 +63,8 @@ static int show_tree(const unsigned char *sha1, const char *base, int baselen,
unsigned long size;
if (S_ISGITLINK(mode)) {
- /*
- * Maybe we want to have some recursive version here?
- *
- * Something similar to this incomplete example:
- *
- if (show_subprojects(base, baselen, pathname)) {
- struct child_process ls_tree;
-
- ls_tree.dir = base;
- ls_tree.argv = ls-tree;
- start_command(&ls_tree);
- }
- *
- */
+ if (show_recursive(base, baselen, pathname))
+ retval = READ_TREE_RECURSIVE;
type = commit_type;
} else if (S_ISDIR(mode)) {
if (show_recursive(base, baselen, pathname)) {
@@ -168,6 +156,11 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
abbrev = DEFAULT_ABBREV;
break;
}
+ if (!strcmp(argv[1]+2, "submodules")) {
+ ls_options |= LS_RECURSIVE;
+ traverse_gitlinks = 1;
+ break;
+ }
/* otherwise fallthru */
default:
usage(ls_tree_usage);
--
1.6.1.81.g1df1.dirty
^ permalink raw reply related
* [RFC/PATCH 2/3] archive.c: enable traversal of submodules
From: Lars Hjemli @ 2009-01-11 23:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1231717555-10559-2-git-send-email-hjemli@gmail.com>
The option --submodules can be used to activate traversal of sub-
modules when creating archives.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
archive.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/archive.c b/archive.c
index 9ac455d..973dde4 100644
--- a/archive.c
+++ b/archive.c
@@ -262,6 +262,8 @@ static int parse_archive_args(int argc, const char **argv,
OPT_STRING(0, "format", &format, "fmt", "archive format"),
OPT_STRING(0, "prefix", &base, "prefix",
"prepend prefix to each pathname in the archive"),
+ OPT_BOOLEAN(0, "submodules", &traverse_gitlinks,
+ "include reacheable submodules"),
OPT__VERBOSE(&verbose),
OPT__COMPR('0', &compression_level, "store only", 0),
OPT__COMPR('1', &compression_level, "compress faster", 1),
--
1.6.1.81.g1df1.dirty
^ permalink raw reply related
* Re: Removing a commit from a local branch
From: Chris Packham @ 2009-01-12 0:12 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20090111225220.GB15533@atjola.homenet>
Thanks thats exactly what I was after.
On Mon, Jan 12, 2009 at 11:52 AM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> On 2009.01.12 11:42:24 +1300, Chris Packham wrote:
>> Hi List,
>>
>> I'm part of a development team using git. We use a maintainer model
>> where developers send patches/pull requests to a maintainer who
>> applies the patches to a local branch, decides if they're good or not
>> and pushes the good patches to the public repository.
>>
>> What I want to do is script the removal of a bad patch so that the
>> maintainer identifies a patch in his local branch, sends an email to
>> the author telling them why their patch is being rejected then removes
>> the commit for that patch. Using git log a script can extract the
>> author email address, hash and headline of each commit. Based on that
>> information scripting the email is easy enough. Now I come to using
>> git rebase to remove the bad commit based on its hash which leads me
>> to my question - How do I refer to a commit based on the hash of its
>> parent?
>>
>> Consider the following example. The maintainer has the following branch locally
>>
>> todeliver: A-B-C-D
>>
>> He is happy with commits A, C and D but wants to reject B. Ideally I
>> want to be able to say
>> git rebase --onto <parent of B> <child of B> todelvier
>
> You don't want <child of B> there, just B.
>
> git rebase --onto <onto> <upstream> <branch>
>
> Rebases the commits from the range <upstream>..<branch>, and that
> _excludes_ the commit (referenced by) <upstream>.
>
> So:
> git rebase --onto B^ B todeliver
>
> Works on: B..todeliver == todeliver --not B
> And that range contains commits C and D.
>
> Björn
>
^ permalink raw reply
* [RFC/PATCH 0/3] Enable in-process submodule traversal
From: Lars Hjemli @ 2009-01-11 23:45 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
This patch series implements basic support for traversing the tree objects
in submodules when the linked commit object is reachable. Normally such
linked commit objects will not be reachable in the containing repository,
but adding local copies of submodule repositories as alternate object
databases for the containing repo solves this issue.
The first patch in the series does all the 'hard work' required for the
traversal to work, while the next two patches adds a '--submodules' flag
to git-archive and git-ls-tree as proof of concept.
Lars Hjemli (3):
tree.c: add support for traversal of submodules
archive.c: enable traversal of submodules
builtin-ls-tree: enable traversal of submodules
archive.c | 2 ++
builtin-ls-tree.c | 23 ++++++++---------------
tree.c | 20 +++++++++++++++++---
tree.h | 1 +
4 files changed, 28 insertions(+), 18 deletions(-)
^ permalink raw reply
* Re: git-svn: File was not found in commit
From: Morgan Christiansson @ 2009-01-12 0:04 UTC (permalink / raw)
To: git
In-Reply-To: <20090111215526.GA15533@atjola.homenet>
Björn Steinbrink wrote:
> On 2009.01.09 18:19:01 +0100, Morgan Christiansson wrote:
>
>> ------------------------------------------------------------------------
>> r10577 | morgan | 2008-11-28 18:31:00 +0000 (Fri, 28 Nov 2008) | 3 lines
>> Changed paths:
>> A /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/FETCH_HEAD
>> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/config
>> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/index
>> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/HEAD
>> M /branches/rails/rails/vendor/plugins/acts_as_xapian/.git/logs/refs/heads/master
>> # -- THIS FILE --
>>
> Unless I totally misread that line, SVN reports that the file was
> _modified_, not added. For the file to be modified, it seems reasonable
> to expect that it existed in the previous commit.
>
> Is there anything "special" about how that file came into existence in
> that branch? Without further knowledge, that looks like a svn bug, but
> hey, it's svn, it might do funny stuff on purpose ;-)
>
> Maybe you could provide a small test case/repo?
>
> Björn
>
Something odd happened when "git svn fetch" was adding r10559 to git:
A rails/vendor/plugins/acts_as_xapian/README.txt
A rails/vendor/plugins/acts_as_xapian/.cvsignore
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/refs/heads/master
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/refs/remotes/origin/HEAD
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/refs/remotes/origin/master
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/HEAD
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/description
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/update
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/post-receive
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/post-update
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/pre-rebase
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/hooks/prepare-commit-msg
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/applypatch-msg
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/pre-applypatch
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/post-commit
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/commit-msg
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/hooks/pre-commit
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/logs/refs/heads/master
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/logs/refs/remotes/origin/HEAD
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/logs/refs/remotes/origin/master
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/logs/HEAD
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/config
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/index
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/objects/pack/pack-570449ffe8ce399eca81f286cf942e51ace03448.pack
Ignoring path
rails/vendor/plugins/acts_as_xapian/.git/objects/pack/pack-570449ffe8ce399eca81f286cf942e51ace03448.idx
Ignoring path rails/vendor/plugins/acts_as_xapian/.git/info/exclude
W: +empty_dir:
branches/rails/rails/vendor/plugins/acts_as_xapian/.git/branches
W: +empty_dir:
branches/rails/rails/vendor/plugins/acts_as_xapian/.git/objects/info
W: +empty_dir:
branches/rails/rails/vendor/plugins/acts_as_xapian/.git/refs/tags
r10559 = 4f33ee36a5d933a62081a76c7788fb46a9e6f0e8 (rails)
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.
#The following commands will create a repository that has this problem:
cd ~
rm -rf gittest*
svnadmin create gittest-repo
svn co file:///$HOME/gittest-repo gittest-checkout
cd gittest-checkout
mkdir -p .git
touch .git/file
svn add .git
svn commit -m "Create .git/file"
echo 1 > .git/file
svn commit -m "Modify .git/file"
# The following will try to import the repository, which fails.
cd ~
mkdir gittest
cd gittest
git svn init file:///$HOME/gittest-repo
git svn fetch
# Output:
$ git svn fetch
A .git/file
Ignoring path .git/file
r1 = ccc56451d54315bd253b65c514351e996fbe880e (git-svn)
.git/file was not found in commit
ccc56451d54315bd253b65c514351e996fbe880e (r1)
# Cleanup
rm -rf gittest gittest-repo gittest-checkout
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.
^ permalink raw reply
* [PATCH v2 1/4] Add color_fwrite(), a function coloring each line individually
From: Johannes Schindelin @ 2009-01-11 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Rast
In-Reply-To: <alpine.DEB.1.00.0901120048430.3586@pacific.mpi-cbg.de>
We have to set the color before every line and reset it before every
newline. Add a function color_fwrite() which does that for us.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
color.c | 28 ++++++++++++++++++++++++++++
color.h | 1 +
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/color.c b/color.c
index fc0b72a..b028880 100644
--- a/color.c
+++ b/color.c
@@ -191,3 +191,31 @@ int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...)
va_end(args);
return r;
}
+
+/*
+ * This function splits the buffer by newlines and colors the lines individually.
+ *
+ * Returns 0 on success.
+ */
+int color_fwrite_lines(FILE *fp, const char *color,
+ size_t count, const char *buf)
+{
+ if (!*color)
+ return fwrite(buf, count, 1, fp) != 1;
+ while (count) {
+ char *p = memchr(buf, '\n', count);
+ if (fputs(color, fp) < 0 ||
+ fwrite(buf, p ? p - buf : count, 1, fp) != 1 ||
+ fputs(COLOR_RESET, fp) < 0)
+ return -1;
+ if (!p)
+ return 0;
+ if (fputc('\n', fp) < 0)
+ return -1;
+ count -= p + 1 - buf;
+ buf = p + 1;
+ }
+ return 0;
+}
+
+
diff --git a/color.h b/color.h
index 6cf5c88..cd5c985 100644
--- a/color.h
+++ b/color.h
@@ -19,5 +19,6 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
void color_parse(const char *var, const char *value, char *dst);
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
+int color_fwrite_lines(FILE *fp, const char *color, size_t count, const char *buf);
#endif /* COLOR_H */
--
1.6.1.223.g50c8f
^ permalink raw reply related
* Re: [PATCH 1/4] Add color_fwrite(), a function coloring each line individually
From: Johannes Schindelin @ 2009-01-11 23:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Rast
In-Reply-To: <7vwsd1o44i.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > +/*
> > + * This function splits the buffer by newlines and colors the lines individually.
> > + */
> > +void color_fwrite(FILE *f, const char *color, size_t count, const char *buf)
>
> Is it just me that this is grossly misnamed? It is not about fwrite of
> count bytes starting at buf in the specified color. At list it should be
> called color_fwrite_lines() or something like that.
>
> > diff --git a/color.h b/color.h
> > index 6cf5c88..9fb58f5 100644
> > --- a/color.h
> > +++ b/color.h
> > @@ -19,5 +19,6 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
> > void color_parse(const char *var, const char *value, char *dst);
> > int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
> > int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
> > +void color_fwrite(FILE *f, const char *color, size_t count, const char *buf);
>
> Also if other functions in the family all return int to indicate errors
> and name the FILE * argument fp, I find it a very bad taste not to follow
> their patterns without having a good reason (which I do not see).
Valid points.
Sorry,
Dscho
^ permalink raw reply
* [PATCH] git-svn: add --authors-file test
From: Eric Wong @ 2009-01-11 23:44 UTC (permalink / raw)
To: git
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.
t/t9130-git-svn-authors-file.sh | 94 +++++++++++++++++++++++++++++++++++++++
1 files changed, 94 insertions(+), 0 deletions(-)
create mode 100755 t/t9130-git-svn-authors-file.sh
diff --git a/t/t9130-git-svn-authors-file.sh b/t/t9130-git-svn-authors-file.sh
new file mode 100755
index 0000000..b8fb277
--- /dev/null
+++ b/t/t9130-git-svn-authors-file.sh
@@ -0,0 +1,94 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Eric Wong
+#
+
+test_description='git svn authors file tests'
+
+. ./lib-git-svn.sh
+
+cat > svn-authors <<EOF
+aa = AAAAAAA AAAAAAA <aa@example.com>
+bb = BBBBBBB BBBBBBB <bb@example.com>
+EOF
+
+test_expect_success 'setup svnrepo' '
+ for i in aa bb cc dd
+ do
+ svn mkdir -m $i --username $i "$svnrepo"/$i
+ done
+ '
+
+test_expect_success 'start import with incomplete authors file' '
+ ! git svn clone --authors-file=svn-authors "$svnrepo" x
+ '
+
+test_expect_success 'imported 2 revisions successfully' '
+ (
+ cd x
+ test "`git rev-list refs/remotes/git-svn | wc -l`" -eq 2 &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn | \
+ grep "^author BBBBBBB BBBBBBB <bb@example\.com> " &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn~1 | \
+ grep "^author AAAAAAA AAAAAAA <aa@example\.com> "
+ )
+ '
+
+cat >> svn-authors <<EOF
+cc = CCCCCCC CCCCCCC <cc@example.com>
+dd = DDDDDDD DDDDDDD <dd@example.com>
+EOF
+
+test_expect_success 'continues to import once authors have been added' '
+ (
+ cd x
+ git svn fetch --authors-file=../svn-authors &&
+ test "`git rev-list refs/remotes/git-svn | wc -l`" -eq 4 &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn | \
+ grep "^author DDDDDDD DDDDDDD <dd@example\.com> " &&
+ git rev-list -1 --pretty=raw refs/remotes/git-svn~1 | \
+ grep "^author CCCCCCC CCCCCCC <cc@example\.com> "
+ )
+ '
+
+test_expect_success 'authors-file against globs' '
+ svn mkdir -m globs --username aa \
+ "$svnrepo"/aa/trunk "$svnrepo"/aa/branches "$svnrepo"/aa/tags &&
+ git svn clone --authors-file=svn-authors -s "$svnrepo"/aa aa-work &&
+ for i in bb ee cc
+ do
+ branch="aa/branches/$i"
+ svn mkdir -m "$branch" --username $i "$svnrepo/$branch"
+ done
+ '
+
+test_expect_success 'fetch fails on ee' '
+ ( cd aa-work && ! git svn fetch --authors-file=../svn-authors )
+ '
+
+tmp_config_get () {
+ GIT_CONFIG=.git/svn/.metadata git config --get "$1"
+}
+
+test_expect_success 'failure happened without negative side effects' '
+ (
+ cd aa-work &&
+ test 6 -eq "`tmp_config_get svn-remote.svn.branches-maxRev`" &&
+ test 6 -eq "`tmp_config_get svn-remote.svn.tags-maxRev`"
+ )
+ '
+
+cat >> svn-authors <<EOF
+ee = EEEEEEE EEEEEEE <ee@example.com>
+EOF
+
+test_expect_success 'fetch continues after authors-file is fixed' '
+ (
+ cd aa-work &&
+ git svn fetch --authors-file=../svn-authors &&
+ test 8 -eq "`tmp_config_get svn-remote.svn.branches-maxRev`" &&
+ test 8 -eq "`tmp_config_get svn-remote.svn.tags-maxRev`"
+ )
+ '
+
+test_done
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH 3/4] color-words: refactor to allow for 0-character word boundaries
From: Johannes Schindelin @ 2009-01-11 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Thomas Rast
In-Reply-To: <7viqolo2z9.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 11 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This code was ugly, for a number of reasons:
> > ...
> > Fix all of these issues by processing the text such that
>
> Looks much cleaner than the original. I didn't compare it with
> Thomas's, but it seems he found some breakages, so I'd expect a second
> round sometime in the future.
Certainly,
Dscho
^ permalink raw reply
* Re: [PATCH v3 3/4] word diff: make regex configurable via attributes
From: Junio C Hamano @ 2009-01-11 23:20 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Johannes Schindelin, Teemu Likonen
In-Reply-To: <72242bd75fa8d55c2afc723f8539ef56f2569d3e.1231669012.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Make the --color-words splitting regular expression configurable via
> the diff driver's 'wordregex' attribute. The user can then set the
> driver on a file in .gitattributes. If a regex is given on the
> command line, it overrides the driver's setting.
> ...
> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
> index 6152d5b..d22c06b 100644
> --- a/Documentation/diff-options.txt
> +++ b/Documentation/diff-options.txt
> @@ -96,7 +96,9 @@ endif::git-format-patch[]
> By default, a new word only starts at whitespace, so that a
> 'word' is defined as a maximal sequence of non-whitespace
> characters. The optional argument <regex> can be used to
> - configure this.
> + configure this. It can also be set via a diff driver, see
> + linkgit:gitattributes[1]; if a <regex> is given explicitly, it
> + overrides any diff driver setting.
> +
> The <regex> must be an (extended) regular expression. When set, every
> non-overlapping match of the <regex> is considered a word. (Regular
One bikeshedding I think is better to get over with is that this probably
should be called xwordregex for consistency with xfuncname where 'x'
variant means POSIX ERE and the one without means POSIX BRE, even if we
are not going to support diff.wordregex that uses BRE.
I am assuming [3/4] can be trivially adjusted if we were to adopt the
clean-up approach Dscho is taking?
^ permalink raw reply
* Re: [PATCH 3/4] color-words: refactor to allow for 0-character word boundaries
From: Junio C Hamano @ 2009-01-11 23:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Thomas Rast
In-Reply-To: <alpine.DEB.1.00.0901112059340.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This code was ugly, for a number of reasons:
> ...
> Fix all of these issues by processing the text such that
Looks much cleaner than the original. I didn't compare it with Thomas's,
but it seems he found some breakages, so I'd expect a second round
sometime in the future.
^ permalink raw reply
* Re: stopping patches from just floating by
From: Junio C Hamano @ 2009-01-11 23:06 UTC (permalink / raw)
To: jidanni; +Cc: barkalow, git
In-Reply-To: <874p05k1ie.fsf@jidanni.org>
jidanni@jidanni.org writes:
> I see. Say, for my forthcoming 40 minor grammar fixes that affect 20
> files in Documentation/*, I just couldn't bear spamming this list with
> more that one or two [PATCH] mails. OK one long mail it will be then,
> with several commits encompassing many diffs. Hope that will be OK.
It probably won't be Ok, as earlier documentation patches from you that
were smaller had good bits that were applied and not so good bits that
were dropped, and I'd refuse to pick and choose only good bits from one
single large patch myself. The tradeoff between "minor grammar fixes" and
my time spent to do so is not good enough.
Please send in small isolated pieces so that people do not have to comment
"in this patch, this and that rewordings are very good clarification, but
this other hunk adds noise without adding much signal".
And by "isolated", I do not mean "one mail per patched file".
For example, if you fix many misused 3rd person singular verbs that ends
with 's' that are used for subject that is not 3rd person singular, that
is one topic and one patch can fix an error of that kind in all of 20
files.
On the other hand, if you conflate such a fix with a new explanation of an
option (which may or may not be adding more noise than the signal) to the
same file in a single e-mailed patch, you will force people to say "this
part is good but that part is not". That's not the isolation I am
referring to.
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Pierre Habouzit @ 2009-01-11 23:02 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Sam Ravnborg, Linus Torvalds, Christian Borntraeger,
Johannes Schindelin, git, Linux Kernel Mailing List
In-Reply-To: <f19298770901111147t625a2161t779bfcfc0317225c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]
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.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/4] refactor the --color-words to make it more hackable
From: Johannes Schindelin @ 2009-01-11 23:02 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200901112253.27165.trast@student.ethz.ch>
Hi,
On Sun, 11 Jan 2009, Thomas Rast wrote:
> Johannes Schindelin wrote:
> >
> > But at least _I_ think it is easy to follow, and it actually makes the code
> > more readable/hackable. Correct me if I'm wrong.
>
> It indeed seems a sane approach.
Thanks.
> 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.
Unfortunately, this includes a newline which utterly confuses the diff,
and therefore the code that tries to get the true offsets.
Consequently, it crashes.
> Plain --color-words is not affected.
Of course, I did not change anything outside the code path of
--color-words.
Ciao,
Dscho
-- snipsnap --
[PATCH] color-words: \n must not be a part of the word.
Allowing \n as part of a word is a pilot error, but that is not a
reason for the code to crash.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
diff.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index d6bba72..676eb79 100644
--- a/diff.c
+++ b/diff.c
@@ -381,8 +381,10 @@ static int find_word_boundary(mmfile_t *buffer, int i, regex_t *word_regex)
if (word_regex) {
regmatch_t match[1];
- if (!regexec(word_regex, buffer->ptr + i, 1, match, 0))
- i += match[0].rm_eo;
+ if (!regexec(word_regex, buffer->ptr + i, 1, match, 0)) {
+ char *p = memchr(buffer->ptr + i, '\n', match[0].rm_eo);
+ i = p ? p - buffer->ptr : match[0].rm_eo + i;
+ }
}
else
while (i < buffer->size && !isspace(buffer->ptr[i]))
^ permalink raw reply related
* Re: Removing a commit from a local branch
From: Björn Steinbrink @ 2009-01-11 22:52 UTC (permalink / raw)
To: Chris Packham; +Cc: git
In-Reply-To: <a038bef50901111442y16695664y4fed7cdd9d8af27@mail.gmail.com>
On 2009.01.12 11:42:24 +1300, Chris Packham wrote:
> Hi List,
>
> I'm part of a development team using git. We use a maintainer model
> where developers send patches/pull requests to a maintainer who
> applies the patches to a local branch, decides if they're good or not
> and pushes the good patches to the public repository.
>
> What I want to do is script the removal of a bad patch so that the
> maintainer identifies a patch in his local branch, sends an email to
> the author telling them why their patch is being rejected then removes
> the commit for that patch. Using git log a script can extract the
> author email address, hash and headline of each commit. Based on that
> information scripting the email is easy enough. Now I come to using
> git rebase to remove the bad commit based on its hash which leads me
> to my question - How do I refer to a commit based on the hash of its
> parent?
>
> Consider the following example. The maintainer has the following branch locally
>
> todeliver: A-B-C-D
>
> He is happy with commits A, C and D but wants to reject B. Ideally I
> want to be able to say
> git rebase --onto <parent of B> <child of B> todelvier
You don't want <child of B> there, just B.
git rebase --onto <onto> <upstream> <branch>
Rebases the commits from the range <upstream>..<branch>, and that
_excludes_ the commit (referenced by) <upstream>.
So:
git rebase --onto B^ B todeliver
Works on: B..todeliver == todeliver --not B
And that range contains commits C and D.
Björn
^ permalink raw reply
* Re: Removing a commit from a local branch
From: Jakub Narebski @ 2009-01-11 22:48 UTC (permalink / raw)
To: Chris Packham; +Cc: git, Stephan Beyer
In-Reply-To: <a038bef50901111442y16695664y4fed7cdd9d8af27@mail.gmail.com>
"Chris Packham" <judge.packham@gmail.com> writes:
> Consider the following example. The maintainer has the following
> branch locally
>
> todeliver: A-B-C-D
>
> He is happy with commits A, C and D but wants to reject B. Ideally I
> want to be able to say
> git rebase --onto <parent of B> <child of B> todelvier
>
> and get
> todeliver: A-C'-D'
>
> I know that <parent of B> can be referred to as B~1 but what about
> <child of B>? I've read through the man page for git-rev-parse and
> nothing stands out as child of commit X.
>
> Is there a better what do achieve what I'm after?
Yes, I think it would be easier to either use "git rebase --interactive"
(with some script taking place of EDITOR, or something), or prod Stephan
Beyer (CC-ed) to finish git-sequencer...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/4] Add color_fwrite(), a function coloring each line individually
From: Junio C Hamano @ 2009-01-11 22:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Thomas Rast
In-Reply-To: <alpine.DEB.1.00.0901112058570.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> +/*
> + * This function splits the buffer by newlines and colors the lines individually.
> + */
> +void color_fwrite(FILE *f, const char *color, size_t count, const char *buf)
Is it just me that this is grossly misnamed? It is not about fwrite of
count bytes starting at buf in the specified color. At list it should be
called color_fwrite_lines() or something like that.
> diff --git a/color.h b/color.h
> index 6cf5c88..9fb58f5 100644
> --- a/color.h
> +++ b/color.h
> @@ -19,5 +19,6 @@ int git_config_colorbool(const char *var, const char *value, int stdout_is_tty);
> void color_parse(const char *var, const char *value, char *dst);
> int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
> int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
> +void color_fwrite(FILE *f, const char *color, size_t count, const char *buf);
Also if other functions in the family all return int to indicate errors
and name the FILE * argument fp, I find it a very bad taste not to follow
their patterns without having a good reason (which I do not see).
^ permalink raw reply
* Removing a commit from a local branch
From: Chris Packham @ 2009-01-11 22:42 UTC (permalink / raw)
To: git
In-Reply-To: <a038bef50901111441w21959397tc41922656a25027c@mail.gmail.com>
Hi List,
I'm part of a development team using git. We use a maintainer model
where developers send patches/pull requests to a maintainer who
applies the patches to a local branch, decides if they're good or not
and pushes the good patches to the public repository.
What I want to do is script the removal of a bad patch so that the
maintainer identifies a patch in his local branch, sends an email to
the author telling them why their patch is being rejected then removes
the commit for that patch. Using git log a script can extract the
author email address, hash and headline of each commit. Based on that
information scripting the email is easy enough. Now I come to using
git rebase to remove the bad commit based on its hash which leads me
to my question - How do I refer to a commit based on the hash of its
parent?
Consider the following example. The maintainer has the following branch locally
todeliver: A-B-C-D
He is happy with commits A, C and D but wants to reject B. Ideally I
want to be able to say
git rebase --onto <parent of B> <child of B> todelvier
and get
todeliver: A-C'-D'
I know that <parent of B> can be referred to as B~1 but what about
<child of B>? I've read through the man page for git-rev-parse and
nothing stands out as child of commit X.
Is there a better what do achieve what I'm after?
Thanks,
Chris
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Daniel Barkalow @ 2009-01-11 22:34 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Linus Torvalds, Sam Ravnborg, Christian Borntraeger,
Johannes Schindelin, git, Linux Kernel Mailing List
In-Reply-To: <f19298770901111417t6762e1e3x79b2f488ee6f1243@mail.gmail.com>
On Mon, 12 Jan 2009, Alexey Zaytsev wrote:
> On Sun, Jan 11, 2009 at 23:04, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> >
> > On Sun, 11 Jan 2009, Sam Ravnborg wrote:
> >>
> >> 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.
> >>
> >> It is not like this history would be lost - one just had to look
> >> somewhere else to find it.
> >>
> >> That may be a bad pain/benefit ratio - time will tell.
> >
> > Umm. No.
> >
> > Time is exactly what makes it useful. It will make all the downsides
> > shrink, and the advantages stay.
> >
> >> There should be a way to avoid such pain when bisecting without
> >> having to mark a semi-random (for the average person) commit as good.
> >
> > Well, you don't actually have to mark that semi-random one as good either.
> > What you can do is to just mark anything that _only_ contains fs/btrfs as
> > good. IOW, you don't have to know the magic number - you just have to be
> > told that "oh, if you only have btrfs files, and you're not actively
> > bisecting a btrfs bug, just do 'git bisect good' and continue".
> >
> > Yeah, you'll hit it a few times, but you don't even have to compile things
> > or boot anything, so it's not actually going to be all that much slower
> > than just knowing about the magic point either.
>
> But would not such bug avoid being bisected if you blindly
> mark btrfs commits as good?
>
> v2.6.29 <-- bad
> ...
> ...
> ...
> btrfs stuff <-- mark as good
> ...
> the-real-bug
> ...
> v2.6.28 <-- good
>
> So you hit the btrfs commit, mark it as good, leaving the real bug below,
> and the bisection continues, with both sides being actually bad.
>
> Am I missing something?
Yes, there are no kernel bugs below the btrfs stuff, because there's no
kernel at all below the btrfs stuff. The history is actually like:
A -- B -- C -- D -- G
/
F -- E
F and E are the btrfs stuff, while A-D and G are commit containing the
kernel source (D and G also containing btrfs). Marking E as good cuts off
F, but doesn't cut off anything at all on the top line. Of course, if
you're actually debugging a problem with btrfs that you somehow know to
have worked while btrfs was a separate module at so point, you would want
to get into this history (and would build it as a separate module in order
to do so).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Sam Ravnborg @ 2009-01-11 22:32 UTC (permalink / raw)
To: Alexey Zaytsev
Cc: Linus Torvalds, Christian Borntraeger, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <f19298770901111417t6762e1e3x79b2f488ee6f1243@mail.gmail.com>
On Mon, Jan 12, 2009 at 01:17:31AM +0300, Alexey Zaytsev wrote:
> On Sun, Jan 11, 2009 at 23:04, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> >
> > On Sun, 11 Jan 2009, Sam Ravnborg wrote:
> >>
> >> 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.
> >>
> >> It is not like this history would be lost - one just had to look
> >> somewhere else to find it.
> >>
> >> That may be a bad pain/benefit ratio - time will tell.
> >
> > Umm. No.
> >
> > Time is exactly what makes it useful. It will make all the downsides
> > shrink, and the advantages stay.
> >
> >> There should be a way to avoid such pain when bisecting without
> >> having to mark a semi-random (for the average person) commit as good.
> >
> > Well, you don't actually have to mark that semi-random one as good either.
> > What you can do is to just mark anything that _only_ contains fs/btrfs as
> > good. IOW, you don't have to know the magic number - you just have to be
> > told that "oh, if you only have btrfs files, and you're not actively
> > bisecting a btrfs bug, just do 'git bisect good' and continue".
> >
> > Yeah, you'll hit it a few times, but you don't even have to compile things
> > or boot anything, so it's not actually going to be all that much slower
> > than just knowing about the magic point either.
>
> But would not such bug avoid being bisected if you blindly
> mark btrfs commits as good?
>
> v2.6.29 <-- bad
> ...
> ...
> ...
> btrfs stuff <-- mark as good
> ...
> the-real-bug
> ...
> v2.6.28 <-- good
>
> So you hit the btrfs commit, mark it as good, leaving the real bug below,
> and the bisection continues, with both sides being actually bad.
>
> Am I missing something?
Yep - you miss that people get confused when suddenly they have no kernel source.
Sam
^ permalink raw reply
* Re: current git kernel has strange problems during bisect
From: Daniel Barkalow @ 2009-01-11 22:27 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Linus Torvalds, Sam Ravnborg, Johannes Schindelin, git,
Linux Kernel Mailing List
In-Reply-To: <200901112239.20306.borntraeger@de.ibm.com>
On Sun, 11 Jan 2009, Christian Borntraeger wrote:
> Am Sonntag 11 Januar 2009 schrieb Linus Torvalds:
> > Well, you don't actually have to mark that semi-random one as good either.
> > What you can do is to just mark anything that _only_ contains fs/btrfs as
> > good. IOW, you don't have to know the magic number - you just have to be
> > told that "oh, if you only have btrfs files, and you're not actively
> > bisecting a btrfs bug, just do 'git bisect good' and continue".
>
> That should work.
>
> <rant>
> Still, I am a bit frustrated. During this weekend I reported 2 regressions
> (wlan and ata) and I still try to find out why suspend/resume stopped
> working. In the meantime I have identified 2 patches (one was already known,
> I reported the 2nd to the usb maintainers) after 2.6.28 that caused suspend
> to ram regressions. In rc1 S2R was broken again. So I tried bisecting the
> third patch - which finally brought me to the btrfs bisect problem.
>
> For me, this was the most annoying merge window ever.
>
> In my opinion we should really avoid subtree merges in the future as a curtesy
> to people who do the uncool work of testing, problem tracking and bisecting.
> </rant>
I think hitting a version without the actual kernel source in it should
actually make bisecting easier, not harder; you can say without even
building the kernel that that version doesn't have the problem you're
trying to find, because it doesn't have anything in it.
The alternative to having that part of the tree empty would be to stick in
some kernel version there (probably 2.6.28), and then you'd build and test
2.6.28 again, completely wasting a bunch of time.
Probably the bisect documentation or messages need to make it clear what
you should do when you land on this sort of commit.
-Daniel
*This .sig left intentionally blank*
^ 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