* [PATCH 2/3] apply --whitespace: configuration option.
From: Junio C Hamano @ 2006-02-28 1:13 UTC (permalink / raw)
To: git; +Cc: Andrew Morton
In-Reply-To: <7vhd6kxuea.fsf@assigned-by-dhcp.cox.net>
The new configuration option apply.whitespace can take one of
"warn", "error", "error-all", or "strip". When git-apply is run
to apply the patch to the index, they are used as the default
value if there is no command line --whitespace option.
Andrew can now tell people who feed him git trees to update to
this version and say:
git repo-config apply.whitespace error
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Already in "next".
apply.c | 72 ++++++++++++++++++++++++++++++++++++++-------------------
cache.h | 2 ++
environment.c | 1 +
3 files changed, 51 insertions(+), 24 deletions(-)
2ae1c53b51ff78b13cc8abf8e9798a12140b7638
diff --git a/apply.c b/apply.c
index 8139d83..a5cdd8e 100644
--- a/apply.c
+++ b/apply.c
@@ -35,16 +35,42 @@ static const char apply_usage[] =
"git-apply [--stat] [--numstat] [--summary] [--check] [--index] [--apply] [--no-add] [--index-info] [--allow-binary-replacement] [-z] [-pNUM] <patch>...";
static enum whitespace_eol {
- nowarn,
+ nowarn_whitespace,
warn_on_whitespace,
error_on_whitespace,
- strip_and_apply,
-} new_whitespace = nowarn;
+ strip_whitespace,
+} new_whitespace = nowarn_whitespace;
static int whitespace_error = 0;
static int squelch_whitespace_errors = 5;
static int applied_after_stripping = 0;
static const char *patch_input_file = NULL;
+static void parse_whitespace_option(const char *option)
+{
+ if (!option) {
+ new_whitespace = nowarn_whitespace;
+ return;
+ }
+ if (!strcmp(option, "warn")) {
+ new_whitespace = warn_on_whitespace;
+ return;
+ }
+ if (!strcmp(option, "error")) {
+ new_whitespace = error_on_whitespace;
+ return;
+ }
+ if (!strcmp(option, "error-all")) {
+ new_whitespace = error_on_whitespace;
+ squelch_whitespace_errors = 0;
+ return;
+ }
+ if (!strcmp(option, "strip")) {
+ new_whitespace = strip_whitespace;
+ return;
+ }
+ die("unrecognized whitespace option '%s'", option);
+}
+
/*
* For "diff-stat" like behaviour, we keep track of the biggest change
* we've seen, and the longest filename. That allows us to do simple
@@ -832,7 +858,7 @@ static int parse_fragment(char *line, un
* That is, an addition of an empty line would check
* the '+' here. Sneaky...
*/
- if ((new_whitespace != nowarn) &&
+ if ((new_whitespace != nowarn_whitespace) &&
isspace(line[len-2])) {
whitespace_error++;
if (squelch_whitespace_errors &&
@@ -1129,7 +1155,7 @@ static int apply_line(char *output, cons
* patch[plen] is '\n'.
*/
int add_nl_to_tail = 0;
- if ((new_whitespace == strip_and_apply) &&
+ if ((new_whitespace == strip_whitespace) &&
1 < plen && isspace(patch[plen-1])) {
if (patch[plen] == '\n')
add_nl_to_tail = 1;
@@ -1824,10 +1850,21 @@ static int apply_patch(int fd, const cha
return 0;
}
+static int git_apply_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "apply.whitespace")) {
+ apply_default_whitespace = strdup(value);
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
+
int main(int argc, char **argv)
{
int i;
int read_stdin = 1;
+ const char *whitespace_option = NULL;
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
@@ -1895,30 +1932,17 @@ int main(int argc, char **argv)
continue;
}
if (!strncmp(arg, "--whitespace=", 13)) {
- if (!strcmp(arg+13, "warn")) {
- new_whitespace = warn_on_whitespace;
- continue;
- }
- if (!strcmp(arg+13, "error")) {
- new_whitespace = error_on_whitespace;
- continue;
- }
- if (!strcmp(arg+13, "error-all")) {
- new_whitespace = error_on_whitespace;
- squelch_whitespace_errors = 0;
- continue;
- }
- if (!strcmp(arg+13, "strip")) {
- new_whitespace = strip_and_apply;
- continue;
- }
- die("unrecognized whitespace option '%s'", arg+13);
+ whitespace_option = arg + 13;
+ parse_whitespace_option(arg + 13);
+ continue;
}
if (check_index && prefix_length < 0) {
prefix = setup_git_directory();
prefix_length = prefix ? strlen(prefix) : 0;
- git_config(git_default_config);
+ git_config(git_apply_config);
+ if (!whitespace_option && apply_default_whitespace)
+ parse_whitespace_option(apply_default_whitespace);
}
if (0 < prefix_length)
arg = prefix_filename(prefix, prefix_length, arg);
diff --git a/cache.h b/cache.h
index 58eec00..0d3b244 100644
--- a/cache.h
+++ b/cache.h
@@ -161,11 +161,13 @@ extern int hold_index_file_for_update(st
extern int commit_index_file(struct cache_file *);
extern void rollback_index_file(struct cache_file *);
+/* Environment bits from configuration mechanism */
extern int trust_executable_bit;
extern int assume_unchanged;
extern int only_use_symrefs;
extern int diff_rename_limit_default;
extern int shared_repository;
+extern const char *apply_default_whitespace;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/environment.c b/environment.c
index 251e53c..16c08f0 100644
--- a/environment.c
+++ b/environment.c
@@ -17,6 +17,7 @@ int only_use_symrefs = 0;
int repository_format_version = 0;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
int shared_repository = 0;
+const char *apply_default_whitespace = NULL;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
--
1.2.3.gbfea
^ permalink raw reply related
* Re: [PATCH] git pull cannot find remote refs.
From: Junio C Hamano @ 2006-02-28 1:13 UTC (permalink / raw)
To: Stefan-W. Hahn; +Cc: git
In-Reply-To: <20060227214936.GA7205@scotty.home>
"Stefan-W. Hahn" <stefan.hahn@s-hahn.de> writes:
> Tracking it down, I found a gap between how git-ls-remote prints out the tags
> and git-fetch scans them with sed. Looking at the code of git-ls-remote the
> there is an tab character between the sha1 and the refname, while there is a
> space and a tab character in the regular expression for th sed command.
>
> As a result the while where all is piped in cannot read the two values.
Sorry.
I do not understand the above comment, nor the following code.
> git-ls-remote $upload_pack --tags "$remote" |
> - sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
> + sed -ne 's|^\([0-9a-f]*\)[\t]\(refs/tags/.*\)^{}$|\1 \2|p' |
ls-remote shows "SHA1\tPATH". The original says "hexadecimal
followed by [either a single space or a single tab] followed by
a refpath", while yours says "hexadecimal followed by a single tab
followed by a refpath". I do not see how that would make any
difference. Puzzled...
I've seen two servers DNS round-robin and one of them fail to
respond. The first "fetch" goes to the good one and the second
ls-remote goes to the bad one, then you would see "Oops, we
cannot peek tags". But this patch does not have anything to do
with that problem..
^ permalink raw reply
* [PATCH 1/3] apply: squelch excessive errors and --whitespace=error-all
From: Junio C Hamano @ 2006-02-28 1:13 UTC (permalink / raw)
To: git; +Cc: Andrew Morton
In-Reply-To: <7vhd6kxuea.fsf@assigned-by-dhcp.cox.net>
This by default makes --whitespace=warn, error, and strip to
warn only the first 5 additions of trailing whitespaces. A new
option --whitespace=error-all can be used to view all of them
before applying.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is already in "next".
apply.c | 53 +++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 45 insertions(+), 8 deletions(-)
fc96b7c9ba5034a408d508c663a96a15b8f8729c
diff --git a/apply.c b/apply.c
index 7dbbeb4..8139d83 100644
--- a/apply.c
+++ b/apply.c
@@ -41,6 +41,8 @@ static enum whitespace_eol {
strip_and_apply,
} new_whitespace = nowarn;
static int whitespace_error = 0;
+static int squelch_whitespace_errors = 5;
+static int applied_after_stripping = 0;
static const char *patch_input_file = NULL;
/*
@@ -832,11 +834,16 @@ static int parse_fragment(char *line, un
*/
if ((new_whitespace != nowarn) &&
isspace(line[len-2])) {
- fprintf(stderr, "Added whitespace\n");
- fprintf(stderr, "%s:%d:%.*s\n",
- patch_input_file,
- linenr, len-2, line+1);
- whitespace_error = 1;
+ whitespace_error++;
+ if (squelch_whitespace_errors &&
+ squelch_whitespace_errors <
+ whitespace_error)
+ ;
+ else {
+ fprintf(stderr, "Adds trailing whitespace.\n%s:%d:%.*s\n",
+ patch_input_file,
+ linenr, len-2, line+1);
+ }
}
added++;
newlines--;
@@ -1129,6 +1136,7 @@ static int apply_line(char *output, cons
plen--;
while (0 < plen && isspace(patch[plen]))
plen--;
+ applied_after_stripping++;
}
memcpy(output, patch + 1, plen);
if (add_nl_to_tail)
@@ -1895,11 +1903,16 @@ int main(int argc, char **argv)
new_whitespace = error_on_whitespace;
continue;
}
+ if (!strcmp(arg+13, "error-all")) {
+ new_whitespace = error_on_whitespace;
+ squelch_whitespace_errors = 0;
+ continue;
+ }
if (!strcmp(arg+13, "strip")) {
new_whitespace = strip_and_apply;
continue;
}
- die("unrecognixed whitespace option '%s'", arg+13);
+ die("unrecognized whitespace option '%s'", arg+13);
}
if (check_index && prefix_length < 0) {
@@ -1919,7 +1932,31 @@ int main(int argc, char **argv)
}
if (read_stdin)
apply_patch(0, "<stdin>");
- if (whitespace_error && new_whitespace == error_on_whitespace)
- return 1;
+ if (whitespace_error) {
+ if (squelch_whitespace_errors &&
+ squelch_whitespace_errors < whitespace_error) {
+ int squelched =
+ whitespace_error - squelch_whitespace_errors;
+ fprintf(stderr, "warning: squelched %d whitespace error%s\n",
+ squelched,
+ squelched == 1 ? "" : "s");
+ }
+ if (new_whitespace == error_on_whitespace)
+ die("%d line%s add%s trailing whitespaces.",
+ whitespace_error,
+ whitespace_error == 1 ? "" : "s",
+ whitespace_error == 1 ? "s" : "");
+ if (applied_after_stripping)
+ fprintf(stderr, "warning: %d line%s applied after"
+ " stripping trailing whitespaces.\n",
+ applied_after_stripping,
+ applied_after_stripping == 1 ? "" : "s");
+ else if (whitespace_error)
+ fprintf(stderr, "warning: %d line%s add%s trailing"
+ " whitespaces.\n",
+ whitespace_error,
+ whitespace_error == 1 ? "" : "s",
+ whitespace_error == 1 ? "s" : "");
+ }
return 0;
}
--
1.2.3.gbfea
^ permalink raw reply related
* Re: [PATCH] First cut at libifying revlist generation
From: Junio C Hamano @ 2006-02-28 1:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0602270947380.5937@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> http://article.gmane.org/gmane.comp.version-control.git/10718, which
> helped me tremendously in identyfing the bug.
I'm willing to accept a response to "Yup. That sounds sensible."
^ permalink raw reply
* Re: the war on trailing whitespace
From: linux @ 2006-02-28 1:07 UTC (permalink / raw)
To: git
The only language I know of where the presence of whitespace on blank
lines matters is make(1). Even there, it's subtle. It's okay to have
(using "cat -e" syntax)
foo : bar$
command$
$
command$
But there's a difference between
foo : bar$
$
which specifies an empty command and will therefore not use a default rule, and
foo : bar$
$
which does not specify any command and so will use a default rule if one exists.
(Of course, you can also get [ \t]\n inside an arbitrary binary file, too.)
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Martin Langhoff @ 2006-02-28 0:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Eric Wong, git
In-Reply-To: <Pine.LNX.4.64.0602271634410.22647@g5.osdl.org>
On 2/28/06, Linus Torvalds <torvalds@osdl.org> wrote:
> On Tue, 28 Feb 2006, Martin Langhoff wrote:
> > git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
> > Nothing within core git prevents it from moving, but I think that
> > porcelains will start breaking. Tags and heads are the same thing,
> > except that heads are expected to change (specifically, to move
> > forward), and tags are expected to stand still.
>
> Well, I wouldn't say that tags are expected to stand still. Some kinds of
> tags are expected to move: a "this is the last tested version" tag would
> be expected to move with testing.
Alrighty... in my git projects where things like these matter, my
"latest tested" and "current in production" refs are actually in
refs/heads.
> That said, the movement is _different_ from a branch. A branch is expected
> to move _with_ development, while a tag is expected to either stay the
> same, or move _after_ development.
Grumble. I'd say a head is expected to reliably move _forward_...
"with" development, yes, but definitely forward. In my book a tag
wouldn't move, but if I take your word for it, then a tag can perhaps
change arbitrarily?
I'm not sure how much support we have in porcelains for "tracking" a
tag if it starts changing. Right now I think we'd find all sorts of
problems, we'd need to think carefully what moving tags means for
porcelains.
> Or something even more specific, like "refs/svn-tracking/". Git
> shouldn't care - all the tools _should_ work fine with any subdirectory
> structure.
I think the moving-forward (therefore is trackable) vs stays reliably
in place distinction *is* useful. "Moves randomly" may also be useful,
but it should get a different treatment, because it's not "trackable".
Not that git and porcelains can't deal with all this stuff. But if
there is a clear convention then porcelains can be smart and refuse to
commit to the wrong place... it'd be a bit of a UI enhancement
perhaps?
martin
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Linus Torvalds @ 2006-02-28 0:41 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Eric Wong, git
In-Reply-To: <46a038f90602271625y6c7e9072u372b8dd3662e272c@mail.gmail.com>
On Tue, 28 Feb 2006, Martin Langhoff wrote:
>
> git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
> Nothing within core git prevents it from moving, but I think that
> porcelains will start breaking. Tags and heads are the same thing,
> except that heads are expected to change (specifically, to move
> forward), and tags are expected to stand still.
Well, I wouldn't say that tags are expected to stand still. Some kinds of
tags are expected to move: a "this is the last tested version" tag would
be expected to move with testing.
That said, the movement is _different_ from a branch. A branch is expected
to move _with_ development, while a tag is expected to either stay the
same, or move _after_ development.
However, in many ways git really doesn't care much. The "refs/heads"
directory is the only one that is really special, in that "git checkout"
refuses to check out a moving branch in anything but that subdirectory.
The "tags" subdirectory is slightly special to some helpers (like "git
pull"), which have flags to pull everythying in that subdirectory.
But other than those two pretty trivial issues, any ref under "refs/"
should work perfectly fine. I would argue that a specialized tracking tool
might well be better off without using either "refs/heads" _or_
"refs/tags", since those have accepted meaning outside of tracking.
Using a "refs/remotes" subdirectory makes tons of sense for something like
this. Or something even more specific, like "refs/svn-tracking/". Git
shouldn't care - all the tools _should_ work fine with any subdirectory
structure.
Linus
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Martin Langhoff @ 2006-02-28 0:25 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060227192422.GB9518@hand.yhbt.net>
On 2/28/06, Eric Wong <normalperson@yhbt.net> wrote:
> > If it is not supposed to be changed by the user, maybe it could be
> > stored as a tag.
> >
> > Or maybe another type of reference can be introduced. refs/remote/, for
> > branches we are tracking, but which should not be modified locally.
>
> Either of those could work for me. Changing git-svn-HEAD to become a
> tag would probably be easier (not having to update other tools, such as
> git-fetch), but refs/remote may make more sense.
git-svn-HEAD "moves" so it's really a bad idea to have it as a tag.
Nothing within core git prevents it from moving, but I think that
porcelains will start breaking. Tags and heads are the same thing,
except that heads are expected to change (specifically, to move
forward), and tags are expected to stand still.
Something else is needed -- a convention to mark a head as 'readonly'
so that git-commit/cg-commit refuse to commit to it. cg-commit already
does that for any head matching the name of a branch.
cheers,
martin
^ permalink raw reply
* Re: the war on trailing whitespace
From: Junio C Hamano @ 2006-02-28 0:10 UTC (permalink / raw)
To: Peter Williams; +Cc: git
In-Reply-To: <44038B73.4030004@bigpond.net.au>
Peter Williams <pwil3058@bigpond.net.au> writes:
>> This whitespace policy should be at least per-project (people
>> working on both kernel and other things may have legitimate
>> reason to want trailing whitespace in the other project),
>
> I'd be interested to hear these reasons. My experience is that people
> don't put trailing white space in deliberately (or even tolerate it if
> they notice it) and it's usually there as a side effect of the way
> their text editor works (and that's also the reason that they don't
> usually notice it). But if my experience is misleading me and there
> are valid reasons for having trailing white space I'm genuinely
> interested in knowing what they are.
For example:
http://compsoc.dur.ac.uk/whitespace/
Jokes aside, I can imagine people want to keep format=flowed
text messages (i.e. not programming language source code) under
git control. Maybe pulling and pushing would be the default
mode of operation for those people, so what git-apply does would
not be in the picture for those people, but who knows.
One way to find it out is to push out a strict one and see who
screams ;-), but the point is I am reluctant to make a stricter
policy the default, thinking, but not knowing as a fact, that it
is good enough for everybody.
^ permalink raw reply
* Re: [PATCH] First cut at libifying revlist generation
From: Junio C Hamano @ 2006-02-27 23:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602270851560.22647@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Here's a cleanup patch that does that. It also moves "unpacked" (and the
> flag parsing) into rev_info, since that actually does affect the revision
> walker too, and thus logically belongs there.
Makes sense. Thanks.
^ permalink raw reply
* Re: the war on trailing whitespace
From: Andrew Morton @ 2006-02-27 23:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd6kxuea.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> tell the higher echelon folks
> to do:
>
> $ git repo-config apply.whitespace error
>
> in their repositories
That might be reasonable, some might object to tiny amounts of extra work..
In my setup, trailing whitespace purely causes warnings. But with a
quilt-style thing, it's trivial to unapply the patch, strip it, reapply.
git is different - I'd imagine that if warnings were generated while an
mbox was being applied, it's too much hassle to go and unapply the mbox,
fix the diffs up and then apply the mbox again.
I'd suggest that git have options to a) generate trailing-whitespace
warnings, b) generate trailing-whitespace errors and c) strip trailing
whitespace while applying. And that the as-shipped default be a).
^ permalink raw reply
* Re: the war on trailing whitespace
From: Peter Williams @ 2006-02-27 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrew Morton, git
In-Reply-To: <7vhd6kxuea.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andrew Morton <akpm@osdl.org> writes:
>
>
>>That's not a good reason. People will discover that git has started
>>shouting at them and they'll work out how to make it stop.
>>
>>The problem is getting C users to turn the check on, not in getting python
>>users to turn it off.
>
>
> This whitespace policy should be at least per-project (people
> working on both kernel and other things may have legitimate
> reason to want trailing whitespace in the other project),
I'd be interested to hear these reasons. My experience is that people
don't put trailing white space in deliberately (or even tolerate it if
they notice it) and it's usually there as a side effect of the way their
text editor works (and that's also the reason that they don't usually
notice it). But if my experience is misleading me and there are valid
reasons for having trailing white space I'm genuinely interested in
knowing what they are.
> so we
> would need some configurability; the problem is *both*.
>
> We could do one of two things, at least.
>
> - I modify the git-apply that is in the "next" branch further
> to make --whitespace=error the default, and push it out. You
> convince people who feed things to you to update to *that*
> version or later.
>
> - I already have the added whitespace detection hook (a fixed
> one that actually matches what I use) shipped with git. You
> convince people who feed things to you to update to *that*
> version or later, and to enable that hook.
>
> I think you are arguing for the first one. I am reluctant to do
> so because it would not help by itself *anyway*. In any case
> you need to convince people who feed things to you to do
> something to prevent later changes fed to you from being
> contaminated with trailing whitespaces.
>
> Having said that, I have a third solution, which consists of two
> patches that come on top of what are already in "next" branch:
>
> - apply: squelch excessive errors and --whitespace=error-all
> - apply --whitespace: configuration option.
>
> With these, git-apply used by git-applymbox and git-am would
> refuse to apply a patch that adds trailing whitespaces, when the
> per-repository configuration is set like this:
>
> [apply]
> whitespace = error
>
> (Alternatively,
>
> $ git repo-config apply.whitespace error
>
> would set these lines there for you).
>
> I think there are three kinds of git users.
>
> * Linus, you, and the kernel subsystem maintainers. The
> whitespace policy with this version of git-apply (with the
> configuration option set to apply.whitespace=error) gives
> would help these people by enforcing the SubmittingPatches
> and your "perfect patch" requirements.
>
> * People who feed patches to the above people. They are helped
> by enabling the pre-commit hook that comes with git to
> conform to the kernel whitespace policy -- they need to be
> educated to do so.
>
> * People outside of kernel community, using git in projects to
> which the kernel whitespace policy does not have any
> relevance.
>
> While I do consider the kernel folks a lot more important
> customers than other users, I have to take flak from the third
> kind of users, and to them, authority by Linus or you does not
> weigh as much as the first two classes of people. Making the
> default to --whitespace=error means that you are making me
> justify this kernel project policy as something applicable to
> projects outside the kernel. That is simply not fair to me.
>
> You have to convince people you work with to update to at least
> to this version anyway, so I do not think it is too much to ask
> from you, while you are at it, to tell the higher echelon folks
> to do:
>
> $ git repo-config apply.whitespace error
>
> in their repositories (and/or set that in their templates so new
> repositories created with git-init-db would inherit it).
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
^ permalink raw reply
* Re: the war on trailing whitespace
From: Junio C Hamano @ 2006-02-27 23:18 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20060227011832.78359f0a.akpm@osdl.org>
Andrew Morton <akpm@osdl.org> writes:
> That's not a good reason. People will discover that git has started
> shouting at them and they'll work out how to make it stop.
>
> The problem is getting C users to turn the check on, not in getting python
> users to turn it off.
This whitespace policy should be at least per-project (people
working on both kernel and other things may have legitimate
reason to want trailing whitespace in the other project), so we
would need some configurability; the problem is *both*.
We could do one of two things, at least.
- I modify the git-apply that is in the "next" branch further
to make --whitespace=error the default, and push it out. You
convince people who feed things to you to update to *that*
version or later.
- I already have the added whitespace detection hook (a fixed
one that actually matches what I use) shipped with git. You
convince people who feed things to you to update to *that*
version or later, and to enable that hook.
I think you are arguing for the first one. I am reluctant to do
so because it would not help by itself *anyway*. In any case
you need to convince people who feed things to you to do
something to prevent later changes fed to you from being
contaminated with trailing whitespaces.
Having said that, I have a third solution, which consists of two
patches that come on top of what are already in "next" branch:
- apply: squelch excessive errors and --whitespace=error-all
- apply --whitespace: configuration option.
With these, git-apply used by git-applymbox and git-am would
refuse to apply a patch that adds trailing whitespaces, when the
per-repository configuration is set like this:
[apply]
whitespace = error
(Alternatively,
$ git repo-config apply.whitespace error
would set these lines there for you).
I think there are three kinds of git users.
* Linus, you, and the kernel subsystem maintainers. The
whitespace policy with this version of git-apply (with the
configuration option set to apply.whitespace=error) gives
would help these people by enforcing the SubmittingPatches
and your "perfect patch" requirements.
* People who feed patches to the above people. They are helped
by enabling the pre-commit hook that comes with git to
conform to the kernel whitespace policy -- they need to be
educated to do so.
* People outside of kernel community, using git in projects to
which the kernel whitespace policy does not have any
relevance.
While I do consider the kernel folks a lot more important
customers than other users, I have to take flak from the third
kind of users, and to them, authority by Linus or you does not
weigh as much as the first two classes of people. Making the
default to --whitespace=error means that you are making me
justify this kernel project policy as something applicable to
projects outside the kernel. That is simply not fair to me.
You have to convince people you work with to update to at least
to this version anyway, so I do not think it is too much to ask
from you, while you are at it, to tell the higher echelon folks
to do:
$ git repo-config apply.whitespace error
in their repositories (and/or set that in their templates so new
repositories created with git-init-db would inherit it).
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Shawn Pearce @ 2006-02-27 22:26 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas
In-Reply-To: <20060227204252.GA31836@diana.vm.bytemark.co.uk>
Karl Hasselstr?m <kha@treskal.com> wrote:
> If I make a patch series where more than one patch touches the same
> line, I get a lot of merge errors when upstream has accepted them and
> I try to merge them back.
>
> Suppose a line contained the string "0". Patch p1 changes that to "1",
> patch p2 further changes that to "2". Upstream accept the patches, and
> I later "stg pull" them. When reapplying p1 after the pull, stg
> generates a merge conflict since upstream changed the "0" to "2" and
> p1 changes the "0" to "1".
You should look at pg:
http://www.spearce.org/2006/02/pg-version-0111-released.html
It has some of the features of StGIT and it (at least partially)
solves this problem.
Assume you had a patch stack of:
PatchA : Change 0 to a 1
PatchB : Change 1 to a 2
PatchC : Change 2 to a 3
with each affecting the same line of the same file.
When pg grabs its (possibly remote) parent ("stg pull" aka pg-rebase)
we try to push down PatchA. If PatchA fails to push cleanly we'll
pop it off and try to push PatchA + PatchB. If that pushes cleanly
then we fold the content of PatchA into PatchB, effectively making
PatchA part of PatchB. If PatchA + PatchB failed to push down
cleanly then we pop both and retry pushing PatchA + PatchB + PatchC.
If that pushes down cleanly then we make PatchA and PatchB officially
part of PatchC.
This required some ``hacks'' in pg-push. Basically if we are
doing a non-fastforward push (as there are new commits we must
merge on top of) we run an external diff/patch to apply the change.
If that fails we reset the tree back to a clean state and try again.
Whenever patch rejects a hunk we examine the hunk to see if it is
already applied to the target file; if it is already applied we
skip the hunk. If all hunks applied cleanly and/or are already
applied we accept the patch (or combination of patches) as merging
cleanly. Yea, its not very pretty. But it works!
Where it falls down is if the upstream accepts all three of your
patches but then changes the line from a 3 to a 4. pg won't look
at the GIT commit history to detect that the upstream accepted your
final change (PatchC) but then overwrite it with a newer change
(3->4). I have thought about trying to implement this but the
current environment where I am using pg wouldn't benefit from it,
so it has not been high on my priority list.
--
Shawn.
^ permalink raw reply
* [PATCH 2/2] Save username -> Full Name <email@addr.es> map file
From: Karl Hasselström @ 2006-02-27 23:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <440195D4.7080905@op5.se>
When the user specifies a username -> Full Name <email@addr.es> map
file with the -A option, save a copy of that file as
$git_dir/svn-authors. When running git-svnimport with an existing GIT
directory, use $git_dir/svn-authors (if it exists) unless a file was
explicitly specified with -A.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/git-svnimport.txt | 5 +++++
git-svnimport.perl | 25 ++++++++++++++++++++-----
2 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index 912a808..a158813 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -82,6 +82,11 @@ When importing incrementally, you might
"username". If encountering a commit made by a user not in the
list, abort.
+ For convenience, this data is saved to $GIT_DIR/svn-authors
+ each time the -A option is provided, and read from that same
+ file each time git-svnimport is run with an existing GIT
+ repository without -A.
+
-m::
Attempt to detect merges based on the commit message. This option
will enable default regexes that try to capture the name source
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 86837ed..639aa41 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -13,6 +13,7 @@
use strict;
use warnings;
use Getopt::Std;
+use File::Copy;
use File::Spec;
use File::Temp qw(tempfile);
use File::Path qw(mkpath);
@@ -68,10 +69,16 @@ if ($opt_M) {
push (@mergerx, qr/$opt_M/);
}
+# Absolutize filename now, since we will have chdir'ed by the time we
+# get around to opening it.
+$opt_A = File::Spec->rel2abs($opt_A) if $opt_A;
+
our %users = ();
-if ($opt_A) {
- die "Cannot open $opt_A\n" unless -f $opt_A;
- open(my $authors,$opt_A);
+our $users_file = undef;
+sub read_users($) {
+ $users_file = File::Spec->rel2abs(@_);
+ die "Cannot open $users_file\n" unless -f $users_file;
+ open(my $authors,$users_file);
while(<$authors>) {
chomp;
next unless /^(\S+?)\s*=\s*(.+?)\s*<(.+)>\s*$/;
@@ -302,6 +309,14 @@ EOM
-d $git_dir
or die "Could not create git subdir ($git_dir).\n";
+my $default_authors = "$git_dir/svn-authors";
+if ($opt_A) {
+ read_users($opt_A);
+ copy($opt_A,$default_authors) or die "Copy failed: $!";
+} else {
+ read_users($default_authors) if -f $default_authors;
+}
+
open BRANCHES,">>", "$git_dir/svn2git";
sub node_kind($$$) {
@@ -498,8 +513,8 @@ sub commit {
if (not defined $author) {
$author_name = $author_email = "unknown";
- } elsif ($opt_A) {
- die "User $author is not listed in $opt_A\n"
+ } elsif (defined $users_file) {
+ die "User $author is not listed in $users_file\n"
unless exists $users{$author};
($author_name,$author_email) = @{$users{$author}};
} elsif ($author =~ /^(.*?)\s+<(.*)>$/) {
^ permalink raw reply related
* [PATCH 1/2] Let git-svnimport's author file use same syntax as git-cvsimport's
From: Karl Hasselström @ 2006-02-27 23:08 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <440195D4.7080905@op5.se>
git-cvsimport uses a username => Full Name <email@addr.es> mapping
file with this syntax:
kha=Karl Hasselström <kha@treskal.com>
Since there is no reason to use another format for git-svnimport, use
the same format.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/git-svnimport.txt | 4 ++--
git-svnimport.perl | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-svnimport.txt b/Documentation/git-svnimport.txt
index e0e3a5d..912a808 100644
--- a/Documentation/git-svnimport.txt
+++ b/Documentation/git-svnimport.txt
@@ -75,9 +75,9 @@ When importing incrementally, you might
-A <author_file>::
Read a file with lines on the form
- username User's Full Name <email@addres.org>
+ username = User's Full Name <email@addr.es>
- and use "User's Full Name <email@addres.org>" as the GIT
+ and use "User's Full Name <email@addr.es>" as the GIT
author and committer for Subversion commits made by
"username". If encountering a commit made by a user not in the
list, abort.
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 75ce8e0..86837ed 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -74,7 +74,7 @@ if ($opt_A) {
open(my $authors,$opt_A);
while(<$authors>) {
chomp;
- next unless /^(\S+)\s+(.+?)\s+<(\S+)>$/;
+ next unless /^(\S+?)\s*=\s*(.+?)\s*<(.+)>\s*$/;
(my $user,my $name,my $email) = ($1,$2,$3);
$users{$user} = [$name,$email];
}
^ permalink raw reply related
* Re: [PATCH 4/4] Read author names and emails from a file
From: Karl Hasselström @ 2006-02-27 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vbqwt1h9r.fsf@assigned-by-dhcp.cox.net>
On 2006-02-26 21:51:12 -0800, Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > This is a good thing, but wouldn't it be better to use the same
> > format as that of cvsimport's -A flag?
>
> If both CVS and SVN have their own native format to express things
> like this, and if the format they use are different, then that is a
> valid reason for git-{cvs,svn}import to use different file format.
>
> But if that is not the case, I tend to agree that it might be easier
> for users if we had just one format. I do not think, however, any
> single project is likely to have to deal with both CVS and SVN
> upstream, importing into the same git repository, so reusing the
> mapping file would not be an issue, but having to learn how to write
> the mapping just once is a good thing.
>
> I do not offhand recall if SVN has its own native format; if it has,
> it may be better to use that, instead of matching what git-cvsimport
> does, since I do not think of a reason why the version with an equal
> sign is preferrable over the version with a space. If the version
> with '=' were the CVS native format then that might be a reason to
> prefer it, but if I recall correctly that is not the case. so...
I don't know of any SVN native format for this, so it seems silly to
use a different format than git-cvsimport. I've also made a patch that
saves the author information, again just like git-cvsimport.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Catalin Marinas @ 2006-02-27 22:17 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20060227204252.GA31836@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> If I make a patch series where more than one patch touches the same
> line, I get a lot of merge errors when upstream has accepted them and
> I try to merge them back.
We discussed about this in the thread announcing pg
(http://article.gmane.org/gmane.comp.version-control.git/16247). This is
not easy to fix because StGIT pushes patches one by one and it stops at
the first conflict. Pg was trying to merge two patches at once but this
is not suitable for StGIT since the latter keeps the patches as single
commits.
There is another problem - the same line might have been modified by a
third-party patch merged into the kernel (and the conflict solved by the
maintainer).
> This situation arises for every line that's modified in more than one
> patch, and for every such patch except the last one. And it's really
> annoying, since it's intuitively obvious that there aren't actually
> any conflicts, since upstream accepted my patches verbatim.
Because I found the same situation a bit annoying, I added the --reset
option to resolved. If you know your patch was merged without
modifications, just use "stg resolved --all --reset local".
An idea (untested, I don't even know whether it's feasible) would be to
check which patches were merged by reverse-applying them starting with
the last. In this situation, all the merged patches should just revert
their changes. You only need to do a git-diff between the bottom and the
top of the patch and git-apply the output (maybe without even modifying
the tree). If this operation succeeds, the patch was integrated and you
don't even need to push it. The tool could even fold two consecutive
patches and reverse-apply them. The disadvantage might be the delay when
pushing patches but we could enable this test only if an option is
passed to the pull command.
If you really want to make StGIT behave intelligently, have a look at
the patch commuting theory in Darcs. It tends to handle this kind of
conflicts easily. StGIT also does some patch commuting but using the
diff3 algorithm and asks the user to fix different conflicts.
Catalin
^ permalink raw reply
* [PATCH] git pull cannot find remote refs.
From: Stefan-W. Hahn @ 2006-02-27 21:49 UTC (permalink / raw)
To: git
[PATCH] git pull cannot find remote refs.
When getting new data from an archive with 'git pull' I sometimes got the
message
fatal: unexpected EOF
Failed to find remote refs
Already up-to-date.
Tracking it down, I found a gap between how git-ls-remote prints out the tags
and git-fetch scans them with sed. Looking at the code of git-ls-remote the
there is an tab character between the sha1 and the refname, while there is a
space and a tab character in the regular expression for th sed command.
As a result the while where all is piped in cannot read the two values.
Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
---
I'm not sure if the solution is the best, because info sed say '\t' is not portable,
so perhaps it will be better to correct it another way?
Comments?
git-fetch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
92905634295ea29a59c773c634197cc029839883
diff --git a/git-fetch.sh b/git-fetch.sh
index 0346d4a..c7b38b2 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -375,7 +375,7 @@ case "$no_tags$tags" in
# using local tracking branch.
taglist=$(IFS=" " &&
git-ls-remote $upload_pack --tags "$remote" |
- sed -ne 's|^\([0-9a-f]*\)[ ]\(refs/tags/.*\)^{}$|\1 \2|p' |
+ sed -ne 's|^\([0-9a-f]*\)[\t]\(refs/tags/.*\)^{}$|\1 \2|p' |
while read sha1 name
do
test -f "$GIT_DIR/$name" && continue
--
1.2.3.gc55f
--
Stefan-W. Hahn It is easy to make things.
/ mailto:stefan.hahn@s-hahn.de / It is hard to make things simple.
^ permalink raw reply related
* Re: bug?: stgit creates (unneccessary?) conflicts when pulling
From: Sam Vilain @ 2006-02-27 21:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, Catalin Marinas
In-Reply-To: <20060227204252.GA31836@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> If I make a patch series where more than one patch touches the same
> line, I get a lot of merge errors when upstream has accepted them and
> I try to merge them back.
>
> Suppose a line contained the string "0". Patch p1 changes that to "1",
> patch p2 further changes that to "2". Upstream accept the patches, and
> I later "stg pull" them. When reapplying p1 after the pull, stg
> generates a merge conflict since upstream changed the "0" to "2" and
> p1 changes the "0" to "1".
>
> This situation arises for every line that's modified in more than one
> patch, and for every such patch except the last one. And it's really
> annoying, since it's intuitively obvious that there aren't actually
> any conflicts, since upstream accepted my patches verbatim.
>
> I suppose one way to fix it manually would be to first fetch, glance
> at the new upstream commits and try to find any accepted patches, and
> then "stg pull" the commit corresponding to the earliest patch in my
> series; repeat for every patch in the series. The queston is, how can
> we automate it?
I don't seem to suffer from this, using my "diff3 ||
ediff-merge-files-with-ancestor" script as a merge tool. The diff3, or
ediff, seem to DTRT so long as the change is cleanly applied. Otherwise
I just get a merge conflict difference and I just press A/B to pick
which one I want.
Sam.
^ permalink raw reply
* [PATCH] contrib/git-svn: correct commit example in manpage
From: Eric Wong @ 2006-02-27 20:55 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git, Junio C Hamano
In-Reply-To: <62402.84.163.87.135.1141073234.squirrel@mail.geht-ab-wie-schnitzel.de>
Thanks to Nicolas Vilz <niv@iaglans.de> for noticing this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
125c2e90f26d8980f415f8066dcc84d02d95f03a
diff --git a/contrib/git-svn/git-svn.txt b/contrib/git-svn/git-svn.txt
index b588a2a..b290739 100644
--- a/contrib/git-svn/git-svn.txt
+++ b/contrib/git-svn/git-svn.txt
@@ -159,7 +159,7 @@ Tracking and contributing to an Subversi
# Commit only the git commits you want to SVN::
git-svn commit <tree-ish> [<tree-ish_2> ...]
# Commit all the git commits from my-branch that don't exist in SVN::
- git commit git-svn-HEAD..my-branch
+ git-svn commit git-svn-HEAD..my-branch
# Something is committed to SVN, pull the latest into your branch::
git-svn fetch && git pull . git-svn-HEAD
# Append svn:ignore settings to the default git exclude file:
--
1.2.3.g4676
^ permalink raw reply related
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Nicolas Vilz 'niv' @ 2006-02-27 20:47 UTC (permalink / raw)
To: git
In-Reply-To: <20060227202713.GB21684@hand.yhbt.net>
Eric Wong wrote:
> [1] - See the 'Additional Fetch Arguments' section of the manpage for
> more info on this. I'll freely admit that the UI for this was an
> accident, but it works fairly well for me.
btw, i think you have a typo in your man-page:
---
# Commit only the git commits you want to SVN::
git-svn commit <tree-ish> [<tree-ish_2> ...]
# Commit all the git commits from my-branch that don't exist in SVN::
git commit git-svn-HEAD..my-branch
---
i think the second one is intended to be "git-svn commit
git-svn-HEAD..my-branch", because you want to sync the SVN tree again, not
another git-tree i think...
Nicolas
^ permalink raw reply
* bug?: stgit creates (unneccessary?) conflicts when pulling
From: Karl Hasselström @ 2006-02-27 20:42 UTC (permalink / raw)
To: git; +Cc: Catalin Marinas
If I make a patch series where more than one patch touches the same
line, I get a lot of merge errors when upstream has accepted them and
I try to merge them back.
Suppose a line contained the string "0". Patch p1 changes that to "1",
patch p2 further changes that to "2". Upstream accept the patches, and
I later "stg pull" them. When reapplying p1 after the pull, stg
generates a merge conflict since upstream changed the "0" to "2" and
p1 changes the "0" to "1".
This situation arises for every line that's modified in more than one
patch, and for every such patch except the last one. And it's really
annoying, since it's intuitively obvious that there aren't actually
any conflicts, since upstream accepted my patches verbatim.
I suppose one way to fix it manually would be to first fetch, glance
at the new upstream commits and try to find any accepted patches, and
then "stg pull" the commit corresponding to the earliest patch in my
series; repeat for every patch in the series. The queston is, how can
we automate it?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: git-svn and huge data and modifying the git-svn-HEAD branch directly
From: Eric Wong @ 2006-02-27 20:27 UTC (permalink / raw)
To: Nicolas Vilz 'niv'; +Cc: git
In-Reply-To: <62354.84.163.87.135.1141068867.squirrel@mail.geht-ab-wie-schnitzel.de>
Nicolas Vilz 'niv' <niv@iaglans.de> wrote:
> ok, i experienced that on little modifications on the git-svn-HEAD branch
> either... so its really about modifying and not about the huge data
> ammount...
Huge data should not have anything to do with it. Well, besides
increasing the chance of somebody committing a conflicting commit while
you're in the middle of your commit. But hey, that's the nature of
centralized SCMs.
> >> now i am still on rev 2 on this branch but i updated it to rev 5 on the
> >> svn-side...
> >>
> >> any hints?
> >
> > Save your current work in git-svn-HEAD to a private branch
> >
> > git branch -b private git-svn-HEAD
> >
> > then reset git-svn-HEAD to the last revision where it was managed by
> > git-svn fetch:
> >
> > git-checkout git-svn-HEAD
> > git-log (look for the last commit with 'git-svn-id:' in it)
> > git-reset --hard <last commit with 'git-svn-id:' in it>
> >
> > Now go to your private branch:
> >
> > git checkout private
> >
> > And continue working on your private branch as usual.
>
> I will keep that in mind for the future. Fortunatelly i am still testing
> and i saved the git repository before experimenting with git-svn.
:)
> Have you any suggestions howto migrate a git-repository to svn and then
> work with git-svn on both of it? I tried cg-merge -j to merge my git
> branch with the private git svn branch, i am allowed to modify safely.
>
> that does work actually... now i can start getting this automated.
>
> perhaps i will write a patch with that automated script, when it is
> finished, just to contribute git.
Cool. I don't know much about cg-*, but I think I did more or less the
same thing (joining branches, but did the join on git-svn-HEAD instead
of a git-only branch) using <revision>=<commit> arguments[1] to git-svn
fetch.
[1] - See the 'Additional Fetch Arguments' section of the manpage for
more info on this. I'll freely admit that the UI for this was an
accident, but it works fairly well for me.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] gitweb: Enable tree (directory) history display
From: Linus Torvalds @ 2006-02-27 19:56 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20060227185554.75822.qmail@web31810.mail.mud.yahoo.com>
On Mon, 27 Feb 2006, Luben Tuikov wrote:
>
> This patch allows history display of whole trees/directories,
> a la "git-rev-list HEAD <dir or file>", but somewhat
> slower, since exported git repository doesn't have
> the files checked out so we have to use
> "$gitbin/git-rev-list $hash | $gitbin/git-diff-tree -r --stdin \'$file_name\'"
No no.
Just use
git-rev-list $hash -- $file_name
where the "--" is the important part.
As a usability-enhancer, you can leave out the "--" to separate filenames
and other things, but when you leave out the "--", git requires that the
filenames exist.
Linus
^ 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