* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Dmitry Potapov @ 2008-10-07 3:08 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.LFD.2.00.0810061909260.3208@nehalem.linux-foundation.org>
On Mon, Oct 06, 2008 at 07:10:37PM -0700, Linus Torvalds wrote:
>
> That changes things. Once some user actually complains, and sends in a
> fix to make the whole dialog optional, I don't see why anybody would ever
> argue against such a patch being accepted.
First, he did not complain. He did not even mention that in the commit
message. He mentioning some other things like removing release notes,
but not the license. Second, I would expect that any change that goes
against the previous achieved agreement may deserve some discussion,
and not blindly accepted just because the user sent a patch. Okay, I
don't really care whether the installer shows the license or not...
Perhaps, something like Help|License would be a better place for it.
Dmitry
^ permalink raw reply
* Re: GitTogether topics status (4th of October)
From: Jeff King @ 2008-10-07 3:15 UTC (permalink / raw)
To: Christian Couder
Cc: git, Shawn O. Pearce, Junio C Hamano, Scott Chacon, Sam Vilain,
Petr Baudis
In-Reply-To: <200810041816.41026.chriscool@tuxfamily.org>
On Sat, Oct 04, 2008 at 06:16:40PM +0200, Christian Couder wrote:
> As can be seen on the GitTogether page on the wiki:
>
> http://git.or.cz/gitwiki/GitTogether
>
> the planned speakers/topics changed a lot during the last weeks and are now:
I just added two proposed half-hour meetings, both of which I intend to
be a few minutes of me talking followed by group discussion. The topics
are:
1. Helping new developers join the git community
This title is a little bit sneaky. I want to talk about not just how
we can get new developers to help improve git, but also how we can
convince them to adopt workflows that make less work for reviewers
and maintainers. It seems like there are some things that we tell
new people over and over about formatting code, formatting patches,
sending patches, etc. Probably the end goal will be improvements to
SubmittingPatches, but maybe putting similar content somewhere more
visible, or maybe even adjusting our workflows a bit.
I hope to make it useful for veterans (who may _constructively_
complain about the habits of new developers), and new developers,
who may learn something about contributing.
This might overlap a bit with Dscho's "contributing with git" talk
(which I am not sure is a talk about using git to contribute in
general, or using git to contribute to git), but I think the
discussion-like forum will make it different enough to be valuable.
2. What needs refactoring?
I occasionally run up against parts of the code that just make my
eyes bleed everytime I touch them. I think we've made significant
progress in maintanability and bug-avoidance with things like the
strbuf library, refactoring of remote and transport handling, etc.
What areas might still benefit from such refactoring?
-Peff
^ permalink raw reply
* [PATCH v2] correct verify_path for Windows
From: Dmitry Potapov @ 2008-10-07 3:26 UTC (permalink / raw)
To: Joshua Juran; +Cc: Giovanni Funchal, git, Shawn O. Pearce, Johannes Sixt
In-Reply-To: <B985AE98-F6E2-4C23-8D34-5A22A9F89FA7@gmail.com>
Colon and backslash in names may be used on Windows to overwrite files
outside of the working directory. Due to the file-system being case-
insensitive, .git can be written as any combination of upper and lower
characters, so we should check that too.
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
In this version, I have added the check that files in .git/ will not
be overwritten by checkout. Overwriting such files as .git/config is
potentially exploitable.
Josh,
Does OS X need the same check below? I believe it has case-insensitive
filesystem, so it needs that too, but I am not sure what is the right
define should be used.
Thanks,
Dmitry
read-cache.c | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index aff6390..7f855ee 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -668,10 +668,19 @@ static int verify_dotfile(const char *rest)
* shares the path end test with the ".." case.
*/
case 'g':
+#if defined(_WIN32) || defined(__CYGWIN__)
+ /* On Windows, file names are case-insensitive */
+ case 'G':
+ if ((rest[1]|0x20) != 'i')
+ break;
+ if ((rest[2]|0x20) != 't')
+ break;
+#else
if (rest[1] != 'i')
break;
if (rest[2] != 't')
break;
+#endif
rest += 2;
/* fallthrough */
case '.':
@@ -703,6 +712,16 @@ inside:
}
return 0;
}
+#if defined(_WIN32) || defined(__CYGWIN__)
+ /*
+ * There is a bunch of other characters that are not allowed
+ * in Win32 API, but the following two create a security hole
+ * by allowing to overwrite files outside of the working tree,
+ * therefore they are explicitly prohibited.
+ */
+ else if (c == ':' || c == '\\')
+ return 0;
+#endif
c = *path++;
}
}
--
1.6.0
^ permalink raw reply related
* Re: RFH: gitk equivalent of "git log -p --full-diff file.cpp"
From: Eric Raible @ 2008-10-07 3:45 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, paulus
In-Reply-To: <20081007022705.GA4496@coredump.intra.peff.net>
On Mon, Oct 6, 2008 at 7:27 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 06, 2008 at 07:04:14PM -0700, Eric Raible wrote:
>
>> Anyway what I'm looking for is the gitk equivalent of:
>>
>> git log -p --full-diff file.cpp
>
> Try turning off the option "Limit diffs to listed paths" in the
> preferences menu (or adding "set limitdiffs 0" to your ~/.gitk).
Yes, that's exactly what I was looking for.
Thanks - Eric
^ permalink raw reply
* Re: GitTogether topics status (4th of October)
From: Nicolas Pitre @ 2008-10-07 3:46 UTC (permalink / raw)
To: Jeff King
Cc: Christian Couder, git, Shawn O. Pearce, Junio C Hamano,
Scott Chacon, Sam Vilain, Petr Baudis
In-Reply-To: <20081007031509.GA6031@coredump.intra.peff.net>
On Mon, 6 Oct 2008, Jeff King wrote:
> 2. What needs refactoring?
>
> I occasionally run up against parts of the code that just make my
> eyes bleed everytime I touch them. I think we've made significant
> progress in maintanability and bug-avoidance with things like the
> strbuf library, refactoring of remote and transport handling, etc.
> What areas might still benefit from such refactoring?
Tree object walking and commit object parsing. This is what's holding
pack v4 performances back. But I think that Shawn will cover this
already (I won't be there but I sent my thoughts about this to him).
Nicolas
^ permalink raw reply
* Re: [PATCH] Replace xmalloc/memset(0) pairs with xcalloc
From: Andreas Ericsson @ 2008-10-07 5:12 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <48R7WYLSZ5lElWvJbfurso2ZPBQbzSCmtOgIsqTWyaA8yfW6Ndq1aA@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Many call sites immediately initialize allocated memory with zero after
> calling xmalloc. A single call to xcalloc can replace this two-call
> sequence.
>
Nicely done. Apart from reducing LoC count, this is also a slight
optimization as we'll no longer bzero() memory handed to us directly
by the kernel (which is already nul'ed out).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH v2] git init: --bare/--shared overrides system/global config
From: Deskin Miller @ 2008-10-07 5:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081006141452.GA7684@spearce.org>
If core.bare or core.sharedRepository are set in /etc/gitconfig or
~/.gitconfig, then 'git init' will read the values when constructing a
new config file; reading them, however, will override the values
specified on the command line. In the case of --bare, this ends up
causing a segfault, without the repository being properly initialised;
in the case of --shared, the permissions are set according to the
existing config settings, not what was specified on the command line.
This fix saves any specified values for --bare and --shared prior to
reading existing config settings, and restores them after reading but
before writing the new config file. core.bare is ignored in all
situations, while core.sharedRepository will only be used if --shared
is not specified to git init.
Also includes testcases which use a specified global config file
override, demonstrating the former failure scenario.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
---
On Mon, Oct 06, 2008 at 07:14:52AM -0700, Shawn O. Pearce wrote:
> Deskin Miller <deskinm@umich.edu> wrote:
> > From b6144562983703079a1eba8cdac3506c18d751a3 Mon Sep 17 00:00:00 2001
> > From: Deskin Miller <deskinm@umich.edu>
> > Date: Sat, 4 Oct 2008 20:07:44 -0400
>
> FWIW please don't include these lines in the commit message part
> of the patch email. [...]
Alright, sorry for the messiness; I guess I thought preserving the original
commit date was important? Won't happen again.
> > diff --git a/builtin-init-db.c b/builtin-init-db.c
> > index 8140c12..38e282c 100644
> > --- a/builtin-init-db.c
> > +++ b/builtin-init-db.c
> > @@ -191,6 +194,8 @@ static int create_default_files(const char *template_path)
> > copy_templates(template_path);
> >
> > git_config(git_default_config, NULL);
> > + is_bare_repository_cfg = init_is_bare_repository;
> > + shared_repository = init_shared_repository;
>
> Is this really the right thing to do? It seems like it would prevent
> a user from setting core.sharedRepository = group in their template
> and thus always have a shared repository on their system.
You're right. Fixed in this version: core.bare ignores any config, while
--shared will override config settings, but init will use the config settings
if --shared is not specified.
> A second related test would be a ~/.gitconfig which sets
> core.sharedRepository = 0666 and then does "git init". I think
> the right outcome is a repository which has that set.
Good suggestion, I added such a case in this version. My first version fails
this new testcase, while maint fails the original testcase I wrote.
builtin-init-db.c | 12 ++++++++++--
t/t0001-init.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 8140c12..d30c3fe 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -17,6 +17,9 @@
#define TEST_FILEMODE 1
#endif
+static int init_is_bare_repository = 0;
+static int init_shared_repository = -1;
+
static void safe_create_dir(const char *dir, int share)
{
if (mkdir(dir, 0777) < 0) {
@@ -191,6 +194,9 @@ static int create_default_files(const char *template_path)
copy_templates(template_path);
git_config(git_default_config, NULL);
+ is_bare_repository_cfg = init_is_bare_repository;
+ if (init_shared_repository != -1)
+ shared_repository = init_shared_repository;
/*
* We would have created the above under user's umask -- under
@@ -277,6 +283,8 @@ int init_db(const char *template_dir, unsigned int flags)
safe_create_dir(get_git_dir(), 0);
+ init_is_bare_repository = is_bare_repository();
+
/* Check to see if the repository version is right.
* Note that a newly created repository does not have
* config file, so this will not fail. What we are catching
@@ -381,9 +389,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
setenv(GIT_DIR_ENVIRONMENT, getcwd(git_dir,
sizeof(git_dir)), 0);
} else if (!strcmp(arg, "--shared"))
- shared_repository = PERM_GROUP;
+ init_shared_repository = PERM_GROUP;
else if (!prefixcmp(arg, "--shared="))
- shared_repository = git_config_perm("arg", arg+9);
+ init_shared_repository = git_config_perm("arg", arg+9);
else if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet"))
flags |= INIT_DB_QUIET;
else
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 620da5b..5ac0a27 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -167,4 +167,36 @@ test_expect_success 'init with --template (blank)' '
! test -f template-blank/.git/info/exclude
'
+test_expect_success 'init --bare/--shared overrides system/global config' '
+ (
+ HOME="`pwd`" &&
+ export HOME &&
+ test_config="$HOME"/.gitconfig &&
+ unset GIT_CONFIG_NOGLOBAL &&
+ git config -f "$test_config" core.bare false &&
+ git config -f "$test_config" core.sharedRepository 0640 &&
+ mkdir init-bare-shared-override &&
+ cd init-bare-shared-override &&
+ git init --bare --shared=0666
+ ) &&
+ check_config init-bare-shared-override true unset &&
+ test x0666 = \
+ x`git config -f init-bare-shared-override/config core.sharedRepository`
+'
+
+test_expect_success 'init honors global core.sharedRepository' '
+ (
+ HOME="`pwd`" &&
+ export HOME &&
+ test_config="$HOME"/.gitconfig &&
+ unset GIT_CONFIG_NOGLOBAL &&
+ git config -f "$test_config" core.sharedRepository 0666 &&
+ mkdir shared-honor-global &&
+ cd shared-honor-global &&
+ git init
+ ) &&
+ test x0666 = \
+ x`git config -f shared-honor-global/.git/config core.sharedRepository`
+'
+
test_done
--
1.6.0.2.307.gc427
^ permalink raw reply related
* Re: [PATCH 0/4] diff text conversion filter
From: Johannes Sixt @ 2008-10-07 5:52 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20081007012044.GA4217@coredump.intra.peff.net>
Jeff King schrieb:
> On Mon, Oct 06, 2008 at 05:15:22PM +0200, Matthieu Moy wrote:
>
>> Actually, I understand you don't want git gui and gitk to load MS-Word
>> anytime you click something, but I'd love to see the textconv+diff in
>> gitk.
>>
>> (yeah, that's pretty hard to specify right, the ideal requirement
>> seems to be "in a gui, use the good part of the diff driver, but not
>> the other" :-\).
>
> I think it is even more complex than that. Sometimes when doing "git
> show" I want to see the textconv'd version, and sometimes I don't. So I
> really want a command-line flag or environment variable that I can use
> to control it (with a sane default).
How about this: If I run 'git show -- foo.doc' (foo.doc resolves to a
single path, obviously), I want MS Word, but for other uses of 'git show'
I don't. I think that heuristics could be very effective: With a plain
'git show' I get the overview of the change, and with 'git show --
foo.doc' I drill down into a single document.
Or this: 'git show -p' uses the textconv'd version, 'git show' does not
("Binary files differ").
BTW, also with 'git diff' I sometimes don't want MS Word to pop up...
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/4] diff text conversion filter
From: Jeff King @ 2008-10-07 6:00 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Matthieu Moy, git
In-Reply-To: <48EAF902.3040402@viscovery.net>
On Tue, Oct 07, 2008 at 07:52:02AM +0200, Johannes Sixt wrote:
> How about this: If I run 'git show -- foo.doc' (foo.doc resolves to a
> single path, obviously), I want MS Word, but for other uses of 'git show'
> I don't. I think that heuristics could be very effective: With a plain
> 'git show' I get the overview of the change, and with 'git show --
> foo.doc' I drill down into a single document.
Hrm. I am not opposed to heuristics, but in this case, I don't like the
one you have proposed. ;P
My specific case that prompted this work is a repository full of
pictures and videos, where I rarely (if ever) change the media content,
but frequently change exif tags. So my "usual" case is to want to see
"git log -p" with the textconv'd version. The commit diffs are otherwise
totally meaningless.
But I think for many others, they are primarily working with text data,
but have some (for example) binary word processor documents. Triggering
such conversions for a single file might make more sense there.
So I'm not sure there is a heuristic that serves both desires. Which is
why I would lean towards a command-line argument, backed by a config
option for those repositories which really want it all the time (and let
me reiterate that such a config option would still have _no_ impact on
plumbing; applying text conversion there is just plain wrong).
> Or this: 'git show -p' uses the textconv'd version, 'git show' does not
> ("Binary files differ").
At that point, is there really an advantage over "git show --textconv"?
> BTW, also with 'git diff' I sometimes don't want MS Word to pop up...
Yes. It is annoying that git can't simply read our minds. :)
-Peff
^ permalink raw reply
* Re: [PATCH] error out if path is invalid
From: Johannes Sixt @ 2008-10-07 6:03 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Shawn O. Pearce, git
In-Reply-To: <20081007002221.GS21650@dpotapov.dyndns.org>
Dmitry Potapov schrieb:
> On Mon, Oct 06, 2008 at 09:02:22AM +0200, Johannes Sixt wrote:
>> Dmitry Potapov schrieb:
>>> if (!verify_path(path))
>>> - return -1;
>>> + return error("Invalid path '%s'", path);
>> Look at this change. Didn't the code error out before, too?
>
> It is certainly did not here. As to its caller, it depends. In fact,
> there are two chunks like that in my patch, so I am not sure to which
> one you refer here. If we speak about add_cacheinfo() then though the
> function did not error out, its caller died with one of the following
> messages:
> git update-index: unable to update some-file-name
> or
> git update-index: --cacheinfo cannot add some-file-name
Look at the original patch. You did not change the behavior except to
write more error messages. Maybe I misunderstand the words "to error out".
I understand them as "to detect an error and return early", but not "write
an error message".
> However, if we speak about add_index_entry_with_check then the caller
> will not produce any error. The git would exit successfully (it still
> does) and there was no error message as if everything was fine.
>
> Perhaps, the exit code should be corrected too, but if the git just dies
> when add_index_entry() fails it may cause that having one invalid path
> will prevent to check out other files, which does not seem to be the
> right thing to do.
>
> As to correction to correction to make_cache_entry then after my
> previous patch, it started to error out:
>
> make_cache_entry failed for path 'some-file-name'
>
> before that it silently segfaulted.
>
>> Same in the
>> other cases. Hence, your patch subject does not describe the patch.
>
> Should I include the above explanation in the commit message or do you
> have any objection to having the above error message in cases where the
> caller already produce some message when it dies?
I don't object the change, only its (missing or IMHO incorrect)
justification. I don't think that the above text would be the correct
description because as far as I can see the only change you made was to
add error messages.
-- Hannes
^ permalink raw reply
* Re: files missing after converting a cvs repository to git
From: Andreas Ericsson @ 2008-10-07 6:08 UTC (permalink / raw)
To: Adam Mercer; +Cc: GIT
In-Reply-To: <799406d60810061502y417ec53o1a1f5cef800dfe45@mail.gmail.com>
Adam Mercer wrote:
> Hi
>
> One of the prrojects I am involved with is currently looking into
> migrating from cvs to git, therefore we have been investigating this
> by setting up a git repository that tracks cvs, however there are some
> very strange things going on and I was hoping someone could offer some
> insight into what is going on.
>
> I use the following git cvsimport command to import the repository:
>
> $ git cvsimport -v -a -i -k
> -d:pserver:user@server:port/path/to/cvs/repo -C /path/to/new/git/repo
> module
>
> this ran successfully with no warnings or errors. However, when I
> checkout the new git repository that are several files missing from
> the git checkout that are present in the cvs checkout.
>
> Does anyone know why this would happen, or how to find out?
Has the CVS repo been tampered with in the past? If so, it's entirely
possible that checking out and working with CVS works just fine, but
getting history into coherent changesets is impossible.
Can you checkout the offending (old) revisions using CVS? If so, there
is indeed a bug in the cvs-importer. Otherwise, your CVS repo is hosed
and you're reduced to running whatever conversion tool does the best
job if you want to maintain history.
cvs2svn is apparently quite good at getting even the weirdest history
right. Perhaps you can try that and then running "git svn" on the
resulting svn repo?
Good luck. You'll probably need it :-/
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Files with colons under Cygwin
From: Johannes Sixt @ 2008-10-07 6:13 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Giovanni Funchal, git, Shawn O. Pearce
In-Reply-To: <20081007005327.GT21650@dpotapov.dyndns.org>
Dmitry Potapov schrieb:
> On Mon, Oct 06, 2008 at 08:54:44AM +0200, Johannes Sixt wrote:
>> [*] I say "meaningful" and not "necessary" because the situation is just
>> like when you grab some random SoftwarePackage.tar.gz, and run ./configure
>> without looking first what it is going to do.
>
> When I grab any tar, I can look at its context without myself of any
> risk that some files can be overwritten on my file system. And when
> I want to look at some remote git repository, I usually do:
>
> git clone URL
>
> If it can overwrite some files behind my back, it is security a hole.
Fair enough.
> On Linux (or other sane file systems), we have all required checks to
> prevent that from happening, and they are places in verify_path, which
> prevents malicious names entering into the index and thus to the file
> system too. So, we should do all required checks on Windows too.
I don't object the intention of your patch. But I cannot judge whether
verify_path() is the correct location to put the checks because I don't
know this part of the code. I leave the final word to others.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] correct verify_path for Windows
From: Johannes Sixt @ 2008-10-07 6:18 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Joshua Juran, Giovanni Funchal, git, Shawn O. Pearce
In-Reply-To: <20081007032623.GX21650@dpotapov.dyndns.org>
Dmitry Potapov schrieb:
> +#if defined(_WIN32) || defined(__CYGWIN__)
I think that for consistency you should use __MINGW32__ instead of _WIN32.
> + /* On Windows, file names are case-insensitive */
> + case 'G':
> + if ((rest[1]|0x20) != 'i')
> + break;
> + if ((rest[2]|0x20) != 't')
> + break;
We have tolower().
-- Hannes
^ permalink raw reply
* Re: [PATCH 0/4] diff text conversion filter
From: Matthieu Moy @ 2008-10-07 6:15 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git
In-Reply-To: <20081007060014.GA7965@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Oct 07, 2008 at 07:52:02AM +0200, Johannes Sixt wrote:
>
>> How about this: If I run 'git show -- foo.doc' (foo.doc resolves to a
>> single path, obviously), I want MS Word, but for other uses of 'git show'
>> I don't. I think that heuristics could be very effective: With a plain
>> 'git show' I get the overview of the change, and with 'git show --
>> foo.doc' I drill down into a single document.
>
> Hrm. I am not opposed to heuristics, but in this case, I don't like the
> one you have proposed. ;P
>
> My specific case that prompted this work is a repository full of
> pictures and videos, where I rarely (if ever) change the media content,
> but frequently change exif tags. So my "usual" case is to want to see
> "git log -p" with the textconv'd version. The commit diffs are otherwise
> totally meaningless.
So, you disagree about "git log" not showing the textconv, but you
still agree with half of the proposal :-P. When the user explicitely
requests a single file, he does want textconv (requesting a diff for a
single file and be happy with "binary files differ" would be
strange ...).
It seems quite clear to me that we won't get a heuristic right for
everybody (some diff driver are fast, some are slow, some require an
external GUI, some don't, ...). Better let the thing be nicely
configurable IMHO.
One proposal: have a diff.<driver>.activate with several values:
* "always": activate the diff driver in any porcelain
* "diff": activate it only for "git diff", as currently
* "singlefile": Johannes's heuristic proposal
That way, one could say easily "activate exiftags filter all the time,
but MS-Word only when I request a diff for a single file", and this
leaves room for other values if the need be. Well, there's no room for
"use MS-Word native diff tool in git-gui but antiword/catdoc +
textconv in 'git log -p'" here, but do we want it?
Or is all that just overkill?
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Implement git clone -v
From: Alex Riesen @ 2008-10-07 6:21 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Constantine Plotnikov, git
In-Reply-To: <1223331590-22138-1-git-send-email-vmiklos@frugalware.org>
2008/10/7 Miklos Vajna <vmiklos@frugalware.org>:
> The new -v option forces the progressbar, even in case the output is not
> a terminal.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Sat, Oct 04, 2008 at 11:42:15PM +0200, Alex Riesen <raa.lkml@gmail.com> wrote:
>> 2008/10/3 Constantine Plotnikov <constantine.plotnikov@gmail.com>:
>> > Is there a way to force a progress output on stderr for git clone
>> > preferably using options or environment variables?
>>
>> No, but "-v" option is not used for anything yet, so you are free to
>> implement it.
>
> Something like this?
>
Yes. Does it work? :)
^ permalink raw reply
* Re: [PATCH v2] correct verify_path for Windows
From: Alex Riesen @ 2008-10-07 6:25 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Joshua Juran, Giovanni Funchal, git, Shawn O. Pearce,
Johannes Sixt
In-Reply-To: <20081007032623.GX21650@dpotapov.dyndns.org>
2008/10/7 Dmitry Potapov <dpotapov@gmail.com>:
> +#if defined(_WIN32) || defined(__CYGWIN__)
> + /* On Windows, file names are case-insensitive */
> + case 'G':
> + if ((rest[1]|0x20) != 'i')
> + break;
> + if ((rest[2]|0x20) != 't')
> + break;
> +#else
Maybe it is already time for FILESYSTEM_CASEINSENSITIVE?
^ permalink raw reply
* Re: [PATCH RFC] rebase--interactive: if preserving merges, use first-parent to limit what is shown.
From: Stephen Haberman @ 2008-10-07 6:36 UTC (permalink / raw)
To: Avi Kivity; +Cc: git
In-Reply-To: <20081006212021.04ba9214.stephen@exigencecorp.com>
> So, unless I think of something else, I'm done hacking on this and am
> withdrawing the patch.
>
> Though I am curious--with the sequencer, is the Avi/my request of not
> listing out-of-band commits in the todo file going to be handled?
>
> Some sort of "--first-parent-unless-included-in-rebase" flag.
Okay, I lied--I have a patch that implements this behavior, passes Avi's
script-turned-test, and passes t3404. It implements the above algorithm
of, if in preserving merges mode, start with only first parents in the
todo list, and then recursively prepend right hand side commits to the
todo list only if their parents are going to be rewritten. This drops a
lot of cruft from rebase-i-p with large merges and is very cool, IMHO.
However, lest I burn my "PATCH v2" opportunity, I'm holding off on
posting the updated patch. It works and passes tests but I'm sure I'll
tinker with it some more over the next few days. It will also likely
conflict with my pu sh/maint-rebase3 patch, so I don't know whether to
base it on top of that one or not (guessing not).
Also, I think the patch itself is less interesting than the discussion
of whether this "first parent only" behavior is desired or not.
Obviously I think so--do others agree/disagree?
I've read more into the sequencer, and from what I can tell it still
just drives off a todo of pick/etc. input, and does not generate the
todo itself. So I think my patch is still fair game in terms of how to
generate either the current or the next generation rebase-i-p todo list.
I could be wrong on that though.
Thanks,
Stephen
^ permalink raw reply
* Re: [StGit PATCH 2/6] Remove TODO items that have already been addressed
From: Karl Hasselström @ 2008-10-07 7:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0810061343g3f675356x960aff02e519bb36@mail.gmail.com>
On 2008-10-06 21:43:47 +0100, Catalin Marinas wrote:
> 2008/10/5 Karl Hasselström <kha@treskal.com>:
>
> > TODO | 9 ---------
> > 1 files changed, 0 insertions(+), 9 deletions(-)
>
> We could also drop this file entirely since we have a Tasks list on
> the gna.org project page.
Right, that's probably a good idea.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH 4/6] Add 1.0 TODO items from recent discussion by private mail
From: Karl Hasselström @ 2008-10-07 7:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0810061350k6b90328cqe49db4b0d3f6c87e@mail.gmail.com>
On 2008-10-06 21:50:32 +0100, Catalin Marinas wrote:
> 2008/10/5 Karl Hasselström <kha@treskal.com>:
>
> > +- Convert the remaining commands to the new infrastructure.
> > +
> > +- Go through the design of the UI and make sure there's nothing hard
> > + to change in there that we'll regret later.
> > +
> > +- Write a user guide. I'm thinking a document on the order of 10-30
> > + pages that'll explain why one would want to use StGit, and how.
> > +
> > +- Make sure the rest of the documentation is in good shape.
>
> Actually, at least for these kind of things we should still keep
> this file. We could drop it after 1.0.
Hmm, OK. Though the issue tracker would probably handle this kind of
stuff too -- doesn't it have a way to tag issues with the desired
milestone, and then present a view with, for example, all the
remaining "1.0" issues?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH 6/6] Refresh and expand the tutorial (not finished)
From: Karl Hasselström @ 2008-10-07 7:12 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0810061425u3ead1de5re1a252f03c2d09b3@mail.gmail.com>
On 2008-10-06 22:25:45 +0100, Catalin Marinas wrote:
> 2008/10/5 Karl Hasselström <kha@treskal.com>:
>
> > This is a first pass at expanding the tutorial, fixing its
> > formatting, and updating it with the new things that have happened
> > in StGit.
> >
> > There are a number of things still left to do in the second half
> > of the document; they are tagged with "TODO".
>
> Thanks for this. Even with the TODOs, I think we can merge them into
> the master branch so that I have the same copy as you.
OK, that makes sense; "master" is, after all, a development branch. A
stable development branch, but still a development branch.
> Do you plan to do more work on the tutorial (so that we don't
> duplicate)?
I was planning to finish it if nobody else stepped up. But it'd be
great if I didn't have to do it alone. :-)
I guess we can avoid duplicate work if we send out a mail saying "I'll
now be working on part XXX" before we start writing.
> > -Layout of the .git directory
>
> Should we mention the metadata storage somewhere? This is probably
> too advanced for the tutorial but might be useful to have it in a
> development document (for other to understand where we keep things).
Yes, probably.
> Actually, is the automatically generated documentation from the new
> infrastructure enough?
I doubt it. It probably could be made enough, though, but I don't know
if that'd be better or worse than a separate document -- the code
documentation is tightly tied to the code, and I'm not sure if we want
that in this case.
We can let whoever writes it decide.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [StGit PATCH 5/6] Refresh the main stg man page
From: Karl Hasselström @ 2008-10-07 7:32 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0810061415n551acbc5r812bbd0e75eeb572@mail.gmail.com>
On 2008-10-06 22:15:42 +0100, Catalin Marinas wrote:
> 2008/10/5 Karl Hasselström <kha@treskal.com>:
>
> > + * You can easily 'rebase' your patch stack on top of any other Git
> > + branch. (The 'base' of a patch stack is the most recent Git commit
> > + that is not an StGit patch.) For example, if you started making
>
> You may want to move the bracket before the dot.
You mean like this?
You can easily 'rebase' your patch stack on top of any other Git
branch (the 'base' of a patch stack is the most recent Git commit
that is not an StGit patch).
I slightly prefer the original, since the paretheses contain a full
stand-alone sentence, but it doesn't matter that much.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [QGit bug] git user settings not retrieved when launched for Windows explorer
From: Abdelrazak Younes @ 2008-10-07 7:33 UTC (permalink / raw)
To: Git Mailing List, Marco Costalba
Dear Marco,
When I double click on qgit.exe, the user name and email are not shown
in the user settings (for any of the 3 combo values). But if I run qgit
from the commandline at the mysysgit bash prompt, the boxes are properly
filled. I would like to debug it but, as I reported last week, the MSVC
project doesn't work for me.
By the way, these two edit boxes are not editable on Windows, is that on
purpose? If yes, maybe we could let the user change them is 'Local
config' is selected and call the appropriate git function?
Thanks,
Abdel.
^ permalink raw reply
* Re: [StGit PATCH 5/6] Refresh the main stg man page
From: Karl Hasselström @ 2008-10-07 7:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0810061414ja87488k6aef65fec0856144@mail.gmail.com>
On 2008-10-06 22:14:05 +0100, Catalin Marinas wrote:
> 2008/10/5 Karl Hasselström <kha@treskal.com>:
>
> > --- a/Documentation/stg.txt
> > +++ b/Documentation/stg.txt
> [...]
> > + * After making changes to the worktree, you can incorporate the
> > + changes into an existing patch; this is called 'refreshing'. You
> > + may refresh any patch, not just the topmost one.
>
> I wouldn't advertise the refreshing of "any" patch as it doesn't
> always work (it actually fails in a lot of cases). Or at least we
> could mention that there are some restrictions.
Well, when it does fail, it fails in a controlled way, and lets the
user manually sort out the conflicts or undo. But I guess we could say
that.
When I wrote this, I didn't yet have a "Conflicts" chapter to point
to. :-)
> > + * You can easily 'rebase' your patch stack on top of any other Git
> > + branch.
>
> It might be better with something like "on top of a different Git
> commit". The first thought when reading the above is that you can
> move the patch stack to a different Git branch easily, which is not
> the case (you need to cherry-pick the patches).
Right, that makes sense. (We might want to mention "remote branch"
explicitly, though, since that's by far the most common case.)
> > + * The patch stack is just some extra metadata attached to regular
> > + Git commits, so you can continue to use Git tools along with
> > + StGit.
>
> Again, this is with some restrictions (or there aren't any with the
> new infrastructure?).
Well, "stg undo" can repair any havoc the git tools can make. And by
"havoc" I mean merge or rebase.
This should probably grow a short disclaimer, and point to the "git
interoperability" chapter.
> > + Tracking changes from a remote branch, while maintaining local
> > + modifications against that branch, possibly with the intent of
> > + sending some patches upstream. You can modify your patch stack as
> > + much as you want, and when your patches are finally accepted
> > + upstream, the permanent recorded Git history will contain just the
> > + final sequence of patches, and not the messy sequence of edits that
> > + produced them.
>
> Maybe we could mention that the local history is also clean, not
> only the upstream tree (though you mention it later in a different
> hunk).
Hmm, yes. Though I can't immediately think of any wording that doesn't
make that paragraph a lot more complicated. Suggestions welcome.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Heikki Orsila @ 2008-10-07 7:42 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johannes Schindelin, Linus Torvalds, Jakub Narebski, Petr Baudis,
msysgit, git
In-Reply-To: <20081007015942.GV21650@dpotapov.dyndns.org>
On Tue, Oct 07, 2008 at 05:59:42AM +0400, Dmitry Potapov wrote:
> On Mon, Oct 06, 2008 at 11:11:25PM +0300, Heikki Orsila wrote:
> >
> > I disagree VIOLENTLY with you. I've been utterly struck with this
> > Windows crap here.. I spent a day installing stupid trivial software
> > and answering pointless EULAs. I REALLY REALLY hate extra questions..
>
> Git installer should NOT ask you whether you agree with the license,
> but it merely shows you the license. (At least, it is what was decided
> half a year ago).
It shouldn't even show that. Also, decisions can be changed..
> > This is my 20th reboot..
>
> I am pretty sure that 20th reboot has nothing to do with how many times
> the license has been shown...
Well, I've clicked through annoying "I accept" EULAs at least that many
times already..
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Heikki Orsila @ 2008-10-07 7:46 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Linus Torvalds, Johannes Schindelin, Jakub Narebski, Petr Baudis,
msysgit, git
In-Reply-To: <20081007030824.GW21650@dpotapov.dyndns.org>
On Tue, Oct 07, 2008 at 07:08:24AM +0400, Dmitry Potapov wrote:
> On Mon, Oct 06, 2008 at 07:10:37PM -0700, Linus Torvalds wrote:
> >
> > That changes things. Once some user actually complains, and sends in a
> > fix to make the whole dialog optional, I don't see why anybody would ever
> > argue against such a patch being accepted.
>
> First, he did not complain. He did not even mention that in the commit
> message.
What does that matter? People are complaining now.
> He mentioning some other things like removing release notes,
> but not the license. Second, I would expect that any change that goes
> against the previous achieved agreement may deserve some discussion,
> and not blindly accepted just because the user sent a patch.
Are you thinking this is some kind of decision by committee
organization? NO. Patches are picked up by maintainers. Anyone can
comment on the patches as they are published.
> Okay, I
> don't really care whether the installer shows the license or not...
Then why argue about it? I care very much.
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ 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