Re: git 1.8.0.rc0.18.gf84667d trouble with git commit -p file
Jeff King p...@peff.net writes: Actually, I am not sure that thread or feature is to blame. Certainly it would have been an opportune time to notice the problem. But this issue goes back much further for git commit --interactive, which has always assumed -i rather than -o. This even predates the switch from shell to C; you can see the same behavior from 6cbf07e (git-commit: add a --interactive option, 2007-03-05). Yes. That was after we started defaulting to only (not also) semantics when the command is run with paths, and it should also have raised a red flag to reviewers. In the case of add/commit --interactive, it is much more clear what state the index is in when the command gave interactive control to the user. The short-cut add/commit -p interface, however, does not give you an access to its s)tatus subcommand, making the user experience somewhat different. That makes the problem much more severe for -p compared to --interactive, but the fundamental UI consistency it introduces is the same as the issue under discussion in this thread. I think the right thing to do is to fix git commit -p so that it starts from the HEAD (on a temporary index), just like how partial commits are made with git commit file1 file2. Or just forbid it when the index does not match HEAD. Agreed. I am inclined to call this a bugfix, though it does worry me slightly that we would be changing a behavior that has existed for so many years. I agree it will be a bugfix, but I am afraid that the fix may have to be much more involved than start from a temporary index that matches HEAD when we are doing the '--only' semantics. Suppose you have two paths E and F, both of which have differences between HEAD and the index, and the index and the working tree file (i.e. you earlier edited E and F, did git add E F and further edited them). You say git commit -p F. What should happen? It is clear that the resulting commit should record no change since its parent commit at path E (that is what only semantics mean). What state should the add -p interaction start from for path F? Should you be picking from a patch between the state you previously git added to the index and the working tree, or should the entire difference between HEAD and the working tree eligible to be picked or deferred during the add -p session? Starting from a temporary index that matches HEAD essentially means that you lose the earlier git add F [*1*]. Another case to consider is to start from the same condition, and instead to say git commit -p without any pathspec. What should happen? Just doing use a temporary index that is initialized to HEAD may be an expedient thing to do, but I suspect that I will be saying the same I should have said 'You cannot have a pony' back then again in a not so distant future if we did so without thinking these things through. As I do not see any practical value in commit -p, I do not think it is worth my time thinking these things through thoroughly myself. Unless somebody who cares about commit -p does so to come up with reasonable semantics, and updates the code to match that desired behaviour, the responsible thing to do is to error out -p when your index is different from HEAD, I think. [Footnote] *1* A not-so-deep thinking of the above might lead to start from the index that match HEAD, except for paths specified on the pathspec given to the -p option. But I do not think it is satisfactory, either. With add -i (or commit --interactive), you have an option to selectively discard parts of your previous, overzealous git add F with its r)evert action, but because commit -p does not give an option to switch to reset -p, you can only add hunks, People who did git add E F earlier and then wants to amend that earlier add with git commit -p F, but it does not allow them to fully amend their earlier action. That is the one of the reasons why I think commit -p is a mistaken we can save one command invocation false economy that adds confusion without adding much value to the UI. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] attr: more matching optimizations from .gitignore
On Sat, Oct 6, 2012 at 12:36 PM, Junio C Hamano gits...@pobox.com wrote: Or the user might think path/ attr1 sets attr1 for all files under path/ because it does not make sense to attach attributes to a directory in git. ... We may not have a need to assign a real attribute to a directory right now, because nothing in Git asks for an attribute for a directory. But that does not necessarily mean we would never need a way to give an attribute to a directory but not to its contents. Exactly why we should not make path/ attr no-op. If we want to make it meaningful some day in future, I don't think we want those no-ops lay around and suddenly cause changes in behavior with a new version of git. If one does not think it through, the path/ excluded example might appear that there is no difference between setting exclude to the path itself and setting it to path and everything underneath it, but that comes largely from the nature of exclude attribute (think of exclude attribute as exclude itself and everything under it). From a user perspective, the thinking through portion is usually less than the try-and-see. There is no reason to assume other attributes we may want to give to a directory share the same recursive kind of semantics. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/10] attr: more matching optimizations from .gitignore
Nguyen Thai Ngoc Duy pclo...@gmail.com writes: On Sat, Oct 6, 2012 at 12:36 PM, Junio C Hamano gits...@pobox.com wrote: Or the user might think path/ attr1 sets attr1 for all files under path/ because it does not make sense to attach attributes to a directory in git. ... We may not have a need to assign a real attribute to a directory right now, because nothing in Git asks for an attribute for a directory. But that does not necessarily mean we would never need a way to give an attribute to a directory but not to its contents. Exactly why we should not make path/ attr no-op. If we want to make it meaningful some day in future, I don't think we want those no-ops lay around and suddenly cause changes in behavior with a new version of git. I do not think you understood. path/ attr is a no-op from the point of view of the *users* of the current versions of Git. It is perfectly fine to accept and apply attr to path/; no codepath in Git should be asking about path/ anyway, so it ends up to be a no-op. You shouldn't be erroring out at the syntactic level, i.e. when these lines are parsed. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] attr: allow pattern escape using backslash
.gitattributes pattern syntax is supposed to be the same as .gitignore
(except a few things that do not make sense in attr context, but
that's a different issue). .gitignore uses fnmatch() as the matching
machinery and \ is accepted as an escape code. In theory the pattern
'foo\ bar' should match path 'foo bar' in .gitignore. Granted, no one
would write 'foo\ bar' in .gitignore when 'foo bar' should
suffice.
Regardless, 'foo\ bar attr' does not (but should) attach attr to
path foo bar because pattern/attr parse code does not understand
backslash escape. It parses the line as path 'foo\' and attributes
'bar' and 'attr'. This patch teaches attr code to recognize the
backslash in patterns (not macro names) and pass 'foo\ bar' down to
fnmatch().
This changes the attr behavior. foo\ attr, if exists in the field,
would match nothing because path foo\ is invalid in UNIX and is a
directory in Windows, which we do not accept attaching attributes
to. With this patch, that line becomes invalid and is rejected. So
it's not really bad (i.e. no silent changes in behavior).
Other subtle behavioral changes may happen. Still, I think we should
do this as it seems like a correct thing to do.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
We discussed the spaces in path names in attr before and I remember
using quotes or double quotes, even substituting spaces with
dots, were raised. I don't remember if backslashes were mentioned.
attr.c| 12 +++-
t/t0003-attributes.sh | 5 +
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/attr.c b/attr.c
index 887a9ae..173d51d 100644
--- a/attr.c
+++ b/attr.c
@@ -221,8 +221,18 @@ static struct match_attr *parse_attr_line(const char
*line, const char *src,
return NULL;
}
}
- else
+ else {
is_macro = 0;
+ namelen = 0;
+ while (name[namelen] != '\0'
+ !strchr(blank, name[namelen])) {
+ if (name[namelen] == '\\'
+ name[namelen + 1] != '\0')
+ namelen += 2;
+ else
+ namelen++;
+ }
+ }
states = name + namelen;
states += strspn(states, blank);
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index febc45c..16b419e 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -24,6 +24,7 @@ test_expect_success 'setup' '
echo offon -test test
echo no notest
echo A/e/F test=A/e/F
+ echo A\\ b test=space
) .gitattributes
(
echo g test=a/g
@@ -196,6 +197,10 @@ test_expect_success 'root subdir attribute test' '
attr_check subdir/a/i unspecified
'
+test_expect_success 'quoting in pattern' '
+ attr_check A b space
+'
+
test_expect_success 'setup bare' '
git clone --bare . bare.git
cd bare.git
--
1.7.12.1.406.g6ab07c4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] attr: allow pattern escape using backslash
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: .gitattributes pattern syntax is supposed to be the same as .gitignore (except a few things that do not make sense in attr context, but that's a different issue). .gitignore uses fnmatch() as the matching machinery and \ is accepted as an escape code. In theory the pattern 'foo\ bar' should match path 'foo bar' in .gitignore. Granted, no one would write 'foo\ bar' in .gitignore when 'foo bar' should suffice. Regardless, 'foo\ bar attr' does not (but should) attach attr to path foo bar because pattern/attr parse code does not understand backslash escape. It parses the line as path 'foo\' and attributes 'bar' and 'attr'. This patch teaches attr code to recognize the backslash in patterns (not macro names) and pass 'foo\ bar' down to fnmatch(). This changes the attr behavior. foo\ attr, if exists in the field, would match nothing because path foo\ is invalid in UNIX and is a directory in Windows, which we do not accept attaching attributes to. With this patch, that line becomes invalid and is rejected. So it's not really bad (i.e. no silent changes in behavior). Other subtle behavioral changes may happen. Still, I think we should do this as it seems like a correct thing to do. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- We discussed the spaces in path names in attr before and I remember using quotes or double quotes, even substituting spaces with dots, were raised. I don't remember if backslashes were mentioned. My knee-jerk reaction, without thinking things through, is that this makes sense and doing the same for .gitignore would, too (even though the one-item-per-line nature of .gitignore makes \ and practically equivalent). Shouldn't we do the same for quoting fnmatch(3) metacharacters? To match a path component 'a' followed by an asterisk followed by 'b', you could then write 'a\*b'. Same for quoting the backslash itself. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC] attr: allow pattern escape using backslash
On Sat, Oct 6, 2012 at 2:54 PM, Junio C Hamano gits...@pobox.com wrote: Shouldn't we do the same for quoting fnmatch(3) metacharacters? To match a path component 'a' followed by an asterisk followed by 'b', you could then write 'a\*b'. Same for quoting the backslash itself. I think my patch does that too. The thing it does not do is optimize this case so that we can do strcmp() instead of fnmatch() if the entire pattern does not contain any metacharacters but backslashes. I don't think it'll become popular enough to deserve an optimization. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Proposed function path_in_directory() [was: Re: [PATCH v2 8/9] longest_ancestor_length(): resolve symlinks before comparing paths]
On 10/01/2012 06:51 AM, Michael Haggerty wrote: I think I would advocate that the prefix has to match the front of the path exactly (including any trailing slashes) and either strlen(prefix) == 0 or the prefix ended with a '/' or the prefix and path are identical or the character in path following the matching part is a '/' This would allow the is path its own prefix policy to be decided by the caller by either including or omitting a trailing slash on the prefix argument. Thinking about this more, I don't think it will work. As usual, the special cases around / and // make things awkward. I think it is necessary to have a separate argument to specify whether path is its own prefix. So I am trying to decide how a function path_in_directory() should work, and would like to get some feedback, especially on the following two points: 1. How should // be handled? I don't really have experience with the peculiar paths that start with //, so I'm not sure how they should be handled (or even if the handling needs to be platform-dependent). My working hypothesis is that the inputs should be normalized by the caller, so if the caller wants // to be treated as equivalent to / then the caller should normalize them *before* calling this function. Conversely, if the caller passes // to the function, that implies that // is distinct from / and // is considered a proper subdirectory of /. See the cases marked with ?? below. 2. Does there need to be any special related to DOS paths? /* * Return true iff path is within dir. The comparison is textual, * meaning that path and dir should be normalized and either both be * absolute or both be relative to the same directory. If path and * dir represent the *same* path, then return true iff allow_equal is * true. Single trailing slashes on either path or dir are ignored, * (except for the special case //); i.e., a/b and a/b/ are * treated equivalently, as are and /. Examples (* means don't * care): * * - path_in_directory(a/b, a, *) - true * - path_in_directory(a, a/b, *) - false * - path_in_directory(ab, a, *) - false * - path_in_directory(a/b, a/b, 0) - false * (same if either argument is replaced with a/b/) * - path_in_directory(a/b, a/b, 1) - true * (same if either argument is replaced with a/b/) * - path_in_directory(*, /, 1) - true * - path_in_directory(/, /, 0) - false * - path_in_directory(//, /, 0) - true?? * - path_in_directory(//, /, 1) - true * - path_in_directory(/, //, 0) - false * - path_in_directory(/, //, 1) - false ?? * - path_in_directory(/a/b, //, *) - false */ int path_in_directory(const char *path, const char *dir, int allow_equal); Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitignore.txt: suggestions how to get literal # or ! at the beginning
We support backslash escape, but we hide the details behind the phrase a shell glob suitable for consumption by fnmatch(3). So it may not be obvious how one can get literal # or ! at the beginning of a pattern. Add a few lines on how to work around the magic characters. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Asciidoc 8.2.6 does not like me writing Put \# if you need a literal #.. so I go with backslash and hash instead. `\!` displays fine both in man page and html format. '!' changed to `!` because it looks clearer in monospace. Documentation/gitignore.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 96639e0..8c03ed4 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -74,11 +74,14 @@ PATTERN FORMAT for readability. - A line starting with # serves as a comment. + Put a backslash in front of the first hash for the patterns + that start with a hash. - - An optional prefix '!' which negates the pattern; any + - An optional prefix `!` which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will - override lower precedence patterns sources. + override lower precedence patterns sources. Use `\!` if + you need a literal `!` at the beginning of the pattern. - If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/10] Integrate wildmatch to git
Thiago Farina wrote:
On Fri, Oct 5, 2012 at 1:41 AM, Nguyễn Thái Ngọc Duy
pclo...@gmail.com wrote:
This makes wildmatch.c part of libgit.a and builds test-wildmatch;
the dependency on libpopt in the original has been replaced with the
use
of our parse-options. Global variables in test-wildmatch are marked
static to avoid sparse warnings.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
Signed-off-by: Junio C Hamano gits...@pobox.com
---
.gitignore | 1 +
Makefile | 3 ++
t/t3070-wildmatch.sh | 27
test-wildmatch.c | 88
++-- wildmatch.c
| 26 +--- 5 files changed, 75 insertions(+), 70
deletions(-) create mode 100755 t/t3070-wildmatch.sh
diff --git a/test-wildmatch.c b/test-wildmatch.c
index 88585c2..bb726c8 100644
--- a/test-wildmatch.c
+++ b/test-wildmatch.c
@@ -19,34 +19,38 @@
/*#define COMPARE_WITH_FNMATCH*/
-#define WILD_TEST_ITERATIONS
-#include lib/wildmatch.c
+#include cache.h
+#include parse-options.h
+#include wildmatch.h
-#include popt.h
+#ifndef MAXPATHLEN
+#define MAXPATHLEN 1024
+#endif
+#ifdef NO_STRLCPY
+#include compat/strlcpy.c
+#define strlcpy gitstrlcpy
+#endif
#ifdef COMPARE_WITH_FNMATCH
#include fnmatch.h
-int fnmatch_errors = 0;
+static int fnmatch_errors = 0;
#endif
-int wildmatch_errors = 0;
-char number_separator = ',';
+static int wildmatch_errors = 0;
typedef char bool;
-int output_iterations = 0;
-int explode_mod = 0;
-int empties_mod = 0;
-int empty_at_start = 0;
-int empty_at_end = 0;
-
-static struct poptOption long_options[] = {
- /* longName, shortName, argInfo, argPtr, value, descrip, argDesc
*/
- {iterations, 'i', POPT_ARG_NONE, output_iterations, 0,
0, 0},
- {empties,'e', POPT_ARG_STRING, 0, 'e', 0, 0},
- {explode,'x', POPT_ARG_INT,explode_mod, 0, 0, 0},
- {0,0,0,0, 0, 0, 0}
+static int explode_mod = 0;
Isn't static variables like this initialized to zero by default? There
is a high chance that I might be wrong though.
C99,
5.1.2.1: All objects with static storage duration shall be initialized (set
to their initial values) before program startup.
6.2.4.2: An object whose identifier is declared with external or internal
linkage, or with the storage-class specifier static has static storage
duration. Its lifetime is the entire execution of the program and its stored
value is initialized only once, prior to program startup.
6.7.8.10: If an object that has automatic storage duration is not
initialized explicitly, its value is indeterminate. If an object that has
static storage duration is not initialized explicitly, then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned)
zero;
— if it is an aggregate, every member is initialized (recursively) according
to these rules;
— if it is a union, the first named member is initialized (recursively)
according to these rules.
So seems you're right ;-)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitignore.txt: suggestions how to get literal # or ! at the beginning
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com We support backslash escape, but we hide the details behind the phrase a shell glob suitable for consumption by fnmatch(3). So it may not be obvious how one can get literal # or ! at the beginning of a pattern. Add a few lines on how to work around the magic characters. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Asciidoc 8.2.6 does not like me writing Put \# if you need a literal #.. so I go with backslash and hash instead. `\!` displays fine both in man page and html format. '!' changed to `!` because it looks clearer in monospace. Why not put the backslash-hash in back quotes as well to give the same look/feel consistency? Documentation/gitignore.txt | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 96639e0..8c03ed4 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -74,11 +74,14 @@ PATTERN FORMAT for readability. - A line starting with # serves as a comment. + A line starting with `#` serves as a comment. + Put a backslash in front of the first hash for the patterns + that start with a hash. + Use `\#` if you need a literal `#` at the beginning of the pattern. - - An optional prefix '!' which negates the pattern; any + - An optional prefix `!` which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will - override lower precedence patterns sources. + override lower precedence patterns sources. Use `\!` if + you need a literal `!` at the beginning of the pattern. - If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitignore.txt: suggestions how to get literal # or ! at the beginning
On Sat, Oct 6, 2012 at 6:33 PM, Philip Oakley philipoak...@iee.org wrote: Asciidoc 8.2.6 does not like me writing Put \# if you need a literal #.. so I go with backslash and hash instead. `\!` displays fine both in man page and html format. '!' changed to `!` because it looks clearer in monospace. Why not put the backslash-hash in back quotes as well to give the same look/feel consistency? Because asciidoc does not like \#, '\#' nor `\#`. It just shows \ without # and I don't want to master asciidoc just to make it show \#. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git pull takes ~8 seconds on up-to-date Linux git tree
On Fri, Oct 05, 2012 at 10:20:37PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
@@ -617,6 +618,8 @@ static struct commit_list
*paint_down_to_common(struct commit *one, int n, struc
one-object.flags |= PARENT1;
commit_list_insert_by_date(one, list);
+if (!n)
+return list;
for (i = 0; i n; i++) {
twos[i]-object.flags |= PARENT2;
commit_list_insert_by_date(twos[i], list);
This seems like an obvious optimization, but does it really have
anything to do with the patch at hand?
The function picks one and paints it against all others, but the
logic assumes there must be at least one other to paint against;
otherwise the traversal will not ever find a node that is painted
with both PARENT1 and PARENT2 to stop, leading us to traverse all
the way down to root.
Ah, OK. I was thinking it was just a way to skip the further logic,
which would come to the same answer (it does, just not quickly). Makes
sense.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 1.8.0.rc0.18.gf84667d trouble with git commit -p file
On Fri, Oct 05, 2012 at 11:26:47PM -0700, Junio C Hamano wrote: In the case of add/commit --interactive, it is much more clear what state the index is in when the command gave interactive control to the user. The short-cut add/commit -p interface, however, does not give you an access to its s)tatus subcommand, making the user experience somewhat different. That makes the problem much more severe for -p compared to --interactive, but the fundamental UI consistency it introduces is the same as the issue under discussion in this thread. Agreed. Suppose you have two paths E and F, both of which have differences between HEAD and the index, and the index and the working tree file (i.e. you earlier edited E and F, did git add E F and further edited them). You say git commit -p F. What should happen? It is clear that the resulting commit should record no change since its parent commit at path E (that is what only semantics mean). What state should the add -p interaction start from for path F? Should you be picking from a patch between the state you previously git added to the index and the working tree, or should the entire difference between HEAD and the working tree eligible to be picked or deferred during the add -p session? Starting from a temporary index that matches HEAD essentially means that you lose the earlier git add F [*1*]. Another case to consider is to start from the same condition, and instead to say git commit -p without any pathspec. What should happen? Hmm. Good questions. In the former case, I would have said you should definitely omit E and then start from the staged point of F, as that is almost certainly what the user meant. But that is utterly inconsistent with what we are discussing for the no-pathspec case. I have a gut feeling that what I would expect for -p is roughly: 1. Feed add--interactive the current index state. 2. Feed add--interactive the set of pathspecs on the command line to limit its work. 3. For any path that is updated by the interactive session, keep the result. 4. For other paths, revert to HEAD. I think that would do what I mean most of the time. But it is a horrible set of rules to try to explain to someone (and it is off the top of my head; I wouldn't be surprised if you can come up with a situation where those rules do not behave well). Just doing use a temporary index that is initialized to HEAD may be an expedient thing to do, but I suspect that I will be saying the same I should have said 'You cannot have a pony' back then again in a not so distant future if we did so without thinking these things through. As I do not see any practical value in commit -p, I do not think it is worth my time thinking these things through thoroughly myself. Unless somebody who cares about commit -p does so to come up with reasonable semantics, and updates the code to match that desired behaviour, the responsible thing to do is to error out -p when your index is different from HEAD, I think. Yeah. I did not agree with your conclusion here when we started the conversation, but I am starting to now. I am not opposed at all to somebody working out the semantics, but I do not really care to work on it myself. In the meantime, I would rather not do any halfway fixes that will just make things worse. Another option is to leave it with -i semantics in the meantime, which are at least easy to explain: it is simply a shorthand for running git add -p git commit. That may be inconsistent with other aspects of commit, but people have (apparently) been happy with it, and there has not been a rash of complaints. As a non-user of commit -p myself, I don't have a strong opinion either way. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitignore.txt: suggestions how to get literal # or ! at the beginning
On Sat, Oct 06, 2012 at 06:43:50PM +0700, Nguyen Thai Ngoc Duy wrote: On Sat, Oct 6, 2012 at 6:33 PM, Philip Oakley philipoak...@iee.org wrote: Asciidoc 8.2.6 does not like me writing Put \# if you need a literal #.. so I go with backslash and hash instead. `\!` displays fine both in man page and html format. '!' changed to `!` because it looks clearer in monospace. Why not put the backslash-hash in back quotes as well to give the same look/feel consistency? Because asciidoc does not like \#, '\#' nor `\#`. It just shows \ without # and I don't want to master asciidoc just to make it show \#. It works fine for me with asciidoc 8.6.7. sigh I would think the inline literal syntax started in 8.2.5 would take care of it; maybe there were some bug fixes, considering how new it was in your version. I also think switching ! to `!` is a slight regression; it will change fonts in the HTML version, but usually not in the manpage, and the loss of the quotes makes things harder to read. I would use both, and it does not hurt to also spell out the name of the punctuation. So this: diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 96639e0..c0a5851 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -73,12 +73,15 @@ PATTERN FORMAT - A blank line matches no files, so it can serve as a separator for readability. - - A line starting with # serves as a comment. + - A line starting with `#` serves as a comment. + Put a backslash (`\`) in front of the first hash for the patterns + that start with a hash (i.e., `\#`). - - An optional prefix '!' which negates the pattern; any + - An optional prefix `!` which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will - override lower precedence patterns sources. + override lower precedence patterns sources. Use `\!` if + you need a literal `!` at the beginning of the pattern. - If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find renders to: · A line starting with # serves as a comment. Put a backslash (\) in front of the first hash for the patterns that start with a hash (i.e., \#). · An optional prefix ! which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will override lower precedence patterns sources. Use \! if you need a literal ! at the beginning of the pattern. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report
On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote: Thank you for your response. I do see the dilemma, but having no possible unmodified state is extremely inconvenient and, as shown, breaks basic git operations. But you have asked for an impossible state. You have said this file cannot have CR when you check it in, because we erase them. And yet the version of the file in HEAD has CRs in it. So it must appear modified with respect to HEAD. And the solution is to make a commit with the normalized content. You said in your test script: # Committing test.txt or clearing .gitattributes does clear # the modified status, but those options are undesirable Why is the commit undesirable? You have decided that CRs will no longer be tolerated in your repository (by setting .gitattributes). Now you need to record that change in history with a commit that strips out the CRs. I guess my thought is that if git doesn't allow CRs to be checked in, then it should strip the CRs when checking the file out, and consider that form (or both forms) as unmodified. It just doesn't make sense to me that files are considered modified immediately after checkout. It is not about having CRs in the working tree file. Those are now considered uninteresting and stripped by git when comparing to the HEAD. The problem is that what's in your _repository_ has CRs. I wonder if this is a fundamental misunderstanding of how the CRLF handling in git works. It is not magically make me not care about line endings anymore. It is the canonical version in the repo is LF-only. Strip anything coming into the repository to match that, and (optionally) add CR to anything going out to the filesystem for my convenience. But you need a flag day to update the in-repository versions to the new scheme. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] gitignore.txt: suggestions how to get literal # or ! at the beginning
We support backslash escape, but we hide the details behind the phrase a shell glob suitable for consumption by fnmatch(3). So it may not be obvious how one can get literal # or ! at the beginning of pattern. Add a few lines on how to work around the magic characters. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- On Sat, Oct 6, 2012 at 8:21 PM, Jeff King p...@peff.net wrote: It works fine for me with asciidoc 8.6.7. sigh 8.6.5 works. I don't care deeply as I read .txt anyway. Here it goes again with examples. Documentation/gitignore.txt | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 96639e0..0bcf079 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -73,12 +73,16 @@ PATTERN FORMAT - A blank line matches no files, so it can serve as a separator for readability. - - A line starting with # serves as a comment. + - A line starting with `#` serves as a comment. + Use `\#` instead for patterns that begin with `#`, + for example, `\#backup#.txt`. - - An optional prefix '!' which negates the pattern; any + - An optional prefix `!` which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will override lower precedence patterns sources. + Use `\!` instead for patterns that begin with `!`, + for example, `\!important!.txt`. - If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git-prompt method for querying users
Am 04.01.2012 01:12 schrieb Junio C Hamano: Now prompt is no longer a method but is merely a helper function, so I've queued this (and 1/2 rewrite we discussed in a separate thread) to 'pu' after rewording the commit log message. Thanks. Is there a reason why these changes did not get merged? The issues are still there. -- Best regards, Sven Strickroth PGP key id F5A9D4C4 @ any key-server -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gitignore.txt: suggestions how to get literal # or ! at the beginning
On Sat, Oct 06, 2012 at 08:51:24PM +0700, Nguyen Thai Ngoc Duy wrote: We support backslash escape, but we hide the details behind the phrase a shell glob suitable for consumption by fnmatch(3). So it may not be obvious how one can get literal # or ! at the beginning of pattern. Add a few lines on how to work around the magic characters. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- On Sat, Oct 6, 2012 at 8:21 PM, Jeff King p...@peff.net wrote: It works fine for me with asciidoc 8.6.7. sigh 8.6.5 works. I don't care deeply as I read .txt anyway. Here it goes again with examples. I'd be slightly worried that we are hurting other people who do care and are on older versions of asciidoc. It would be nice if we actually knew the cause of the different behaviors we saw and if there was a way to work around it (it might not even be old asciidoc, but rather old docbook). Part of me wants to just take the change and see if anybody complains. But that is probably the wrong thing to do, and just my general frustration with our doc toolchain talking. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 0/5] Create single PDF for all HTML files
Hi, I wanted to have a single PDF file which contains the complete Git documentation (except user-manual) for easier reading on my tablet. The simplest way to do this was by using wkhtmltopdf which can combine a set of HTML files into a sinlge PDF file and also apply some reformatting. To this end HTML files for all the missing files in Documentation/technical and Documentation/howto and also for all the release notes in Documentation/RelNotes were created. The resulting PDF file git-doc.pdf is created by a new make target called fullpdf. Hope anybody finds that useful. --- Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 1/5] Fix some asciidoc layout problems
Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/git-bisect-lk2009.txt | 12 ++-- Documentation/git-fetch-pack.txt| 5 - 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index 8a2ba37..99bdb46 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -248,7 +248,7 @@ Bisecting: 5480 revisions left to test after this (roughly 13 steps) And after a few more steps like that, git bisect will eventually find a first bad commit: -- + $ git bisect bad 2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit commit 2ddcca36c8bcfa251724fe342c8327451988be0d @@ -257,8 +257,8 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile -- +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile + At this point we can see what the commit does, check it out (if it's not already checked out) or tinker with it, for example: @@ -305,7 +305,7 @@ to launch a script or command at each bisection step to know if the current commit is good or bad. To do that, we use the git bisect run command. For example: -- + $ git bisect start v2.6.27 v2.6.25 Bisecting: 10928 revisions left to test after this (roughly 14 steps) [2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit @@ -331,9 +331,9 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile bisect run success -- + In this example, we passed grep '^SUBLEVEL = 25' Makefile as parameter to git bisect run. This means that at each step, the grep diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 474fa30..12cd8a2 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -9,7 +9,10 @@ git-fetch-pack - Receive missing objects from another repository SYNOPSIS [verse] -'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=git-upload-pack] [--depth=n] [--no-progress] [-v] [host:]directory [refs...] +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] + [--upload-pack=git-upload-pack] + [--depth=n] [--no-progress] + [-v] [host:]directory [refs...] DESCRIPTION --- -- 1.7.11.msysgit.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 2/5] Create html documents for all files in Documentation/technical
- add missing files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/Makefile| 12 ++- Documentation/technical/index-format.txt | 2 +- Documentation/technical/pack-format.txt | 8 +++ Documentation/technical/pack-protocol.txt | 7 +++--- Documentation/technical/shallow.txt | 8 ++- Documentation/technical/trivial-merge.txt | 36 +++ 6 files changed, 45 insertions(+), 28 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 267dfe1..86594f6 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -25,6 +25,16 @@ SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) +API_DOCS += technical/index-format +API_DOCS += technical/pack-format +API_DOCS += technical/pack-heuristics +API_DOCS += technical/pack-protocol +API_DOCS += technical/protocol-capabilities +API_DOCS += technical/protocol-common +API_DOCS += technical/racy-git +API_DOCS += technical/send-pack-pipeline +API_DOCS += technical/shallow +API_DOCS += technical/trivial-merge SP_ARTICLES += $(API_DOCS) SP_ARTICLES += technical/api-index @@ -231,7 +241,7 @@ clean: $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf $(RM) howto-index.txt howto/*.html doc.dep - $(RM) technical/api-*.html technical/api-index.txt + $(RM) technical/*.html technical/api-index.txt $(RM) $(cmds_txt) *.made $(RM) manpage-base-url.xsl diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..57d6f91 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -1,7 +1,7 @@ GIT index format -= The git index file has the following format +== The git index file has the following format All binary numbers are in network byte order. Version 2 is described here unless stated otherwise. diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index 1803e64..a7871fb 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -1,7 +1,7 @@ GIT pack format === -= pack-*.pack files have the following format: +== pack-*.pack files have the following format: - A header appears at the beginning and consists of the following: @@ -34,7 +34,7 @@ GIT pack format - The trailer records 20-byte SHA1 checksum of all of the above. -= Original (version 1) pack-*.idx files have the following format: +== Original (version 1) pack-*.idx files have the following format: - The header consists of 256 4-byte network byte order integers. N-th entry of this table records the number of @@ -123,8 +123,8 @@ Pack file entry: + -= Version 2 pack-*.idx files support packs larger than 4 GiB, and - have some other reorganizations. They have the format: +== Version 2 pack-*.idx files support packs larger than 4 GiB, and + have some other reorganizations. They have the format: - A 4-byte magic number '\377tOc' which is an unreasonable fanout[0] value. diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index d51e20f..25e1fbe 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -117,7 +117,7 @@ A few things to remember here: - The repository path is always quoted with single quotes. Fetching Data From a Server -=== +--- When one Git repository wants to get data that a second repository has, the first can 'fetch' from the second. This operation determines @@ -134,7 +134,8 @@ with the object name that each reference currently points to. $ echo -e -n 0039git-upload-pack /schacon/gitbook.git\0host=example.com\0 | nc -v example.com 9418 - 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag + 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack +side-band side-band-64k ofs-delta shallow no-progress include-tag 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9 @@ -421,7 +422,7 @@ entire packfile without multiplexing. Pushing Data To a Server - + Pushing data to a server will invoke the 'receive-pack' process on the server, which will allow the client to tell it which references it should diff --git
[Patch 3/5] Create html documents for all files in Documentation/RelNotes
- create html for all release note files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/Makefile | 2 ++ Documentation/RelNotes/1.5.2.1.txt | 6 -- Documentation/RelNotes/1.6.0.2.txt | 6 -- Documentation/RelNotes/1.6.1.3.txt | 4 Documentation/RelNotes/1.6.1.4.txt | 3 --- Documentation/RelNotes/1.6.1.txt | 6 -- 6 files changed, 2 insertions(+), 25 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 86594f6..80eb06d 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -24,6 +24,7 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +RELNOTES = $(patsubst %.txt,%,$(wildcard RelNotes/*.txt)) API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) API_DOCS += technical/index-format API_DOCS += technical/pack-format @@ -35,6 +36,7 @@ API_DOCS += technical/racy-git API_DOCS += technical/send-pack-pipeline API_DOCS += technical/shallow API_DOCS += technical/trivial-merge +API_DOCS += $(RELNOTES) SP_ARTICLES += $(API_DOCS) SP_ARTICLES += technical/api-index diff --git a/Documentation/RelNotes/1.5.2.1.txt b/Documentation/RelNotes/1.5.2.1.txt index ebf20e2..d41984d 100644 --- a/Documentation/RelNotes/1.5.2.1.txt +++ b/Documentation/RelNotes/1.5.2.1.txt @@ -45,9 +45,3 @@ Fixes since v1.5.2 - git-fastimport --import-marks was broken; fixed. - A lot of documentation updates, clarifications and fixes. - --- -exec /var/tmp/1 -O=v1.5.2-65-g996e2d6 -echo O=`git describe refs/heads/maint` -git shortlog --no-merges $O..refs/heads/maint diff --git a/Documentation/RelNotes/1.6.0.2.txt b/Documentation/RelNotes/1.6.0.2.txt index e1e24b3..7d8fb85 100644 --- a/Documentation/RelNotes/1.6.0.2.txt +++ b/Documentation/RelNotes/1.6.0.2.txt @@ -79,9 +79,3 @@ Fixes since v1.6.0.1 packfile. Also contains many documentation updates. - --- -exec /var/tmp/1 -O=v1.6.0.1-78-g3632cfc -echo O=$(git describe maint) -git shortlog --no-merges $O..maint diff --git a/Documentation/RelNotes/1.6.1.3.txt b/Documentation/RelNotes/1.6.1.3.txt index 6f0bde1..cd08d81 100644 --- a/Documentation/RelNotes/1.6.1.3.txt +++ b/Documentation/RelNotes/1.6.1.3.txt @@ -26,7 +26,3 @@ Fixes since v1.6.1.2 * RPM binary package installed the html manpages in a wrong place. Also includes minor documentation fixes and updates. - - --- -git shortlog --no-merges v1.6.1.2-33-gc789350.. diff --git a/Documentation/RelNotes/1.6.1.4.txt b/Documentation/RelNotes/1.6.1.4.txt index 0ce6316..ccbad79 100644 --- a/Documentation/RelNotes/1.6.1.4.txt +++ b/Documentation/RelNotes/1.6.1.4.txt @@ -39,6 +39,3 @@ Fixes since v1.6.1.3 This fix was first merged to 1.6.2.3. Also includes minor documentation fixes and updates. - --- -git shortlog --no-merges v1.6.1.3.. diff --git a/Documentation/RelNotes/1.6.1.txt b/Documentation/RelNotes/1.6.1.txt index adb7cca..7b152a6 100644 --- a/Documentation/RelNotes/1.6.1.txt +++ b/Documentation/RelNotes/1.6.1.txt @@ -278,9 +278,3 @@ release, unless otherwise noted. * gitweb did not mark non-ASCII characters imported from external HTML fragments correctly. - --- -exec /var/tmp/1 -O=v1.6.1-rc3-74-gf66bc5f -echo O=$(git describe master) -git shortlog --no-merges $O..master ^maint -- 1.7.11.msysgit.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Patch 4/5] Create html documents for all files in Documentation/howto
- add missing files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/Makefile | 10 + Documentation/howto/maintain-git.txt | 4 ++ .../howto/rebase-from-internal-branch.txt | 11 ++--- Documentation/howto/rebuild-from-update-hook.txt | 4 ++ .../howto/recover-corrupted-blob-object.txt| 10 + Documentation/howto/revert-a-faulty-merge.txt | 4 ++ Documentation/howto/separating-topic-branches.txt | 4 ++ Documentation/howto/setup-git-server-over-http.txt | 4 ++ Documentation/howto/update-hook-example.txt| 50 +++--- Documentation/howto/use-git-daemon.txt | 3 ++ .../howto/using-signed-tag-in-pull-request.txt | 4 +- 11 files changed, 76 insertions(+), 32 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 80eb06d..abd27b5 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -24,6 +24,16 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +SP_ARTICLES += howto/use-git-daemon +SP_ARTICLES += howto/update-hook-example +SP_ARTICLES += howto/setup-git-server-over-http +SP_ARTICLES += howto/separating-topic-branches +SP_ARTICLES += howto/revert-a-faulty-merge +SP_ARTICLES += howto/recover-corrupted-blob-object +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebuild-from-update-hook +SP_ARTICLES += howto/rebase-from-internal-branch +SP_ARTICLES += howto/maintain-git RELNOTES = $(patsubst %.txt,%,$(wildcard RelNotes/*.txt)) API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) API_DOCS += technical/index-format diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 8823a37..58fd809 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -5,6 +5,10 @@ Abstract: Imagine that git development is racing along as usual, when our friend neighborhood maintainer is struck down by a wayward bus. Out of the hordes of suckers (loyal developers), you have been tricked (chosen) to step up as the new maintainer. This howto will show you how to do it. +Content-type: text/asciidoc + +Maintain Git + The maintainer's git time is spent on three activities. diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt index 74a1c0c..577b9a7 100644 --- a/Documentation/howto/rebase-from-internal-branch.txt +++ b/Documentation/howto/rebase-from-internal-branch.txt @@ -8,7 +8,12 @@ Abstract: In this article, JC talks about how he rebases the the master branch, and how rebase works. Also discussed is how this applies to individual developers who sends patches upstream. +Content-type: text/asciidoc +Rebase from internal branch +=== + +-- Petr Baudis pa...@suse.cz writes: Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter @@ -19,6 +24,7 @@ Petr Baudis pa...@suse.cz writes: branch to the real branches. Actually, wouldn't this be also precisely for what StGIT is intended to? +-- Exactly my feeling. I was sort of waiting for Catalin to speak up. With its basing philosophical ancestry on quilt, this is @@ -156,8 +162,3 @@ you continue on starting from the new master head, which is the #1' commit. -jc - -- -To unsubscribe from this list: send the line unsubscribe git in -the body of a message to majord...@vger.kernel.org -More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/Documentation/howto/rebuild-from-update-hook.txt b/Documentation/howto/rebuild-from-update-hook.txt index 48c6756..7aa13ac 100644 --- a/Documentation/howto/rebuild-from-update-hook.txt +++ b/Documentation/howto/rebuild-from-update-hook.txt @@ -5,6 +5,10 @@ Date: Fri, 26 Aug 2005 18:19:10 -0700 Abstract: In this how-to article, JC talks about how he uses the post-update hook to automate git documentation page shown at http://www.kernel.org/pub/software/scm/git/docs/. +Content-type: text/asciidoc + +Rebuild from update hook + The pages under http://www.kernel.org/pub/software/scm/git/docs/ are built from Documentation/ directory of the git.git project diff --git a/Documentation/howto/recover-corrupted-blob-object.txt b/Documentation/howto/recover-corrupted-blob-object.txt index 323b513..2af4ad7 100644 --- a/Documentation/howto/recover-corrupted-blob-object.txt +++ b/Documentation/howto/recover-corrupted-blob-object.txt @@ -3,11 +3,17 @@ From: Linus Torvalds torva...@linux-foundation.org Subject: corrupt object on git-gc Abstract: Some tricks to reconstruct blob objects in order to
[Patch 5/5] Create pdf from all html files
- use wkhtmltopdf to combine all html files into a single pdf file git-doc.pdf - provide make target fullpdf to create git-doc.pdf Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/.gitignore | 1 + Documentation/Makefile| 9 + Documentation/footerend.txt | 4 Documentation/footerstart.txt | 7 +++ Documentation/makedocpdf.sh | 25 + Makefile | 6 ++ 6 files changed, 52 insertions(+) create mode 100644 Documentation/footerend.txt create mode 100644 Documentation/footerstart.txt create mode 100644 Documentation/makedocpdf.sh diff --git a/Documentation/.gitignore b/Documentation/.gitignore index d62aebd..fba4730 100644 --- a/Documentation/.gitignore +++ b/Documentation/.gitignore @@ -10,3 +10,4 @@ howto-index.txt doc.dep cmds-*.txt manpage-base-url.xsl +docfiles.txt diff --git a/Documentation/Makefile b/Documentation/Makefile index abd27b5..c4c2a30 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -189,6 +189,9 @@ info: git.info gitman.info pdf: user-manual.pdf +fullpdf: pdf all + ./makedocpdf.sh + install: install-man install-man: man @@ -213,6 +216,10 @@ install-pdf: pdf $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) $(INSTALL) -m 644 user-manual.pdf $(DESTDIR)$(pdfdir) +install-fullpdf: fullpdf install-pdf + $(INSTALL) -d -m 755 $(DESTDIR)$(pdfdir) + $(INSTALL) -m 644 git-doc.pdf $(DESTDIR)$(pdfdir) + install-html: html '$(SHELL_PATH_SQ)' ./install-webdoc.sh $(DESTDIR)$(htmldir) @@ -252,6 +259,8 @@ clean: $(RM) *.xml *.xml+ *.html *.html+ *.1 *.5 *.7 $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf + $(RM) docfiles.txt + $(RM) RelNotes/*.html $(RM) howto-index.txt howto/*.html doc.dep $(RM) technical/*.html technical/api-index.txt $(RM) $(cmds_txt) *.made diff --git a/Documentation/footerend.txt b/Documentation/footerend.txt new file mode 100644 index 000..ed16923 --- /dev/null +++ b/Documentation/footerend.txt @@ -0,0 +1,4 @@ +/td + /tr +/table +/body/html diff --git a/Documentation/footerstart.txt b/Documentation/footerstart.txt new file mode 100644 index 000..a2746ef --- /dev/null +++ b/Documentation/footerstart.txt @@ -0,0 +1,7 @@ +html +head/head +body style=border:0; margin: 0; onload=subst() +table style=border-top: 1px solid black; width: 100% + tr +td class=section/td +td style=text-align:center diff --git a/Documentation/makedocpdf.sh b/Documentation/makedocpdf.sh new file mode 100644 index 000..fd9f5bb --- /dev/null +++ b/Documentation/makedocpdf.sh @@ -0,0 +1,25 @@ +#!/bin/sh + +rm -f git-doc.pdf + +cat /dev/null docfiles.txt + +ls gittutorial.html docfiles.txt +ls gittutorial-2.htmldocfiles.txt +ls everyday.html docfiles.txt +ls gitworkflows.html docfiles.txt +ls git-*.htmldocfiles.txt +ls git[acdghikmnr]*.html docfiles.txt +ls gitweb*.html docfiles.txt +ls howto-index.html docfiles.txt +ls howto/*.html docfiles.txt +ls technical/*.html docfiles.txt +ls RelNotes/*.html docfiles.txt + +cat /dev/null footer.html + +cat footerstart.txt footer.html +cat ../GIT-VERSION-FILE footer.html +cat footerend.txt footer.html + +cat docfiles.txt | xargs cat | wkhtmltopdf --book --footer-html footer.html --disable-external-links - git-doc.pdf diff --git a/Makefile b/Makefile index 8413606..2ddb3c9 100644 --- a/Makefile +++ b/Makefile @@ -2485,6 +2485,9 @@ info: pdf: $(MAKE) -C Documentation pdf +fullpdf: + $(MAKE) -C Documentation fullpdf + XGETTEXT_FLAGS = \ --force-po \ --add-comments \ @@ -2796,6 +2799,9 @@ install-info: install-pdf: $(MAKE) -C Documentation install-pdf +install-fullpdf: + $(MAKE) -C Documentation install-fullpdf + quick-install-doc: $(MAKE) -C Documentation quick-install -- 1.7.11.msysgit.1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] add a lua pretty format
On Mon, Sep 24, 2012 at 08:25:39PM -0400, Jeff King wrote: @@ -1168,7 +1180,11 @@ void format_commit_message(const struct commit *commit, free(enc); } - strbuf_expand(sb, format, format_commit_item, context); + if (pretty_ctx-fmt == CMIT_FMT_USERFORMAT) + strbuf_expand(sb, format, format_commit_item, context); + else if (pretty_ctx-fmt == CMIT_FMT_LUA) + lua_commit_format(sb, context); + This hunk breaks lots of tests. I know we are not seriously considering the lua series as-is, but in case anybody wants to play with it, here is the fix (and we would need the same fix regardless of language, anyway). You might want to queue this on jk/lua-hackery (probably it would be squashed in for a real series). -- 8 -- Subject: [PATCH] pretty: fix up one-off format_commit_message calls If the usual pretty-print code invokes format_commit_message, the fmt field of the pretty_print_context will always have either CMIT_FMT_USERFORMAT or CMIT_FMT_LUA in it, and we can just choose which to use. However, many call sites invoke format_commit_message directly without bothering to set the fmt field of the context; they expect format_commit_message to just default to CMIT_FMT_USERFORMAT in that case, since previously that was the only format it handled. The recent addition of the lua formatter broke that assumption. Rather than require each caller to be more strict, let's just default to USERFORMAT when the format is set to something nonsensical. Signed-off-by: Jeff King p...@peff.net --- pretty.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/pretty.c b/pretty.c index fdd4258..7289590 100644 --- a/pretty.c +++ b/pretty.c @@ -1180,10 +1180,10 @@ void format_commit_message(const struct commit *commit, free(enc); } - if (pretty_ctx-fmt == CMIT_FMT_USERFORMAT) - strbuf_expand(sb, format, format_commit_item, context); - else if (pretty_ctx-fmt == CMIT_FMT_LUA) + if (pretty_ctx-fmt == CMIT_FMT_LUA) lua_commit_format(sb, context); + else + strbuf_expand(sb, format, format_commit_item, context); rewrap_message_tail(sb, context, 0, 0, 0); -- 1.8.0.rc0.22.g285fd2d -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak
The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK variable, either from the environment or command line of an 'make test' invocation. In order to allow the malloc checks to be disabled from the 'config.mak' file, we add TEST_NO_MALLOC_CHECK to the environment using an export directive. Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk --- Hi Junio, Now that the malloc checks have been enabled, running the tests has become somewhat noisy with malloc: using debugging hooks messages spewing continuously to the terminal. [I usually run the tests like so: ramsay$ time $(make test test-out 21) malloc: using debugging hooks malloc: using debugging hooks ... malloc: using debugging hooks real16m11.408s user5m17.412s sys 4m54.786s ramsay$ ] strace tells me that the controlling terminal, /dev/tty, is being opened directly in order to write these messages. I find this annoying, so I tried to disable the malloc checks from config.mak ... Note that I decided not to write the TEST_NO_MALLOC_CHECK setting to the GIT-BUILD-OPTIONS file, since I prefer to enable/disable the malloc checks myself when running the test script directly. ATB, Ramsay Jones Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/Makefile b/Makefile index 8413606..f69979e 100644 --- a/Makefile +++ b/Makefile @@ -2636,6 +2636,7 @@ bin-wrappers/%: wrap-for-bin.sh # with that. export NO_SVN_TESTS +export TEST_NO_MALLOC_CHECK ### Testing rules -- 1.7.12 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 1.8.0.rc0.18.gf84667d trouble with git commit -p file
Jeff King p...@peff.net writes: Another option is to leave it with -i semantics in the meantime, which are at least easy to explain: it is simply a shorthand for running git add -p git commit. That may be inconsistent with other aspects of commit, but people have (apparently) been happy with it, and there has not been a rash of complaints. Yeah, that would be the safest and possibly the sanest way forward. Did the documentation update patch by Conrad on the other subthread look sane to you? I haven't read it very carefully yet. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gitignore.txt: suggestions how to get literal # or ! at the beginning
Jeff King p...@peff.net writes: I'd be slightly worried that we are hurting other people who do care and are on older versions of asciidoc. It would be nice if we actually knew the cause of the different behaviors we saw and if there was a way to work around it (it might not even be old asciidoc, but rather old docbook). Part of me wants to just take the change and see if anybody complains. But that is probably the wrong thing to do, and just my general frustration with our doc toolchain talking. Yeah, I do not think we would want to introduce such a regression especially when the proposed update is not the only (or best) way to give us the intended benefit. I think the spell the character name out approach you showed in the other message was far more readable anyway. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] git-svn, perl/Git.pm: extend and use Git-prompt method for querying users
Sven Strickroth sven.strickr...@tu-clausthal.de writes: Am 04.01.2012 01:12 schrieb Junio C Hamano: Now prompt is no longer a method but is merely a helper function, so I've queued this (and 1/2 rewrite we discussed in a separate thread) to 'pu' after rewording the commit log message. Thanks. Is there a reason why these changes did not get merged? The issues are still there. It is either that it was simply forgotten, or after I wrote the part you quoted early in January there were discussions later that showed the patch was not desirable for some reason. I do not recall which. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 1.8.0.rc0.18.gf84667d trouble with git commit -p file
On Sat, Oct 06, 2012 at 11:22:50AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: Another option is to leave it with -i semantics in the meantime, which are at least easy to explain: it is simply a shorthand for running git add -p git commit. That may be inconsistent with other aspects of commit, but people have (apparently) been happy with it, and there has not been a rash of complaints. Yeah, that would be the safest and possibly the sanest way forward. Did the documentation update patch by Conrad on the other subthread look sane to you? I haven't read it very carefully yet. I didn't notice any documentation patch, and I can't find one looking through the archive. Do you have a link? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 1/5] Fix some asciidoc layout problems
Thomas Ackermann th.acke...@arcor.de writes: Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/git-bisect-lk2009.txt | 12 ++-- Documentation/git-fetch-pack.txt| 5 - 2 files changed, 10 insertions(+), 7 deletions(-) You didn't say what layout problem you are fixing, or what the approach you took to fix it. From the patch, I can guess that the latter is to lengthen the lines that surround the displayed examples, but as far as I know and can tell, the existing ones are long enough so I cannot tell why you needed such a change to the source in the first place. A better explanation, please? The synopsis section of git-fetch-pack manual is a long single line which is unsightly. A fix to that issue is indeed needed. Please make a separate patch only for that issue. Is git-fetch-pack the only one whose synopsis section is overlong, by the way? Thanks. diff --git a/Documentation/git-bisect-lk2009.txt b/Documentation/git-bisect-lk2009.txt index 8a2ba37..99bdb46 100644 --- a/Documentation/git-bisect-lk2009.txt +++ b/Documentation/git-bisect-lk2009.txt @@ -248,7 +248,7 @@ Bisecting: 5480 revisions left to test after this (roughly 13 steps) And after a few more steps like that, git bisect will eventually find a first bad commit: -- + $ git bisect bad 2ddcca36c8bcfa251724fe342c8327451988be0d is the first bad commit commit 2ddcca36c8bcfa251724fe342c8327451988be0d @@ -257,8 +257,8 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile -- +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile + At this point we can see what the commit does, check it out (if it's not already checked out) or tinker with it, for example: @@ -305,7 +305,7 @@ to launch a script or command at each bisection step to know if the current commit is good or bad. To do that, we use the git bisect run command. For example: -- + $ git bisect start v2.6.27 v2.6.25 Bisecting: 10928 revisions left to test after this (roughly 14 steps) [2ec65f8b89ea003c27ff7723525a2ee335a2b393] x86: clean up using max_low_pfn on 32-bit @@ -331,9 +331,9 @@ Date: Sat May 3 11:59:44 2008 -0700 Linux 2.6.26-rc1 -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile bisect run success -- + In this example, we passed grep '^SUBLEVEL = 25' Makefile as parameter to git bisect run. This means that at each step, the grep diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt index 474fa30..12cd8a2 100644 --- a/Documentation/git-fetch-pack.txt +++ b/Documentation/git-fetch-pack.txt @@ -9,7 +9,10 @@ git-fetch-pack - Receive missing objects from another repository SYNOPSIS [verse] -'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=git-upload-pack] [--depth=n] [--no-progress] [-v] [host:]directory [refs...] +'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] + [--upload-pack=git-upload-pack] + [--depth=n] [--no-progress] + [-v] [host:]directory [refs...] DESCRIPTION --- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 2/5] Create html documents for all files in Documentation/technical
From: Thomas Ackermann th.acke...@arcor.de - add missing files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/Makefile| 12 ++- Documentation/technical/index-format.txt | 2 +- Documentation/technical/pack-format.txt | 8 +++ Documentation/technical/pack-protocol.txt | 7 +++--- Documentation/technical/shallow.txt | 8 ++- Documentation/technical/trivial-merge.txt | 36 +++ 6 files changed, 45 insertions(+), 28 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 267dfe1..86594f6 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -25,6 +25,16 @@ SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) +API_DOCS += technical/index-format Would it not be better to create a separate TECH_DOCS list, rather than confuse the API_DOCS list? +API_DOCS += technical/pack-format +API_DOCS += technical/pack-heuristics +API_DOCS += technical/pack-protocol +API_DOCS += technical/protocol-capabilities +API_DOCS += technical/protocol-common +API_DOCS += technical/racy-git +API_DOCS += technical/send-pack-pipeline +API_DOCS += technical/shallow +API_DOCS += technical/trivial-merge SP_ARTICLES += $(API_DOCS) SP_ARTICLES += technical/api-index @@ -231,7 +241,7 @@ clean: $(RM) *.texi *.texi+ *.texi++ git.info gitman.info $(RM) *.pdf $(RM) howto-index.txt howto/*.html doc.dep - $(RM) technical/api-*.html technical/api-index.txt + $(RM) technical/*.html technical/api-index.txt $(RM) $(cmds_txt) *.made $(RM) manpage-base-url.xsl diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt index 9d25b30..57d6f91 100644 --- a/Documentation/technical/index-format.txt +++ b/Documentation/technical/index-format.txt @@ -1,7 +1,7 @@ GIT index format -= The git index file has the following format +== The git index file has the following format snip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 3/5] Create html documents for all files in Documentation/RelNotes
From: Thomas Ackermann th.acke...@arcor.de - create html for all release note files - fix some asciidoc layout problems Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/Makefile | 2 ++ Documentation/RelNotes/1.5.2.1.txt | 6 -- Documentation/RelNotes/1.6.0.2.txt | 6 -- Documentation/RelNotes/1.6.1.3.txt | 4 Documentation/RelNotes/1.6.1.4.txt | 3 --- Documentation/RelNotes/1.6.1.txt | 6 -- 6 files changed, 2 insertions(+), 25 deletions(-) diff --git a/Documentation/Makefile b/Documentation/Makefile index 86594f6..80eb06d 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -24,6 +24,7 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +RELNOTES = $(patsubst %.txt,%,$(wildcard RelNotes/*.txt)) API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) API_DOCS += technical/index-format API_DOCS += technical/pack-format @@ -35,6 +36,7 @@ API_DOCS += technical/racy-git API_DOCS += technical/send-pack-pipeline API_DOCS += technical/shallow API_DOCS += technical/trivial-merge +API_DOCS += $(RELNOTES) Again, is this the right docs list? SP_ARTICLES += $(API_DOCS) SP_ARTICLES += technical/api-index snip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 1.8.0.rc0.18.gf84667d trouble with git commit -p file
On Sat, Oct 06, 2012 at 11:32:51AM -0700, Conrad Irwin wrote: I think I messed up sending somehow: Thanks for resending. What state should the add -p interaction start from for path F? Should you be picking from a patch between the state you previously git added to the index and the working tree, or should the entire difference between HEAD and the working tree eligible to be picked or deferred during the add -p session? Starting from a temporary index that matches HEAD essentially means that you lose the earlier git add F [*1*]. Two questions are easier answered: What should git commit --only --patch F do? = It should start you from the state of HEAD. Are you sure? Does --only mean only the changes I am about to mark or only the paths I am about to tell you about? Without partial hunk selection (i.e., commit -p), they were the same; a path you mention is a path which will be either be staged in its entirety or not. Specifying (or omitting) the path was sufficient to say what you wanted. But with -p, I can see three useful possibilities: 1. Do not include F in the commit, even if changes are staged in the index (i.e., take HEAD exactly). 2. Include F in the commit, and stage partial changes on top of what is already staged. 3. Include F in the commit, and stage partial changes on top of HEAD. In cases 2 and 3, we are still taking only the path F. But we are not taking only what is about to be staged in 2. And I can see both being useful (2 because it is more convenient not to re-approve staged changes, and 3 because there is no way to unstage changes via -p). What should git commit --include --patch F do? = It should start you from the state of the index. This one is much easier. The distinction between cases 2 and 3 above does not exist here, because we always start from the current index state. So there are two questions: 1. How does --only interact with partial staging (whether paths are specified or not)? 2. What should the default for -p be, between --only and --include? I think the answer to the second is --only; but a prerequisite to that is making --only work at all (it currently just barfs). And a prerequisite to that is figuring out what the right semantics are. The question that's harder to ponder, is what should the default be. Interestingly, I came to the exact opposite conclusion of which question is harder. :) The big UI problem with --only is not figuring out what should go in the commit, but rather ensuring that the index is in the expected state after the commit (it's the problems solved by 2888605c649ccd423232161186d72c0e6c458a48 but for hunks instead of files). If file F has hunks (H, J, K) then I stage hunk J with git add --interactive; then I commit hunks H K with git commit --interactive, the resulting index should contain H, J, K. Unfortunately, git add --interactive allows me to edit hunks, and so if I instead commit H J2 (where J2 is an edited version of J) then the index would contain (H, J) and the commit (H, J2); the working tree would contain H, J, K still. Yeah, that's a gross-ness I hadn't even considered. All in all, I think supporting --only --interactive is well beyond what I'm capable of doing, and probably pushing the limits of what's sane. (it would be nice for warm fuzzy completeness reasons though). Yes. The more we talk about it, the more turned off I am by the idea. Above I posed my questions as what _should_ we do when And I still think we _should_ default to --only with interactive, if we can find sane semantics. But until we can find them, it obviously does not make sense to enable it, and the whole discussion is stalled. And we must come up with an interim solution that is the least bad. Which is obviously one of: 1. Keep defaulting to --include, as that is what we have been doing. 2. Forbid the cases where it would matter (i.e., when the index and HEAD differ). The former is more convenient, but the latter is safer against future breakage. I'm OK either way, but option (1) clearly needs a documentation update. On Fri, Oct 5, 2012 at 3:57 PM, Jeff King p...@peff.net wrote: We should probably also support explicit -i -p and -o -p options, as well (the former would give people who really want the existing behavior a way to get it). And the same for --interactive. I can't say I'm excited about making all that work, though. Like you, I think it is more sane to use existing tools to inspect and tweak the index to your liking, and then commit. You made the same thinko as me :). --include isn't defined to mean include the index as well, but rather include these files when committing the index. Flipping that around makes a lot of sense and then --include can be used semantically with --patch, --interactive or even --all. (patch attached). But of course we're not specifying paths. So to me it is include the changes I am about to
Re: [Patch 1/5] Fix some asciidoc layout problems
On Sat, Oct 06, 2012 at 11:39:13AM -0700, Junio C Hamano wrote: Thomas Ackermann th.acke...@arcor.de writes: Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/git-bisect-lk2009.txt | 12 ++-- Documentation/git-fetch-pack.txt| 5 - 2 files changed, 10 insertions(+), 7 deletions(-) You didn't say what layout problem you are fixing, or what the approach you took to fix it. From the patch, I can guess that the latter is to lengthen the lines that surround the displayed examples, but as far as I know and can tell, the existing ones are long enough so I cannot tell why you needed such a change to the source in the first place. A better explanation, please? I had the same question. Also, some of the lines convert tabs in literal output into spaces, which is actively wrong (or maybe they were converted already to spaces in the current code, but they should at least align with 8-space tabstops): -:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile +:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 5/5] Create pdf from all html files
On Sat, Oct 06, 2012 at 05:58:01PM +0200, Thomas Ackermann wrote: - use wkhtmltopdf to combine all html files into a single pdf file git-doc.pdf - provide make target fullpdf to create git-doc.pdf Signed-off-by: Thomas Ackermann th.ac...@arcor.de --- Documentation/.gitignore | 1 + Documentation/Makefile| 9 + Documentation/footerend.txt | 4 Documentation/footerstart.txt | 7 +++ Documentation/makedocpdf.sh | 25 + Makefile | 6 ++ 6 files changed, 52 insertions(+) create mode 100644 Documentation/footerend.txt create mode 100644 Documentation/footerstart.txt create mode 100644 Documentation/makedocpdf.sh The makedocpdf script has no execute bit, but... diff --git a/Documentation/Makefile b/Documentation/Makefile index abd27b5..c4c2a30 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -189,6 +189,9 @@ info: git.info gitman.info pdf: user-manual.pdf +fullpdf: pdf all + ./makedocpdf.sh Here we try to run it. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 3/5] Create html documents for all files in Documentation/RelNotes
On Sat, Oct 06, 2012 at 05:55:58PM +0200, Thomas Ackermann wrote: - create html for all release note files [...] diff --git a/Documentation/Makefile b/Documentation/Makefile index 86594f6..80eb06d 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -24,6 +24,7 @@ SP_ARTICLES = user-manual SP_ARTICLES += howto/revert-branch-rebase SP_ARTICLES += howto/using-merge-subtree SP_ARTICLES += howto/using-signed-tag-in-pull-request +RELNOTES = $(patsubst %.txt,%,$(wildcard RelNotes/*.txt)) API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt))) API_DOCS += technical/index-format API_DOCS += technical/pack-format @@ -35,6 +36,7 @@ API_DOCS += technical/racy-git API_DOCS += technical/send-pack-pipeline API_DOCS += technical/shallow API_DOCS += technical/trivial-merge +API_DOCS += $(RELNOTES) Yuck. This means that anyone generating the html documentation will have to format all of the release notes, too, even though they are much less likely to be useful[1]. If this is only useful for the fullpdf target, can we omit it from the regular html target (and maybe add a relnotes target or something for people who really want them formatted)? -Peff [1] I would not be surprised if they do not actually format all that well. Though they are written in an asciidoc-ish style, they have not traditionally been formatted, and I suspect there are many small errors (like improper quoting of metacharacters) in them. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MALLOC_CHECK: Allow checking to be disabled from config.mak
Ramsay Jones ram...@ramsay1.demon.co.uk writes: The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK variable, either from the environment or command line of an 'make test' invocation. In order to allow the malloc checks to be disabled from the 'config.mak' file, we add TEST_NO_MALLOC_CHECK to the environment using an export directive. We would want to encourage people to test with cheap but effective checks when available. I do not see malloc: using debugging hooks message anywhere when I run tests, but if you do, I'd rather see us check if we can tell glibc to stop doing so first without disabling the whole test. Your patch feels like the first step to a slipperly slope whose destination would make us say we get too many messages so let's do nothing in make test with this configuration. when taken to the extreme, and obviously we would not want to go there ;-). Elia, you brought the MALLOC_CHECK_ up. Did you hear about this issue elsewhere before, and if you did, do you know how other projects solves it? Besides, doesn't a simple instruction to export TEST_NO_MALLOC_CHECK to your environment before running make test suffice? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] test: work around SVN 1.7 mishandling of svn:special changes
Subversion represents symlinks as ordinary files with content
starting with link and the svn:special property set to *. Thus a
file can switch between being a symlink and a non-symlink simply by
toggling its svn:special property, and new checkouts will
automatically write a file of the appropriate type. Likewise, in
subversion 1.6 and older, running svn update would notice changes
in filetype and update the working copy appropriately.
Unfortunately, starting in subversion 1.7 ,changes to the svn:special
property trip an assertion instead:
$ svn up svn-tree
Updating 'svn-tree':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' \
line 1583: assertion failed (action == svn_wc_conflict_action_edit \
|| action == svn_wc_conflict_action_delete || action == \
svn_wc_conflict_action_replace)
This is a known bug in svn update (Subversion issue 4091) and for
the sake of old repositories it will need to be fixed some day.
Revisions prepared with ordinary svn commands (svn add and not svn
propset) don't trip this because they represent filetype changes
using a replace operation, which is approximately equivalent to
removal followed by adding a new file and works fine. Perhaps git
svn should mimic that, but for now let's teach the test suite to
recover from the bug by testing the content of HEAD with a new
checkout.
After this change, tests t9100.11-13 pass again.
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
Hi Eric,
Michael G. Schwern wrote:
At this point SVN 1.7 passes except for 3 tests in
t9100-git-svn-basic.sh that look like an SVN bug to do with
symlinks.
How about this patch?
I didn't add a new xfail test for svn up working because I'm not yet
sure what good git-svn behavior would be. Probably it would be better
to track down that svn bug and get a fix backported to the 1.7.x
branch.
Reference: http://subversion.tigris.org/issues/show_bug.cgi?id=4160
t/t9100-git-svn-basic.sh | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 749b75e8..34d3485f 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -19,6 +19,15 @@ case $GIT_SVN_LC_ALL in
;;
esac
+svn_up_avoiding_issue4091 () {
+ if ! svn_cmd_up $SVN_TREE
+ then
+ # work around Subversion issue 4091
+ rm -r $SVN_TREE
+ svn_cmd checkout $svnrepo $SVN_TREE
+ fi
+}
+
test_expect_success \
'initialize git svn' '
mkdir import
@@ -148,7 +157,7 @@ test_expect_success $name '
git commit -m $name
git svn set-tree --find-copies-harder --rmdir \
${remotes_git_svn}..mybranch5
- svn_cmd up $SVN_TREE
+ svn_up_avoiding_issue4091
test -h $SVN_TREE/exec.sh'
name='new symlink is added to a file that was also just made executable'
@@ -173,7 +182,7 @@ test_expect_success $name '
git commit -m $name
git svn set-tree --find-copies-harder --rmdir \
${remotes_git_svn}..mybranch5
- svn_cmd up $SVN_TREE
+ svn_up_avoiding_issue4091
test -f $SVN_TREE/exec-2.sh
test ! -h $SVN_TREE/exec-2.sh
test_cmp help $SVN_TREE/exec-2.sh'
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Patch 0/5] Create single PDF for all HTML files
On Sat, Oct 06, 2012 at 05:51:15PM +0200, Thomas Ackermann wrote: I wanted to have a single PDF file which contains the complete Git documentation (except user-manual) for easier reading on my tablet. The simplest way to do this was by using wkhtmltopdf which can combine a set of HTML files into a sinlge PDF file and also apply some reformatting. To this end HTML files for all the missing files in Documentation/technical and Documentation/howto and also for all the release notes in Documentation/RelNotes were created. It seems like a reasonable goal. I do not have a strong opinion on the approach or how the final output looks, but I wasn't able to actually get output at all after applying your patches. Running make fullpdf (after installing dblatex) got me: The switch --book, is not support using unpatched qt, and will be ignored.The switch --footer-html, is not support using unpatched qt, and will be ignored.The switch --disable-external-links, is not support using unpatched qt, and will be ignored. after which wkhtmltopdf began pegging my CPU. I let it run for 10 minutes before giving up. Another way of doing this would be to format the individual troff manpages into dvi or postscript, convert that into pdf, and then concatenate that. Something like: for i in *.[157]; do man -Tdvi -l $i $i.dvi dvipdfm $i done pdftk *.[157].pdf cat output full.pdf works for me, though obviously that does not handle some of the non-man items you included. No idea on how the output compares to yours, but it's something you may want to look at. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug report
On 10/6/12 8:31 AM, Jeff King wrote:
On Thu, Oct 04, 2012 at 11:10:40AM -0500, John Whitney wrote:
Thank you for your response. I do see the dilemma, but having
no possible unmodified state is extremely inconvenient and,
as shown, breaks basic git operations.
But you have asked for an impossible state. You have said this file
cannot have CR when you check it in, because we erase them. And yet the
version of the file in HEAD has CRs in it. So it must appear modified
with respect to HEAD. And the solution is to make a commit with the
normalized content.
I guess I'd really like to see git ignore all line endings of text files
in the repository. Text files would then never be marked as modified
for this reason and there would be no need to fix the line endings. I
think that should be the default, but just having the option would be nice.
You said in your test script:
# Committing test.txt or clearing .gitattributes does clear
# the modified status, but those options are undesirable
Why is the commit undesirable? You have decided that CRs will no longer
be tolerated in your repository (by setting .gitattributes). Now you
need to record that change in history with a commit that strips out the
CRs.
In some cases it's undesirable. In my example, all I want to do is merge
in the change that deletes the file, so I don't want to have to add that
extra commit when I'm just going to delete the file anyway. It's also
very inconvenient to have to deal with this issue when you're in the
middle of a complex rebase operation.
I guess my thought is that if git doesn't allow CRs to be checked
in, then it should strip the CRs when checking the file out, and
consider that form (or both forms) as unmodified. It just
doesn't make sense to me that files are considered modified
immediately after checkout.
It is not about having CRs in the working tree file. Those are now
considered uninteresting and stripped by git when comparing to the HEAD.
The problem is that what's in your _repository_ has CRs.
Yes, but does that really have to be an issue? Is there any technical or
practical reason you can think of that the repository shouldn't ignore
those CRs?
I wonder if this is a fundamental misunderstanding of how the CRLF
handling in git works. It is not magically make me not care about line
endings anymore. It is the canonical version in the repo is LF-only.
Strip anything coming into the repository to match that, and
(optionally) add CR to anything going out to the filesystem for my
convenience. But you need a flag day to update the in-repository
versions to the new scheme.
-Peff
You're right, we can't magically avoid all the line ending issues that
people will run into. In this case, though, I think git can sidestep a
fairly obnoxious problem. My example was simple, but when you've got
multiple branches that need to be rebased/merged, it can get pretty
hairy. The repository will never be truly clean unless you rewrite the
whole thing (using filter-branch, for instance).
Maybe my above suggestion is more of a feature request than a bug, but
there is the obvious bug that after changing .gitattributes, git still
doesn't notice that files are modified until you modify them again in
some way (touch works). I only noticed the CRs in our own repository
after I tried to rebase a branch and got strange errors. To make git
notice all the files, I had to find . -type f -exec touch {} \;.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] gitignore.txt: suggestions how to get literal # or ! at the beginning
We support backslash escape, but we hide the details behind the phrase a shell glob suitable for consumption by fnmatch(3). So it may not be obvious how one can get literal # or ! at the beginning of pattern. Add a few lines on how to work around the magic characters. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Back to spelling out, which works with 8.2.6. No examples for \# because '\' in '\#example#.txt' is eaten. Documentation/gitignore.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt index 96639e0..90106c4 100644 --- a/Documentation/gitignore.txt +++ b/Documentation/gitignore.txt @@ -74,11 +74,15 @@ PATTERN FORMAT for readability. - A line starting with # serves as a comment. + Put a backslash (`\`) in front of the first hash for patterns + that begin with a hash. - - An optional prefix '!' which negates the pattern; any + - An optional prefix `!` which negates the pattern; any matching file excluded by a previous pattern will become included again. If a negated pattern matches, this will override lower precedence patterns sources. + Put a backslash (`\`) in front of the first `!` for patterns + that begin with a literal `!`, for example, `\!important!.txt`. - If the pattern ends with a slash, it is removed for the purpose of the following description, but it would only find -- 1.7.12.1.406.g6ab07c4 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git am crash (builtin/apply.c:2108) + small repro
On Wed, Oct 3, 2012 at 10:44 PM, Alexey Spiridonov snarkmas...@gmail.com wrote: Thanks a lot for trying this. My hashes match. I just re-reproduced it on two flavors of Linux (64 and 32-bit), with two different Git versions (see below). What platform are you using? x86, 32 bit. Perhaps it has something to do with your configuration (config files, hooks, attributes). Assuming you use standard repository templates, you create new repo in your test so hooks and attributes are out. Is there anything suspicuous in git config -l? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
