* [PATCH] Documentation/submodule: Add --force to update synopsis
From: Brad King @ 2013-02-27 0:41 UTC (permalink / raw)
To: git; +Cc: gitster
In commit 9db31bdf (submodule: Add --force option for git submodule
update, 2011-04-01) we added the option to the implementation's usage
synopsis but forgot to add it to the synopsis in the command
documentation. Add the option to the synopsis in the same location it
is reported in usage and re-wrap the options to avoid long lines.
Signed-off-by: Brad King <brad.king@kitware.com>
---
Documentation/git-submodule.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index a0c9df8..c604731 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,8 +13,9 @@ SYNOPSIS
[--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
-'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [--rebase]
- [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
+'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
+ [-f|--force] [--rebase] [--reference <repository>] [--merge]
+ [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
[commit] [--] [<path>...]
'git submodule' [--quiet] foreach [--recursive] <command>
--
1.7.10.4
^ permalink raw reply related
* Re: gc does not clean up after itself when not enough disk space
From: Jeff King @ 2013-02-27 5:07 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Jens Lehmann, Junio C Hamano, jones.noamle, git
In-Reply-To: <CAMK1S_hxZZzi911s2QRpc67sNf_U7Ceo1fPT_hg1gO500pO=6A@mail.gmail.com>
On Wed, Feb 27, 2013 at 05:58:20AM +0530, Sitaram Chamarty wrote:
> > Ack. I just recently had to do
> >
> > git gc || rm -f .git/objects/*/tmp_*
> >
> > as workaround in the nightly housekeeping script on our CI server.
>
> it's not just 'git gc'; a failed push of a large repo (failed due to,
> say, network issues or whatever) also leave tmp_* lying around. At
> least as far as I can tell...
Yes, we used to run into problems with failed pushes sometimes at
GitHub. A later `git gc` will clean up the tmp_* objects (via `git
prune`), but of course we will not run the prune if the repack fails.
Also note that a push will just keep receiving objects as long as the
client wishes to send them, spooling straight to disk, before any
enforcement hooks have a chance to run. So on stock git, you could in
theory just fill up the receiver's disk, and then git will leave the
file sitting around.
I have a patch to make index-pack just do a hard hangup after receiving
`receive.maximumBytes` bytes (with an appropriate message to stderr).
It's not an exact measure of the size of the push (since we need to
complete thin packs, and we may also explode smaller packs), but it at
least bounds the size that the sender can push. I'm happy to share the
patch if others are interested (it's only a few lines).
I've also considered a patch to have index-pack clean up tmp_pack_*
automatically on exit, default to off (i.e., the current behavior). A
busy site could turn it on globally, and then shut it off for a specific
repo when trying to debug a push problem. I find that the leftover
tmp_pack files are very seldom of interest for forensic debugging. I
haven't bothered to write that patch, though; we dropped our prune
expiration time well below the 2-week default, so the tmp files get
cleaned up pretty regularly now.
-Peff
^ permalink raw reply
* Re: problem switching branches
From: Jeff King @ 2013-02-27 5:17 UTC (permalink / raw)
To: J.V.; +Cc: git@vger.kernel.org
In-Reply-To: <512D4087.5070504@gmail.com>
On Tue, Feb 26, 2013 at 04:08:55PM -0700, J.V. wrote:
> I was on my master branch, I then checked out a branch (
> origin/somebranch ), made no updates
> but did a few git pulls on the branch over about a week; then made a
> small change to only a single file & committed & pushed.
>
> Now am trying to go back to my master branch and get:
>
> error: The following untracked working tree files would be
> overwritten by checkout:
> lib/derbyclient.jar
> Please move or remove them before you can switch branches.
> Aborting
>
>
> I did not put that jar file there (I edited a single config file),
> how do I now get back to my master branch?
Not knowing anything about your project, it's impossible to say for
sure, but this often happens with something like:
1. lib/derbyclient.jar used to be generated by your project's build
procedure
2. You did a build of your project, generating the file in your
working tree.
3. Meanwhile, somebody upstream added and commited lib/derbyclient.jar
directly in the repository. This might have been intentional (it
used to be a generated file, but now is included as source), or it
may have been an accident (mistaken use of `git add`).
4. You try to switch to the master branch with the new commits from
(3). Git sees that the copy of the file in your working tree would
be overwritten and lost (since it was never committed by you), so
aborts.
If you are sure that the file in the working tree does not contain
anything interesting, you can use "git checkout -f master" to force the
overwrite.
> I do not want to muck up the branch that I am now on by deleting anything.
> Any ideas how this happened?
You won't hurt the branch you are on; you will just lose the contents in
the untracked working tree file. That's probably fine if it is a
generated file, as in the scenario I described above. We know that the
file is not included in the branch you are on (otherwise, it would not
be listed as untracked). And even if it were, you would only impact the
branch by committing the changes, not by changing the working tree.
> Obviously someone put derbyclient.jar there, not sure, but it is
> supposed to be there so do not want to remove as advised.
It won't be removed; it will be overwritten with the version of the file
that is on "master". Which is probably what you want; you may want to
look at `git log master -- lib/derbyclient.jar` to see why it was added.
-Peff
^ permalink raw reply
* Re: clean/smudge filters on .zip/.tgz files
From: Johannes Sixt @ 2013-02-27 6:39 UTC (permalink / raw)
To: Tim Chase; +Cc: git
In-Reply-To: <20130226163800.454cd093@bigbox.christie.dr>
Am 2/26/2013 23:38, schrieb Tim Chase:
> Various programs that I use ([Open|Libre]Office, Vym, etc) use a
> zipped/.tgz'ed file format, usually containing multiple
> (usually) plain-text files within.
>
> I'm trying to figure out a way for git to treat these as virtual
> directories for purposes of merging/diffing.
>
> Reading up on clean/smudge filters, it looks like they expect one
> file coming in and one file going out, rather than one file
> on one side and a directory-tree of files on the other side.
>
> I tried creating my own pair of clean/smudge filters that would
> uncompress the files, but there's no good way put multiple files on
> stdout.
>
> Has anybody else played with such a scheme for uncompressing files as
> they go into git and recompressing them as they come back out?
I attempted to do something like this for OpenDocument files (I didn't get
very far) until I discovered that LibreOffice can save "flat open document
files". That combined with the option "save files optimized" switched off
results in fairly readable XML in a single file that can even be merged
under some circumstances.
You would still need a clean filter that normalizes the style numbers,
cross reference marks and other stuff that changes each time LibreOffice
saves the file.
-- Hannes
^ permalink raw reply
* Re: post-receive-email hook with custom_showrev
From: Michael Haggerty @ 2013-02-27 7:42 UTC (permalink / raw)
To: Adam Mercer; +Cc: git
In-Reply-To: <CA+mfgz1jrSbbZc7+asxfZivemYSvbB3+UxYx4sm3BwLmR0ELEA@mail.gmail.com>
On 02/22/2013 09:57 PM, Adam Mercer wrote:
> I'm trying to setup the post-receive-email hook, from contrib, using a
> custom_showrev, from the script I do this by setting hooks.showrev
>
> # hooks.showrev
> # The shell command used to format each revision in the email, with
> # "%s" replaced with the commit id. Defaults to "git rev-list -1
> # --pretty %s", displaying the commit id, author, date and log
> # message. To list full patches separated by a blank line, you
> # could set this to "git show -C %s; echo".
> # To list a gitweb/cgit URL *and* a full patch for each change set, use this:
> # "t=%s; printf 'http://.../?id=%%s' \$t; echo;echo; git show -C \$t; echo"
> # Be careful if "..." contains things that will be expanded by shell "eval"
> # or printf.
>
> in my repositories config I have showrev set to:
>
> [hooks]
> showrev = t=%s; printf
> 'http://server/cgit/repository/commit/?id=%%s' \$t; echo;echo; git
> show -C \$t; echo
If I type that into my .git/config file then type "git config
hooks.showrev" I get "bad config file line 7 in .git/config" due to the
"\$". I think the quoting in the comment in post-receive-email is
written as if it would be passed via the command line to "git config"; i.e.,
git config hooks.showrev "t=%s; printf 'http://.../?id=%%s' \$t;
echo;echo; git show -C \$t; echo"
Granted, the docs don't make that clear. See git-config(1) for the
details of the config file syntax.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: [PATCH 1/4] config: factor out config file stack management
From: Heiko Voigt @ 2013-02-27 7:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jens Lehmann
In-Reply-To: <7vobf6loas.fsf@alter.siamese.dyndns.org>
On Tue, Feb 26, 2013 at 02:10:03PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I wonder if it would be more obvious with the more usual OO-struct
> > functions, like:
> >
> > struct config_source {
> > ...
> > };
> > void config_source_init_file(struct config_source *, const char *fn);
> > void config_source_init_strbuf(struct config_source *,
> > const struct strbuf *buf);
> > void config_source_clear(struct config_source *);
> >
> > int config_source_parse(struct config_source *);
> >
> > and then the use would be something like:
> >
> > struct config_source top;
> > int ret;
> >
> > config_source_init_file(&top, "foo");
> > ret = config_source_parse(&top);
> > config_source_clear(&top);
> >
> > return ret;
> >
> > I.e., "init" constructors, a "clear" destructor, and any methods like
> > "parse" that you need.
>
> Yup, that cocincides with my first impression I sent out for the
> previous RFC/PATCH round.
I agree that your suggestions would make the design more OO and provide
us with more flexibility. However at the following costs:
Currently the push and pop are combined into one function. This design
makes it impossible to forget the cleanup if someone else uses this
function. The same applies to the private data handling around
do_config_from().
All memory is currently handled on the stack. If we have an init/clear
design at least the private data for strbuf needs to be put on the heap.
We could pass in the config_strbuf but IMO that would violate the
encapsulation.
Thus we also require a specialized clear which frees that private data
(we need that to close the file anyway). Because of that I would probably
call it destroy or free.
That means there will be six additional functions instead of one: We
need init and clear for both, a common init and a common clear for the
push/pop part. IMO that will make the code harder to read for the first
time.
Then we would have a hybrid stack/heap solution still involving side
effects (setting the global cf).
Do not get me wrong. I am not against changing it but I would like to
spell out the consequences first before doing so.
Do you still think that is nicer approach?
Cheers Heiko
^ permalink raw reply
* Re: [PATCH 2/4] config: drop file pointer validity check in get_next_char()
From: Heiko Voigt @ 2013-02-27 7:52 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Jens Lehmann
In-Reply-To: <20130226200556.GB13830@sigill.intra.peff.net>
On Tue, Feb 26, 2013 at 03:05:56PM -0500, Jeff King wrote:
> On Tue, Feb 26, 2013 at 08:40:23PM +0100, Heiko Voigt wrote:
>
> > The only location where cf is set in this file is in do_config_from().
> > This function has only one callsite which is config_from_file(). In
> > config_from_file() its ensured that the f member is set to non-zero.
>
> Makes sense, although...
>
> > - if (cf && ((f = cf->f) != NULL)) {
> > + if (cf) {
> > + FILE *f = cf->f;
>
> Couldn't we say the same thing about "cf" here (i.e., that it would
> never be NULL)? Can we just get rid of this conditional entirely?
That might be true. I will look into it. Just wanted to get rid of an
extra callback in my series.
Cheers Heiko
^ permalink raw reply
* Re: [PATCH 1/4] config: factor out config file stack management
From: Heiko Voigt @ 2013-02-27 7:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Jens Lehmann
In-Reply-To: <7vk3pulo6w.fsf@alter.siamese.dyndns.org>
On Tue, Feb 26, 2013 at 02:12:23PM -0800, Junio C Hamano wrote:
> Heiko Voigt <hvoigt@hvoigt.net> writes:
>
> > The "do_config_from" means "parse from whatever is in 'top'". Later in
> > the series its type changes from config_file to struct config.
>
> Yuck. It would be nice to have it as struct config_src or
> something. "struct config" sounds as if it represents the entire
> configuration state and you can ask it to add new ones or enumerate
> all known configuration variables, etc.
Will change it to struct config_source. I choose that name in lack of a
better one. Since it can be considered the base for both sources I just
removed the _file postfix.
Cheers Heiko
^ permalink raw reply
* [PATCH] archive-zip: fix compressed size for stored export-subst files
From: René Scharfe @ 2013-02-27 10:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git discussion list
Currently ZIP archive entries of files with export-subst attribute are
broken if they are stored uncompressed.
We get the size of a file from sha1_object_info(), but this number is
likely wrong for files whose contents are changed due to export-subst
placeholder expansion. We use sha1_file_to_archive() to get the
expanded file contents and size in that case. We proceed to use that
size for the uncompressed size field (good), but the compressed size
field is set based on the size from sha1_object_info() (bad).
This matters only for uncompressed files because for deflated files
we use the correct value after compression is done. And for files
without export-subst expansion the sizes from sha1_object_info() and
sha1_file_to_archive() are the same, so they are unaffected as well.
This patch fixes the issue by setting the compressed size based on the
uncompressed size only after we actually know the latter.
Also make use of the test file substfile1 to check for the breakage;
it was only stored verbatim so far. For that purpose, set the
attribute export-subst and replace its contents with the expected
expansion after committing.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
This bug was present even before 5ea2c847 (archive-zip: write
uncompressed size into header even with streaming).
archive-zip.c | 2 +-
t/t5003-archive-zip.sh | 6 ++++++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/archive-zip.c b/archive-zip.c
index d3aef53..a8d1193 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -240,7 +240,6 @@ static int write_zip_entry(struct archiver_args *args,
(mode & 0111) ? ((mode) << 16) : 0;
if (S_ISREG(mode) && args->compression_level != 0 && size > 0)
method = 8;
- compressed_size = (method == 0) ? size : 0;
if (S_ISREG(mode) && type == OBJ_BLOB && !args->convert &&
size > big_file_threshold) {
@@ -259,6 +258,7 @@ static int write_zip_entry(struct archiver_args *args,
crc = crc32(crc, buffer, size);
out = buffer;
}
+ compressed_size = (method == 0) ? size : 0;
} else {
return error("unsupported file mode: 0%o (SHA1: %s)", mode,
sha1_to_hex(sha1));
diff --git a/t/t5003-archive-zip.sh b/t/t5003-archive-zip.sh
index 7cfe9ca..6a33606 100755
--- a/t/t5003-archive-zip.sh
+++ b/t/t5003-archive-zip.sh
@@ -76,6 +76,12 @@ test_expect_success \
git update-ref HEAD $(TZ=GMT GIT_COMMITTER_DATE="2005-05-27 22:00:00" \
git commit-tree $treeid </dev/null)'
+test_expect_success 'setup export-subst' '
+ echo "substfile?" export-subst >>.git/info/attributes &&
+ git log --max-count=1 "--pretty=format:A${SUBSTFORMAT}O" HEAD \
+ >a/substfile1
+'
+
test_expect_success \
'create bare clone' \
'git clone --bare . bare.git &&
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] attr: allow pattern escape using backslashes
From: Duy Nguyen @ 2013-02-27 12:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7gly5az0.fsf@alter.siamese.dyndns.org>
On Sun, Feb 24, 2013 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Speaking of .gitignore, I recall that there was a hanging discussion
> on allowing a pattern to name the directory that the .gitignore file
> appears in, which I do not think we currently support. With such a
> feature, instead of listing "/junk" in the .gitignore file at the
> top-level to say that everything inside the "junk" directory is
> ignored by default, we could instead say "<this>" at the beginning
> of the .gitignore file in the "junk" directory.
Shouldn't "/" alone in junk/.gitignore express that? It does not work,
but I think it's a natural interpretation of the syntax.
> I think "* <attr>"
> in the .gitattributes file in a directory causes "git check-attr ."
> in that directory to report the <attr>, and we may want to have some
> way to allow "git check-ignore ." to be affected by the .gitignore
> file in the same directory in a similar way, but I do not have a
> very strong opinion. Do people have any comment on this?
--
Duy
^ permalink raw reply
* [PATCH] contrib/subtree: fix Makefile to respect non-configure `make`
From: Jan Rueegg @ 2013-02-27 13:09 UTC (permalink / raw)
To: git
Hello
There was a message in this list before to try to fix the Makefile:
http://marc.info/?l=git&m=134116914230460&w=2
However, without any reaction following. See also here whats the problem:
https://bugs.archlinux.org/task/30473
Anyone there who can have a look at the patch and integrate it upstream?
Regards
Jan Rüegg
^ permalink raw reply
* Re: [PATCH] diff: prevent pprint_rename from underrunning input
From: Antoine Pelisse @ 2013-02-27 13:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, git
In-Reply-To: <7vsj4ilphz.fsf@alter.siamese.dyndns.org>
>> The logic described in d020e27 (diff: Fix rename pretty-print when
>> suffix and prefix overlap, 2013-02-23) is wrong: The proof in the
>> comment is valid only if both strings are the same length. *One* of
>> old/new can reach a-1 (b-1, resp.) if 'a' is a suffix of 'b' (or vice
>> versa).
Indeed, sorry about that. I guess I was too focused on my specific
issue and didn't broaden my thoughts.
> Thanks. I was also having hard time convincing myself why that -1
> does not under-run yesterday.
>
> Will queue.
Thanks
^ permalink raw reply
* Re: [PATCHv4 5/6] Git.pm: add interface for git credential command
From: Matthieu Moy @ 2013-02-27 14:18 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: peff, gitster, git
In-Reply-To: <e5834c9b5ccb66a88b64b3d07982ad41205fb97e.1360677646.git.mina86@mina86.com>
Michal Nazarewicz <mpn@google.com> writes:
> +=item credential_read( FILEHANDLE )
> +
> +Reads credential key-value pairs from C<FILEHANDLE>. Reading stops at EOF or
> +when an empty line is encountered. Each line must be of the form C<key=value>
> +with a non-empty key. Function returns hash with all read values. Any white
> +space (other then new-line character) is preserved.
Typo: other then -> than.
> +sub credential_read {
> + my ($self, $reader) = _maybe_self(@_);
> + my %credential;
> + while (<$reader>) {
> + chomp;
> + if ($_ eq '') {
> + last;
> + } elsif (!/^([^=]+)=(.*)$/) {
Good.
> + # Check if $credential is valid prior to writing anything
> + while (($key, $value) = each %$credential) {
> + if (!defined $key || !length $key) {
> + throw Error::Simple("credential key empty or undefined");
> + } elsif ($key =~ /[=\n\0]/) {
> + throw Error::Simple("credential key contains invalid characters: $key");
> + } elsif (defined $value && $value =~ /[\n\0]/) {
> + throw Error::Simple("credential value for key=$key contains invalid characters: $value");
> + }
> + }
Good.
These checks seem to address all the points raised during discussion
about when the API should reject values.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCHv4 6/6] git-send-email: use git credential to obtain password
From: Matthieu Moy @ 2013-02-27 14:20 UTC (permalink / raw)
To: Michal Nazarewicz; +Cc: peff, gitster, git
In-Reply-To: <32bae1f3c7159035ea3fb5f61ab622cbff30293a.1360677646.git.mina86@mina86.com>
Michal Nazarewicz <mpn@google.com> writes:
> + $auth = Git::credential({
> + 'protocol' => 'smtp',
> + 'host' => join(':', $smtp_server, $smtp_server_port),
At this point, $smtp_server_port is not always defined. I just tested
and got
Use of uninitialized value $smtp_server_port in join or string at
git-send-email line 1077.
Other than that, the whole series looks good.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: post-receive-email hook with custom_showrev
From: Adam Mercer @ 2013-02-27 14:30 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <512DB8D6.9010109@alum.mit.edu>
On Wed, Feb 27, 2013 at 1:42 AM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> If I type that into my .git/config file then type "git config
> hooks.showrev" I get "bad config file line 7 in .git/config" due to the
> "\$". I think the quoting in the comment in post-receive-email is
> written as if it would be passed via the command line to "git config"; i.e.,
>
> git config hooks.showrev "t=%s; printf 'http://.../?id=%%s' \$t;
> echo;echo; git show -C \$t; echo"
>
> Granted, the docs don't make that clear. See git-config(1) for the
> details of the config file syntax.
Thanks a lot that did the trick! I imagined it'd be some quoting issue.
Cheers
Adam
^ permalink raw reply
* [PATCH] name-hash.c: fix endless loop with core.ignorecase=true
From: Karsten Blees @ 2013-02-27 14:45 UTC (permalink / raw)
To: Jeff King
Cc: Karsten Blees, Duy Nguyen, kusmabite, Ramkumar Ramachandra,
Robert Zeh, Junio C Hamano, Git List, finnag
In-Reply-To: <511C3454.6080204@gmail.com>
With core.ignorecase=true, name-hash.c builds a case insensitive index of
all tracked directories. Currently, the existing cache entry structures are
added multiple times to the same hashtable (with different name lengths and
hash codes). However, there's only one dir_next pointer, which gets
completely messed up in case of hash collisions. In the worst case, this
causes an endless loop if ce == ce->dir_next:
---8<---
# "V/", "V/XQANY/" and "WURZAUP/" all have the same hash_name
mkdir V
mkdir V/XQANY
mkdir WURZAUP
touch V/XQANY/test
git init
git config core.ignorecase true
git add .
git status
---8<---
Use a separate hashtable and separate structures for the directory index
so that each directory entry has its own next pointer. Use reference
counting to track which directory entry contains files.
There are only slight changes to the name-hash.c API:
- new free_name_hash() used by read_cache.c::discard_index()
- remove_name_hash() takes an additional index_state parameter
- index_name_exists() for a directory (trailing '/') may return a cache
entry that has been removed (CE_UNHASHED). This is not a problem as the
return value is only used to check if the directory exists (dir.c) or to
normalize casing of directory names (read-cache.c).
Getting rid of cache_entry.dir_next reduces memory consumption, especially
with core.ignorecase=false (which doesn't use that member at all).
With core.ignorecase=true, building the directory index is slightly faster
as we add / check the parent directory first (instead of going through all
directory levels for each file in the index). E.g. with WebKit (~200k
files, ~7k dirs), time taken in lazy_init_name_hash is reduced from 176ms
to 130ms.
Signed-off-by: Karsten Blees <blees@dcon.de>
---
Also available here:
https://github.com/kblees/git/tree/kb/name-hash-fix-endless-loop
git pull git://github.com/kblees/git.git kb/name-hash-fix-endless-loop
This combines the pros of the patches suggested by Jeff and me:
- reduced memory usage due to smaller dir_entry and cache_entry structs
- faster indexing due to right-to-left directory lookup
- marginal API changes, i.e. less impact on the rest of git
Test suite runs clean on msysgit and Linux.
Have fun,
Karsten
cache.h | 17 ++-----
name-hash.c | 164 +++++++++++++++++++++++++++++++++++++++++++----------------
read-cache.c | 9 ++--
3 files changed, 126 insertions(+), 64 deletions(-)
diff --git a/cache.h b/cache.h
index e493563..898e346 100644
--- a/cache.h
+++ b/cache.h
@@ -131,7 +131,6 @@ struct cache_entry {
unsigned int ce_namelen;
unsigned char sha1[20];
struct cache_entry *next;
- struct cache_entry *dir_next;
char name[FLEX_ARRAY]; /* more */
};
@@ -267,25 +266,15 @@ struct index_state {
unsigned name_hash_initialized : 1,
initialized : 1;
struct hash_table name_hash;
+ struct hash_table dir_hash;
};
extern struct index_state the_index;
/* Name hashing */
extern void add_name_hash(struct index_state *istate, struct cache_entry *ce);
-/*
- * We don't actually *remove* it, we can just mark it invalid so that
- * we won't find it in lookups.
- *
- * Not only would we have to search the lists (simple enough), but
- * we'd also have to rehash other hash buckets in case this makes the
- * hash bucket empty (common). So it's much better to just mark
- * it.
- */
-static inline void remove_name_hash(struct cache_entry *ce)
-{
- ce->ce_flags |= CE_UNHASHED;
-}
+extern void remove_name_hash(struct index_state *istate, struct cache_entry *ce);
+extern void free_name_hash(struct index_state *istate);
#ifndef NO_THE_INDEX_COMPATIBILITY_MACROS
diff --git a/name-hash.c b/name-hash.c
index 942c459..6b130e1 100644
--- a/name-hash.c
+++ b/name-hash.c
@@ -32,38 +32,75 @@ static unsigned int hash_name(const char *name, int namelen)
return hash;
}
-static void hash_index_entry_directories(struct index_state *istate, struct cache_entry *ce)
+struct dir_entry {
+ struct dir_entry *next;
+ struct dir_entry *parent;
+ struct cache_entry *ce;
+ int nr;
+ unsigned int namelen;
+};
+
+static struct dir_entry *find_dir_entry(struct index_state *istate,
+ const char *name, unsigned int namelen)
+{
+ unsigned int hash = hash_name(name, namelen);
+ struct dir_entry *dir;
+
+ for (dir = lookup_hash(hash, &istate->dir_hash); dir; dir = dir->next)
+ if (dir->namelen == namelen &&
+ !strncasecmp(dir->ce->name, name, namelen))
+ return dir;
+ return NULL;
+}
+
+static struct dir_entry *hash_dir_entry(struct index_state *istate,
+ struct cache_entry *ce, int namelen, int add)
{
/*
* Throw each directory component in the hash for quick lookup
* during a git status. Directory components are stored with their
- * closing slash. Despite submodules being a directory, they never
- * reach this point, because they are stored without a closing slash
- * in the cache.
- *
- * Note that the cache_entry stored with the directory does not
- * represent the directory itself. It is a pointer to an existing
- * filename, and its only purpose is to represent existence of the
- * directory in the cache. It is very possible multiple directory
- * hash entries may point to the same cache_entry.
+ * closing slash.
*/
- unsigned int hash;
- void **pos;
+ struct dir_entry *dir, *p;
+
+ /* get length of parent directory */
+ while (namelen > 0 && !is_dir_sep(ce->name[namelen - 1]))
+ namelen--;
+ if (namelen <= 0)
+ return NULL;
+
+ /* lookup existing entry for that directory */
+ dir = find_dir_entry(istate, ce->name, namelen);
+ if (add && !dir) {
+ /* not found, create it and add to hash table */
+ void **pdir;
+ unsigned int hash = hash_name(ce->name, namelen);
- const char *ptr = ce->name;
- while (*ptr) {
- while (*ptr && *ptr != '/')
- ++ptr;
- if (*ptr == '/') {
- ++ptr;
- hash = hash_name(ce->name, ptr - ce->name);
- pos = insert_hash(hash, ce, &istate->name_hash);
- if (pos) {
- ce->dir_next = *pos;
- *pos = ce;
- }
+ dir = xcalloc(1, sizeof(struct dir_entry));
+ dir->namelen = namelen;
+ dir->ce = ce;
+
+ pdir = insert_hash(hash, dir, &istate->dir_hash);
+ if (pdir) {
+ dir->next = *pdir;
+ *pdir = dir;
}
+
+ /* recursively add missing parent directories */
+ dir->parent = hash_dir_entry(istate, ce, namelen - 1, add);
}
+
+ /* add or release reference to this entry (and parents if 0) */
+ p = dir;
+ if (add) {
+ while (p && !(p->nr++))
+ p = p->parent;
+ } else {
+ while (p && p->nr && !(--p->nr))
+ p = p->parent;
+ }
+
+ return dir;
}
static void hash_index_entry(struct index_state *istate, struct cache_entry *ce)
@@ -74,7 +111,7 @@ static void hash_index_entry(struct index_state *istate, struct cache_entry *ce)
if (ce->ce_flags & CE_HASHED)
return;
ce->ce_flags |= CE_HASHED;
- ce->next = ce->dir_next = NULL;
+ ce->next = NULL;
hash = hash_name(ce->name, ce_namelen(ce));
pos = insert_hash(hash, ce, &istate->name_hash);
if (pos) {
@@ -82,8 +119,8 @@ static void hash_index_entry(struct index_state *istate, struct cache_entry *ce)
*pos = ce;
}
- if (ignore_case)
- hash_index_entry_directories(istate, ce);
+ if (ignore_case && !(ce->ce_flags & CE_UNHASHED))
+ hash_dir_entry(istate, ce, ce_namelen(ce), 1);
}
static void lazy_init_name_hash(struct index_state *istate)
@@ -99,11 +136,33 @@ static void lazy_init_name_hash(struct index_state *istate)
void add_name_hash(struct index_state *istate, struct cache_entry *ce)
{
+ /* if already hashed, add reference to directory entries */
+ if (ignore_case && (ce->ce_flags & CE_STATE_MASK) == CE_STATE_MASK)
+ hash_dir_entry(istate, ce, ce_namelen(ce), 1);
+
ce->ce_flags &= ~CE_UNHASHED;
if (istate->name_hash_initialized)
hash_index_entry(istate, ce);
}
+/*
+ * We don't actually *remove* it, we can just mark it invalid so that
+ * we won't find it in lookups.
+ *
+ * Not only would we have to search the lists (simple enough), but
+ * we'd also have to rehash other hash buckets in case this makes the
+ * hash bucket empty (common). So it's much better to just mark
+ * it.
+ */
+void remove_name_hash(struct index_state *istate, struct cache_entry *ce)
+{
+ /* if already hashed, release reference to directory entries */
+ if (ignore_case && (ce->ce_flags & CE_STATE_MASK) == CE_HASHED)
+ hash_dir_entry(istate, ce, ce_namelen(ce), 0);
+
+ ce->ce_flags |= CE_UNHASHED;
+}
+
static int slow_same_name(const char *name1, int len1, const char *name2, int len2)
{
if (len1 != len2)
@@ -137,18 +196,7 @@ static int same_name(const struct cache_entry *ce, const char *name, int namelen
if (!icase)
return 0;
- /*
- * If the entry we're comparing is a filename (no trailing slash), then compare
- * the lengths exactly.
- */
- if (name[namelen - 1] != '/')
- return slow_same_name(name, namelen, ce->name, len);
-
- /*
- * For a directory, we point to an arbitrary cache_entry filename. Just
- * make sure the directory portion matches.
- */
- return slow_same_name(name, namelen, ce->name, namelen < len ? namelen : len);
+ return slow_same_name(name, namelen, ce->name, len);
}
struct cache_entry *index_name_exists(struct index_state *istate, const char *name, int namelen, int icase)
@@ -164,16 +212,14 @@ struct cache_entry *index_name_exists(struct index_state *istate, const char *na
if (same_name(ce, name, namelen, icase))
return ce;
}
- if (icase && name[namelen - 1] == '/')
- ce = ce->dir_next;
- else
- ce = ce->next;
+ ce = ce->next;
}
/*
- * Might be a submodule. Despite submodules being directories,
+ * When looking for a directory (trailing '/'), it might be a
+ * submodule or a directory. Despite submodules being directories,
* they are stored in the name hash without a closing slash.
- * When ignore_case is 1, directories are stored in the name hash
+ * When ignore_case is 1, directories are stored in a separate hash
* with their closing slash.
*
* The side effect of this storage technique is we have need to
@@ -182,9 +228,37 @@ struct cache_entry *index_name_exists(struct index_state *istate, const char *na
* true.
*/
if (icase && name[namelen - 1] == '/') {
+ struct dir_entry *dir = find_dir_entry(istate, name, namelen);
+ if (dir && dir->nr)
+ return dir->ce;
+
ce = index_name_exists(istate, name, namelen - 1, icase);
if (ce && S_ISGITLINK(ce->ce_mode))
return ce;
}
return NULL;
}
+
+static int free_dir_entry(void *entry, void *unused)
+{
+ struct dir_entry *dir = entry;
+ while (dir) {
+ struct dir_entry *next = dir->next;
+ free(dir);
+ dir = next;
+ }
+ return 0;
+}
+
+void free_name_hash(struct index_state *istate)
+{
+ if (!istate->name_hash_initialized)
+ return;
+ istate->name_hash_initialized = 0;
+ if (ignore_case)
+ /* free directory entries */
+ for_each_hash(&istate->dir_hash, free_dir_entry, NULL);
+
+ free_hash(&istate->name_hash);
+ free_hash(&istate->dir_hash);
+}
diff --git a/read-cache.c b/read-cache.c
index 827ae55..47eb9d8 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -46,7 +46,7 @@ static void replace_index_entry(struct index_state *istate, int nr, struct cache
{
struct cache_entry *old = istate->cache[nr];
- remove_name_hash(old);
+ remove_name_hash(istate, old);
set_index_entry(istate, nr, ce);
istate->cache_changed = 1;
}
@@ -460,7 +460,7 @@ int remove_index_entry_at(struct index_state *istate, int pos)
struct cache_entry *ce = istate->cache[pos];
record_resolve_undo(istate, ce);
- remove_name_hash(ce);
+ remove_name_hash(istate, ce);
istate->cache_changed = 1;
istate->cache_nr--;
if (pos >= istate->cache_nr)
@@ -483,7 +483,7 @@ void remove_marked_cache_entries(struct index_state *istate)
for (i = j = 0; i < istate->cache_nr; i++) {
if (ce_array[i]->ce_flags & CE_REMOVE)
- remove_name_hash(ce_array[i]);
+ remove_name_hash(istate, ce_array[i]);
else
ce_array[j++] = ce_array[i];
}
@@ -1515,8 +1515,7 @@ int discard_index(struct index_state *istate)
istate->cache_changed = 0;
istate->timestamp.sec = 0;
istate->timestamp.nsec = 0;
- istate->name_hash_initialized = 0;
- free_hash(&istate->name_hash);
+ free_name_hash(istate);
cache_tree_free(&(istate->cache_tree));
istate->initialized = 0;
--
1.8.1.2.7986.g6e98809.dirty
^ permalink raw reply related
* Re: clean/smudge filters on .zip/.tgz files
From: Michael J Gruber @ 2013-02-27 15:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Tim Chase, git
In-Reply-To: <512DAA0E.9010401@viscovery.net>
Johannes Sixt venit, vidit, dixit 27.02.2013 07:39:
> Am 2/26/2013 23:38, schrieb Tim Chase:
>> Various programs that I use ([Open|Libre]Office, Vym, etc) use a
>> zipped/.tgz'ed file format, usually containing multiple
>> (usually) plain-text files within.
>>
>> I'm trying to figure out a way for git to treat these as virtual
>> directories for purposes of merging/diffing.
>>
>> Reading up on clean/smudge filters, it looks like they expect one
>> file coming in and one file going out, rather than one file
>> on one side and a directory-tree of files on the other side.
>>
>> I tried creating my own pair of clean/smudge filters that would
>> uncompress the files, but there's no good way put multiple files on
>> stdout.
>>
>> Has anybody else played with such a scheme for uncompressing files as
>> they go into git and recompressing them as they come back out?
>
> I attempted to do something like this for OpenDocument files (I didn't get
> very far) until I discovered that LibreOffice can save "flat open document
> files". That combined with the option "save files optimized" switched off
> results in fairly readable XML in a single file that can even be merged
> under some circumstances.
>
> You would still need a clean filter that normalizes the style numbers,
> cross reference marks and other stuff that changes each time LibreOffice
> saves the file.
>
> -- Hannes
>
In general, using "zip -0" is a good way of getting something that
delta-compresses well and that can give a meaningful diff (and has no
information loss).
The (my) problem is that recompressing a zip archive (i.e. multi-file)
is a pita, you can't just use a pipe "unzip | zip -0". You'd have to do
that in a temp dir.
Michael
^ permalink raw reply
* Re: [PATCH] Documentation/submodule: Add --force to update synopsis
From: Junio C Hamano @ 2013-02-27 15:31 UTC (permalink / raw)
To: Brad King; +Cc: git
In-Reply-To: <7bf0424a37df48a59e4d45fb93f8518ff2db00f5.1361925124.git.brad.king@kitware.com>
Thanks.
^ permalink raw reply
* [BUG] git gui alert dialogs interfere with each other
From: Yann Dirson @ 2013-02-27 15:26 UTC (permalink / raw)
To: git list; +Cc: me@bt
(Seen in 1.7.12.3)
When launching git gui in a repo where there are 1. lots of (>5000) stashed changes
(to do a tree move), and 2. many non-packed files, git gui throws 2 alert dialogs:
one saying that it will only show 5000 changed files and ignore the others, which
very quickly hidden by the offer to repack. If I decline repacking, then both
dialogs are discarded, and the first one, which is quite critical, may not have been
seen at all by the user.
--
Yann Dirson - Bertin Technologies
^ permalink raw reply
* Git Notes - Search Functionality
From: krishna chaitanya kurnala @ 2013-02-27 15:34 UTC (permalink / raw)
To: git
Hello All
I working on Git Notes. I want to know if there is an easy way to
obtain a list of all "namespaces"(For eg., git notes --ref=namespace
... ) with notes objects in a specific git repository. We can easily
create, edit, merge git notes with commands if we know the namespaces
and/or the sha. But, for example, Has anyone tried to search for a
string in a git notes objects for that project etc?
The closest i can think of is using some options with git logs, for
example, git log --show-notes=* --format="%H %N" etc.
Appreciate your time.
thanks
Krishna Chaitanya
^ permalink raw reply
* Re: [PATCH] attr: allow pattern escape using backslashes
From: Junio C Hamano @ 2013-02-27 15:42 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git
In-Reply-To: <CACsJy8Ag8rJ4P6w6ZCB0vBp6Hzqr_G5vWS_Jt=RNQT8+hF_w_A@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> On Sun, Feb 24, 2013 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Speaking of .gitignore, I recall that there was a hanging discussion
>> on allowing a pattern to name the directory that the .gitignore file
>> appears in, which I do not think we currently support. With such a
>> feature, instead of listing "/junk" in the .gitignore file at the
>> top-level to say that everything inside the "junk" directory is
>> ignored by default, we could instead say "<this>" at the beginning
>> of the .gitignore file in the "junk" directory.
>
> Shouldn't "/" alone in junk/.gitignore express that? It does not work,
> but I think it's a natural interpretation of the syntax.
Yup, there is nothing that you can plug to the "<this>" in the above
to make it mean "junk" directory is ignored. A trailing "/" is
removed after noting the fact that the entry is about a directory
and leaves an empty string, and it would be OK to define that an
empty string matches the directory the gitignore file appears in.
^ permalink raw reply
* Re: [PATCHv4 6/6] git-send-email: use git credential to obtain password
From: Junio C Hamano @ 2013-02-27 15:54 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michal Nazarewicz, peff, git
In-Reply-To: <vpqhakx4z4c.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Michal Nazarewicz <mpn@google.com> writes:
>
>> + $auth = Git::credential({
>> + 'protocol' => 'smtp',
>> + 'host' => join(':', $smtp_server, $smtp_server_port),
>
> At this point, $smtp_server_port is not always defined. I just tested
> and got
>
> Use of uninitialized value $smtp_server_port in join or string at
> git-send-email line 1077.
>
> Other than that, the whole series looks good.
Given that there is another place that conditionally append ":$port"
to the host string, I think we should follow suit here. Perhaps
like the attached diff?
Thanks for a review.
git-send-email.perl | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 76bbfc3..c3501d9 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1045,6 +1045,14 @@ sub maildomain {
return maildomain_net() || maildomain_mta() || 'localhost.localdomain';
}
+sub smtp_host_string {
+ if (defined $smtp_server_port) {
+ return "$smtp_server:$smtp_server_port";
+ } else {
+ return $smtp_server;
+ }
+}
+
# Returns 1 if authentication succeeded or was not necessary
# (smtp_user was not specified), and 0 otherwise.
@@ -1065,7 +1073,7 @@ sub smtp_auth_maybe {
# reject credentials.
$auth = Git::credential({
'protocol' => 'smtp',
- 'host' => join(':', $smtp_server, $smtp_server_port),
+ 'host' => smtp_host_string(),
'username' => $smtp_authuser,
# if there's no password, "git credential fill" will
# give us one, otherwise it'll just pass this one.
@@ -1188,9 +1196,7 @@ sub send_message {
else {
require Net::SMTP;
$smtp_domain ||= maildomain();
- $smtp ||= Net::SMTP->new((defined $smtp_server_port)
- ? "$smtp_server:$smtp_server_port"
- : $smtp_server,
+ $smtp ||= Net::SMTP->new(smtp_host_string(),
Hello => $smtp_domain,
Debug => $debug_net_smtp);
if ($smtp_encryption eq 'tls' && $smtp) {
^ permalink raw reply related
* git blame -M seems not to work as expected
From: Sokolov, Konstantin (ext) @ 2013-02-27 15:45 UTC (permalink / raw)
To: git@vger.kernel.org
Hi Folks!
I've posed this question already on stackoverflow and on Google Groups - without any (satisfying) answer. So maybe you can help me to understand the behavior of git blame -M.
First I commit the following file(file.cpp):
void func1(){return;}[CR][LF]
int func2(){return 23;}[CR][LF]
Then I modify it by moving what was in the first line and adding something new instead:
float newFunc(){return 23.0;}[CR][LF]
int func2(){return 23;}[CR][LF]
[CR][LF]
[CR][LF]
void func1(){return;}[CR][LF]
The log now looks as follows:
>git log --oneline -2
18c670f modified file.cpp
92b4186 added file.cpp
Now I run blame:
git blame -s -w -M file.cpp
18c670fa 1) float newFunc(){return 23.0;}
92b4186d 2) int func2(){return 23;}
18c670fa 3)
18c670fa 4)
18c670fa 5) void func1(){return;}
I wonder why the line containing func1() isn't recognized as moved. I've tried to reduce the number of required characters (i.e. -M4 etc.). Furthermore spaces should not matter because of the -w option.
On the other hand, when I move float newFunc(){return 23.0;} from line 1 to line 6 (which was empty before) in the subsequent commit, git blame -M correctly recognizes that it originates from commit 18c670fa even though it firstly appeared in line 6 only in the current commit.
So what's the reason for this seemingly inconsequent behavior? As far as I understand the documentation, both movements should be recognized. It's very important for us to correctly understand the behavior of git blame -M since we are about to add some code analysis logic on top of git blame.
Thanks in advance
Konstantin
^ permalink raw reply
* Re: Git Notes - Search Functionality
From: Thomas Rast @ 2013-02-27 15:57 UTC (permalink / raw)
To: krishna chaitanya kurnala; +Cc: git
In-Reply-To: <CAFZnXLJCiq4G+_ZStWmjAGePWCD6mhske7Y4=oe2h==F0BYVLQ@mail.gmail.com>
krishna chaitanya kurnala <kkc4al@gmail.com> writes:
> I working on Git Notes. I want to know if there is an easy way to
> obtain a list of all "namespaces"(For eg., git notes --ref=namespace
> ... ) with notes objects in a specific git repository. We can easily
> create, edit, merge git notes with commands if we know the namespaces
> and/or the sha. But, for example, Has anyone tried to search for a
> string in a git notes objects for that project etc?
> The closest i can think of is using some options with git logs, for
> example, git log --show-notes=* --format="%H %N" etc.
>
> Appreciate your time.
An easy way to list everything in refs/notes/ is
git for-each-ref refs/notes/
but that of course won't figure out if you have more notes e.g. in
refs/remotes/origin/notes/* or some such. I think this more general
problem can be solved only by heuristics, since the notes trees are
actually "just trees" -- the only distinction is that they have fairly
funny filenames in them.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCHv4 6/6] git-send-email: use git credential to obtain password
From: Michal Nazarewicz @ 2013-02-27 16:09 UTC (permalink / raw)
To: Junio C Hamano, Matthieu Moy; +Cc: peff, git
In-Reply-To: <7vehg1kb09.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 3715 bytes --]
On Wed, Feb 27 2013, Junio C Hamano <gitster@pobox.com> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>> Michal Nazarewicz <mpn@google.com> writes:
>>
>>> + $auth = Git::credential({
>>> + 'protocol' => 'smtp',
>>> + 'host' => join(':', $smtp_server, $smtp_server_port),
>>
>> At this point, $smtp_server_port is not always defined. I just tested
>> and got
>>
>> Use of uninitialized value $smtp_server_port in join or string at
>> git-send-email line 1077.
>>
>> Other than that, the whole series looks good.
>
> Given that there is another place that conditionally append ":$port"
> to the host string, I think we should follow suit here. Perhaps
> like the attached diff?
Damn meetings, you beat me to it… I was just about to send a patch. ;)
> Thanks for a review.
>
>
> git-send-email.perl | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 76bbfc3..c3501d9 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1045,6 +1045,14 @@ sub maildomain {
> return maildomain_net() || maildomain_mta() || 'localhost.localdomain';
> }
>
> +sub smtp_host_string {
> + if (defined $smtp_server_port) {
> + return "$smtp_server:$smtp_server_port";
> + } else {
> + return $smtp_server;
> + }
> +}
> +
> # Returns 1 if authentication succeeded or was not necessary
> # (smtp_user was not specified), and 0 otherwise.
>
> @@ -1065,7 +1073,7 @@ sub smtp_auth_maybe {
> # reject credentials.
> $auth = Git::credential({
> 'protocol' => 'smtp',
> - 'host' => join(':', $smtp_server, $smtp_server_port),
> + 'host' => smtp_host_string(),
> 'username' => $smtp_authuser,
> # if there's no password, "git credential fill" will
> # give us one, otherwise it'll just pass this one.
> @@ -1188,9 +1196,7 @@ sub send_message {
> else {
> require Net::SMTP;
> $smtp_domain ||= maildomain();
> - $smtp ||= Net::SMTP->new((defined $smtp_server_port)
> - ? "$smtp_server:$smtp_server_port"
> - : $smtp_server,
> + $smtp ||= Net::SMTP->new(smtp_host_string(),
> Hello => $smtp_domain,
> Debug => $debug_net_smtp);
> if ($smtp_encryption eq 'tls' && $smtp) {
>From reading of SMTP.pm, it seems that this could be changed to:
- $smtp ||= Net::SMTP->new((defined $smtp_server_port)
- ? "$smtp_server:$smtp_server_port"
- : $smtp_server,
+ $smtp ||= Net::SMTP->new($smtp_server,
+ Port => $smtp_server_port,
and than the other part would become:
@@ -1060,12 +1060,17 @@ sub smtp_auth_maybe {
Authen::SASL->import(qw(Perl));
};
+ my $host = $smtp_server;
+ if (defined $smtp_server_port) {
+ $host .= ':' . $smtp_server_port;
+ }
+
# TODO: Authentication may fail not because credentials were
# invalid but due to other reasons, in which we should not
# reject credentials.
$auth = Git::credential({
'protocol' => 'smtp',
- 'host' => join(':', $smtp_server, $smtp_server_port),
+ 'host' => $host,
'username' => $smtp_authuser,
# if there's no password, "git credential fill" will
# give us one, otherwise it'll just pass this one.
Either way, looks good to me.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michał “mina86” Nazarewicz (o o)
ooo +----<email/xmpp: mpn@google.com>--------------ooO--(_)--Ooo--
[-- Attachment #2.1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2.2: Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox