* [Bug report] git fetch/push fails from sub-directory
From: Frederic Heitzmann @ 2011-09-20 21:50 UTC (permalink / raw)
To: git
Hi,
I found a bug in git fetch, with local repositories.
git fetch works fine from the root directory, but it fails when called
from deeper into the file tree of the repository.
git push fails the same way.
The bug is on 1.7.7.rc2 and on master.
mkdir repo1
cd repo1
git init .
mkdir d
touch d/f
git add d/f
git commit -m'initial commit'
cd ..
git clone repo1 repo2
cd repo2
git fetch ../repo1 # OK
cd d
git fetch ../../repo1 # failed
fatal: '../../repo1' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
--
Fred
^ permalink raw reply
* Re: [PATCH v3 1/2] pretty: Add failing tests: user format ignores i18n.logOutputEncoding setting
From: Alexey Shumkin @ 2011-09-20 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaa9z6n9p.fsf@alter.siamese.dyndns.org>
> 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)?
I did not know how is right.
AFAIK, XP way tells to write failing tests and then
patch/fix the code to pass them.
Here, As I understand now all tests must be successful
The difference is in expectation of failure or success.
Ok. I got it and I will reroll the patches.
>
> > 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 is a remained from v1 patch code. It is not required now.
I'll fix it. Thanks.
> 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?
No, the reason was not in "flushed left". And, BTW, this code generates
expected output that has predefined format...
>
> @@ -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
> "
>
--
С уважением, Алексей Шумкин
Программист компании 1С-Рарус
E-mail: ashu@rarus.ru
ICQ: 118001447
Jabber (GoogleTalk): ashu@rarus.ru
Skype: crezoff
^ permalink raw reply
* Re: git-rebase skips automatically no more needed commits
From: Martin von Zweigbergk @ 2011-09-20 20:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin von Zweigbergk, Francis Moreau, Michael J Gruber, git,
Ramkumar Ramachandra
In-Reply-To: <alpine.DEB.2.00.1109151956040.12564@debian>
On Thu, 15 Sep 2011, Martin von Zweigbergk wrote:
[CC'ing Ramkunar regarding the footnote]
> [...] With your
> patch, we would also get the patch body from the commit. The only
> thing remaining after that is the commit log message, correct?
It turns out the commit log message have been taken from the commit
for ages. Sorry about not checking the code first.
I have started implementing the changes to git-am.sh now. I have made
it not use mailinfo when in $rebasing mode, as you suggested. So now
git-am works even if only a list of
From $sha1 Mon Sep 17 00:00:00 2001
lines are fed to it. Since only the $sha1 is needed, we should
probably make --rebasing imply a patch-format is just a simple list of
revisions. Since the --rebasing flag is only for internal use, this
should be safe when it comes to backwards compatibility. [1]
Now the question is how to generate such lines, without the overhead
of a full format-patch call. We still want the --ignore-if-in-upstream
functionality, so we can not use plain rev-list. We also want it to
work with --root, so we can not use git-cherry. Finally, we can not
use 'git rev-list --cherry-pick --right-only' since it seems to be
inherently for symmetric ranges and therefore does not support
git-cherry's <limit> parameter.
If I'm not mistaken, we would have to teach some new option to some
command, but which one?
It doesn't feel right to teach format-patch a --commit-name-only,
simply because it would then no longer be a patch.
It's probably easiest to teach git-cherry a --root flag. Does that
sound like the right solution to people? I think it makes sense for
such an option to exist.
More involved would be to teach rev-list --cherry-pick also for
asymmetric ranges. I would imagine that "--cherry-pick $branch --not
$newbase $oldbase" could be defined as "all commits in $branch that
are not patch-equivalent to any commits in $newbase or $oldbase". Just
s/patch-equivalent/identical/ and you have the regular definition of
the rev-list, right? There is of course no need to actually calculate
the patch-id for any commits are not in "$branch --not $newbase
$oldbase" (identical => patch-equivalent).
I would go for teaching git-cherry --root, unless the "rev-list
--cherry-pick for asymmetric ranges" option would be useful
elsewhere. Either way, teaching git-cherry --root would not be a bad
thing, I think.
Martin
[1] Long term, would it make sense to teach 'git cherry-pick' a '-2'
option instead of using the '-3' option to 'git am'? (Where 'git
cherry-pick -2' would try "apply && write-tree && commit-tree"
before falling back to merging.)
^ permalink raw reply
* Re: [PATCH/RFCv4 1/4] Documentation: Preparation for gitweb manpages
From: Jakub Narebski @ 2011-09-20 20:33 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Drew Northup
In-Reply-To: <20110920201953.GA11464@elie>
Jonathan Nieder wrote:
> 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).
No, your concern was valid.
It's better to be more explicit.
--
Jakub Narebski
Poland
^ permalink raw reply
* 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
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