* Re: Worktree vs. working copy
From: Carlos Martín Nieto @ 2011-09-20 20:25 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ramkumar Ramachandra, git, Nguyễn Thái Ngọc Duy,
Michael Haggerty
In-Reply-To: <7vhb476ned.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 5104 bytes --]
On Tue, 2011-09-20 at 12:10 -0700, Junio C Hamano wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
> > Hi Carlos,
> >
> > Carlos Martín Nieto writes:
> >> [...]
> >> $ git grep 'worktree' | wc -l
> >> 412
> >> $ git grep 'working copy' | grep -v ^git-cvsserver | wc -l
> >> 32
> >> [...]
> >
> > You might like to refer to a related discussion [1].
> >
> > [1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083
>
> Sorry, I do not see "working tree" discussion there. The discussion on
> that quoted thread was about remote-tracking branches, no?
>
> Historically, we used to say "working tree" and "worktree" more or less
> interchangeably, and over time we tried to update the documentation to use
> "working tree" consistently, even though the latter is still seen in
> places like "GIT_WORK_TREE" environment variable (which will _not_
> change).
>
> But as far as I recall, we have never referred to the working tree
> controlled by a git repository as "working copy".
The config man page has three mentions, diff-lib.c has one,
merge-recursive.c three and perl/Git.pm nine.
This patch covers the documentation and C code. I'll move the perl code
over if you want, but I'm not sure how well maintained or relevant that
part of the codebase is.
--- 8< ---
Subject: [PATCH] Remove 'working copy' from the documentation and C code
The git term is 'working tree', so replace the most public references
to 'working copy'.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
---
Documentation/config.txt | 6 +++---
Documentation/git-svn.txt | 2 +-
diff-lib.c | 2 +-
merge-recursive.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6b93777..c3f22f3 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -147,7 +147,7 @@ advice.*::
core.fileMode::
If false, the executable bit differences between the index and
- the working copy are ignored; useful on broken filesystems like FAT.
+ the working tree are ignored; useful on broken filesystems like FAT.
See linkgit:git-update-index[1].
+
The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
@@ -179,7 +179,7 @@ is created.
core.trustctime::
If false, the ctime differences between the index and the
- working copy are ignored; useful when the inode change time
+ working tree are ignored; useful when the inode change time
is regularly modified by something outside Git (file system
crawlers and some backup systems).
See linkgit:git-update-index[1]. True by default.
@@ -292,7 +292,7 @@ core.ignoreStat::
If true, commands which modify both the working tree and the index
will mark the updated paths with the "assume unchanged" bit in the
index. These marked files are then assumed to stay unchanged in the
- working copy, until you mark them otherwise manually - Git will not
+ working tree, until you mark them otherwise manually - Git will not
detect the file changes by lstat() calls. This is useful on systems
where those are very slow, such as Microsoft Windows.
See linkgit:git-update-index[1].
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 713e523..4ba6f61 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -297,7 +297,7 @@ Any other arguments are passed directly to 'git log'
Show what revision and author last modified each line of a file. The
output of this mode is format-compatible with the output of
`svn blame' by default. Like the SVN blame command,
- local uncommitted changes in the working copy are ignored;
+ local uncommitted changes in the working tree are ignored;
the version of the file in the HEAD revision is annotated. Unknown
arguments are passed directly to 'git blame'.
+
diff --git a/diff-lib.c b/diff-lib.c
index 9c29293..c7d33d7 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -289,7 +289,7 @@ static void show_new_file(struct rev_info *revs,
/*
* New file in the index: it might actually be different in
- * the working copy.
+ * the working tree.
*/
if (get_stat_data(new, &sha1, &mode, cached, match_missing,
&dirty_submodule, &revs->diffopt) < 0)
diff --git a/merge-recursive.c b/merge-recursive.c
index db9ba19..0c9f77e 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -337,7 +337,7 @@ static void make_room_for_directories_of_df_conflicts(struct merge_options *o,
struct string_list *entries)
{
/* If there are D/F conflicts, and the paths currently exist
- * in the working copy as a file, we want to remove them to
+ * in the working tree as a file, we want to remove them to
* make room for the corresponding directory. Such paths will
* later be processed in process_df_entry() at the end. If
* the corresponding directory ends up being removed by the
--
1.7.5.2.354.g349bf
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply related
* Re: [PATCH/RFCv4 1/4] Documentation: Preparation for gitweb manpages
From: Jonathan Nieder @ 2011-09-20 20:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Drew Northup
In-Reply-To: <201109202211.06899.jnareb@gmail.com>
Jakub Narebski wrote:
> I hope that this version is more clear:
Yep, it doesn't leave me confused any more. Thanks, this looks good
(and sorry for my carelessness in reading the patch before).
^ permalink raw reply
* Re: [PATCH] send-email: Honor multi-part email messages
From: Alexey Shumkin @ 2011-09-20 20:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1uvb6mn9.fsf@alter.siamese.dyndns.org>
> Alexey Shumkin <zapped@mail.ru> writes:
>
> > diff --git a/git-send-email.perl b/git-send-email.perl
> > index 98ab33a..1abf4a4 100755
> > --- a/git-send-email.perl
> > +++ b/git-send-email.perl
> > @@ -1403,12 +1403,17 @@ sub file_has_nonascii {
> >
> > sub body_or_subject_has_nonascii {
> > my $fn = shift;
> > + my $multipart = 0;
> > open(my $fh, '<', $fn)
> > or die "unable to open $fn: $!\n";
> > while (my $line = <$fh>) {
> > last if $line =~ /^$/;
> > + if ($line
> > =~ /^Content-Type:\s*multipart\/mixed.*$/) {
> > + $multipart = 1;
> > + }
> > return 1 if $line =~ /^Subject.*[^[:ascii:]]/;
> > }
> > + return 0 if $multipart;
>
> Looks as if you can lose the extra variable and return 0 immediately
> when you find a line with that Content-Type inside the loop.
Well, as I understand "current" algorithm:
1. It assumes that file is one-part email message
2. Function searches non-ASCII characters in Subject header
3. If none then it looks non-ASCII characters at message body
my changes are to skip looking at message body of a multi-part
message as it has parts with their own Content-Type headers
The said above in details:
1. To set flag when we meet Content-Type: multipart/mixed header
2. After we processed all headers and did not found non-ASCII characters
in a Subject we take a look at this flag and exit with 0
if it is a multi-part message
^ permalink raw reply
* Re: git patch-id fails on long lines
From: Jeff King @ 2011-09-20 20:18 UTC (permalink / raw)
To: Andrew Pimlott; +Cc: git
In-Reply-To: <1316541771-sup-9996@pimlott.net>
On Tue, Sep 20, 2011 at 11:07:42AM -0700, Andrew Pimlott wrote:
> In patch-id.c, get_one_patchid uses a fixed 1000-char buffer to read a line.[1]
> This causes incorrect results on longer lines. Pasted below is a git commit
> (from git show) that demonstrates the problem. The result of running git
> patch-id on this commit is:
>
> 9220f380851be9cab1a760430e3be096dcbee8c6 9b96b6fde8f7df791a1490ae18e1fa75fbab3262
> 74b8ede07628a574fd586624e0c77a4b6c9967e0 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Hmm, yeah. My initial impression "eh, so what, it will just add the
line contents to the sha1 patch-id in two separate hunks". But we
actually treat lines magically based on their beginnings, and it
seems we accidentally think the "aaa" is the start of the next commit
header.
I think this can be trivially converted to use strbuf_getwholeline,
something like this (completely untested):
diff --git a/builtin/patch-id.c b/builtin/patch-id.c
index f821eb3..99ba2ca 100644
--- a/builtin/patch-id.c
+++ b/builtin/patch-id.c
@@ -58,11 +58,12 @@ static int scan_hunk_header(const char *p, int *p_before, int *p_after)
static int get_one_patchid(unsigned char *next_sha1, git_SHA_CTX *ctx)
{
- static char line[1000];
+ static struct strbuf line_buf = STRBUF_INIT;
int patchlen = 0, found_next = 0;
int before = -1, after = -1;
- while (fgets(line, sizeof(line), stdin) != NULL) {
+ while (strbuf_getwholeline(&line_buf, stdin, '\n') != EOF) {
+ char *line = line_buf.buf;
char *p = line;
int len;
That just reuses the same heap-allocated buffer over and over, and then
eventually leaks it at the end (but then the program exits anyway). You
could get fancier and actually pass in the strbuf from generate_id_list,
and then release it when we're done.
-Peff
^ permalink raw reply related
* Re: git patch-id fails on long lines
From: Junio C Hamano @ 2011-09-20 20:11 UTC (permalink / raw)
To: Andrew Pimlott; +Cc: git
In-Reply-To: <1316541771-sup-9996@pimlott.net>
Andrew Pimlott <andrew@pimlott.net> writes:
> In patch-id.c, get_one_patchid uses a fixed 1000-char buffer to read a line.
Thanks; builtin/patch-id.c is parhaps one of the more ancient part of the
system and it hasn't been updated to use more modern facility like strbuf
API.
Fix should be pretty straightforward. Any takers?
^ permalink raw reply
* Re: [PATCH/RFCv4 1/4] Documentation: Preparation for gitweb manpages
From: Jakub Narebski @ 2011-09-20 20:11 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Drew Northup
In-Reply-To: <20110919233703.GF6343@elie>
Thanks again for all language fixes. English is my secondary language...
Jonathan Nieder wrote:
> Jakub Narebski wrote:
> > The goal is to move documentation out of gitweb/README to gitweb.txt and
> > gitweb.conf.txt manpages, reducing its size 10x from around 500 to
> > around 50 lines (two pages), and move information not related drectly to
> > building and installing gitweb out of gitweb/INSTALL there.
>
> I guess you mean this patch prepares for or is part of a larger
> project or series with that goal? [...]
[...]
> > This way to build gitweb documentation one can use
> >
> > make -C gitweb doc
> >
> > or
> >
> > cd gitweb; make doc
>
> Language nit: a comma after "This way" would disambiguate.
>
> Does "make -CDocumentation man html" build the gitweb documentation,
> too (and "make install-doc" install it)?
Jonathan Nieder wrote:
> Maybe its commit message could
> be clarified to mention that the new targets build a subset of the pages
> built by the ordinary "make doc" et al targets.
I hope that this version is more clear:
-- >8 --
From: Jakub Narebski <jnareb@gmail.com>
Subject: [PATCH/RFCv5 1/4] Documentation: Preparation for gitweb manpages
Gitweb documentation currently consists of gitweb/README, gitweb/INSTALL
and comments in gitweb source code. This is harder to find, use and
browse than manpages ("man gitweb" or "git help gitweb") and HTML
documentation ("git help --web gitweb").
The goal of the next two commits is to move documentation out of
gitweb/README to gitweb.txt and gitweb.conf.txt manpages, reducing its
size 10x from around 500 to around 50 lines (two pages), and to move
information not related directly to building and installing gitweb out
of gitweb/INSTALL.
The idea is to have the gitweb manpage sources reside in AsciiDoc
format in the Documentation/ directory, like for gitk and git-gui.
This means that building git documentation (with "make doc") would
also build gitweb manpages.
An alternate solution would be to have gitweb documentation in the
gitweb/ directory, perhaps in POD format (see perlpod(1)).
This patch adds infrastructure for easy generation of only
gitweb-related manpages. It adds a currently empty 'gitweb-doc'
target to Documentation/Makefile, and a 'doc' proxy target to
gitweb/Makefile.
This way to build only gitweb documentation in both 'man' and 'html'
formats one can use
make -C gitweb doc
or
cd gitweb; make doc
This somewhat follows the idea of 'full-svn-test' and 'gitweb-test' in
t/Makefile. Note also that with alternate solution, where source of
gitweb manpages would reside in the gitweb/ directory, "make doc"
would invoke "make -C gitweb doc" to generate formatted docs.
The gitweb.conf(5) and gitweb(1) manpages will be added in subsequent
commits.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/Makefile | 3 +++
gitweb/Makefile | 7 ++++++-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 6346a75..44be67b 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -170,6 +170,9 @@ info: git.info gitman.info
pdf: user-manual.pdf
+GITWEB_DOC = $(filter gitweb.%,$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7))
+gitweb-doc: $(GITWEB_DOC)
+
install: install-man
install-man: man
diff --git a/gitweb/Makefile b/gitweb/Makefile
index 1c85b5f..3014d80 100644
--- a/gitweb/Makefile
+++ b/gitweb/Makefile
@@ -174,6 +174,11 @@ test-installed:
GITWEB_TEST_INSTALLED='$(DESTDIR_SQ)$(gitwebdir_SQ)' \
$(MAKE) -C ../t gitweb-test
+### Documentation
+
+doc:
+ $(MAKE) -C ../Documentation gitweb-doc
+
### Installation rules
install: all
@@ -187,5 +192,5 @@ install: all
clean:
$(RM) gitweb.cgi static/gitweb.min.js static/gitweb.min.css GITWEB-BUILD-OPTIONS
-.PHONY: all clean install test test-installed .FORCE-GIT-VERSION-FILE FORCE
+.PHONY: all clean install test test-installed doc .FORCE-GIT-VERSION-FILE FORCE
--
1.7.6
^ permalink raw reply related
* Re: [PATCH] format-patch: cover letter does not respect i18n.commitencoding
From: Alexey Shumkin @ 2011-09-20 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v62kn6mqi.fsf@alter.siamese.dyndns.org>
> Alexey Shumkin <zapped@mail.ru> writes:
>
> > diff --git a/builtin/log.c b/builtin/log.c
> > index 5c2af59..6a4050c 100644
> > --- a/builtin/log.c
> > +++ b/builtin/log.c
> > @@ -769,7 +769,7 @@ static void make_cover_letter(struct rev_info
> > *rev, int use_stdout, struct shortlog log;
> > struct strbuf sb = STRBUF_INIT;
> > int i;
> > - const char *encoding = "UTF-8";
> > + const char *encoding = get_commit_output_encoding();
>
> Hmm, I have a feeling that this should use log output encoding. Am I
> mistaken?
Oooh! I made a mistake. I'm sorry
get_log_output_encoding must be used instead, yes
> The i18n.commitencoding variable is about the internal representation
> in the object [*1*] that is to be converted from the encoding of the
> original e-mail message which could be different.
> i18n.logoutputencoding is to externalize it [*2*].
>
> [Footnotes]
>
> *1* f1f909e (mailinfo: Use i18n.commitencoding, 2005-11-27)
> *2* a731ec5 (t3901: test "format-patch | am" pipe with i18n,
> 2007-01-13)
>
^ permalink raw reply
* Re: maybe I missed the announcement, but...
From: Junio C Hamano @ 2011-09-20 19:51 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Carlos Martín Nieto, git
In-Reply-To: <86pqivqnzw.fsf@red.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Carlos" == Carlos Martín Nieto <cmn@elego.de> writes:
>
> Carlos> From Junio's latest "What's cooking"[0]
>
> Ahh, the famous "buried lead". :)
Did I do anything wrong to "bury" it?
^ permalink raw reply
* Re: [PATCH] Documentation/git-update-index: refer to 'ls-files'
From: Junio C Hamano @ 2011-09-20 19:50 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git
In-Reply-To: <1316521427-20855-1-git-send-email-stefan.naewe@gmail.com>
Stefan Naewe <stefan.naewe@gmail.com> writes:
> 'ls-files' refers to 'update-index' to show how the 'assume unchanged'
> can be seen. This makes the connection 'bi-directional'.
Thanks, but for that bi-directional connection, I think the place you
inserted the new text is suboptimal. There is a single paragraph with two
sentences to teach how to set and how to unset. Adding another to teach
how to inspect would flow the resulting logic more naturally.
^ permalink raw reply
* Re: [PATCH] contrib/hooks: adapt default Debian install location for contrib hooks
From: Junio C Hamano @ 2011-09-20 19:44 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20110920111914.17913.qmail@d29ca435be5a3d.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
> index fa6d41a..ba077c1 100755
> --- a/contrib/hooks/post-receive-email
> +++ b/contrib/hooks/post-receive-email
> @@ -11,11 +11,11 @@
> # will have put this somewhere standard. You should make this script
> # executable then link to it in the repository you would like to use it in.
> # For example, on debian the hook is stored in
> -# /usr/share/doc/git-core/contrib/hooks/post-receive-email:
> +# /usr/share/git-core/contrib/hooks/post-receive-email:
> #
> # chmod a+x post-receive-email
> # cd /path/to/your/repository.git
> -# ln -sf /usr/share/doc/git-core/contrib/hooks/post-receive-email hooks/post-receive
> +# ln -sf /usr/share/git-core/contrib/hooks/post-receive-email hooks/post-receive
This one I do not have any problem with; the leading text makes it very
clear that this is an example that is specific to Debian and that is
good enough to signal readers that they may have to look elsewhere if they
are on a different distribution.
> diff --git a/templates/hooks--post-receive.sample b/templates/hooks--post-receive.sample
> index 7a83e17..e48346e 100755
> --- a/templates/hooks--post-receive.sample
> +++ b/templates/hooks--post-receive.sample
> @@ -12,4 +12,4 @@
> # see contrib/hooks/ for a sample, or uncomment the next line and
> # rename the file to "post-receive".
>
> -#. /usr/share/doc/git-core/contrib/hooks/post-receive-email
> +#. /usr/share/git-core/contrib/hooks/post-receive-email
I am however not sure about this. For one thing, it is not clear that this
(both old and new) text are meant to be Debian specific, and they should
not complain and instead should look for it elsewhere, if the users do not
find the sample in the path that is shown in the file. For another, it is
not "see ... for a sample, OR UNCOMMENT" at all, for readers who are _NOT_
interested in sending e-mails from the hook at all, but the way it is
stated makes it sound as if people who do not want to bother reading the
samples can blindly enable the hook and it is guaranteed that the
particular sample hook satisfies their needs, which is not the case.
Perhaps removing this sample file might be a better option. The first ten
lines or so repeat what the documentation says, which can go stale, and if
we remove them, the only thing that remains is the "see contrib/hooks for
a sample".
Thanks.
^ permalink raw reply
* Re: [PATCH] contrib/hooks: adapt default Debian install location for contrib hooks
From: Drew Northup @ 2011-09-20 19:38 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Junio C Hamano
In-Reply-To: <20110920111914.17913.qmail@d29ca435be5a3d.315fe32.mid.smarden.org>
On Tue, 2011-09-20 at 11:19 +0000, Gerrit Pape wrote:
> Placing the contrib hooks into /usr/share/doc/ wasn't a good idea in the
> first place. According to the Debian policy they should be located in
> /usr/share/git-core/, so let's put them there.
>
> Thanks to Bill Allombert for reporting this through
> http://bugs.debian.org/640949
>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
> contrib/hooks/post-receive-email | 4 ++--
> templates/hooks--post-receive.sample | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
What is the rationale for applying this outside of the land of Debian? I
understand the EPEL/Fedora crew are putting those example hooks
into /usr/share/git-gore, but I want to know why that should become the
standard in git.git.
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [RFC/PATCHv2] git-web--browse: avoid the use of eval
From: Junio C Hamano @ 2011-09-20 19:35 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Packham, git, chriscool, jepler
In-Reply-To: <20110920184939.GA17322@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> The example in t/README has has a copyright notice which is why I put
>> one in but I don't consider the test (or the fix itself) to actually be
>> copyrightable. If I wasn't creating a new file I wouldn't have bothered
>> putting anything in (other than the testcase).
>
> Yeah, that's why I said I don't know if we have a policy. We clearly
> have a lot of copyright statements, but they are all horribly out of
> date. I was hoping Junio might weigh in.
To be honest, I do not care very much either way. From the licensing point
of view we know everything is covered by the top-level COPYING unless
otherwise noted explicitly in an individual file (which is not the case
for this patch anyway), and even without the copyright notice we can trace
where the files come from with "git log", so these three lines in a small
test file are essentially noise, not very useful but are not irritating
enough to warrant an effort from me to amend it out.
I do have a mild objection to a patch that adds a new copyright notice
line to an existing file when it adds only a few new lines, though. When
the code is refactored and these new lines are made unneeded, it is likely
that nobody would bother removing that copyright notice line that names
the author of the patch that added these lines.
^ permalink raw reply
* Re: [PATCH] send-email: Honor multi-part email messages
From: Junio C Hamano @ 2011-09-20 19:26 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <1316507347-6693-1-git-send-email-zapped@mail.ru>
Alexey Shumkin <zapped@mail.ru> writes:
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 98ab33a..1abf4a4 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1403,12 +1403,17 @@ sub file_has_nonascii {
>
> sub body_or_subject_has_nonascii {
> my $fn = shift;
> + my $multipart = 0;
> open(my $fh, '<', $fn)
> or die "unable to open $fn: $!\n";
> while (my $line = <$fh>) {
> last if $line =~ /^$/;
> + if ($line =~ /^Content-Type:\s*multipart\/mixed.*$/) {
> + $multipart = 1;
> + }
> return 1 if $line =~ /^Subject.*[^[:ascii:]]/;
> }
> + return 0 if $multipart;
Looks as if you can lose the extra variable and return 0 immediately when
you find a line with that Content-Type inside the loop.
What am I missing?
^ permalink raw reply
* Re: [PATCH] format-patch: cover letter does not respect i18n.commitencoding
From: Junio C Hamano @ 2011-09-20 19:24 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <1316507177-6403-1-git-send-email-zapped@mail.ru>
Alexey Shumkin <zapped@mail.ru> writes:
> diff --git a/builtin/log.c b/builtin/log.c
> index 5c2af59..6a4050c 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -769,7 +769,7 @@ static void make_cover_letter(struct rev_info *rev, int use_stdout,
> struct shortlog log;
> struct strbuf sb = STRBUF_INIT;
> int i;
> - const char *encoding = "UTF-8";
> + const char *encoding = get_commit_output_encoding();
Hmm, I have a feeling that this should use log output encoding. Am I
mistaken?
The i18n.commitencoding variable is about the internal representation in
the object [*1*] that is to be converted from the encoding of the original
e-mail message which could be different. i18n.logoutputencoding is to
externalize it [*2*].
[Footnotes]
*1* f1f909e (mailinfo: Use i18n.commitencoding, 2005-11-27)
*2* a731ec5 (t3901: test "format-patch | am" pipe with i18n, 2007-01-13)
^ permalink raw reply
* Re: [PATCH v3 1/2] pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting
From: Junio C Hamano @ 2011-09-20 19:12 UTC (permalink / raw)
To: Alexey Shumkin; +Cc: git
In-Reply-To: <1316506892-6072-1-git-send-email-zapped@mail.ru>
Alexey Shumkin <zapped@mail.ru> writes:
> diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
> ...
> @@ -48,28 +53,25 @@ head2=$(add_file sm1 foo3)
>
> test_expect_success 'modified submodule(forward)' "
As this is [PATCH 1/2], doesn't this patch make this test fail, calling
for test_expect_failure here (and then later in 2/2 to be flipped back to
test_expect_success)?
> git diff-index -p --submodule=log HEAD >actual &&
> - cat >expected <<-EOF &&
> -Submodule sm1 $head1..$head2:
> - > Add foo3
> -EOF
> + printf \"Submodule sm1 $head1..$head2:\n\
> + > Add foo3 ($added foo3)\n\
> +\" > expected &&
> test_cmp expected actual
> "
Hmmm... why printf? Is it worth to force reviewers wonder what would
happen if any of these $variables happened to have "%" in them? Are you
benefiting from any printf features that you cannot achieve with the
original cat?
This hunk and others throughout your patch that change cat with here doc
into printf seem to make the tests less legible, at least to me.
Perhaps like this instead, if the "flushed left" of the original looked
ugly to your eyes?
@@ -49,27 +54,25 @@ head2=$(add_file sm1 foo3)
test_expect_success 'modified submodule(forward)' "
git diff-index -p --submodule=log HEAD >actual &&
cat >expected <<-EOF &&
-Submodule sm1 $head1..$head2:
- > Add foo3
-EOF
+ Submodule sm1 $head1..$head2:
+ > Add foo3 ($added foo3)
+ EOF
test_cmp expected actual
"
^ permalink raw reply
* Re: Worktree vs. working copy
From: Junio C Hamano @ 2011-09-20 19:10 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Carlos Martín Nieto, git,
Nguyễn Thái Ngọc Duy, Michael Haggerty
In-Reply-To: <CALkWK0mHQZEPKk3Dy3RSp70thcsw3x6RSvUxTuPVzzRjgsM8-A@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Hi Carlos,
>
> Carlos Martín Nieto writes:
>> [...]
>> $ git grep 'worktree' | wc -l
>> 412
>> $ git grep 'working copy' | grep -v ^git-cvsserver | wc -l
>> 32
>> [...]
>
> You might like to refer to a related discussion [1].
>
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/159287/focus=160083
Sorry, I do not see "working tree" discussion there. The discussion on
that quoted thread was about remote-tracking branches, no?
Historically, we used to say "working tree" and "worktree" more or less
interchangeably, and over time we tried to update the documentation to use
"working tree" consistently, even though the latter is still seen in
places like "GIT_WORK_TREE" environment variable (which will _not_
change).
But as far as I recall, we have never referred to the working tree
controlled by a git repository as "working copy".
^ permalink raw reply
* Re: [RFC/PATCHv2] git-web--browse: avoid the use of eval
From: Jeff King @ 2011-09-20 18:49 UTC (permalink / raw)
To: Chris Packham; +Cc: Junio C Hamano, git, chriscool, jepler
In-Reply-To: <4E78572E.6030105@gmail.com>
On Tue, Sep 20, 2011 at 09:04:46PM +1200, Chris Packham wrote:
> > Although other projects do use "cc" in the commit message, I think we
> > don't usually bother adding this noise in the git project. The cc
> > headers in your email are enough.
>
> That's more for git send-email's benefit than anything else. I'm working
> on a laptop with a touchpad (and a cat) so the less switching between
> editor and MUA the better. Any better suggestions for tracking Cc's for
> git send-email?
It would depend on your workflow, I think. You can use --cc to add
headers to format-patch. You could get very fancy and store them in
git-notes or somewhere else, and then pull them in with send-email's
cc-cmd option. But I suspect you just want to stick them in the commit
message one time and then have it used each time.
If put them after the double-dash line in your commit message, like:
subject
body
---
cc: whoever
Then that will be included verbatim in the mail by format-patch,
send-email will respect the cc line, and those lines will be dropped by
"git am" when Junio applies the patch (they are still a slight noise to
readers of the mail, but at least they don't make it into the commit
history).
> The example in t/README has has a copyright notice which is why I put
> one in but I don't consider the test (or the fix itself) to actually be
> copyrightable. If I wasn't creating a new file I wouldn't have bothered
> putting anything in (other than the testcase).
Yeah, that's why I said I don't know if we have a policy. We clearly
have a lot of copyright statements, but they are all horribly out of
date. I was hoping Junio might weigh in.
-Peff
^ permalink raw reply
* git patch-id fails on long lines
From: Andrew Pimlott @ 2011-09-20 18:07 UTC (permalink / raw)
To: git
In patch-id.c, get_one_patchid uses a fixed 1000-char buffer to read a line.[1]
This causes incorrect results on longer lines. Pasted below is a git commit
(from git show) that demonstrates the problem. The result of running git
patch-id on this commit is:
9220f380851be9cab1a760430e3be096dcbee8c6 9b96b6fde8f7df791a1490ae18e1fa75fbab3262
74b8ede07628a574fd586624e0c77a4b6c9967e0 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
The commit:
commit 9b96b6fde8f7df791a1490ae18e1fa75fbab3262
Author: Andrew Pimlott <andrew@pimlott.net>
Date: Tue Sep 20 10:53:25 2011 -0700
2
diff --git a/a b/a
index e69de29..2e6adac 100644
--- a/a
+++ b/a
@@ -0,0 +1 @@
+aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
diff --git a/b b/b
index e69de29..1425fcc 100644
--- a/b
+++ b/b
@@ -0,0 +1 @@
+b
Andrew
[1] https://github.com/git/git/blob/master/builtin/patch-id.c
^ permalink raw reply related
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Joshua Jensen @ 2011-09-20 18:26 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git@vger.kernel.org
In-Reply-To: <4E78ACE2.60306@drmicha.warpmail.net>
----- Original Message -----
From: Michael J Gruber
Date: 9/20/2011 9:10 AM
> Can you provide a simple test case, such as this one:
>
> ---%<---
> #!/bin/sh
>
> rm -Rf utest || exit 1
> mkdir utest || exit 1
> cd utest || exit 1
> git init
> echo tracked>a
> git add a
> git commit -m a a
> git branch side
> echo tracked>b
> git add b
> git commit -m b
> cat b
> git checkout side
> cat b
> echo untracked>b
> cat b
> git checkout master
> cat b
> ---%<---
>
> Does this test reproduce your problem on msysgit?
As listed, your script produces the same results on msysGit.
It appears the issue is related to sparse checkouts:
---%<---
#!/bin/sh
rm -Rf utest || exit 1
mkdir utest || exit 1
cd utest || exit 1
git init
git config core.sparseCheckout true
echo *>.git/info/sparse-checkout
echo tracked>a
git add a
git commit -m a a
git branch side
echo tracked>b
git add b
git commit -m b
cat b
git checkout side
cat b
echo untracked>b
cat b
git checkout master
cat b
---%<---
-Josh
^ permalink raw reply
* Re: Possible timestamp problems with diff-files?
From: Jeff King @ 2011-09-20 17:54 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4E786B5D.40601@syntevo.com>
On Tue, Sep 20, 2011 at 12:30:53PM +0200, Marc Strapetz wrote:
> For our Git client, we are invoking
>
> git diff-files--quiet --ignore-submodules
>
> immediately after a commit of *all* changes. Hence, the expected exit
> code would be 0 (because there are no changes). A user has now reported
> that for commits with many changes, exit code is sometimes 1. For the
> last incident, the commit was started at 15:24:11,820 and finished at
> 15:24:12,329, diff-files was invoked at 15:24:12,455 and failed with
> exit code 1 at 15:24:21,394. A subsequent diff-files succeeded, so I'm
> wondering now, if that could be a timestamp problem (maybe related to
> the Index)?
diff-files is scriptable plumbing, which means it is up to the script
writer to decide exactly when the index should be refreshed with respect
to the working tree files (because doing so could be kind of expensive,
as it needs to stat every file in the working tree). Have you tried
running "git update-index --refresh" just before your diff-files?
-Peff
^ permalink raw reply
* Re: Git 1.7.6: Sparse checkouts do not work with directory exclusions
From: Joshua Jensen @ 2011-09-20 15:22 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git@vger.kernel.org
In-Reply-To: <CACsJy8CDtswtPJVt-T911_1y0WqShonvcCbXhFtWu2zjEqLa4A@mail.gmail.com>
----- Original Message -----
From: Nguyen Thai Ngoc Duy
Date: 9/20/2011 4:09 AM
> On Tue, Sep 20, 2011 at 8:03 AM, Joshua Jensen
> <jjensen@workspacewhiz.com> wrote:
>> Sometime after Git 1.7.3.2, sparse checkouts stopped working for me. My
>> sparse-checkout file looks something like:
>>
>> *
>> !DirA/
>> !DirB/
>> DirC/
> Confirmed. It got me wonder why the negated pattern tests did not
> catch this. Turns out this works:
>
> /*
> !DirA/
> !DirB/
> DirC
>
> This is my theory why yours does not work: negated patterns !DirA and
> !DirB excludes both directories, but git still descends in them
> because you may have other patterns that re-include parts of
> DirA/DirB, for example:
>
> DirA/DirD
> !DirA
>
> When it's in DirA/DirB, "*" tells git to match everything (equivalent
> "DirA/*" and "DirB/*"), so it matches all entries in DirA/DirB again,
> essentially reverting "!DirA" and "!DirB" effects.
>
> By using "/*" instead of "*", we tell git to just match entries at top
> level, not all levels.
>
> I think it makes sense, but it's a bit tricky.
I can confirm this fix works for me, but it is certainly tricky. IMO,
it should either be documented or some kind of fix should be added to a
future version of Git to allow * by itself to work again.
>> and describe why those lines were removed?
> Quotes from 9e08273: "The commit provided a workaround for matching
> directories in index. But it is no longer needed."
Yeah, I saw that, but it made little sense to me, especially since it
seems to break a behavior that worked before.
Thanks!
Josh
^ permalink raw reply
* Re: git checkout under 1.7.6 does not properly list untracked files and aborts
From: Michael J Gruber @ 2011-09-20 15:10 UTC (permalink / raw)
To: Joshua Jensen; +Cc: git@vger.kernel.org
In-Reply-To: <4E779BA4.8070109@workspacewhiz.com>
Joshua Jensen venit, vidit, dixit 19.09.2011 21:44:
> ----- Original Message -----
> From: Joshua Jensen
> Date: 9/9/2011 2:04 PM
>> This may be an msysGit 1.7.6 issue, as that is what I am using. It
>> also occurs in msysGit 1.7.5, but I am almost certain it did not
>> happen in msysGit 1.7.2.
>>
>> Given an untracked file in the working directory that has been added
>> to an alternate branch, when switching to that alternate branch, 'git
>> checkout' exits with an error code but does not print anything to the
>> console. It should print an untracked file error.
>>
>> I have been trying to track this down in code. The point where the
>> error messages are printed, display_error_msgs, is never hit.
> Okay, so I've tracked this down, but I am unsure what the correct fix is.
>
> In unpack-trees.c's unpack_trees() function, there are some lines that read:
>
> if (ce->ce_flags & CE_ADDED &&
> verify_absent(ce, ERROR_WOULD_LOSE_UNTRACKED_OVERWRITTEN, o))
> return -1;
>
> If the 'return -1' is changed to 'goto return_failed', then a proper
> error message appears:
>
> error: The following untracked working tree files would be
> overwritten by checkout:
> one/file/listed/here.txt
> Please move or remove them before you can switch branches.
> Aborting
>
> The thing is, there are multiple files that would be overwritten by
> checkout, and I believe an older version of Git showed me the entire
> list before aborting.
>
> What would be the proper fix here? What am I doing wrong?
Can you provide a simple test case, such as this one:
---%<---
#!/bin/sh
rm -Rf utest || exit 1
mkdir utest || exit 1
cd utest || exit 1
git init
echo tracked >a
git add a
git commit -m a a
git branch side
echo tracked >b
git add b
git commit -m b
cat b
git checkout side
cat b
echo untracked >b
cat b
git checkout master
cat b
---%<---
With 1.7.6 and current next this gives (Linux):
Initialized empty Git repository in /tmp/t/utest/.git/
[master (root-commit) b462c80] a
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 a
[master 22d8f2f] b
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 b
tracked
Switched to branch 'side'
cat: b: No such file or directory
untracked
error: The following untracked working tree files would be overwritten
by checkout:
b
Please move or remove them before you can switch branches.
Aborting
untracked
Does this test reproduce your problem on msysgit?
Michael
^ permalink raw reply
* Re: [ANNOUNCE] Git User's Survey 2011
From: Jakub Narebski @ 2011-09-20 15:04 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4E78A667.8050805@drmicha.warpmail.net>
Dnia wtorek 20. września 2011 16:42, Michael J Gruber napisał:
> Jakub Narebski venit, vidit, dixit 19.09.2011 21:10:
> > On Mon, 5 Sep 2011, Michael J Gruber wrote:
> > > I've made a few last minute minor edits on the wiki (language-wise) and
> > > linked to it from identi.ca, twitter and g+. Hope that's alright.
[...]
> > Unfortunately when I had free time and got to correcting the survey,
> > Git Wiki was down already, and it stays unfortunately down till now.
> > When it is up, I'll review your corrections and fix survey
> > appropriately... well, if it will get up before survey closing.
>
> Those were only about the intro paragraph on the wiki, not about the
> content of the survey. Don't worry ;)
You had me worry (especially that I got one minor language-wise fixup,
"commit" -> "a commit")... ;-)
> > > Let the results come in!
> >
> > 3500+ responses and counting...
> >
>
> Yeah!
And that even without GitHub announcing it (yes, I send request, and
resent it yesterday via email rather than GitHub IM system), or
announcement on Git Homepage (Scott is hard to reach...).
> Michael
>
> P.S.: I don't remember what year I filled in my first survey. Can we
> have an answer "3+" next time...
Well, there is "I don't remember, but I have participated in the past"
answer... and you can select it _in addition_ to marking years that
you are sure about.
--
Jakub Narębski
^ permalink raw reply
* Re: maybe I missed the announcement, but...
From: Jakub Narebski @ 2011-09-20 14:55 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <8639frs3bf.fsf@red.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> dhcp:~ +% host git.kernel.org
> Host git.kernel.org not found: 3(NXDOMAIN)
All kernel.org pages are down for maintenance, see
http://kernel.org
> Is there a replacement?
On Gitster's Blog (blog of Junio Hamano) there is "Fun with
url.$that.insteadOf" article showing more or less temporarily
workaround:
http://git-blame.blogspot.com/2011/09/fun-with-urlthatinsteadof.html
HTH
--
Jakub Narębski
^ permalink raw reply
* Re: [ANNOUNCE] Git User's Survey 2011
From: Michael J Gruber @ 2011-09-20 14:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <201109192110.30763.jnareb@gmail.com>
Jakub Narebski venit, vidit, dixit 19.09.2011 21:10:
> On Mon, 5 Sep 2011, Michael J Gruber wrote:
>> Jakub Narebski venit, vidit, dixit 05.09.2011 02:43:
>
>>> We would like to ask you a few questions about your use of the Git
>>> version control system. This survey is mainly to understand who is
>>> using Git, how and why.
>>>
>>> The results will be published to the Git wiki on the GitSurvey2011
>>> page (https://git.wiki.kernel.org/index.php/GitSurvey2011) and
>>> discussed on the git mailing list.
>>
>> Jakub, thanks for your work!
>>
>> I've made a few last minute minor edits on the wiki (language-wise) and
>> linked to it from identi.ca, twitter and g+. Hope that's alright.
>
> Thank you for announcing it via microblogging / social network sites.
> I really appreciate spreading the word about Git User's Survey 2011.
>
> Unfortunately when I had free time and got to correcting the survey,
> Git Wiki was down already, and it stays unfortunately down till now.
> When it is up, I'll review your corrections and fix survey
> appropriately... well, if it will get up before survey closing.
Those were only about the intro paragraph on the wiki, not about the
content of the survey. Don't worry ;)
>> Let the results come in!
>
> 3500+ responses and counting...
>
Yeah!
Michael
P.S.: I don't remember what year I filled in my first survey. Can we
have an answer "3+" next time...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox