* [BUG (or misfeature?)] git checkout and symlinks
From: Pierre Habouzit @ 2007-07-04 20:35 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
if in a branch [branch1] you track the file: dir1/file1.c
and in the branch [branch2] you track elsewhere/file1.c and dir1 be
symlink on elsewhere, then it's not possible to checkout the branch
[branch1] if your previous checkout was [branch2]. You have to manually
remove the symlink `dir1` else git complains that checkouting branch1
would overwrite dir1/file1.c.
I'm not sure how to fix this, and it's quite painful actually :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Allow rebase to run if upstream is completely merged
From: Johannes Sixt @ 2007-07-04 20:09 UTC (permalink / raw)
To: git
Consider this history:
o--o-...-B <- origin
\ \
x--x--M--x--x <- master
In this situation, rebase considers master fully up-to-date and would
not do anything. However, if there were additional commits on origin,
the rebase would run and move the commits x on top of origin.
Here we change rebase to short-circuit out only if the history since origin
is strictly linear. Consequently, the above as well as a history like this
would be linearized:
o--o <- origin
\
x--x
\ \
x--M--x--x <- master
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-rebase.sh | 8 +++++---
t/t3400-rebase.sh | 39 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index c590661..7a02f29 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -305,10 +305,12 @@ branch=$(git rev-parse --verify "${branch_name}^0") || exit
# Now we are rebasing commits $upstream..$branch on top of $onto
-# Check if we are already based on $onto, but this should be
-# done only when upstream and onto are the same.
+# Check if we are already based on $onto with linear history,
+# but this should be done only when upstream and onto are the same.
mb=$(git merge-base "$onto" "$branch")
-if test "$upstream" = "$onto" && test "$mb" = "$onto"
+if test "$upstream" = "$onto" && test "$mb" = "$onto" &&
+ # linear history?
+ ! git rev-list --parents "$onto".."$branch" | grep " .* " > /dev/null
then
echo >&2 "Current branch $branch_name is up to date."
exit 0
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index 95f3a2a..62205b2 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -12,7 +12,7 @@ This test runs git rebase and checks that the author information is not lost.
export GIT_AUTHOR_EMAIL=bogus_email_address
test_expect_success \
- 'prepare repository with topic branch, then rebase against master' \
+ 'prepare repository with topic branches' \
'echo First > A &&
git update-index --add A &&
git-commit -m "Add A." &&
@@ -24,11 +24,48 @@ test_expect_success \
echo Third >> A &&
git update-index A &&
git-commit -m "Modify A." &&
+ git checkout -b side my-topic-branch &&
+ echo Side >> C &&
+ git add C &&
+ git commit -m "Add C" &&
+ git checkout -b nonlinear my-topic-branch &&
+ echo Edit >> B &&
+ git add B &&
+ git commit -m "Modify B" &&
+ git merge side &&
+ git checkout -b upstream-merged-nonlinear &&
+ git merge master &&
git checkout -f my-topic-branch &&
+ git tag topic
+'
+
+test_expect_success 'rebase against master' '
git rebase master'
test_expect_failure \
'the rebase operation should not have destroyed author information' \
'git log | grep "Author:" | grep "<>"'
+test_expect_success 'rebase after merge master' '
+ git reset --hard topic &&
+ git merge master &&
+ git rebase master &&
+ ! git show | grep "^Merge:"
+'
+
+test_expect_success 'rebase of history with merges is linearized' '
+ git checkout nonlinear &&
+ test 4 = $(git rev-list master.. | wc -l) &&
+ git rebase master &&
+ test 3 = $(git rev-list master.. | wc -l)
+'
+
+test_expect_success \
+ 'rebase of history with merges after upstream merge is linearized' '
+ git checkout upstream-merged-nonlinear &&
+ test 5 = $(git rev-list master.. | wc -l) &&
+ git rebase master &&
+ test 3 = $(git rev-list master.. | wc -l)
+'
+
test_done
--
1.5.3.rc0
^ permalink raw reply related
* Re: git-rm isn't the inverse action of git-add
From: Jan Hudec @ 2007-07-04 20:08 UTC (permalink / raw)
To: Johannes Schindelin, Yann Dirson, Christian Jaeger, git
In-Reply-To: <vpqir91hagz.fsf@bauges.imag.fr>
[-- Attachment #1: Type: text/plain, Size: 1228 bytes --]
On Tue, Jul 03, 2007 at 15:40:12 +0200, Matthieu Moy wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > Hmm. How did you expect then, that git-rm does _not_ lead to data
> > loss?
>
> Because there are tons of possible behaviors for "$VCS rm", and I'd
> expect it to be safe even if VCS=git, since it is with all the other
> VCS I know.
>
> What's wrong with the behavior of "hg rm"?
> What's wrong with the behavior of "svn rm"?
> What's wrong with the behavior of "bzr rm"?
> (no, I won't do it with CVS ;-) )
>
> None of these commands have the problem that git-rm has.
Hm. They all behave roughly the same: They unversion the file and unlink it,
unless it is modified, in which case they unversion it and leave it alone.
Now git has the extra complexity that index contains also content of the
file. But the behaviour can be easily adapted like this (HEAD = version in
HEAD, index = version in index, tree = version in tree):
- if (HEAD == index && index == version) unversion and unlink
- else if (HEAD == index || index == version) unversion
- else print message and do nothing
Would you consider that a sane behaviour?
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Junio C Hamano @ 2007-07-04 19:51 UTC (permalink / raw)
To: Jan Hudec; +Cc: Marco Costalba, git
In-Reply-To: <20070704182806.GA3268@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> On Wed, Jul 04, 2007 at 14:44:16 +0200, Marco Costalba wrote:
>> On 7/4/07, Junio C Hamano <gitster@pobox.com> wrote:
>>> But if a Porcelain like StGIT or Qgit would want to do that kind
>>> of operation for different use case than "amending", it can and
>>> should use plumbing commands, just like the implementation of
>>> "commit --amend" does, with different constraints and error
>>> checks.
>
> I would prefer if there was something between git-commit-tree and git-commit.
> There are several steps one has to do for commit, that are the same for most
> ways of commit:
> - call pre-commit hook (unless --no-verify)
> - write-tree
> - commit-tree
> - update-ref
> - mv next-index index
> - call post-commit hook (unless --no-verify or unconditionally?)
>
> Would factoring out such script from the end of git-commit.sh be accepted?
>
> Or would it be possible to get just that from git-commit with right options?
> Basically I need to replicate the logic with
>
> I would suggest a name git-commit-index. It would take the index to commit,
> index to move in after commit, head to update, list of parents and commit
> message on standard input (as commit-tree does).
Judging from the existing users (am, commit, filter-branch, and
merge), I would say "write-tree then commit-tree then
update-ref" sequence could be made to a new built-in plumbing if
you really wanted to. "mv next-index index" and calling of
hooks definitely do _not_ belong there, though, since the hook
that needs to be called are different, and the caller of such a
plumbing command is very well equipped to do them by themselves
anyway.
^ permalink raw reply
* [StGIT PATCH] Document shortcoming of stg-k and stg-unnew.
From: Yann Dirson @ 2007-07-04 19:18 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
contrib/stg-k | 8 +++++---
contrib/stg-unnew | 3 +++
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/contrib/stg-k b/contrib/stg-k
index 0134c25..62211be 100755
--- a/contrib/stg-k
+++ b/contrib/stg-k
@@ -8,11 +8,13 @@ set -e
# essence, "stg-k pop" is a "stg pop -k" that works better, hence its
# name.
-# CAVEAT: this script relies on the operation to run ignoring hidden
+# CAVEATS:
+# - this script relies on the operation to run ignoring hidden
# patches, so in 0.12 (where "stg push" can push an hidden patch)
# "stg-k push" will fail midway, albeit with no information loss -
-# you'll just have to finish manually. Luckilly this appears to work
-# on master branch.
+# you'll just have to finish manually. This is fixed in 0.13
+# - running this script to pop all patches in the stack fails, since
+# stg-unnew does not support this case.
# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
# Subject to the GNU GPL, version 2.
diff --git a/contrib/stg-unnew b/contrib/stg-unnew
index 5ac8781..2a38264 100755
--- a/contrib/stg-unnew
+++ b/contrib/stg-unnew
@@ -6,6 +6,9 @@ set -e
# Remove the current patch from the stack, keeping its contents as
# uncommitted changes.
+# CAVEAT: running this script on the bottom-most patch fails, since
+# "stg pick --fold" does not allow this situation.
+
# Copyright (c) 2007 Yann Dirson <ydirson@altern.org>
# Subject to the GNU GPL, version 2.
^ permalink raw reply related
* Re: [PATCH 2/2] diff: add custom regular expressions for function names
From: Johannes Schindelin @ 2007-07-04 18:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, gitster
In-Reply-To: <alpine.LFD.0.98.0707041140230.9434@woody.linux-foundation.org>
Hi,
On Wed, 4 Jul 2007, Linus Torvalds wrote:
> On Wed, 4 Jul 2007, Johannes Schindelin wrote:
> >
> > This patch introduces a config variable diff.functionNameRegexp
> > which replaces the default heuristics. If the pattern contains
> > a group, the match of this group is used for the hunk header
> > instead of the whole match.
>
> Umm. Shouldn't it be a path-name based attribute instead?
>From my original mail:
Yes, I know. .gitattributes integration would be nice. But for now
I am done with it. I invested way too much time into this.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] diff: add custom regular expressions for function names
From: Linus Torvalds @ 2007-07-04 18:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707041905570.4071@racer.site>
On Wed, 4 Jul 2007, Johannes Schindelin wrote:
>
> This patch introduces a config variable diff.functionNameRegexp
> which replaces the default heuristics. If the pattern contains
> a group, the match of this group is used for the hunk header
> instead of the whole match.
Umm. Shouldn't it be a path-name based attribute instead?
That way you can set it to be different things for different source files
in the same repository.. IOW, think mixed Java/C codebases.
Linus
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Jan Hudec @ 2007-07-04 18:28 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550707040544l6272bdeao3a891c1793d29eae@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3523 bytes --]
On Wed, Jul 04, 2007 at 14:44:16 +0200, Marco Costalba wrote:
> On 7/4/07, Junio C Hamano <gitster@pobox.com> wrote:
>> But if a Porcelain like StGIT or Qgit would want to do that kind
>> of operation for different use case than "amending", it can and
>> should use plumbing commands, just like the implementation of
>> "commit --amend" does, with different constraints and error
>> checks.
I would prefer if there was something between git-commit-tree and git-commit.
There are several steps one has to do for commit, that are the same for most
ways of commit:
- call pre-commit hook (unless --no-verify)
- write-tree
- commit-tree
- update-ref
- mv next-index index
- call post-commit hook (unless --no-verify or unconditionally?)
Would factoring out such script from the end of git-commit.sh be accepted?
Or would it be possible to get just that from git-commit with right options?
Basically I need to replicate the logic with
I would suggest a name git-commit-index. It would take the index to commit,
index to move in after commit, head to update, list of parents and commit
message on standard input (as commit-tree does).
The other thing is, that of course qgit (or any other frontend) can't start
using it until it's accepted and released with git. So I'll first try to get
it working in qgit and than think about making it a separate plumbing command
in git.
> I always prefer qgit to use the highest level commands as possible because:
>
> 1- Less error prone
> 2- Easier to implement
Definitely.
> 3- More robust to API change
> 4- Less easy to break by changes in git.
Actually, no. The porcelains are more likely to change than the plumbing.
> Having said that, from '-F' option documentation:
>
> -F <file>::
> Take the commit message from the given file. Use '-' to
> read the message from the standard input.
>
> Jan, what about to use '-' and feed message from stdin?
I actually am, because I am rewriting it to use plumbing, which means
git-write-tree and git-commit-tree directly. And git-commit-tree always reads
commit message from stdin.
> Indeed the full signature of run() is:
>
> bool Git::run(SCRef runCmd, QString* runOutput, QObject* receiver, SCRef
> buf)
>
> Where the last parameter 'buf' it's a string that, if not empty, is
> passed to the launched program stdin.
... except if I read the code correctly, it will create a temporary file
anyway. The comment in QGit::startProcess says it is because of windows, but
there is nothing to disable it in Unix, so to me it seems temporary file is
used anyway.
> I don't know if it is already too late, but I would suggest to stick
> to git-commit if possible, I see only downsides in not doing so. But
> of course who writes the code decides.
The old code needs rewriting in any case, because if I read it correctly, it
will not commit merges either. Yes, you rarely do it, because git
automatically commits non-conflicting merges, but amending such commits is
much more common.
I would personally most like qgit to do all playing with index on it's own
and than call a single command to commit the index. But commit can't really
do that, because I can't give commit the parent list and I don't like the
idea of reset --soft HEAD^ + reinstate whatever MERGE_HEAD there needs to be
(to not clutter reflog and also to leave the tree is as sensible state as
possible if something goes wrong).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/2] diff: add custom regular expressions for function names
From: Johannes Schindelin @ 2007-07-04 18:06 UTC (permalink / raw)
To: git, gitster
For convenience, the hunk headers contain function names. The
heuristics used for that in "git diff" is extremely simple, but
works quite well for most C/C++ and script source code.
However, it usually fails for Java source code.
This patch introduces a config variable diff.functionNameRegexp
which replaces the default heuristics. If the pattern contains
a group, the match of this group is used for the hunk header
instead of the whole match.
You can give more than one regular expression (all of which have to
match), by separating them with '\n'. By prefixing an expression
with '!', it is negated, i.e. a non-match is required. The last
expression is used for the hunk header, and therefore must not be
negated.
A special exception: since Java is so common nowadays, you can set
the config variable to "java", and it will be substituted by a sensible
heuristic.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Yes, I know. .gitattributes integration would be nice. But for now
I am done with it. I invested way too much time into this.
Documentation/config.txt | 17 ++++++++++
diff.c | 4 ++
t/t4018-diff-funcname.sh | 60 +++++++++++++++++++++++++++++++++++
xdiff-interface.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++
xdiff-interface.h | 2 +
xdiff/xdiff.h | 4 ++
xdiff/xemit.c | 37 +++++++++++++--------
7 files changed, 188 insertions(+), 14 deletions(-)
create mode 100644 t/t4018-diff-funcname.sh
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1d96adf..326e27b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -390,6 +390,23 @@ diff.renames::
will enable basic rename detection. If set to "copies" or
"copy", it will detect copies, as well.
+diff.functionNameRegexp::
+ Instead of the builtin heuristic to determine the function names
+ for the hunk headers, use the given regular expression to match
+ lines which contain the function name. If this regular expression
+ contains at least one group, the match of the first group is
+ used, rather than the whole line.
++
+Sometimes, one regular expression is not enough. Use '\n' to separate
+multiple regular expressions. All of these expressions have to match,
+and the last one determines the returned function name. Prefix the
+expression with '!' to require a non-match instead of a match.
++
+As a special exception, the pattern 'java' is substituted with a preset
+pattern which can be expressed as: 'At least two identifiers, followed by
+a "(", and not followed by a ";", and the first identifier must not be a
+reserved keyword such as "new", "return", etc.'
+
fetch.unpackLimit::
If the number of objects fetched over the git native
transfer is below this
diff --git a/diff.c b/diff.c
index bea0163..24b66d0 100644
--- a/diff.c
+++ b/diff.c
@@ -131,6 +131,10 @@ int git_diff_ui_config(const char *var, const char *value)
color_parse(value, var, diff_colors[slot]);
return 0;
}
+ if (!prefixcmp(var, "diff.functionnameregexp")) {
+ xdiff_set_find_func(&default_xecfg, value);
+ return 0;
+ }
return git_default_config(var, value);
}
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
new file mode 100644
index 0000000..90c6605
--- /dev/null
+++ b/t/t4018-diff-funcname.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='Test custom diff function name patterns'
+
+. ./test-lib.sh
+
+LF='
+'
+
+cat > Beer.java << EOF
+public class Beer
+{
+ int special;
+ public static void main(String args[])
+ {
+ String s=" ";
+ for(int x = 99; x > 0; x--)
+ {
+ System.out.print(x + " bottles of beer on the wall "
+ + x + " bottles of beer\n"
+ + "Take one down, pass it around, " + (x - 1)
+ + " bottles of beer on the wall.\n");
+ }
+ System.out.print("Go to the store, buy some more,\n"
+ + "99 bottles of beer on the wall.\n");
+ }
+}
+EOF
+
+sed 's/beer\\/beer,\\/' < Beer.java > Beer-correct.java
+
+test_expect_success 'default behaviour' '
+ git diff Beer.java Beer-correct.java |
+ grep "^@@.*@@ public class Beer"
+'
+
+test_expect_success 'preset java pattern' '
+ git config diff.functionnameregexp java &&
+ git diff Beer.java Beer-correct.java |
+ grep "^@@.*@@ public static void main("
+'
+
+git config diff.functionnameregexp '!static
+!String
+[^ ].*s.*'
+
+test_expect_success 'custom pattern' '
+ git diff Beer.java Beer-correct.java |
+ grep "^@@.*@@ int special;$"
+'
+
+test_expect_success 'last regexp must not be negated' '
+ git config diff.functionnameregexp "!static" &&
+ ! git diff Beer.java Beer-correct.java
+'
+
+test_done
diff --git a/xdiff-interface.c b/xdiff-interface.c
index e407cf1..b0cbd60 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -129,3 +129,81 @@ int buffer_is_binary(const char *ptr, unsigned long size)
size = FIRST_FEW_BYTES;
return !!memchr(ptr, 0, size);
}
+
+struct ff_regs {
+ int nr;
+ struct ff_reg {
+ regex_t re;
+ int negate;
+ } *array;
+};
+
+static long ff_regexp(const char *line, long len,
+ char *buffer, long buffer_size, void *priv)
+{
+ char *line_buffer = xstrndup(line, len); /* make NUL terminated */
+ struct ff_regs *regs = priv;
+ regmatch_t pmatch[2];
+ int result = 0, i;
+
+ for (i = 0; i < regs->nr; i++) {
+ struct ff_reg *reg = regs->array + i;
+ if (reg->negate ^ !!regexec(®->re,
+ line_buffer, 2, pmatch, 0)) {
+ free(line_buffer);
+ return -1;
+ }
+ }
+ i = pmatch[1].rm_so >= 0 ? 1 : 0;
+ line += pmatch[i].rm_so;
+ result = pmatch[i].rm_eo - pmatch[i].rm_so;
+ if (result > buffer_size)
+ result = buffer_size;
+ else
+ while (result > 0 && (isspace(line[result - 1]) ||
+ line[result - 1] == '\n'))
+ result--;
+ memcpy(buffer, line, result);
+ free(line_buffer);
+ return result;
+}
+
+void xdiff_set_find_func(xdemitconf_t *xecfg, const char *value)
+{
+ int i;
+ struct ff_regs *regs;
+
+ if (!strcmp(value, "java"))
+ value = "!^[ ]*\\(catch\\|do\\|for\\|if\\|instanceof\\|"
+ "new\\|return\\|switch\\|throw\\|while\\)\n"
+ "^[ ]*\\(\\([ ]*"
+ "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
+ "[ ]*([^;]*$\\)";
+
+ xecfg->find_func = ff_regexp;
+ regs = xecfg->find_func_priv = xmalloc(sizeof(struct ff_regs));
+ for (i = 0, regs->nr = 1; value[i]; i++)
+ if (value[i] == '\n')
+ regs->nr++;
+ regs->array = xmalloc(regs->nr * sizeof(struct ff_reg));
+ for (i = 0; i < regs->nr; i++) {
+ struct ff_reg *reg = regs->array + i;
+ const char *ep = strchr(value, '\n'), *expression;
+ char *buffer = NULL;
+
+ reg->negate = (*value == '!');
+ if (reg->negate && i == regs->nr - 1)
+ die("Last expression must not be negated: %s", value);
+ if (*value == '!')
+ value++;
+ if (ep)
+ expression = buffer = xstrndup(value, ep - value);
+ else
+ expression = value;
+ if (regcomp(®->re, expression, 0))
+ die("Invalid diff.functionNameRegexp: %s", expression);
+ if (buffer)
+ free(buffer);
+ value = ep + 1;
+ }
+}
diff --git a/xdiff-interface.h b/xdiff-interface.h
index 536f4e4..fb742db 100644
--- a/xdiff-interface.h
+++ b/xdiff-interface.h
@@ -20,4 +20,6 @@ int parse_hunk_header(char *line, int len,
int read_mmfile(mmfile_t *ptr, const char *filename);
int buffer_is_binary(const char *ptr, unsigned long size);
+extern void xdiff_set_find_func(xdemitconf_t *xecfg, const char *line);
+
#endif
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 9402bb0..c00ddaa 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -73,9 +73,13 @@ typedef struct s_xdemitcb {
int (*outf)(void *, mmbuffer_t *, int);
} xdemitcb_t;
+typedef long (*find_func_t)(const char *line, long line_len, char *buffer, long buffer_size, void *priv);
+
typedef struct s_xdemitconf {
long ctxlen;
unsigned long flags;
+ find_func_t find_func;
+ void *find_func_priv;
} xdemitconf_t;
typedef struct s_bdiffparam {
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index 4b6e639..7237054 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -69,7 +69,24 @@ static xdchange_t *xdl_get_hunk(xdchange_t *xscr, xdemitconf_t const *xecfg) {
}
-static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll) {
+static long def_ff(const char *rec, long len, char *buf, long sz, void *priv)
+{
+ if (len > 0 &&
+ (isalpha((unsigned char)*rec) || /* identifier? */
+ *rec == '_' || /* also identifier? */
+ *rec == '$')) { /* mysterious GNU diff's invention */
+ if (len > sz)
+ len = sz;
+ while (0 < len && isspace((unsigned char)rec[len - 1]))
+ len--;
+ memcpy(buf, rec, len);
+ return len;
+ }
+ return -1;
+}
+
+static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll,
+ find_func_t ff, void *ff_priv) {
/*
* Be quite stupid about this for now. Find a line in the old file
@@ -80,22 +97,12 @@ static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll) {
const char *rec;
long len;
- *ll = 0;
while (i-- > 0) {
len = xdl_get_rec(xf, i, &rec);
- if (len > 0 &&
- (isalpha((unsigned char)*rec) || /* identifier? */
- *rec == '_' || /* also identifier? */
- *rec == '$')) { /* mysterious GNU diff's invention */
- if (len > sz)
- len = sz;
- while (0 < len && isspace((unsigned char)rec[len - 1]))
- len--;
- memcpy(buf, rec, len);
- *ll = len;
+ if ((*ll = ff(rec, len, buf, sz, ff_priv)) >= 0)
return;
- }
}
+ *ll = 0;
}
@@ -120,6 +127,7 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
xdchange_t *xch, *xche;
char funcbuf[80];
long funclen = 0;
+ find_func_t ff = xecfg->find_func ? xecfg->find_func : def_ff;
if (xecfg->flags & XDL_EMIT_COMMON)
return xdl_emit_common(xe, xscr, ecb, xecfg);
@@ -143,7 +151,8 @@ int xdl_emit_diff(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
if (xecfg->flags & XDL_EMIT_FUNCNAMES) {
xdl_find_func(&xe->xdf1, s1, funcbuf,
- sizeof(funcbuf), &funclen);
+ sizeof(funcbuf), &funclen,
+ ff, xecfg->find_func_priv);
}
if (xdl_emit_hunk_hdr(s1 + 1, e1 - s1, s2 + 1, e2 - s2,
funcbuf, funclen, ecb) < 0)
--
1.5.3.rc0.804.g7068
^ permalink raw reply related
* [PATCH 1/2] Future-proof source for changes in xdemitconf_t
From: Johannes Schindelin @ 2007-07-04 18:05 UTC (permalink / raw)
To: git, gitster
The instances of xdemitconf_t were initialized member by member.
Instead, initialize them to all zero, so we do not have
to update those places each time we introduce a new member.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-blame.c | 2 +-
builtin-rerere.c | 2 +-
combine-diff.c | 3 +--
diff.c | 16 ++++++----------
merge-file.c | 1 +
merge-tree.c | 2 +-
6 files changed, 11 insertions(+), 15 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index da23a6f..0519339 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -518,8 +518,8 @@ static struct patch *compare_buffer(mmfile_t *file_p, mmfile_t *file_o,
xdemitcb_t ecb;
xpp.flags = xdl_opts;
+ memset(&xecfg, 0, sizeof(xecfg));
xecfg.ctxlen = context;
- xecfg.flags = 0;
ecb.outf = xdiff_outf;
ecb.priv = &state;
memset(&state, 0, sizeof(state));
diff --git a/builtin-rerere.c b/builtin-rerere.c
index 29fb075..01f3848 100644
--- a/builtin-rerere.c
+++ b/builtin-rerere.c
@@ -282,8 +282,8 @@ static int diff_two(const char *file1, const char *label1,
printf("--- a/%s\n+++ b/%s\n", label1, label2);
fflush(stdout);
xpp.flags = XDF_NEED_MINIMAL;
+ memset(&xecfg, 0, sizeof(xecfg));
xecfg.ctxlen = 3;
- xecfg.flags = 0;
ecb.outf = outf;
xdl_diff(&minus, &plus, &xpp, &xecfg, &ecb);
diff --git a/combine-diff.c b/combine-diff.c
index ea3ca5f..ef62234 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -215,8 +215,7 @@ static void combine_diff(const unsigned char *parent, mmfile_t *result_file,
parent_file.ptr = grab_blob(parent, &sz);
parent_file.size = sz;
xpp.flags = XDF_NEED_MINIMAL;
- xecfg.ctxlen = 0;
- xecfg.flags = 0;
+ memset(&xecfg, 0, sizeof(xecfg));
ecb.outf = xdiff_outf;
ecb.priv = &state;
memset(&state, 0, sizeof(state));
diff --git a/diff.c b/diff.c
index 1958970..bea0163 100644
--- a/diff.c
+++ b/diff.c
@@ -19,6 +19,7 @@
static int diff_detect_rename_default;
static int diff_rename_limit_default = -1;
static int diff_use_color_default;
+static xdemitconf_t default_xecfg;
static char diff_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
@@ -385,7 +386,7 @@ static void fn_out_diff_words_aux(void *priv, char *line, unsigned long len)
static void diff_words_show(struct diff_words_data *diff_words)
{
xpparam_t xpp;
- xdemitconf_t xecfg;
+ xdemitconf_t xecfg = default_xecfg;
xdemitcb_t ecb;
mmfile_t minus, plus;
int i;
@@ -408,7 +409,6 @@ static void diff_words_show(struct diff_words_data *diff_words)
xpp.flags = XDF_NEED_MINIMAL;
xecfg.ctxlen = diff_words->minus.alloc + diff_words->plus.alloc;
- xecfg.flags = 0;
ecb.outf = xdiff_outf;
ecb.priv = diff_words;
diff_words->xm.consume = fn_out_diff_words_aux;
@@ -1198,7 +1198,7 @@ static void builtin_diff(const char *name_a,
/* Crazy xdl interfaces.. */
const char *diffopts = getenv("GIT_DIFF_OPTS");
xpparam_t xpp;
- xdemitconf_t xecfg;
+ xdemitconf_t xecfg = default_xecfg;
xdemitcb_t ecb;
struct emit_callback ecbdata;
@@ -1267,12 +1267,10 @@ static void builtin_diffstat(const char *name_a, const char *name_b,
} else {
/* Crazy xdl interfaces.. */
xpparam_t xpp;
- xdemitconf_t xecfg;
+ xdemitconf_t xecfg = default_xecfg;
xdemitcb_t ecb;
xpp.flags = XDF_NEED_MINIMAL | o->xdl_opts;
- xecfg.ctxlen = 0;
- xecfg.flags = 0;
ecb.outf = xdiff_outf;
ecb.priv = diffstat;
xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
@@ -1307,12 +1305,10 @@ static void builtin_checkdiff(const char *name_a, const char *name_b,
else {
/* Crazy xdl interfaces.. */
xpparam_t xpp;
- xdemitconf_t xecfg;
+ xdemitconf_t xecfg = default_xecfg;
xdemitcb_t ecb;
xpp.flags = XDF_NEED_MINIMAL;
- xecfg.ctxlen = 0;
- xecfg.flags = 0;
ecb.outf = xdiff_outf;
ecb.priv = &data;
xdl_diff(&mf1, &mf2, &xpp, &xecfg, &ecb);
@@ -2758,7 +2754,7 @@ static int diff_get_patch_id(struct diff_options *options, unsigned char *sha1)
for (i = 0; i < q->nr; i++) {
xpparam_t xpp;
- xdemitconf_t xecfg;
+ xdemitconf_t xecfg = default_xecfg;
xdemitcb_t ecb;
mmfile_t mf1, mf2;
struct diff_filepair *p = q->queue[i];
diff --git a/merge-file.c b/merge-file.c
index 748d15c..1e031ea 100644
--- a/merge-file.c
+++ b/merge-file.c
@@ -62,6 +62,7 @@ static int generate_common_file(mmfile_t *res, mmfile_t *f1, mmfile_t *f2)
xdemitcb_t ecb;
xpp.flags = XDF_NEED_MINIMAL;
+ memset(&xecfg, 0, sizeof(xecfg));
xecfg.ctxlen = 3;
xecfg.flags = XDL_EMIT_COMMON;
ecb.outf = common_outf;
diff --git a/merge-tree.c b/merge-tree.c
index 3b8d9e6..7d4f628 100644
--- a/merge-tree.c
+++ b/merge-tree.c
@@ -106,8 +106,8 @@ static void show_diff(struct merge_list *entry)
xdemitcb_t ecb;
xpp.flags = XDF_NEED_MINIMAL;
+ memset(&xecfg, 0, sizeof(xecfg));
xecfg.ctxlen = 3;
- xecfg.flags = 0;
ecb.outf = show_outf;
ecb.priv = NULL;
--
1.5.3.rc0.804.g7068
^ permalink raw reply related
* Re: [PATCH] git-init: set core.worktree if GIT_WORK_TREE is specified
From: Linus Torvalds @ 2007-07-04 17:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Lederhofer, git, Johannes Schindelin
In-Reply-To: <7vsl84gkrz.fsf@assigned-by-dhcp.cox.net>
On Wed, 4 Jul 2007, Junio C Hamano wrote:
>
> Ok, will do this.
Ack.
> From: Linus Torvalds <torvalds@linux-foundation.org>
I don't think you need to credit me, or forge my sign-off for stuff like
this where I didn't actually send out a patch.
I'd suggest instead just committing it as yours, but maybe with the
explanation saying something like "Linus explains: <explanation>" instead.
But hey, you can do it your way too, your choice.
Linus
^ permalink raw reply
* Re: [PATCH] git-init: set core.worktree if GIT_WORK_TREE is specified
From: Junio C Hamano @ 2007-07-04 17:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Matthias Lederhofer, git, Johannes Schindelin
In-Reply-To: <alpine.LFD.0.98.0707040920520.9434@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 4 Jul 2007, Matthias Lederhofer wrote:
>
>> > + if (!getcwd(cwd, sizeof(cwd)) || cwd[0] != '/')
>> > + die("Unable to read current working directory");
>>
>> Dscho just pointed out that this causes problems on windows. The same
>> is also in setup_git_directory_gently and was there before I touched
>> it, introduced by Linus in d288a700. What was the original reason to
>> do this? Are there implementations of getcwd which return a relative
>> path?
>
> Just remove the check for cwd[0] being '/'.
Ok, will do this.
-- >8 --
From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Wed, 4 Jul 2007 09:23:17 -0700 (PDT)
Subject: Do not check if getcwd() result begins with a slash
It's just me being too kernel-oriented - inside the kernel, a d_path()
return value pathname can be either a real path, or something like
"pipe:[8003]", and the difference is the '/' at the beginning.
In user space, and for getcwd(), the check doesn't make sense. So please
just remove it, and sorry for my idiotic "I've worked with the kernel for
too damn long" programming mistakes.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Forged-signature-by: Junio C Hamano <gitster@pobox.com>
---
setup.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/setup.c b/setup.c
index 01f74d4..bb26f3a 100644
--- a/setup.c
+++ b/setup.c
@@ -211,7 +211,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (!gitdirenv) {
int len, offset;
- if (!getcwd(cwd, sizeof(cwd)-1) || cwd[0] != '/')
+ if (!getcwd(cwd, sizeof(cwd)-1))
die("Unable to read current working directory");
offset = len = strlen(cwd);
@@ -271,7 +271,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
die("Not a git repository: '%s'", gitdirenv);
}
- if (!getcwd(cwd, sizeof(cwd)-1) || cwd[0] != '/')
+ if (!getcwd(cwd, sizeof(cwd)-1))
die("Unable to read current working directory");
if (chdir(gitdirenv)) {
if (nongit_ok) {
@@ -281,7 +281,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
die("Cannot change directory to $%s '%s'",
GIT_DIR_ENVIRONMENT, gitdirenv);
}
- if (!getcwd(gitdir, sizeof(gitdir)-1) || gitdir[0] != '/')
+ if (!getcwd(gitdir, sizeof(gitdir)-1))
die("Unable to read current working directory");
if (chdir(cwd))
die("Cannot come back to cwd");
@@ -340,7 +340,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
die("Cannot change directory to working tree '%s'",
gitworktree);
}
- if (!getcwd(worktree, sizeof(worktree)-1) || worktree[0] != '/')
+ if (!getcwd(worktree, sizeof(worktree)-1))
die("Unable to read current working directory");
strcat(worktree, "/");
inside_work_tree = !prefixcmp(cwd, worktree);
^ permalink raw reply related
* Re: [PATCH] git-submodule: Fix a typo
From: Junio C Hamano @ 2007-07-04 16:59 UTC (permalink / raw)
To: CJ van den Berg; +Cc: git
In-Reply-To: <20070704162214.GA28542@prefect.vdbonline.net>
CJ van den Berg <cj@vdbonline.com> writes:
> This typo breaks the output of git submodule status.
>
> ---
> git-submodule.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 0ba0161..277fadc 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -234,7 +234,7 @@ modules_list()
> continue;
> fi
> revname=$(unset GIT_DIR && cd "$path" && git describe --tags $sha1)
> - set_name_rev "$path" $"sha1"
> + set_name_rev "$path" "$sha1"
> if git diff-files --quiet -- "$path"
> then
> say " $sha1 $path$revname"
Thanks. There is another, probably from a cut-n-paste.
^ permalink raw reply
* Re: [PATCH] gitk: fix for "gitk <ambiguous-name> --"
From: Junio C Hamano @ 2007-07-04 16:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Johannes Schindelin, Linus Torvalds, Uwe Kleine-K?nig, git
In-Reply-To: <18059.31237.286280.566140@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Junio: there seems to be an inconsistency between git rev-list and git
> rev-parse here. If a name is both a filename and a ref, git rev-list
> will give a fatal error but git rev-parse will take it as a ref.
$ rev-parse --no-revs --no-flags gitk -- gitk
$ rev-parse --no-revs --no-flags -- gitk
should give you the path "gitk", while
$ rev-parse --revs-only --no-flags gitk -- gitk
$ rev-parse --revs-only --no-flags gitk --
should give you the revision (i.e. branch name) "gitk", I think.
But it is not well defined what it should do upon
$ rev-parse --no-flags gitk
$ rev-parse gitk
Currently they treat "gitk" as a ref. On the other hand, as you
said:
$ rev-list gitk
would error out without leading or traiing -- to disambiguate.
So you are right that they behave differently.
It might be an improvement to make rev-parse require leading or
trailing -- in such a case, but I haven't thought through the
ramifications of such a change. Quite a lot of existing users
expect "rev-parse foo" to favor a ref "foo" over a file "foo"
and give its object name.
^ permalink raw reply
* Re: [PATCH 1/2] Remove obsolete commit-walkers
From: Junio C Hamano @ 2007-07-04 16:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0707041228290.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Actually these fetch backend shouldn't even be needed by the end
>> users. "git fetch" simply does not drive them these days.
>
> You forget that this backend is a plumbing component, which might well be
> used by other porcelains. IIRC cogito uses it, optionally.
You are correct that these plumbing commands can be called by
Cogito, but we are not removing them but merely deprecating
them. And I thought Cogito itself is deprecated these days,
so...
^ permalink raw reply
* Re: [PATCH] filter-branch documentation: some more touch-ups.
From: Junio C Hamano @ 2007-07-04 16:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git, Frank Lichtenheld, j.sixt
In-Reply-To: <Pine.LNX.4.64.0707041155110.4071@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 4 Jul 2007, Johannes Sixt wrote:
>
>> - The map function used to fail, but no longer does (since 3520e1e8687.)
>> - Fix the "edge-graft" example.
>> - Show the same using .git/info/grafts.
>>
>> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
>> ---
>>
>> I think that "edge-graft" makes more sense than "etch-graft".
>> Native speakers, please?
>
> I looked at dict.leo.org, and it does not know either version. Maybe it is
> just "graft"?
Why even need a new term there, if you are not going to use it
elsewhere? Instead of saying:
-To "etch-graft" a commit to the revision history (set a commit to be
+To "edge-graft" a commit to the revision history (set a commit to be
the parent of the current initial commit and propagate that):
----------------------------------------------------------------------
git filter-branch --parent-filter sed\ 's/^$/-p <graft-id>/' newbranch
----------------------------------------------------------------------
You could say:
To set a commit to be the parent of the current initial
commit and propagate that:
without inventing unfamiliar word that is not used anywhere else
in the documentation.
One thing that you may want to stress is that <graft-id> does
not represent a single commit, but the history that leads to it.
So "set a commit to be a parent" is technically correct, but it
is not "To edge-graft _a_ commit", but more like "Paste another
history behind the current beginning of time".
You have two filmstrips, the first frame of one filmstrip, your
current history, should logically follow the last frame of the
other filmstrip but they are separated into two. You are
splicing them together to make a single, longer, filmstrip.
^ permalink raw reply
* [PATCH] git-submodule: Fix a typo
From: CJ van den Berg @ 2007-07-04 16:22 UTC (permalink / raw)
To: git
This typo breaks the output of git submodule status.
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 0ba0161..277fadc 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -234,7 +234,7 @@ modules_list()
continue;
fi
revname=$(unset GIT_DIR && cd "$path" && git describe --tags $sha1)
- set_name_rev "$path" $"sha1"
+ set_name_rev "$path" "$sha1"
if git diff-files --quiet -- "$path"
then
say " $sha1 $path$revname"
--
1.5.2.GIT
^ permalink raw reply related
* Re: [PATCH] git-init: set core.worktree if GIT_WORK_TREE is specified
From: Linus Torvalds @ 2007-07-04 16:23 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git, Johannes Schindelin
In-Reply-To: <20070704092915.GA18597@moooo.ath.cx>
On Wed, 4 Jul 2007, Matthias Lederhofer wrote:
> > + if (!getcwd(cwd, sizeof(cwd)) || cwd[0] != '/')
> > + die("Unable to read current working directory");
>
> Dscho just pointed out that this causes problems on windows. The same
> is also in setup_git_directory_gently and was there before I touched
> it, introduced by Linus in d288a700. What was the original reason to
> do this? Are there implementations of getcwd which return a relative
> path?
Just remove the check for cwd[0] being '/'.
It's just me being too kernel-oriented - inside the kernel, a d_path()
return value pathname can be either a real path, or something like
"pipe:[8003]", and the difference is the '/' at the beginning.
In user space, and for getcwd(), the check doesn't make sense. So please
just remove it, and sorry for my idiotic "I've worked with the kernel for
too damn long" programming mistakes.
Linus
^ permalink raw reply
* Re: [PATCH] git-repack: generational repacking (and example hook script)
From: Nicolas Pitre @ 2007-07-04 15:42 UTC (permalink / raw)
To: Sam Vilain; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <468B3B42.2040103@vilain.net>
On Wed, 4 Jul 2007, Sam Vilain wrote:
> Johannes Schindelin wrote:
> >>>> 1. Do you agree that some users would want their git repositories to be
> >>>> "maintenance free"?
> >>> I'm not so sure.
> >> Well, no offence, but I think you should withhold from voicing a
> >> fundamental concern as this, because you're not one of its target users.
> > Let's put it this way. A lot of car drivers would probably agree that it
> > is a Good Thing (tm) if their car automatically went to get gas, before it
> > ran out of it. Less hassle, right?
> >
> > Yes, except if your car decides to get gas when you are already late,
> > speeding, trying to catch your plane.
>
> Ok, but if you're only packing a few hundred objects it usually won't
> matter because it is fast enough that you hardly notice.
... in which case you might as well keep them loose too.
> And if you don't like it, you turn it off, or don't turn it on.
You seem to forget the maintenance cost of having this in the Git
distribution. When something is merged in, it has to be maintained and
kept working. Given the complexity of your proposal weighted against
the relative benefits I remain unconvinced.
Yet you didn't state what exactly is the issue you're trying to solve.
If it is only to avoid running "git gc" occasionally then this clearly
isn't a benefit worth the cost.
If, instead, you implement it as a post-commit or post-receive hook
meant for contrib/hooks/ then I wouldn't have any issue with that.
Nicolas
^ permalink raw reply
* Re: [PATCH] filter-branch: a few more touch ups to the man page
From: Frank Lichtenheld @ 2007-07-04 15:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707041546510.4071@racer.site>
On Wed, Jul 04, 2007 at 03:50:45PM +0100, Johannes Schindelin wrote:
>
> All based on comments from Frank Lichtenheld.
Acked-by: Frank Lichtenheld <frank@lichtenheld.de>
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* [PATCH] filter-branch: a few more touch ups to the man page
From: Johannes Schindelin @ 2007-07-04 14:50 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, gitster
In-Reply-To: <20070704112900.GO12721@planck.djpig.de>
All based on comments from Frank Lichtenheld.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 4 Jul 2007, Frank Lichtenheld wrote:
> On Wed, Jul 04, 2007 at 12:17:05AM +0100, Johannes Schindelin wrote:
> >
> > On Wed, 4 Jul 2007, Frank Lichtenheld wrote:
> >
> > > General note: All the stuff in all uppercase should probably
> > > also have some asciidoc emphasis.
>
> [...] it is used at least in the case of WARNING as a means of
> emphasis and this should be reflected in the end result as
> markup. So I still suggest changing it to *WARNING* or even
> *Warning* if you don't want to double the emphasis.
>
> > Also, GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE,
> > GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, and
> > GIT_COMMITTER_DATE is set according to the current commit.
>
> "are" set. And yeah, it doesn't look pretty. I still prefer
> having the list somewhere in the text, though.
>
> > > > + Only regard the history, as seen by the given [...]
> > > ^^^
> > > Does this comma belong there?
> >
> > This is my bad English. What I meant was this:
> >
> > Only ever look at the history, which touches the given
> > subdirectory. The result will contain that directory as its
> > project root.
>
> I'm still not sure there should be a comma in this sentence, but
> my English grammar is a bit rusty.
Better?
Documentation/git-filter-branch.txt | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index 2074f31..363287d 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -31,7 +31,7 @@ branch as your current branch. Nevertheless, this may be useful in
the future for compensating for some git bugs or such, therefore
such a usage is permitted.
-WARNING! The rewritten history will have different object names for all
+*WARNING*! The rewritten history will have different object names for all
the objects and will not converge with the original branch. You will not
be able to easily push and distribute the rewritten branch on top of the
original branch. Please do not use this command if you do not know the
@@ -54,7 +54,7 @@ argument is always evaluated in shell using the 'eval' command.
Prior to that, the $GIT_COMMIT environment variable will be set to contain
the id of the commit being rewritten. Also, GIT_AUTHOR_NAME,
GIT_AUTHOR_EMAIL, GIT_AUTHOR_DATE, GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL,
-and GIT_COMMITTER_DATE is set according to the current commit.
+and GIT_COMMITTER_DATE are set according to the current commit.
A 'map' function is available that takes an "original sha1 id" argument
and outputs a "rewritten sha1 id" if the commit has been already
@@ -78,7 +78,7 @@ OPTIONS
directory set to the root of the checked out tree. The new tree
is then used as-is (new files are auto-added, disappeared files
are auto-removed - neither .gitignore files nor any other ignore
- rules HAVE ANY EFFECT!).
+ rules *HAVE ANY EFFECT*!).
--index-filter <command>::
This is the filter for rewriting the index. It is similar to the
@@ -128,8 +128,9 @@ attached, the rewritten tag won't have it. Sorry. (It is by
definition impossible to preserve signatures at any rate.)
--subdirectory-filter <directory>::
- Only ever look at the history, which touches the given subdirectory.
- The result will contain that directory as its project root.
+ Only look at the history which touches the given subdirectory.
+ The result will contain that directory (and only that) as its
+ project root.
-d <directory>::
Use this option to set the path to the temporary directory used for
--
1.5.3.rc0.2663.gfbb70
^ permalink raw reply related
* [PATCH 2/2] filter-branch: fail gracefully when a filter fails
From: Johannes Schindelin @ 2007-07-04 14:36 UTC (permalink / raw)
To: git, gitster
A common mistake is to provide a filter which fails unwantedly. For
example, this will stop in the middle:
git filter-branch --env-filter '
test $GIT_COMMITTER_EMAIL = xyz &&
export GIT_COMMITTER_EMAIL = abc' rewritten
When $GIT_COMMITTER_EMAIL is not "xyz", the test fails, and consequently
the whole filter has a non-zero exit status. However, as demonstrated
in this example, filter-branch would just stop, and the user would be
none the wiser.
Also, a failing msg-filter would not have been caught, as was the
case with one of the tests.
This patch fixes both issues, by paying attention to the exit status
of msg-filter, and by saying what failed before exiting.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
It is slightly ugly that the output of msg-filter is written
to a temporary file. But I do not know a better method to
catch a failing msg-filter. Help?
git-filter-branch.sh | 39 +++++++++++++++++++++++++++++----------
t/t7003-filter-branch.sh | 8 +++++++-
2 files changed, 36 insertions(+), 11 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 3bf5d88..f0a5070 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -20,6 +20,16 @@ map()
cat "$workdir/../map/$1"
}
+# override die(): this version puts in an extra line break, so that
+# the progress is still visible
+
+die()
+{
+ echo >&2
+ echo "$*" >&2
+ exit 1
+}
+
# When piped a commit, output a script to set the ident of either
# "author" or "committer
@@ -173,23 +183,29 @@ while read commit parents; do
export GIT_COMMIT=$commit
git cat-file commit "$commit" >../commit
- eval "$(set_ident AUTHOR <../commit)"
- eval "$(set_ident COMMITTER <../commit)"
- eval "$filter_env" < /dev/null
+ eval "$(set_ident AUTHOR <../commit)" ||
+ die "setting author failed for commit $commit"
+ eval "$(set_ident COMMITTER <../commit)" ||
+ die "setting committer failed for commit $commit"
+ eval "$filter_env" < /dev/null ||
+ die "env filter failed: $filter_env"
if [ "$filter_tree" ]; then
git checkout-index -f -u -a
# files that $commit removed are now still in the working tree;
# remove them, else they would be added again
git ls-files -z --others | xargs -0 rm -f
- eval "$filter_tree" < /dev/null
+ eval "$filter_tree" < /dev/null ||
+ die "tree filter failed: $filter_tree"
+
git diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
xargs -0 git update-index --add --replace --remove
git ls-files -z --others | \
xargs -0 git update-index --add --replace --remove
fi
- eval "$filter_index" < /dev/null
+ eval "$filter_index" < /dev/null ||
+ die "index filter failed: $filter_index"
parentstr=
for parent in $parents; do
@@ -198,13 +214,15 @@ while read commit parents; do
done
done
if [ "$filter_parent" ]; then
- parentstr="$(echo "$parentstr" | eval "$filter_parent")"
+ parentstr="$(echo "$parentstr" | eval "$filter_parent")" ||
+ die "parent filter failed: $filter_parent"
fi
sed -e '1,/^$/d' <../commit | \
- eval "$filter_msg" | \
- sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
- $parentstr > ../map/$commit
+ eval "$filter_msg" > ../message ||
+ die "msg filter failed: $filter_msg"
+ sh -c "$filter_commit" "git commit-tree" \
+ $(git write-tree) $parentstr < ../message > ../map/$commit
done <../revs
src_head=$(tail -n 1 ../revs | sed -e 's/ .*//')
@@ -241,7 +259,8 @@ if [ "$filter_tag_name" ]; then
[ -f "../map/$sha1" ] || continue
new_sha1="$(cat "../map/$sha1")"
export GIT_COMMIT="$sha1"
- new_ref="$(echo "$ref" | eval "$filter_tag_name")"
+ new_ref="$(echo "$ref" | eval "$filter_tag_name")" ||
+ die "tag name filter failed: $filter_tag_name"
echo "$ref -> $new_ref ($sha1 -> $new_sha1)"
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index 451ac86..4ddd656 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -107,13 +107,19 @@ test_expect_success 'use index-filter to move into a subdirectory' '
mv \$GIT_INDEX_FILE.new \$GIT_INDEX_FILE" directorymoved &&
test -z "$(git diff HEAD directorymoved:newsubdir)"'
+test_expect_success 'stops when msg filter fails' '
+ ! git-filter-branch --msg-filter false nonono &&
+ rm -rf .git-rewrite &&
+ ! git rev-parse nonono
+'
+
test_expect_success 'author information is preserved' '
: > i &&
git add i &&
test_tick &&
GIT_AUTHOR_NAME="B V Uips" git commit -m bvuips &&
git-filter-branch --msg-filter "cat; \
- test \$GIT_COMMIT = $(git rev-parse master) && \
+ test \$GIT_COMMIT != $(git rev-parse master) || \
echo Hallo" \
preserved-author &&
test 1 = $(git rev-list --author="B V Uips" preserved-author | wc -l)
--
1.5.3.rc0.2646.g88600-dirty
^ permalink raw reply related
* [PATCH 1/2] filter-branch: make output nicer
From: Johannes Schindelin @ 2007-07-04 14:33 UTC (permalink / raw)
To: git, gitster
Instead of filling the screen with progress lines, use \r so that
the progress can be seen, but warning messages are more visible.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Okay, this is actually tested. Several times.
git-filter-branch.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
mode change 100644 => 100755 git-filter-branch.sh
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
old mode 100644
new mode 100755
index 22fb5bf..3bf5d88
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -160,7 +160,7 @@ test $commits -eq 0 && die "Found nothing to rewrite"
i=0
while read commit parents; do
i=$(($i+1))
- printf "$commit ($i/$commits) "
+ printf "\rRewrite $commit ($i/$commits)"
case "$filter_subdir" in
"")
@@ -203,8 +203,8 @@ while read commit parents; do
sed -e '1,/^$/d' <../commit | \
eval "$filter_msg" | \
- sh -c "$filter_commit" "git commit-tree" $(git write-tree) $parentstr | \
- tee ../map/$commit
+ sh -c "$filter_commit" "git commit-tree" $(git write-tree) \
+ $parentstr > ../map/$commit
done <../revs
src_head=$(tail -n 1 ../revs | sed -e 's/ .*//')
@@ -256,6 +256,6 @@ fi
cd ../..
rm -rf "$tempdir"
-echo "Rewritten history saved to the $dstbranch branch"
+printf "\nRewritten history saved to the $dstbranch branch\n"
exit $ret
--
1.5.3.rc0.2646.g88600-dirty
^ permalink raw reply related
* Re: efficient way to filter several branches with common history?
From: Johannes Schindelin @ 2007-07-04 14:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <6DC0E50A-CAD3-453E-BD9C-73E51EDD5785@zib.de>
Hi,
On Wed, 4 Jul 2007, Steffen Prohaska wrote:
> On Jul 4, 2007, at 10:37 AM, Johannes Sixt wrote:
>
> > Steffen Prohaska wrote:
> > >
> > > Is there an efficient way to filter several branches at once
> > > through git-filter-branch?
> >
> > That feature is not yet implemented.
> >
> > In the meantime do it this way:
> >
> > [...]
>
> Thanks for your explanation. The following is the template I used
> to build my fully automated version of what you proposed:
>
> [...]
Since you seem quite proficient in shell, why not implement this feature
in filter-branch (which is a shell script) to begin with?
Ciao,
Dscho
^ permalink raw reply
* Re: How to rebase after upstream was merged?
From: Johannes Sixt @ 2007-07-04 13:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707041426570.4071@racer.site>
Johannes Schindelin wrote:
> [...how to check for linear history...]
> I usually to
>
> test -z "$(git rev-list --parents origin..HEAD | grep " .* ")"
Ah, that's much better.
Thanks,
-- Hannes
^ 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