* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Erik Faye-Lund @ 2011-01-14 9:55 UTC (permalink / raw)
To: Tor Arntsen; +Cc: JT Olds, Jeff King, git, torvalds
In-Reply-To: <AANLkTi=PTgmOSC7pRLjujO5fi9Wdp69Jmj4zCkhGSYSz@mail.gmail.com>
(CC'ed Linus, as he wrote mailinfo's sanity-checking -- sorry, forgot
to actually CC him the first time)
On Fri, Jan 14, 2011 at 10:24 AM, Tor Arntsen <tor@spacetec.no> wrote:
> On Fri, Jan 14, 2011 at 09:56, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>> On Fri, Jan 14, 2011 at 9:45 AM, Tor Arntsen <tor@spacetec.no> wrote:
>>> I think I've mentioned this before in another thread, but first/last
>>> name isn't universal, not even within countries where it's the common
>>> form. When I was as student there was a fellow student from another
>>> scandinavian country and his legal, full name consisted of a single
>>> letter.
>>>
>>
>> I'm curious, what Scandinavian country was this? Because as a
>> Norwegian, I know a lot of people from all Scandinavian country, yet
>> I've never heard of such names. In Norway, I the shortest legal name
>> I've ever heard of was five characters.
>
> Sweden (I'm Norwegian too - this guy was a Swede studying in Norway).
> Admittedly I have only that single example, and it was back in the
> late seventies. His name was accepted as legal by Statens Lånekasse
> (bank for students) and when the loans arrived his single-letter name
> would be found at the very end of the long lists of wide listing-paper
> printouts from the bank that was stiched up on the billboard wall
> outside the administration offices. The loans arrived a couple of
> times per year but we always had to go looking - the rest of us were
> just amazed that we could really find that single letter down there
> and he wasn't bs'ing the rest of us about his name.
>
> I'm not sure why there's a 3-letter limit on git author names.. but I
> would suggest it should be set down to 1 letter minimum.. below that
> would, I think, be overdoing it..
>
Linus, you wrote sanity_check (from 2744b23). Do you remember if there
were any specific reason for the minimum length of 3 of an
author-name? It seems that in Sweden, legal names can be even a single
letter (see Tor's comment)...
^ permalink raw reply
* [PATCH] Optionally parse author information
From: Ramkumar Ramachandra @ 2011-01-14 10:16 UTC (permalink / raw)
To: Love Hörnquist Åstrand
Cc: Jonathan Nieder, Joe Corneli, Git List, Michael Haggerty
In-Reply-To: <F0299861-B36C-459C-972E-856212A92615@kth.se>
When creating a new commit, instead of picking up the SVN author from
the committer's email, pick it up from the author's email, when
possible. Also add a new command-line switch '--ignore-author' to
force older behavior for backward compatibilty.
Noticed-by: Joe Corneli <holtzermann17@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
git2svn | 25 +++++++++++++++++++------
1 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/git2svn b/git2svn
index 2380775..8ef55f1 100755
--- a/git2svn
+++ b/git2svn
@@ -36,7 +36,7 @@ use Pod::Usage;
my $IN;
my $OUT;
-my ($help, $verbose, $keeplogs, $no_load);
+my ($help, $verbose, $keeplogs, $no_load, $ignore_author);
# svn
my $svntree = "repro";
@@ -200,6 +200,7 @@ $result = GetOptions ("git-branch=s" => \$branch,
"svn-prefix=s" => \$basedir,
"keep-logs" => \$keeplogs,
"no-load" => \$no_load,
+ "ignore-author" => \$ignore_author,
"verbose+" => \$verbose,
"help" => \$help) or pod2usage(2);
@@ -261,12 +262,15 @@ COMMAND: while (!eof(IN)) {
$commit{Mark} = $1;
$next = next_line($IN);
}
- if ($next =~ m/author +(.*)/) {
- $commit{Author} = $1;
+ if ($next =~ m/author +(.+) +<([^>]+)> +(\d+) +[+-](\d+)$/) {
+ $commit{AuthorName} = $1;
+ $commit{AuthorEmail} = $2;
+ $commit{AuthorWhen} = $3;
+ $commit{AuthorTZ} = $4;
$next = next_line($IN);
}
unless ($next =~ m/committer +(.+) +<([^>]+)> +(\d+) +[+-](\d+)$/) {
- die "missing comitter: $_";
+ die "missing committer: $_";
}
$commit{CommitterName} = $1;
@@ -291,11 +295,15 @@ COMMAND: while (!eof(IN)) {
strftime("%Y-%m-%dT%H:%M:%S.000000Z",
gmtime($commit{CommitterWhen}));
- my $author = "(no author)";
+ my $author = "git2svn-dump";
if ($commit{CommitterEmail} =~ m/([^@]+)/) {
$author = $1;
}
- $author = "git2svn-dump" if ($author eq "(no author)");
+ unless ($ignore_author) {
+ if ($commit{AuthorEmail} =~ m/([^@]+)/) {
+ $author = $1;
+ }
+ }
my $props = "";
$props .= prop("svn:author", $author);
@@ -486,6 +494,11 @@ match the default GIT branch (master).
Don't load the svn repository or update the syncpoint tagname.
+=item B<--ignore-author>
+
+Ignore "author" lines in the fast-import stream. Use "committer"
+information instead.
+
=item B<--keep-logs>
Don't delete the logs in $CWD/.data on success.
--
1.7.4.rc1.7.g2cf08.dirty
^ permalink raw reply related
* How does 'git notes --ref' work?
From: Edwin Kempin @ 2011-01-14 10:21 UTC (permalink / raw)
To: git
How does 'git notes --ref' work? If I try
'git notes --ref refs/meta/reject-commits add -m "reject" HEAD'
then the note is added to 'refs/notes/refs/meta/reject-commits' and not as
expected to 'refs/meta/reject-commits'.
The description of the --ref option says [1]:
"The ref is taken to be in refs/notes/ if it is not qualified."
What is a qualified ref?
Thanks, Edwin
[1] http://www.kernel.org/pub/software/scm/git/docs/git-notes.html
^ permalink raw reply
* Re: How does 'git notes --ref' work?
From: Johan Herland @ 2011-01-14 10:49 UTC (permalink / raw)
To: Edwin Kempin; +Cc: git
In-Reply-To: <AANLkTimL137aFt2dyvdHxTMUjB4diwJQG-FQiYEK8tVJ@mail.gmail.com>
On Friday 14 January 2011, Edwin Kempin wrote:
> How does 'git notes --ref' work? If I try
> 'git notes --ref refs/meta/reject-commits add -m "reject" HEAD'
> then the note is added to 'refs/notes/refs/meta/reject-commits' and
> not as expected to 'refs/meta/reject-commits'.
>
> The description of the --ref option says [1]:
> "The ref is taken to be in refs/notes/ if it is not qualified."
> What is a qualified ref?
A qualified ref (in this context) is one that starts with refs/notes. If
it doesn't start with refs/notes, then refs/notes is prepended to it.
This is a restriction we put in place to make sure the notes
infrastructure didn't edit (i.e. damage) any refs outside the
refs/notes/ namespace.
We will probably remove this restriction in a future Git version. Until
then, please keep your notes within the refs/notes/ namespace.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: noob question
From: Thomas Rast @ 2011-01-14 11:10 UTC (permalink / raw)
To: Harry Johnson; +Cc: git
In-Reply-To: <AANLkTinU---Bw5nWFXr7psSyZEty=awihPrDGqNX916O@mail.gmail.com>
Harry Johnson wrote:
>
> I have used git-svn to create a git repo from our subversion repo. I
> have done this as user foo which is just an account that is used for
> doing central builds. I have then cloned this as repo as myself,
> harry. My thought is that the repo owned by foo would be a central
> repo that all of the developers, including myself, could clone and to
> which we could then 'git push' our changes.
[...]
> when checking the git log is that while the changes I made and checked
> into my repo clearly showed me as the author, the same changes after
> being pushed to foo's repo showed a different author.
>
> So two things.. First should the author have been preserved? How can I
> make sure that it is?
Yes, absolutely, and since the author is encoded in the commit objects
it's impossible to change it without also changing the commit sha1s.
Can you spell your experiments in actual commands and output snippets
so we can see what happened?
Did you ever run 'git svn dcommit', 'git rebase', 'git commit --amend'
or similar in foo's repo? All of these rewrite commits. As part of
their rewriting they set the *committer* to the identity of the
current user. 'git svn dcommit' sets author&committer to the identity
coming back from SVN.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: How does 'git notes --ref' work?
From: Edwin Kempin @ 2011-01-14 11:14 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <201101141149.38778.johan@herland.net>
Thanks for the clarification.
^ permalink raw reply
* [PATCH] fix git-parse-remote.sh for remotes that contain slashes
From: Stefan Naewe @ 2011-01-14 11:36 UTC (permalink / raw)
To: git; +Cc: Stefan Naewe
In-Reply-To: <20110114090645.GA13060@pengutronix.de>
Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
---
git-parse-remote.sh | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 5f47b18..7cf204e 100644
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -7,8 +7,12 @@ GIT_DIR=$(git rev-parse -q --git-dir) || :;
get_data_source () {
case "$1" in
*/*)
- echo ''
- ;;
+ if test "$(git config --get "remote.$1.url")"
+ then
+ echo config
+ else
+ echo ''
+ fi ;;
.)
echo self
;;
--
1.7.3.5
^ permalink raw reply related
* Re: weird github capitalization problem
From: Torsten Bögershausen @ 2011-01-14 12:11 UTC (permalink / raw)
To: Andreas Stricker; +Cc: bolfo, git, tboegi
In-Reply-To: <4D26DA12.50002@futurelab.ch>
On 07.01.11 10:17, Andreas Stricker wrote:
> Am 04.01.11 14:04, schrieb bolfo:
>> I first installed everything on my laptop, coded some stuff and then pushed
>> to github. Apparently something went wrong because there was a new
>> directory, while at first the directory was OurProjectsources, there now was
>> a new directory called OurProjectSources. Weird since my local directory has
>> the s not capitalized.
>
>> I work on a windows PC while the original author works on a Mac, could this
>> be the problem?
>
> Yes, Mac OSX HFS+ filesystem ignores the case by default (you'll need
> to reformat to change this). So OurProjectSources and OurProjectsources
> both refers to the same directory on Mac OS X. On Linux there are two
> different directories
>
> This frequently causes issues here too. An example:
>
> me@mac:t $ git init r
> Initialized empty Git repository in /private/tmp/t/r/.git/
> me@mac:r (master) $ mkdir OurProjectsources
> me@mac:r (master) $ touch OurProjectsources/a
> me@mac:r (master) $ git add OurProjectsources/a
> me@mac:r (master) $ git commit -m "initial import"
> [master (root-commit) c2cb2f3] initial import
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 OurProjectsources/a
> me@mac:r (master) $ mv OurProjectsources/ OurProjectSources
> me@mac:r (master) $ touch OurProjectSources/b
> me@mac:r (master) $ git add OurProjectSources/b
> me@mac:r (master) $ git commit -m "added b"
> [master 4de780c] added b
> 0 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 OurProjectSources/b
> me@mac:r (master) $ git stat
> # On branch master
> nothing to commit (working directory clean)
> me@mac:r (master) $ scp -r .git linux:t.git
> me@mac:r (master) $ ssh linux
>
> me@linux:~ $ git clone t.git/
> Initialized empty Git repository in /home/me/t/.git/
> me@linux:~ $ cd t
> me@linux:~/t $ ls
> OurProjectsources OurProjectSources
> me@linux:~/t $ find *
> OurProjectsources
> OurProjectsources/a
> OurProjectSources
> OurProjectSources/b
>
> And there it is, our mess. The mac user accidentally created
> two different directories but didn't see them.
>
> ~/Andy
>
The following is on next from git.git:
(And more commits fixing more core.ignorecase issues)
You might give it a try.
HTH
/Torsten
commit 50906e04e8f48215b0b09841686709b92a2ab2e4
Author: Joshua Jensen <jjensen@workspacewhiz.com>
Date: Sun Oct 3 09:56:46 2010 +0000
Support case folding in git fast-import when core.ignorecase=true
When core.ignorecase=true, imported file paths will be folded to match
existing directory case.
Signed-off-by: Joshua Jensen <jjensen@workspacewhiz.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: Presenting myself to the community and GSoC 2011
From: Michael J Gruber @ 2011-01-14 12:18 UTC (permalink / raw)
To: João Paulo Melo de Sampaio; +Cc: GIT Mailing List
In-Reply-To: <AANLkTimMhKDimy5pUfT7+cQraU1x470WJ0OWgZBwjdit@mail.gmail.com>
João Paulo Melo de Sampaio venit, vidit, dixit 14.01.2011 01:43:
> Hello, people.
>
> I intend to present myself to the community here. I'll keep it as
> short as possible.
Welcome and bem-vindo, João!
The next release (1.7.4) is on the doorsteps, after that the usual
development process will kick in again.
Checking out git.git, getting to know the build process and reading
Documentation/SubmittingPatches in git.git are good first steps for a
prospective contributor. If you do this and follow the list then ideas
for your first fixes and contributions will come up automatically.
Getting a few patches accepted in git.git is not required before a GSoC
application but its the best way of getting to know the project and the
(developers') community (and for us to get to know you). It can also
give you an idea about what area of Git to focus on for GSoC - if you
still want to stick with us by then ;)
Cheers,
Michael
^ permalink raw reply
* core.whitespace space-in-indent feature request
From: Victor Engmark @ 2011-01-14 12:40 UTC (permalink / raw)
To: git
Hi all,
I couldn't find this mentioned anywhere, but it would be useful for
languages where you typically want only tab characters in indentation,
like makefiles. Would be equivalent or similar to indent-with-non-tab
and tabwidth=1.
--
Victor Engmark
^ permalink raw reply
* [PATCH] handle rename of case only, for windows
From: Tim Abell @ 2011-01-14 13:41 UTC (permalink / raw)
To: git
Hi folks,
I've never contributed to git before so be gentle :-)
Would someone have the time to help me get this patch into mailine git?
I tripped over a failure to rename files on windows when only the case
has changed. I've created a patch which fixes it for me and doesn't seem
to break on linux or windows. I also created a test to demonstrate the
issue (part of this patch). This test passes on linux and fails on
windows before my patch for mv.c is applied, and passes on both windows
and linux for me after my patch is applied.
The problem with changing the case of a file happens because git mv
checks if the destination filename exists before performing a
move/rename, and on windows lstat reports that the destination file
*does* already exist because it ignores case for this check and
semi-erroneously finds the source file.
The way I've attempted to fix it in my patch is by checking if the inode
of the source and destination are the same before deciding to fail with
a "destination exists" error.
When using "git mv" it is possible to work around the error by using
--force.
I've also seen a problem with windows users pulling from remotes where a
case only rename has been performed which is more problematic as you
have to tell every user how to handle the issue. I'm not sure if I've
managed to fix that case or not.
The fault exists in both the current cygwin git and the current msysgit,
so I figured it would be good to get a patch to upstream (you) so that
it could work everywhere.
I found an email from Linus relating to this issue here:
http://marc.info/?l=git&m=120612172706823 so it's a known problem.
Thanks
Tim Abell
---
builtin/mv.c | 33 ++++++++++++++++++++++-----------
t/t7001-mv.sh | 9 +++++++++
2 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 93e8995..6bb262e 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -63,6 +63,7 @@ int cmd_mv(int argc, const char **argv, const char
*prefix)
const char **source, **destination, **dest_path;
enum update_mode { BOTH = 0, WORKING_DIRECTORY, INDEX } *modes;
struct stat st;
+ struct stat src_st;
struct string_list src_for_dst = STRING_LIST_INIT_NODUP;
git_config(git_default_config, NULL);
@@ -165,17 +166,27 @@ int cmd_mv(int argc, const char **argv, const char
*prefix)
} else if (cache_name_pos(src, length) < 0)
bad = "not under version control";
else if (lstat(dst, &st) == 0) {
- bad = "destination exists";
- if (force) {
- /*
- * only files can overwrite each other:
- * check both source and destination
- */
- if (S_ISREG(st.st_mode) ||
S_ISLNK(st.st_mode)) {
- warning("%s; will overwrite!",
bad);
- bad = NULL;
- } else
- bad = "Cannot overwrite";
+ /* If we are on a case insensitive files= system
(windows) http://is.gd/kyxgg
+ * and we are only changing the case of the file
then lstat for the
+ * destination will return != 0 because it sees
the source file.
+ * To prevent this causing failure, lstat is
used to get the inode of the src
+ * and see if it's actually the same file.
+ */
+ lstat(src, &src_st); //get file serial number
(inode) for source
+ #warning("src inode: %s, dst inode: %s",
src_st.st_ino, st.st_ino);
+ if (src_st.st_ino != st.st_ino) {
+ bad = "destination exists";
+ if (force) {
+ /*
+ * only files can overwrite each
other:
+ * check both source and
destination
+ */
+ if (S_ISREG(st.st_mode) ||
S_ISLNK(st.st_mode)) {
+ warning("%s; will
overwrite!", bad);
+ bad = NULL;
+ } else
+ bad = "Cannot
overwrite";
+ }
}
} else if (string_list_has_string(&src_for_dst, dst))
bad = "multiple sources for the same target";
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index a845b15..95146bf 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -255,4 +255,13 @@ test_expect_success SYMLINKS 'git mv should
overwrite file with a symlink' '
rm -f moved symlink
+test_expect_success 'git mv should not fail when only changing case' '
+
+ rm -fr .git &&
+ git init &&
+ >foo.txt &&
+ git add foo.txt &&
+ git mv foo.txt Foo.txt
+'
+
test_done
--
1.5.6.5
^ permalink raw reply related
* [PATCH] handle rename of case only, for windows
From: Tim Abell @ 2011-01-14 13:44 UTC (permalink / raw)
To: git
Hi folks,
I've never contributed to git before so be gentle :-)
Would someone have the time to help me get this patch into mailine git?
I tripped over a failure to rename files on windows when only the case
has changed. I've created a patch which fixes it for me and doesn't seem
to break on linux or windows. I also created a test to demonstrate the
issue (part of this patch). This test passes on linux and fails on
windows before my patch for mv.c is applied, and passes on both windows
and linux for me after my patch is applied.
The problem with changing the case of a file happens because git mv
checks if the destination filename exists before performing a
move/rename, and on windows lstat reports that the destination file
*does* already exist because it ignores case for this check and
semi-erroneously finds the source file.
The way I've attempted to fix it in my patch is by checking if the inode
of the source and destination are the same before deciding to fail with
a "destination exists" error.
When using "git mv" it is possible to work around the error by using
--force.
I've also seen a problem with windows users pulling from remotes where a
case only rename has been performed which is more problematic as you
have to tell every user how to handle the issue. I'm not sure if I've
managed to fix that case or not.
The fault exists in both the current cygwin git and the current msysgit,
so I figured it would be good to get a patch to upstream (you) so that
it could work everywhere.
I found an email from Linus relating to this issue here:
http://marc.info/?l=git&m=120612172706823 so it's a known problem.
Thanks
Tim Abell
---
builtin/mv.c | 33 ++++++++++++++++++++++-----------
t/t7001-mv.sh | 9 +++++++++
2 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 93e8995..6bb262e 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -63,6 +63,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
const char **source, **destination, **dest_path;
enum update_mode { BOTH = 0, WORKING_DIRECTORY, INDEX } *modes;
struct stat st;
+ struct stat src_st;
struct string_list src_for_dst = STRING_LIST_INIT_NODUP;
git_config(git_default_config, NULL);
@@ -165,17 +166,27 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
} else if (cache_name_pos(src, length) < 0)
bad = "not under version control";
else if (lstat(dst, &st) == 0) {
- bad = "destination exists";
- if (force) {
- /*
- * only files can overwrite each other:
- * check both source and destination
- */
- if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
- warning("%s; will overwrite!", bad);
- bad = NULL;
- } else
- bad = "Cannot overwrite";
+ /* If we are on a case insensitive files= system (windows) http://is.gd/kyxgg
+ * and we are only changing the case of the file then lstat for the
+ * destination will return != 0 because it sees the source file.
+ * To prevent this causing failure, lstat is used to get the inode of the src
+ * and see if it's actually the same file.
+ */
+ lstat(src, &src_st); //get file serial number (inode) for source
+ #warning("src inode: %s, dst inode: %s", src_st.st_ino, st.st_ino);
+ if (src_st.st_ino != st.st_ino) {
+ bad = "destination exists";
+ if (force) {
+ /*
+ * only files can overwrite each other:
+ * check both source and destination
+ */
+ if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
+ warning("%s; will overwrite!", bad);
+ bad = NULL;
+ } else
+ bad = "Cannot overwrite";
+ }
}
} else if (string_list_has_string(&src_for_dst, dst))
bad = "multiple sources for the same target";
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index a845b15..95146bf 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -255,4 +255,13 @@ test_expect_success SYMLINKS 'git mv should overwrite file with a symlink' '
rm -f moved symlink
+test_expect_success 'git mv should not fail when only changing case' '
+
+ rm -fr .git &&
+ git init &&
+ >foo.txt &&
+ git add foo.txt &&
+ git mv foo.txt Foo.txt
+'
+
test_done
--
1.5.6.5
^ permalink raw reply related
* [PATCH] handle rename of case only, for windows (resend)
From: Tim Abell @ 2011-01-14 13:54 UTC (permalink / raw)
To: git
Sorry folks, resending because my mail client wrapped the lines in my
patch on my first attempt.
If there's any more problems with the way I've sent it you can grab a
copy from http://is.gd/iWupI8
Tim
--------
Hi folks,
I've never contributed to git before so be gentle :-)
Would someone have the time to help me get this patch into mailine git?
I tripped over a failure to rename files on windows when only the case
has changed. I've created a patch which fixes it for me and doesn't seem
to break on linux or windows. I also created a test to demonstrate the
issue (part of this patch). This test passes on linux and fails on
windows before my patch for mv.c is applied, and passes on both windows
and linux for me after my patch is applied.
The problem with changing the case of a file happens because git mv
checks if the destination filename exists before performing a
move/rename, and on windows lstat reports that the destination file
*does* already exist because it ignores case for this check and
semi-erroneously finds the source file.
The way I've attempted to fix it in my patch is by checking if the inode
of the source and destination are the same before deciding to fail with
a "destination exists" error.
When using "git mv" it is possible to work around the error by using
--force.
I've also seen a problem with windows users pulling from remotes where a
case only rename has been performed which is more problematic as you
have to tell every user how to handle the issue. I'm not sure if I've
managed to fix that case or not.
The fault exists in both the current cygwin git and the current msysgit,
so I figured it would be good to get a patch to upstream (you) so that
it could work everywhere.
I found an email from Linus relating to this issue here:
http://marc.info/?l=git&m=120612172706823 so it's a known problem.
Thanks
Tim Abell
---
builtin/mv.c | 33 ++++++++++++++++++++++-----------
t/t7001-mv.sh | 9 +++++++++
2 files changed, 31 insertions(+), 11 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 93e8995..6bb262e 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -63,6 +63,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
const char **source, **destination, **dest_path;
enum update_mode { BOTH = 0, WORKING_DIRECTORY, INDEX } *modes;
struct stat st;
+ struct stat src_st;
struct string_list src_for_dst = STRING_LIST_INIT_NODUP;
git_config(git_default_config, NULL);
@@ -165,17 +166,27 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
} else if (cache_name_pos(src, length) < 0)
bad = "not under version control";
else if (lstat(dst, &st) == 0) {
- bad = "destination exists";
- if (force) {
- /*
- * only files can overwrite each other:
- * check both source and destination
- */
- if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
- warning("%s; will overwrite!", bad);
- bad = NULL;
- } else
- bad = "Cannot overwrite";
+ /* If we are on a case insensitive files= system (windows) http://is.gd/kyxgg
+ * and we are only changing the case of the file then lstat for the
+ * destination will return != 0 because it sees the source file.
+ * To prevent this causing failure, lstat is used to get the inode of the src
+ * and see if it's actually the same file.
+ */
+ lstat(src, &src_st); //get file serial number (inode) for source
+ #warning("src inode: %s, dst inode: %s", src_st.st_ino, st.st_ino);
+ if (src_st.st_ino != st.st_ino) {
+ bad = "destination exists";
+ if (force) {
+ /*
+ * only files can overwrite each other:
+ * check both source and destination
+ */
+ if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
+ warning("%s; will overwrite!", bad);
+ bad = NULL;
+ } else
+ bad = "Cannot overwrite";
+ }
}
} else if (string_list_has_string(&src_for_dst, dst))
bad = "multiple sources for the same target";
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index a845b15..95146bf 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -255,4 +255,13 @@ test_expect_success SYMLINKS 'git mv should overwrite file with a symlink' '
rm -f moved symlink
+test_expect_success 'git mv should not fail when only changing case' '
+
+ rm -fr .git &&
+ git init &&
+ >foo.txt &&
+ git add foo.txt &&
+ git mv foo.txt Foo.txt
+'
+
test_done
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] handle rename of case only, for windows
From: Nguyen Thai Ngoc Duy @ 2011-01-14 14:17 UTC (permalink / raw)
To: Tim Abell; +Cc: git
In-Reply-To: <1295012644.7883.1415296115@webmail.messagingengine.com>
On Fri, Jan 14, 2011 at 8:44 PM, Tim Abell <tim@timwise.co.uk> wrote:
> else if (lstat(dst, &st) == 0) {
> - bad = "destination exists";
> - if (force) {
> - /*
> - * only files can overwrite each other:
> - * check both source and destination
> - */
> - if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
> - warning("%s; will overwrite!", bad);
> - bad = NULL;
> - } else
> - bad = "Cannot overwrite";
> + /* If we are on a case insensitive files= system (windows) http://is.gd/kyxgg
> + * and we are only changing the case of the file then lstat for the
> + * destination will return != 0 because it sees the source file.
> + * To prevent this causing failure, lstat is used to get the inode of the src
> + * and see if it's actually the same file.
> + */
> + lstat(src, &src_st); //get file serial number (inode) for source
> + #warning("src inode: %s, dst inode: %s", src_st.st_ino, st.st_ino);
> + if (src_st.st_ino != st.st_ino) {
> + bad = "destination exists";
> + if (force) {
> + /*
> + * only files can overwrite each other:
> + * check both source and destination
> + */
> + if (S_ISREG(st.st_mode) || S_ISLNK(st.st_mode)) {
> + warning("%s; will overwrite!", bad);
> + bad = NULL;
> + } else
> + bad = "Cannot overwrite";
> + }
> }
> } else if (string_list_has_string(&src_for_dst, dst))
> bad = "multiple sources for the same target";
I wonder if we can make lstat_case() that would only return 0 if it
matches exactly the filename, even on FAT. FindFirstFile/FindNextFile
should return true file name, I think. If not, we can make
lstat_case() take two paths (src and dst) and move all inode
comparison code in there. Much cleaner.
--
Duy
^ permalink raw reply
* Re: [PATCH] handle rename of case only, for windows
From: Erik Faye-Lund @ 2011-01-14 14:22 UTC (permalink / raw)
To: Tim Abell; +Cc: git, msysGit
In-Reply-To: <1295012461.7403.1415291765@webmail.messagingengine.com>
On Fri, Jan 14, 2011 at 2:41 PM, Tim Abell <tim@timwise.co.uk> wrote:
> Hi folks,
>
> I've never contributed to git before so be gentle :-)
>
> Would someone have the time to help me get this patch into mailine git?
>
First of all, welcome!
There are some problems with your patch that aren't directly related
to the code:
- It's become white-space damaged, most likely from when you e-mailed
it. Perhaps you could try again with git-send-email?
- There's no real commit-message. This e-mail description isn't really
suited as a commit message as it is, IMO. It might just be a matter of
snipping away some stuff, though.
- The patch lacks a sign-off
- Since this is a Windows-issue, it would be nice if you CC'ed
msysgit@googlegroups.com as well. I've done that for now.
I suggest you read through Documentation/SubmittingPatches to get to
know the process.
> I tripped over a failure to rename files on windows when only the case
> has changed. I've created a patch which fixes it for me and doesn't seem
> to break on linux or windows. I also created a test to demonstrate the
> issue (part of this patch). This test passes on linux and fails on
> windows before my patch for mv.c is applied, and passes on both windows
> and linux for me after my patch is applied.
>
> The problem with changing the case of a file happens because git mv
> checks if the destination filename exists before performing a
> move/rename, and on windows lstat reports that the destination file
> *does* already exist because it ignores case for this check and
> semi-erroneously finds the source file.
>
<snip>
> When using "git mv" it is possible to work around the error by using
> --force.
>
Your reasoning seems to match what we've discussed on the msysGit
mailing list. Good work, and a clear description.
> The way I've attempted to fix it in my patch is by checking if the inode
> of the source and destination are the same before deciding to fail with
> a "destination exists" error.
>
Hmm, not so good. st_ino is always 0 on Windows, so this would make
false positives, no?
> The fault exists in both the current cygwin git and the current msysgit,
> so I figured it would be good to get a patch to upstream (you) so that
> it could work everywhere.
>
It also affects MacOS X, AFAIK. So yes, it'd be good for upstream.
> ---
> builtin/mv.c | 33 ++++++++++++++++++++++-----------
> t/t7001-mv.sh | 9 +++++++++
> 2 files changed, 31 insertions(+), 11 deletions(-)
>
> diff --git a/builtin/mv.c b/builtin/mv.c
> index 93e8995..6bb262e 100644
> --- a/builtin/mv.c
> +++ b/builtin/mv.c
> @@ -63,6 +63,7 @@ int cmd_mv(int argc, const char **argv, const char
> *prefix)
> const char **source, **destination, **dest_path;
> enum update_mode { BOTH = 0, WORKING_DIRECTORY, INDEX } *modes;
> struct stat st;
> + struct stat src_st;
Couldn't this be moved inside the scope around "cache_name_pos"?
That's the only scope it is valid inside anyway...
And if not, perhaps you could piggy-back on the st-definition, like this:
- struct stat st;
+ struct stat st, src_st;
> struct string_list src_for_dst = STRING_LIST_INIT_NODUP;
>
> git_config(git_default_config, NULL);
> @@ -165,17 +166,27 @@ int cmd_mv(int argc, const char **argv, const char
> *prefix)
> } else if (cache_name_pos(src, length) < 0)
> bad = "not under version control";
> else if (lstat(dst, &st) == 0) {
> - bad = "destination exists";
> - if (force) {
> - /*
> - * only files can overwrite each other:
> - * check both source and destination
> - */
> - if (S_ISREG(st.st_mode) ||
> S_ISLNK(st.st_mode)) {
> - warning("%s; will overwrite!",
> bad);
> - bad = NULL;
> - } else
> - bad = "Cannot overwrite";
> + /* If we are on a case insensitive files= system
> (windows) http://is.gd/kyxgg
Perhaps you could use the full URL (and maybe put it in the commit
message insted)? It'd be nice if we could reach this information even
if is.gd disappears...
> + * and we are only changing the case of the file
> then lstat for the
> + * destination will return != 0 because it sees
> the source file.
> + * To prevent this causing failure, lstat is
> used to get the inode of the src
> + * and see if it's actually the same file.
> + */
> + lstat(src, &src_st); //get file serial number
> (inode) for source
> + #warning("src inode: %s, dst inode: %s",
> src_st.st_ino, st.st_ino);
Uhm, is this debug-leftovers? #warning is a preprocessor-construct,
and it can't understand varaibles in c. Especially not formatted as
strings. Can #warning even do varags? :P
Blah, it's too tiresome to review this white-space broken version, and
I seen now that you have re-posted a non-broken version. Thanks!
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Luke Kenneth Casson Leighton @ 2011-01-14 14:26 UTC (permalink / raw)
To: Sam Vilain; +Cc: Nguyen Thai Ngoc Duy, Nicolas Pitre, Git Mailing List
In-Reply-To: <4D2F8D7E.6030305@vilain.net>
On Thu, Jan 13, 2011 at 11:40 PM, Sam Vilain <sam@vilain.net> wrote:
> On 14/01/11 00:39, Luke Kenneth Casson Leighton wrote:
>> and change that graph? are you _certain_ that you can write an
>> algorithm which is capable of generating exactly the same mapping,
>> even as more commits are added to the repository being mirrored, or,
>> does that situation not matter?
>
> For a given set of start and end points, and a given sort algorithm,
> walking the commit tree can yield deterministic results.
excellent. out of curiosity, is it as efficient as git pack-objects
for the same start and end points?
> Did you look at any of the previous research I linked to before?
i've been following this since you first originally started it, sam
:) it would have been be nice if it was a completed implementation
that i could test and see "for real" what you're referring to (above)
- the fact that it's in perl and has "TODO" at some of the critical
points, after trying to work with it for several days i stopped and
went "i'm not getting anywhere with this" and focussed on bittorrent
"as a black box" instead.
if i recall, the original gittorrent work that you did (mirror-sync),
the primary aim was to rely solely and exclusively on a one-to-one
direct link between one machine and another. in other words, whilst
syncing, if that peer went "offline", you're screwed - you have to
start again. is that a fair assessment? please do correct any
assumptions that i've made.
because on the basis _of_ that assumption, i decided not to proceed
with mirror-sync, instead to pursue a "cache git pack-objects"
approach and to use bittorrent "black-box-style". which i
demonstrated (minus the cacheing) works perfectly well, several months
back.
in this way (i know i didn't reply earlier - apologies), there is
absolutely no need to "take bittorrent apart", no need to modify it,
tinker with it, adjust it, redesign it, learn from it "for
inspiration" - you just get on with it, using the code, protocol and
everything about it as a black-box. "get this file to everyone and
anyone wot needs it".
as well, after nicolas and others went to all the trouble to explain
what git pack-objects is, how it works, and how damn efficient it is,
i'm pretty much convinced that an approach to uniquely identify, then
pick and cache the *best* git pack-object made [by all the peers
requested to provide a particular commit range], is the best, most
efficient - and importantly simplest and easiest to understand -
approach so far that i've heard. perhaps that's because i came up
with it, i dunno :) but the important thing is that i can _show_ that
it works (http://gitorious.org/python-libbittorrent/pybtlib - go back
a few revisions)
so - perhaps it would help if mirrorsync was revived, so that it can
be used to demonstrate what you mean (there aren't any instructions on
how to set up mirrorsync, for example). that would then allow people
to do a comparative analysis of the approaches being taken.
i'd be *very* interested - and i'm sure that there are others
likewise equally as interested - to see if the mirrorsync "commit tree
walking" algorithm can come up with a more efficient method of
transferring git repositories than git pack-objects can.
l.
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: JT Olds @ 2011-01-14 14:51 UTC (permalink / raw)
To: kusmabite; +Cc: Tor Arntsen, Jeff King, git
In-Reply-To: <AANLkTiksAZSi-Yo8yJv5ca9XWWvB3iVQhZOJtTs-F8gk@mail.gmail.com>
On Fri, Jan 14, 2011 at 2:53 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> (CC'ed Linus, as he wrote mailinfo's sanity-checking)
>
> On Fri, Jan 14, 2011 at 10:24 AM, Tor Arntsen <tor@spacetec.no> wrote:
>> On Fri, Jan 14, 2011 at 09:56, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>>> On Fri, Jan 14, 2011 at 9:45 AM, Tor Arntsen <tor@spacetec.no> wrote:
>>>> I think I've mentioned this before in another thread, but first/last
>>>> name isn't universal, not even within countries where it's the common
>>>> form. When I was as student there was a fellow student from another
>>>> scandinavian country and his legal, full name consisted of a single
>>>> letter.
>>>>
>>>
>>> I'm curious, what Scandinavian country was this? Because as a
>>> Norwegian, I know a lot of people from all Scandinavian country, yet
>>> I've never heard of such names. In Norway, I the shortest legal name
>>> I've ever heard of was five characters.
>>
>> Sweden (I'm Norwegian too - this guy was a Swede studying in Norway).
>> Admittedly I have only that single example, and it was back in the
>> late seventies. His name was accepted as legal by Statens Lånekasse
>> (bank for students) and when the loans arrived his single-letter name
>> would be found at the very end of the long lists of wide listing-paper
>> printouts from the bank that was stiched up on the billboard wall
>> outside the administration offices. The loans arrived a couple of
>> times per year but we always had to go looking - the rest of us were
>> just amazed that we could really find that single letter down there
>> and he wasn't bs'ing the rest of us about his name.
>>
>> I'm not sure why there's a 3-letter limit on git author names.. but I
>> would suggest it should be set down to 1 letter minimum.. below that
>> would, I think, be overdoing it..
>>
>
> Linus, you wrote sanity_check (from 2744b23). Do you remember if there
> were any specific reason for the minimum length of 3 of an
> author-name? It seems that in Sweden, legal names can be even a single
> letter (see Tor's comment)...
>
Thanks all.
I suppose another question, regardless of the outcome of following up
on the name limit, is how come this is silently swallowed?
^ permalink raw reply
* Re: weird github capitalization problem
From: Torsten Bögershausen @ 2011-01-14 15:30 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Andreas Stricker, bolfo, git
In-Reply-To: <4D303D5D.6090108@web.de>
On 14.01.11 13:11, Torsten Bögershausen wrote:
> On 07.01.11 10:17, Andreas Stricker wrote:
>> Am 04.01.11 14:04, schrieb bolfo:
>>> I first installed everything on my laptop, coded some stuff and then
>>> pushed
>>> to github. Apparently something went wrong because there was a new
>>> directory, while at first the directory was OurProjectsources, there
>>> now was
>>> a new directory called OurProjectSources. Weird since my local
>>> directory has
>>> the s not capitalized.
>>
>>> I work on a windows PC while the original author works on a Mac,
>>> could this
>>> be the problem?
>>
>> Yes, Mac OSX HFS+ filesystem ignores the case by default (you'll need
>> to reformat to change this). So OurProjectSources and OurProjectsources
>> both refers to the same directory on Mac OS X. On Linux there are two
>> different directories
>>
>> This frequently causes issues here too. An example:
>>
>> me@mac:t $ git init r
>> Initialized empty Git repository in /private/tmp/t/r/.git/
>> me@mac:r (master) $ mkdir OurProjectsources
>> me@mac:r (master) $ touch OurProjectsources/a
>> me@mac:r (master) $ git add OurProjectsources/a
>> me@mac:r (master) $ git commit -m "initial import"
>> [master (root-commit) c2cb2f3] initial import
>> 0 files changed, 0 insertions(+), 0 deletions(-)
>> create mode 100644 OurProjectsources/a
>> me@mac:r (master) $ mv OurProjectsources/ OurProjectSources
>> me@mac:r (master) $ touch OurProjectSources/b
>> me@mac:r (master) $ git add OurProjectSources/b
>> me@mac:r (master) $ git commit -m "added b"
>> [master 4de780c] added b
>> 0 files changed, 0 insertions(+), 0 deletions(-)
>> create mode 100644 OurProjectSources/b
>> me@mac:r (master) $ git stat
>> # On branch master
>> nothing to commit (working directory clean)
>> me@mac:r (master) $ scp -r .git linux:t.git
>> me@mac:r (master) $ ssh linux
>>
>> me@linux:~ $ git clone t.git/
>> Initialized empty Git repository in /home/me/t/.git/
>> me@linux:~ $ cd t
>> me@linux:~/t $ ls
>> OurProjectsources OurProjectSources
>> me@linux:~/t $ find *
>> OurProjectsources
>> OurProjectsources/a
>> OurProjectSources
>> OurProjectSources/b
>>
>> And there it is, our mess. The mac user accidentally created
>> two different directories but didn't see them.
>>
>> ~/Andy
>>
>
> The following is on next from git.git:
> (And more commits fixing more core.ignorecase issues)
> You might give it a try.
> HTH
> /Torsten
>
>
>
> commit 50906e04e8f48215b0b09841686709b92a2ab2e4
> Author: Joshua Jensen <jjensen@workspacewhiz.com>
> Date: Sun Oct 3 09:56:46 2010 +0000
>
> Support case folding in git fast-import when core.ignorecase=true
>
> When core.ignorecase=true, imported file paths will be folded to match
> existing directory case.
>
> Signed-off-by: Joshua Jensen <jjensen@workspacewhiz.com>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Hm,
that didn't work.
See the test on my linux box, after the clone:
config core.ignorecase true && rm -rf * && git reset --hard && ls && git
config core.ignorecase
HEAD is now at 2dac314 Added b
OurProjectsources OurProjectSources
true
git --version
git version 1.7.2.1.105.g50906
More work seems to be needed, sorry for the noise.
/Torsten
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Linus Torvalds @ 2011-01-14 15:41 UTC (permalink / raw)
To: kusmabite; +Cc: Tor Arntsen, JT Olds, Jeff King, git
In-Reply-To: <AANLkTiksAZSi-Yo8yJv5ca9XWWvB3iVQhZOJtTs-F8gk@mail.gmail.com>
On Fri, Jan 14, 2011 at 1:53 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>
> Linus, you wrote sanity_check (from 2744b23). Do you remember if there
> were any specific reason for the minimum length of 3 of an
> author-name? It seems that in Sweden, legal names can be even a single
> letter (see Tor's comment)...
Even if the legal name would be a single letter, you'd still need to
have a surname.
The three-letter minimum is just a sanity check. If your name really
is even just three letters, I suspect you're just lying. I don't know
of anybody named "A B".
That thing is supposed to be a *NAME*. Not shorthand. Not your first
name. Not your nickname. If you have a nickname, put it in quotes
inside the real name.
I've seen too many broken source control systems that just take your
login as a name *cough*CVS*cough*, and then people think it's
"convenient" and "cool" to have a short name.
It's not convenient. It's not cool. It's just shorthand where
shorthand doesn't help. Then you end up using it in a public setting,
and suddenly your cool shorthand or nickname isn't even remotely
unique.
No, there is no uniquness "requirements" for the name, but come on.
Look at shortlog output some day. We try to use just the name because
it looks better. But if people don't use their full name, it just
looks _stupid_
Linus
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Erik Faye-Lund @ 2011-01-14 16:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tor Arntsen, JT Olds, Jeff King, git
In-Reply-To: <AANLkTi=Z6Dx6m68zi7Q1eRVxX3DXOyKj+Ff177UCQrAj@mail.gmail.com>
On Fri, Jan 14, 2011 at 4:41 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Fri, Jan 14, 2011 at 1:53 AM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>>
>> Linus, you wrote sanity_check (from 2744b23). Do you remember if there
>> were any specific reason for the minimum length of 3 of an
>> author-name? It seems that in Sweden, legal names can be even a single
>> letter (see Tor's comment)...
>
> Even if the legal name would be a single letter, you'd still need to
> have a surname.
>
I think Tor pointed out that he knew a swede with his full legal name
to be only one letter long. I would suppose that meant that he didn't
have a surename?
> The three-letter minimum is just a sanity check. If your name really
> is even just three letters, I suspect you're just lying. I don't know
> of anybody named "A B".
>
Thanks for clarifying that it's not there for a technical reason. The
thing is, git-am seems to be the only place where such a sanity-check
is performed. Shouldn't git-commit rather perform such checks also (if
such a check should be done at all), perhaps with an override similar
to --allow-empty? And on top of all it doesn't barf, it just silently
replace the name with the e-mail...
> That thing is supposed to be a *NAME*. Not shorthand. Not your first
> name. Not your nickname. If you have a nickname, put it in quotes
> inside the real name.
>
> I've seen too many broken source control systems that just take your
> login as a name *cough*CVS*cough*, and then people think it's
> "convenient" and "cool" to have a short name.
>
> It's not convenient. It's not cool. It's just shorthand where
> shorthand doesn't help. Then you end up using it in a public setting,
> and suddenly your cool shorthand or nickname isn't even remotely
> unique.
>
> No, there is no uniquness "requirements" for the name, but come on.
> Look at shortlog output some day. We try to use just the name because
> it looks better. But if people don't use their full name, it just
> looks _stupid_
I agree with you that using nicknames etc as author-name is a bit
silly, but I'm not sure if I want my version control system to tell me
that it thinks my author-name looks stupid :)
IMO, we should probably just remove the check altogether.
There's also an upper-bound of 60 characters. I'm wondering if this
could be hit by valid names, especially with non-western UTF-8
characters. Perhaps this should be removed also. The check for '@',
'<' and '>' is probably still OK.
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Jeff King @ 2011-01-14 16:21 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Linus Torvalds, Tor Arntsen, JT Olds, git
In-Reply-To: <AANLkTimZF+r2aNzrXsUuHVZR65N5wpOYLutFgGAGoci_@mail.gmail.com>
On Fri, Jan 14, 2011 at 05:13:59PM +0100, Erik Faye-Lund wrote:
> > The three-letter minimum is just a sanity check. If your name really
> > is even just three letters, I suspect you're just lying. I don't know
> > of anybody named "A B".
> >
> Thanks for clarifying that it's not there for a technical reason. The
> thing is, git-am seems to be the only place where such a sanity-check
> is performed. Shouldn't git-commit rather perform such checks also (if
> such a check should be done at all), perhaps with an override similar
> to --allow-empty? And on top of all it doesn't barf, it just silently
> replace the name with the e-mail...
I tend to agree with Linus on the stupidity issue, but I do worry about
the subtlety of the results. It causes silent data corruption during a
rebase (or when somebody is applying an emailed patch). On the other
hand, I do understand why Linus made a sanity check in the first place;
his use case is to deal with whatever crap people happen to mail him,
whether they have used git or not.
So we should probably do one or both of:
1. Make an --allow-any-name option to mailinfo, and use it when we
invoke mailinfo internally for rebasing. That still doesn't solve
the emailed patch problem, but at least keeps purely internal
operations sane.
2. Bump the check up to git-commit time, which is the best place to
catch and tell somebody that their name is too short, because they
can actually fix it.
Even if we dropped the check now, option (2) is still useful, because
you have no idea which version of git the other end will use to apply
your patch.
-Peff
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Erik Faye-Lund @ 2011-01-14 16:26 UTC (permalink / raw)
To: Tor Arntsen; +Cc: Linus Torvalds, JT Olds, Jeff King, git
In-Reply-To: <4D3077FE.9090407@spacetec.no>
On Fri, Jan 14, 2011 at 5:21 PM, Tor Arntsen <tor@spacetec.no> wrote:
> On 14/01/2011 17:13, Erik Faye-Lund wrote:
>
>> I think Tor pointed out that he knew a swede with his full legal name
>> to be only one letter long. I would suppose that meant that he didn't
>> have a surename?
>
> Exactly. He didn't. Bank printouts etc. would only have that single
> letter, he didn't use a nickname - that letter was his legal name.
>
Perhaps he could have spelled it out like he usually have to do:
"The artist formerly known as Prince" ;)
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Tor Arntsen @ 2011-01-14 16:21 UTC (permalink / raw)
To: kusmabite; +Cc: Linus Torvalds, JT Olds, Jeff King, git
In-Reply-To: <AANLkTimZF+r2aNzrXsUuHVZR65N5wpOYLutFgGAGoci_@m ail.gmail.com>
On 14/01/2011 17:13, Erik Faye-Lund wrote:
> I think Tor pointed out that he knew a swede with his full legal name
> to be only one letter long. I would suppose that meant that he didn't
> have a surename?
Exactly. He didn't. Bank printouts etc. would only have that single
letter, he didn't use a nickname - that letter was his legal name.
As for the rest of the world - I don't think the first name/last name combo
(almost) everyone in the west use is necessarily a universal rule.
-Tor
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Erik Faye-Lund @ 2011-01-14 16:30 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Tor Arntsen, JT Olds, git
In-Reply-To: <20110114162144.GA867@sigill.intra.peff.net>
On Fri, Jan 14, 2011 at 5:21 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Jan 14, 2011 at 05:13:59PM +0100, Erik Faye-Lund wrote:
>
>> > The three-letter minimum is just a sanity check. If your name really
>> > is even just three letters, I suspect you're just lying. I don't know
>> > of anybody named "A B".
>> >
>> Thanks for clarifying that it's not there for a technical reason. The
>> thing is, git-am seems to be the only place where such a sanity-check
>> is performed. Shouldn't git-commit rather perform such checks also (if
>> such a check should be done at all), perhaps with an override similar
>> to --allow-empty? And on top of all it doesn't barf, it just silently
>> replace the name with the e-mail...
>
> I tend to agree with Linus on the stupidity issue, but I do worry about
> the subtlety of the results. It causes silent data corruption during a
> rebase (or when somebody is applying an emailed patch). On the other
> hand, I do understand why Linus made a sanity check in the first place;
> his use case is to deal with whatever crap people happen to mail him,
> whether they have used git or not.
>
> So we should probably do one or both of:
>
> 1. Make an --allow-any-name option to mailinfo, and use it when we
> invoke mailinfo internally for rebasing. That still doesn't solve
> the emailed patch problem, but at least keeps purely internal
> operations sane.
>
> 2. Bump the check up to git-commit time, which is the best place to
> catch and tell somebody that their name is too short, because they
> can actually fix it.
>
The problem with (2) is that git-am uses git-commit-tree rather than
git-commit. But I do think that adding the same checks to git-commit
would make sense. Unless we decide to remove the checks, that is...
^ permalink raw reply
* Re: Git Rebase blows away GIT_AUTHOR_NAME
From: Jeff King @ 2011-01-14 16:33 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Linus Torvalds, Tor Arntsen, JT Olds, git
In-Reply-To: <AANLkTimcQq++CLv66AyTve+PiXBhYdUPk2epCyOXX1c0@mail.gmail.com>
On Fri, Jan 14, 2011 at 05:30:51PM +0100, Erik Faye-Lund wrote:
> > 2. Bump the check up to git-commit time, which is the best place to
> > catch and tell somebody that their name is too short, because they
> > can actually fix it.
> >
>
> The problem with (2) is that git-am uses git-commit-tree rather than
> git-commit. But I do think that adding the same checks to git-commit
> would make sense. Unless we decide to remove the checks, that is...
Yeah, I didn't say it very clearly, but I meant to factor the check out
and use it also in git-commit (probably as a warning, the same way we do
with other ident verification in print_summary().
Even if we remove the check, it may still be worthwhile to say "Just so
you know, older versions of git may mangle the name you have chosen".
-Peff
^ 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