* Re: [PATCH] Fixing path quoting issues
From: Jonathan del Strother @ 2007-10-15 13:13 UTC (permalink / raw)
To: git
In-Reply-To: <4711486B.1050301@op5.se>
OK, second attempt at this. First patch fixes quoting in git rebase. Second patch allows you to run tests from a path with a space in. The third allows you to run tests from a path with an apostrophe in (and is where things start to get a bit ugly, hence the separate patch).
^ permalink raw reply
* Re: [PATCH 6/7] Bisect: factorise "bisect_{bad,good,dunno}" into "bisect_state".
From: Johannes Schindelin @ 2007-10-15 12:38 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <200710150542.17667.chriscool@tuxfamily.org>
Hi,
On Mon, 15 Oct 2007, Christian Couder wrote:
> Le dimanche 14 octobre 2007, Johannes Schindelin a ?crit :
>
> > On Sun, 14 Oct 2007, Christian Couder wrote:
> > > -bisect_bad() {
> > > +bisect_state() {
> > > bisect_autostart
> > > - case "$#" in
> > > - 0)
> > > - rev=$(git rev-parse --verify HEAD) ;;
> > > - 1)
> > > - rev=$(git rev-parse --verify "$1^{commit}") ;;
> > > + state=$1
> > > + case "$#,$state" in
> > > + 0,*)
> > > + die "Please call 'bisect_state' with at least one argument." ;;
> > > + 1,bad|1,good|1,dunno)
> > > + rev=$(git rev-parse --verify HEAD) ||
> > > + die "Bad rev input: HEAD"
> > > + bisect_write "$state" "$rev" ;;
> > > + 2,bad)
> > > + rev=$(git rev-parse --verify "$2^{commit}") ||
> > > + die "Bad rev input: $2"
> > > + bisect_write "$state" "$rev" ;;
> >
> > Really? As far as I see, "2,bad" is an error in the current bisect.
>
> But the new "bisect_state" takes one more argument, because the first
> one must be "good" "bad" or "dunno".
>
> So when there is only one argument HEAD is used, and when there are 2
> arguments, $2 is used as the good|bad|dunno rev.
Ah, that explains it! But do you not need to do "2,bad|2,good|2,dunno" in
that case? Or even better: "2,*"?
Thanks,
Dscho
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 12:37 UTC (permalink / raw)
To: Johannes Sixt; +Cc: prohaska, make-w32, Johannes.Schindelin, raa.lkml, ae, git
In-Reply-To: <47135D85.50701@viscovery.net>
> Date: Mon, 15 Oct 2007 14:31:01 +0200
> From: Johannes Sixt <j.sixt@viscovery.net>
> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
> prohaska@zib.de, make-w32@gnu.org, raa.lkml@gmail.com, ae@op5.se,
> git@vger.kernel.org
>
> > I prefer GCC (the MinGW port), but without the MSYS ports of
> > additional tools. I use the GnuWin32 ports augmented by some of my
> > own (where GnuWin32 ports are buggy or terribly slow).
>
> They should work, too. If a tool is missing, ought to notice it soon enough.
>
> These are important to note, though:
>
> - The tools must not do their own LF->CRLF conversion when they are used in
> a pipeline, "just because they know it better".
>
> - GNU tar is needed (in the cpio emulator).
>
> - ln must be able to create hard links on NTFS or do the equivalent of
> cp -p
>
> - GNU cp -al will be needed and should create hard links on NTFS. (I plan to
> use it for local clones in place of cpio -pl.)
>
> Any feedback on how git works for you with these tools is appreciated.
Thanks, I will try.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Sixt @ 2007-10-15 12:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Johannes Schindelin, prohaska, make-w32, raa.lkml, ae, git
In-Reply-To: <E1IhNox-0004n2-N5@fencepost.gnu.org>
Eli Zaretskii schrieb:
>> Date: Mon, 15 Oct 2007 09:47:25 +0100 (BST)
>> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> cc: Steffen Prohaska <prohaska@zib.de>, git@vger.kernel.org,
>> raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, make-w32@gnu.org
>>
>> If you could make Git compile with Visual C++, that would be fabulous.
>
> I prefer GCC (the MinGW port), but without the MSYS ports of
> additional tools. I use the GnuWin32 ports augmented by some of my
> own (where GnuWin32 ports are buggy or terribly slow).
They should work, too. If a tool is missing, ought to notice it soon enough.
These are important to note, though:
- The tools must not do their own LF->CRLF conversion when they are used in
a pipeline, "just because they know it better".
- GNU tar is needed (in the cpio emulator).
- ln must be able to create hard links on NTFS or do the equivalent of
cp -p
- GNU cp -al will be needed and should create hard links on NTFS. (I plan to
use it for local clones in place of cpio -pl.)
Any feedback on how git works for you with these tools is appreciated.
-- Hannes
^ permalink raw reply
* [PATCH] Let users override name of per-directory ignore file
From: Andreas Ericsson @ 2007-10-15 12:30 UTC (permalink / raw)
To: Git Mailing List
When collaborating with projects managed by some other
scm, it often makes sense to have git read that other
scm's ignore-files. This patch lets git do just that, if
the user only tells it the name of the per-directory
ignore file by specifying the newly introduced git config
option 'core.ignorefile'.
Theoretically, this could cause problems when projects get
ported from some other scm to git, but in practice that
is a moot point, as such changes are always followed by a
flagday anyway.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
I'm in the unfortunate position of being forced to work on a large
amount of projects where the upstream repo is in either CVS or SVN,
and fiddling with exclude-files gets more than just a little tedious.
I've tested this patch lightly. git-status and git-add pick up the
option. "make test" passes as well, and the patch is small enough to
seem obviously correct, so I left it at that.
git-svn should probably set this option by default after a successful
clone, and it has the smell of fruit so low-hanging it's practically
already dropped from the tree, but unfortunately my perl-fu is so weak
I can't even find where to add it. Volunteers?
Documentation/config.txt | 10 ++++++++++
Documentation/gitignore.txt | 5 +++++
builtin-add.c | 11 +++++++++--
wt-status.c | 9 ++++++++-
4 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6b2fc82..267f93c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -275,6 +275,16 @@ You probably do not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
+core.ignorefile::
+ Tells git to use a different file for per-directory ignores.
+ This is useful when one wishes to use git for a project
+ when the upstream repository is managed by some other SCM
+ whose ignore-file formats are the same as that of git.
+ For example, setting core.ignorefile to .svnignore in
+ repos where one interacts with the upstream project repo
+ using gitlink:git-svn[1] will make a both SVN users and
+ your own repo ignore the same files.
+
core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index e8b8581..f82eac6 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -32,6 +32,11 @@ precedence, the last matching pattern decides the outcome):
`.gitignore` file. A project normally includes such
`.gitignore` files in its repository, containing patterns for
files generated as part of the project build.
+ The name of the `.gitignore` file can be changed by setting
+ the configuration variable 'core.ignorefile'. This is useful
+ when using git for projects where upstream is using some other
+ SCM. For example, setting 'core.ignorefile' to `.cvsignore`
+ will make git ignore the same files CVS would.
* Patterns read from `$GIT_DIR/info/exclude`.
diff --git a/builtin-add.c b/builtin-add.c
index 966e145..c785d99 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -19,6 +19,7 @@ static const char builtin_add_usage[] =
static int take_worktree_changes;
static const char *excludes_file;
+static const char *ignore_file = ".gitignore";
static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
{
@@ -57,7 +58,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
memset(dir, 0, sizeof(*dir));
if (!ignored_too) {
dir->collect_ignored = 1;
- dir->exclude_per_dir = ".gitignore";
+ dir->exclude_per_dir = ignore_file;
path = git_path("info/exclude");
if (!access(path, R_OK))
add_excludes_from_file(dir, path);
@@ -144,6 +145,12 @@ static int git_add_config(const char *var, const char *value)
excludes_file = xstrdup(value);
return 0;
}
+ if (!strcmp(var, "core.ignorefile")) {
+ if (!value)
+ die("core.ignorefile without value");
+ ignore_file = xstrdup(value);
+ return 0;
+ }
return git_default_config(var, value);
}
@@ -158,7 +165,7 @@ int interactive_add(void)
static struct lock_file lock_file;
static const char ignore_error[] =
-"The following paths are ignored by one of your .gitignore files:\n";
+"The following paths are ignored:\n";
int cmd_add(int argc, const char **argv, const char *prefix)
{
diff --git a/wt-status.c b/wt-status.c
index 03b5ec4..103aefe 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -23,6 +23,7 @@ static const char use_add_rm_msg[] =
static const char use_add_to_include_msg[] =
"use \"git add <file>...\" to include in what will be committed";
static const char *excludes_file;
+static const char *ignore_file = ".gitignore";
static int parse_status_slot(const char *var, int offset)
{
@@ -257,7 +258,7 @@ static void wt_status_print_untracked(struct wt_status *s)
memset(&dir, 0, sizeof(dir));
- dir.exclude_per_dir = ".gitignore";
+ dir.exclude_per_dir = ignore_file;
if (!s->untracked) {
dir.show_other_directories = 1;
dir.hide_empty_directories = 1;
@@ -370,5 +371,11 @@ int git_status_config(const char *k, const char *v)
excludes_file = xstrdup(v);
return 0;
}
+ if (!strcmp(k, "core.ignorefile")) {
+ if (!v)
+ die("core.ignorefile without value");
+ ignore_file = xstrdup(v);
+ return 0;
+ }
return git_default_config(k, v);
}
--
1.5.3.4.1155.gfe96ee-dirty
^ permalink raw reply related
* Re: [PATCH 0/7] Bisect dunno
From: David Symonds @ 2007-10-15 11:53 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johan Herland, git, Marius Storm-Olsen, David Kastrup,
Christian Couder, René Scharfe, Junio Hamano,
Johannes Schindelin
In-Reply-To: <7EDF99A4-00BD-4F89-A31F-DCA33723CDD5@wincent.com>
On 15/10/2007, Wincent Colaiuta <win@wincent.com> wrote:
> El 15/10/2007, a las 9:02, Johan Herland escribió:
>
> > On Monday 15 October 2007, David Symonds wrote:
> >> On 15/10/2007, Marius Storm-Olsen <marius@trolltech.com> wrote:
> >>> David Kastrup said the following on 14.10.2007 19:48:
> >>>>
> >>>> "unknown" clearly is much better than "dunno" though even if my own
> >>>> favorite would be "undecided".
> >>>
> >>> What then about a good'ol programming favorite, "void"? :-)
> >>
> >> "skip"? That would make semantic sense, right?
> >
> > ...or we could go all spaghetti western, and call it "ugly".
> >
> > (as in "git-bisect [the <good>, the <bad> and the <ugly>]")
>
> <personal opinion>
> Yes, it's funny, but I don't think an SCM interface is a place for
> jokes or puns. Git already has one big tongue-in-cheek attribute:
> it's name, so let's leave it at that.
> </personal opinion>
That's also why I suggested "skip"; you might not be able to test a
particular commit, but you might also not *want* to test a particular
commit for some reason.
Dave.
^ permalink raw reply
* RE: Switching from CVS to GIT
From: Dave Korn @ 2007-10-15 11:16 UTC (permalink / raw)
To: 'Johannes Sixt', 'Andreas Ericsson'
Cc: 'Eli Zaretskii', 'David Brown', raa.lkml,
Johannes.Schindelin, git, make-w32
In-Reply-To: <4713431C.7030103@viscovery.net>
On 15 October 2007 11:38, Johannes Sixt wrote:
> http://repo.or.cz/w/git/mingw.git?a=blob;f=compat/mingw.c;h=2554f19765da5709b787e873da225c59f9d22bb7;hb=HEAD#l306
>
> -- Hannes
291 /* Thanks, Bill. You'll burn in hell for that. */
;-)
cheers,
DaveK
--
Can't think of a witty .sigline today....
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 11:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: prohaska, make-w32, raa.lkml, ae, git
In-Reply-To: <Pine.LNX.4.64.0710150946500.25221@racer.site>
> Date: Mon, 15 Oct 2007 09:47:25 +0100 (BST)
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> cc: Steffen Prohaska <prohaska@zib.de>, git@vger.kernel.org,
> raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, make-w32@gnu.org
>
> If you could make Git compile with Visual C++, that would be fabulous.
I prefer GCC (the MinGW port), but without the MSYS ports of
additional tools. I use the GnuWin32 ports augmented by some of my
own (where GnuWin32 ports are buggy or terribly slow).
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Eli Zaretskii @ 2007-10-15 11:06 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes.Schindelin, git, raa.lkml, ae, tsuna, make-w32
In-Reply-To: <E45D25D3-F37A-49BE-8B83-B4567322D41D@zib.de>
> Cc: Johannes.Schindelin@gmx.de, git@vger.kernel.org, raa.lkml@gmail.com,
> ae@op5.se, tsuna@lrde.epita.fr, make-w32@gnu.org
> From: Steffen Prohaska <prohaska@zib.de>
> Date: Mon, 15 Oct 2007 11:23:37 +0200
>
> Ok, so I uploaded the most recent preview of the installer to
>
> http://msysgit.googlecode.com/files/WinGit-1.5.3-preview20071010.exe
Thanks!
> Note, we're about to release an updated version soon. Personally,
> I don't plan to put work in providing tar balls. A working installer
> has higher priority for me.
Fair enough.
> msysgit's GitMe contains all tools from MSYS required to build git.
> It also clones the git source and compiles it. It doesn't install
> anything outside the folder that you chose upon installation.
>
> I strongly believe it is the easiest way to compile git from source.
Okay, thanks a lot for the info.
^ permalink raw reply
* Re: Switching from CVS to GIT
From: David Kastrup @ 2007-10-15 8:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: raa.lkml, make-w32, ae, git
In-Reply-To: <Pine.LNX.4.64.0710150936070.25221@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Mon, 15 Oct 2007, Eli Zaretskii wrote:
>
>> > Date: Mon, 15 Oct 2007 00:45:47 +0100 (BST)
>> > From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>> > cc: Alex Riesen <raa.lkml@gmail.com>, ae@op5.se, tsuna@lrde.epita.fr,
>> > git@vger.kernel.org, make-w32@gnu.org
>> >
>> > The problem is not so much opening, but determining if an existing file
>> > and a file in the index have the same name.
>> >
>> > For example, "README" in the index, but "readme" in the working directory,
>> > will be handled as "deleted/untracked" by the current machinery. IOW git
>> > will not know that what it gets from readdir() as "readme" really is the
>> > same file as "README" in the index.
>>
>> That's because you think file names are simple strings and can be
>> compared by simple string comparison.
>
> Almost...
>
>> This na?ve view is not true even on POSIX systems: "foo/bar" and
>> "/a/b/foo/bar" can be the same file, as well as "/a/b/c/d" and "/x/y/z",
>> given the right symlinks.
>
> ... not quite, ah ...
>
>> But for some reason that eludes me, people who are accustomed to POSIX
>> stop right there and in effect say "file names are strings, if we only
>> make them absolute and resolve links".
>
> ... yes! There you have it. Absolute filenames, resolved by
> readlink() are assumed to be the unique (!) identifiers for the
> contents.
They aren't. One can mount the same file system several times in
different places. In Linux, one can even mount directories and files
to several places at once. Most Unices also support some
case-insensitive file systems, and readlink does not canonicalize the
casing.
> _Note:_ absolute paths _without_ readlink() resolving are _still_
> unique identifiers; this time for files/symlinks.
Not even that. A unique identifier for files would imply that
touching the file does not affect, say, the access times of files with
other unique identifiers.
--
David Kastrup
^ permalink raw reply
* Re: git-svn and submodules
From: Benoit SIGOURE @ 2007-10-15 10:53 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86lka4ofb8.fsf@lola.quinscape.zz>
[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]
On Oct 15, 2007, at 12:14 PM, David Kastrup wrote:
> Benoit SIGOURE <tsuna@lrde.epita.fr> writes:
>
>> This week I'm probably going to start to dive in git-svn by
>> implementing simpler things first:
>> - git svn create-ignore (to create one .gitignore per directory
>> from the svn:ignore properties. This has the disadvantage of
>> committing the .gitignore during the next dcommit, but when you
>> import a repo with tons of ignores (>1000), using git svn show-ignore
>> to build .git/info/exclude is *not* a good idea, because things like
>> git-status will end up doing >1000 fnmatch *per file* in the repo,
>> which leads to git-status taking more than 4s on my Core2Duo 2Ghz 2G
>> RAM)
>
> Well, then this should be fixed in git general, by sorting the ignores
> (wildcards in the first place where they can match), and then just
> moving those patterns that can actually match according to sort order
> to the list of fnmatch candidates (and moving those files that can't
> match anymore die to the sort order out again).
>
> I don't think that the final "solution" for avoiding a lousy global
> O(n^2) algorithm is to replace it with lousy local O(n^2) algorithms
> and just hope for smaller values of n.
That's entirely true, it's more of a workaround than a real
solution. Anyways, there could be other situations in which someone
would like to generate the .gitignore instead of using .git/info/
exclude, so this feature could be useful anyways.
I can try to address this issue later, if I have enough free time in
my hands to do so.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: git-svn and submodules
From: Benoit SIGOURE @ 2007-10-15 10:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git list
In-Reply-To: <47133A40.20303@op5.se>
[-- Attachment #1: Type: text/plain, Size: 928 bytes --]
On Oct 15, 2007, at 12:00 PM, Andreas Ericsson wrote:
> Benoit SIGOURE wrote:
>> - git svn create-ignore (to create one .gitignore per directory
>> from the svn:ignore properties. This has the disadvantage of
>> committing the .gitignore during the next dcommit, but when you
>> import a repo with tons of ignores (>1000), using git svn show-
>> ignore to build .git/info/exclude is *not* a good idea, because
>> things like git-status will end up doing >1000 fnmatch *per file*
>> in the repo, which leads to git-status taking more than 4s on my
>> Core2Duo 2Ghz 2G RAM)
>
> How spoiled we are. I just ran cvs status on a checkout of a repo
> located
> on a server in the local network. It took 6 seconds to complete :P
Hehe, true, once you get used to the taste of Git, you'll never want
to switch back to these disgusting SCMs.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Andreas Ericsson @ 2007-10-15 10:52 UTC (permalink / raw)
To: Johannes Sixt
Cc: Eli Zaretskii, David Brown, dave.korn, raa.lkml,
Johannes.Schindelin, git, make-w32
In-Reply-To: <4713431C.7030103@viscovery.net>
Johannes Sixt wrote:
> Andreas Ericsson schrieb:
>> Eli Zaretskii wrote:
>>>
>>>> If you know what the library on the other end is doing to re-parse the
>>>> arguments back into separate strings, it might be possible to quote
>>>> things
>>>> enough to handle names with spaces, but it is hard.
>>>
>>> It's not hard, it's just a bit of work. And it needs to be done
>>> exactly once.
>>
>> Before someone beats me to it: "Patches welcome" ;-)
>
> Let others do the research for you, hm?
>
> http://repo.or.cz/w/git/mingw.git?a=blob;f=compat/mingw.c;h=2554f19765da5709b787e873da225c59f9d22bb7;hb=HEAD#l306
>
Yup. Although it was more in the nature of "whoever wrote it surely knows
he/she did it and where to find the patch", so I expect this wasn't much
of a timesink for you. My apologies if I was incorrect.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Johannes Sixt @ 2007-10-15 10:38 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Eli Zaretskii, David Brown, dave.korn, raa.lkml,
Johannes.Schindelin, git, make-w32
In-Reply-To: <47133DEC.6020600@op5.se>
Andreas Ericsson schrieb:
> Eli Zaretskii wrote:
>>
>>> If you know what the library on the other end is doing to re-parse the
>>> arguments back into separate strings, it might be possible to quote
>>> things
>>> enough to handle names with spaces, but it is hard.
>>
>> It's not hard, it's just a bit of work. And it needs to be done
>> exactly once.
>
> Before someone beats me to it: "Patches welcome" ;-)
Let others do the research for you, hm?
http://repo.or.cz/w/git/mingw.git?a=blob;f=compat/mingw.c;h=2554f19765da5709b787e873da225c59f9d22bb7;hb=HEAD#l306
-- Hannes
^ permalink raw reply
* Re: git-svn and submodules
From: David Kastrup @ 2007-10-15 10:14 UTC (permalink / raw)
To: git
In-Reply-To: <05CAB148-56ED-4FF1-8AAB-4BA2A0B70C2C@lrde.epita.fr>
Benoit SIGOURE <tsuna@lrde.epita.fr> writes:
> This week I'm probably going to start to dive in git-svn by
> implementing simpler things first:
> - git svn create-ignore (to create one .gitignore per directory
> from the svn:ignore properties. This has the disadvantage of
> committing the .gitignore during the next dcommit, but when you
> import a repo with tons of ignores (>1000), using git svn show-ignore
> to build .git/info/exclude is *not* a good idea, because things like
> git-status will end up doing >1000 fnmatch *per file* in the repo,
> which leads to git-status taking more than 4s on my Core2Duo 2Ghz 2G
> RAM)
Well, then this should be fixed in git general, by sorting the ignores
(wildcards in the first place where they can match), and then just
moving those patterns that can actually match according to sort order
to the list of fnmatch candidates (and moving those files that can't
match anymore die to the sort order out again).
I don't think that the final "solution" for avoiding a lousy global
O(n^2) algorithm is to replace it with lousy local O(n^2) algorithms
and just hope for smaller values of n.
--
David Kastrup
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Andreas Ericsson @ 2007-10-15 10:16 UTC (permalink / raw)
To: Eli Zaretskii
Cc: David Brown, dave.korn, raa.lkml, Johannes.Schindelin, git,
make-w32
In-Reply-To: <E1IhJ7T-0008AC-8b@fencepost.gnu.org>
Eli Zaretskii wrote:
>
>> If you know what the library on the other end is doing to re-parse the
>> arguments back into separate strings, it might be possible to quote things
>> enough to handle names with spaces, but it is hard.
>
> It's not hard, it's just a bit of work. And it needs to be done
> exactly once.
Before someone beats me to it: "Patches welcome" ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH resend] gitk: Do not pick up file names of "copy from" lines
From: Johannes Sixt @ 2007-10-15 10:08 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, Git Mailing List
From: Johannes Sixt <johannes.sixt@telecom.at>
A file copy would be detected only if the original file was modified in the
same commit. This implies that there will be a patch listed under the
original file name, and we would expect that clicking the original file
name in the file list warps the patch window to that file's patch. (If the
original file was not modified, the copy would not be detected in the first
place, the copied file would be listed as "new file", and this whole matter
would not apply.)
However, if the name of the copy is sorted after the original file's patch,
then the logic introduced by commit d1cb298b0b (which picks up the link
information from the "copy from" line) would overwrite the link
information that is already present for the original file name, which was
parsed earlier. Hence, this patch reverts part of said commit.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
I did not see this appear in http://git.kernel.org/?p=gitk/gitk.git
so I assume it got lost in the noise, and resend it.
-- Hannes
gitk | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index b3ca704..1306382 100755
--- a/gitk
+++ b/gitk
@@ -5216,8 +5216,7 @@ proc getblobdiffline {bdf ids} {
set diffinhdr 0
} elseif {$diffinhdr} {
- if {![string compare -length 12 "rename from " $line] ||
- ![string compare -length 10 "copy from " $line]} {
+ if {![string compare -length 12 "rename from " $line]} {
set fname [string range $line [expr 6 + [string first " from " $line] ] end]
if {[string index $fname 0] eq "\""} {
set fname [lindex $fname 0]
--
1.5.3.716.gb8ce0-dirty
^ permalink raw reply related
* Re: git-svn and submodules
From: Andreas Ericsson @ 2007-10-15 10:00 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Eric Wong, git list, Johannes Schindelin
In-Reply-To: <05CAB148-56ED-4FF1-8AAB-4BA2A0B70C2C@lrde.epita.fr>
Benoit SIGOURE wrote:
> - git svn create-ignore (to create one .gitignore per directory from
> the svn:ignore properties. This has the disadvantage of committing the
> .gitignore during the next dcommit, but when you import a repo with tons
> of ignores (>1000), using git svn show-ignore to build .git/info/exclude
> is *not* a good idea, because things like git-status will end up doing
> >1000 fnmatch *per file* in the repo, which leads to git-status taking
> more than 4s on my Core2Duo 2Ghz 2G RAM)
How spoiled we are. I just ran cvs status on a checkout of a repo located
on a server in the local network. It took 6 seconds to complete :P
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-rebase: document suppression of duplicate commits
From: Michael Witten @ 2007-10-15 9:47 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20071015044730.GA12118@coredump.intra.peff.net>
On 15 Oct 2007, at 12:47:30 AM, Jeff King wrote:
> On Sat, Oct 13, 2007 at 07:04:52PM -0400, Michael Witten wrote:
>> I can make a patch, but at the moment I'm swamped and I don't want to
>> think about doing that.
>
> And whoever said procrastination didn't get things done?
:-)
Thanks.
I'm pretty bad at setting priories, so I apologize for
saying I'm swamped and then turning around to submit
other patches.
Sincerely,
Michael Witten
^ permalink raw reply
* [PATCH 2/2] Fixing gitk indentation
From: Jonathan del Strother @ 2007-10-15 9:33 UTC (permalink / raw)
To: git; +Cc: Jonathan del Strother
In-Reply-To: <8c5c35580710141727k4bbd2bgc2292cfcc6f97c4a@mail.gmail.com>
From: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Just tweaking some minor indentation issues in gitk
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
---
gitk | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index ee2a6f5..9b3e627 100755
--- a/gitk
+++ b/gitk
@@ -838,11 +838,11 @@ proc makewindow {} {
bindall <1> {selcanvline %W %x %y}
#bindall <B1-Motion> {selcanvline %W %x %y}
if {[tk windowingsystem] == "win32"} {
- bind . <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D }
- bind $ctext <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D ; break }
+ bind . <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D }
+ bind $ctext <MouseWheel> { windows_mousewheel_redirector %W %X %Y %D ; break }
} else {
- bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
- bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
+ bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
+ bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
if {[tk windowingsystem] eq "aqua"} {
bindall <MouseWheel> {
set delta [expr {- (%D)}]
--
1.5.3.1
^ permalink raw reply related
* [PATCH 1/2] gitk: Added support for OS X mouse wheel
From: Jonathan del Strother @ 2007-10-15 9:33 UTC (permalink / raw)
To: git; +Cc: Jonathan del Strother
In-Reply-To: <8c5c35580710141727k4bbd2bgc2292cfcc6f97c4a@mail.gmail.com>
From: Jonathan del Strother <jon.delStrother@bestbefore.tv>
(Väinö Järvelä supplied this patch a while ago for 1.5.2. It no longer
applied cleanly, so I'm reposting it.)
MacBook doesn't seem to recognize MouseRelease-4 and -5 events, at all.
So i added a support for the MouseWheel event, which i limited to Tcl/tk
aqua, as i couldn't test it neither on Linux or Windows. Tcl/tk needs to
be updated from the version that is shipped with OS X 10.4 Tiger, for
this patch to work.
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
---
gitk | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 300fdce..ee2a6f5 100755
--- a/gitk
+++ b/gitk
@@ -843,6 +843,12 @@ proc makewindow {} {
} else {
bindall <ButtonRelease-4> "allcanvs yview scroll -5 units"
bindall <ButtonRelease-5> "allcanvs yview scroll 5 units"
+ if {[tk windowingsystem] eq "aqua"} {
+ bindall <MouseWheel> {
+ set delta [expr {- (%D)}]
+ allcanvs yview scroll $delta units
+ }
+ }
}
bindall <2> "canvscan mark %W %x %y"
bindall <B2-Motion> "canvscan dragto %W %x %y"
--
1.5.3.1
^ permalink raw reply related
* [PATCH 0/2] gitk: Added support for OS X mouse wheel
From: Jonathan del Strother @ 2007-10-15 9:33 UTC (permalink / raw)
To: git
In-Reply-To: <8c5c35580710141727k4bbd2bgc2292cfcc6f97c4a@mail.gmail.com>
On 15 Oct 2007, at 01:27, Lars Hjemli wrote:
> Your patch has been mangled, probably by your MUA.
>
> Also, these -/+ 4 lines seem to only change tab into spaces: please
> send such cleanups in a separate patch
Alright, let's try again. First patch fixes the mouse wheel, second patch fixes the weird indentation
^ permalink raw reply
* Re: [PATCH 0/7] Bisect dunno
From: Wincent Colaiuta @ 2007-10-15 9:31 UTC (permalink / raw)
To: Johan Herland
Cc: git, David Symonds, Marius Storm-Olsen, David Kastrup,
Christian Couder, René Scharfe, Junio Hamano,
Johannes Schindelin
In-Reply-To: <200710150902.52653.johan@herland.net>
El 15/10/2007, a las 9:02, Johan Herland escribió:
> On Monday 15 October 2007, David Symonds wrote:
>> On 15/10/2007, Marius Storm-Olsen <marius@trolltech.com> wrote:
>>> David Kastrup said the following on 14.10.2007 19:48:
>>>>
>>>> "unknown" clearly is much better than "dunno" though even if my own
>>>> favorite would be "undecided".
>>>
>>> What then about a good'ol programming favorite, "void"? :-)
>>
>> "skip"? That would make semantic sense, right?
>
> ...or we could go all spaghetti western, and call it "ugly".
>
> (as in "git-bisect [the <good>, the <bad> and the <ugly>]")
<personal opinion>
Yes, it's funny, but I don't think an SCM interface is a place for
jokes or puns. Git already has one big tongue-in-cheek attribute:
it's name, so let's leave it at that.
</personal opinion>
Cheers,
Wincent
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Steffen Prohaska @ 2007-10-15 9:23 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Johannes.Schindelin, git, raa.lkml, ae, tsuna, make-w32
In-Reply-To: <E1IhLBW-0006uw-19@fencepost.gnu.org>
On Oct 15, 2007, at 10:20 AM, Eli Zaretskii wrote:
>> Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
>> git@vger.kernel.org,
>> raa.lkml@gmail.com, ae@op5.se, tsuna@lrde.epita.fr, make-
>> w32@gnu.org
>> From: Steffen Prohaska <prohaska@zib.de>
>> Date: Mon, 15 Oct 2007 09:56:40 +0200
>>
>>> While we are at that: can you (or someone else) point me to
>>> instructions on how to build the MinGW port of GIT? I found a
>>> tarball
>>> of the MinGW-ported GIT (v1.5.3, I think), but what I don't seem
>>> to be
>>> able to find is some kind of HOWTO: what tools I need to have
>>> installed, how to configure them (if there are any special issues
>>> there), what command(s) to type, etc. Is there anything like
>>> that out
>>> there, or can someone post such instructions?
>>
>> If you want to have a full working development environment, such that
>> you can start contributing to msysgit right away, and have no
>> firewall
>> issues, go to
>>
>> http://code.google.com/p/msysgit/
>>
>> and install GitMe, currently
>>
>> http://msysgit.googlecode.com/files/GitMe-0.4.2.exe
>>
>> If you only care about an end-user setup, which contains only the git
>> binaries on your system, but no tools to compile them, stay tuned for
>> one or two days. We'll release an updated installer soon.
>
> Sorry I wasn't clear: I want neither. I don't think I will have
> enough free time to become an active contributor to GIT any time
> soon. OTOH, since binaries are not available (and I'd prefer a
> tarball as opposed to an installer, to be more in control of what's
> being installed and where),
Ok, so I uploaded the most recent preview of the installer to
http://msysgit.googlecode.com/files/WinGit-1.5.3-preview20071010.exe
Note, we're about to release an updated version soon. Personally,
I don't plan to put work in providing tar balls. A working installer
has higher priority for me.
> I asked about the development tools
> (compiler and Binutils, obviously, but what else?) required to build
> the source tarball with MinGW tools.
>
> Do I understand correctly that building GIT currently requires MSYS?
> That'd be unfortunate, at least for me.
msysgit's GitMe contains all tools from MSYS required to build git.
It also clones the git source and compiles it. It doesn't install
anything outside the folder that you chose upon installation.
I strongly believe it is the easiest way to compile git from source.
Steffen
^ permalink raw reply
* Re: [PATCH] git-add (-a|-u) and -n support
From: Michael Witten @ 2007-10-15 9:09 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20071015042028.GB4844@coredump.intra.peff.net>
On 15 Oct 2007, at 12:20:28 AM, Jeff King wrote:
> Thank you for submitting a patch! However, please make sure you read
> SubmittingPatches carefully.
I apologize, though I got your first email about
Documentation/SubmittingPatches after I had sent
in this patch; I had gone rummaging around the homepage
for some information, but had found nothing special.
I just submitted a patch (properly!) to Petr Baudis
to add a link to that documentation on the main page.
> -Peff "policing the list with an iron fist in Junio's absence" King
Don't worry, I didn't take it personally ;-)
Sincerely,
Michael Witten
^ 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