* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Avery Pennarun @ 2008-07-23 15:53 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <20080723120104.GQ2925@dpotapov.dyndns.org>
On 7/23/08, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Tue, Jul 22, 2008 at 06:22:34PM -0400, Avery Pennarun wrote:
> > This patch is perhaps a symptom of something I've been meaning to ask
> > about for a while.
> >
> > Why doesn't "edit" just stage the commit and not auto-commit it at
> > all? That way an amend would *never* be necessary, and rebase
> > --continue would always do a commit -a (if there was anything left to
> > commit).
>
> Actually, it would be better to refuse to continue if there are unstaged
> changes in the work tree, and if all changes are staged then just do git
> commit.
I'm not sure about that. The auto-committing on --continue has never
annoyed me, and in fact I greatly appreciate that I can just "git
rebase --continue" after making changes and the expected thing will
happen. After all, if I screw it up and commit too much at once, I
can always just rebase one more time.
However, taking out the auto-commit wouldn't pain me too much if
others want it that way. It would be somewhat more typing, but at
least makes easy to understand exactly what's going on.
> It would not only save typing, but also help to avoid costly mistakes
> where users, being taught to use "git commit --amend" after editing
> during git-rebase, fire this command automatically after a conflict
> resolution and get two commits accidently squashed.
Yes! Good point. I forgot about this, but I've been bitten by it a
couple of times.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Avery Pennarun @ 2008-07-23 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7viquxjwyf.fsf@gitster.siamese.dyndns.org>
On 7/22/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Avery Pennarun" <apenwarr@gmail.com> writes:
> > Why doesn't "edit" just stage the commit and not auto-commit it at
> > all? That way an amend would *never* be necessary, and rebase
> > --continue would always do a commit -a (if there was anything left to
> > commit). The special case fixed by this patch would thus not be
> > needed.
>
> That would actually be in-line with the way how "rebase --skip" does the
> resetting without asking the user to do so, wouldn't it?
I'm not sure exactly what you mean, but I think with my proposed
change, "rebase --skip" would do "git reset --hard HEAD" while "rebase
--continue" would do "git commit -a", so it would be nice and
symmetrical, where currently it isn't exactly.
Have fun,
Avery
^ permalink raw reply
* git svn throws locale related error when built from source
From: Anton Mostovoy @ 2008-07-23 16:00 UTC (permalink / raw)
To: git
In-Reply-To: <20080722203128.GB5113@blimp.local>
Hi
I built git 1.5.6.3 manually (no package with 1.5.4+ on gutsy), and I am
getting the error below when running 'git svn rebase'.
svn works fine on its own though.
The default locale is set to en_US.UTF-8
svn: error: cannot set LC_ALL locale
svn: error: environment variable LANG is en_US.UTF-8
svn: error: please check that your locale name is correct
I found a workaround that works, but it would be nice to have it work
properly.
$> LANG= git svn rebase"
Thanks in advance.
-Anton
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-23 16:00 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jakub Narebski, git
In-Reply-To: <200807231654.18019.robin.rosenberg.lists@dewire.com>
Hi,
On Wed, 23 Jul 2008, Robin Rosenberg wrote:
> onsdagen den 23 juli 2008 15.18.40 skrev Johannes Schindelin:
>
> > On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >
> > > On Wed, 23 Jul 2008, Johannes Schindelin wrote:
> > > > On Wed, 23 Jul 2008, Jakub Narebski wrote:
> > > >
> > > > Some people prefer to stay anonymous, so I think email is out.
> > > >
> > > > > 04. Which programming languages you are proficient with?
> > > > > (The choices include programming languages used by git)
> > > > > (zero or more: multiple choice)
> > > > > - C, shell, Perl, Python, Tcl/Tk
> > > > > + (should we include other languages, like C++, Java, PHP,
> > > > > Ruby,...?)
> > > >
> > > > Yes, I think this should be a long list.
> > >
> > > I'd rather not have a "laundry list" of languages. I have put C++
> > > because QGit uses it, Java because of egit/jgit, PHP for web
> > > interfaces, Ruby because of GitHub and because of Ruby comminity
> > > choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
> > > JavaScript here. What other languages should be considered?
> >
> > C# at least, since we had one (pretty unsuccessful) attempt at
> > reimplementing Git in it.
>
> What is the reason for the question? Do we want to know what languages
> people would like to contribute to Git in or do we want to know what "kind"
> of programmers are attracted by Git? Making it a long list should make
> it easier to tabulate the responses.
"could contribute" is more appropriate IMHO. Although you might be right
to ask "would like to contribute"... ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-23 16:02 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Jakub Narebski, git, Stephan Beyer
In-Reply-To: <20080723145455.GS2925@dpotapov.dyndns.org>
Hi,
On Wed, 23 Jul 2008, Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 11:53:27AM +0200, Johannes Schindelin wrote:
> >
> > On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >
> >
> > > 11. Why did you choose Git? (if you use Git)
> > > What do you like about using Git?
> > > (free form, not to be tabulated)
> >
> > Again, to avoid hassles with free-form:
> >
> > Mandatory: work, mandatory: open source project I am participating
> > in, speed, scalability, It's What Linus Uses, Other.
>
> If we move away from free-form, it should be much more choices here.
>
> - Ability to work offline
> - Cryptographic authentication of history.
Cryptographically strong integrity check. There is no authentication.
> - Distributed development (pull/push from/to more than one remote repo)
> - Easy to extend functionality through scripting
> - Efficient storage model
> - Elegant design
> - Fast
> - Good community support
> - Rewriting patches before publishing (git rebase, commit --amend)
> - Scalability (Efficient handling of large projects)
> - Strong support for non-linear development
> - Support of wide range of protocols for synchronization.
> ...
Yeah, I would tick all of them, too.
Ciao,
Dscho
^ permalink raw reply
* [FYI PATCH] Added a git search and replace command
From: Sverre Rabbelier @ 2008-07-23 15:36 UTC (permalink / raw)
To: git; +Cc: Sverre Rabbelier
A simple script that uses 'git ls-files' and xargs to
search and replace all the specified files.
---
Not meant for inclusion, just a simple script I wrote up
when I wanted to change a function name in my repository
but didn't want to figure out which magic argument to find
does what I want. Another advantage of using git ls-files
is that it will prevent that any unrevertable changes will
be made (since the script checks if the tree is dirty or
not). I'm sure there's plenty of room for improvement here,
it's probably not portable at all either, so comments are
welcome :).
.gitignore | 1 +
Makefile | 1 +
git-sar.sh | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 63 insertions(+), 0 deletions(-)
create mode 100755 git-sar.sh
diff --git a/.gitignore b/.gitignore
index a213e8e..451cb93 100644
--- a/.gitignore
+++ b/.gitignore
@@ -108,6 +108,7 @@ git-rev-list
git-rev-parse
git-revert
git-rm
+git-sar
git-send-email
git-send-pack
git-sh-setup
diff --git a/Makefile b/Makefile
index b01cf1c..979e9ea 100644
--- a/Makefile
+++ b/Makefile
@@ -252,6 +252,7 @@ SCRIPT_SH += git-sh-setup.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
+SCRIPT_SH += git-sar.sh
SCRIPT_PERL += git-add--interactive.perl
SCRIPT_PERL += git-archimport.perl
diff --git a/git-sar.sh b/git-sar.sh
new file mode 100755
index 0000000..db6317b
--- /dev/null
+++ b/git-sar.sh
@@ -0,0 +1,61 @@
+#!/bin/bash
+
+do_sed () {
+ sed "$2" $3 > $3.replaced
+ mv $3.replaced $3
+}
+
+do_git_find() {
+ # Sanity check
+ if is_dirty_tree
+ then
+ echo "Refusing to work on a dirty tree"
+ fi
+
+ files=`git ls-files "$1"`
+ if test -z "$files"
+ then
+ echo "Your pathspec did not match any files."
+ exit 1
+ fi
+ echo "$files" | xargs -n 1 git-sar --replace $2
+}
+
+is_dirty_tree () {
+ `git diff --quiet`
+ test $? -ne 0
+}
+
+do_show_usage() {
+ echo "usage: git-sar pathspec sed"
+ exit 128
+}
+
+do_main() {
+ # Verify argument size
+ if test "$#" -le 1 -o "$#" -ge 4
+ then
+ do_show_usage
+ fi
+
+ # Two argument form
+ if test "$#" -eq 2
+ then
+ do_git_find "$@"
+ fi
+
+ # Three argument form, we're calling ourselves through sed
+ if test "$#" -eq 3
+ then
+ # Double check if the user typoed or if we are indeed meta-calling
+ if test "$1" != "--replace"
+ then
+ do_show_usage
+ fi
+
+ do_sed "$@"
+ fi
+}
+
+do_main "$@"
+
--
1.5.6.4.570.g052e.dirty
^ permalink raw reply related
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Johannes Schindelin @ 2008-07-23 16:07 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Alexander Litvinov, git
In-Reply-To: <32541b130807230849t42b491b9jf1d6f31bcdd50dac@mail.gmail.com>
Hi,
On Wed, 23 Jul 2008, Avery Pennarun wrote:
> On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > > > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > > > > In short: I can't clone svn repo into git when crlf convertion
> > > > > is activated.
> > > >
> > > > This is a known issue, but since nobody with that itch seems to
> > > > care enough to fix it, I doubt it will ever be fixed.
> > >
> > > That is a bad news for me. Anyway I will spend some time at
> > > holidays during digging this bug.
> >
> > Note that you will have to do your digging using msysGit (i.e. the
> > developer's pack, not the installer for plain Git), since git-svn will
> > be removed from the next official "Windows Git" release, due to lack
> > of fixers.
>
> Presumably cygwin git will work too, right?
Yes.
> Does this known issue apply only to msysGit, or both msys and Cygwin, or
> all versions? ie. could it be debugged on Linux?
You mean the crlf vs git-svn issue? No, yes, yes, yes, and yes.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Johannes Schindelin @ 2008-07-23 16:09 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Dmitry Potapov, git, gitster
In-Reply-To: <32541b130807230853y136f41bdmf221637e35d601c3@mail.gmail.com>
Hi,
On Wed, 23 Jul 2008, Avery Pennarun wrote:
> However, taking out the auto-commit wouldn't pain me too much if
> others want it that way.
IMO the -rc0 cycle is a particularly ill-chosen time to discuss behavior
changes like this.
Hth,
Dscho
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-23 16:15 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20080723145518.GA29035@laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 559 bytes --]
Hi,
On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
> So in short, sparse prefix will be stored in config, core.sparsecheckout.
Do you really think the prefix should be stored anywhere else than the
index?
With core.sparseCheckout you have to introduce a _sh*tload_ of config
loaders.
And with core.sparseCheckout you are at the whim of the user, since
.git/config is _supposed_ to be user-editable.
>From a logical point of view, I'd say that the sparse prefix has nothing
to do with the "configuration" of the local repository.
Ciao,
Dscho
^ permalink raw reply
* git-svn - failed to clone repository
From: Derek Fawcus @ 2008-07-23 16:06 UTC (permalink / raw)
To: git
I tried to create a clone of an svn repository, and it gave
up part way through with the following error:
Incomplete data: Delta source ended unexpectedly at /usr/bin/git-svn line 3858
Looking at the source, this is the call '$reporter->finish-report($pool)'
near the end of gs_do_update.
This is using git 1.5.6 from the etch backports repository.
The repository in question was cocotron, the command being:
git svn clone http://cocotron.googlecode.com/svn -t tags -b branches -T trunk
It seemed to fail at revision 91, the last couple of lines of the command output being:
r90 = <hex I can't be bothered to type unless required> (trunk)
M Foundation/NSStream/NSFileHandle.m
then followed by the above error. Looking at the actual revision
page (http://code.google.com/p/cocotron/source/detail?r=91)
the only thing that stands out as odd is one file claims to be 'too large to diff'.
It's ~900k and if one grabs and diffs by hand, the output is only ~70 lines.
So - is this at all related to the 'known bug' mentioned earlier - stopped on
line 3856 when using line ending mapping (I'm not using such), or is this
something else?
Last, assuming I was to simply grab and apply this changeset by hand,
what would I need to do to fix up metadata so that git-svn could continue
importing the history? There are about 200 changesets in the whole repository.
Thanks,
DF
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Avery Pennarun @ 2008-07-23 16:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Dmitry Potapov, git, gitster
In-Reply-To: <alpine.DEB.1.00.0807231708520.8986@racer>
On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 23 Jul 2008, Avery Pennarun wrote:
> > However, taking out the auto-commit wouldn't pain me too much if
> > others want it that way.
>
> IMO the -rc0 cycle is a particularly ill-chosen time to discuss behavior
> changes like this.
Probably, but it relates to the discussion of the current patch.
Would it be better to change the rebase behaviour now and then
possibly again in the next version, or just leave it as-is for now?
Avery
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Nguyen Thai Ngoc Duy @ 2008-07-23 16:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231713280.8986@racer>
On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
>
> > So in short, sparse prefix will be stored in config, core.sparsecheckout.
>
>
> Do you really think the prefix should be stored anywhere else than the
> index?
>
> With core.sparseCheckout you have to introduce a _sh*tload_ of config
> loaders.
>
> And with core.sparseCheckout you are at the whim of the user, since
> .git/config is _supposed_ to be user-editable.
>
> From a logical point of view, I'd say that the sparse prefix has nothing
> to do with the "configuration" of the local repository.
Well, whatever place. I chose .git/config because I did not want to
introduce a new config place. But then how about .git/sparsecheckout?
>
> Ciao,
> Dscho
>
--
Duy
^ permalink raw reply
* [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Alex Riesen @ 2008-07-22 22:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807222242160.8986@racer>
It is off by default, to avoid scaring people unless they asked to.
---
Johannes Schindelin, Tue, Jul 22, 2008 23:44:50 +0200:
> On Tue, 22 Jul 2008, Alex Riesen wrote:
>
> > @@ -704,9 +707,10 @@ const char *help_unknown_cmd(const char *cmd)
> >
> > if (!main_cmds.cnt)
> > die ("Uh oh. Your system reports no Git commands at all.");
> > + git_config(git_help_config, NULL);
> > best_similarity = similarity(main_cmds.names[0]->name);
> > - if (main_cmds.cnt < 2 || best_similarity <
> > - similarity(main_cmds.names[1]->name)) {
> > + if (autocorrect && (main_cmds.cnt < 2 ||
> > + best_similarity < similarity(main_cmds.names[1]->name))) {
> > if (!*cwd)
> > exit(1);
> > if (chdir(cwd))
>
> This "if" already checks if there is only one candidate. So you should
> just add an inner "if (autocorrect) ... else single = 1;" or some such.
Oh right, stupid me.
> However, I think that the intention of this patch is too much DWIMery,
> which might be good for me (just like my "git add remote" patch), but not
> for the general audience.
Mustn't be good for all (for the "general audience" it is even common
practice to forget to thank. It may be even a sign of bad manners for
it). It is good for me though. And thanks for sharing.
Moved git_config before the calls where current directory is changed:
so that it has the same filesystem context as in normal case. Less
surprises.
help.c | 19 +++++++++++++------
1 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/help.c b/help.c
index 480befe..8b25a55 100644
--- a/help.c
+++ b/help.c
@@ -28,6 +28,7 @@ enum help_format {
HELP_FORMAT_WEB,
};
+static int autocorrect;
static int show_all = 0;
static enum help_format help_format = HELP_FORMAT_MAN;
static struct option builtin_help_options[] = {
@@ -269,6 +270,8 @@ static int git_help_config(const char *var, const char *value, void *cb)
}
if (!prefixcmp(var, "man."))
return add_man_viewer_info(var, value);
+ if (!strcmp(var, "help.autocorrect"))
+ autocorrect = git_config_bool(var,value);
return git_default_config(var, value, cb);
}
@@ -683,7 +686,7 @@ static int levenshtein_compare(const void *p1, const void *p2)
const char *help_unknown_cmd(const char *cmd)
{
- int i, best_similarity = 0;
+ int i, best_similarity = 0, n;
char cwd[PATH_MAX];
if (!getcwd(cwd, sizeof(cwd))) {
@@ -691,6 +694,7 @@ const char *help_unknown_cmd(const char *cmd)
cwd[0] = '\0';
}
+ git_config(git_help_config, NULL);
load_command_list();
ALLOC_GROW(main_cmds.names, main_cmds.cnt + other_cmds.cnt,
main_cmds.alloc);
@@ -705,8 +709,11 @@ const char *help_unknown_cmd(const char *cmd)
if (!main_cmds.cnt)
die ("Uh oh. Your system reports no Git commands at all.");
best_similarity = similarity(main_cmds.names[0]->name);
- if (main_cmds.cnt < 2 || best_similarity <
- similarity(main_cmds.names[1]->name)) {
+ n = 1;
+ while (n < main_cmds.cnt &&
+ best_similarity == similarity(main_cmds.names[n]->name))
+ ++n;
+ if (autocorrect && n == 1) {
if (!*cwd)
exit(1);
if (chdir(cwd))
@@ -721,10 +728,10 @@ const char *help_unknown_cmd(const char *cmd)
fprintf(stderr, "git: '%s' is not a git-command. See 'git --help'.\n", cmd);
if (best_similarity < 6) {
- fprintf(stderr, "\nDid you mean one of these?\n");
+ fprintf(stderr, "\nDid you mean %s?\n",
+ n < 2 ? "this": "one of these");
- for (i = 0; i < main_cmds.cnt && best_similarity ==
- similarity(main_cmds.names[i]->name); i++)
+ for (i = 0; i < n; i++)
fprintf(stderr, "\t%s\n", main_cmds.names[i]->name);
}
--
1.6.0.rc0.48.ga184
^ permalink raw reply related
* Re: [PATCH] perl/Makefile: update NO_PERL_MAKEMAKER section
From: Brandon Casey @ 2008-07-23 16:22 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20080722230940.GK32184@machine.or.cz>
Petr Baudis wrote:
> On Tue, Jul 22, 2008 at 04:15:41PM -0500, Brandon Casey wrote:
>> The perl modules must be copied to blib/lib so they are available for
>> testing.
>>
>> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
>
> I don't understand why do you need to do this; perl.mak should do this
> on its own during project-wide make all.
perl.mak is auto-generated by one of two methods in perl/Makefile. This
patch modifies the 'NO_PERL_MAKEMAKER' section. Currently 'make all', when
NO_PERL_MAKEMAKER is set, does nothing, and looks like:
$ cat perl.mak
all:
:
install:
mkdir -p ...
With this patch it looks like:
$ cat perl.mak
all: private-Error.pm Git.pm
mkdir -p blib/lib
rm -f blib/lib/Git.pm; cp Git.pm blib/lib/
rm -f blib/lib/Error.pm; cp private-Error.pm blib/lib/Error.pm
install:
mkdir -p ...
-brandon
^ permalink raw reply
* [PATCH] Wait help.autocorrect deciseconds before running corrected command
From: Alex Riesen @ 2008-07-23 16:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vsku1jz4u.fsf@gitster.siamese.dyndns.org>
Suggested by Junio, so he has a chance to hit Ctrl-C.
---
Junio C Hamano, Wed, Jul 23, 2008 01:08:17 +0200:
>
> Please make autocorrect not a binary but optionally the number of
> deciseconds before it continues, so that I have a chance to hit ^C ;-)
on top of the last patch.
Documentation/config.txt | 9 +++++++++
help.c | 7 ++++++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e784805..5bf1d0d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -771,6 +771,15 @@ help.format::
Values 'man', 'info', 'web' and 'html' are supported. 'man' is
the default. 'web' and 'html' are the same.
+help.autocorrect::
+ Automatically correct and execute mistyped commands after
+ waiting for the given number of deciseconds (0.1 sec). If more
+ than one command can be deduced from the entered text, nothing
+ will be executed. If the value of this option is negative,
+ the corrected command will be executed immediately. If the
+ value is 0 - the command will be just shown but not executed.
+ This is the default.
+
http.proxy::
Override the HTTP proxy, normally configured using the 'http_proxy'
environment variable (see linkgit:curl[1]). This can be overridden
diff --git a/help.c b/help.c
index 8b25a55..4d52781 100644
--- a/help.c
+++ b/help.c
@@ -271,7 +271,7 @@ static int git_help_config(const char *var, const char *value, void *cb)
if (!prefixcmp(var, "man."))
return add_man_viewer_info(var, value);
if (!strcmp(var, "help.autocorrect"))
- autocorrect = git_config_bool(var,value);
+ autocorrect = git_config_int(var,value);
return git_default_config(var, value, cb);
}
@@ -722,6 +722,11 @@ const char *help_unknown_cmd(const char *cmd)
"which does not exist.\n"
"Continuing under the assumption that you meant '%s'\n",
cmd, main_cmds.names[0]->name);
+ if (autocorrect > 0) {
+ fprintf(stderr, "in %0.1f seconds automatically...\n",
+ (float)autocorrect/10.0);
+ poll(NULL, 0, autocorrect * 100);
+ }
return main_cmds.names[0]->name;
}
--
1.6.0.rc0.50.g9c23
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: Junio C Hamano @ 2008-07-23 16:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, git
In-Reply-To: <200807231508.42334.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>
>> Some people prefer to stay anonymous, so I think email is out.
>>
>> > 04. Which programming languages you are proficient with?
>> > (The choices include programming languages used by git)
>> > (zero or more: multiple choice)
>> > - C, shell, Perl, Python, Tcl/Tk
>> > + (should we include other languages, like C++, Java, PHP,
>> > Ruby,...?)
>>
>> Yes, I think this should be a long list.
>
> I'd rather not have a "laundry list" of languages. I have put C++
> because QGit uses it, Java because of egit/jgit, PHP for web
> interfaces, Ruby because of GitHub and because of Ruby comminity
> choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
> JavaScript here. What other languages should be considered?
I refrained saying this in my initial response, but my initial reaction
was "Why are you even asking this?".
Yes, "getting to know you" demographics are customary done in surveys, and
you kept it to the minimum which is also good, but I do not think this
particular question is very interesting. For one thing, the question
assumes the participant is a programmer, and we are giving an impression
that we are interested in better programmers. Do we *still* require users
to be a programmer to use git? I do not think so. Having to answer "none
of these" to this question would make you feel unnecessarily bad, even if
you are not a programmer and you know at the intellectual level that it is
not your flaw not to be proficient in any.
Asking about geographic location and preferred human languages might help
to gauge what l10n are desired for GUIs, but even there, don't forget that
we are no company. We do not research markets and translate messages to
missing languages, however popular, before being asked. That's not how we
operate. So the result of these questions will be mainly to satisfy our
curiosity, nothing more.
"What kind of content do you track" might also be an equally interesting
question. It also falls into the curiosity department, though.
> I'm not sure about having multiple choice vs. free-form question here.
> Multiple choice is easier to analyze, especially if one would want
> histogram of replies...
And when you expect very many respondents, (1) you cannot afford to
free-form; and (2) statistics over multiple choices, as long as choices
are well seeded, will give you a good enough overview picture.
> Again: free form has some hassles, but so does coming up with good
> choice of fixed answers in multiple choice question.
You need to do at least one or the other, and I do not think there is any
way to avoid that. Without a good choices, histogram would become useless
(not necessarily because the answer will be dominated by "Other", but the
seeing the choices tends to set the frame of mind when/before somebody
answers the question). With free-form, you will spend the rest of your
life analyzing to get any useful insight.
^ permalink raw reply
* Re: [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Johannes Schindelin @ 2008-07-23 16:44 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080722222510.GA4474@blimp.local>
Hi,
On Wed, 23 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Tue, Jul 22, 2008 23:44:50 +0200:
> > However, I think that the intention of this patch is too much DWIMery,
> > which might be good for me (just like my "git add remote" patch), but
> > not for the general audience.
>
> Mustn't be good for all
You meant "needn't"? It is good for me ;-)
> And thanks for sharing.
You're welcome.
> + n = 1;
> + while (n < main_cmds.cnt &&
> + best_similarity == similarity(main_cmds.names[n]->name))
> + ++n;
Mini-nit: you never ask for the value of n, only if it is 1 or larger. So
you do not need to count...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Alex Riesen @ 2008-07-23 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <7vr69lihkt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Wed, Jul 23, 2008 02:12:50 +0200:
> >> Otherwise, if you really want to tell at compile time,I think for clarity
> >> you have to introduce another #define, since NO_TRUSTABLE_FILEMODE
> >> definitely says something different than CTIME_IS_USELESS.
> >
> > I had that at first (NO_DEPENDABLE_CTIME, than IGNORE_CTIME), than
> > deemed it excessive.
>
> Why is it excessive? My initial reaction was "what does trustable
> filemode nor trust_executable_bit has anything to do with ctime". Please
> explain.
Because exactly the file mode (the executable bit) is the reason for
checking ctime. Otherwise there is no point: Git doesn't save any
other data which when changed cause a ctime update. And exactly the
file mode is completely broken on that cygwin thing. Which is
precisely pointed by NO_TRUSTABLE_FILEMODE. Hence - just it.
^ permalink raw reply
* [PATCH] git-am: Add colon before the subject that is printed out as being applied
From: Stephan Beyer @ 2008-07-23 16:46 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Linus Torvalds, Stephan Beyer
git-am output can be confusing, because the subject of the applied
patch can look like the rest of a sentence starting with "Applying".
The added colon should make this clearer.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Hi,
Linus added single quotes to applypatch in 610968199,
writing:
Add quotes around the subject line that we print out as being applied.
My brain just flipped when it tried to read the "Applying" as part
of the explanation of the patch, and the sentence didn't make any
sense. The quotes make it clear what's going on.
I think he is right ;)
Of course, it's debatable whether
Applying: foo
or
Applying "foo"
or
Applying 'foo'
may be the best. I don't really care :)
The main reason I chose the colon variant is because the change in t4151
is less ugly.
Another reason: thinking of "ambiguous" subjects:
- Applying "Remove "string" from foo.c"
- Applying 'Remove 'string' from foo.sh'
- Applying: foo.c: Remove "string"
Regards,
Stephan
git-am.sh | 2 +-
t/t4151-am-abort.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 7864b5f..f4abd9d 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -456,7 +456,7 @@ do
stop_here $this
fi
- printf 'Applying %s\n' "$FIRSTLINE"
+ printf 'Applying: %s\n' "$FIRSTLINE"
case "$resolved" in
'')
diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index 249093b..f45ab0a 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -43,7 +43,7 @@ do
test_expect_success "am$with3 --skip continue after failed am$with3" '
test_must_fail git-am$with3 --skip >output &&
- test "$(grep "^Applying" output)" = "Applying 6" &&
+ test "$(grep "^Applying" output)" = "Applying: 6" &&
test_cmp file-2-expect file-2 &&
test ! -f .git/rr-cache/MERGE_RR
'
--
1.6.0.rc0.102.ga1791
^ permalink raw reply related
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Stephan Beyer @ 2008-07-23 16:47 UTC (permalink / raw)
To: Olivier Marin
Cc: Junio C Hamano, Theodore Tso, Nanako Shiraishi,
Johannes Schindelin, René Scharfe, Joe Fiorini, git,
Jari Aalto
In-Reply-To: <48874617.3010108@free.fr>
Hi,
Olivier Marin wrote:
> > The reason of my question was that I *blindly* incorporated the change into
> > sequencer to make it able to work on a dirty working tree and thus to be
> > able to migrate am onto it without losing the ability to apply patches
> > on a dirty working tree....
>
> Are you talking about your seq-proto-dev3 branch?
Right, and your suggested changes are right, too, and I've incorporated
them yesterday (with an --allow-dirty option) but I hadn't commited them...
(Hence, not pushed.)
> > Now, because t4151 does not pass, I am wondering what's the best thing
> > I could do...
Well, that was solved...
The problem was that the additional "HEAD" (that made t4151 work), resulted
in untracked files in some test cases of sequencer and rebase-i. Those made
merges fail, because these merges would overwrite these files. So the
merges failed, and the test cases failed.
I've solved this with the trick that the "HEAD" argument is only added if
--allow-dirty is set (and git-am uses --allow-dirty of course).
This is perhaps not the cleanest way but seemed to be far more better
than forcing overwrites on merges (checkouts, etc.).
> Ah, you should change "Applying 6" with "Applying \"6\"" in t4151-am-abort.sh
> too.
I btw wondered if the quotes are useful in original am.
Well, I've just sent a patch adding a colon (instead of quotes). Let's
see ;)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-23 16:55 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0807230921m114f5ae0ybfec4917432d6dc7@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1185 bytes --]
Hi,
On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
> >
> > > So in short, sparse prefix will be stored in config,
> > > core.sparsecheckout.
> >
> > Do you really think the prefix should be stored anywhere else than the
> > index?
> >
> > With core.sparseCheckout you have to introduce a _sh*tload_ of config
> > loaders.
> >
> > And with core.sparseCheckout you are at the whim of the user, since
> > .git/config is _supposed_ to be user-editable.
> >
> > From a logical point of view, I'd say that the sparse prefix has
> > nothing to do with the "configuration" of the local repository.
>
> Well, whatever place. I chose .git/config because I did not want to
> introduce a new config place. But then how about .git/sparsecheckout?
No, I did mean the index. This is an attribute of the index: either it is
sparsely checked out or not. You can even have multiple indices
(switching between them by setting GIT_INDEX_FILE) which have different
prefixes.
Ciao,
Dscho "who seems to recall that the first series was much less intrusive"
^ permalink raw reply
* Re: [PATCH] Wait help.autocorrect deciseconds before running corrected command
From: Johannes Schindelin @ 2008-07-23 16:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20080723164109.GA5283@blimp.local>
Hi,
On Wed, 23 Jul 2008, Alex Riesen wrote:
> + if (autocorrect > 0) {
> + fprintf(stderr, "in %0.1f seconds automatically...\n",
> + (float)autocorrect/10.0);
> + poll(NULL, 0, autocorrect * 100);
> + }
What? No countdown? No fancy sounds when the time ran up?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Johannes Schindelin @ 2008-07-23 16:59 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <20080723164614.GB5283@blimp.local>
Hi,
On Wed, 23 Jul 2008, Alex Riesen wrote:
> Because exactly the file mode (the executable bit) is the reason for
> checking ctime.
But ctime is broken on Windows. Because ctime is supposed to change
whenever the _inode_ changes.
You have to admit that saying "I ignore the ctime because the executable
bit is broken" must leave the reader puzzled.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Stephan Beyer @ 2008-07-23 17:01 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <20080723145455.GS2925@dpotapov.dyndns.org>
Hi,
Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 11:53:27AM +0200, Johannes Schindelin wrote:
> > On Wed, 23 Jul 2008, Jakub Narebski wrote:
> > > 11. Why did you choose Git? (if you use Git)
> > > What do you like about using Git?
> > > (free form, not to be tabulated)
> >
> > Again, to avoid hassles with free-form:
> >
> > Mandatory: work, mandatory: open source project I am participating
> > in, speed, scalability, It's What Linus Uses, Other.
>
> If we move away from free-form, it should be much more choices here.
>
> - Ability to work offline
> - Cryptographic authentication of history.
> - Distributed development (pull/push from/to more than one remote repo)
> - Easy to extend functionality through scripting
> - Efficient storage model
> - Elegant design
> - Fast
> - Good community support
> - Rewriting patches before publishing (git rebase, commit --amend)
> - Scalability (Efficient handling of large projects)
> - Strong support for non-linear development
> - Support of wide range of protocols for synchronization.
> ...
Heh, I can imagine git users reading that survey and thinking
"What? Git allows me to rewrite patches before publishing?
And it provides cryptographic integrity? Sounds good. *click*"
Nevertheless, the list is fine ;)
Perhaps also: "Good reputation".
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Junio C Hamano @ 2008-07-23 17:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807230203350.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> However, if you want to avoid CRs to _enter_ the repository, when you have
> a lot of binary files tracked, you _do_ want to force all repositories to
> crlf=input.
If you are on a sane system, you do not even want to pay the price of
conversion. Only people on systems with CRLF line endings should pay the
price (because your aim is to convert on such systems). Are we throwing
that out of the window when the project decides to use gitattributes?
How about setting autocrlf automatically on mingw/msys/cygwin versions,
perhaps via templates or a patch to init-db? Would that, combined with
user education, be a viable alternative?
^ 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