Re: Moving (renaming) submodules, recipe/script
Am 07.01.2013 08:44, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: Am 07.01.2013 02:39, schrieb Jonathan Nieder: (just cc-ing Jens and Peter, who might be interested) I´m currently working on teaching mv to move submodules and intend to send those patches to the list after finishing submodule deinit. Thanks for a heads-up. As a couple of recent What's cooking message has stated, I'll shortly kick jl/submodule-deinit topic out of 'next' back to 'pu', so please make an update a replacement, not an incremental. If I recall the discussion correctly, I think we agreed that deinit should clear the slate, which means the submodule working tree should be removed and made into an empty directory without .git in it, and the last round we saw on the list didn't do that. Right, and me thinks that would warrant a --force option for deinit to do that even if the submodule contains local changes (which would make deinit fail otherwise). Additionally Michael and Marc spoke up that they would rather have a --all option to deinit all initialized submodules and git submodule deinit without any arguments should just produce a usage message. As I saw no voices against it that'll be part of the next iteration too. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] status: report ignored yet tracked directories
On Sun, Jan 06, 2013 at 05:40:46PM +0100, Antoine Pelisse wrote: Looking at your fix and remembering how the index hashing works, I think the answer is that: 1. This bug only affects directories, because they are the only thing that can be simultaneously ignored and untracked and tracked (i.e., they have entries of both, and we are using DIR_SHOW_OTHER_DIRECTORIES). 2. When core.ignorecase is false, the index name hash contains only the file entries, and cache_name_exists returns an exact match. So it doesn't matter if we make an extra check when adding the directory via dir_add_name; we know that it will not be there, and the final check is a no-op. 3. When core.ignorecase is true, we also store directory entries in the index name hash, and this extra check is harmful; the entry does not really exist in the index, and we still need to add it. Yes, because of this couple of lines I guess (name-hash.c, hash_index_entry()): if (ignore_case) hash_index_entry_directories(istate, ce); Exactly. I couldn't remember at first why this was the case, but after reading 5102c61 (Add case insensitivity support for directories when using git status, 2010-10-03) again, I think it is because we cannot do a partial-name lookup via the hash (i.e., the hash for foo/ and foo/bar have no relation to each other). Not related to your patch, obviously, but it was the missing piece for me to understand why the code was doing what it does. I think in the normal file case, we'd expect treat_path to just tell us that it is handled, and we would not ever call dir_add_name in the first place. But what if we have an index entry for a file, but the working tree now contains a directory? The directory is treated as any other untracked directory (it never matches indexed file because of the trailing /). Ah, right. That makes sense. I _think_ we still do not hit this code path in that instance, because we will end up in treat_directory, and we will end up checking directory_exists_in_index. And I cannot get it to misbehave in practice. So I think your fix is correct, but the exact how and why is a bit subtle. Thanks a lot for the help, I will try to come up with a better commit message now. Thanks. I think the patch is right, but the reasoning is just a bit subtle. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] t0024, t5000: use test_lazy_prereq for UNZIP
René Scharfe wrote:
--- a/t/t0024-crlf-archive.sh
+++ b/t/t0024-crlf-archive.sh
@@ -5,6 +5,11 @@ test_description='respect crlf in git archive'
. ./test-lib.sh
GIT_UNZIP=${GIT_UNZIP:-unzip}
+test_lazy_prereq UNZIP '
+ $GIT_UNZIP -v /dev/null 21
+ test $? -ne 127
Micronit: now that this is part of a test, there is no more need to
silence its output. The unzip -v output could be useful to people
debugging with t0024-crlf-archive.sh -v -i.
With or without that change, this is a nice cleanup and obviously
correct, so
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] t5002: check if unzip supports symlinks
René Scharfe wrote: Only add a symlink to the repository if both the filesystem and unzip support symlinks. To check the latter, add a ZIP file containing a symlink, created like this with InfoZIP zip 3.0: $ echo sample text textfile $ ln -s textfile symlink $ zip -y infozip-symlinks.zip textfile symlink Hm. Do some implementations of unzip not support symlinks, or is the problem that some systems build Info-ZIP without the SYMLINKS option? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
-Original Message- From: Junio C Hamano Sent: Monday, January 07, 2013 2:29 AM Jason Pyeron writes: [administrivia: please never cull CC list when you respond to a message on this list without a good reason] Apologies, I just have 4 copies of every message and was trying to save other that pain. circumvent the Cygwin API (and by extension, Cygwin project goals). So, perhaps a better path forward is to disable / remove the above code by default. (Those wanting a native Win32 git should just use the native Win32 git). Or a make option... It already is a runtime option, isn't it? I do not have much stake in this personally, but IIRC, the (l)stat workaround was back then found to make Cygwin version from unusably slow to slow but torelable, as our POSIX-y codebase assumes that lstat is fairly efficient, which Cygwin cannot satisify because it Is there already a set of test cases I can run to validate that this is still true? has call many win32 calls to collect bits that we do not even look at, in order to give faithful emulation. It does place extra maintenance burden (e.g. conditional compilation depending on the header file the particular version of Cygwin installation the user has at hand) on us, but as long as it works, the ugly hack is fairly There seems to be only 2 valid use cases here, with regards to cygwin. 1. Do it the normal posix way, and dont hack it up. 2. For speed reasons, merge in native windows/non-posix functions. I would not care about the user's cygwin version because the cygwin supporters won't either. In both cases assume the latest cygwin libraries. If there is a specific user with a use case for an older version of cygwin libraries then we can cross that bridge when (if) we arrive at it. isolated and I do not see a reason to unconditionally rip it out, especially if the reasoning behind such move is on All programs that run in Cygwin environment has to be POSIX only and must not use Win32 API directly, even in a controlled way. I presently do not care if it stays or goes. But if someone were to bring this to the cygwin mailing list it would be a headache to deal with the hacked way. They would likely be more receptive to increasing the efficiency of the lstat than other approaches. It is a completely different matter if the direct win32 calls we make, bypassing (l)stat emulation, somehow change the internal state of win32 resources Cygwin controls and violates the invariants Cygwin API implemenation expects, breaking later calls to it. I do not know that is the case here, but I doubt it. I agree, it is not going to break anything here. Those libraries are just a way of presenting the Windows API without using Microsoft files and making it easier to wrap the POSIX apis to it. smime.p7s Description: S/MIME cryptographic signature
Re: recovering a corrupted git repo
On Mon, Jan 7, 2013 at 4:44 AM, Phillip Susi ps...@ubuntu.com wrote: I have not had any issue until I ran a git fsck recently, which repored gzip and crc errors in some pack files. git fsck does not seem to repair the errors, only report them. I would like to try to rebuild my repository, without downloading any more from the origin than I have to. All of the commits I have added seem to still be intact, so I assume the corruption in somewhere in the upstream history packs. How can I correct the errors, and fetch the corrupted upstream history, while preserving my patches? So far I have exported my patches as bundles, and made a fresh clone from upstream, then pulled the bundles back in, but there must be a better way that only fetches the corrupted bits from upstream? The documentation about fixing broken repo is this one: https://git.wiki.kernel.org/index.php/GitFaq#fix-broken-repo Hope this helps, Christian. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Jan 2013, #03; Sun, 6)
On Sun, Jan 06, 2013 at 06:42:16PM -0800, Junio C Hamano wrote: * jk/maint-fast-import-doc-dedup-done (2013-01-05) 1 commit - git-fast-import(1): remove duplicate --done option Will merge to 'next' and 'master' as a quick oops fix. The logical order reorganization can come after that is done and can cook longer in 'next'. I was going to re-send this to change the quoting of 'done' to `done`, which is what the original version had. Is there still time for that or should I send a separate patch? John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] git-fast-import(1): remove duplicate '--done' option
On Sat, Jan 05, 2013 at 04:06:52PM +, John Keeping wrote: The '--done' option to git-fast-import is documented twice in its manual page. Combine the best bits of each description, keeping the location of the instance that was added first. Signed-off-by: John Keeping j...@keeping.me.uk --- Changed since v1: 'done' = `done` I'll wait a bit longer for comments on [1] before I have another go at the full re-organisation of this page. [1] http://article.gmane.org/gmane.comp.version-control.git/212805 Documentation/git-fast-import.txt | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index 68bca1a..4ef5721 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -39,10 +39,6 @@ OPTIONS See ``Date Formats'' below for details about which formats are supported, and their syntax. --- done:: - Terminate with error if there is no 'done' command at the - end of the stream. - --force:: Force updating modified existing branches, even if doing so would cause commits to be lost (as the new commit does @@ -108,7 +104,8 @@ OPTIONS output. --done:: - Require a `done` command at the end of the stream. + Terminate with error if there is no `done` command at the + end of the stream. This option might be useful for detecting errors that cause the frontend to terminate before it has started to write a stream. -- 1.8.0.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] git-completion.bash: add support for path completion
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 05/01/2013 21:23, Marc Khouzam ha scritto: [...] Below are two suggestions that are in line with this effort but that are not regressions. A) It would be nice if git commit -a TAB also completed with untracked files $ git commit -a foo fatal: Paths with -a does not make sense. So git commit -a TAB should not suggest untracked files; instead it should suggest nothing. [...] Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDq0PoACgkQscQJ24LbaUSTNwCfWt7a1Tdg9u5sd6B3FXCEFj1/ sBwAoIv4B2y4MUQgLNafY2PTWx4giSfD =tb3O -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] two-way read-tree can write null sha1s into index
On Thu, Jan 03, 2013 at 02:33:09PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Oh, I agree it's insane to try to carry through unmerged entries. I'm
just concerned that not all code paths are careful enough to check.
I would actually be surprised if some code path do assume somebody
might give them an index with conflicting entries in it and guard
against it. We have been coding under the index must exactly match
the second tree when three-way unpack_trees() begin requirement
since day one. An conflicted entry will appear as index and HEAD
not matching and will cause reject_merge() early in threeway_merge()
anyway, no?
Hmm. There is code in threeway_merge to handle a few cases:
/*
* We start with cases where the index is allowed to match
* something other than the head: #14(ALT) and #2ALT, where it
* is permitted to match the result instead.
*/
/* #14, #14ALT, #2ALT */
if (remote !df_conflict_head head_match !remote_match) {
if (index !same(index, remote) !same(index, head))
return o-gently ? -1 : reject_merge(index, o);
return merged_entry(remote, index, o);
}
but I do not think we have to worry, because we know that the index will
never match remote, either (and merged_entry has already been taught to
be wary of the conflicted bit, anyway). I'm not entirely clear on how
that would get triggered if all of the callers avoid operating on a
modified index.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] Use %B for Split Subject/Body
2013/1/1 Junio C Hamano gits...@pobox.com: David A. Greene gree...@obbligato.org writes: From: Techlive Zheng techlivezh...@gmail.com Use %B to format the commit message and body to avoid an extra newline if a commit only has a subject line. Is this an unconditional improvement, or is it generally an improvement but for some users it may be a regression? I am guessing it is the former but am just making sure. Author:Techlive Zheng techlivezh...@gmail.com Signed-off-by: David A. Greene gree...@obbligato.org Please don't do Author: which does not add anything new. That is what From: is for. Instead it needs to be a sign-off. Also, is that a real name, I have to wonder? Hmm, sorry about the confusing. I am a Chinese, I coined that first name a couple years ago when I decided to have a unique name across the web. My real name is 郑文辉 in Chinese，translate to English by its pronucation is Wenhui Zheng，which means Zheng is acturally my real last name. The first name Wenhui does not have any meaning in English, so I coined it by Tech + Live, which I interprate it as Technological Living, thus, Techlive Zheng is the name I am currently using online. Here are some links: * Let the code talks. https://github.com/techlivezheng * I cross the great GFW to use twitter. https://twitter.com/techlivezheng * Also search Techlive Zheng in Google, the result should be unique to me. So, no doubt, I am a real person, just with kind of an uncommon name. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4] git-completion.bash: add support for path completion
-Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf Of Manlio Perillo Sent: Monday, January 07, 2013 8:43 AM To: Marc Khouzam Cc: Junio C Hamano; git@vger.kernel.org; sze...@ira.uka.de; felipe.contre...@gmail.com Subject: Re: [PATCH v4] git-completion.bash: add support for path completion -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 05/01/2013 21:23, Marc Khouzam ha scritto: [...] Below are two suggestions that are in line with this effort but that are not regressions. A) It would be nice if git commit -a TAB also completed with untracked files $ git commit -a foo fatal: Paths with -a does not make sense. So git commit -a TAB should not suggest untracked files; instead it should suggest nothing. You are right, I was confused. git commit --all TAB should also suggest nothing then. Thanks Marc-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] Use %B for Split Subject/Body
2013/1/1 Junio C Hamano gits...@pobox.com: David A. Greene gree...@obbligato.org writes: From: Techlive Zheng techlivezh...@gmail.com Use %B to format the commit message and body to avoid an extra newline if a commit only has a subject line. Is this an unconditional improvement, or is it generally an improvement but for some users it may be a regression? I am guessing it is the former but am just making sure. This patch will make sure the commits in the result branch by using `git-subtree split` stays intact as they were in the original branch. This patch will break the current existing branch that splitted before this patch, becuase these branches were splitted with the wrongly altered commit messages. Maybe a fallback option should be added to make sure these branches could still be updated. Though, this patch defintely should be merged, becuase no one expects his commit message be altered durging the splitting process. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG/PATCH] setup: Copy an environment variable to avoid overwrites
On Sat, Jan 5, 2013 at 1:35 AM, David Michael fedora@gmail.com wrote: It is possible for this pointer of the GIT_DIR environment variable to survive unduplicated until further getenv calls are made. The standards allow for subsequent calls of getenv to overwrite the string located at its returned pointer, and this can result in broken git operations on certain platforms. Signed-off-by: David Michael fedora@gmail.com --- I have encountered an issue with consecutive calls to getenv overwriting earlier values. Most notably, it prevents a plain git clone from working. Long story short: This value of GIT_DIR gets passed around setup.c until it reaches check_repository_format_gently. This function calls git_config_early, which eventually runs getenv(HOME). When it returns back to check_repository_format_gently, the gitdir variable contains my home directory path. The end result is that I wind up with ~/objects/ etc. and a failed repository clone. (Simply adding a bare getenv(GIT_DIR) afterwards to reset the pointer also corrects the problem.) Since other platforms are apparently working, yet this getenv behavior is supported by the standards, I am left wondering if this could be a symptom of something else being broken on my platform (z/OS). Can anyone more familiar with this part of git identify any condition that obviously should not be occurring? Thanks. I have some patches of a similar nature here: https://github.com/kusma/git/commits/work/getenv-safety These were written for an earlier version of the UTF-8 patches for Git for Windows, where we were looking into allowing getenv to use a static buffer to convert the environment variables from UTF-16 (which is what Windows maintains) to UTF-8. We ended converting the environment on start-up instead, so these weren't needed for us. But perhaps they can be of use to someone else? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add getenv.so for catching invalid getenv() use via LD_PRELOAD
Hi, On Sat, Jan 5, 2013 at 3:55 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: Perhaps this will help the getenv bug hunting (I assume we do the hunting on Linux platform only). So far it catches this and is stuck at getenv in git_pager(). For the record: I have been testing a macro pointing getenv at an alternate implementation for the purpose of my port. This alternate function will return a unique pointer for each variable, as opposed to using the same static buffer. IBM considers this function a proprietary z/OS extension (whereas the other is labelled as conforming to half a dozen standards), but it seems to be more in-line with the behavior git expects. So I agree this patch is useful for reaching strict conformance to the published specs, but I think we can go back to assuming no known platforms are broken and unusable because of this. Thanks. David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Moving (renaming) submodules, recipe/script
Jens Lehmann jens.lehm...@web.de writes: Right, and me thinks that would warrant a --force option for deinit to do that even if the submodule contains local changes (which would make deinit fail otherwise). Probably. Additionally Michael and Marc spoke up that they would rather have a --all option to deinit all initialized submodules and git submodule deinit without any arguments should just produce a usage message. As I saw no voices against it that'll be part of the next iteration too. Yeah, I forgot about that possible surprise of deiniting everything under the sun by default. I am not sure if --all is a good way forward, though. Can you defeat it with git submodule deinit ./--all or something to limit the target only to one submodule whose unfortunate location is named as such? If you have such a support, I have this suspicion that you already get a short and explicit way to say everything under the current directory with git submodule deinit . for free. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] t0024, t5000: clear variable UNZIP, use GIT_UNZIP instead
Am 07.01.2013 06:16, schrieb Jonathan Nieder:
René Scharfe wrote:
InfoZIP's unzip takes default parameters from the environment variable
UNZIP. Unset it in the test library and use GIT_UNZIP for specifying
alternate versions of the unzip command instead.
t0024 wasn't even using variable for the actual extraction. t5000
was, but when setting it to InfoZIP's unzip it would try to extract
from itself (because it treats the contents of $UNZIP as parameters),
which failed of course.
That would only happen if the UNZIP variable was already exported,
right?
We don't want any parameters a user may have been specified influence
the test. I'm not sure if someone actually sets that variable for that
purpose, though.
My main use case is running individual test scripts with an alternative
unzip binary, and with the patch this works as expected:
$ cd t
$ GIT_UNZIP=/usr/pkg/bin/unzip ./t5000-tar-tree.sh
The patch makes sense and takes care of all uses of ${UNZIP} I can
find, and it even makes the quoting consistent so a person can put
their copy of unzip under /Program Files. For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks!
René
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] t0024, t5000: use test_lazy_prereq for UNZIP
Am 07.01.2013 09:45, schrieb Jonathan Nieder:
René Scharfe wrote:
--- a/t/t0024-crlf-archive.sh
+++ b/t/t0024-crlf-archive.sh
@@ -5,6 +5,11 @@ test_description='respect crlf in git archive'
. ./test-lib.sh
GIT_UNZIP=${GIT_UNZIP:-unzip}
+test_lazy_prereq UNZIP '
+ $GIT_UNZIP -v /dev/null 21
+ test $? -ne 127
Micronit: now that this is part of a test, there is no more need to
silence its output. The unzip -v output could be useful to people
debugging with t0024-crlf-archive.sh -v -i.
Oh, yes, good point.
With or without that change, this is a nice cleanup and obviously
correct, so
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
Thanks,
René
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] t5002: check if unzip supports symlinks
Am 07.01.2013 09:52, schrieb Jonathan Nieder: René Scharfe wrote: Only add a symlink to the repository if both the filesystem and unzip support symlinks. To check the latter, add a ZIP file containing a symlink, created like this with InfoZIP zip 3.0: $ echo sample text textfile $ ln -s textfile symlink $ zip -y infozip-symlinks.zip textfile symlink Hm. Do some implementations of unzip not support symlinks, or is the problem that some systems build Info-ZIP without the SYMLINKS option? The unzip supplied with NetBSD 6.0.1, which is based on libarchive, doesn't support symlinks. It creates a file with the link target path as its only content for such entries. I assume that Info-ZIP is compiled with the SYMLINKS option on all platforms whose default filesystem supports symbolic links. Except on Windows perhaps, where it's complicated. For the test script there is no difference: If we don't have a tool to verify symlinks in archives, we better skip that part. René -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/8] Use %B for Split Subject/Body
郑文辉(Techlive Zheng) techlivezh...@gmail.com writes:
Though, this patch defintely should be merged, becuase no one expects
his commit message be altered durging the splitting process.
Are you saying that after double-checking what was posted? It said
something like this below, which does not look like 'definitely
should be' to me.
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 920c664..f2b6d4a 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -296,7 +296,12 @@ copy_commit()
# We're going to set some environment vars here, so
# do it in a subshell to get rid of them safely later
debug copy_commit {$1} {$2} {$3}
+ # Use %B rather than %s%n%n%b to handle the special case of a
+ # commit that only has a subject line. We don't want to
+ # introduce a newline after the subject, causing generation of
+ # a new hash.
git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%s%n%n%b'
$1 |
+# git log -1 --pretty=format:'%an%n%ae%n%ad%n%cn%n%ce%n%cd%n%B' $1 |
(
read GIT_AUTHOR_NAME
read GIT_AUTHOR_EMAIL
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] status: always report ignored tracked directories
On 06.01.13 23:09, Antoine Pelisse wrote:
[snip]
Signed-off-by: Antoine Pelisse apeli...@gmail.com
---
dir.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/dir.c b/dir.c
index 9b80348..f836590 100644
--- a/dir.c
+++ b/dir.c
@@ -672,7 +672,8 @@ static struct dir_entry *dir_entry_new(const char
*pathname, int len)
static struct dir_entry *dir_add_name(struct dir_struct *dir, const char
*pathname, int len)
{
- if (cache_name_exists(pathname, len, ignore_case))
+ if (!(dir-flags DIR_SHOW_IGNORED)
+ cache_name_exists(pathname, len, ignore_case))
return NULL;
ALLOC_GROW(dir-entries, dir-nr+1, dir-alloc);
@@ -877,11 +878,7 @@ static int treat_file(struct dir_struct *dir, struct
strbuf *path, int exclude,
if (exclude)
exclude_file = !(dir-flags DIR_SHOW_IGNORED);
else if (dir-flags DIR_SHOW_IGNORED) {
- /*
- * Optimization:
- * Don't spend time on indexed files, they won't be
- * added to the list anyway
- */
+ /* Always exclude indexed files */
struct cache_entry *ce = index_name_exists(the_index,
path-buf, path-len, ignore_case);
--
1.7.12.4.3.g90f5e2d
The bad news: the patch does not apply.
The good news: t7061 passes on pu,
and dir.c seems to be changes as needed:
commit 1f4e17c6c9833f17dc6bbf045f8a8d6378dcb417
Merge: dee1fa4 cc37e5b
Author: Junio C Hamano gits...@pobox.com
Date: Sun Jan 6 23:46:29 2013 -0800
Merge branch 'nd/parse-pathspec' into pu
which comes from Duy:
commit cc37e5bf18ca11d9a884bddfebcdff61df3e6279
Author: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Date: Sun Jan 6 13:21:08 2013 +0700
Convert more init_pathspec() to parse_pathspec()
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation on depth option in git clone.
--- Documentation/git-clone.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt index 7fefdb0..e76aa50 100644 --- a/Documentation/git-clone.txt +++ b/Documentation/git-clone.txt @@ -186,7 +186,8 @@ objects from the source repository into a pack in the cloned repository. it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes - as patches. + as patches. The depth should be at least 1. If it is 0 or + below, the cloned repository will not be shallow. --single-branch:: Clone only the history leading to the tip of a single branch, -- 1.8.1.80.g3e293fb.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] test: Add target test-lint-shell-syntax
Torsten Bögershausen tbo...@web.de writes: Sorry for late answer, but there is a problem (both linux and Mac OS X) :-( $ make test-lint does not do shel syntax check, neither $ make test-lint-shell-syntax In which directory? $ make -C t test-lint-shell-syntax ... passes silently ... $ ed t/t-basic.sh /test_expect_success/ a which sh . w q $ make -C t test-lint-shell-syntax t-basic.sh:28: error: which is not portable (please use type): which sh make: *** [test-lint-shell-syntax] Error 1 If you edit out '@' (but nothing else) from this line: @'$(PERL_PATH_SQ)' check-non-portable-shell.pl $(T) and run the above again, you would see that it is running this shell command: '/usr/bin/perl' check-non-portable-shell.pl t-basic.sh t0001-init.sh ... If you introduce a Perl syntax error to check-non-portable-shell.pl, like this, you will get: $ make -C t test-lint-shell-syntax syntax error at check-non-portable-shell.pl line 11, near whoa So... is your shell broken? The above seems to work for dash, bash, ksh and zsh. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] refs: do not use cached refs in repack_without_ref
...[Sorry about the previous HTML reposts] Jeff King p...@peff.net wrote: On Mon, Dec 31, 2012 at 03:30:53AM -0700, Martin Fick wrote: The general approach is to setup a transaction and either commit or abort it. A transaction can be setup by renaming an appropriately setup directory to the ref.lock name. If the rename succeeds, the transaction is begun. Any actor can abort the transaction (up until it is committed) by simply deleting the ref.lock directory, so it is not at risk of going stale. Deleting a directory is not atomic, as you first have to remove the contents, putting it into a potentially inconsistent state. I'll assume you deal with that later... Right, these simple single file transactions have at best 1 important file/directory in them, once deleted the transaction is aborted (can no longer complete). However to support multi file transactions, a better approach is likely to rename the uuid directory to have a .delete extension before deleting stuff in it. One important piece of the transaction is the use of uuids. The uuids provide a mechanism to tie the atomic commit pieces to the transactions and thus to prevent long sleeping process from inadvertently performing actions which could be out of date when they wake finally up. Has this been a problem for you in practice? No, but as you say, we don't currently hold locks for very long. I anticipate it being a problem in a clustered environment when transactions start spanning repos from java processes, with insane amounts of RAM, which can sometimes have unpredictable indeterminately long java GC cycles at inopportune times.. It would seem short sighted if Gerrit at least did not assume this will be a problem. But, deletes today in git are not so short and Michael's fixes may make things worse? But, as you point out, that should perhaps be solved a different way. Avoiding this is one of the reasons that git does not take out long locks; instead, it takes the lock only at the moment it is ready to write, and aborts if it has been updated since the longer-term operation began. This has its own problems (you might do a lot of work only to have your operation aborted), but I am not sure that your proposal improves on that. It does not, it might increase this. Git typically holds ref locks for a few syscalls. If you are conservative about leaving potentially stale locks in place (e.g., give them a few minutes to complete before assuming they are now bogus), you will not run into that problem. In a distributed environment even a few minutes might not be enough, processes could be on a remote server with a temporarily split network, that could cause delays longer than your typical local expectations. But there is also the other piece of this problem, how do you detect stale locks? How long will it be stale until a user figures it out and reports it? How many other users will simply have failed pushes and wonder why without reporting them? In each case, the atomic commit piece is the renaming of a file. For the create and update pieces, a file is renamed from the ref.lock dir to the ref file resulting in an update to the sha for the ref. I think we've had problems with cross-directory renames on some filesystems, but I don't recall the details. I know that Coda does not like cross-directory links, but cross-directory renames are OK (and in fact we fall back to the latter when the former does not work). Ah, here we go: 5723fe7 (Avoid cross-directory renames and linking on object creation, 2008-06-14). Looks like NFS is the culprit. If the renames fail we can fall back to regular file locking, the hard part to detect and deal with would be if the renames don't fail but become copies/mkdirs. In the case of a delete, the actor may verify that ref currently contains the sha to prune if it needs to, and then renames the ref file to ref.lock/uuid/delete. On success, the ref was deleted. Whether successful or not, the actor may now simply delete the ref.lock directory, clearing the way for a new transaction. Any other actor may delete this directory at any time also, likely either on conflict (if they are attempting to initiate a transaction), or after a grace period just to cleanup the FS. Any actor may also safely cleanup the tmp directories, preferably also after a grace period. Hmm. So what happens to the delete file when the ref.lock directory is being deleted? Presumably deleting the ref.lock directory means doing it recursively (which is non-atomic). But then why are we keeping the delete file at all, if we're just about to remove it? We are not trying to keep it, but we need to ensure that our transaction has not yet been aborted: the rename does this. If we just deleted the file, we may sleep and another transaction may abort our transaction and complete before we wake up and actually delete the file. But by using
[PATCH] git clone depth of 0 not possible.
Currently it is not possible to have a shallow depth of just 0, i.e. only one commit in that repository after cloning. The minimum number of commits is 2, caused by depth=1. I had no good idea how to add this behavior to git clone as the depth variable in git_transport_options struct (file transport.h) uses value 0 for another meaning, so it would have need changes at all places, where the transport options depth is being used (e.g. fetch) So I documented the current behavior, see attached patch. Stefan Beller (1): Documentation on depth option in git clone. Documentation/git-clone.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 1.8.1.80.g3e293fb.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] status: always report ignored tracked directories
Antoine Pelisse apeli...@gmail.com writes:
First, thanks for working on this.
The explanation is a bit confusing, especially for people like me,
as it does not make it clear that there are two kinds of paths in
the index. Files can be added to the index (git add and then
shown via ls-files) and these are what we usually call files in
the index. But there is a separate name hash that keeps track of
paths the index knows about in play, and that is what is discussed
in the description.
Tracked directories (i.e. directories containing tracked files)
that are ignored must be reported as ignored if they contain
untracked files.
Currently, files in the index can't be reported as ignored and are
automatically dropped from the list:
file in the index will never be ignored, period. Some paths the
index knows about, namely, directory names in name hash, may need to
be reported as ignored.
It is not clear what list the above dropped from the list refers
to. The list of paths that becomes the result of status?
- When core.ignorecase is false, directories (which are not directly
tracked) are not listed as part of the index, and the directory can be
shown as ignored.
- When core.ignorecase is true on the other hand, directories are
reported as part of the index, and the directory is dropped, thus not
displayed as ignored.
Fix that behavior by allowing indexed file to be added when looking for
ignored files.
- Ignored tracked and untracked directories are treated the same way
when looking for ignored files, so we should not care about their index
status.
- Files are dismissed by treat_file() if they belong to the
index, so that step would have been a no-op anyway.
Here is my attempt...
When enumerating paths that are ignored, paths the index knows
about are not included in the result. The index knows about
check is done by consulting the name hash, not the actual
contents of the index:
- When core.ignorecase is false, directory names are not in the
name hash, and ignored ones are shown as ignored (directories
can never be tracked anyway).
- When core.ignorecase is true, however, the name hash keeps
track of the names of directories, in order to detect
additions of the paths under different cases. This causes
ignored directories to be mistakenly excluded when
enumerating ignored paths.
Stop excluding directories that are in the name hash when
looking for ignored files in dir_add_name(); the names that are
actually in the index are excluded much earlier in the callchain
in treat_file(), so this fix will not make them mistakenly
identified as ignored.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
Reviewed-by: Jeff King p...@peff.net
Signed-off-by: Junio C Hamano gits...@pobox.com
diff --git a/dir.c b/dir.c
index 9b80348..f836590 100644
--- a/dir.c
+++ b/dir.c
@@ -672,7 +672,8 @@ static struct dir_entry *dir_entry_new(const char
*pathname, int len)
static struct dir_entry *dir_add_name(struct dir_struct *dir, const char
*pathname, int len)
{
- if (cache_name_exists(pathname, len, ignore_case))
+ if (!(dir-flags DIR_SHOW_IGNORED)
+ cache_name_exists(pathname, len, ignore_case))
return NULL;
ALLOC_GROW(dir-entries, dir-nr+1, dir-alloc);
@@ -877,11 +878,7 @@ static int treat_file(struct dir_struct *dir, struct
strbuf *path, int exclude,
if (exclude)
exclude_file = !(dir-flags DIR_SHOW_IGNORED);
else if (dir-flags DIR_SHOW_IGNORED) {
- /*
-* Optimization:
-* Don't spend time on indexed files, they won't be
-* added to the list anyway
-*/
+ /* Always exclude indexed files */
struct cache_entry *ce = index_name_exists(the_index,
path-buf, path-len, ignore_case);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Prevent space after directories in tcsh completion
If git-completion.bash returns a single directory as a completion,
tcsh will automatically add a space after it, which is not what the
user wants.
This commit prevents tcsh from doing this.
Also, a check is added to make sure the tcsh version used is recent
enough to allow completion to work as expected.
Signed-off-by: Marc Khouzam marc.khou...@ericsson.com
---
This update is meant to have tcsh completion work better if the
feature git-completion.bash: add support for path completion
is accepted.
See http://www.mail-archive.com/git@vger.kernel.org/msg14137.html
This commit does not depend on that other feature though and can
be applied right away.
Furthermore, based on feedback I received, some users are running
versions of tcsh that are over 5 years old and don't provide the
proper support for this script. I've added a check to let the user
know of such (sad) situation nicely.
Thanks
Marc
contrib/completion/git-completion.tcsh | 33 +
1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index 8aafb63..3e3889f 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -13,6 +13,7 @@
#
# To use this completion script:
#
+#0) You need tcsh 6.16.00 or newer.
#1) Copy both this file and the bash completion script to ${HOME}.
# You _must_ use the name ${HOME}/.git-completion.bash for the
# bash script.
@@ -24,6 +25,15 @@
#set autolist=ambiguous
# It will tell tcsh to list the possible completion choices.
+set __git_tcsh_completion_version = `\echo ${tcsh} | \sed 's/\./ /g'`
+if ( ${__git_tcsh_completion_version[1]} 6 || \
+ ( ${__git_tcsh_completion_version[1]} == 6 \
+ ${__git_tcsh_completion_version[2]} 16 ) ) then
+ echo git-completion.tcsh: Your version of tcsh is too old, you need
version 6.16.00 or newer. Git completion will not work.
+ exit
+endif
+unset __git_tcsh_completion_version
+
set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
@@ -64,9 +74,7 @@ fi
_\${1}
IFS=\$'\n'
-if [ \${#COMPREPLY[*]} -gt 0 ]; then
- echo \${COMPREPLY[*]} | sort | uniq
-else
+if [ \${#COMPREPLY[*]} -eq 0 ]; then
# No completions suggested. In this case, we want tcsh to perform
# standard file completion. However, there does not seem to be way
# to tell tcsh to do that. To help the user, we try to simulate
@@ -85,19 +93,20 @@ else
# We don't support ~ expansion: too tricky.
if [ \${TO_COMPLETE:0:1} != ~ ]; then
# Use ls so as to add the '/' at the end of directories.
- RESULT=(\`ls -dp \${TO_COMPLETE}* 2 /dev/null\`)
- echo \${RESULT[*]}
-
- # If there is a single completion and it is a directory,
- # we output it a second time to trick tcsh into not
adding a space
- # after it.
- if [ \${#RESULT[*]} -eq 1 ] [ \${RESULT[0]: -1} ==
/ ]; then
- echo \${RESULT[*]}
- fi
+ COMPREPLY=(\`ls -dp \${TO_COMPLETE}* 2 /dev/null\`)
fi
fi
fi
+# tcsh does not automatically remove duplicates, so we do it ourselves
+echo \${COMPREPLY[*]} | sort | uniq
+
+# If there is a single completion and it is a directory, we output it
+# a second time to trick tcsh into not adding a space after it.
+if [ \${#COMPREPLY[*]} -eq 1 ] [ \${COMPREPLY[0]: -1} == / ]; then
+ echo \${COMPREPLY[*]}
+fi
+
EOF
# Don't need this variable anymore, so don't pollute the users environment
--
1.8.1.367.g8e14972.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the suggestion to use parsecvs, which is currently broken.
Heiko Voigt hvo...@hvoigt.net writes: Hi, On Fri, Dec 28, 2012 at 11:42:00PM -0500, Eric S. Raymond wrote: Heiko Voigt hvo...@hvoigt.net: Maybe you could add that information to the parsecvs compile instructions? I think just because it takes some effort to compile does not justify to remove this useful pointer here. When I was converting a legacy cvs repository this pointer would have helped me a lot. I'm parsecvs's maintainer now. It's not in good shape; there is at least one other known showstopper besides the build issue. I would strongly prefer to direct peoples' attention away from it until I have time to fix it and cut a release. This is not a distant prospect - two or three weeks out, maybe. So for this short amount of time you want to change gits documentation? Is this hint causing you trouble? Are there many people asking for support because of that? Even if it takes some effort to get parsecvs running I would like to keep the hint to a good and proven cvs importer. I do not mind changing the documentation, but now I re-read the change, I tend to agree that dropping the last (un)maintained version of parsecvs may be detrimental. Most people will not download parsecvs from keith's page, but first will try the one shipped with their distros, and the recent maintainer change for that tool would not have any impact to these users. But at the same time, by the time this change reaches these users who may benefit by the mention of parsecvs via the distro route, the situation may be different, so I do not think it is such a big deal. In the longer term, if parsecvs is revived either by Eric or somebody else, we will add the mention back to the documentation, probably with an updated URL. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
The tip of 'next' has been rewound.
Just to let you contributors know, your next git fetch will notice that remotes/origin/next has been rewound. Two topics have been kicked back to 'pu', and the branch has been reordered somewhat. I'll start merging bugfix topics that have graduated to master since v1.8.1 to maint so that we can have v1.8.1.1 sometime next week. We haven't seen any real regression report for v1.8.1 since tagging it, and it has been a week, so this may be the first 'maint' release without brown paper bag regression fix for quite some time ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] status: always report ignored tracked directories
Here is my attempt... When enumerating paths that are ignored, paths the index knows about are not included in the result. The index knows about check is done by consulting the name hash, not the actual contents of the index: - When core.ignorecase is false, directory names are not in the name hash, and ignored ones are shown as ignored (directories can never be tracked anyway). - When core.ignorecase is true, however, the name hash keeps track of the names of directories, in order to detect additions of the paths under different cases. This causes ignored directories to be mistakenly excluded when enumerating ignored paths. Stop excluding directories that are in the name hash when looking for ignored files in dir_add_name(); the names that are actually in the index are excluded much earlier in the callchain in treat_file(), so this fix will not make them mistakenly identified as ignored. Signed-off-by: Antoine Pelisse apeli...@gmail.com Reviewed-by: Jeff King p...@peff.net Signed-off-by: Junio C Hamano gits...@pobox.com I like it a lot, thanks to both of you -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove the suggestion to use parsecvs, which is currently broken.
Junio C Hamano gits...@pobox.com: In the longer term, if parsecvs is revived either by Eric or somebody else, we will add the mention back to the documentation, probably with an updated URL. I'm working on the revival right now. Repository generation is still broken, and likely to remain so until I can make the export-stream stage work, but just a few minutes ago I coaxed it into generating what looks like graphviz markup describing a commit graph on standard output. Even though dot(1) barfs on the markup, this is encouraging. It almost certainly means that the analysis and parsing stages aren't broken, and by stubbing out enough functions I can figure out what is being passed to the broken repository-maker well enough for my purposes. Actually, I've already figured out how to generate blob and commit-header markup. The hard part is generating fileops; I don't quite understand the generated data structures well enough to do that yet. But I'm making progress, and feeling more optimistic than I was yesterday. In related news, I've sent Michael Haggerty patches that fix the visible problems with cvs2git that I enumerated in previous mail. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] list_lookup: create case and length search
Junio C Hamano gits...@pobox.com writes: Antoine Pelisse apeli...@gmail.com writes: Create a new function to look-up a string in a string_list, but: - add a new parameter to ignore case differences - add a length parameter to search for a substring The idea is to avoid several copies (lowering a string before searching it when we just want to ignore case), or copying a substring of a bigger string to search it in the string_list Signed-off-by: Antoine Pelisse apeli...@gmail.com --- I did not read beyond the log message and the function signature of the updated get_entry_index(), but it strikes me insane to build a sorted list using case sensitive full string comarison and then to look for an element in that list using a different comparison criteria (e.g. case insensitive comparison) and to expect the bisection search to still work. Shouldn't the codepath that builds the string-list be sorting the list in case insensitive way from the beginning if this were to work correctly? It seems to suggest to me that this are the keys case sensitive? bit belongs to the entire struct string_list structure as its property (similar to the way do the keys need to be strdup'ed? bit), not something you would flip per invocation basis of the lookup function. Also isn't size_t an unsigned type? What does it even mean to pass -1 to it, and propagate it down to strncmp()? If you have a list sorted by a key, and if you want to query it with a partial prefix of a possibly valid key, I think you shouldn't have to add the length search at all. The existing look up function would return the location in the list that short key would have been inserted, which would come before the first entry that your short key is a prefix of, so the caller can iterate the list from there to find all entries. In other words, if existing list has aaa, bba, and bbc, and you want to grab entries that begin with bb, you can ask for bb to the loop up function, which would say the key does not exist in the list, but it would be inserted before this 'bba' entry. Then you can discover that bba and bbc both matches the shortened key you have, no? In the above, I mixed up which string is a prefix of which, but the overall comment still stands, I think. Your mailmap string list has Ee@eee (email part only) stored, while the record from author/committer line has EE@EEE TT s, to hold name, timestamp and zone. You have a pointer email pointing at the first E in that record, with maillen set to 6, and see if the mailmap contains a string that match EE@EEE. So I mixed up the prefix-ness of these strings. Let's address the case sensitivety first. The string_list_lookup() and your string_list_lookup_extended() functions both work on a string list that is built by add_mapping() function that asks string_list_find_insert_index() to find an insertion point in the sorted string list. If this is not done using the same case insensitive manner for a string list that is meant to be queried case insensitively, the resulting list is still sorted case sensitively, and look-up functions that work by binary search won't find what you are looking for when they try to find the string using case-insensitive comparison. The change to implement it would probably look like the attached patch. Assuming that we can leave the case sensitivity behind us that way, we still would need a new helper function string_list_lookup_prefix(struct string_list *, const char*, size_t) so that you can find an existing Ee@eee entry in the string list by email that points at EE@EEE TT s with maillen of 6. I am wondering if we can do that without adding the length-limited sort in the low-level get_entry_index() to do so, though. You could first ask string_list_find_insert_index() to locate the insertion point for EE@EEE TT s. That has to come after Ee@eee if it exists (or it could be De@eee in which case you know there is no match). 1. Ask string_list_find_insert_index() to locate EE@EEE TT... a. If it says there is an exact match, then that did not match EE@EEE list (you found EE@EEE TT s). You might still find EE@EEE before that record, though. Also your key may have been EE@EEE exactly, in which case you already found what you were looking for. b. If it says there is not an exact match, the returned value is pointing at a record that comes after EE@EEE TT s if you were to insert it, which definitely is after EE@EEE. So in either case, you know what you are looking for must come before string_list_find_insert_index() gave you. Let's call that position i. You still need to be careful that there could be an existing entry whose key is EE@EEE followed by a byte that sorts before or (we do not want to limit this new generic string-list function to operate only on e-mail addresses), though. So the
[PATCH v2 00/10] reroll of ap/log-mailmap
This is a reroll of the previous series Antoine posted on Saturday. A new patch string-list: allow case-insensitive string list teaches the string-list API that some string lists can be sorted case insensitively (actually, you can feed any custom two string comparison functions). The string_list_lookup_extended() function introduced by the previous series has been discarded. Instead, the third patch mailmap: remove email copy and length limitation introduces a helper function that takes a char *, size_t key that is not NUL terminated to look for a matching item in a string list, and uses that to update map_user() function, together with the fourth patch mailmap: simplify map_user() interface. All other patches are unmodified from Antoine's series (modulo wording tweaks here and there). Antoine Pelisse (9): Use split_ident_line to parse author and committer mailmap: remove email copy and length limitation mailmap: simplify map_user() interface mailmap: add mailmap structure to rev_info and pp pretty: use mailmap to display username and email log: add --use-mailmap option test: add test for --use-mailmap option log: grep author/committer using mailmap log: add log.mailmap configuration option Junio C Hamano (1): string-list: allow case-insensitive string list Documentation/config.txt | 4 + Documentation/git-log.txt | 5 ++ builtin/blame.c | 183 ++ builtin/log.c | 16 +++- builtin/shortlog.c| 54 -- commit.h | 1 + log-tree.c| 1 + mailmap.c | 94 +++- mailmap.h | 4 +- pretty.c | 114 - revision.c| 54 ++ revision.h| 1 + string-list.c | 17 - string-list.h | 4 + t/t4203-mailmap.sh| 56 ++ 15 files changed, 379 insertions(+), 229 deletions(-) -- 1.8.1.304.gf036638 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 02/10] Use split_ident_line to parse author and committer
From: Antoine Pelisse apeli...@gmail.com
Currently blame.c::get_acline(), pretty.c::pp_user_info() and
shortlog.c::insert_one_record() are parsing author name, email, time
and tz themselves.
Use ident.c::split_ident_line() for better code reuse.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/blame.c| 59 +++---
builtin/shortlog.c | 36 +
pretty.c | 35 +++-
3 files changed, 52 insertions(+), 78 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index cfae569..dd4aff9 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1343,8 +1343,9 @@ static void get_ac_line(const char *inbuf, const char
*what,
int mail_len, char *mail,
unsigned long *time, const char **tz)
{
- int len, tzlen, maillen;
- char *tmp, *endp, *timepos, *mailpos;
+ struct ident_split ident;
+ int len, tzlen, maillen, namelen;
+ char *tmp, *endp, *mailpos;
tmp = strstr(inbuf, what);
if (!tmp)
@@ -1355,7 +1356,10 @@ static void get_ac_line(const char *inbuf, const char
*what,
len = strlen(tmp);
else
len = endp - tmp;
- if (person_len = len) {
+ if (person_len = len)
+ goto error_out;
+
+ if (split_ident_line(ident, tmp, len)) {
error_out:
/* Ugh */
*tz = (unknown);
@@ -1364,47 +1368,26 @@ static void get_ac_line(const char *inbuf, const char
*what,
*time = 0;
return;
}
- memcpy(person, tmp, len);
- tmp = person;
- tmp += len;
- *tmp = 0;
- while (person tmp *tmp != ' ')
- tmp--;
- if (tmp = person)
- goto error_out;
- *tz = tmp+1;
- tzlen = (person+len)-(tmp+1);
+ namelen = ident.name_end - ident.name_begin;
+ memcpy(person, ident.name_begin, namelen);
+ person[namelen] = 0;
- *tmp = 0;
- while (person tmp *tmp != ' ')
- tmp--;
- if (tmp = person)
- goto error_out;
- *time = strtoul(tmp, NULL, 10);
- timepos = tmp;
+ maillen = ident.mail_end - ident.mail_begin + 2;
+ memcpy(mail, ident.mail_begin - 1, maillen);
+ mail[maillen] = 0;
- *tmp = 0;
- while (person tmp !(*tmp == ' ' tmp[1] == ''))
- tmp--;
- if (tmp = person)
- return;
- mailpos = tmp + 1;
- *tmp = 0;
- maillen = timepos - tmp;
- memcpy(mail, mailpos, maillen);
+ *time = strtoul(ident.date_begin, NULL, 10);
- if (!mailmap.nr)
- return;
+ tzlen = ident.tz_end - ident.tz_begin;
- /*
-* mailmap expansion may make the name longer.
-* make room by pushing stuff down.
-*/
- tmp = person + person_len - (tzlen + 1);
- memmove(tmp, *tz, tzlen);
+ /* Place tz at the end of person */
+ *tz = tmp = person + person_len - (tzlen + 1);
+ memcpy(tmp, ident.tz_begin, tzlen);
tmp[tzlen] = 0;
- *tz = tmp;
+
+ if (!mailmap.nr)
+ return;
/*
* Now, convert both name and e-mail using mailmap
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index b316cf3..03c6cd7 100644
--- a/builtin/shortlog.c
+++ b/builtin/shortlog.c
@@ -40,40 +40,24 @@ static void insert_one_record(struct shortlog *log,
char emailbuf[1024];
size_t len;
const char *eol;
- const char *boemail, *eoemail;
struct strbuf subject = STRBUF_INIT;
+ struct ident_split ident;
- boemail = strchr(author, '');
- if (!boemail)
- return;
- eoemail = strchr(boemail, '');
- if (!eoemail)
+ if (split_ident_line(ident, author, strlen(author)))
return;
/* copy author name to namebuf, to support matching on both name and
email */
- memcpy(namebuf, author, boemail - author);
- len = boemail - author;
- while (len 0 isspace(namebuf[len-1]))
- len--;
+ len = ident.name_end - ident.name_begin;
+ memcpy(namebuf, ident.name_begin, len);
namebuf[len] = 0;
/* copy email name to emailbuf, to allow email replacement as well */
- memcpy(emailbuf, boemail+1, eoemail - boemail);
- emailbuf[eoemail - boemail - 1] = 0;
-
- if (!map_user(log-mailmap, emailbuf, sizeof(emailbuf), namebuf,
sizeof(namebuf))) {
- while (author boemail isspace(*author))
- author++;
- for (len = 0;
-len sizeof(namebuf) - 1 author + len boemail;
-len++)
- namebuf[len] = author[len];
- while (0 len isspace(namebuf[len-1]))
-
[PATCH v2 01/10] string-list: allow case-insensitive string list
Some string list needs to be searched case insensitively, and for
that to work correctly, the string needs to be sorted case
insensitively from the beginning.
Allow a custom comparison function to be defined on a string list
instance and use it throughout in place of strcmp().
Signed-off-by: Junio C Hamano gits...@pobox.com
---
string-list.c | 17 +
string-list.h | 4
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/string-list.c b/string-list.c
index 397e6cf..6f3d8cf 100644
--- a/string-list.c
+++ b/string-list.c
@@ -7,10 +7,11 @@ static int get_entry_index(const struct string_list *list,
const char *string,
int *exact_match)
{
int left = -1, right = list-nr;
+ compare_strings_fn cmp = list-cmp ? list-cmp : strcmp;
while (left + 1 right) {
int middle = (left + right) / 2;
- int compare = strcmp(string, list-items[middle].string);
+ int compare = cmp(string, list-items[middle].string);
if (compare 0)
right = middle;
else if (compare 0)
@@ -96,8 +97,9 @@ void string_list_remove_duplicates(struct string_list *list,
int free_util)
{
if (list-nr 1) {
int src, dst;
+ compare_strings_fn cmp = list-cmp ? list-cmp : strcmp;
for (src = dst = 1; src list-nr; src++) {
- if (!strcmp(list-items[dst - 1].string,
list-items[src].string)) {
+ if (!cmp(list-items[dst - 1].string,
list-items[src].string)) {
if (list-strdup_strings)
free(list-items[src].string);
if (free_util)
@@ -230,15 +232,20 @@ struct string_list_item *string_list_append(struct
string_list *list,
list-strdup_strings ? xstrdup(string) : (char
*)string);
}
+/* Yuck */
+static compare_strings_fn compare_for_qsort;
+
+/* Only call this from inside sort_string_list! */
static int cmp_items(const void *a, const void *b)
{
const struct string_list_item *one = a;
const struct string_list_item *two = b;
- return strcmp(one-string, two-string);
+ return compare_for_qsort(one-string, two-string);
}
void sort_string_list(struct string_list *list)
{
+ compare_for_qsort = list-cmp ? list-cmp : strcmp;
qsort(list-items, list-nr, sizeof(*list-items), cmp_items);
}
@@ -246,8 +253,10 @@ struct string_list_item
*unsorted_string_list_lookup(struct string_list *list,
const char *string)
{
int i;
+ compare_strings_fn cmp = list-cmp ? list-cmp : strcmp;
+
for (i = 0; i list-nr; i++)
- if (!strcmp(string, list-items[i].string))
+ if (!cmp(string, list-items[i].string))
return list-items + i;
return NULL;
}
diff --git a/string-list.h b/string-list.h
index c50b0d0..446e79e 100644
--- a/string-list.h
+++ b/string-list.h
@@ -5,10 +5,14 @@ struct string_list_item {
char *string;
void *util;
};
+
+typedef int (*compare_strings_fn)(const char *, const char *);
+
struct string_list {
struct string_list_item *items;
unsigned int nr, alloc;
unsigned int strdup_strings:1;
+ compare_strings_fn cmp; /* NULL uses strcmp() */
};
#define STRING_LIST_INIT_NODUP { NULL, 0, 0, 0 }
--
1.8.1.304.gf036638
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 03/10] mailmap: remove email copy and length limitation
In map_user(), we have email pointer that points at the beginning of
an e-mail address, but the buffer is not terminated with a NUL after
the e-mail address. It typically has after the address, and it
could have even more if it comes from author/committer line in a
commit object. Or it may not have after it.
We used to copy the e-mail address proper into a temporary buffer
before asking the string-list API to find the e-mail address in the
mailmap, because string_list_lookup() function only takes a NUL
terminated full string.
Introduce a helper function lookup_prefix that takes the email
pointer and the length, and finds a matching entry in the string
list used for the mailmap, by doing the following:
- First ask string_list_find_insert_index() where in its sorted
list the e-mail address we have (including the possible trailing
junk ...) would be inserted.
- It could find an exact match (e.g. we had a clean e-mail address
without any trailing junk). We can return the item in that case.
- Or it could return the index of an item that sorts after the
e-mail address we have.
- If we did not find an exact match against a clean e-mail address,
then the record we are looking for in the mailmap has to exist
before the index returned by the function (i.e. emailjunk
always sorts later than email). Iterate, starting from that
index, down the map-items[] array until we find the exact record
we are looking for, or we see a record with a key that definitely
sorts earlier than the e-mail we are looking for (i.e. when we
are looking for email in emailjunk, a record in the mailmap
that begins with emaik strictly sorts before email, if such a
key existed in the mailmap).
This, together with the earlier enhancement to support
case-insensitive sorting, allow us to remove an extra copy of email
buffer to downcase it.
A part of this is based on Antoine Pelisse's previous work.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
mailmap.c | 61 +
1 file changed, 45 insertions(+), 16 deletions(-)
diff --git a/mailmap.c b/mailmap.c
index ea4b471..1a0b769 100644
--- a/mailmap.c
+++ b/mailmap.c
@@ -174,6 +174,7 @@ static int read_single_mailmap(struct string_list *map,
const char *filename, ch
int read_mailmap(struct string_list *map, char **repo_abbrev)
{
map-strdup_strings = 1;
+ map-cmp = strcasecmp;
/* each failure returns 1, so 1 means both calls failed */
return read_single_mailmap(map, .mailmap, repo_abbrev) +
read_single_mailmap(map, git_mailmap_file, repo_abbrev) 1;
@@ -187,14 +188,50 @@ void clear_mailmap(struct string_list *map)
debug_mm(mailmap: cleared\n);
}
+static struct string_list_item *lookup_prefix(struct string_list *map,
+ const char *string, size_t len)
+{
+ int i = string_list_find_insert_index(map, string, 1);
+ if (i 0) {
+ /* exact match */
+ i = -1 - i;
+ /* does it match exactly? */
+ if (!map-items[i].string[len])
+ return map-items[i];
+ }
+
+ /*
+* i is at the exact match to an overlong key, or
+* location the possibly overlong key would be inserted,
+* which must be after the real location of the key.
+*/
+ while (0 = --i i map-nr) {
+ int cmp = strncasecmp(map-items[i].string, string, len);
+ if (cmp 0)
+ /*
+* i points at a key definitely below the prefix;
+* the map does not have string[0:len] in it.
+*/
+ break;
+ else if (!cmp !map-items[i].string[len])
+ /* found it */
+ return map-items[i];
+ /*
+* otherwise, the string at i may be string[0:len]
+* followed by a string that sorts later than string[len:];
+* keep trying.
+*/
+ }
+ return NULL;
+}
+
int map_user(struct string_list *map,
char *email, int maxlen_email, char *name, int maxlen_name)
{
char *end_of_email;
struct string_list_item *item;
struct mailmap_entry *me;
- char buf[1024], *mailbuf;
- int i;
+ size_t maillen;
/* figure out space requirement for email */
end_of_email = strchr(email, '');
@@ -204,18 +241,12 @@ int map_user(struct string_list *map,
if (!end_of_email)
return 0;
}
- if (end_of_email - email + 1 sizeof(buf))
- mailbuf = buf;
- else
- mailbuf = xmalloc(end_of_email - email + 1);
-
- /* downcase the email address */
- for (i = 0; i end_of_email - email; i++)
- mailbuf[i] =
[PATCH v2 07/10] log: add --use-mailmap option
From: Antoine Pelisse apeli...@gmail.com
Add the --use-mailmap option to log commands. It allows to display
names from mailmap file when displaying logs, whatever the format
used.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-log.txt | 5 +
builtin/log.c | 9 -
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 585dac4..a99be97 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -47,6 +47,11 @@ OPTIONS
Print out the ref name given on the command line by which each
commit was reached.
+--use-mailmap::
+ Use mailmap file to map author and committer names and email
+ to canonical real names and email addresses. See
+ linkgit:git-shortlog[1].
+
--full-diff::
Without this flag, git log -p path... shows commits that
touch the specified paths, and diffs about the same specified
diff --git a/builtin/log.c b/builtin/log.c
index e7b7db1..d2bd8ce 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -22,6 +22,7 @@
#include branch.h
#include streaming.h
#include version.h
+#include mailmap.h
/* Set a default date-time format for git log (log.date config variable) */
static const char *default_date_mode = NULL;
@@ -94,11 +95,12 @@ static void cmd_log_init_finish(int argc, const char
**argv, const char *prefix,
struct rev_info *rev, struct setup_revision_opt *opt)
{
struct userformat_want w;
- int quiet = 0, source = 0;
+ int quiet = 0, source = 0, mailmap = 0;
const struct option builtin_log_options[] = {
OPT_BOOLEAN(0, quiet, quiet, N_(suppress diff output)),
OPT_BOOLEAN(0, source, source, N_(show source)),
+ OPT_BOOLEAN(0, use-mailmap, mailmap, N_(Use mail map
file)),
{ OPTION_CALLBACK, 0, decorate, NULL, NULL, N_(decorate
options),
PARSE_OPT_OPTARG, decorate_callback},
OPT_END()
@@ -136,6 +138,11 @@ static void cmd_log_init_finish(int argc, const char
**argv, const char *prefix,
if (source)
rev-show_source = 1;
+ if (mailmap) {
+ rev-mailmap = xcalloc(1, sizeof(struct string_list));
+ read_mailmap(rev-mailmap, NULL);
+ }
+
if (rev-pretty_given rev-commit_format == CMIT_FMT_RAW) {
/*
* log --pretty=raw is special; ignore UI oriented
--
1.8.1.304.gf036638
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 05/10] mailmap: add mailmap structure to rev_info and pp
From: Antoine Pelisse apeli...@gmail.com
Pass a mailmap from rev_info to pretty_print_context to so that the
pretty printer can use rewritten name and email address when showing
commits.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
commit.h | 1 +
log-tree.c | 1 +
revision.h | 1 +
3 files changed, 3 insertions(+)
diff --git a/commit.h b/commit.h
index b6ad8f3..7f8f987 100644
--- a/commit.h
+++ b/commit.h
@@ -89,6 +89,7 @@ struct pretty_print_context {
char *notes_message;
struct reflog_walk_info *reflog_info;
const char *output_encoding;
+ struct string_list *mailmap;
};
struct userformat_want {
diff --git a/log-tree.c b/log-tree.c
index 4f86def..92254fd 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -671,6 +671,7 @@ void show_log(struct rev_info *opt)
ctx.preserve_subject = opt-preserve_subject;
ctx.reflog_info = opt-reflog_info;
ctx.fmt = opt-commit_format;
+ ctx.mailmap = opt-mailmap;
pretty_print_commit(ctx, commit, msgbuf);
if (opt-add_signoff)
diff --git a/revision.h b/revision.h
index 059bfff..83a79f5 100644
--- a/revision.h
+++ b/revision.h
@@ -143,6 +143,7 @@ struct rev_info {
const char *subject_prefix;
int no_inline;
int show_log_size;
+ struct string_list *mailmap;
/* Filter by commit log message */
struct grep_opt grep_filter;
--
1.8.1.304.gf036638
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 10/10] log: add log.mailmap configuration option
From: Antoine Pelisse apeli...@gmail.com
Teach log.mailmap configuration variable to turn --use-mailmap
option on to git log, git show and git whatchanged.
The --no-use-mailmap option from the command line can countermand
the setting.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 4
builtin/log.c| 7 +++
t/t4203-mailmap.sh | 24
3 files changed, 35 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index bf8f911..226362a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1509,6 +1509,10 @@ log.showroot::
Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
normally hide the root commit will now show it. True by default.
+log.mailmap::
+ If true, makes linkgit:git-log[1], linkgit:git-show[1], and
+ linkgit:git-whatchanged[1] assume `--use-mailmap`.
+
mailmap.file::
The location of an augmenting mailmap file. The default
mailmap, located in the root of the repository, is loaded
diff --git a/builtin/log.c b/builtin/log.c
index d2bd8ce..16e6520 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static int default_abbrev_commit;
static int default_show_root = 1;
static int decoration_style;
static int decoration_given;
+static int use_mailmap_config;
static const char *fmt_patch_subject_prefix = PATCH;
static const char *fmt_pretty;
@@ -106,6 +107,7 @@ static void cmd_log_init_finish(int argc, const char
**argv, const char *prefix,
OPT_END()
};
+ mailmap = use_mailmap_config;
argc = parse_options(argc, argv, prefix,
builtin_log_options, builtin_log_usage,
PARSE_OPT_KEEP_ARGV0 | PARSE_OPT_KEEP_UNKNOWN |
@@ -358,6 +360,11 @@ static int git_log_config(const char *var, const char
*value, void *cb)
}
if (!prefixcmp(var, color.decorate.))
return parse_decorate_color_config(var, 15, value);
+ if (!strcmp(var, log.mailmap)) {
+ use_mailmap_config = git_config_bool(var, value);
+ return 0;
+ }
+
if (grep_config(var, value, cb) 0)
return -1;
return git_diff_ui_config(var, value, cb);
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index e16187f..7d4d31c 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -255,6 +255,21 @@ test_expect_success 'Log output with --use-mailmap' '
'
cat expect \EOF
+Author: CTO c...@company.xx
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Other Author ot...@author.xx
+Author: Other Author ot...@author.xx
+Author: Some Dude s...@dude.xx
+Author: A U Thor aut...@example.com
+EOF
+
+test_expect_success 'Log output with log.mailmap' '
+ git -c log.mailmap=True log | grep Author actual
+ test_cmp expect actual
+'
+
+cat expect \EOF
Author: Santa Claus santa.cl...@northpole.xx
Author: Santa Claus santa.cl...@northpole.xx
EOF
@@ -263,6 +278,15 @@ test_expect_success 'Grep author with --use-mailmap' '
git log --use-mailmap --author Santa | grep Author actual
test_cmp expect actual
'
+cat expect \EOF
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Santa Claus santa.cl...@northpole.xx
+EOF
+
+test_expect_success 'Grep author with log.mailmap' '
+ git -c log.mailmap=True log --author Santa | grep Author actual
+ test_cmp expect actual
+'
expect
--
1.8.1.304.gf036638
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 09/10] log: grep author/committer using mailmap
From: Antoine Pelisse apeli...@gmail.com
Currently you can use mailmap to display log authors and committers
but you can't use the mailmap to find commits with mapped values.
This commit allows you to run:
git log --use-mailmap --author mapped_name_or_email
git log --use-mailmap --committer mapped_name_or_email
Of course it only works if the --use-mailmap option is used.
The new name and email are copied only when necessary.
Signed-off-by: Antoine Pelisse apeli...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
revision.c | 54 ++
t/t4203-mailmap.sh | 18 ++
2 files changed, 72 insertions(+)
diff --git a/revision.c b/revision.c
index 95d21e6..2cce85a 100644
--- a/revision.c
+++ b/revision.c
@@ -13,6 +13,7 @@
#include decorate.h
#include log-tree.h
#include string-list.h
+#include mailmap.h
volatile show_early_output_fn_t show_early_output;
@@ -2219,6 +2220,51 @@ static int rewrite_parents(struct rev_info *revs, struct
commit *commit)
return 0;
}
+static int commit_rewrite_person(struct strbuf *buf, const char *what, struct
string_list *mailmap)
+{
+ char *person, *endp;
+ size_t len, namelen, maillen;
+ const char *name;
+ const char *mail;
+ struct ident_split ident;
+
+ person = strstr(buf-buf, what);
+ if (!person)
+ return 0;
+
+ person += strlen(what);
+ endp = strchr(person, '\n');
+ if (!endp)
+ return 0;
+
+ len = endp - person;
+
+ if (split_ident_line(ident, person, len))
+ return 0;
+
+ mail = ident.mail_begin;
+ maillen = ident.mail_end - ident.mail_begin;
+ name = ident.name_begin;
+ namelen = ident.name_end - ident.name_begin;
+
+ if (map_user(mailmap, mail, maillen, name, namelen)) {
+ struct strbuf namemail = STRBUF_INIT;
+
+ strbuf_addf(namemail, %.*s %.*s,
+ (int)namelen, name, (int)maillen, mail);
+
+ strbuf_splice(buf, ident.name_begin - buf-buf,
+ ident.mail_end - ident.name_begin + 1,
+ namemail.buf, namemail.len);
+
+ strbuf_release(namemail);
+
+ return 1;
+ }
+
+ return 0;
+}
+
static int commit_match(struct commit *commit, struct rev_info *opt)
{
int retval;
@@ -2237,6 +2283,14 @@ static int commit_match(struct commit *commit, struct
rev_info *opt)
if (buf.len)
strbuf_addstr(buf, commit-buffer);
+ if (opt-mailmap) {
+ if (!buf.len)
+ strbuf_addstr(buf, commit-buffer);
+
+ commit_rewrite_person(buf, \nauthor , opt-mailmap);
+ commit_rewrite_person(buf, \ncommitter , opt-mailmap);
+ }
+
/* Append fake message parts as needed */
if (opt-show_notes) {
if (!buf.len)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index db043dc..e16187f 100755
--- a/t/t4203-mailmap.sh
+++ b/t/t4203-mailmap.sh
@@ -248,11 +248,29 @@ Author: Other Author ot...@author.xx
Author: Some Dude s...@dude.xx
Author: A U Thor aut...@example.com
EOF
+
test_expect_success 'Log output with --use-mailmap' '
git log --use-mailmap | grep Author actual
test_cmp expect actual
'
+cat expect \EOF
+Author: Santa Claus santa.cl...@northpole.xx
+Author: Santa Claus santa.cl...@northpole.xx
+EOF
+
+test_expect_success 'Grep author with --use-mailmap' '
+ git log --use-mailmap --author Santa | grep Author actual
+ test_cmp expect actual
+'
+
+expect
+
+test_expect_success 'Only grep replaced author with --use-mailmap' '
+ git log --use-mailmap --author c...@coompany.xx actual
+ test_cmp expect actual
+'
+
# git blame
cat expect \EOF
^OBJI (A U Thor DATE 1) one
--
1.8.1.304.gf036638
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 08/10] test: add test for --use-mailmap option
From: Antoine Pelisse apeli...@gmail.com The new option '--use-mailmap' can be used to make sure that mailmap file is used to convert name when running log commands. The test is simple and checks that the Author line is correctly replaced when running log. Signed-off-by: Antoine Pelisse apeli...@gmail.com Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t4203-mailmap.sh | 14 ++ 1 file changed, 14 insertions(+) diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh index 1f182f6..db043dc 100755 --- a/t/t4203-mailmap.sh +++ b/t/t4203-mailmap.sh @@ -239,6 +239,20 @@ test_expect_success 'Log output (complex mapping)' ' test_cmp expect actual ' +cat expect \EOF +Author: CTO c...@company.xx +Author: Santa Claus santa.cl...@northpole.xx +Author: Santa Claus santa.cl...@northpole.xx +Author: Other Author ot...@author.xx +Author: Other Author ot...@author.xx +Author: Some Dude s...@dude.xx +Author: A U Thor aut...@example.com +EOF +test_expect_success 'Log output with --use-mailmap' ' + git log --use-mailmap | grep Author actual + test_cmp expect actual +' + # git blame cat expect \EOF ^OBJI (A U Thor DATE 1) one -- 1.8.1.304.gf036638 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git.wiki.kernel.org spam ...
On 4 January 2013 23:47, Theodore Ts'o ty...@mit.edu wrote: On Sat, Jan 05, 2013 at 12:27:12AM +0100, Johannes Schindelin wrote: I was. John Hawley trusted me when I asked for admin privileges to keep the spam at bay, but a very vocal voice on the mailing list tried to discredit my work, and in the wake of the ensuing mailing list thread I got the impression that that feeling was universal, so I abided and stopped. changed since those early days because LF sysadmins (e.g., John and Konstantin) do *not* have time to police the various wikis for spam) Based on the proliferation of new users listed in some recent changes pages, the account registration step needs a captcha test. Perhaps some other limits too.. one new account per ip per day or whatever.. (edu domains excepted perhaps) :) (the explosion of users seem to have started back in mid 2010 or so.) No human could keep up with unrestricted automated spamming from the internet that isn't filtered in any way. Human efforts to remove the spam will always result in a false positive from time to time and is simple mistake to make. Automated efforts to remove spam will DEFINATELY result in false positives too.. but you won't find a computer that graciously says sorry about that when it happens. IMHO.. a big thanks to Johannes for keeping the beasts at bay, I'm sure it would have been MUCH worse with nobody cleaning the mess up. Cheers! -phil -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] test: Add target test-lint-shell-syntax
On 07.01.13 19:07, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: Sorry for late answer, but there is a problem (both linux and Mac OS X) :-( $ make test-lint does not do shel syntax check, neither $ make test-lint-shell-syntax In which directory? $ make -C t test-lint-shell-syntax ... passes silently ... $ ed t/t-basic.sh /test_expect_success/ a which sh . w q $ make -C t test-lint-shell-syntax t-basic.sh:28: error: which is not portable (please use type): which sh make: *** [test-lint-shell-syntax] Error 1 If you edit out '@' (but nothing else) from this line: @'$(PERL_PATH_SQ)' check-non-portable-shell.pl $(T) and run the above again, you would see that it is running this shell command: '/usr/bin/perl' check-non-portable-shell.pl t-basic.sh t0001-init.sh ... If you introduce a Perl syntax error to check-non-portable-shell.pl, like this, you will get: $ make -C t test-lint-shell-syntax syntax error at check-non-portable-shell.pl line 11, near whoa So... is your shell broken? The above seems to work for dash, bash, ksh and zsh. Thanks for helping me out, and sorry for the noise. My brain went off track while chasing a failure of t7400 on pu under Mac OS :-( -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git clone depth of 0 not possible.
Jonathan Nieder jrnie...@gmail.com writes: Stefan Beller wrote: Currently it is not possible to have a shallow depth of just 0, i.e. only one commit in that repository after cloning. The minimum number of commits is 2, caused by depth=1. Sounds buggy. Would anything break if we were to make --depth=1 mean 1 deep, including the tip commit? As long as we do not change the meaning of the shallow count going over the wire (i.e. the number we receive from the user will be fudged, so that user's depth 1 that used to mean the tip and one behind it is expressed as depth 2 at the end-user level, and we send over the wire the number that corresponded to the old depth 1), I do not think anything will break, and then --depth=0 may magically start meaning only the tip; its immediate parents will not be transferred and recorded as the shallow boundary in the receiving repository. I do not mind carrying such a (technially) backward incompatible change in jn/clone-2.0-depth-off-by-one branch, keep it cooking in 'next' for a while and push it out together with other 2.0 topics in a future release ;-). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
You have exceeded the email quota limit
You have exceeded the email quota limit of 450MB and you need to expand the e-mail quota before the next 48 hours.if you do not update your e-mail account in 2013, you must do it now. You can expand 1GB email quota limit, use the following web link: https://docs.google.com/spreadsheet/viewform?formkey=dDdUYUpKVEdjNjNUd0ZZTnVaZUw0NHc6MQ Admin: Thanks for your understanding. Copyright c 2013 Webmaster Central Helpdesk -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git clone depth of 0 not possible.
On Tue, Jan 8, 2013 at 1:06 AM, Stefan Beller stefanbel...@googlemail.com wrote: Currently it is not possible to have a shallow depth of just 0, i.e. only one commit in that repository after cloning. The minimum number of commits is 2, caused by depth=1. I had no good idea how to add this behavior to git clone as the depth variable in git_transport_options struct (file transport.h) uses value 0 for another meaning, so it would have need changes at all places, where the transport options depth is being used (e.g. fetch) So I documented the current behavior, see attached patch. If we choose not to do the off-by-one topic Junio suggested elsewhere in the same thread, I think this document patch should be turned into code instead. Just reject --depth=0 with an explanation. Users who are hit by this will be caught without the need to read through the document. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git clone depth of 0 not possible.
Junio C Hamano gits...@pobox.com writes: Jonathan Nieder jrnie...@gmail.com writes: Stefan Beller wrote: Currently it is not possible to have a shallow depth of just 0, i.e. only one commit in that repository after cloning. The minimum number of commits is 2, caused by depth=1. Sounds buggy. Would anything break if we were to make --depth=1 mean 1 deep, including the tip commit? As long as we do not change the meaning of the shallow count going over the wire (i.e. the number we receive from the user will be fudged, so that user's depth 1 that used to mean the tip and one behind it is expressed as depth 2 at the end-user level, and we send over the wire the number that corresponded to the old depth 1), I do not think anything will break, and then --depth=0 may magically start meaning only the tip; its immediate parents will not be transferred and recorded as the shallow boundary in the receiving repository. I do not mind carrying such a (technially) backward incompatible change in jn/clone-2.0-depth-off-by-one branch, keep it cooking in 'next' for a while and push it out together with other 2.0 topics in a future release ;-). Speaking of --depth, I think in Git 2.0 we should fix the semantics of deepening done with git fetch. Its --depth parameter is used to specify the new depth of the history that you can tangle from the updated tip of remote tracking branches, and it has a rather unpleasant ramifications. Suppose you start from git clone --depth=1 $there. You have the today's snapshot, and one parent behind it. You keep working happily with the code and then realize that you want to know a bit more history behind the snapshot you started from. (upstream) ---o---o---o---A---B (you) A---B So you do: $ git fetch --depth=3 (upstream) ---o---o---o---A---B---C---D---E---F---...---W---X---Y---Z (you) A---B W---X---Y---Z But in the meantime, if the upstream accumulated 20+ commits, you end up getting the commit at the updated tip of the upstream, and 3 generations of parents behind it. There will be a 10+ commit worth of gap between the bottom of the new shallow history and the old tip you have been working on, and the history becomes disjoint. I think we need a protocol update to fix this; instead of sending Now I want your tips and N commits behind it, please update my shallow bottom accordingly, which creates the above by giving you Z and 3 generations back and updates your cut-off point to W, the receiving end should be able to ask I have a shallow history that cuts off at these commits. I want to get the history leading up to your tips, and also deepen the history further back from my current cut-off points by N commits, so that you would instead end up with something like this: (you) o---o---o---A---B---C---D---E---F---...---W---X---Y---Z That is, truly deepen my history by 3. We could call that git fetch --deepen=3 or something. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git clone depth of 0 not possible.
On Tue, Jan 8, 2013 at 1:54 PM, Junio C Hamano gits...@pobox.com wrote: Sounds buggy. Would anything break if we were to make --depth=1 mean 1 deep, including the tip commit? As long as we do not change the meaning of the shallow count going over the wire (i.e. the number we receive from the user will be fudged, so that user's depth 1 that used to mean the tip and one behind it is expressed as depth 2 at the end-user level, and we send over the wire the number that corresponded to the old depth 1), I do not think anything will break, and then --depth=0 may magically start meaning only the tip; its immediate parents will not be transferred and recorded as the shallow boundary in the receiving repository. I'd rather we reserve 0 for unlimited fetch, something we haven't done so far [1]. And because unlimited clone with --depth does not make sense, --depth=0 should be rejected by git-clone. [1] If we don't want to break the protocol, we could make depth 0x a special value as unlimited for newer git. Older git works most of the time, until some project exceeds 4G commit depth history. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/10] reroll of ap/log-mailmap
Antoine Pelisse apeli...@gmail.com writes: Have you been able to measure a speed increase due to less copies ? No. This topic was not strictly my itch, but I did the rewrite because I couldn't stand staring at that *_extended() function ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
