* Re: [PATCH v5 1/7] reset: do not accept a mixed reset in a .git dir
From: Junio C Hamano @ 2009-12-15 20:20 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <200912152041.36194.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> diff --git a/builtin-reset.c b/builtin-reset.c
> index 11d1c6e..ac3505b 100644
> --- a/builtin-reset.c
> +++ b/builtin-reset.c
> @@ -286,11 +286,15 @@ int cmd_reset(int argc, const char **argv, const char
> *pre
> if (reset_type == NONE)
> reset_type = MIXED; /* by default */
>
> - if ((reset_type == HARD || reset_type == MERGE)
> - && !is_inside_work_tree())
> + if (reset_type != SOFT && reset_type != MIXED
> + && !is_inside_work_tree())
> die("%s reset requires a work tree",
> reset_type_names[reset_type]);
>
> + if (reset_type == MIXED && is_bare_repository())
> + die("%s reset is not allowed in a bare repository",
> + reset_type_names[reset_type]);
This patch text itself makes sense, I think, except the first part.
^ permalink raw reply
* Re: [PATCH v5 1/7] reset: do not accept a mixed reset in a .git dir
From: Junio C Hamano @ 2009-12-15 20:25 UTC (permalink / raw)
To: Christian Couder
Cc: git, Linus Torvalds, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <7vskbcyot5.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> The reason is that after the next patch, it will not fail in a bare
>> repository,...
>
> That sounds as if you want to change the definition of what the expected
> behaviour is early, because you want to claim a regression you will later
> introduce is not a regression. I hope that is not the case.
Hmm...
By "after the next patch, it will not fail in a bare repository",
did you mean "if the next patch blindly replaced an external call to
read-tree with an internal call to unpack_trees(), it will change the
behaviour, and we will end up allowing '--mixed in bare'. To prevent it
from happening, cmd_reset() should check that condition upfront"?
Then you were not trying to hide regressions (which makes me happier).
But then doesn't the change belong to the next patch, not this one?
^ permalink raw reply
* Git on QNX
From: Tarmigan @ 2009-12-15 21:23 UTC (permalink / raw)
To: Git Mailing List; +Cc: mkraai
Is anyone running git on QNX?
I have compiled and installed it (see config below) but it is failing
a number of the tests. I suspect that many of the later failures are
related to the earlier ones, so I think the earlier ones are probably
more interesting. Am I missing some makefile options?
Despite the test failures, I have been running the binaries
successfully for a couple days. I'm not planning on using git on QNX
very heavily or for very long, but as long as I'm on QNX I figured I
try to get git to work on it.
Here's the tests that are currently failing:
t0000.42 absolute path works as expected
t0006.14 parse date (2008-02-14 20:30:45)
t1002-read-tree-m-u-2way.sh lots of failures
t1100.4 compare commit
t1400.22,27,38,41
t1410.8 reflog delete
t2300.4,5 cd-to-toplevel
t3200.5,30 branch (maybe same as date in t0006.14?)
t3900.10,18 NO_ICONV?
t3901 NO_ICONV?
t4013-diff-various.sh lots of failures
t4201.3 shortlog encoding (NO_ICONV?)
t5000.13 tar tree validate file modification time
t5100-mailinfo.sh
t5510-fetch.sh
I got impatient after about t5600 because QNX in a virtual machine is
very slow. If anyone else wants to try it, you can download a QNX
.iso, get a free 30-day evaluation license and install and run in a
virtual machine.
I have started to look into t0000.42 a little. The symlinks seem to
get setup properly but make_absolute_path gives incorrect results:
# ls -l second/other
lrwxrwxrwx 1 root root 8 Dec 15 12:27 second/other -> ../first
# ../../test-path-utils make_absolute_path third/../second/other/.git/syml
/root/git/t/trash directory.t0000-basic/second/other/.git/syml
# ../../test-path-utils make_absolute_path second/other/.git/syml
/root/git/t/trash directory.t0000-basic/second/other/.git/syml
# ../../test-path-utils make_absolute_path second/other
/root/git/t/trash directory.t0000-basic/second/first <---- THIS LOOKS WRONG
# ../../test-path-utils make_absolute_path second/other/
/root/git/t/trash directory.t0000-basic/second/first <---- THIS LOOKS WRONG
# ../../test-path-utils make_absolute_path second/other/.git
../.git <---- THIS LOOKS WRONG
If anyone has any ideas or interest in the other failing tests, I can
provide more specific information.
Here's the diff that I applied to make git compile (cut-n-paste +
gmail warning) and it's on top of 9a424b27. I would like to properly
submit some bits of it once the tests are passing.
Thanks,
Tarmigan
--------
diff --git a/Makefile b/Makefile
index 4a1e5bc..ca78dcd 100644
--- a/Makefile
+++ b/Makefile
@@ -934,6 +934,30 @@ ifeq ($(uname_S),HP-UX)
NO_SYS_SELECT_H = YesPlease
SNPRINTF_RETURNS_BOGUS = YesPlease
endif
+ifeq ($(uname_S),QNX)
+ NO_OPENSSL=YesPlease
+ NO_CURL=YesPlease
+ NEEDS_SOCKET=YesPlease
+ NO_D_TYPE_IN_DIRENT=YesPlease
+ NO_STRCASESTR=YesPlease
+ NO_MEMMEM = YesPlease
+ NO_STRLCPY = YesPlease
+ NO_MKDTEMP = YesPlease
+ NO_MKSTEMPS = YesPlease
+ #NO_ICONV=YesPlease
+ OLD_ICONV=UnfortunatelyYes
+ NEEDS_LIBICONV=yes
+ ICONVDIR=/opt
+ NO_R_TO_GCC_LINKER=UnfortunatelyYes
+ NO_DEFLATE_BOUND=yes
+ FREAD_READS_DIRECTORIES=UnfortunatelyYes
+ NO_PTHREADS=UnfortunatelyYes
+ NO_MMAP=YesPlease
+ NO_NSEC=YesPlease
+ PERL_PATH=/opt/bin/perl
+ #NO_HSTRERROR = YesPlease
+ #NO_SYS_SELECT_H = YesPlease
+endif
ifeq ($(uname_S),Windows)
GIT_VERSION := $(GIT_VERSION).MSVC
pathsep = ;
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 8ed4a6f..5cbc16c 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -778,7 +778,7 @@ static int fetch_pack_config(const char *var,
const char *value, void *cb)
return git_default_config(var, value, cb);
}
-static struct lock_file lock;
+static struct lock_file lockfile;
static void fetch_pack_setup(void)
{
@@ -958,14 +958,14 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
)
die("shallow file was changed during fetch");
- fd = hold_lock_file_for_update(&lock, shallow,
+ fd = hold_lock_file_for_update(&lockfile, shallow,
LOCK_DIE_ON_ERROR);
if (!write_shallow_commits(&sb, 0)
|| write_in_full(fd, sb.buf, sb.len) != sb.len) {
unlink_or_warn(shallow);
- rollback_lock_file(&lock);
+ rollback_lock_file(&lockfile);
} else {
- commit_lock_file(&lock);
+ commit_lock_file(&lockfile);
}
strbuf_release(&sb);
}
diff --git a/git-compat-util.h b/git-compat-util.h
index 5c59687..857e938 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -42,6 +42,11 @@
/* Approximation of the length of the decimal representation of this type. */
#define decimal_length(x) ((int)(sizeof(x) * 2.56 + 0.5) + 1)
+#if defined(__QNX__)
+#define getpagesize() sysconf(_SC_PAGESIZE)
+#define SA_RESTART 0
+#endif
+
#if defined(__sun__)
/*
* On Solaris, when _XOPEN_EXTENDED is set, its header file
@@ -55,7 +60,7 @@
# else
# define _XOPEN_SOURCE 500
# endif
-#elif !defined(__APPLE__) && !defined(__FreeBSD__) &&
!defined(__USLC__) && !defined(_M_UNIX) && !defined(sgi)
+#elif !defined(__APPLE__) && !defined(__FreeBSD__) &&
!defined(__USLC__) && !defined(_M_UNIX) && !defined(sgi) &&
!defined(__QNX__)
#define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD
needs 600 for S_ISLNK() */
#define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */
#endif
@@ -79,6 +84,7 @@
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
+#include <strings.h>
#include <errno.h>
#include <limits.h>
#include <sys/param.h>
^ permalink raw reply related
* New Proposal (simple) for Metadata in Git Commits: git-meta
From: Sam Elliott @ 2009-12-15 21:27 UTC (permalink / raw)
To: git
Hi,
I had this idea a day or so again, and have written a simple
implementation to storing some semi-structured data in a git commit
message. This means that it's much easier for data to be found and
scraped from a certain commit, for instance what issue numbers commits
refer to or close.
The entirety of the idea is expressed here: http://lenary.github.com/hackery/2009/12/git-meta/
I have so far built an implementation of a way to get the data out of
a commit. I am still investigating how to get this info into the
commit message before the git-commit command so that it doesn't have
to be entirely hand-written.
I was just looking for feedback and to see whether the mailing list
thinks this is a good idea or not? Any help would also be greatly
appreciated.
Thanks!
Sam
--
Sam Elliott
sam@lenary.co.uk
--
^ permalink raw reply
* Re: Git on QNX
From: Junio C Hamano @ 2009-12-15 21:42 UTC (permalink / raw)
To: Tarmigan; +Cc: Git Mailing List, mkraai
In-Reply-To: <905315640912151323s4b158565o2e74ce018b64dc72@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> writes:
> diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
> index 8ed4a6f..5cbc16c 100644
> --- a/builtin-fetch-pack.c
> +++ b/builtin-fetch-pack.c
> @@ -778,7 +778,7 @@ static int fetch_pack_config(const char *var,
> const char *value, void *cb)
> return git_default_config(var, value, cb);
> }
>
> -static struct lock_file lock;
> +static struct lock_file lockfile;
>
> static void fetch_pack_setup(void)
> {
> @@ -958,14 +958,14 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
> )
> die("shallow file was changed during fetch");
>
> - fd = hold_lock_file_for_update(&lock, shallow,
> + fd = hold_lock_file_for_update(&lockfile, shallow,
> LOCK_DIE_ON_ERROR);
> if (!write_shallow_commits(&sb, 0)
> || write_in_full(fd, sb.buf, sb.len) != sb.len) {
> unlink_or_warn(shallow);
> - rollback_lock_file(&lock);
> + rollback_lock_file(&lockfile);
> } else {
> - commit_lock_file(&lock);
> + commit_lock_file(&lockfile);
> }
> strbuf_release(&sb);
> }
Is this because QNX uses "lock" as some global identifier for some other
purpose? I think moving the file-scope-static definition to the scope
it is used in without renaming would make a cleaner patch.
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 5c59687..857e938 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -79,6 +84,7 @@
> #include <stdlib.h>
> #include <stdarg.h>
> #include <string.h>
> +#include <strings.h>
> #include <errno.h>
> #include <limits.h>
> #include <sys/param.h>
Other hunks are QNX specific enough but this hunk is worrisome; you cannot
tell how you are hurting other platforms with this change. Can you tell
declarations of which functions are missing on QNX without this change?
^ permalink raw reply
* Re: New Proposal (simple) for Metadata in Git Commits: git-meta
From: Shawn O. Pearce @ 2009-12-15 22:05 UTC (permalink / raw)
To: Sam Elliott; +Cc: git
In-Reply-To: <93857A5A-744E-4A7C-B42D-23A56A48AAF7@lenary.co.uk>
Sam Elliott <sam@lenary.co.uk> wrote:
> I had this idea a day or so again, and have written a simple
> implementation to storing some semi-structured data in a git commit
> message. This means that it's much easier for data to be found and
> scraped from a certain commit, for instance what issue numbers commits
> refer to or close.
So from your web page, this is basically just YAML shoved into the
footer of the message:
--8<--
Written half of the functionality. Namely the querying half.
---git-meta---
awesome: true
Github:
user: lenary
---git-meta---
-->8--
Why do we need the --git-meta-- delimiter lines?
JGit and Gerrit Code Review have already been following Git tradition
by using footer messages as metadata. E.g. we have lines like:
--8<--
init: Don't abort on empty directory
The following sequence should work:
mkdir testgit
java -jar gerrit.war init -d testgit
Since testgit is empty, it should be acceptable for us to populate the
directory with our files.
Bug: issue 358
Change-Id: Ia85f31802066f8d39b042d3d057d33950a5035fd
Signed-off-by: Shawn O. Pearce <sop@google.com>
-->8--
The JGit commit message parser has special logic to handle lines
that smell like one of these tag lines. So long as there is no
blank line in the footer paragraph, each of these tags can be read
and processed. Continuation lines should start with whitespace.
I don't remember my YAML well enough, but isn't this existing
standard still parseable by a YAML processor?
If you dropped the --git-meta-- tags above, JGit would happily
recognize the awesome: and Github: tags, but it might need a bit
more work to recognize the nested user: tag. Also, you'd be able
to use git-meta on the git and Linux kernel repositories to pull
out and work with Signed-off-by, Acked-by, etc.
--
Shawn.
^ permalink raw reply
* Re: Git on QNX
From: Tarmigan @ 2009-12-15 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, mkraai
In-Reply-To: <7v6387zzfi.fsf@alter.siamese.dyndns.org>
On Tue, Dec 15, 2009 at 1:42 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan <tarmigan+git@gmail.com> writes:
>
>> diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
>> index 8ed4a6f..5cbc16c 100644
>> --- a/builtin-fetch-pack.c
>> +++ b/builtin-fetch-pack.c
>> @@ -778,7 +778,7 @@ static int fetch_pack_config(const char *var,
>> const char *value, void *cb)
>> return git_default_config(var, value, cb);
>> }
>>
>> -static struct lock_file lock;
>> +static struct lock_file lockfile;
>>
>> static void fetch_pack_setup(void)
>> {
>> @@ -958,14 +958,14 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
>> )
>> die("shallow file was changed during fetch");
>>
>> - fd = hold_lock_file_for_update(&lock, shallow,
>> + fd = hold_lock_file_for_update(&lockfile, shallow,
>> LOCK_DIE_ON_ERROR);
>> if (!write_shallow_commits(&sb, 0)
>> || write_in_full(fd, sb.buf, sb.len) != sb.len) {
>> unlink_or_warn(shallow);
>> - rollback_lock_file(&lock);
>> + rollback_lock_file(&lockfile);
>> } else {
>> - commit_lock_file(&lock);
>> + commit_lock_file(&lockfile);
>> }
>> strbuf_release(&sb);
>> }
>
> Is this because QNX uses "lock" as some global identifier for some other
> purpose? I think moving the file-scope-static definition to the scope
> it is used in without renaming would make a cleaner patch.
Yes, exactly that reason. I agree the declaration should just move
into fetch_pack() as a static, but I didn't realize that until after I
had renamed all of the uses, and I was lazy as this was not for
submission.
>
>> diff --git a/git-compat-util.h b/git-compat-util.h
>> index 5c59687..857e938 100644
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -79,6 +84,7 @@
>> #include <stdlib.h>
>> #include <stdarg.h>
>> #include <string.h>
>> +#include <strings.h>
>> #include <errno.h>
>> #include <limits.h>
>> #include <sys/param.h>
>
> Other hunks are QNX specific enough but this hunk is worrisome; you cannot
> tell how you are hurting other platforms with this change. Can you tell
> declarations of which functions are missing on QNX without this change?
strcasecmp()
http://www.opengroup.org/onlinepubs/000095399/functions/strcasecmp.html
I agree that this change could affect other platforms and they've
gotten along fine without it so far. I'm surprised no others have
needed it. Would it be better wrapped in a #ifdef?
Thanks,
Tarmigan
^ permalink raw reply
* core.autocrlf & Cygwin - files incorrectly flagged as modified
From: David Antliff @ 2009-12-15 22:24 UTC (permalink / raw)
To: git
I approached the Cygwin mailing list about this problem, and the package
maintainer suggested I ask here as well, in case someone can shed some light on
this.
I am using git-1.6.4.2 (as part of Cygwin-1.7 beta) and I've observed some
behaviour that seems wrong to me.
When we deployed git on Cygwin, we decided to set core.autocrlf=true, as many of
our users are working with DOS/Windows files (CRLF endings). Some users are
using Linux and working on the same code. I'm not actually sure why we chose to
use this setting - there's a lot of conflicting advice around. I think the final
decision was made so that kdiff3 would operate correctly. However we did go to
lengths to ensure that everyone is using the same configuration setting.
The problem is that sometimes, after a git-clone, the output of git-status and
git-diff shows entire files as being different. However these files have not
been modified by the user - only git has had a chance to change them (due to
autocrlf=true). But surely if git has converted the file automatically, it
should know that it has to compensate for this when comparing with the local
repository?
And I think it usually does this and almost all files behave properly. The
problem arises when the source-controlled file contains lines with trailing
whitespace. In this situation, git-diff clearly indicates a difference and this
blocks merges and checkouts.
I suspect what is happening is that the line conversion routine in git might be
stripping trailing whitespace, as well as converting the line endings. This
operation is not properly accounted for in the reverse direction, and the file
is flagged as modified.
The Cygwin git package maintainer has indicated that he thinks this might be a
bug: http://cygwin.com/ml/cygwin/2009-12/msg00466.html
Also, as cloned files are converted to DOS-line-endings, by default Cygwin's
bash cannot run any scripts as they have the wrong line endings. I have to set
the 'permanent' bash variable SHELLOPTS to include 'igncr' before bash scripts
can run. Perhaps this is wrong and git on Cygwin (with binary mounts) should be
converting to UNIX line endings instead?
At one point I tried switching off core.autocrlf for myself but this caused a
lot of conflicts due to mismatched line-endings. It seems to me that if we want
to switch to this, *everyone* has to do it at once.
I'd like to know whether this is a problem worthy of further investigation,
whether it should fall in the git or Cygwin camp, and whether I really ought to
be using autocrlf=true please.
^ permalink raw reply
* git svn clone just stops
From: Mark Jerkovic @ 2009-12-15 22:19 UTC (permalink / raw)
To: git
Hi all,
I am new to Git and I am attempting to clone a SVN repository
(containing approximately 60,000 commits) to Git.
Using Git v1.6.0.4 with the following command:
git svn clone https://path/to/svn/repo/trunk project.git
--authors-file=svnauthors.txt --no-metadata
the process just ends without any messages and the Git repository is
empty. I have attempted this four times already, and each time it has
stopped after a different revision, so I can't pin it down to a
particular commit.
Has anyone experienced this before? Is there a log anywhere that
records what is happening during this process?
Thanks,
Mark.
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Andreas Schwab @ 2009-12-15 22:52 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Brandon Casey, Junio C Hamano, Brandon Casey, jk, git
In-Reply-To: <20091215012514.GB1317@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Right. And checking, after sending a patch containing CRs with mutt, it
> lost those CRs. Even the local copy saved directly by mutt, which didn't
> leave my box, lacks the CRs. So it seems basically impossible to send
> patches to CRLF files inline.
If you want to send mail containing a bare CR you need to encode it.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Fwd: am fails to apply patches for files with CRLF lineendings
From: Andreas Schwab @ 2009-12-15 23:18 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <ee63ef30912141809k27bc73edp20abddd5e9c7c063@mail.gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> But isn't each email in the mbox file supposed to be RFC-2822
> formatted anyway? If so, then my reading of RFC-2822 says that there
> should only be CRLF everywhere and no bare CR or bare LF. But maybe
> everyone has just been ignoring that part of RFC-2822? I'm not an
> email expert, so I really don't know.
RFC 2822 specifies a *transport* format, where each text lines is
represented by terminating it with CRLF. Any other use is outside the
scope of that RFC. The mbox format normally uses the native format for
text files, which means LF terminated lines when used under Unix.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH 1/2] filter-branch: remove an unnecessary use of 'git read-tree'
From: Junio C Hamano @ 2009-12-16 0:19 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <4B274BDE.8000504@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Johannes Sixt <j6t@kdbg.org>
>
> The intent of this particular call to 'git read-tree' was to fill an
> index. But in fact, it only allocated an empty index. Later in the
> program, the index is filled anyway by calling read-tree with specific
> commits, and considering that elsewhere the index is even removed (i.e.,
> it is not relied upon that the index file exists), this first call of
> read-tree is completely redundant.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Very true. The only thing it would have done is to error out early when
the user mistakenly tried to run the command in a directory in which s/he
does not have write access to, before running potentially expensive
commit listing with rev-list, but then the user would have failed to
create the tempdir before that to begin with.
Will queue, but it doesn't seem urgent to put it in 1.6.6 or 1.6.5.X
maint (i.e. nothing is broken without this patch).
> Calling read-tree without arguments is not allowed according to the
> documentation.
I think saying "is not allowed" is going a bit too far. The documentation
simply does not list it as a _useful_ thing to do, that's all.
By the way, I notice that the command still insists on being run in a
clean work tree with a clean index at the beginning, but isn't everything
done inside the tempdir (i.e. ".git-rewrite" by default) these days,
including the temporary work tree tree-filter creates with "checkout-index
-fqua"? It is obviously not a topic of this patch, but we may want to
stop doing that if we are not rewriting the current commit (which we will
know by the time we list the commits to be rewritten with rev-list before
actually starting to rewrite).
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Andreas Schwab @ 2009-12-16 0:38 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Brandon Casey, Junio C Hamano, Brandon Casey, jk, git
In-Reply-To: <m26387voiy.fsf@igel.home>
Andreas Schwab <schwab@linux-m68k.org> writes:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
>> Right. And checking, after sending a patch containing CRs with mutt, it
>> lost those CRs. Even the local copy saved directly by mutt, which didn't
>> leave my box, lacks the CRs. So it seems basically impossible to send
>> patches to CRLF files inline.
>
> If you want to send mail containing a bare CR you need to encode it.
Btw, this mail had a stray CR added to the last line when I sent it out
(properly encoded as quoted-printable), but that didn't make it through
gmane. :-)
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Junio C Hamano @ 2009-12-16 1:05 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, git
In-Reply-To: <20091215164959.GA21322@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> - diff.c::run_external_diff() that runs GIT_EXTERNAL_DIFF defines that
>> the command has to take 7 parameters in a fixed order, and is not
>> designed to permute its arguments like ll_ext_merge() does, but these
>> days people don't use it directly (they use it indirectly via
>> "difftool" wrapper), so it probably is not an issue.
>
> There is also diff.*.command, which I think people _do_ set manually (I
> used to, until I wrote textconv. :) ).
I had to spend fair amount of time to find where "diff.*.command" is
described. We may want to update the documentation.
> .... I agree that people almost certainly have to write a shell-script
> wrapper anyway. But I wonder if we should pass it through the shell,
> just for the sake of consistency with the other variables (in
> particular, if textconv changes,
This covers GIT_EXTERNAL_DIFF, diff.external, and diff.<driver>.command
trio, if I am not mistaken.
If we changed run_external_diff(), in practice nobody would notice, except
for people who have installed the difftool helper in a directory with IFS
in the path. That's one downside but I don't offhand see a use case where
the change would make somebody vastly happier.
But maybe people will find good uses and we'll never know until we try.
Care to roll a patch for that as well, to be queued for 1.7.0 (which will
be the one after 1.6.6)?
^ permalink raw reply
* Re: Giving command line parameter to textconv command?
From: Jeff King @ 2009-12-16 1:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vljh3wwwf.fsf@alter.siamese.dyndns.org>
On Tue, Dec 15, 2009 at 05:05:52PM -0800, Junio C Hamano wrote:
> > There is also diff.*.command, which I think people _do_ set manually (I
> > used to, until I wrote textconv. :) ).
>
> I had to spend fair amount of time to find where "diff.*.command" is
> described. We may want to update the documentation.
Yeah, I think textconv is similarly hard to find. We should probably
have a pointer in "git-diff.txt" to the attributes documentation.
I also think it would be much more obvious as "diff.*.external", but it
is probably not worth changing at this point.
> > .... I agree that people almost certainly have to write a shell-script
> > wrapper anyway. But I wonder if we should pass it through the shell,
> > just for the sake of consistency with the other variables (in
> > particular, if textconv changes,
>
> This covers GIT_EXTERNAL_DIFF, diff.external, and diff.<driver>.command
> trio, if I am not mistaken.
It does cover all three. We could do them separately, I guess, but I
think that is just making things confusingly more inconsistent.
> If we changed run_external_diff(), in practice nobody would notice, except
> for people who have installed the difftool helper in a directory with IFS
> in the path. That's one downside but I don't offhand see a use case where
> the change would make somebody vastly happier.
Yeah, the only upside I can see is consistency. Which I do value, but it
will be a hard sell to somebody whose setup has been broken. ;P
> But maybe people will find good uses and we'll never know until we try.
> Care to roll a patch for that as well, to be queued for 1.7.0 (which will
> be the one after 1.6.6)?
Will do, but it will probably be a few days as I'm about to do some
holiday traveling. I'll do the textconv change with it as a series.
-Peff
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: Junio C Hamano @ 2009-12-16 1:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: J.H., git, John 'Warthog9' Hawley
In-Reply-To: <200912112353.11034.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Fri, 11 Dec 2009, J.H. wrote:
>
>>>> This is also a not-so-subtle start of trying to break up gitweb into
>>>> separate files for easier maintainability, having everything in a
>>>> single file is just a mess and makes the whole thing more complicated
>>>> than it needs to be. This is a bit of a baby step towards breaking it
>>>> up for easier maintenance.
>>>
>>> The question is if easier maintenance and development by spliting
>>> gitweb for developers offsets ease of install for users.
>>
>> This would just get dropped into the same location that gitweb.cgi
>> exists in, there is no real difference in installation, and thus I can't
>> see this as an issue for users.
>
> To be more exact you have to know that you have to drop _generated files_,
> which means (for this version of patch) gitweb.cgi and gitweb_defaults.pl
> (or whatever the generated file with config variables would be named).
>
>
> ATTENTION!
You didn't have to shout.
Any progress on this front?
Not that I am anxious to queue new topics to 'next' right now (we are
frozen for 1.6.6), but I think having what is proven to work well at a
real site like k.org is much better than waiting for an unproven
reimplementation using somebody else's framework only for your theoretical
cleanliness. John has better things to do than doing such a rewrite
himself, and even if you helped the process by producing a competing
caching scheme based on existing web caching engines, the aggregated
result (not just the web caching engine you base your work on) needs to
get a similar field exposure to prove itself that it can scale to the load
k.org sees, which would be quite a lot of work, no?
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Junio C Hamano @ 2009-12-16 1:25 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <7vzl5mjndi.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> On Sat, Dec 12, 2009 at 01:45:45PM -0800, Junio C Hamano wrote:
>>
>>> This is a sane thing to do, as "slot" is part of the name of the variable,
>>> and we generally do not warn upon seeing a misspelled variable name (it
>>> makes it worse that "func" is not even misspelled but merely unknown to
>>> older version of git in your scenario).
>>>
>>> On the other hand, I suspect that most people would apprecfiate if their
>>> git pointed out "diff.color.finc? What do you mean?" before they waste
>>> 30 minutes wondering why the new feature in 1.6.6 does not work for them.
>>
>> I would be more sympathetic to that user if this weren't the _only_ set
>> of variables with this property. They don't get warned for diff.externel
>> or color.show-branch.
>
> True and fair enough. Let's have this in 1.6.6 then.
Actually I think we should have this in 1.6.5.X as well for it to be
useful. Am I mistaken?
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Junio C Hamano @ 2009-12-16 1:29 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091212122524.GA17547@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/builtin-branch.c b/builtin-branch.c
> index 05e876e..c87e63b 100644
> --- a/builtin-branch.c
> +++ b/builtin-branch.c
> @@ -65,7 +65,7 @@ static int parse_branch_color_slot(const char *var, int ofs)
> return BRANCH_COLOR_LOCAL;
> if (!strcasecmp(var+ofs, "current"))
> return BRANCH_COLOR_CURRENT;
> - die("bad config variable '%s'", var);
> + return -1;
> }
>
> static int git_branch_config(const char *var, const char *value, void *cb)
> @@ -76,6 +76,8 @@ static int git_branch_config(const char *var, const char *value, void *cb)
> }
> if (!prefixcmp(var, "color.branch.")) {
> int slot = parse_branch_color_slot(var, 13);
> + if (slot < 0)
> + return 0;
> if (!value)
> return config_error_nonbool(var);
> color_parse(value, var, branch_colors[slot]);
> diff --git a/builtin-commit.c b/builtin-commit.c
> index e93a647..326cd63 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -890,7 +890,7 @@ static int parse_status_slot(const char *var, int offset)
> return WT_STATUS_NOBRANCH;
> if (!strcasecmp(var+offset, "unmerged"))
> return WT_STATUS_UNMERGED;
> - die("bad config variable '%s'", var);
> + return -1;
> }
>
> static int git_status_config(const char *k, const char *v, void *cb)
> @@ -910,6 +910,8 @@ static int git_status_config(const char *k, const char *v, void *cb)
> }
> if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
> int slot = parse_status_slot(k, 13);
> + if (slot < 0)
> + return -1;
Shouldn't this return 0, to say "we handled it (by ignoring), don't
worry", instead of saying "hey it's error" by returning -1? That's what
is done on the "diff" side below...
> diff --git a/diff.c b/diff.c
> index d952686..08bbd3e 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -122,6 +122,8 @@ int git_diff_basic_config(const char *var, const char *value, void *cb)
>
> if (!prefixcmp(var, "diff.color.") || !prefixcmp(var, "color.diff.")) {
> int slot = parse_diff_color_slot(var, 11);
> + if (slot < 0)
> + return 0;
> if (!value)
> return config_error_nonbool(var);
> color_parse(value, var, diff_colors[slot]);
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: J.H. @ 2009-12-16 2:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, John 'Warthog9' Hawley
In-Reply-To: <7v8wd3ww4d.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> On Fri, 11 Dec 2009, J.H. wrote:
>>
>>>>> This is also a not-so-subtle start of trying to break up gitweb into
>>>>> separate files for easier maintainability, having everything in a
>>>>> single file is just a mess and makes the whole thing more complicated
>>>>> than it needs to be. This is a bit of a baby step towards breaking it
>>>>> up for easier maintenance.
>>>> The question is if easier maintenance and development by spliting
>>>> gitweb for developers offsets ease of install for users.
>>> This would just get dropped into the same location that gitweb.cgi
>>> exists in, there is no real difference in installation, and thus I can't
>>> see this as an issue for users.
>> To be more exact you have to know that you have to drop _generated files_,
>> which means (for this version of patch) gitweb.cgi and gitweb_defaults.pl
>> (or whatever the generated file with config variables would be named).
>>
>>
>> ATTENTION!
>
> You didn't have to shout.
>
> Any progress on this front?
Sadly, no. Busy weekend and a need to get some of the kernel.org
servers upgraded has taken some precedence. I should be circling back
around on this tomorrow I think.
> Not that I am anxious to queue new topics to 'next' right now (we are
> frozen for 1.6.6), but I think having what is proven to work well at a
> real site like k.org is much better than waiting for an unproven
> reimplementation using somebody else's framework only for your theoretical
> cleanliness. John has better things to do than doing such a rewrite
> himself, and even if you helped the process by producing a competing
> caching scheme based on existing web caching engines, the aggregated
> result (not just the web caching engine you base your work on) needs to
> get a similar field exposure to prove itself that it can scale to the load
> k.org sees, which would be quite a lot of work, no?
^ permalink raw reply
* Re: [PATCH 6/6] GITWEB - Separate defaults from main file
From: Jakub Narebski @ 2009-12-16 2:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J.H., git, John 'Warthog9' Hawley
In-Reply-To: <7v8wd3ww4d.fsf@alter.siamese.dyndns.org>
On Wed, 16 Dec 2009, Junio C Hamano wrote:
> Not that I am anxious to queue new topics to 'next' right now (we are
> frozen for 1.6.6), but I think having what is proven to work well at a
> real site like k.org is much better than waiting for an unproven
> reimplementation using somebody else's framework only for your theoretical
> cleanliness. John has better things to do than doing such a rewrite
> himself, and even if you helped the process by producing a competing
> caching scheme based on existing web caching engines, the aggregated
> result (not just the web caching engine you base your work on) needs to
> get a similar field exposure to prove itself that it can scale to the load
> k.org sees, which would be quite a lot of work, no?
I'm not against (well, not much against) custom caching that kernel.org
uses, but I am against large change to gitweb code currently accompanying
caching, namely gather then output solution, which would negatively
affect performance when caching is turned off.
Also I'd like to have caching code (the one that didn't made it to git
mailing list for some reason, probably vger anti-SPAM filter) cleaned up
for submission: remove commented-out code, reduce code duplication,
separate dealing with orthogonal issues (cache itself, adaptivity of cache,
background generation and 'in progress' info, generating key for cache
(and improve key generation to include path_info / use %input_params)),
follow the same style that gitweb itself uses.
As for the "[PATCH 6/6] GITWEB - Separate defaults from main file" patch,
it would require modifying gitweb tests to use generated gitweb/gitweb.cgi
rather than source gitweb/gitweb.perl.
As for having caching code tested by git.kernel.org: IIRC there was issue
with it not having cache expiration thus gathering GB of cached data.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Nicolas Pitre @ 2009-12-16 3:03 UTC (permalink / raw)
To: Eric Paris; +Cc: Jeff King, git
In-Reply-To: <1260851180.9379.88.camel@localhost>
On Mon, 14 Dec 2009, Eric Paris wrote:
> The alternative repo is slowing pushing up to that same location. That
> tar is 855838982, so just a tad bit smaller.
It doesn't appear to be complete yet, and not progressing either.
Nicolas
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-16 3:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <alpine.LFD.2.00.0912152201300.23173@xanadu.home>
On Tue, 2009-12-15 at 22:03 -0500, Nicolas Pitre wrote:
> On Mon, 14 Dec 2009, Eric Paris wrote:
>
> > The alternative repo is slowing pushing up to that same location. That
> > tar is 855838982, so just a tad bit smaller.
>
> It doesn't appear to be complete yet, and not progressing either.
I ran out of quota and ask for more, but IT departments moves at the
speed of IT departments. I'll delete the first one and just push the
alternative repo. Once I get more space I'll try to get them both up at
once....
-Eric
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Jeff King @ 2009-12-16 3:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3a3bwvzj.fsf@alter.siamese.dyndns.org>
On Tue, Dec 15, 2009 at 05:25:36PM -0800, Junio C Hamano wrote:
> >> I would be more sympathetic to that user if this weren't the _only_ set
> >> of variables with this property. They don't get warned for diff.externel
> >> or color.show-branch.
> >
> > True and fair enough. Let's have this in 1.6.6 then.
>
> Actually I think we should have this in 1.6.5.X as well for it to be
> useful. Am I mistaken?
The earlier the better for making it useful, but it is still somewhat of
a lost cause for color.diff.func. The problem comes from using git
v1.6.6, setting the variable, and then going to back to some older
version (either because you are testing multiple versions, or because
your config is shared across multiple machines).
So yes, putting it in v1.6.5.x means switching back there will not be as
painful. But switching back to existing versions will still be broken
until all older versions you might want to switch to have this patch.
So we are not so much fixing this color.diff.func problem as
future-proofing against this happening again.
-Peff
^ permalink raw reply
* Re: [PATCH/RFC] ignore unknown color configuration
From: Jeff King @ 2009-12-16 3:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6l3vh8x.fsf@alter.siamese.dyndns.org>
On Tue, Dec 15, 2009 at 05:29:18PM -0800, Junio C Hamano wrote:
> > if (!prefixcmp(k, "status.color.") || !prefixcmp(k, "color.status.")) {
> > int slot = parse_status_slot(k, 13);
> > + if (slot < 0)
> > + return -1;
>
> Shouldn't this return 0, to say "we handled it (by ignoring), don't
> worry", instead of saying "hey it's error" by returning -1? That's what
> is done on the "diff" side below...
Yes, thank you for catching it. It should definitely be "return 0" (as
the other two cases are). It was a simple think-o on my part.
-Peff
^ permalink raw reply
* Re: TortoiseGIT
From: Frank Li @ 2009-12-16 6:26 UTC (permalink / raw)
To: Laszlo Papp; +Cc: git
In-Reply-To: <a362e8010912150741x2c39c01bh1f64e669726dafab@mail.gmail.com>
You keep cr+lf on/off on whole develop cycle. Avoid change it during
developing.
After change cr+lf setting, I perfer you remove all work copy and
recheckout all.
best regards
Frank Li
2009/12/15 Laszlo Papp <djszapi@archlinux.us>:
> Hello,
>
> I had got a problem in the past with cr + lf between windows and linux
> client(maybe now too).
> I heard that from more experienced users I need to set autocrlf +
> safecrlf on windows, and core.autocrlf false on linux (which is the
> default), but If I set core.autocrlf true on linux too, it worked
> normally, after a git pull on windows I don't see any modified file
> that should be committed, not the case in core.autocrlf false.
>
> Could someone explain this habbit of git, please ?
>
> Everybody said I need to set autocrlf for false, but it doesn't work
> so, just with true on linux client, what do I do wrong ?
> It's okay now for me, because it works without any problem, I just
> don't understand the behaviour of it, and I don't know whether it will
> cause further problems.
>
> Thanks in advance!
>
> Best Regards,
> Laszlo Papp
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ 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