* Re: [PATCH] diff: add ruby funcname pattern
From: Jeff King @ 2008-08-01 14:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Giuseppe Bilotta, git
In-Reply-To: <7v4p65tadh.fsf@gitster.siamese.dyndns.org>
On Fri, Aug 01, 2008 at 01:20:10AM -0700, Junio C Hamano wrote:
> Thanks again for the patch. Somewhere I heard that there are 10 Rubyista
> git users for every non Rubyista git user, so I am sure somebody would
> comment on your patch in a day or two. Perhaps we might even get Python
> and Perl hunk patterns (although I suspect Perl people are happy with the
> default one we stole from GNU diff) to go with it ;-).
I keep a lot of Perl in git, and yes, I am quite happy with the default
regex.
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] clone --bare: Add ".git" suffix to the directory name to clone into
From: Bert Wesarg @ 2008-08-01 15:34 UTC (permalink / raw)
To: Marcus Griep; +Cc: Git Mailing List
In-Reply-To: <4893172C.1060203@griep.us>
On Fri, Aug 1, 2008 at 16:01, Marcus Griep <marcus@griep.us> wrote:
> Does this patch forgo adding a ".git" suffix if one is already present?
No, the purpose of the guess_dir_name() function is exactly to remove
any present ".git", and more.
Bert
>
> Marcus
>
^ permalink raw reply
* [PATCH] git mv: try harder to keep index entries intact
From: Johannes Schindelin @ 2008-08-01 16:49 UTC (permalink / raw)
To: git, gitster, pasky
Some filesystems change the ctime during a rename(), for technical
reasons. Since this is the only change, the contents need not be
rehashed. So just update the ctime after renaming the entry.
This change requires rename_index_entry_at() to return the new
position.
As git-mv assumes that it runs in a non-bare repository, and is
marked as such in the cmd_struct in git.c, the changes do not have
to be guarded against running in a bare repository.
To test this properly, you need to run t7001 with the environment
variable TEST_CTIME_WITH_SLEEP set non-empty, since there is no way
to manipulate the ctime directly; we have to sleep.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-mv.c | 15 +++++++++++++--
cache.h | 2 +-
read-cache.c | 4 ++--
t/t7001-mv.sh | 10 ++++++++--
4 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/builtin-mv.c b/builtin-mv.c
index 4f65b5a..166a019 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -214,8 +214,19 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
pos = cache_name_pos(src, strlen(src));
assert(pos >= 0);
- if (!show_only)
- rename_cache_entry_at(pos, dst);
+ if (!show_only) {
+ struct stat st;
+ pos = rename_cache_entry_at(pos, dst);
+
+ /*
+ * Renaming can update the ctime. Do not force
+ * a complete rehash just because of that.
+ */
+ if (!lstat(dst, &st))
+ active_cache[pos]->ce_ctime = st.st_ctime;
+ else if (!ignore_errors)
+ die ("Could not stat '%s'", dst);
+ }
}
if (active_cache_changed) {
diff --git a/cache.h b/cache.h
index 8155ab8..4b6876b 100644
--- a/cache.h
+++ b/cache.h
@@ -371,7 +371,7 @@ extern int index_name_pos(const struct index_state *, const char *name, int name
#define ADD_CACHE_JUST_APPEND 8 /* Append only; tree.c::read_tree() */
extern int add_index_entry(struct index_state *, struct cache_entry *ce, int option);
extern struct cache_entry *refresh_cache_entry(struct cache_entry *ce, int really);
-extern void rename_index_entry_at(struct index_state *, int pos, const char *new_name);
+extern int rename_index_entry_at(struct index_state *, int pos, const char *new_name);
extern int remove_index_entry_at(struct index_state *, int pos);
extern int remove_file_from_index(struct index_state *, const char *path);
#define ADD_CACHE_VERBOSE 1
diff --git a/read-cache.c b/read-cache.c
index c5aa5bc..4454686 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -43,7 +43,7 @@ static void replace_index_entry(struct index_state *istate, int nr, struct cache
istate->cache_changed = 1;
}
-void rename_index_entry_at(struct index_state *istate, int nr, const char *new_name)
+int rename_index_entry_at(struct index_state *istate, int nr, const char *new_name)
{
struct cache_entry *old = istate->cache[nr], *new;
int namelen = strlen(new_name);
@@ -56,7 +56,7 @@ void rename_index_entry_at(struct index_state *istate, int nr, const char *new_n
cache_tree_invalidate_path(istate->cache_tree, old->name);
remove_index_entry_at(istate, nr);
- add_index_entry(istate, new, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
+ return add_index_entry(istate, new, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
}
/*
diff --git a/t/t7001-mv.sh b/t/t7001-mv.sh
index 910a28c..5f6cee5 100755
--- a/t/t7001-mv.sh
+++ b/t/t7001-mv.sh
@@ -180,12 +180,15 @@ test_expect_success 'git mv should overwrite symlink to a file' '
echo 1 >moved &&
ln -s moved symlink &&
git add moved symlink &&
+ if test ! -z "$TEST_CTIME_WITH_SLEEP"
+ then
+ sleep 1
+ fi &&
test_must_fail git mv moved symlink &&
git mv -f moved symlink &&
! test -e moved &&
test -f symlink &&
test "$(cat symlink)" = 1 &&
- git update-index --refresh &&
git diff-files --quiet
'
@@ -199,11 +202,14 @@ test_expect_success 'git mv should overwrite file with a symlink' '
echo 1 >moved &&
ln -s moved symlink &&
git add moved symlink &&
+ if test ! -z "$TEST_CTIME_WITH_SLEEP"
+ then
+ sleep 1
+ fi &&
test_must_fail git mv symlink moved &&
git mv -f symlink moved &&
! test -e symlink &&
test -h moved &&
- git update-index --refresh &&
git diff-files --quiet
'
--
1.6.0.rc1.55.g69db8
^ permalink raw reply related
* Re: Is there any hope (format-patch)??
From: Daniel Barkalow @ 2008-08-01 17:35 UTC (permalink / raw)
To: Matti Kaasinen; +Cc: git
In-Reply-To: <4892FBF6.8060505@sitecno.fi>
On Fri, 1 Aug 2008, Matti Kaasinen wrote:
> Hi!
>
> Is there any hope with following procedure:
> I took reporitory from linux git:
> # git clone
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> For getting patches to make recent version from v2.6.26-rc3 I executed:
> # git format-patch -o patchdir v2.6.26-rc3..origin
format-patch isn't going to work too well with non-linear history. When
two people make nearby or overlapping changes which get merged later, and
this gets turned into a linear sequence of changes, there's no
possible patch that will accurately reflect the change which got ordered
second.
> Then I checked out v2.6.26-rc3 to a new branch and patched it with
> at91patch/maxim.org.za that was produced against v2.6.26-rc3. That worked out
> without complaints.
It sounds like you really just want to do "merge origin" now, and skip the
whole patch series thing.
You'll probably get some conflicts (or applying the patch directly to
origin would have worked), but they should be relatively easy to resolve.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Git vs Monotone
From: Daniel Barkalow @ 2008-08-01 18:00 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0808010023r5d44e7a2ke062c9c39dfb865c@mail.gmail.com>
On Fri, 1 Aug 2008, Sverre Rabbelier wrote:
> On Thu, Jul 31, 2008 at 20:13, Sverre Rabbelier <alturin@gmail.com> wrote:
> > I just read this blog post [0] in which one of the Pidgin devs sheds
> > his light on their 'tool choice'. In the post he mentions the
> > following figures:
>
> > [0] http://theflamingbanker.blogspot.com/2008/07/holy-war-of-tool-choice.html
>
> I have poked him on #pidgin, and he has added the following:
>
> "Note: It's come to my attention that I had missed the ability to
> share a git database across multiple working copies. In that scenario,
> the total size of the database and 11 working copies is slightly under
> 750 MB, and thus a space savings in the neighborhood of 150 MB over
> monotone. It had been my understanding that I needed a copy of the
> database per working copy. I stand corrected. I don't use git on a
> daily basis, as the projects I work with currently use CVS, SVN, or
> monotone, so I am bound to miss finer details of git here and there.
> There are other reasons I prefer to stick with monotone, but I won't
> get into them here, as they're not important to the point of this
> post."
Did he retry the size calculation? I think someone on the list tried it
and found that the clone, including the checkout, was (for them) the size
that he thought was just the database; if you're used to having the clone
equivalent be effectively --bare by default, it's an easy mistake,
especially if you don't think it's possible for the entire project history
to be smaller than a checkout.
Not that it actually matters to the comparison of monotone and SVN that
was the actual point, but still, git is often more space-efficient than
SVN even just on the client, even without any sharing between branches,
just because uncompressed source is (relatively) huge. Which does, in a
way, contribute to the point that SVN have a vast quantity of per-branch
overhead.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] builtin-name-rev: refactor stdin handling to its own function
From: Junio C Hamano @ 2008-08-01 19:07 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Johannes Schindelin, Shawn O. Pearce, Git Mailinglist
In-Reply-To: <1217589372-4151-1-git-send-email-pdebie@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> Signed-off-by: Pieter de Bie <pdebie@ai.rug.nl>
> ---
>
> On 1 aug 2008, at 09:23, Junio C Hamano wrote:
> >Is it just me to find that this part is getting indented too deeply to be
> >readable?
>
> How about something like this then?
Much nicer, except that this refactoring should come first and then a new
feature. Dropping those extra five 's' so that it would compile would be
a nice bonus as well ;-)
> ...
> +
> + if (name_only) {
> + fwrite(p_start, p - p_start + 1 - 40,
> + 1, stdout);sssss
> + printf(name);
> + }
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 19:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20080731194042.a1534b4d.akpm@linux-foundation.org>
On Thu, 31 Jul 2008, Andrew Morton wrote:
>
> A minor thing.
>
> Commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2 is displayed thusly:
>
> commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2
> Author: Zhang, Rui <rui.zhang@intel.com>
> Date: Thu Apr 10 16:20:23 2008 +0800
>
> ACPI: update thermal temperature
>
> but that isn't a valid email address. Because it contains a comma it
> must be quoted: "Zhang, Rui".
The email address is rui.zhang@intel.com.
The name is Zhang, Rui.
Git at no point ever mixes the two up. It's _not_ one field ("Zhang, Rui
<rui.zhang@intel.com>"), it's literally two different parts that you set
separately, that just get shown (and encoded in the commit, for that
matter) in a way that resembles a single email address.
> I assume that something in the git toolchain removed his quotes, and
> that was arguably incorrect.
No, it would be incorrect to keep them, because the name doesn't contain
the quotes. The name is just that
Zhang, Rui
part.
I've considered having the email->name detection change "A, B" into "B A",
but it's not always right, so it doesn't try to munge the names it finds
in other ways except to remove obvious crud from the ends.
And Andrew, this is true of Signed-off-by: lines too, btw. If you actually
want to send emails to them, _then_ you need to add quotes to follow the
email rules.
Linus
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Junio C Hamano @ 2008-08-01 19:42 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <37fcd2780808010224l68c2c717y5334a34d9de1de8d@mail.gmail.com>
"Dmitry Potapov" <dpotapov@gmail.com> writes:
> On Fri, Aug 1, 2008 at 12:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> "Dmitry Potapov" <dpotapov@gmail.com> writes:
>>>
>>> To being able to synchronize efficiently in both ways, you need to store
>>> files exactly as they were received from SVN then there will be no
>>> problem with applying binary delta patch. All CRLF conversion should be
>>> done on checkout and checkin from/to Git repository.
>>
>> Ahh,... if that is the philosophy, perhaps we can teach --stdin-paths to
>> optionally open the file itself and use index_pipe() like --stdin codepath
>> does?
>
> It is possible to do in this way, but it less efficient, because it uses
> index_pipe, which does not know the actual size, so it reallocates the buffer
> as it reads data from the descriptor, while index_fd uses xmap() instead.
> So I sent another solution yesterday:
> http://article.gmane.org/gmane.comp.version-control.git/90968
>
> It is a bit hackish because...
Ok, earlier I was confused who was proposing what for what purpose, but
that one was not just "a bit hackish" but an unacceptable hack ;-)
Perhaps you would want to do the s/write_object/flags/ conversion, like
this?
--
cache.h | 9 ++++++---
sha1_file.c | 15 +++++++++------
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/cache.h b/cache.h
index 2475de9..39975fb 100644
--- a/cache.h
+++ b/cache.h
@@ -390,9 +390,12 @@ extern int ie_match_stat(const struct index_state *, struct cache_entry *, struc
extern int ie_modified(const struct index_state *, struct cache_entry *, struct stat *, unsigned int);
extern int ce_path_match(const struct cache_entry *ce, const char **pathspec);
-extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, enum object_type type, const char *path);
-extern int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object);
-extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object);
+
+#define HASH_OBJECT_DO_CREATE 01
+#define HASH_OBJECT_LITERALLY 02
+extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int flags, enum object_type type, const char *path);
+extern int index_pipe(unsigned char *sha1, int fd, const char *type, int flags);
+extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int flags);
extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
#define REFRESH_REALLY 0x0001 /* ignore_valid */
diff --git a/sha1_file.c b/sha1_file.c
index e281c14..5def648 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2353,10 +2353,11 @@ int has_sha1_file(const unsigned char *sha1)
return has_loose_object(sha1);
}
-int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object)
+int index_pipe(unsigned char *sha1, int fd, const char *type, int flags)
{
struct strbuf buf;
int ret;
+ int write_object = flags & HASH_OBJECT_DO_CREATE;
strbuf_init(&buf, 0);
if (strbuf_read(&buf, fd, 4096) < 0) {
@@ -2375,9 +2376,11 @@ int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object)
return ret;
}
-int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object,
+int index_fd(unsigned char *sha1, int fd, struct stat *st, int flags,
enum object_type type, const char *path)
{
+ int write_object = flags & HASH_OBJECT_DO_CREATE;
+ int hash_literally = flags & HASH_OBJECT_LITERALLY;
size_t size = xsize_t(st->st_size);
void *buf = NULL;
int ret, re_allocated = 0;
@@ -2392,7 +2395,7 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object,
/*
* Convert blobs to git internal format
*/
- if ((type == OBJ_BLOB) && S_ISREG(st->st_mode)) {
+ if (!hash_literally && (type == OBJ_BLOB) && S_ISREG(st->st_mode)) {
struct strbuf nbuf;
strbuf_init(&nbuf, 0);
if (convert_to_git(path, buf, size, &nbuf,
@@ -2416,7 +2419,7 @@ int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object,
return ret;
}
-int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object)
+int index_path(unsigned char *sha1, const char *path, struct stat *st, int flags)
{
int fd;
char *target;
@@ -2428,7 +2431,7 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write
if (fd < 0)
return error("open(\"%s\"): %s", path,
strerror(errno));
- if (index_fd(sha1, fd, st, write_object, OBJ_BLOB, path) < 0)
+ if (index_fd(sha1, fd, st, flags, OBJ_BLOB, path) < 0)
return error("%s: failed to insert into database",
path);
break;
@@ -2441,7 +2444,7 @@ int index_path(unsigned char *sha1, const char *path, struct stat *st, int write
return error("readlink(\"%s\"): %s", path,
errstr);
}
- if (!write_object)
+ if (!(flags & HASH_OBJECT_DO_CREATE))
hash_sha1_file(target, len, blob_type, sha1);
else if (write_sha1_file(target, len, blob_type, sha1))
return error("%s: failed to insert into database",
^ permalink raw reply related
* Re: email address handling
From: Andrew Morton @ 2008-08-01 19:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0808011229400.3277@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 12:34:58 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> And Andrew, this is true of Signed-off-by: lines too, btw. If you actually
> want to send emails to them, _then_ you need to add quotes to follow the
> email rules.
That's how I noticed it - copied, pasted, MTA barfed.
Converting a usable name+email-address into an unusable one seems ... unuseful.
^ permalink raw reply
* [PATCH] git-p4: chdir now properly sets PWD environment variable in msysGit
From: Robert Blum @ 2008-08-01 19:50 UTC (permalink / raw)
To: simon, shausman, marius, hanwen, gitster; +Cc: git
P4 on Windows expects the PWD environment variable to be set to the
current working dir, but os.chdir in python doesn't do that by default
Signed-off-by: Robert Blum <rob.blum@gmail.com>
---
Pushing it out to the list since I'm not entirely sure who the git-p4 owner
even is. CC'ed likely suspects for ownership ;)
contrib/fast-import/git-p4 | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 6ae0429..b4d0c65 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -16,6 +16,13 @@ from sets import Set;
verbose = False
+if os.name == 'nt':
+ def os_chdir(dir):
+ os.environ['PWD']=dir
+ os.chdir(dir)
+else:
+ os_chdir = os.chdir
+
def die(msg):
if verbose:
raise Exception(msg)
@@ -712,7 +719,7 @@ class P4Submit(Command):
print "Perforce checkout for depot path %s located at %s" % (self.depot
Path, self.clientPath)
self.oldWorkingDirectory = os.getcwd()
- os.chdir(self.clientPath)
+ os_chdir(self.clientPath)
print "Syncronizing p4 checkout..."
system("p4 sync ...")
@@ -732,7 +739,7 @@ class P4Submit(Command):
if len(commits) == 0:
print "All changes applied!"
- os.chdir(self.oldWorkingDirectory)
+ os_chdir(self.oldWorkingDirectory)
sync = P4Sync()
sync.run([])
@@ -1670,7 +1677,7 @@ class P4Clone(P4Sync):
print "Importing from %s into %s" % (', '.join(depotPaths), self.cloneD
estination)
if not os.path.exists(self.cloneDestination):
os.makedirs(self.cloneDestination)
- os.chdir(self.cloneDestination)
+ os_chdir(self.cloneDestination)
system("git init")
self.gitdir = os.getcwd() + "/.git"
if not P4Sync.run(self, depotPaths):
@@ -1782,7 +1789,7 @@ def main():
if os.path.exists(cmd.gitdir):
cdup = read_pipe("git rev-parse --show-cdup").strip()
if len(cdup) > 0:
- os.chdir(cdup);
+ os_chdir(cdup);
if not isValidGitDir(cmd.gitdir):
if isValidGitDir(cmd.gitdir + "/.git"):
--
1.5.5.1015.g9d258
^ permalink raw reply related
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 19:56 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20080801124550.26b9efc0.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
>
> That's how I noticed it - copied, pasted, MTA barfed.
>
> Converting a usable name+email-address into an unusable one seems ... unuseful.
Umm. Those signed-off ones weren't even _converted_ They were written by
people.
Also, you seemed to miss the point that it's not a name+email-address.
It's a name. Oh, and there's an email address too. But they aren't
connected. We often just print out the name *without* the email address.
Why should those things have to know about some totally irrelevant email
quoting rules? They weren't emails, didn't know about it, and didn't care.
Linus
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-01 20:00 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, git
In-Reply-To: <20080801124550.26b9efc0.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> writes:
> On Fri, 1 Aug 2008 12:34:58 -0700 (PDT)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>> And Andrew, this is true of Signed-off-by: lines too, btw. If you actually
>> want to send emails to them, _then_ you need to add quotes to follow the
>> email rules.
>
> That's how I noticed it - copied, pasted, MTA barfed.
>
> Converting a usable name+email-address into an unusable one seems ... unuseful.
Name is used not just for pasting into your MUA. For example, if your
shortlog output showed this, it would be "funny looking":
"Zhang, Rui" (4):
...
Andrew Morton (20):
...
...
^ permalink raw reply
* [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Avery Pennarun @ 2008-08-01 19:45 UTC (permalink / raw)
To: gitster, git; +Cc: Avery Pennarun
Finds classes, records, functions, procedures, and sections. Most lines
need to start at the first column, or else there's no way to differentiate
a procedure's definition from its declaration.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
---
The Ruby funcname pattern patch inspired me. Although unlike him, I didn't
check with anyone else for confirmation. How many Pascal programmers can
there possibly be? :)
diff.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index cbf2547..c73ba69 100644
--- a/diff.c
+++ b/diff.c
@@ -1380,6 +1380,10 @@ static struct builtin_funcname_pattern {
"^[ ]*\\(\\([ ]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
"[ ]*([^;]*\\)$" },
+ { "pas", "\\(^\\(procedure\\|function\\|constructor\\|"
+ "destructor\\|interface\\|implementation\\|"
+ "type|initialization|finalization\\).*$\\)"
+ "\\|\\(^.*=[ \t]*\\(class\\|record\\).*$\\)" },
{ "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
};
--
1.6.0.rc1.34.g23b24.dirty
^ permalink raw reply related
* Re: email address handling
From: Junio C Hamano @ 2008-08-01 20:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, git
In-Reply-To: <alpine.LFD.1.10.0808011253580.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Fri, 1 Aug 2008, Andrew Morton wrote:
>>
>> That's how I noticed it - copied, pasted, MTA barfed.
>>
>> Converting a usable name+email-address into an unusable one seems ... unuseful.
>
> Umm. Those signed-off ones weren't even _converted_ They were written by
> people.
>
> Also, you seemed to miss the point that it's not a name+email-address.
>
> It's a name. Oh, and there's an email address too. But they aren't
> connected. We often just print out the name *without* the email address.
> Why should those things have to know about some totally irrelevant email
> quoting rules? They weren't emails, didn't know about it, and didn't care.
One place that can matter is git-send-email.perl; IIRC, it reads from the
S-o-b:, Cc: and From: lines people write, and these follow "name next to
address, that does not care irrelevant email quoting rules" format. I do
not think send-email currently does much about quoting them, but I think
it should be the right place to do so.
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 20:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0808011253580.3277@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 12:56:44 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 1 Aug 2008, Andrew Morton wrote:
> >
> > That's how I noticed it - copied, pasted, MTA barfed.
> >
> > Converting a usable name+email-address into an unusable one seems ... unuseful.
>
> Umm. Those signed-off ones weren't even _converted_ They were written by
> people.
This was the Author: line.
Afaik that person doesn't send patches via git, and that this text by
some means was transferred into git from an emailed patch.
So unless he explicitly typed a "From:" line (without quoting his name)
into the top of his changelog, some piece of software somewhere has
stripped the quotes when it was converting his name from the email
headers into the git Author: line.
> Also, you seemed to miss the point that it's not a name+email-address.
I know exactly what it is.
> It's a name. Oh, and there's an email address too. But they aren't
> connected. We often just print out the name *without* the email address.
> Why should those things have to know about some totally irrelevant email
> quoting rules? They weren't emails, didn't know about it, and didn't care.
Well, as I said, it's a minor point. It's just that converting
something which _can_ be copied and pasted into an MUA into something
which cannot seems... odd.
Most sane MUA's will omit the quotes if the name part does not need
them, so simply retaining the quotes if they were originally there
would be an OK thing to do.
So how serious is this issue?
Well, if all MUAs either generate synchronous error messages or will
insert the quotes for you then not very serious at all.
If, however, there are MUA+MTA combinations which do _not_ inform about
or correct the error then this failure to quote the name could cause
people's emails to get lost altogether, which is a bit serious.
Also, _most_ git Author: lines _can_ be successfully copied-and-pasted
into an MUA. The fact that a small minority of git Author: lines cannot
be used this way is a bit dangerous.
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: torvalds, git
In-Reply-To: <7viquksdyn.fsf@gitster.siamese.dyndns.org>
On Fri, 01 Aug 2008 13:00:16 -0700
Junio C Hamano <gitster@pobox.com> wrote:
> Andrew Morton <akpm@linux-foundation.org> writes:
>
> > On Fri, 1 Aug 2008 12:34:58 -0700 (PDT)
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >> And Andrew, this is true of Signed-off-by: lines too, btw. If you actually
> >> want to send emails to them, _then_ you need to add quotes to follow the
> >> email rules.
> >
> > That's how I noticed it - copied, pasted, MTA barfed.
> >
> > Converting a usable name+email-address into an unusable one seems ... unuseful.
>
> Name is used not just for pasting into your MUA. For example, if your
> shortlog output showed this, it would be "funny looking":
>
> "Zhang, Rui" (4):
> ...
>
> Andrew Morton (20):
> ...
> ...
yep. That'd be a git-shortlog bug :)
I really don't care about this much!
^ permalink raw reply
* Re: [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Junio C Hamano @ 2008-08-01 20:16 UTC (permalink / raw)
To: Avery Pennarun; +Cc: gitster, git
In-Reply-To: <1217619915-9331-1-git-send-email-apenwarr@gmail.com>
"Avery Pennarun" <apenwarr@gmail.com> writes:
> Finds classes, records, functions, procedures, and sections. Most lines
> need to start at the first column, or else there's no way to differentiate
> a procedure's definition from its declaration.
>
> Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
> ---
>
> The Ruby funcname pattern patch inspired me. Although unlike him, I didn't
> check with anyone else for confirmation. How many Pascal programmers can
> there possibly be? :)
> + { "pas", "\\(^\\(procedure\\|function\\|constructor\\|"
> + "destructor\\|interface\\|implementation\\|"
> + "type|initialization|finalization\\).*$\\)"
> + "\\|\\(^.*=[ \t]*\\(class\\|record\\).*$\\)" },
Is Delphi the only surviving Pascal? Why is the name "pas", not "pascal"
or even "delphi-pascal"?
The keys are not file extensions ("ruby" example did the right thing by
not saying "rb").
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 20:17 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20080801131127.20b3acfd.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
>
> This was the Author: line.
So?
I mean, it's not sending email, is it? It says "Author:".
You could have just inserted the actual email address. Or something.
Linus
^ permalink raw reply
* Re: [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Petr Baudis @ 2008-08-01 20:20 UTC (permalink / raw)
To: Avery Pennarun; +Cc: gitster, git
In-Reply-To: <1217619915-9331-1-git-send-email-apenwarr@gmail.com>
On Fri, Aug 01, 2008 at 03:45:15PM -0400, Avery Pennarun wrote:
> diff --git a/diff.c b/diff.c
> index cbf2547..c73ba69 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -1380,6 +1380,10 @@ static struct builtin_funcname_pattern {
> "^[ ]*\\(\\([ ]*"
> "[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
> "[ ]*([^;]*\\)$" },
> + { "pas", "\\(^\\(procedure\\|function\\|constructor\\|"
> + "destructor\\|interface\\|implementation\\|"
> + "type|initialization|finalization\\).*$\\)"
> + "\\|\\(^.*=[ \t]*\\(class\\|record\\).*$\\)" },
> { "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
> };
>
Wouldn't it be better to make the second pattern start on new line
instead of the outer \(\|\)?
Why "type"?
--
Petr "Pasky, but not writing in Pascal anymore!" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: email address handling
From: Andrew Morton @ 2008-08-01 20:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0808011316050.3277@nehalem.linux-foundation.org>
On Fri, 1 Aug 2008 13:17:11 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 1 Aug 2008, Andrew Morton wrote:
> >
> > This was the Author: line.
>
> So?
So all the other things I said.
> I mean, it's not sending email, is it? It says "Author:".
>
> You could have just inserted the actual email address. Or something.
>
pls read earlier email.
^ permalink raw reply
* git-submodule add -b
From: Tim Olsen @ 2008-08-01 20:27 UTC (permalink / raw)
To: git
The git-submodule man page says that the -b option to "git-submodule
add" is the "Branch of repository to add as submodule."
I get the error "fatal: A branch named '1.x' already exists." when I try
to use "git submodule add -b". A sample session is below. What am I
doing wrong?
tolsen@neurofunk:~/git$ mkdir submodule-branch
tolsen@neurofunk:~/git$ cd submodule-branch
tolsen@neurofunk:~/git/submodule-branch$ mkdir sub
tolsen@neurofunk:~/git/submodule-branch$ cd sub
tolsen@neurofunk:~/git/submodule-branch/sub$ git init
Initialized empty Git repository in
/home/tolsen/git/submodule-branch/sub/.git/
tolsen@neurofunk:~/git/submodule-branch/sub$ echo 1 > file
tolsen@neurofunk:~/git/submodule-branch/sub$ git add file
tolsen@neurofunk:~/git/submodule-branch/sub$ git commit -m v1
Created initial commit d5c185a: v1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 file
tolsen@neurofunk:~/git/submodule-branch/sub$ echo 2 > file
tolsen@neurofunk:~/git/submodule-branch/sub$ git add file
tolsen@neurofunk:~/git/submodule-branch/sub$ git commit -m v2
Created commit fb864b2: v2
1 files changed, 1 insertions(+), 1 deletions(-)
tolsen@neurofunk:~/git/submodule-branch/sub$ git log
commit fb864b2d4d9dacd87e55d0be970baa5fc6a0972c
Author: Tim Olsen <tolsen@limespot.com>
Date: Fri Aug 1 16:21:09 2008 -0400
v2
commit d5c185a7ea91b66b5df524b21bbe0daf40a456f4
Author: Tim Olsen <tolsen@limespot.com>
Date: Fri Aug 1 16:21:03 2008 -0400
v1
tolsen@neurofunk:~/git/submodule-branch/sub$ git checkout -b 1.x d5c185a7
Switched to a new branch "1.x"
tolsen@neurofunk:~/git/submodule-branch/sub$ echo 1.1 > file
tolsen@neurofunk:~/git/submodule-branch/sub$ git add file
tolsen@neurofunk:~/git/submodule-branch/sub$ git commit -m v1.1
Created commit d9868c5: v1.1
1 files changed, 1 insertions(+), 1 deletions(-)
tolsen@neurofunk:~/git/submodule-branch/sub$ git log
commit d9868c5dc837404834b44eca6d21930c4f352127
Author: Tim Olsen <tolsen@limespot.com>
Date: Fri Aug 1 16:21:58 2008 -0400
v1.1
commit d5c185a7ea91b66b5df524b21bbe0daf40a456f4
Author: Tim Olsen <tolsen@limespot.com>
Date: Fri Aug 1 16:21:03 2008 -0400
v1
tolsen@neurofunk:~/git/submodule-branch/sub$ cd ..
tolsen@neurofunk:~/git/submodule-branch$ mkdir super
tolsen@neurofunk:~/git/submodule-branch$ cd super
tolsen@neurofunk:~/git/submodule-branch/super$ git init
Initialized empty Git repository in
/home/tolsen/git/submodule-branch/super/.git/
tolsen@neurofunk:~/git/submodule-branch/super$ echo dummy > dummy
tolsen@neurofunk:~/git/submodule-branch/super$ git add dummy
tolsen@neurofunk:~/git/submodule-branch/super$ git commit -m dummy
Created initial commit f1c41b6: dummy
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 dummy
tolsen@neurofunk:~/git/submodule-branch/super$ cd ..
tolsen@neurofunk:~/git/submodule-branch$ git clone super super2
Initialized empty Git repository in
/home/tolsen/git/submodule-branch/super2/.git/
tolsen@neurofunk:~/git/submodule-branch$ cd super2
tolsen@neurofunk:~/git/submodule-branch/super2$ git submodule add -b 1.x
~/git/submodule-branch/sub
Initialized empty Git repository in
/home/tolsen/git/submodule-branch/super2/sub/.git/
fatal: A branch named '1.x' already exists.
Unable to checkout submodule 'sub'
tolsen@neurofunk:~/git/submodule-branch/super2$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# sub/
nothing added to commit but untracked files present (use "git add" to track)
tolsen@neurofunk:~/git/submodule-branch/super2$
Thanks,
Tim
^ permalink raw reply
* [PATCH] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-08-01 20:35 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Giuseppe Bilotta
In-Reply-To: <1217593425-28314-1-git-send-email-giuseppe.bilotta@gmail.com>
When using path info, make filenames start with a / (right after the :
that separates them from the hash base). This minimal change allows
relative navigation to work properly when viewing HTML files.
---
This patch is based on top of my previous patch
gitweb: action in path with use_pathinfo
(which I sent with the wrong CC: lines)
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 56fbdab..a8c0887 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -664,7 +664,7 @@ sub href (%) {
if (defined $params{'hash_base'}) {
$href .= "/".esc_url($params{'hash_base'});
if (defined $params{'file_name'}) {
- $href .= ":".esc_url($params{'file_name'});
+ $href .= ":/".esc_url($params{'file_name'});
delete $params{'hash'} if $params{'hash'} eq git_get_hash_by_path($params{'hash_base'},$params{'file_name'});
delete $params{'file_name'};
} else {
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Avery Pennarun @ 2008-08-01 20:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8wvgsd6s.fsf@gitster.siamese.dyndns.org>
On 8/1/08, Junio C Hamano <gitster@pobox.com> wrote:
> Is Delphi the only surviving Pascal? Why is the name "pas", not "pascal"
> or even "delphi-pascal"?
No, but all surviving Pascals pretty much support the same syntax, so
when I say Pascal/Delphi, I mean either one. And Delphi does use the
.pas extension.
> The keys are not file extensions ("ruby" example did the right thing by
> not saying "rb").
Will fix.
Avery
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-01 20:40 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20080801132415.0b0314e4.akpm@linux-foundation.org>
On Fri, 1 Aug 2008, Andrew Morton wrote:
>
> pls read earlier email.
I did. It seems that your complaint is:
> So unless he explicitly typed a "From:" line (without quoting his name)
> into the top of his changelog, some piece of software somewhere has
> stripped the quotes when it was converting his name from the email
> headers into the git Author: line.
And yes, git will strip out all the crap and try to make it into a real
name.
The part _you_ don't seem to understand is that my point is
- git changed that "From:" line to an "Author:" line
- "git log" isn't an email system. It's a human-readable (and
machine-parseable, for that matter) log.
If you want to turn it into emails, you need to follow the email rules.
You're cutting-and-pasting anyway, it's not like this is fundamentally
hard.
Linus
^ permalink raw reply
* Re: [PATCH] Add Pascal/Delphi (.pas file) funcname pattern.
From: Avery Pennarun @ 2008-08-01 20:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080801202059.GS32184@machine.or.cz>
On 8/1/08, Petr Baudis <pasky@suse.cz> wrote:
> On Fri, Aug 01, 2008 at 03:45:15PM -0400, Avery Pennarun wrote:
> > + { "pas", "\\(^\\(procedure\\|function\\|constructor\\|"
> > + "destructor\\|interface\\|implementation\\|"
> > + "type|initialization|finalization\\).*$\\)"
> > + "\\|\\(^.*=[ \t]*\\(class\\|record\\).*$\\)" },
>
> Wouldn't it be better to make the second pattern start on new line
> instead of the outer \(\|\)?
I didn't even know that was possible, but suddenly I understand the
"java" pattern a lot better. Thanks!
> Why "type"?
Well, it's a subsection, but it's always followed by a class or record
definition anyway, so I guess it makes more sense to omit it, now that
you bring it up.
Have fun,
Avery
^ 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