Re: [BUG?] git http connection reuse
On Tue, 18 Feb 2014, Jeff King wrote: I think there is still an unrelated issue with curl_multi preventing connection reuse, but I'm not sure from what you say below... I'm not clear whether you mean by this that it is _expected_ in my test program for curl not to reuse the connection. Or that curl may simply have to do a little more work, and it is still a bug that the connection is not reused. Argh, sorry. I thought were still referring to the previous problem. I can indeed repeat the problem you talk about with your test code. Thanks! I'll get back to you. -- / daniel.haxx.se -- 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] config: teach git config --file - to read from the standard input
On Sun, Feb 16, 2014 at 02:13:01PM +0200, Kirill A. Shutemov wrote:
The patch extends git config --file interface to allow read config from
stdin.
Editing stdin or setting value in stdin is an error.
Include by absolute path is allowed in stdin config, but not by relative
path.
Thanks, this looks very cleanly done.
One nit:
diff --git a/config.c b/config.c
index 6269da907964..7b42608f5c89 100644
--- a/config.c
+++ b/config.c
@@ -443,10 +443,20 @@ static int git_parse_source(config_fn_t fn, void *data)
if (get_value(fn, data, var) 0)
break;
}
- if (cf-die_on_error)
- die(bad config file line %d in %s, cf-linenr, cf-name);
- else
- return error(bad config file line %d in %s, cf-linenr,
cf-name);
+ if (cf-die_on_error) {
+ if (cf-name)
+ die(bad config file line %d in %s,
+ cf-linenr, cf-name);
+ else
+ die(bad config file line %d, cf-linenr);
+
+ } else {
+ if (cf-name)
+ return error(bad config file line %d in %s,
+ cf-linenr, cf-name);
+ else
+ return error(bad config file line %d, cf-linenr);
+ }
I think I preferred the earlier version where you had stdin in the
name field, and this hunk could just go away. I know you switched it to
NULL here to avoid making bogus relative filenames in includes.
But that would be pretty straightforward to fix by splitting the name
field into an additional path field. It looks like git config --blob
has the same problem (it will try relative lookups in the filesystem,
even though that is nonsensical from the blob). So we could fix the
existing bug at the same time. :)
Perhaps this could go at the start of your series?
-- 8 --
Subject: config: disallow relative include paths from blobs
When we see a relative config include like:
[include]
path = foo
we make it relative to the containing directory of the file
that contains the snippet. This makes no sense for config
read from a blob, as it is not on the filesystem. Something
like HEAD:some/path could have a relative path within the
tree, but:
1. It would not be part of include.path, which explicitly
refers to the filesystem.
2. It would need different parsing rules anyway to
determine that it is a tree path.
The current code just uses the name field, which is wrong.
Let's split that into name and path fields, use the
latter for relative includes, and fill in only the former
for blobs.
Signed-off-by: Jeff King p...@peff.net
---
I don't think we considered includes at all when adding --blob. I cannot
think of any good reason to have even an absolute filesystem include
from a blob. And I wonder if it is possible to cause security mischief
by convincing git to look at /etc/passwd or similar (it would not parse,
of course, but you might be able to glean information from the error
messages or something).
It's probably OK, though, because you would generally not read real
config from an untrusted source (there are many bad things they could
set), and other code which uses the config reader explicitly does not
turn on includes.
config.c | 10 ++
t/t1305-config-include.sh | 16
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index d969a5a..b295310 100644
--- a/config.c
+++ b/config.c
@@ -21,6 +21,7 @@ struct config_source {
} buf;
} u;
const char *name;
+ const char *path;
int die_on_error;
int linenr;
int eof;
@@ -97,12 +98,12 @@ static int handle_path_include(const char *path, struct
config_include_data *inc
if (!is_absolute_path(path)) {
char *slash;
- if (!cf || !cf-name)
+ if (!cf || !cf-path)
return error(relative config includes must come from
files);
- slash = find_last_dir_sep(cf-name);
+ slash = find_last_dir_sep(cf-path);
if (slash)
- strbuf_add(buf, cf-name, slash - cf-name + 1);
+ strbuf_add(buf, cf-path, slash - cf-path + 1);
strbuf_addstr(buf, path);
path = buf.buf;
}
@@ -1040,7 +1041,7 @@ int git_config_from_file(config_fn_t fn, const char
*filename, void *data)
struct config_source top;
top.u.file = f;
- top.name = filename;
+ top.name = top.path = filename;
top.die_on_error = 1;
top.do_fgetc = config_file_fgetc;
top.do_ungetc = config_file_ungetc;
@@ -1062,6 +1063,7 @@ int git_config_from_buf(config_fn_t fn, const char *name,
const char *buf,
top.u.buf.len = len;
top.u.buf.pos = 0;
Re: [PATCH 1/5] notes-utils: handle boolean notes.rewritemode correctly
Jeff King p...@peff.net writes: On Sun, Feb 16, 2014 at 05:22:45PM +0100, David Kastrup wrote: config.c:#undef config_error_nonbool config.c:int config_error_nonbool(const char *var) You could always look in the commit history: $ git log -S'#define config_error_nonbool' cache.h or search the mailing list: http://thread.gmane.org/gmane.comp.version-control.git/211505 Presumably this was done so that the uses of config_error_nonbool can be recognized as returning -1 unconditionally. Yes, it helps prevent false positives in gcc's flow analysis (specifically, -Wuninitialized warnings). But is that worth the obfuscation? Yes? gcc's flow analysis works with the same data as humans reading the code. If there is no information content in the function call, it makes more sense to either making it void. One can always explicitly write (config_error_nonbool(panic-when-assailed), -1) for shortcircuit use inside of an expression even when config_error_nonbool is a function returning a void expression: comma operators do not try type coercion on their first argument. Shrug. This one has likely been discussed to death already. Sometimes it's more convenient to avoid getting a question asked in the first place rather than having a stock answer for it. -- David Kastrup -- 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/5] notes-utils: handle boolean notes.rewritemode correctly
On Tue, Feb 18, 2014 at 09:41:51AM +0100, David Kastrup wrote:
gcc's flow analysis works with the same data as humans reading the
code. If there is no information content in the function call, it makes
more sense to either making it void.
The point of error() returning a constant -1 is to use this idiom:
if (something_failed)
return error(this will get printed, and we get a -1 return);
From a code perspective it's pointless. You could just write:
if (something_failed) {
error(...);
return -1;
}
which is equivalent. But the point is that the former is shorter and a
little more readable, assuming you are familiar with the idiom.
One can always explicitly write
(config_error_nonbool(panic-when-assailed), -1)
Yes, but again, the point is readability. Doing that at each callsite is
ugly and annoying.
Shrug. This one has likely been discussed to death already. Sometimes
it's more convenient to avoid getting a question asked in the first
place rather than having a stock answer for it.
You are the first person to ask about it, so there is no stock answer.
However, everything I told you was in the commit messages and the list
archive already. We can also avoid questions being asked by using those
tools.
-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: [msysGit] Git for Windows 1.9.0 (fwd)
On Tue, Feb 18, 2014 at 3:33 AM, Mike Hommey m...@glandium.org wrote: On Tue, Feb 18, 2014 at 12:52:28AM +0100, Johannes Schindelin wrote: Hopefully the Postfix Greylisting Policy Server will not try again to greylist me, as it might however do without violating the RFC. -- Forwarded message -- Date: Tue, 18 Feb 2014 00:38:54 +0100 (CET) From: Johannes Schindelin johannes.schinde...@gmx.de To: msys...@googlegroups.com Cc: git@vger.kernel.org Subject: [msysGit] Git for Windows 1.9.0 Dear Git fanbois, this announcement informs you that the small team of volunteers who keep the Git ship afloat for the most prevalent desktop operating system managed to release yet another version of Git for Windows: Git Release Notes (Git-1.9.0-preview20140217) Last update: 17 February 2013 Changes since Git-1.8.5.2-preview20131230 New Features - Comes with Git 1.9.0 plus Windows-specific patches. - Better work-arounds for Windows-specific path length limitations (pull request #122) - Uses optimized TortoiseGitPLink when detected (msysGit pull request #154) - Allow Windows users to use Linux Git on their files, using Vagrant http://www.vagrantup.com/ (msysGit pull request #159) I was curious about this, so i went to github and... couldn't find any pull request above #126. It's right here: https://github.com/msysgit/msysgit/pull/159 You probably looked in our git repo rather than our msysGit repo. -- 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: [msysGit] Git for Windows 1.9.0
Am 18.02.2014 00:38, schrieb Johannes Schindelin:
Dear Git fanbois,
this announcement informs you that the small team of volunteers who keep
the Git ship afloat for the most prevalent desktop operating system
managed to release yet another version of Git for Windows:
Git Release Notes (Git-1.9.0-preview20140217)
Last update: 17 February 2013
Changes since Git-1.8.5.2-preview20131230
New Features
- Comes with Git 1.9.0 plus Windows-specific patches.
- Better work-arounds for Windows-specific path length limitations (pull
request #122)
- Uses optimized TortoiseGitPLink when detected (msysGit pull request
#154)
- Allow Windows users to use Linux Git on their files, using Vagrant
http://www.vagrantup.com/ (msysGit pull request #159)
- InnoSetup 5.5.4 is now used to generate the installer (msysGit pull
request #167)
Bugfixes
- Fixed regression with interactive password prompt for remotes using the
HTTPS protocol (issue #111)
- We now work around Subversion servers printing non-ISO-8601-compliant
time stamps (pull request #126)
- The installer no longer sets the HOME environment variable (msysGit pull
request #166)
- Perl no longer creates empty sys$command files when no stdin is
connected (msysGit pull request #152)
Ciao,
Johannes
Thanks to all involved!
Stefan
--
/dev/random says: I didn't cheat, I just changed the Rules!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
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?] git http connection reuse
On Tue, 18 Feb 2014, Jeff King wrote: I'm not clear whether you mean by this that it is _expected_ in my test program for curl not to reuse the connection. Or that curl may simply have to do a little more work, and it is still a bug that the connection is not reused. Okey, I checked this closer now and this is the full explanation to what happens. It seems to work as intended: It's all about where the connection cache is held by libcurl. When you create a multi handle, it will create a connection cache that will automatically be shared by all easy handles that are added to it. If you create an easy handle and make a curl_easy_perform() on that, it will create its own connection cache and keep it associated with this easy handle. When first using an easy handle within a multi handle it will use the shared connection cache in there as long as it is in that multi handle family, but as soon as you remove it from there it will be detached from that connection cache. Then, when doing a fresh request with easy_perform using the handle that was detached from the multi handle, it will create and use its own private cache as it can't re-use the previous connection that is cached within the multi handle. We can certainly teach git to use the multi interface, even when doing a single blocking request. For connection re-use purposes, that may make a lot of sense. -- / daniel.haxx.se -- 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] revert.c: Allow to specify -x via git-config
On Tue, Feb 18, 2014 at 07:56:20AM +0100, Guido Günther wrote:
Without this when maintaining stable branches it's easy to forget to use
-x to track where a patch was cherry-picked from.
Signed-off-by: Guido Günther a...@sigxcpu.org
---
Documentation/git-cherry-pick.txt | 8
builtin/revert.c | 10 ++
2 files changed, 18 insertions(+)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index c205d23..c35064f 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -215,6 +215,14 @@ the working tree.
spending extra time to avoid mistakes based on incorrectly matching
context lines.
+CONFIGURATION
+-
+
+See linkgit:git-config[1] for core variables.
+
+cherrypick.record-origin::
For consistency, this should be cherrypick.recordOrigin, although I
wonder if we should permit cherry-pick here so as to keep the config
section the same as the name of the command.
I think this should also be added to git-config(1)
+ Default for the `-x` option. Defaults to `false`.
+
SEE ALSO
linkgit:git-revert[1]
diff --git a/builtin/revert.c b/builtin/revert.c
index 87659c9..df9718f 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -196,6 +196,15 @@ int cmd_revert(int argc, const char **argv, const char
*prefix)
return res;
}
+static int git_cherry_pick_config(const char *var, const char *value, void
*cb)
+{
+ struct replay_opts *opts = cb;
+
+ if (!strcmp(var, cherrypick.record-origin))
+ opts-record_origin = git_config_bool (var, value);
+ return 0;
If you change this to:
return git_default_config(var, value, cb);
then the code below won't end up walking the config twice.
+}
+
int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
struct replay_opts opts;
@@ -204,6 +213,7 @@ int cmd_cherry_pick(int argc, const char **argv, const
char *prefix)
memset(opts, 0, sizeof(opts));
opts.action = REPLAY_PICK;
git_config(git_default_config, NULL);
+ git_config(git_cherry_pick_config, opts);
parse_args(argc, argv, opts);
res = sequencer_pick_revisions(opts);
if (res 0)
--
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: [msysGit] Git for Windows 1.9.0 (fwd)
On Tue, Feb 18, 2014 at 10:04:54AM +0100, Erik Faye-Lund wrote: It's right here: https://github.com/msysgit/msysgit/pull/159 You probably looked in our git repo rather than our msysGit repo. Oh indeed I was, thanks. Mike -- 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 gc --aggressive led to about 40 times slower git log --raw
Christian Jaeger chr...@gmail.com writes: I've got a repository where git log --raw _somefile took a few seconds in the past, but after an attempt at merging some commits that were collected in a clone of the same repo that was created about a year ago, I noticed that this command was now taking 3 minutes 7 seconds. git gc, git fsck, git clone file:///the/repo/.git also now each took between ~4-10 minutes, also git log --raw somefile got equally unusably slow. With the help of the people on the IRC, I tracked it down to my recent use of git gc --aggressive in this repo. Running git repack -a -d -f solved it, now it's again taking 4-5 seconds. After running git gc --aggressive again for confirmation, git log --raw _somefile was again slowed down, although now 'only' to 1 minute 34 seconds; [...] I've now learned to avoid git gc --aggressive. Perhaps there are some other conclusions to be drawn, I don't know. I've seen the same with my ongoing work on git-blame with the current Emacs Git mirror. Aggressive packing reduces the repository size to about a quarter, but it blows up the system time (mainly I/O) significantly, quite reducing the total benefits of my algorithmic improvements there. There is also some quite visible additional time spent in zlib, so a wild guess would be that zlib is not really suited to the massive amount of directory entries of a Git object store. Since the system time still dominates, this guess would only make sense if Git over zlib kept rereading the directory section of whatever compressed file we are talking about. But that's really a rather handwavy wild guess without anything better than a hunch to back it up. I don't even know what kind of compression and/or packs are used: I've only ever messed myself with the delta coding of the normal unpacked operation (there are a few older commits from me on that). -- David Kastrup -- 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/5] notes-utils: handle boolean notes.rewritemode correctly
Jeff King p...@peff.net writes:
On Tue, Feb 18, 2014 at 09:41:51AM +0100, David Kastrup wrote:
gcc's flow analysis works with the same data as humans reading the
code. If there is no information content in the function call, it makes
more sense to either making it void.
The point of error() returning a constant -1 is to use this idiom:
if (something_failed)
return error(this will get printed, and we get a -1 return);
if (something_failed)
return error(this will get printed), -1;
Not much of an idiom, no insider logic hidden to both compiler and
reader.
From a code perspective it's pointless. You could just write:
if (something_failed) {
error(...);
return -1;
}
which is equivalent. But the point is that the former is shorter and a
little more readable, assuming you are familiar with the idiom.
Assuming that.
One can always explicitly write
(config_error_nonbool(panic-when-assailed), -1)
Yes, but again, the point is readability. Doing that at each callsite is
ugly and annoying.
I consider insider semantics ugly and annoying. To each his own.
You are the first person to ask about it, so there is no stock answer.
However, everything I told you was in the commit messages and the list
archive already. We can also avoid questions being asked by using
those tools.
It's further raising the barriers for contributors if they are expected
to have studied the last few years in the mailing archive. And the
skills needed for that kind of study are mostly unrelated to good
programming skills.
So I am less than convinced that this is among the coding practices that
can be expected to attract/scare away potential contributors in
proportion to their expected capability of advancing/hindering the
project.
It's not me running the shop, so it's nothing more than an opinion.
--
David Kastrup
--
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 gc --aggressive led to about 40 times slower git log --raw
On Tue, Feb 18, 2014 at 3:55 PM, David Kastrup d...@gnu.org wrote: Christian Jaeger chr...@gmail.com writes: I've got a repository where git log --raw _somefile took a few seconds in the past, but after an attempt at merging some commits that were collected in a clone of the same repo that was created about a year ago, I noticed that this command was now taking 3 minutes 7 seconds. git gc, git fsck, git clone file:///the/repo/.git also now each took between ~4-10 minutes, also git log --raw somefile got equally unusably slow. With the help of the people on the IRC, I tracked it down to my recent use of git gc --aggressive in this repo. Running git repack -a -d -f solved it, now it's again taking 4-5 seconds. After running git gc --aggressive again for confirmation, git log --raw _somefile was again slowed down, although now 'only' to 1 minute 34 seconds; [...] I've now learned to avoid git gc --aggressive. Perhaps there are some other conclusions to be drawn, I don't know. I've seen the same with my ongoing work on git-blame with the current Emacs Git mirror. Aggressive packing reduces the repository size to about a quarter, but it blows up the system time (mainly I/O) significantly, quite reducing the total benefits of my algorithmic improvements there. Likely because --aggressive passes --depth=250 to pack-objects. Long delta chains could reduce pack size and increase I/O as well as zlib processing signficantly. Christian can try git repack -adf which is really close to --aggressive (except it uses default --depth=50) and see if it makes any difference. There is also some quite visible additional time spent in zlib, so a wild guess would be that zlib is not really suited to the massive amount of directory entries of a Git object store. Since the system time still dominates, this guess would only make sense if Git over zlib kept rereading the directory section of whatever compressed file we are talking about. But that's really a rather handwavy wild guess without anything better than a hunch to back it up. I don't even know what kind of compression and/or packs are used: I've only ever messed myself with the delta coding of the normal unpacked operation (there are a few older commits from me on that). -- David Kastrup -- 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 -- 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: git gc --aggressive led to about 40 times slower git log --raw
Duy Nguyen pclo...@gmail.com writes: On Tue, Feb 18, 2014 at 3:55 PM, David Kastrup d...@gnu.org wrote: I've seen the same with my ongoing work on git-blame with the current Emacs Git mirror. Aggressive packing reduces the repository size to about a quarter, but it blows up the system time (mainly I/O) significantly, quite reducing the total benefits of my algorithmic improvements there. Likely because --aggressive passes --depth=250 to pack-objects. Long delta chains could reduce pack size and increase I/O as well as zlib processing signficantly. Increased zlib processing time is one thing, but if it _increases_ I/O, then it would seem there is a serious impedance mismatch between the compression scheme and the code relying on it, leading to repeated reads of blocks only needed for reconstructing dynamic compression dictionaries. Compression should reduce rather than increase the total amount of reads. So it would seem that either better caching and/or smaller independent block sizes and/or strategies for sorting the delta chain to make its resolution require mostly linear reads, and then make sure to do this in a manner that does not reinitialize the decompression for accessing each delta that happens to be more or less in sequence. Of course, this is assuming that the additional time is spent uncompressing data rather than navigating directories. It's actually conceivable that there is quite a bit of potential to get better performance from unchanged readers by packing stuff in a different order while still using the same delta chain depth. -- David Kastrup -- 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
Problems while converting complex repository from SVN
Hi,
I had some issues while converting our current SVN repository to a GIT
repository. The old repository has a lot of strange history in it making
it far from easy to convert it but for some issues I had to modify the
convert scripts.
As I don't know the internals of GIT or git-svn enough I don't know if
these are actually bugs or not. I will also not produce and submit
patches to fix this as I don't know enough Perl to know if maybe it can
be solved in a better way or that it should be solved at all.
1. issue with git-svn dying because git could not find the refname. I
noticed that in the function resolve_local_globs it was actually passing
desanitized names to the cmt_metadata function, so I changed the code to
use sanitized names, trying to keep the rest of the script (which I
don't pretend to understand) intact:
sub resolve_local_globs {
my ($url, $fetch, $glob_spec) = @_;
return unless defined $glob_spec;
my $ref = $glob_spec-{ref};
my $path = $glob_spec-{path};
foreach (command(qw#for-each-ref --format=%(refname) refs/#)) {
next unless m#^$ref-{regex}$#;
my $p = $1;
my $pathname = $path-full_path($p);
my $svnpathname = desanitize_refname($pathname);
my $refname = $ref-full_path($p);
my $svnrefname = desanitize_refname($refname);
if (my $existing = $fetch-{$svnpathname}) {
if ($existing ne $svnrefname) {
die Refspec conflict:\n,
existing: $existing\n,
globbed: $svnrefname\n;
}
my $u = (::cmt_metadata($refname))[0];
$u =~ s!^\Q$url\E(/|$)!! or die
$svnrefname: '$url' not found in '$u'\n;
if ($pathname ne $u) {
warn W: Refspec glob conflict ,
(ref: $svnrefname):\n,
expected path: $pathname\n,
real path: $u\n,
Continuing ahead with $u\n;
next;
}
} else {
$fetch-{$svnpathname} = $svnrefname;
}
}
}
2. issue with an @ being present in a branch name. A first branch was
created just fine, but a second branch was created from that branch
which failed.
The following message (simplified for confidentiality reasons) was
shown while trying to branch 'blabla bla@bla blabla' to 'blabla blabla'
Found possible branch point:
svn://localhost/path/to/branch/blabla%20bla@bla%20blabla =
svn://localhost/path/to/branches/blabla%20blabla, 13486
refs/remotes/origin/branches/blabla bla@bla blabla: 'svn://localhost'
not found in 'svn://bla%20blabla'
I found out that the git-svn-id was actually being wrongly initiated to
'svn://bla%20blabla'. This is due to a mistake in the regex that is used
in remove_username.
It was:
$_[0] =~ s{^([^:]*://)[^@]+@}{$1};
I changed it to
$_[0] =~ s{^([^:]*://)[^@/]+@}{$1};
And it works.
I did all this using the standard Git package for Windows, release
1.8.5.2
PS: I tried to send this from my work email several times but I think
the mail server can't handle the greylisting so I apologize if the mails
still end up in the list.
--
Met vriendelijke groeten,
Best regards,
Mathy Vanvoorden
--
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
http: never use curl_easy_perform
On Tue, Feb 18, 2014 at 10:09:29AM +0100, Daniel Stenberg wrote:
Okey, I checked this closer now and this is the full explanation to
what happens. It seems to work as intended:
Thanks, your explanation makes perfect sense.
I think we should apply the patch below for git to consistently use the
multi interface. With this (and the recent patch for the NTLM issue), I
can do a whole smart-http clone over a single connection. This doesn't
make a huge difference for github.com, because the ssl session cache
eliminates most of the repeated work, but for servers which do not
implement ssl session caching, it may be more noticeable.
-- 8 --
Subject: http: never use curl_easy_perform
We currently don't reuse http connections when fetching via
the smart-http protocol. This is bad because the TCP
handshake introduces latency, and especially because SSL
connection setup may be non-trivial.
We can fix it by consistently using curl's multi
interface. The reason is rather complicated:
Our http code has two ways of being used: queuing many
slots to be fetched in parallel, or fetching a single
request in a blocking manner. The parallel code is built on
curl's multi interface. Most of the single-request code
uses http_request, which is built on top of the parallel
code (we just feed it one slot, and wait until it finishes).
However, one could also accomplish the single-request scheme
by avoiding curl's multi interface entirely and just using
curl_easy_perform. This is simpler, and is used by post_rpc
in the smart-http protocol.
It does work to use the same curl handle in both contexts,
as long as it is not at the same time. However, internally
curl may not share all of the cached resources between both
contexts. In particular, a connection formed using the
multi code will go into a reuse pool connected to the
multi object. Further requests using the easy interface
will not be able to reuse that connection.
The smart http protocol does ref discovery via http_request,
which uses the multi interface, and then follows up with
the easy interface for its rpc calls. As a result, we make
two HTTP connections rather than reusing a single one.
We could teach the ref discovery to use the easy
interface. But it is only once we have done this discovery
that we know whether the protocol will be smart or dumb. If
it is dumb, then our further requests, which want to fetch
objects in parallel, will not be able to reuse the same
connection.
Instead, this patch switches post_rpc to build on the
parallel interface, which means that we use it consistently
everywhere. It's a little more complicated to use, but since
we have the infrastructure already, it doesn't add any code;
we can just factor out the relevant bits from http_request.
Signed-off-by: Jeff King p...@peff.net
---
http.c| 24 +++-
http.h| 9 +
remote-curl.c | 5 +
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/http.c b/http.c
index 70eaa26..1212c58 100644
--- a/http.c
+++ b/http.c
@@ -880,6 +880,20 @@ int handle_curl_result(struct slot_results *results)
}
}
+int run_one_slot(struct active_request_slot *slot,
+struct slot_results *results)
+{
+ slot-results = results;
+ if (!start_active_slot(slot)) {
+ snprintf(curl_errorstr, sizeof(curl_errorstr),
+failed to start HTTP request);
+ return HTTP_START_FAILED;
+ }
+
+ run_active_slot(slot);
+ return handle_curl_result(results);
+}
+
static CURLcode curlinfo_strbuf(CURL *curl, CURLINFO info, struct strbuf *buf)
{
char *ptr;
@@ -907,7 +921,6 @@ static int http_request(const char *url,
int ret;
slot = get_active_slot();
- slot-results = results;
curl_easy_setopt(slot-curl, CURLOPT_HTTPGET, 1);
if (result == NULL) {
@@ -942,14 +955,7 @@ static int http_request(const char *url,
curl_easy_setopt(slot-curl, CURLOPT_HTTPHEADER, headers);
curl_easy_setopt(slot-curl, CURLOPT_ENCODING, gzip);
- if (start_active_slot(slot)) {
- run_active_slot(slot);
- ret = handle_curl_result(results);
- } else {
- snprintf(curl_errorstr, sizeof(curl_errorstr),
-failed to start HTTP request);
- ret = HTTP_START_FAILED;
- }
+ ret = run_one_slot(slot, results);
if (options options-content_type)
curlinfo_strbuf(slot-curl, CURLINFO_CONTENT_TYPE,
diff --git a/http.h b/http.h
index cd37d58..a828884 100644
--- a/http.h
+++ b/http.h
@@ -90,6 +90,15 @@ extern void finish_active_slot(struct active_request_slot
*slot);
extern void finish_all_active_slots(void);
extern int handle_curl_result(struct slot_results *results);
+/*
+ * This will run one slot to completion in a blocking manner, similar to how
+ * curl_easy_perform would work (but we don't want to use that, because
+ * we
[PATCH] Rename read_replace_refs to check_replace_refs
The semantics of this flag was changed in commit
ecef23 inline lookup_replace_object() calls
but wasn't renamed at the time to minimize code churn. Rename it now,
and add a comment explaining its use.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
This change doesn't conflict with anything in pu; perhaps we can
squeeze it in now?
builtin/fsck.c | 2 +-
builtin/index-pack.c | 2 +-
builtin/pack-objects.c | 2 +-
builtin/prune.c | 2 +-
builtin/replace.c| 2 +-
builtin/unpack-objects.c | 2 +-
cache.h | 14 --
environment.c| 4 ++--
git.c| 2 +-
log-tree.c | 2 +-
replace_object.c | 2 +-
upload-pack.c| 2 +-
12 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 1affdd5..3d42978 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -630,7 +630,7 @@ int cmd_fsck(int argc, const char **argv, const char
*prefix)
struct alternate_object_database *alt;
errors_found = 0;
- read_replace_refs = 0;
+ check_replace_refs = 0;
argc = parse_options(argc, argv, prefix, fsck_opts, fsck_usage, 0);
diff --git a/builtin/index-pack.c b/builtin/index-pack.c
index 2f37a38..a6b1c17 100644
--- a/builtin/index-pack.c
+++ b/builtin/index-pack.c
@@ -1502,7 +1502,7 @@ int cmd_index_pack(int argc, const char **argv, const
char *prefix)
if (argc == 2 !strcmp(argv[1], -h))
usage(index_pack_usage);
- read_replace_refs = 0;
+ check_replace_refs = 0;
reset_pack_idx_option(opts);
git_config(git_index_pack_config, opts);
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 541667f..124015d 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -2507,7 +2507,7 @@ int cmd_pack_objects(int argc, const char **argv, const
char *prefix)
OPT_END(),
};
- read_replace_refs = 0;
+ check_replace_refs = 0;
reset_pack_idx_option(pack_idx_opts);
git_config(git_pack_config, NULL);
diff --git a/builtin/prune.c b/builtin/prune.c
index de43b26..68adc1c 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -150,7 +150,7 @@ int cmd_prune(int argc, const char **argv, const char
*prefix)
expire = ULONG_MAX;
save_commit_buffer = 0;
- read_replace_refs = 0;
+ check_replace_refs = 0;
init_revisions(revs, prefix);
argc = parse_options(argc, argv, prefix, options, prune_usage, 0);
diff --git a/builtin/replace.c b/builtin/replace.c
index 2336325..8b59775 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -178,7 +178,7 @@ int cmd_replace(int argc, const char **argv, const char
*prefix)
OPT_END()
};
- read_replace_refs = 0;
+ check_replace_refs = 0;
argc = parse_options(argc, argv, prefix, options, git_replace_usage, 0);
diff --git a/builtin/unpack-objects.c b/builtin/unpack-objects.c
index 62ff673..df2d3e3 100644
--- a/builtin/unpack-objects.c
+++ b/builtin/unpack-objects.c
@@ -497,7 +497,7 @@ int cmd_unpack_objects(int argc, const char **argv, const
char *prefix)
int i;
unsigned char sha1[20];
- read_replace_refs = 0;
+ check_replace_refs = 0;
git_config(git_default_config, NULL);
diff --git a/cache.h b/cache.h
index dc040fb..b039abc 100644
--- a/cache.h
+++ b/cache.h
@@ -580,7 +580,17 @@ extern size_t packed_git_limit;
extern size_t delta_base_cache_limit;
extern unsigned long big_file_threshold;
extern unsigned long pack_size_limit_cfg;
-extern int read_replace_refs;
+
+/*
+ * Do replace refs need to be checked this run? This variable is
+ * initialized to true unless --no-replace-object is used or
+ * $GIT_NO_REPLACE_OBJECTS is set, but is set to false by some
+ * commands that do not want replace references to be active. As an
+ * optimization it is also set to false if replace references have
+ * been sought but there were none.
+ */
+extern int check_replace_refs;
+
extern int fsync_object_files;
extern int core_preload_index;
extern int core_apply_sparse_checkout;
@@ -791,7 +801,7 @@ static inline void *read_sha1_file(const unsigned char
*sha1, enum object_type *
extern const unsigned char *do_lookup_replace_object(const unsigned char
*sha1);
static inline const unsigned char *lookup_replace_object(const unsigned char
*sha1)
{
- if (!read_replace_refs)
+ if (!check_replace_refs)
return sha1;
return do_lookup_replace_object(sha1);
}
diff --git a/environment.c b/environment.c
index 4a3437d..c3c8606 100644
--- a/environment.c
+++ b/environment.c
@@ -45,7 +45,7 @@ const char *editor_program;
const char *askpass_program;
const char *excludes_file;
enum auto_crlf auto_crlf = AUTO_CRLF_FALSE;
-int read_replace_refs = 1; /* NEEDSWORK: rename to use_replace_refs */
+int
gitweb.cgi bug - XML Parsing Error: not well-formed
Here is gitweb generated XHTML fragment: div class=patch id=patch19 div class=diff headerdiff --git a/RFC/2010/DRE-2010-004 RFC for Update Synchronization Program amp; Solve the Balance Adjustment Issue v2.doc a class=path href=/repo/git?p=DRE/Reference.git;a=blob;f=RFC/2010/DRE-2010-004+RFC+for+Update+Synchronization+Program+%26+Solve+the+Balance+Adjustment+Issue+v2.doc;h=3074448e2e68235e891ebd1301e6277d993973a5;hb=fbd4e74c867214062ad39282a899f1d14a2e89bab/RFC/2010/DRE-2010-004 RFC for Update Synchronization Program amp; Solve the Balance Adjustment Issue v2.doc/a/div div class=diff extended_header new file mode 100644span class=info (file)/spanbr/ index 000..a class=hash href=/repo/git?p=DRE/Reference.git;a=blob;f=RFC/2010/DRE-2010-004+RFC+for+Update+Synchronization+Program+%26+Solve+the+Balance+Adjustment+Issue+v2.doc;h=3074448e2e68235e891ebd1301e6277d993973a5;hb=fbd4e74c867214062ad39282a899f1d14a2e89ba3074448/abr/ Binary files /dev/null and b/RFC/2010/DRE-2010-004 RFC for Update Synchronization Program Solve the Balance Adjustment Issue v2.doc differbr/ /div /div -- Dongsheng -- 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
Fwd: git p4: feature request - branch check filtering
Hi, I'm unable to find a similar issue, and if it's raised on the mailing list I apologize. I work at a company that has recently moved all CVS, SVN, and git repositories to Perforce. Depots have not been setup correctly in every case, and there is one depot that contains literally hundreds of projects under commercial development (and hundreds of branches as a result) My project may be in //stupid_depot/commercial/teamporter/rok. This is the path I clone with git-p4. The only branches in this depot that contain files at this path are titled as 'rok_porter_branch/release_1.x' or similar. When using '--detect-branches' git-p4 checks each key of branches to see if any of them have files in the path I've cloned. Whilst this is good in practice there is unfortunately 6,809 branches, git-p4 processes about 2 a second and just under an hour to perform any git-p4 rebase, submit, or similar operation. I propose the addition of a branch list filtering option (--filter-branches) that takes either a regular expression or list of branches it should check. This may be useful in sane situations where you don't want to scan every branch in a Perforce repository, or blacklist branches that have undesirable content (for example, one of the branches is called 'svn-backup'. It contains a single, multi-GB tarball.) It would be ideal to have this information (after initial clone or sync) stored somewhere in the git config where is appropriate so that future submit/rebase operations adhere to this list. Has something like this been worked on, or has been considered in the past? If not I will consider implementing this after reading up on the Git code guidelines. Thanks for keeping the Git workflow accessible in painful areas. Dan -- 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 5/5] implement @{publish} shorthand
On Tue, Feb 18, 2014 at 9:52 AM, Jeff King p...@peff.net wrote:
On Sat, Feb 15, 2014 at 11:50:10AM -, Philip Oakley wrote:
This patch introduces the branch@{publish} shorthand (or
@{pu} to be even shorter).
Just to say that I'm not sure that publish is the best word for
this concept.
[...]
I would much rather have a name that describes what the thing _is_, then
how it is meant to be used. The concept of @{publish} is a shorthand for
where would I push if I typed git push on this branch. In a
non-triangular workflow, that means sharing your commits with others on
the main branch. In a triangular workflow, it means sharing your commits
with a publishing point so that others can see them. If your default
push goes to a backup repo, it does not mean publishing at all, but
rather syncing the backup.
So I do not think any one word can describe all of those use cases; they
are orthogonal to each other, and it depends on your workflow.
In that sense, publish is not the best word, either, as it describes
only the first two, but not the third case (and those are just examples;
there may be other setups beyond that, even).
Perhaps @{push} would be the most direct word.
I agree that we want a more general (i.e. workflow-agnostic) term to
differentiate between where we pull from, and where we push to. As
such, @{push} should have a corresponding @{pull} (which I believe
should function as an alias of @{upstream}). [1]
...Johan
[1]: I don't think there is a reason not to reuse the push/pull
terminology for these concepts, but if there is, I guess we could
instead call them @{source}/@{destination}, @{src}/@{dst}, or
@{from}/@{to}, or somesuch...
--
Johan Herland, jo...@herland.net
www.herland.net
--
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 v3 07/25] reflog: avoid constructing .lock path with git_path
git_path() soon understands the path given to it. Some paths abc may
become def while other ghi may become ijk. We don't want
git_path() to interfere with .lock path construction. Concatenate
.lock after the path has been resolved by git_path() so if abc
becomes def, we'll have def.lock, not ijk.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/reflog.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/reflog.c b/builtin/reflog.c
index 852cff6..ccf2cf6 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -372,7 +372,7 @@ static int expire_reflog(const char *ref, const unsigned
char *sha1, int unused,
if (!file_exists(log_file))
goto finish;
if (!cmd-dry_run) {
- newlog_path = git_pathdup(logs/%s.lock, ref);
+ newlog_path = mkpathdup(%s.lock, log_file);
cb.newlog = fopen(newlog_path, w);
}
--
1.8.5.2.240.g8478abd
--
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 v3 04/25] path.c: group git_path(), git_pathdup() and strbuf_git_path() together
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
path.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/path.c b/path.c
index 635ec41..e088c40 100644
--- a/path.c
+++ b/path.c
@@ -78,6 +78,16 @@ void strbuf_git_path(struct strbuf *sb, const char *fmt, ...)
va_end(args);
}
+char *git_path(const char *fmt, ...)
+{
+ struct strbuf *pathname = get_pathname();
+ va_list args;
+ va_start(args, fmt);
+ do_git_path(pathname, fmt, args);
+ va_end(args);
+ return pathname-buf;
+}
+
char *git_pathdup(const char *fmt, ...)
{
struct strbuf *path = get_pathname();
@@ -109,16 +119,6 @@ char *mkpath(const char *fmt, ...)
return cleanup_path(pathname-buf);
}
-char *git_path(const char *fmt, ...)
-{
- struct strbuf *pathname = get_pathname();
- va_list args;
- va_start(args, fmt);
- do_git_path(pathname, fmt, args);
- va_end(args);
- return pathname-buf;
-}
-
void home_config_paths(char **global, char **xdg, char *file)
{
char *xdg_home = getenv(XDG_CONFIG_HOME);
--
1.8.5.2.240.g8478abd
--
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 v3 05/25] Make git_path() aware of file relocation in $GIT_DIR
We allow the user to relocate certain paths out of $GIT_DIR via
environment variables, e.g. GIT_OBJECT_DIRECTORY, GIT_INDEX_FILE and
GIT_GRAFT_FILE. All callers are not supposed to use git_path() or
git_pathdup() to get those paths. Instead they must use
get_object_directory(), get_index_file() and get_graft_file()
respectively. This is inconvenient and could be missed in review
(there's git_path(objects/info/alternates) somewhere in
sha1_file.c).
This patch makes git_path() and git_pathdup() understand those
environment variables. So if you set GIT_OBJECT_DIRECTORY to /foo/bar,
git_path(objects/abc) should return /tmp/bar/abc. The same is done
for the two remaining env variables.
git rev-parse --git-path is the wrapper for script use.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-rev-parse.txt | 5 +
builtin/rev-parse.c | 7 +++
cache.h | 1 +
environment.c | 9 ++--
path.c | 46 +
t/t0060-path-utils.sh | 19 +
6 files changed, 85 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 0d2cdcd..33e4e90 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -232,6 +232,11 @@ print a message to stderr and exit with nonzero status.
repository. If path is a gitfile then the resolved path
to the real repository is printed.
+--git-path path::
+ Resolve $GIT_DIR/path and takes other path relocation
+ variables such as $GIT_OBJECT_DIRECTORY,
+ $GIT_INDEX_FILE... into account.
+
--show-cdup::
When the command is invoked from a subdirectory, show the
path of the top-level directory relative to the current
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index aaeb611..e50bc65 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -518,6 +518,13 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
for (i = 1; i argc; i++) {
const char *arg = argv[i];
+ if (!strcmp(arg, --git-path)) {
+ if (!argv[i + 1])
+ die(--git-path requires an argument);
+ puts(git_path(%s, argv[i + 1]));
+ i++;
+ continue;
+ }
if (as_is) {
if (show_file(arg, output_prefix) as_is 2)
verify_filename(prefix, arg, 0);
diff --git a/cache.h b/cache.h
index 8d3697e..6c08e4a 100644
--- a/cache.h
+++ b/cache.h
@@ -585,6 +585,7 @@ extern int fsync_object_files;
extern int core_preload_index;
extern int core_apply_sparse_checkout;
extern int precomposed_unicode;
+extern int git_db_env, git_index_env, git_graft_env;
/*
* The character that begins a commented line in user-editable file
diff --git a/environment.c b/environment.c
index 4a3437d..f513479 100644
--- a/environment.c
+++ b/environment.c
@@ -82,6 +82,7 @@ static size_t namespace_len;
static const char *git_dir;
static char *git_object_dir, *git_index_file, *git_graft_file;
+int git_db_env, git_index_env, git_graft_env;
/*
* Repository-local GIT_* environment variables; see cache.h for details.
@@ -137,15 +138,19 @@ static void setup_git_env(void)
if (!git_object_dir) {
git_object_dir = xmalloc(strlen(git_dir) + 9);
sprintf(git_object_dir, %s/objects, git_dir);
- }
+ } else
+ git_db_env = 1;
git_index_file = getenv(INDEX_ENVIRONMENT);
if (!git_index_file) {
git_index_file = xmalloc(strlen(git_dir) + 7);
sprintf(git_index_file, %s/index, git_dir);
- }
+ } else
+ git_index_env = 1;
git_graft_file = getenv(GRAFT_ENVIRONMENT);
if (!git_graft_file)
git_graft_file = git_pathdup(info/grafts);
+ else
+ git_graft_env = 1;
if (getenv(NO_REPLACE_OBJECTS_ENVIRONMENT))
read_replace_refs = 0;
namespace = expand_namespace(getenv(GIT_NAMESPACE_ENVIRONMENT));
diff --git a/path.c b/path.c
index e088c40..0f8c3dc 100644
--- a/path.c
+++ b/path.c
@@ -60,13 +60,59 @@ char *mksnpath(char *buf, size_t n, const char *fmt, ...)
return cleanup_path(buf);
}
+static int dir_prefix(const char *buf, const char *dir)
+{
+ int len = strlen(dir);
+ return !strncmp(buf, dir, len)
+ (is_dir_sep(buf[len]) || buf[len] == '\0');
+}
+
+/* $buf =~ m|$dir/+$file| but without regex */
+static int is_dir_file(const char *buf, const char *dir, const char *file)
+{
+ int len = strlen(dir);
+ if (strncmp(buf, dir, len) || !is_dir_sep(buf[len]))
+ return 0;
+ while (is_dir_sep(buf[len]))
+ len++;
+ return
[PATCH v3 00/25] Support multiple checkouts
In short you can attach multiple worktrees to the same git repository with git checkout --to somewhere. This is basically what git-new-workdir is for. Previous discussion here http://thread.gmane.org/gmane.comp.version-control.git/239194/focus=239581 Compared to last time: - .git file format remains unchanged. It was a stupid idea to tie $GIT_COMMON_DIR pointer to .git file because you will have to pass that info another way if you don't go through .git file. Now it's stored in $GIT_DIR/commondir - Last time, checking out an already checked out branch will detach the previous checkout. Junio wanted to error out for less user confusion. I go with a (good, imo) compromise in this reroll: the new checkout detaches itself in this case, hinting where the branch is truly checked out so the user can go there and do things Nguyễn Thái Ngọc Duy (25): path.c: make get_pathname() return strbuf instead of static buffer Convert git_snpath() to strbuf_git_path() path.c: rename vsnpath() to do_git_path() path.c: group git_path(), git_pathdup() and strbuf_git_path() together Make git_path() aware of file relocation in $GIT_DIR *.sh: respect $GIT_INDEX_FILE reflog: avoid constructing .lock path with git_path fast-import: use git_path() for accessing .git dir instead of get_git_dir() commit: use SEQ_DIR instead of hardcoding sequencer Add new environment variable $GIT_COMMON_DIR git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects *.sh: avoid hardcoding $GIT_DIR/hooks/... git-stash: avoid hardcoding $GIT_DIR/logs/ setup.c: convert is_git_directory() to use strbuf setup.c: detect $GIT_COMMON_DIR in is_git_directory() setup.c: convert check_repository_format_gently to use strbuf setup.c: detect $GIT_COMMON_DIR check_repository_format_gently() setup.c: support multi-checkout repo setup wrapper.c: wrapper to open a file, fprintf then close use new wrapper write_file() for simple file writing checkout: support checking out into a new working directory checkout: clean up half-prepared directories in --to mode checkout: detach if the branch is already checked out elsewhere prune: strategies for linked checkouts gc: support prune --repos Documentation/config.txt | 9 +- Documentation/git-checkout.txt | 34 + Documentation/git-prune.txt| 3 + Documentation/git-rev-parse.txt| 8 + Documentation/git.txt | 8 + Documentation/gitrepository-layout.txt | 26 builtin/branch.c | 4 +- builtin/checkout.c | 272 +++-- builtin/commit.c | 2 +- builtin/gc.c | 17 +++ builtin/init-db.c | 7 +- builtin/prune.c| 75 + builtin/reflog.c | 2 +- builtin/rev-parse.c| 11 ++ cache.h| 10 +- daemon.c | 11 +- environment.c | 24 ++- fast-import.c | 5 +- git-am.sh | 22 +-- git-pull.sh| 2 +- git-rebase--interactive.sh | 6 +- git-rebase--merge.sh | 6 +- git-rebase.sh | 4 +- git-sh-setup.sh| 2 +- git-stash.sh | 6 +- path.c | 201 +++- refs.c | 66 +--- refs.h | 2 +- setup.c| 117 ++ strbuf.c | 8 + strbuf.h | 5 + submodule.c| 9 +- t/t0060-path-utils.sh | 34 + t/t1501-worktree.sh| 76 + t/t1510-repo-setup.sh | 1 + t/t2025-checkout-to.sh (new +x)| 48 ++ templates/hooks--applypatch-msg.sample | 4 +- templates/hooks--pre-applypatch.sample | 4 +- trace.c| 1 + transport.c| 8 +- wrapper.c | 31 41 files changed, 976 insertions(+), 215 deletions(-) create mode 100755 t/t2025-checkout-to.sh -- 1.8.5.2.240.g8478abd -- 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 v3 02/25] Convert git_snpath() to strbuf_git_path()
In the previous patch, git_snpath() is modified to take a strbuf
buffer from get_pathname() because vsnpath() needs that. But that
makes it awkward because git_snpath() receives a pre-allocated buffer
from outside and has to copy data back.
Rename it to strbuf_git_path() and make it receive strbuf directly.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/checkout.c | 22 +-
cache.h| 4 ++--
path.c | 8 +--
refs.c | 66 +++---
refs.h | 2 +-
5 files changed, 57 insertions(+), 45 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 5df3837..0570e41 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -585,18 +585,20 @@ static void update_refs_for_switch(const struct
checkout_opts *opts,
if (opts-new_orphan_branch) {
if (opts-new_branch_log !log_all_ref_updates) {
int temp;
- char log_file[PATH_MAX];
+ struct strbuf log_file = STRBUF_INIT;
char *ref_name = mkpath(refs/heads/%s,
opts-new_orphan_branch);
+ int ret;
temp = log_all_ref_updates;
log_all_ref_updates = 1;
- if (log_ref_setup(ref_name, log_file,
sizeof(log_file))) {
+ ret = log_ref_setup(ref_name, log_file);
+ log_all_ref_updates = temp;
+ strbuf_release(log_file);
+ if (ret) {
fprintf(stderr, _(Can not do reflog
for '%s'\n),
opts-new_orphan_branch);
- log_all_ref_updates = temp;
return;
}
- log_all_ref_updates = temp;
}
}
else
@@ -651,14 +653,10 @@ static void update_refs_for_switch(const struct
checkout_opts *opts,
new-name);
}
}
- if (old-path old-name) {
- char log_file[PATH_MAX], ref_file[PATH_MAX];
-
- git_snpath(log_file, sizeof(log_file), logs/%s,
old-path);
- git_snpath(ref_file, sizeof(ref_file), %s, old-path);
- if (!file_exists(ref_file) file_exists(log_file))
- remove_path(log_file);
- }
+ if (old-path old-name
+ !file_exists(git_path(%s, old-path))
+file_exists(git_path(logs/%s, old-path)))
+ remove_path(git_path(logs/%s, old-path));
}
remove_branch_state();
strbuf_release(msg);
diff --git a/cache.h b/cache.h
index dc040fb..8d3697e 100644
--- a/cache.h
+++ b/cache.h
@@ -646,8 +646,8 @@ extern int check_repository_format(void);
extern char *mksnpath(char *buf, size_t n, const char *fmt, ...)
__attribute__((format (printf, 3, 4)));
-extern char *git_snpath(char *buf, size_t n, const char *fmt, ...)
- __attribute__((format (printf, 3, 4)));
+extern void strbuf_git_path(struct strbuf *sb, const char *fmt, ...)
+ __attribute__((format (printf, 2, 3)));
extern char *git_pathdup(const char *fmt, ...)
__attribute__((format (printf, 1, 2)));
extern char *mkpathdup(const char *fmt, ...)
diff --git a/path.c b/path.c
index 1a1b784..fe3f844 100644
--- a/path.c
+++ b/path.c
@@ -70,18 +70,12 @@ static void vsnpath(struct strbuf *buf, const char *fmt,
va_list args)
strbuf_cleanup_path(buf);
}
-char *git_snpath(char *buf, size_t n, const char *fmt, ...)
+void strbuf_git_path(struct strbuf *sb, const char *fmt, ...)
{
- struct strbuf *sb = get_pathname();
va_list args;
va_start(args, fmt);
vsnpath(sb, fmt, args);
va_end(args);
- if (sb-len = n)
- strlcpy(buf, bad_path, n);
- else
- memcpy(buf, sb-buf, sb-len + 1);
- return buf;
}
char *git_pathdup(const char *fmt, ...)
diff --git a/refs.c b/refs.c
index 89228e2..434bd5e 100644
--- a/refs.c
+++ b/refs.c
@@ -1325,10 +1325,12 @@ static const char *handle_missing_loose_ref(const char
*refname,
const char *resolve_ref_unsafe(const char *refname, unsigned char *sha1, int
reading, int *flag)
{
+ struct strbuf sb_path = STRBUF_INIT;
int depth = MAXDEPTH;
ssize_t len;
char buffer[256];
static char refname_buffer[256];
+ const char *ret;
if (flag)
*flag = 0;
@@ -1337,15 +1339,17 @@ const char *resolve_ref_unsafe(const char *refname,
[PATCH v3 01/25] path.c: make get_pathname() return strbuf instead of static buffer
We've been avoiding PATH_MAX whenever possible. This patch makes
get_pathname() return a strbuf and updates the callers to take
advantage of this. The code is simplified as we no longer need to
worry about buffer overflow.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
path.c | 119 +++--
1 file changed, 50 insertions(+), 69 deletions(-)
diff --git a/path.c b/path.c
index 24594c4..1a1b784 100644
--- a/path.c
+++ b/path.c
@@ -16,11 +16,15 @@ static int get_st_mode_bits(const char *path, int *mode)
static char bad_path[] = /bad-path/;
-static char *get_pathname(void)
+static struct strbuf *get_pathname()
{
- static char pathname_array[4][PATH_MAX];
+ static struct strbuf pathname_array[4] = {
+ STRBUF_INIT, STRBUF_INIT, STRBUF_INIT, STRBUF_INIT
+ };
static int index;
- return pathname_array[3 ++index];
+ struct strbuf *sb = pathname_array[3 ++index];
+ strbuf_reset(sb);
+ return sb;
}
static char *cleanup_path(char *path)
@@ -34,6 +38,13 @@ static char *cleanup_path(char *path)
return path;
}
+static void strbuf_cleanup_path(struct strbuf *sb)
+{
+ char *path = cleanup_path(sb-buf);
+ if (path sb-buf)
+ strbuf_remove(sb, 0, path - sb-buf);
+}
+
char *mksnpath(char *buf, size_t n, const char *fmt, ...)
{
va_list args;
@@ -49,85 +60,69 @@ char *mksnpath(char *buf, size_t n, const char *fmt, ...)
return cleanup_path(buf);
}
-static char *vsnpath(char *buf, size_t n, const char *fmt, va_list args)
+static void vsnpath(struct strbuf *buf, const char *fmt, va_list args)
{
const char *git_dir = get_git_dir();
- size_t len;
-
- len = strlen(git_dir);
- if (n len + 1)
- goto bad;
- memcpy(buf, git_dir, len);
- if (len !is_dir_sep(git_dir[len-1]))
- buf[len++] = '/';
- len += vsnprintf(buf + len, n - len, fmt, args);
- if (len = n)
- goto bad;
- return cleanup_path(buf);
-bad:
- strlcpy(buf, bad_path, n);
- return buf;
+ strbuf_addstr(buf, git_dir);
+ if (buf-len !is_dir_sep(buf-buf[buf-len - 1]))
+ strbuf_addch(buf, '/');
+ strbuf_vaddf(buf, fmt, args);
+ strbuf_cleanup_path(buf);
}
char *git_snpath(char *buf, size_t n, const char *fmt, ...)
{
- char *ret;
+ struct strbuf *sb = get_pathname();
va_list args;
va_start(args, fmt);
- ret = vsnpath(buf, n, fmt, args);
+ vsnpath(sb, fmt, args);
va_end(args);
- return ret;
+ if (sb-len = n)
+ strlcpy(buf, bad_path, n);
+ else
+ memcpy(buf, sb-buf, sb-len + 1);
+ return buf;
}
char *git_pathdup(const char *fmt, ...)
{
- char path[PATH_MAX], *ret;
+ struct strbuf *path = get_pathname();
va_list args;
va_start(args, fmt);
- ret = vsnpath(path, sizeof(path), fmt, args);
+ vsnpath(path, fmt, args);
va_end(args);
- return xstrdup(ret);
+ return strbuf_detach(path, NULL);
}
char *mkpathdup(const char *fmt, ...)
{
- char *path;
struct strbuf sb = STRBUF_INIT;
va_list args;
-
va_start(args, fmt);
strbuf_vaddf(sb, fmt, args);
va_end(args);
- path = xstrdup(cleanup_path(sb.buf));
-
- strbuf_release(sb);
- return path;
+ strbuf_cleanup_path(sb);
+ return strbuf_detach(sb, NULL);
}
char *mkpath(const char *fmt, ...)
{
va_list args;
- unsigned len;
- char *pathname = get_pathname();
-
+ struct strbuf *pathname = get_pathname();
va_start(args, fmt);
- len = vsnprintf(pathname, PATH_MAX, fmt, args);
+ strbuf_vaddf(pathname, fmt, args);
va_end(args);
- if (len = PATH_MAX)
- return bad_path;
- return cleanup_path(pathname);
+ return cleanup_path(pathname-buf);
}
char *git_path(const char *fmt, ...)
{
- char *pathname = get_pathname();
+ struct strbuf *pathname = get_pathname();
va_list args;
- char *ret;
-
va_start(args, fmt);
- ret = vsnpath(pathname, PATH_MAX, fmt, args);
+ vsnpath(pathname, fmt, args);
va_end(args);
- return ret;
+ return pathname-buf;
}
void home_config_paths(char **global, char **xdg, char *file)
@@ -158,41 +153,27 @@ void home_config_paths(char **global, char **xdg, char
*file)
char *git_path_submodule(const char *path, const char *fmt, ...)
{
- char *pathname = get_pathname();
- struct strbuf buf = STRBUF_INIT;
+ struct strbuf *buf = get_pathname();
const char *git_dir;
va_list args;
- unsigned len;
-
- len = strlen(path);
- if (len PATH_MAX-100)
- return bad_path;
- strbuf_addstr(buf, path);
- if (len path[len-1] !=
[PATCH v3 03/25] path.c: rename vsnpath() to do_git_path()
The name vsnpath() gives an impression that this is general path
handling function. It's not. This is the underlying implementation of
git_path(), git_pathdup() and strbuf_git_path() which will prefix
$GIT_DIR in the result string.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
path.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/path.c b/path.c
index fe3f844..635ec41 100644
--- a/path.c
+++ b/path.c
@@ -60,7 +60,7 @@ char *mksnpath(char *buf, size_t n, const char *fmt, ...)
return cleanup_path(buf);
}
-static void vsnpath(struct strbuf *buf, const char *fmt, va_list args)
+static void do_git_path(struct strbuf *buf, const char *fmt, va_list args)
{
const char *git_dir = get_git_dir();
strbuf_addstr(buf, git_dir);
@@ -74,7 +74,7 @@ void strbuf_git_path(struct strbuf *sb, const char *fmt, ...)
{
va_list args;
va_start(args, fmt);
- vsnpath(sb, fmt, args);
+ do_git_path(sb, fmt, args);
va_end(args);
}
@@ -83,7 +83,7 @@ char *git_pathdup(const char *fmt, ...)
struct strbuf *path = get_pathname();
va_list args;
va_start(args, fmt);
- vsnpath(path, fmt, args);
+ do_git_path(path, fmt, args);
va_end(args);
return strbuf_detach(path, NULL);
}
@@ -114,7 +114,7 @@ char *git_path(const char *fmt, ...)
struct strbuf *pathname = get_pathname();
va_list args;
va_start(args, fmt);
- vsnpath(pathname, fmt, args);
+ do_git_path(pathname, fmt, args);
va_end(args);
return pathname-buf;
}
--
1.8.5.2.240.g8478abd
--
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 v3 18/25] setup.c: support multi-checkout repo setup
The repo setup procedure is updated to detect $GIT_DIR/commondir and
set $GIT_COMMON_DIR properly.
The core.worktree is ignored when $GIT_DIR/commondir presents. This is
because commondir repos are intended for separate/linked checkouts
and pointing them back to a fixed core.worktree just does not make
sense.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/config.txt| 3 +-
Documentation/git-rev-parse.txt | 3 ++
builtin/rev-parse.c | 4 +++
cache.h | 1 +
environment.c | 8 ++---
setup.c | 33 +-
t/t1501-worktree.sh | 76 +
t/t1510-repo-setup.sh | 1 +
trace.c | 1 +
9 files changed, 115 insertions(+), 15 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5f4d793..cbf4d97 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -381,7 +381,8 @@ false), while all other repositories are assumed to be bare
(bare
core.worktree::
Set the path to the root of the working tree.
- This can be overridden by the GIT_WORK_TREE environment
+ This can be overridden by the GIT_WORK_TREE
+ or GIT_COMMON_DIR environment
variable and the '--work-tree' command line option.
The value can be an absolute path or relative to the path to
the .git directory, which is either specified by --git-dir
diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 33e4e90..8e6ad32 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -215,6 +215,9 @@ If `$GIT_DIR` is not defined and the current directory
is not detected to lie in a Git repository or work tree
print a message to stderr and exit with nonzero status.
+--git-common-dir::
+ Show `$GIT_COMMON_DIR` if defined, else `$GIT_DIR`.
+
--is-inside-git-dir::
When the current working directory is below the repository
directory print true, otherwise false.
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index e50bc65..c7057ce 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -744,6 +744,10 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
printf(%s%s.git\n, cwd, len cwd[len-1] !=
'/' ? / : );
continue;
}
+ if (!strcmp(arg, --git-common-dir)) {
+ puts(get_git_common_dir());
+ continue;
+ }
if (!strcmp(arg, --resolve-git-dir)) {
const char *gitdir = resolve_gitdir(argv[i+1]);
if (!gitdir)
diff --git a/cache.h b/cache.h
index 51ade32..98b5dd3 100644
--- a/cache.h
+++ b/cache.h
@@ -407,6 +407,7 @@ extern char *get_object_directory(void);
extern char *get_index_file(void);
extern char *get_graft_file(void);
extern int set_git_dir(const char *path);
+extern int get_common_dir(struct strbuf *sb, const char *gitdir);
extern const char *get_git_namespace(void);
extern const char *strip_namespace(const char *namespaced_ref);
extern const char *get_git_work_tree(void);
diff --git a/environment.c b/environment.c
index c998120..0999fc1 100644
--- a/environment.c
+++ b/environment.c
@@ -126,6 +126,7 @@ static char *expand_namespace(const char *raw_namespace)
static void setup_git_env(void)
{
+ struct strbuf sb = STRBUF_INIT;
const char *gitfile;
const char *shallow_file;
@@ -134,12 +135,9 @@ static void setup_git_env(void)
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
gitfile = read_gitfile(git_dir);
git_dir = xstrdup(gitfile ? gitfile : git_dir);
- git_common_dir = getenv(GIT_COMMON_DIR_ENVIRONMENT);
- if (git_common_dir) {
+ if (get_common_dir(sb, git_dir))
git_common_dir_env = 1;
- git_common_dir = xstrdup(git_common_dir);
- } else
- git_common_dir = git_dir;
+ git_common_dir = strbuf_detach(sb, NULL);
git_object_dir = getenv(DB_ENVIRONMENT);
if (!git_object_dir) {
git_object_dir = xmalloc(strlen(git_common_dir) + 9);
diff --git a/setup.c b/setup.c
index e56ec11..d4ac878 100644
--- a/setup.c
+++ b/setup.c
@@ -170,14 +170,15 @@ void verify_non_filename(const char *prefix, const char
*arg)
'git command [revision...] -- [file...]', arg);
}
-static void get_common_dir(struct strbuf *sb, const char *gitdir)
+int get_common_dir(struct strbuf *sb, const char *gitdir)
{
struct strbuf data = STRBUF_INIT;
struct strbuf path = STRBUF_INIT;
const char *git_common_dir = getenv(GIT_COMMON_DIR_ENVIRONMENT);
+ int ret = 0;
if (git_common_dir) {
strbuf_addstr(sb,
[PATCH v3 08/25] fast-import: use git_path() for accessing .git dir instead of get_git_dir()
This allows git_path() to redirect info/fast-import to another place
if needed
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
fast-import.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 4fd18a3..08a1e78 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -3125,12 +3125,9 @@ static void parse_progress(void)
static char* make_fast_import_path(const char *path)
{
- struct strbuf abs_path = STRBUF_INIT;
-
if (!relative_marks_paths || is_absolute_path(path))
return xstrdup(path);
- strbuf_addf(abs_path, %s/info/fast-import/%s, get_git_dir(), path);
- return strbuf_detach(abs_path, NULL);
+ return xstrdup(git_path(info/fast-import/%s, path));
}
static void option_import_marks(const char *marks,
--
1.8.5.2.240.g8478abd
--
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 v3 14/25] setup.c: convert is_git_directory() to use strbuf
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
setup.c | 35 +++
strbuf.h | 4
2 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/setup.c b/setup.c
index 6c3f85f..999225b 100644
--- a/setup.c
+++ b/setup.c
@@ -184,31 +184,34 @@ void verify_non_filename(const char *prefix, const char
*arg)
*/
int is_git_directory(const char *suspect)
{
- char path[PATH_MAX];
- size_t len = strlen(suspect);
+ struct strbuf path = STRBUF_INIT;
+ int ret = 0;
+ size_t len;
- if (PATH_MAX = len + strlen(/objects))
- die(Too long path: %.*s, 60, suspect);
- strcpy(path, suspect);
+ strbuf_addstr(path, suspect);
+ len = path.len;
if (getenv(DB_ENVIRONMENT)) {
if (access(getenv(DB_ENVIRONMENT), X_OK))
- return 0;
+ goto done;
}
else {
- strcpy(path + len, /objects);
- if (access(path, X_OK))
- return 0;
+ strbuf_addstr(path, /objects);
+ if (access(path.buf, X_OK))
+ goto done;
}
- strcpy(path + len, /refs);
- if (access(path, X_OK))
- return 0;
+ strbuf_addstr_at(path, len, /refs);
+ if (access(path.buf, X_OK))
+ goto done;
- strcpy(path + len, /HEAD);
- if (validate_headref(path))
- return 0;
+ strbuf_addstr_at(path, len, /HEAD);
+ if (validate_headref(path.buf))
+ goto done;
- return 1;
+ ret = 1;
+done:
+ strbuf_release(path);
+ return ret;
}
int is_inside_git_dir(void)
diff --git a/strbuf.h b/strbuf.h
index 73e80ce..aec9fdb 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -116,6 +116,10 @@ extern void strbuf_add(struct strbuf *, const void *,
size_t);
static inline void strbuf_addstr(struct strbuf *sb, const char *s) {
strbuf_add(sb, s, strlen(s));
}
+static inline void strbuf_addstr_at(struct strbuf *sb, size_t len, const char
*s) {
+ strbuf_setlen(sb, len);
+ strbuf_add(sb, s, strlen(s));
+}
static inline void strbuf_addbuf(struct strbuf *sb, const struct strbuf *sb2) {
strbuf_grow(sb, sb2-len);
strbuf_add(sb, sb2-buf, sb2-len);
--
1.8.5.2.240.g8478abd
--
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 v3 20/25] use new wrapper write_file() for simple file writing
This fixes common problems in these code about error handling,
forgetting to close the file handle after fprintf() fails, or not
printing out the error string..
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/branch.c | 4 +---
builtin/init-db.c | 7 +--
daemon.c | 11 +--
submodule.c | 9 ++---
transport.c | 8 +++-
5 files changed, 8 insertions(+), 31 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index b4d7716..3eebdbc 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -754,7 +754,6 @@ static const char edit_description[] = BRANCH_DESCRIPTION;
static int edit_branch_description(const char *branch_name)
{
- FILE *fp;
int status;
struct strbuf buf = STRBUF_INIT;
struct strbuf name = STRBUF_INIT;
@@ -767,8 +766,7 @@ static int edit_branch_description(const char *branch_name)
%s\n
Lines starting with '%c' will be stripped.\n,
branch_name, comment_line_char);
- fp = fopen(git_path(edit_description), w);
- if ((fwrite(buf.buf, 1, buf.len, fp) buf.len) || fclose(fp)) {
+ if (write_file(git_path(edit_description), 0, %s, buf.buf)) {
strbuf_release(buf);
return error(_(could not write branch description template:
%s),
strerror(errno));
diff --git a/builtin/init-db.c b/builtin/init-db.c
index c7c76bb..081e512 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -342,7 +342,6 @@ int set_git_dir_init(const char *git_dir, const char
*real_git_dir,
static void separate_git_dir(const char *git_dir)
{
struct stat st;
- FILE *fp;
if (!stat(git_link, st)) {
const char *src;
@@ -358,11 +357,7 @@ static void separate_git_dir(const char *git_dir)
die_errno(_(unable to move %s to %s), src, git_dir);
}
- fp = fopen(git_link, w);
- if (!fp)
- die(_(Could not create git link %s), git_link);
- fprintf(fp, gitdir: %s\n, git_dir);
- fclose(fp);
+ write_file(git_link, 1, gitdir: %s\n, git_dir);
}
int init_db(const char *template_dir, unsigned int flags)
diff --git a/daemon.c b/daemon.c
index 503e039..b880d30 100644
--- a/daemon.c
+++ b/daemon.c
@@ -1122,15 +1122,6 @@ static void daemonize(void)
}
#endif
-static void store_pid(const char *path)
-{
- FILE *f = fopen(path, w);
- if (!f)
- die_errno(cannot open pid file '%s', path);
- if (fprintf(f, %PRIuMAX\n, (uintmax_t) getpid()) 0 || fclose(f)
!= 0)
- die_errno(failed to write pid file '%s', path);
-}
-
static int serve(struct string_list *listen_addr, int listen_port,
struct credentials *cred)
{
@@ -1339,7 +1330,7 @@ int main(int argc, char **argv)
sanitize_stdfds();
if (pid_file)
- store_pid(pid_file);
+ write_file(pid_file, 1, %PRIuMAX\n, (uintmax_t) getpid());
/* prepare argv for serving-processes */
cld_argv = xmalloc(sizeof (char *) * (argc + 2));
diff --git a/submodule.c b/submodule.c
index 613857e..fe5748d 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1135,16 +1135,11 @@ void connect_work_tree_and_git_dir(const char
*work_tree, const char *git_dir)
struct strbuf file_name = STRBUF_INIT;
struct strbuf rel_path = STRBUF_INIT;
const char *real_work_tree = xstrdup(real_path(work_tree));
- FILE *fp;
/* Update gitfile */
strbuf_addf(file_name, %s/.git, work_tree);
- fp = fopen(file_name.buf, w);
- if (!fp)
- die(_(Could not create git link %s), file_name.buf);
- fprintf(fp, gitdir: %s\n, relative_path(git_dir, real_work_tree,
- rel_path));
- fclose(fp);
+ write_file(file_name.buf, 1, gitdir: %s\n,
+ relative_path(git_dir, real_work_tree, rel_path));
/* Update core.worktree setting */
strbuf_reset(file_name);
diff --git a/transport.c b/transport.c
index ca7bb44..2df8a15 100644
--- a/transport.c
+++ b/transport.c
@@ -294,7 +294,6 @@ static int write_one_ref(const char *name, const unsigned
char *sha1,
{
struct strbuf *buf = data;
int len = buf-len;
- FILE *f;
/* when called via for_each_ref(), flags is non-zero */
if (flags !starts_with(name, refs/heads/)
@@ -303,10 +302,9 @@ static int write_one_ref(const char *name, const unsigned
char *sha1,
strbuf_addstr(buf, name);
if (safe_create_leading_directories(buf-buf) ||
- !(f = fopen(buf-buf, w)) ||
- fprintf(f, %s\n, sha1_to_hex(sha1)) 0 ||
- fclose(f))
- return error(problems writing temporary file %s, buf-buf);
+ write_file(buf-buf, 0, %s\n, sha1_to_hex(sha1)))
+ return
[PATCH v3 25/25] gc: support prune --repos
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/config.txt | 6 ++
builtin/gc.c | 17 +
2 files changed, 23 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index cbf4d97..eec2d05 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1182,6 +1182,12 @@ gc.pruneexpire::
now may be used to disable this grace period and always prune
unreachable objects immediately.
+gc.prunereposexpire::
+ When 'git gc' is run, it will call 'prune --repos --expire
3.months.ago'.
+ Override the grace period with this config variable. The value
+ now may be used to disable this grace period and always prune
+ $GIT_DIR/repos immediately.
+
gc.reflogexpire::
gc.pattern.reflogexpire::
'git reflog expire' removes reflog entries older than
diff --git a/builtin/gc.c b/builtin/gc.c
index c19545d..fbeba86 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -30,11 +30,13 @@ static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
static const char *prune_expire = 2.weeks.ago;
+static const char *prune_repos_expire = 3.months.ago;
static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
static struct argv_array reflog = ARGV_ARRAY_INIT;
static struct argv_array repack = ARGV_ARRAY_INIT;
static struct argv_array prune = ARGV_ARRAY_INIT;
+static struct argv_array prune_repos = ARGV_ARRAY_INIT;
static struct argv_array rerere = ARGV_ARRAY_INIT;
static char *pidfile;
@@ -81,6 +83,14 @@ static int gc_config(const char *var, const char *value,
void *cb)
}
return git_config_string(prune_expire, var, value);
}
+ if (!strcmp(var, gc.prunereposexpire)) {
+ if (value strcmp(value, now)) {
+ unsigned long now = approxidate(now);
+ if (approxidate(value) = now)
+ return error(_(Invalid %s: '%s'), var, value);
+ }
+ return git_config_string(prune_repos_expire, var, value);
+ }
return git_default_config(var, value, cb);
}
@@ -274,6 +284,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
argv_array_pushl(reflog, reflog, expire, --all, NULL);
argv_array_pushl(repack, repack, -d, -l, NULL);
argv_array_pushl(prune, prune, --expire, NULL );
+ argv_array_pushl(prune_repos, prune, --repos, --expire, NULL );
argv_array_pushl(rerere, rerere, gc, NULL);
git_config(gc_config, NULL);
@@ -334,6 +345,12 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
return error(FAILED_RUN, prune.argv[0]);
}
+ if (prune_repos_expire) {
+ argv_array_push(prune_repos, prune_repos_expire);
+ if (run_command_v_opt(prune_repos.argv, RUN_GIT_CMD))
+ return error(FAILED_RUN, prune_repos.argv[0]);
+ }
+
if (run_command_v_opt(rerere.argv, RUN_GIT_CMD))
return error(FAILED_RUN, rerere.argv[0]);
--
1.8.5.2.240.g8478abd
--
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 v3 24/25] prune: strategies for linked checkouts
alias REPO=$GIT_COMMON_DIR/repos/id
- linked checkouts are supposed to update mtime of $REPO/gitdir
- linked checkouts are supposed to keep its location in $REPO/gitdir up to
date
- git checkout --to is supposed to create $REPO/locked if the new
repo is on a different partition than the shared one.
- git checkout --to is supposed to make hardlink named $REPO/link
pointing to the .git file
The pruning rules are:
- if $REPO/locked exists, repos/id is not supposed to be pruned.
- if $REPO/locked exists and $REPO/gitdir's mtimer is older than a
really long limit, warn about old unused repo.
- if $REPO/link exists and its link count is greated than 1, the repo
is kept.
- if $REPO/gitdir's mtime is older than a limit, and it points to
nowhere, repos/id is to be pruned.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-prune.txt| 3 ++
Documentation/gitrepository-layout.txt | 19 +
builtin/checkout.c | 36 +++-
builtin/prune.c| 75 ++
setup.c| 13 ++
5 files changed, 145 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-prune.txt b/Documentation/git-prune.txt
index 058ac0d..7babf11 100644
--- a/Documentation/git-prune.txt
+++ b/Documentation/git-prune.txt
@@ -48,6 +48,9 @@ OPTIONS
--expire time::
Only expire loose objects older than time.
+--repos::
+ Prune directories in $GIT_DIR/repos.
+
head...::
In addition to objects
reachable from any of our references, keep objects
diff --git a/Documentation/gitrepository-layout.txt
b/Documentation/gitrepository-layout.txt
index 495a937..784d0a5 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -221,6 +221,25 @@ modules::
repos::
Contains worktree specific information of linked checkouts.
+repos/id/gitdir::
+ A text file containing the absolute path back to the .git file
+ that points to here. This is used to check if the linked
+ repository has been manually removed and there is no need to
+ keep this directory any more. mtime of this file should be
+ updated every time the linked repository is accessed.
+
+repos/id/locked::
+ If this file exists, the linked repository may be on a
+ portable device and not available. It does not mean that the
+ linked repository is gone and `repos/id` could be
+ removed. The file's content contains a reason string on why
+ the repository is locked.
+
+repos/id/link::
+ If this file exists, it is a hard link to the linked .git
+ file. It is used to detect if the linked repository is
+ manually removed.
+
SEE ALSO
linkgit:git-init[1],
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 7b86f2b..c501e9c 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -854,6 +854,17 @@ static void remove_junk_on_signal(int signo)
raise(signo);
}
+static dev_t get_device_or_die(const char *path)
+{
+ struct stat buf;
+ if (stat(path, buf))
+ die_errno(failed to stat '%s', path);
+ /* Ah Windows! Make different drives different partitions */
+ if (buf.st_dev == 0 has_dos_drive_prefix(c:\\))
+ buf.st_dev = toupper(real_path(path)[0]);
+ return buf.st_dev;
+}
+
static int prepare_linked_checkout(const struct checkout_opts *opts,
struct branch_info *new)
{
@@ -863,7 +874,7 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
struct stat st;
const char *name;
struct child_process cp;
- int counter = 0, len, ret;
+ int counter = 0, len, keep_locked = 0, ret;
if (!new-commit)
die(_(no branch specified));
@@ -898,12 +909,18 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
junk_git_dir = sb_repo.buf;
is_junk = 1;
+ strbuf_addf(sb, %s/locked, sb_repo.buf);
+ write_file(sb.buf, 1, initializing\n);
+
strbuf_addf(sb_git, %s/.git, path);
if (safe_create_leading_directories_const(sb_git.buf))
die_errno(_(could not create leading directories of '%s'),
sb_git.buf);
junk_work_tree = path;
+ strbuf_reset(sb);
+ strbuf_addf(sb, %s/gitdir, sb_repo.buf);
+ write_file(sb.buf, 1, %s\n, real_path(sb_git.buf));
write_file(sb_git.buf, 1, gitdir: %s/repos/%s\n,
real_path(get_git_dir()), name);
/*
@@ -912,12 +929,24 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
* value would do because this value will be ignored and
* replaced at the next (real) checkout.
*/
+ strbuf_reset(sb);
strbuf_addf(sb, %s/HEAD, sb_repo.buf);
write_file(sb.buf, 1,
[PATCH v3 09/25] commit: use SEQ_DIR instead of hardcoding sequencer
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/commit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 3767478..ee3ac10 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -155,7 +155,7 @@ static void determine_whence(struct wt_status *s)
whence = FROM_MERGE;
else if (file_exists(git_path(CHERRY_PICK_HEAD))) {
whence = FROM_CHERRY_PICK;
- if (file_exists(git_path(sequencer)))
+ if (file_exists(git_path(SEQ_DIR)))
sequencer_in_use = 1;
}
else
--
1.8.5.2.240.g8478abd
--
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 v3 23/25] checkout: detach if the branch is already checked out elsewhere
The normal rule is anything outside refs/heads/ is detached. This
strictens the rule a bit more: if the branch is checked out (either in
$GIT_COMMON_DIR/HEAD or any $GIT_DIR/repos/.../HEAD) then it's
detached as well.
A hint is given so the user knows where to go and do something there
if they still want to checkout undetached here.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/checkout.c | 78 ++
t/t2025-checkout-to.sh | 15 --
2 files changed, 90 insertions(+), 3 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index f961604..7b86f2b 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -433,6 +433,11 @@ struct branch_info {
const char *name; /* The short name used */
const char *path; /* The full name of a real branch */
struct commit *commit; /* The named commit */
+ /*
+* if not null the branch is detached because it's alrady
+* checked out in this checkout
+*/
+ char *checkout;
};
static void setup_branch_path(struct branch_info *branch)
@@ -640,6 +645,11 @@ static void update_refs_for_switch(const struct
checkout_opts *opts,
if (old-path advice_detached_head)
detach_advice(new-name);
describe_detached_head(_(HEAD is now at),
new-commit);
+ if (new-checkout !*new-checkout)
+ fprintf(stderr, _(hint: the main checkout is
holding this branch\n));
+ else if (new-checkout)
+ fprintf(stderr, _(hint: the linked checkout %s
is holding this branch\n),
+ new-checkout);
}
} else if (new-path) { /* Switch branches. */
create_symref(HEAD, new-path, msg.buf);
@@ -982,6 +992,71 @@ static const char *unique_tracking_name(const char *name,
unsigned char *sha1)
return NULL;
}
+static int check_linked_checkout(struct branch_info *new,
+ const char *name, const char *path)
+{
+ struct strbuf sb = STRBUF_INIT;
+ char *start, *end;
+ if (strbuf_read_file(sb, path, 0) 0)
+ return 0;
+ if (!starts_with(sb.buf, ref:)) {
+ strbuf_release(sb);
+ return 0;
+ }
+
+ start = sb.buf + 4;
+ while (isspace(*start))
+ start++;
+ end = start;
+ while (*end !isspace(*end))
+ end++;
+ if (!strncmp(start, new-path, end - start)
+ new-path[end - start] == '\0') {
+ strbuf_release(sb);
+ new-path = NULL; /* detach */
+ new-checkout = xstrdup(name); /* reason */
+ return 1;
+ }
+ strbuf_release(sb);
+ return 0;
+}
+
+static void check_linked_checkouts(struct branch_info *new)
+{
+ struct strbuf path = STRBUF_INIT;
+ DIR *dir;
+ struct dirent *d;
+
+ strbuf_addf(path, %s/repos, get_git_common_dir());
+ if ((dir = opendir(path.buf)) == NULL)
+ return;
+
+ strbuf_reset(path);
+ strbuf_addf(path, %s/HEAD, get_git_common_dir());
+ /*
+* $GIT_COMMON_DIR/HEAD is practically outside
+* $GIT_DIR so resolve_ref_unsafe() won't work (it
+* uses git_path). Parse the ref ourselves.
+*/
+ if (check_linked_checkout(new, , path.buf)) {
+ strbuf_release(path);
+ closedir(dir);
+ return;
+ }
+
+ while ((d = readdir(dir)) != NULL) {
+ if (!strcmp(d-d_name, .) || !strcmp(d-d_name, ..))
+ continue;
+ strbuf_reset(path);
+ strbuf_addf(path, %s/repos/%s/HEAD,
+ get_git_common_dir(), d-d_name);
+ if (check_linked_checkout(new, d-d_name, path.buf))
+ break;
+ }
+ strbuf_release(path);
+ closedir(dir);
+}
+
static int parse_branchname_arg(int argc, const char **argv,
int dwim_new_local_branch_ok,
struct branch_info *new,
@@ -1109,6 +1184,9 @@ static int parse_branchname_arg(int argc, const char
**argv,
else
new-path = NULL; /* not an existing branch */
+ if (new-path)
+ check_linked_checkouts(new);
+
new-commit = lookup_commit_reference_gently(rev, 1);
if (!new-commit) {
/* not a commit */
diff --git a/t/t2025-checkout-to.sh b/t/t2025-checkout-to.sh
index 76eae4a..f6a5c47 100755
--- a/t/t2025-checkout-to.sh
+++ b/t/t2025-checkout-to.sh
@@ -13,13 +13,14 @@ test_expect_success 'checkout --to not updating paths' '
'
test_expect_success 'checkout --to a new worktree' '
+ git rev-parse HEAD expect
git checkout --to here master
[PATCH v3 11/25] git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects
If $GIT_COMMON_DIR is set, $GIT_OBJECT_DIRECTORY should be
$GIT_COMMON_DIR/objects, not $GIT_DIR/objects. Just let rev-parse
--git-path handle it.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
git-sh-setup.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index fffa3c7..fec9430 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -343,7 +343,7 @@ then
echo 2 Unable to determine absolute path of git directory
exit 1
}
- : ${GIT_OBJECT_DIRECTORY=$GIT_DIR/objects}
+ : ${GIT_OBJECT_DIRECTORY=`git rev-parse --git-path objects`}
fi
peel_committish () {
--
1.8.5.2.240.g8478abd
--
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 v3 06/25] *.sh: respect $GIT_INDEX_FILE
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
git-pull.sh | 2 +-
git-stash.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 0a5aa2c..c9dc9ba 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -218,7 +218,7 @@ test true = $rebase {
if ! git rev-parse -q --verify HEAD /dev/null
then
# On an unborn branch
- if test -f $GIT_DIR/index
+ if test -f `git rev-parse --git-path index`
then
die $(gettext updating an unborn branch with changes
added to the index)
fi
diff --git a/git-stash.sh b/git-stash.sh
index f0a94ab..ae7d16e 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -20,7 +20,7 @@ require_work_tree
cd_to_toplevel
TMP=$GIT_DIR/.git-stash.$$
-TMPindex=${GIT_INDEX_FILE-$GIT_DIR/index}.stash.$$
+TMPindex=${GIT_INDEX_FILE-`git rev-parse --git-path index`}.stash.$$
trap 'rm -f $TMP-* $TMPindex' 0
ref_stash=refs/stash
--
1.8.5.2.240.g8478abd
--
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 v3 15/25] setup.c: detect $GIT_COMMON_DIR in is_git_directory()
If the file $GIT_DIR/commondir exists, it contains the value of
$GIT_COMMON_DIR.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitrepository-layout.txt | 4
setup.c| 38 --
strbuf.c | 8 +++
strbuf.h | 1 +
4 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/Documentation/gitrepository-layout.txt
b/Documentation/gitrepository-layout.txt
index aa03882..9bfe0f1 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -211,6 +211,10 @@ shallow::
and maintained by shallow clone mechanism. See `--depth`
option to linkgit:git-clone[1] and linkgit:git-fetch[1].
+commondir::
+ If this file exists, $GIT_COMMON_DIR will be set to the path
+ specified in this file if it is not set.
+
modules::
Contains the git-repositories of the submodules.
diff --git a/setup.c b/setup.c
index 999225b..4e5711c 100644
--- a/setup.c
+++ b/setup.c
@@ -170,6 +170,30 @@ void verify_non_filename(const char *prefix, const char
*arg)
'git command [revision...] -- [file...]', arg);
}
+static void get_common_dir(struct strbuf *sb, const char *gitdir)
+{
+ struct strbuf data = STRBUF_INIT;
+ struct strbuf path = STRBUF_INIT;
+ const char *git_common_dir = getenv(GIT_COMMON_DIR_ENVIRONMENT);
+ if (git_common_dir) {
+ strbuf_addstr(sb, git_common_dir);
+ return;
+ }
+ strbuf_addf(path, %s/commondir, gitdir);
+ if (file_exists(path.buf)) {
+ if (strbuf_read_file(data, path.buf, 0) = 0)
+ die_errno(_(failed to read %s), path.buf);
+ strbuf_chomp(data);
+ strbuf_reset(path);
+ if (!is_absolute_path(data.buf))
+ strbuf_addf(path, %s/, gitdir);
+ strbuf_addbuf(path, data);
+ strbuf_addstr(sb, real_path(path.buf));
+ } else
+ strbuf_addstr(sb, gitdir);
+ strbuf_release(data);
+ strbuf_release(path);
+}
/*
* Test if it looks like we're at a git directory.
@@ -188,14 +212,20 @@ int is_git_directory(const char *suspect)
int ret = 0;
size_t len;
- strbuf_addstr(path, suspect);
+ strbuf_addf(path, %s/HEAD, suspect);
+ if (validate_headref(path.buf))
+ goto done;
+
+ strbuf_reset(path);
+ get_common_dir(path, suspect);
len = path.len;
+
if (getenv(DB_ENVIRONMENT)) {
if (access(getenv(DB_ENVIRONMENT), X_OK))
goto done;
}
else {
- strbuf_addstr(path, /objects);
+ strbuf_addstr_at(path, len, /objects);
if (access(path.buf, X_OK))
goto done;
}
@@ -204,10 +234,6 @@ int is_git_directory(const char *suspect)
if (access(path.buf, X_OK))
goto done;
- strbuf_addstr_at(path, len, /HEAD);
- if (validate_headref(path.buf))
- goto done;
-
ret = 1;
done:
strbuf_release(path);
diff --git a/strbuf.c b/strbuf.c
index 83caf4a..e17c358 100644
--- a/strbuf.c
+++ b/strbuf.c
@@ -588,3 +588,11 @@ int fprintf_ln(FILE *fp, const char *fmt, ...)
return -1;
return ret + 1;
}
+
+void strbuf_chomp(struct strbuf *sb)
+{
+ while (sb-len (sb-buf[sb-len - 1] == '\n' ||
+ sb-buf[sb-len - 1] == '\r'))
+ sb-len--;
+ sb-buf[sb-len] = '\0';
+}
diff --git a/strbuf.h b/strbuf.h
index aec9fdb..cd9578f 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -109,6 +109,7 @@ extern void strbuf_remove(struct strbuf *, size_t pos,
size_t len);
/* splice pos..pos+len with given data */
extern void strbuf_splice(struct strbuf *, size_t pos, size_t len,
const void *, size_t);
+extern void strbuf_chomp(struct strbuf *sb);
extern void strbuf_add_commented_lines(struct strbuf *out, const char *buf,
size_t size);
--
1.8.5.2.240.g8478abd
--
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 v3 13/25] git-stash: avoid hardcoding $GIT_DIR/logs/....
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
git-stash.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index ae7d16e..12d9b37 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -183,7 +183,7 @@ store_stash () {
fi
# Make sure the reflog for stash is kept.
- : $GIT_DIR/logs/$ref_stash
+ : `git rev-parse --git-path logs/$ref_stash`
git update-ref -m $stash_msg $ref_stash $w_commit
ret=$?
test $ret != 0 test -z $quiet
@@ -258,7 +258,7 @@ save_stash () {
say $(gettext No local changes to save)
exit 0
fi
- test -f $GIT_DIR/logs/$ref_stash ||
+ test -f `git rev-parse --git-path logs/$ref_stash` ||
clear_stash || die $(gettext Cannot initialize stash)
create_stash $stash_msg $untracked
--
1.8.5.2.240.g8478abd
--
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 v3 10/25] Add new environment variable $GIT_COMMON_DIR
This variable is intended to support multiple working directories attached to a repository. Such a repository may have a main working directory, created by either git init or git clone and one or more linked working directories. These working directories and the main repository share the same repository directory. In linked working directories, $GIT_COMMON_DIR must be defined to point to the real repository directory and $GIT_DIR points to an unused subdirectory inside $GIT_COMMON_DIR. File locations inside the repository are reorganized from the linked worktree view point: - worktree-specific such as HEAD, logs/HEAD, index, other top-level refs and unrecognized files are from $GIT_DIR. - the rest like objects, refs, info, hooks, packed-refs, shallow... are from $GIT_COMMON_DIR Scripts are supposed to retrieve paths in $GIT_DIR with git rev-parse --git-path, which will take care of $GIT_DIR vs $GIT_COMMON_DIR business. Note that logs/refs/.tmp-renamed-log is used to prepare new reflog entry and it's supposed to be on the same filesystem as the target reflog file. This is not guaranteed true for logs/HEAD when it's mapped to repos/xx/logs/HEAD because the user can put repos directory on different filesystem. Don't mess with .git unless you know what you're doing. The redirection is done by git_path(), git_pathdup() and strbuf_git_path(). The selected list of paths goes to $GIT_COMMON_DIR, not the other way around in case a developer adds a new worktree-specific file and it's accidentally promoted to be shared across repositories (this includes unknown files added by third party commands) The list of known files that belong to $GIT_DIR are: ADD_EDIT.patch BISECT_ANCESTORS_OK BISECT_EXPECTED_REV BISECT_LOG BISECT_NAMES CHERRY_PICK_HEAD COMMIT_MSG FETCH_HEAD HEAD MERGE_HEAD MERGE_MODE MERGE_RR NOTES_EDITMSG NOTES_MERGE_WORKTREE ORIG_HEAD REVERT_HEAD SQUASH_MSG TAG_EDITMSG fast_import_crash_* logs/HEAD next-index-* rebase-apply rebase-merge rsync-refs-* sequencer/* shallow_* Path mapping is NOT done for git_path_submodule(). Multi-checkouts are not supported as submodules. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/git.txt | 8 cache.h | 4 +++- environment.c | 19 +++ path.c| 28 t/t0060-path-utils.sh | 15 +++ 5 files changed, 69 insertions(+), 5 deletions(-) diff --git a/Documentation/git.txt b/Documentation/git.txt index 02bbc08..2c4a055 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -773,6 +773,14 @@ Git so take care if using Cogito etc. an explicit repository directory set via 'GIT_DIR' or on the command line. +'GIT_COMMON_DIR':: + If this variable is set to a path, non-worktree files that are + normally in $GIT_DIR will be taken from this path + instead. Worktree-specific files such as HEAD or index are + taken from $GIT_DIR. This variable has lower precedence than + other path variables such as GIT_INDEX_FILE, + GIT_OBJECT_DIRECTORY... + Git Commits ~~~ 'GIT_AUTHOR_NAME':: diff --git a/cache.h b/cache.h index 6c08e4a..51ade32 100644 --- a/cache.h +++ b/cache.h @@ -347,6 +347,7 @@ static inline enum object_type object_type(unsigned int mode) /* Double-check local_repo_env below if you add to this list. */ #define GIT_DIR_ENVIRONMENT GIT_DIR +#define GIT_COMMON_DIR_ENVIRONMENT GIT_COMMON_DIR #define GIT_NAMESPACE_ENVIRONMENT GIT_NAMESPACE #define GIT_WORK_TREE_ENVIRONMENT GIT_WORK_TREE #define GIT_PREFIX_ENVIRONMENT GIT_PREFIX @@ -400,6 +401,7 @@ extern int is_inside_git_dir(void); extern char *git_work_tree_cfg; extern int is_inside_work_tree(void); extern const char *get_git_dir(void); +extern const char *get_git_common_dir(void); extern int is_git_directory(const char *path); extern char *get_object_directory(void); extern char *get_index_file(void); @@ -585,7 +587,7 @@ extern int fsync_object_files; extern int core_preload_index; extern int core_apply_sparse_checkout; extern int precomposed_unicode; -extern int git_db_env, git_index_env, git_graft_env; +extern int git_db_env, git_index_env, git_graft_env, git_common_dir_env; /* * The character that begins a commented line in user-editable file diff --git a/environment.c b/environment.c index f513479..c998120 100644 --- a/environment.c +++ b/environment.c @@ -80,9 +80,9 @@ static char *work_tree; static const char *namespace; static size_t namespace_len; -static const char *git_dir; +static const char *git_dir, *git_common_dir; static char *git_object_dir, *git_index_file, *git_graft_file; -int git_db_env, git_index_env, git_graft_env; +int git_db_env, git_index_env, git_graft_env, git_common_dir_env; /* * Repository-local GIT_* environment variables; see cache.h for details. @@ -134,10 +134,16 @@ static void setup_git_env(void) git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
[PATCH v3 22/25] checkout: clean up half-prepared directories in --to mode
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/checkout.c | 49 +++--
1 file changed, 47 insertions(+), 2 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 2b856a6..f961604 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -20,6 +20,7 @@
#include resolve-undo.h
#include submodule.h
#include argv-array.h
+#include sigchain.h
static const char * const checkout_usage[] = {
N_(git checkout [options] branch),
@@ -814,6 +815,35 @@ static int switch_branches(const struct checkout_opts
*opts,
return ret || writeout_error;
}
+static const char *junk_work_tree;
+static const char *junk_git_dir;
+static int is_junk;
+static pid_t junk_pid;
+
+static void remove_junk(void)
+{
+ struct strbuf sb = STRBUF_INIT;
+ if (!is_junk || getpid() != junk_pid)
+ return;
+ if (junk_git_dir) {
+ strbuf_addstr(sb, junk_git_dir);
+ remove_dir_recursively(sb, 0);
+ strbuf_reset(sb);
+ }
+ if (junk_work_tree) {
+ strbuf_addstr(sb, junk_work_tree);
+ remove_dir_recursively(sb, 0);
+ strbuf_reset(sb);
+ }
+}
+
+static void remove_junk_on_signal(int signo)
+{
+ remove_junk();
+ sigchain_pop(signo);
+ raise(signo);
+}
+
static int prepare_linked_checkout(const struct checkout_opts *opts,
struct branch_info *new)
{
@@ -823,7 +853,7 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
struct stat st;
const char *name;
struct child_process cp;
- int counter = 0, len;
+ int counter = 0, len, ret;
if (!new-commit)
die(_(no branch specified));
@@ -848,13 +878,21 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
strbuf_addf(sb_repo, %d, counter);
}
name = sb_repo.buf + len - strlen(name);
+
+ junk_pid = getpid();
+ atexit(remove_junk);
+ sigchain_push_common(remove_junk_on_signal);
+
if (mkdir(sb_repo.buf, 0777))
die_errno(_(could not create directory of '%s'), sb_repo.buf);
+ junk_git_dir = sb_repo.buf;
+ is_junk = 1;
strbuf_addf(sb_git, %s/.git, path);
if (safe_create_leading_directories_const(sb_git.buf))
die_errno(_(could not create leading directories of '%s'),
sb_git.buf);
+ junk_work_tree = path;
write_file(sb_git.buf, 1, gitdir: %s/repos/%s\n,
real_path(get_git_dir()), name);
@@ -879,7 +917,14 @@ static int prepare_linked_checkout(const struct
checkout_opts *opts,
memset(cp, 0, sizeof(cp));
cp.git_cmd = 1;
cp.argv = opts-saved_argv;
- return run_command(cp);
+ ret = run_command(cp);
+ if (!ret)
+ is_junk = 0;
+ strbuf_release(sb);
+ strbuf_release(sb_repo);
+ strbuf_release(sb_git);
+ return ret;
+
}
static int git_checkout_config(const char *var, const char *value, void *cb)
--
1.8.5.2.240.g8478abd
--
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 v3 21/25] checkout: support checking out into a new working directory
git checkout --to sets up a new working directory with a .git file
pointing to $GIT_DIR/repos/id. It then executes git checkout again
on the new worktree with the same arguments except --to is taken
out. The second checkout execution, which is not contaminated with any
info from the current repository, will actually check out and
everything that normal git checkout does.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-checkout.txt | 34 +
Documentation/gitrepository-layout.txt | 3 ++
builtin/checkout.c | 93 +-
t/t2025-checkout-to.sh (new +x)| 39 ++
4 files changed, 167 insertions(+), 2 deletions(-)
create mode 100755 t/t2025-checkout-to.sh
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 33ad2ad..fcf73b2 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -225,6 +225,13 @@ This means that you can use `git checkout -p` to
selectively discard
edits from your current working tree. See the ``Interactive Mode''
section of linkgit:git-add[1] to learn how to operate the `--patch` mode.
+--to=path::
+ Check out a new branch in a separate working directory at
+ `path`. A new working directory is linked to the current
+ repository, sharing everything except working directory
+ specific files such as HEAD, index... See MULTIPLE CHECKOUT
+ MODE section for more information.
+
branch::
Branch to checkout; if it refers to a branch (i.e., a name that,
when prepended with refs/heads/, is a valid ref), then that
@@ -388,6 +395,33 @@ $ git reflog -2 HEAD # or
$ git log -g -2 HEAD
+MULTIPLE CHECKOUT MODE
+---
+Normally a working directory is attached to repository. When git
+checkout --to is used, a new working directory is attached to the
+current repository. This new working directory is called linked
+checkout as compared to the main checkout prepared by git init or
+git clone. A repository has one main checkout and zero or more
+linked checkouts.
+
+All checkouts share the same repository. Linked checkouts see the
+repository a bit different from the main checkout. When the checkout
+new reads the path $GIT_DIR/HEAD for example, the actual path
+returned could be $GIT_DIR/repos/new/HEAD. This ensures checkouts
+won't step on each other.
+
+Each linked checkout has a private space in $GIT_DIR/repos, usually
+named after the base name of the working directory with a number added
+to make it unique. The linked checkout's $GIT_DIR points to this
+private space while $GIT_COMMON_DIR points to the main checkout's
+$GIT_DIR. These settings are done by git checkout --to.
+
+Because in this mode $GIT_DIR becomes a lightweight virtual file
+system where a path could be rewritten to some place else, accessing
+$GIT_DIR from scripts should use `git rev-parse --git-path` to resolve
+a path instead of using it directly unless the path is known to be
+private to the working directory.
+
EXAMPLES
diff --git a/Documentation/gitrepository-layout.txt
b/Documentation/gitrepository-layout.txt
index 9bfe0f1..495a937 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -218,6 +218,9 @@ commondir::
modules::
Contains the git-repositories of the submodules.
+repos::
+ Contains worktree specific information of linked checkouts.
+
SEE ALSO
linkgit:git-init[1],
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 0570e41..2b856a6 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -48,6 +48,10 @@ struct checkout_opts {
const char *prefix;
struct pathspec pathspec;
struct tree *source_tree;
+
+ const char *new_worktree;
+ const char **saved_argv;
+ int new_worktree_mode;
};
static int post_checkout_hook(struct commit *old, struct commit *new,
@@ -250,6 +254,9 @@ static int checkout_paths(const struct checkout_opts *opts,
die(_(Cannot update paths and switch to branch '%s' at the
same time.),
opts-new_branch);
+ if (opts-new_worktree)
+ die(_('%s' cannot be used with updating paths), --to);
+
if (opts-patch_mode)
return run_add_interactive(revision, --patch=checkout,
opts-pathspec);
@@ -486,7 +493,7 @@ static int merge_working_tree(const struct checkout_opts
*opts,
topts.dir-flags |= DIR_SHOW_IGNORED;
setup_standard_excludes(topts.dir);
}
- tree = parse_tree_indirect(old-commit ?
+ tree = parse_tree_indirect(old-commit
!opts-new_worktree_mode ?
old-commit-object.sha1 :
EMPTY_TREE_SHA1_BIN);
[PATCH v3 17/25] setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
setup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/setup.c b/setup.c
index 282fdc9..e56ec11 100644
--- a/setup.c
+++ b/setup.c
@@ -285,6 +285,10 @@ static int check_repository_format_gently(const char
*gitdir, int *nongit_ok)
const char *repo_config;
int ret = 0;
+ get_common_dir(sb, gitdir);
+ strbuf_addstr(sb, /config);
+ repo_config = sb.buf;
+
/*
* git_config() can't be used here because it calls git_pathdup()
* to get $GIT_CONFIG/config. That call will make setup_git_env()
@@ -294,8 +298,6 @@ static int check_repository_format_gently(const char
*gitdir, int *nongit_ok)
* Use a gentler version of git_config() to check if this repo
* is a good one.
*/
- strbuf_addf(sb, %s/config, gitdir);
- repo_config = sb.buf;
git_config_early(check_repository_format_version, NULL, repo_config);
if (GIT_REPO_VERSION repository_format_version) {
if (!nongit_ok)
--
1.8.5.2.240.g8478abd
--
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 v3 12/25] *.sh: avoid hardcoding $GIT_DIR/hooks/...
If $GIT_COMMON_DIR is set, it should be $GIT_COMMON_DIR/hooks/, not
$GIT_DIR/hooks/. Just let rev-parse --git-path handle it.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
git-am.sh | 22 +++---
git-rebase--interactive.sh | 6 +++---
git-rebase--merge.sh | 6 ++
git-rebase.sh | 4 ++--
templates/hooks--applypatch-msg.sample | 4 ++--
templates/hooks--pre-applypatch.sample | 4 ++--
6 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index bbea430..dfa0618 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -803,10 +803,10 @@ To restore the original branch and stop patching run
\\$cmdline --abort\.
continue
fi
- if test -x $GIT_DIR/hooks/applypatch-msg
+ hook=`git rev-parse --git-path hooks/applypatch-msg`
+ if test -x $hook
then
- $GIT_DIR/hooks/applypatch-msg $dotest/final-commit ||
- stop_here $this
+ $hook $dotest/final-commit || stop_here $this
fi
if test -f $dotest/final-commit
@@ -880,9 +880,10 @@ did you forget to use 'git add'?
stop_here_user_resolve $this
fi
- if test -x $GIT_DIR/hooks/pre-applypatch
+ hook=`git rev-parse --git-path hooks/pre-applypatch`
+ if test -x $hook
then
- $GIT_DIR/hooks/pre-applypatch || stop_here $this
+ $hook || stop_here $this
fi
tree=$(git write-tree)
@@ -908,18 +909,17 @@ did you forget to use 'git add'?
echo $(cat $dotest/original-commit) $commit
$dotest/rewritten
fi
- if test -x $GIT_DIR/hooks/post-applypatch
- then
- $GIT_DIR/hooks/post-applypatch
- fi
+ hook=`git rev-parse --git-path hooks/post-applypatch`
+ test -x $hook $hook
go_next
done
if test -s $dotest/rewritten; then
git notes copy --for-rewrite=rebase $dotest/rewritten
-if test -x $GIT_DIR/hooks/post-rewrite; then
- $GIT_DIR/hooks/post-rewrite rebase $dotest/rewritten
+hook=`git rev-parse --git-path hooks/post-rewrite`
+if test -x $hook; then
+ $hook rebase $dotest/rewritten
fi
fi
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 43c19e0..d741b04 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -632,9 +632,9 @@ do_next () {
git notes copy --for-rewrite=rebase $rewritten_list ||
true # we don't care if this copying failed
}
- if test -x $GIT_DIR/hooks/post-rewrite
- test -s $rewritten_list; then
- $GIT_DIR/hooks/post-rewrite rebase $rewritten_list
+ hook=`git rev-parse --git-path hooks/post-rewrite`
+ if test -x $hook test -s $rewritten_list; then
+ $hook rebase $rewritten_list
true # we don't care if this hook failed
fi
warn Successfully rebased and updated $head_name.
diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
index e7d96de..68f5d09 100644
--- a/git-rebase--merge.sh
+++ b/git-rebase--merge.sh
@@ -93,10 +93,8 @@ finish_rb_merge () {
if test -s $state_dir/rewritten
then
git notes copy --for-rewrite=rebase $state_dir/rewritten
- if test -x $GIT_DIR/hooks/post-rewrite
- then
- $GIT_DIR/hooks/post-rewrite rebase
$state_dir/rewritten
- fi
+ hook=`git rev-parse --git-path hooks/post-rewrite`
+ test -x $hook $hook rebase $state_dir/rewritten
fi
say All done.
}
diff --git a/git-rebase.sh b/git-rebase.sh
index 8a3efa2..1cf8dba 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -195,9 +195,9 @@ run_specific_rebase () {
run_pre_rebase_hook () {
if test -z $ok_to_skip_pre_rebase
- test -x $GIT_DIR/hooks/pre-rebase
+ test -x `git rev-parse --git-path hooks/pre-rebase`
then
- $GIT_DIR/hooks/pre-rebase ${1+$@} ||
+ `git rev-parse --git-path hooks/pre-rebase` ${1+$@} ||
die $(gettext The pre-rebase hook refused to rebase.)
fi
}
diff --git a/templates/hooks--applypatch-msg.sample
b/templates/hooks--applypatch-msg.sample
index 8b2a2fe..28b843b 100755
--- a/templates/hooks--applypatch-msg.sample
+++ b/templates/hooks--applypatch-msg.sample
@@ -10,6 +10,6 @@
# To enable this hook, rename this file to applypatch-msg.
. git-sh-setup
-test -x $GIT_DIR/hooks/commit-msg
- exec $GIT_DIR/hooks/commit-msg ${1+$@}
+commitmsg=`git rev-parse --git-path hooks/commit-msg`
+test -x $commitmsg exec $commitmsg ${1+$@}
:
diff --git a/templates/hooks--pre-applypatch.sample
b/templates/hooks--pre-applypatch.sample
index b1f187c..51aa244 100755
--- a/templates/hooks--pre-applypatch.sample
+++
[PATCH v3 19/25] wrapper.c: wrapper to open a file, fprintf then close
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
cache.h | 2 ++
wrapper.c | 31 +++
2 files changed, 33 insertions(+)
diff --git a/cache.h b/cache.h
index 98b5dd3..99b86d9 100644
--- a/cache.h
+++ b/cache.h
@@ -1239,6 +1239,8 @@ static inline ssize_t write_str_in_full(int fd, const
char *str)
{
return write_in_full(fd, str, strlen(str));
}
+__attribute__((format (printf,3,4)))
+extern int write_file(const char *path, int fatal, const char *fmt, ...);
/* pager.c */
extern void setup_pager(void);
diff --git a/wrapper.c b/wrapper.c
index 0cc5636..5ced50d 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -455,3 +455,34 @@ struct passwd *xgetpwuid_self(void)
errno ? strerror(errno) : _(no such user));
return pw;
}
+
+int write_file(const char *path, int fatal, const char *fmt, ...)
+{
+ struct strbuf sb = STRBUF_INIT;
+ int fd = open(path, O_RDWR | O_CREAT | O_TRUNC, 0666);
+ va_list params;
+ if (fd 0) {
+ if (fatal)
+ die_errno(_(could not open %s for writing), path);
+ return -1;
+ }
+ va_start(params, fmt);
+ strbuf_vaddf(sb, fmt, params);
+ va_end(params);
+ if (write_in_full(fd, sb.buf, sb.len) != sb.len) {
+ int err = errno;
+ close(fd);
+ errno = err;
+ strbuf_release(sb);
+ if (fatal)
+ die_errno(_(could not write to %s), path);
+ return -1;
+ }
+ strbuf_release(sb);
+ if (close(fd)) {
+ if (fatal)
+ die_errno(_(could not close %s), path);
+ return -1;
+ }
+ return 0;
+}
--
1.8.5.2.240.g8478abd
--
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 v3 16/25] setup.c: convert check_repository_format_gently to use strbuf
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
setup.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/setup.c b/setup.c
index 4e5711c..282fdc9 100644
--- a/setup.c
+++ b/setup.c
@@ -281,7 +281,9 @@ void setup_work_tree(void)
static int check_repository_format_gently(const char *gitdir, int *nongit_ok)
{
- char repo_config[PATH_MAX+1];
+ struct strbuf sb = STRBUF_INIT;
+ const char *repo_config;
+ int ret = 0;
/*
* git_config() can't be used here because it calls git_pathdup()
@@ -292,7 +294,8 @@ static int check_repository_format_gently(const char
*gitdir, int *nongit_ok)
* Use a gentler version of git_config() to check if this repo
* is a good one.
*/
- snprintf(repo_config, PATH_MAX, %s/config, gitdir);
+ strbuf_addf(sb, %s/config, gitdir);
+ repo_config = sb.buf;
git_config_early(check_repository_format_version, NULL, repo_config);
if (GIT_REPO_VERSION repository_format_version) {
if (!nongit_ok)
@@ -302,9 +305,10 @@ static int check_repository_format_gently(const char
*gitdir, int *nongit_ok)
GIT_REPO_VERSION, repository_format_version);
warning(Please upgrade Git);
*nongit_ok = -1;
- return -1;
+ ret = -1;
}
- return 0;
+ strbuf_release(sb);
+ return ret;
}
/*
--
1.8.5.2.240.g8478abd
--
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: gitweb.cgi bug - XML Parsing Error: not well-formed
On Feb 18, 2014, at 6:41 AM, Dongsheng Song dongsheng.s...@gmail.com wrote: Here is gitweb generated XHTML fragment: … You're going to have to be more specific. - Andrew -- 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: [RFC/PATCH] Supporting non-blob notes
On Mon, Feb 17, 2014 at 11:48 AM, yann.dir...@bertin.fr wrote: The recent git-note -C changes commit type? thread (http://thread.gmane.org/gmane.comp.version-control.git/241950) looks like a good occasion to discuss possible uses of non-blob notes. The use-case we're thinking about is the storage of testrun logs as notes (think: being able to justify that a given set of tests were successfully run on a given revision). I think this is a good use of notes, and organizing the testrun logs into a tree of files seems like a natural way to proceed. Here is a proof-of-concept patch (that applies to 1.8.4.2) I've been playing with. Because of the -C behaviour described in this other thread, I opted for a new -o flag that would not mess with the object argument. This patch is very minimalist, and just allows storing a tree note (currently any type of object, but that's easy to restrict if we want to), and retrieving it. I think we must think _very_ carefully about which object types we allow to be stored in notes trees. As far as I can see, you use case (storing testrun logs) is covered nicely by allowing tree objects as notes, and I think that's where we should start. The note tree is itself a tree object, and storing sub-trees of that is not new or unusual to Git at all. Reachability is nicely covered by how Git already handles sub-trees. Obviously we must flesh out how the notes-related parts of the code deal with trees (see below), but that does not really affect the rest of Git, and should therefore be relatively uncontroversial. If we go on to _commit_ objects, they are currently only referenced from tree objects as gitlinks (with a special 16 mode). If you were to put one of these in a notes tree, you would get the same semantics as a gitlink, i.e. git handles that part of the tree as a submodule where a different submodule repo is (to be) checked out. The commit is NOT considered/required to be reachable, and would therefore not be automatically communicated by a fetch or push. So if you want commits in a notes tree to be handled differently from commits-as-gitlinks, you would have to tweak all the code in Git that deal with gitlinks. You would have to introduce a differentiation between your commits-as-gitlinks and commits-as-notes, either by reserving another special mode number, or by otherwise making the rest of Git notes-aware. All of this comes in addition to teaching the notes-related code how to deal with commits (i.e. how to display them, etc.). In other words, before you embark on this, you need a convincing argument for why allowing commits-as-notes is really necessary and worth it in the end. Please also consider that you _can_ support commits-as-notes by the mechanism I suggested in the previous thread: Store the commit SHA1 in a note-as-blob, and then amend the notes commit to include the commit SHA1 as an additional parent. It's not very elegant, but it solves the reachability problem. If we go even further and want to allow ANY git object as a note, then we must also consider tag objects, which AFAIK has never before been stored inside a tree. Here we are really entering uncharted territory... So for now (and in lieu of a convincing use case for notes-as-commits), I suggest you only look at notes-as-trees. The first consequence of this is probably that your added -o/--object option should be renamed. -t/--tree is not taken, AFAICS... Johan Herland wrote: Obviously, it would not make sense to use refs/notes/history while displaying the commit log (git log --notes=history), as the raw commit object would be shown in the log. Currently, a non-blob commit is just not displayed at all. And rather than displaying the raw object, we have a number of options available, starting with object's sha1, to more elaborate presentations depending on the type of object (commit info, tree hierarchy, etc, as git notes show already does). This PoC shows that it can be dealt with later. I'm only considering the notes-as-tree case here... I assume that if you organize your notes in tree objects, then you probably have more information in there than is useful to display in the textual output from git log. Also, you probably have special-purpose scripts for initially generating those trees, and later digging into the information stored therein. Hence we should concentrate on getting the basics covered, to allow those scripts to do their thing, and adding bells and whistles to git log for displaying notes-as-trees is much less important. For now, git log should probably show a short summary when encountering a notes-as-tree. Whether that summary consists of merely the tree SHA1, or in providing a (relatively short) tree listing, I leave up to you. I also agree that this can be dealt with later (as long as the default behaviour is not actively harmful/confusing). What I envision, would be viewers like gitk simply show the hyperlinked sha1, and (in the case of a tree
Re: gitweb.cgi bug - XML Parsing Error: not well-formed
What's your mean ? I think I had post enough information: When I access https://xxx.info/repo/git?p=DRE/Reference.git;a=commitdiff;h=fbd4e74c867214062ad39282a899f1d14a2e89ba Then gitweb.cgi generate invalid XHTML: div class=patch id=patch19 div class=diff headerdiff --git a/RFC/2010/DRE-2010-004 RFC for Update Synchronization Program amp; Solve the Balance Adjustment Issue v2.doc a class=path href=/repo/git?p=DRE/Reference.git;a=blob;f=RFC/2010/DRE-2010-004+RFC+for+Update+Synchronization+Program+%26+Solve+the+Balance+Adjustment+Issue+v2.doc;h=3074448e2e68235e891ebd1301e6277d993973a5;hb=fbd4e74c867214062ad39282a899f1d14a2e89bab/RFC/2010/DRE-2010-004 RFC for Update Synchronization Program amp; Solve the Balance Adjustment Issue v2.doc/a/div div class=diff extended_header new file mode 100644span class=info (file)/spanbr/ index 000..a class=hash href=/repo/git?p=DRE/Reference.git;a=blob;f=RFC/2010/DRE-2010-004+RFC+for+Update+Synchronization+Program+%26+Solve+the+Balance+Adjustment+Issue+v2.doc;h=3074448e2e68235e891ebd1301e6277d993973a5;hb=fbd4e74c867214062ad39282a899f1d14a2e89ba3074448/abr/ Binary files /dev/null and b/RFC/2010/DRE-2010-004 RFC for Update Synchronization Program Solve the Balance Adjustment Issue v2.doc differbr/ /div /div The last 'Program Solve' should be 'Program amp; Solve' Regards, Dongsheng On Tue, Feb 18, 2014 at 10:34 PM, Andrew Keller and...@kellerfarm.com wrote: On Feb 18, 2014, at 6:41 AM, Dongsheng Song dongsheng.s...@gmail.com wrote: Here is gitweb generated XHTML fragment: … You're going to have to be more specific. - Andrew -- 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 gc --aggressive led to about 40 times slower git log --raw
David Kastrup wrote: Duy Nguyen pclo...@gmail.com writes: Likely because --aggressive passes --depth=250 to pack-objects. Long delta chains could reduce pack size and increase I/O as well as zlib processing signficantly. [...] Compression should reduce rather than increase the total amount of reads. --depth=250 means to allow chains of To get this object, first inflate this object, then apply this delta of length 250. That's absurdly long, and doesn't even help compression much in practice (many short chains referring to the same objects tends to work fine). We probably shouldn't make --aggressive do that. Something like --depth=10 would make more sense. Hoping that clarifies, Jonathan -- 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 gc --aggressive led to about 40 times slower git log --raw
2014-02-18 9:45 GMT+00:00 Duy Nguyen pclo...@gmail.com: Christian can try git repack -adf That's what I already mentioned in my first mail is what I used to fix the problem. Here are some 'hard' numbers, FWIW: - both ~/scr and swap are on the same SSD; $ free total used free sharedbuffers cached Mem: 39967483800828 195920 0 3771761078848 -/+ buffers/cache:23448041651944 Swap: 2097148 1697601927388 git only used up to about 100 MB of VIRT or RSS when I checked, there was an ulimit of -S -v 120. - this is git version 1.7.10.4 (1:1.7.10.4-1+wheezy1 i386 Debian) - after my attempted merge (which had conflicts and I had then cancelled by way of git reset --hard), and then a git gc, the times were: ~/scr$ time git log --raw _THELOG real 3m7.002s user 2m0.252s sys 1m6.008s - on a copy: /dev/shm/scr$ time git repack -a -d -f Counting objects: 34917, done. Delta compression using up to 2 threads. Compressing objects: 100% (27038/27038), done. Writing objects: 100% (34917/34917), done. Total 34917 (delta 13928), reused 0 (delta 0) real 4m33.193s user 3m42.950s sys 1m13.821s /dev/shm/scr$ time git log --raw _THELOG2 real 0m8.276s user 0m7.192s sys 0m1.052s (not sure why it took 8s here, perhaps I had another process running at the same time? Compare with the 0m4.913s below.) /dev/shm/scr$ time g-gc --aggressive Counting objects: 36066, done. Delta compression using up to 2 threads. Compressing objects: 100% (27812/27812), done. Writing objects: 100% (36066/36066), done. Total 36066 (delta 14367), reused 21699 (delta 0) Checking connectivity: 36066, done. real 5m52.013s user 8m28.652s sys 1m4.308s /dev/shm/scr$ time git log --raw _THELOG2 real 1m34.430s user 0m47.291s sys 0m46.615s /dev/shm/scr$ time git repack -adf Counting objects: 36066, done. Delta compression using up to 2 threads. Compressing objects: 100% (27812/27812), done. Writing objects: 100% (36066/36066), done. Total 36066 (delta 14256), reused 21699 (delta 0) real 2m32.083s user 1m51.295s sys 1m4.940s /dev/shm/scr$ time git log --raw _THELOG3 real 0m4.913s user 0m3.944s sys 0m0.944s /dev/shm/scr$ du -s .git 43728 .git - back in the original place: ~/scr$ time git repack -a -d -f Counting objects: 36066, done. Delta compression using up to 2 threads. Compressing objects: 100% (27812/27812), done. Writing objects: 100% (36066/36066), done. Total 36066 (delta 14257), reused 21700 (delta 0) real 4m6.503s user 3m16.568s sys 1m11.640s ~/scr$ time git log --raw _THELOG2 real 0m5.002s user 0m4.032s sys 0m0.952s -- 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
Business Proposal
I am Mr. Mr. Leung Wing Lok and I work with Hang Seng Bank, Hong Kong. I have a Business Proposal of $19,500,000.00 of mutual benefits. Contact me via leungwlok...@yahoo.com.vn for more info.-- 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 3/3] push: Add the --no-recurse-submodules option
I noticed the option in the man-page but there is still no configuration option available. Did you forget to add it after all? Right now --recurse-submodules has little use by itself as the problem it solves is forgetting to push a submodule which is no different from forgetting to specify the 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: [PATCH] revert.c: Allow to specify -x via git-config
Hi, Guido Günther wrote: Without this when maintaining stable branches it's easy to forget to use -x to track where a patch was cherry-picked from. [...] --- a/Documentation/git-cherry-pick.txt +++ b/Documentation/git-cherry-pick.txt @@ -215,6 +215,14 @@ the working tree. spending extra time to avoid mistakes based on incorrectly matching context lines. +CONFIGURATION +- + +See linkgit:git-config[1] for core variables. + +cherrypick.record-origin:: + Default for the `-x` option. Defaults to `false`. I'm not convinced this is a good idea. Even if I always want -x when cherry-picking to stable, isn't this going to add the extra clutter line when I cherry-pick on other branches? It's especially worrying because there would be no way to override the configuration with a flag on the command line. (-r which used to do that is now a no-op.) I would be more easily convinced by a '[branch foo] recordcherrypickorigins' option that makes cherry-pick default to '-x' when and only when on the foo branch. Can you say more about the context? Why is it important to record the original commit id? Is it a matter of keeping a reminder of the commits' similarity (which cherry-pick without '-x' does ok by reusing the same message) or are people reviewing the change downstream going to be judging the change based on the recorded upstream commit id? (Like linux's stable-version branches --- but those have other requirements so I don't think this configuration would work as is there.) [...] +++ b/builtin/revert.c @@ -196,6 +196,15 @@ int cmd_revert(int argc, const char **argv, const char *prefix) [...] + if (!strcmp(var, cherrypick.record-origin)) + opts-record_origin = git_config_bool (var, value); More nitpicky: git uses camelCase, not dash-delimited, for multiword configuration items. The config parsing machinery normalizes to lowercase, so this would then be cherrypick.recordorigin. Hope that helps, Jonathan -- 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: Make the git codebase thread-safe
Duy Nguyen pclo...@gmail.com writes: On Sat, Feb 15, 2014 at 8:15 AM, Zachary Turner ztur...@chromium.org wrote: ... 2) Use TLS as you suggest and have one fd per pack thread. Probably the most complicated code change (at least for me, being a first-time contributor) It's not so complicated. I suggested a patch [1] before (surprise!). ... [1] http://article.gmane.org/gmane.comp.version-control.git/196042 That message is at the tail end of the discussion. I wonder why nothing came out of it back then. While I do not see anything glaringly wrong with the change from a quick glance over it, it would be nice to hear how well it performs on their platform from Windows folks. 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: Make the git codebase thread-safe
It shouldn't be hard for us to run some tests with this patch applied. Will report back in a day or two. On Tue, Feb 18, 2014 at 9:55 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: On Sat, Feb 15, 2014 at 8:15 AM, Zachary Turner ztur...@chromium.org wrote: ... 2) Use TLS as you suggest and have one fd per pack thread. Probably the most complicated code change (at least for me, being a first-time contributor) It's not so complicated. I suggested a patch [1] before (surprise!). ... [1] http://article.gmane.org/gmane.comp.version-control.git/196042 That message is at the tail end of the discussion. I wonder why nothing came out of it back then. While I do not see anything glaringly wrong with the change from a quick glance over it, it would be nice to hear how well it performs on their platform from Windows folks. 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] revert.c: Allow to specify -x via git-config
On Tue, Feb 18, 2014 at 09:49:13AM -0800, Jonathan Nieder wrote: Can you say more about the context? Why is it important to record the original commit id? Is it a matter of keeping a reminder of the commits' similarity (which cherry-pick without '-x' does ok by reusing the same message) or are people reviewing the change downstream going to be judging the change based on the recorded upstream commit id? (Like linux's stable-version branches --- but those have other requirements so I don't think this configuration would work as is there.) I can provide a use case. At work, we merge into the maintenance and development branches and cherry-pick from the maintenance to the stable branches. We want committers to always use -x -s because we need to know which reviewer backported the change and we want to be able to track which commits have been backported and whether any reverts also need to be cherry-picked. We also have automated tools that want this information. I usually solve this with an alias (backport = cherry-pick -x -s), but I can see how this might be a useful option. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: error: src refspec refs/heads/master matches more than one.
Duy Nguyen pclo...@gmail.com writes: Prevent is a strong word. I meant we only do it if they force it. Something like this.. -- 8 -- diff --git a/branch.c b/branch.c index 723a36b..3f0540f 100644 --- a/branch.c +++ b/branch.c @@ -251,6 +251,11 @@ void create_branch(const char *head, forcing = 1; } + if (!force dwim_ref(name, strlen(name), sha1, real_ref)) + die(_(creating ref refs/heads/%s makes %s ambiguous.\n + Use -f to create it anyway.), + name, name); Does this check still allow you to create a branch refs/heads/next and then later create a branch next? The latter will introduce an ambiguity without any prevention, even though the prevention would trigger if the order in which these two branches are created is swapped--- the end result has ambiguity but the safety covers only one avenue to the confusing situation. And the only way I can think of to avoid that kind of confusion is to forbid creation of a subset of possible names by reserving a set of known (but arbitrary) prefixes---which I am not sure is a good way to go. At least not yet. So... -- 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: diff weirdness (bug?)
Dario Bertini berda...@gmail.com writes: On 02/14/2014 09:03 PM, Junio C Hamano wrote: This is a combined diff, and yaml-related lines are added relative to your _other_ branch you are merging (notice these + are indented by one place). Relative to what you had at the tip of your branch before you started this operation that ended up conflicted, the half-merged result removes if/else that sets DIST_MODULE_PATH and replaces it with a single line (their +/- are on the first column, signifying that these are differences relative to the first parent, i.e. your state before you started the operation). if we remove these 3 lines, we'll get this diff: With that understanding, I think the output after removing these three lines is perfectlyh understandable and correct. You are looking at the three lines that used to exist in the version you started from, that were missing from the other side. If you remoe them, it will show as removal from _your_ version (notice these - that shows what _you_ did manually are on the first column, saying that that is relative to _your_ version). Thank you, I was completely unaware of combined diffs. Still: I can't see how this would explain the empty diff when deleting 4 lines instead of 3. Also: in the diff output I get 2 hashes, but these are not the hashes of the commits, but the contents of the files apparently. One should be HEAD (but if I run sha1sum over the file the hash doesn't match), but A blob object name (or for that matter, names of any type of object) is not the same as the hash over its contents alone. See combined diff format section of git diff --help if you are interested in reading what the output format is telling you. the other can't be the commit which I reverted: the diff is too small... or at least this is what I understand By the way, in the man of git diff there's the briefly mentioned '-m' flag. If anyone else reading this mail in the archives is confused by the combined diff output, just use git diff -m HEAD... I'll probably add this in my git aliases If you are primarily interested in what a merge (or other mergy-operation like revert) did to your working tree state, relative to the state it operated on, git diff HEAD is most likely what you want. -- 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] config: teach git config --file - to read from the standard input
Jeff King p...@peff.net writes:
+} else {
+if (cf-name)
+return error(bad config file line %d in %s,
+cf-linenr, cf-name);
+else
+return error(bad config file line %d, cf-linenr);
+}
I think I preferred the earlier version where you had stdin in the
name field, and this hunk could just go away. I know you switched it to
NULL here to avoid making bogus relative filenames in includes.
Exactly the same comment here. I really like the way how this
series becomes more polished every time we see it.
But that would be pretty straightforward to fix by splitting the name
field into an additional path field. It looks like git config --blob
has the same problem (it will try relative lookups in the filesystem,
even though that is nonsensical from the blob). So we could fix the
existing bug at the same time. :)
Perhaps this could go at the start of your series?
Sounds like the right thing to do.
Thanks.
-- 8 --
Subject: config: disallow relative include paths from blobs
When we see a relative config include like:
[include]
path = foo
we make it relative to the containing directory of the file
that contains the snippet. This makes no sense for config
read from a blob, as it is not on the filesystem. Something
like HEAD:some/path could have a relative path within the
tree, but:
1. It would not be part of include.path, which explicitly
refers to the filesystem.
2. It would need different parsing rules anyway to
determine that it is a tree path.
The current code just uses the name field, which is wrong.
Let's split that into name and path fields, use the
latter for relative includes, and fill in only the former
for blobs.
Signed-off-by: Jeff King p...@peff.net
---
I don't think we considered includes at all when adding --blob. I cannot
think of any good reason to have even an absolute filesystem include
from a blob. And I wonder if it is possible to cause security mischief
by convincing git to look at /etc/passwd or similar (it would not parse,
of course, but you might be able to glean information from the error
messages or something).
It's probably OK, though, because you would generally not read real
config from an untrusted source (there are many bad things they could
set), and other code which uses the config reader explicitly does not
turn on includes.
config.c | 10 ++
t/t1305-config-include.sh | 16
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index d969a5a..b295310 100644
--- a/config.c
+++ b/config.c
@@ -21,6 +21,7 @@ struct config_source {
} buf;
} u;
const char *name;
+ const char *path;
int die_on_error;
int linenr;
int eof;
@@ -97,12 +98,12 @@ static int handle_path_include(const char *path, struct
config_include_data *inc
if (!is_absolute_path(path)) {
char *slash;
- if (!cf || !cf-name)
+ if (!cf || !cf-path)
return error(relative config includes must come from
files);
- slash = find_last_dir_sep(cf-name);
+ slash = find_last_dir_sep(cf-path);
if (slash)
- strbuf_add(buf, cf-name, slash - cf-name + 1);
+ strbuf_add(buf, cf-path, slash - cf-path + 1);
strbuf_addstr(buf, path);
path = buf.buf;
}
@@ -1040,7 +1041,7 @@ int git_config_from_file(config_fn_t fn, const char
*filename, void *data)
struct config_source top;
top.u.file = f;
- top.name = filename;
+ top.name = top.path = filename;
top.die_on_error = 1;
top.do_fgetc = config_file_fgetc;
top.do_ungetc = config_file_ungetc;
@@ -1062,6 +1063,7 @@ int git_config_from_buf(config_fn_t fn, const char
*name, const char *buf,
top.u.buf.len = len;
top.u.buf.pos = 0;
top.name = name;
+ top.path = NULL;
top.die_on_error = 0;
top.do_fgetc = config_buf_fgetc;
top.do_ungetc = config_buf_ungetc;
diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index a707076..6edd38b 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -122,6 +122,22 @@ test_expect_success 'relative includes from command line
fail' '
test_must_fail git -c include.path=one config test.one
'
+test_expect_success 'absolute includes from blobs work' '
+ echo [test]one = 1 one
+ echo [include]path=$(pwd)/one blob
+ blob=$(git hash-object -w blob)
+ echo 1 expect
+ git config --blob=$blob test.one actual
+ test_cmp expect actual
+'
+
+test_expect_success 'relative includes from blobs fail' '
+ echo [test]one = 1 one
+
Re: [PATCH 0/4] Good bye fnmatch
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Long story short, we wanted globbing wildcard ** so I ripped wildmatch library from rsync to do it. And it opened a possibility to replace fnmatch completely, which would provide consistent behavior across platforms (native fnmatch behaves differently on many corner cases), and some performance gains. I started fnmatch replacement with 4917e1e (Makefile: promote wildmatch to be the default fnmatch implementation - 2013-05-30). This is the final step. Nice. Nguyễn Thái Ngọc Duy (4): Use wildmatch() directly without fnmatch() wrapper Revert test-wildmatch: add perf command to compare wildmatch and fnmatch Stop using fnmatch (either native or compat) Actually remove compat fnmatch source code Makefile| 22 -- builtin/apply.c | 2 +- builtin/branch.c| 2 +- builtin/describe.c | 2 +- builtin/for-each-ref.c | 2 +- builtin/ls-remote.c | 2 +- builtin/name-rev.c | 2 +- builtin/reflog.c| 2 +- builtin/replace.c | 2 +- builtin/show-branch.c | 2 +- builtin/tag.c | 2 +- compat/fnmatch/fnmatch.c (gone) | 494 compat/fnmatch/fnmatch.h (gone) | 84 --- config.mak.uname| 10 - configure.ac| 28 --- diffcore-order.c| 2 +- dir.c | 11 +- git-compat-util.h | 12 - refs.c | 2 +- revision.c | 2 +- t/t3070-wildmatch.sh| 13 -- test-wildmatch.c| 79 --- 22 files changed, 20 insertions(+), 759 deletions(-) -- 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: error: src refspec refs/heads/master matches more than one.
On Tue, Feb 18, 2014 at 11:03:10AM -0800, Junio C Hamano wrote: Duy Nguyen pclo...@gmail.com writes: Prevent is a strong word. I meant we only do it if they force it. Something like this.. -- 8 -- diff --git a/branch.c b/branch.c index 723a36b..3f0540f 100644 --- a/branch.c +++ b/branch.c @@ -251,6 +251,11 @@ void create_branch(const char *head, forcing = 1; } + if (!force dwim_ref(name, strlen(name), sha1, real_ref)) + die(_(creating ref refs/heads/%s makes %s ambiguous.\n + Use -f to create it anyway.), + name, name); Does this check still allow you to create a branch refs/heads/next and then later create a branch next? The latter will introduce an ambiguity without any prevention, even though the prevention would trigger if the order in which these two branches are created is swapped--- the end result has ambiguity but the safety covers only one avenue to the confusing situation. And the only way I can think of to avoid that kind of confusion is to forbid creation of a subset of possible names by reserving a set of known (but arbitrary) prefixes---which I am not sure is a good way to go. At least not yet. There's already the arbitrary set of prefixes in refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see how a user might think that since git log refs/heads/name is equivalent to git log master then git branch refs/heads/name should be equivalent to git branch name. I don't think requiring --force for these branch names that overlap with these special namespaces is a big leap from supporting them for inspection commands. Although I'm not sure how sensible it is to examine every remote name to catch something like git branch origin/master. Perhaps Duy's ambiguity check is the best thing for that 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
Re: [PATCH/RESEND] attr: allow pattern escape using backslashes
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Patterns in .gitattributes are separated by whitespaces, which makes
it impossible to specify exact spaces in the pattern. '?' can be used
as a workaround, but it matches other characters too. This patch makes
a space following a backslash part of the pattern, not a pattern
separator.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Last discussion is [1] although the thread went off topic, so no
actual discussion.
The only people who could get hurt with this patch are those who do
have a path that ends with a backslash (e.g. 'hello\') and have been
matching it with a pattern that literally match with it, but even
then they should have been quoting it at the end of the pattern
(e.g. as 'hello\\'), so the new parsing rule would not be confused,
I would think.
So, I like it. Thanks.
[1] http://thread.gmane.org/gmane.comp.version-control.git/212631
Documentation/gitattributes.txt | 6 +++---
attr.c | 8 +++-
t/t0003-attributes.sh | 5 +
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 643c1ba..5d4d386 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -20,9 +20,9 @@ Each line in `gitattributes` file is of form:
pattern attr1 attr2 ...
-That is, a pattern followed by an attributes list,
-separated by whitespaces. When the pattern matches the
-path in question, the attributes listed on the line are given to
+That is, a pattern followed by an attributes list, separated by
+whitespaces that are not quoted by a backslash. When the pattern matches
+the path in question, the attributes listed on the line are given to
the path.
Each attribute can be in one of these states for a given path:
diff --git a/attr.c b/attr.c
index 8d13d70..699716d 100644
--- a/attr.c
+++ b/attr.c
@@ -209,7 +209,13 @@ static struct match_attr *parse_attr_line(const char
*line, const char *src,
if (!*cp || *cp == '#')
return NULL;
name = cp;
- namelen = strcspn(name, blank);
+ namelen = 0;
+ while (name[namelen] != '\0' !strchr(blank, name[namelen])) {
+ if (name[namelen] == '\\' name[namelen + 1] != '\0')
+ namelen += 2;
+ else
+ namelen++;
+ }
if (strlen(ATTRIBUTE_MACRO_PREFIX) namelen
starts_with(name, ATTRIBUTE_MACRO_PREFIX)) {
if (!macro_ok) {
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index b9d7947..2f16805 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -23,6 +23,7 @@ test_expect_success 'setup' '
echo offon -test test
echo no notest
echo A/e/F test=A/e/F
+ echo A\\ b test=space
) .gitattributes
(
echo g test=a/g
@@ -195,6 +196,10 @@ test_expect_success 'root subdir attribute test' '
attr_check subdir/a/i unspecified
'
+test_expect_success 'quoting in pattern' '
+ attr_check A b space
+'
+
test_expect_success 'negative patterns' '
echo !f test=bar .gitattributes
git check-attr test -- '''!f''' 2errors
--
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: error: src refspec refs/heads/master matches more than one.
Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: +if (!force dwim_ref(name, strlen(name), sha1, real_ref)) +die(_(creating ref refs/heads/%s makes %s ambiguous.\n + Use -f to create it anyway.), +name, name); Does this check still allow you to create a branch refs/heads/next and then later create a branch next? The latter will introduce an ambiguity without any prevention, even though the prevention would trigger if the order in which these two branches are created is swapped--- the end result has ambiguity but the safety covers only one avenue to the confusing situation. And the only way I can think of to avoid that kind of confusion is to forbid creation of a subset of possible names by reserving a set of known (but arbitrary) prefixes---which I am not sure is a good way to go. At least not yet. Just for the record: after seeing the respective arguments, I consider it the sanest way. It's conceivable to give a configuration option for augmenting the set of reserved prefixes. That would allow to adapt the arbitrariness to match the policies or ref name choices of a particular project while keeping the set of references addressed by the standard git commands in check automagically. -- David Kastrup -- 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] blame: add a failing test for a CRLF issue.
If a file contains CRLF line endings in a repository with core.autocrlf=input, then blame always marks the lines as Not Committed Yet, even if they are unmodified. Add a failing test for this case, so we are at least aware of this issue. Reported-by: Ephrim Khong dr.kh...@gmail.com Signed-off-by: brian m. carlson sand...@crustytoothpaste.net --- Obviously, this doesn't actually fix the issue, but at least we're aware of it so we don't lose track of it and can fix it. A future patch can mark the test passing. t/t8003-blame-corner-cases.sh | 10 ++ 1 file changed, 10 insertions(+) diff --git a/t/t8003-blame-corner-cases.sh b/t/t8003-blame-corner-cases.sh index e7cac1d..903f775 100755 --- a/t/t8003-blame-corner-cases.sh +++ b/t/t8003-blame-corner-cases.sh @@ -191,4 +191,14 @@ test_expect_success 'indent of line numbers, ten lines' ' test $(grep -cactual) = 9 ' +test_expect_failure 'blaming files with CRLF newlines' ' + git config core.autocrlf false + printf testcase\r\n crlffile + git add crlffile + git commit -m testcase + git config core.autocrlf input + git blame crlffile actual + grep A U Thor actual +' + test_done -- 1.9.0.rc3.1008.gd08b47c.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: error: src refspec refs/heads/master matches more than one.
John Keeping j...@keeping.me.uk writes: There's already the arbitrary set of prefixes in refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see how a user might think that since git log refs/heads/name is equivalent to git log master then git branch refs/heads/name should be equivalent to git branch name. Not quite, I am afraid. Branch names used for git branch name and git checkout name are like the Lvalue of an assignment, as opposed to extended SHA-1 expressions to express any commit (e.g. 'master^0', 'refs/heads/master', or 'master') that correspond to the Rvalues used in an expression. Because git checkout can take a branch name or an arbitrary commit object name, there needs a way for the users to disambiguate. Saying that git checkout refs/heads/name must be equivalent to git checkout name is like arguing that assignment value+0 = x should be valid because value+0 is a valid value. For the first parameter to git branch, there is no ambiguity---it must be the name of a branch and cannot be an arbitrary commit object name, so special casing git branch refs/heads/master to mean git branch master may not be too bad. But then we need to either start rejecting git branch refs/tags/v1.0 or keep allowing it to create a ref refs/heads/refs/tags/v1.0 to denote the branch of that exact name given---neither of which is more consistent, so... -- 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 5/5] implement @{publish} shorthand
Jeff King p...@peff.net writes:
In that sense, publish is not the best word, either, as it describes
only the first two, but not the third case (and those are just examples;
there may be other setups beyond that, even).
Perhaps @{push} would be the most direct word.
Hmph, then the other one would be @{pull}.
Which does not sound too bad, IMHO.
--
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: error: src refspec refs/heads/master matches more than one.
On Tue, Feb 18, 2014 at 11:51:05AM -0800, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: There's already the arbitrary set of prefixes in refs.c::prettify_refname() and refs.c::ref_rev_parse_rules(). I can see how a user might think that since git log refs/heads/name is equivalent to git log master then git branch refs/heads/name should be equivalent to git branch name. Not quite, I am afraid. Branch names used for git branch name and git checkout name are like the Lvalue of an assignment, as opposed to extended SHA-1 expressions to express any commit (e.g. 'master^0', 'refs/heads/master', or 'master') that correspond to the Rvalues used in an expression. Because git checkout can take a branch name or an arbitrary commit object name, there needs a way for the users to disambiguate. Saying that git checkout refs/heads/name must be equivalent to git checkout name is like arguing that assignment value+0 = x should be valid because value+0 is a valid value. That isn't my argument. I agree that the create and view operations are distinct. The problem appears to be that not all users expect this and it caused them confusion because they are able to create refs like refs/heads/refs/heads/master. I don't think we should apply the mapping, but I also do not think that using a set of known (but arbitrary) constraints to prevent the creation of potentially confusing branch names is a particularly big leap from applying a similar set of rules in prettify_ref() and dwim_ref(). Especially if there's an escape hatch via '--force' or 'git update-ref' for those who know what they're doing. -- 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] Provide a 'git help user-manual' route to the docbook
Philip Oakley philipoak...@iee.org writes:
diff --git a/Documentation/gituser-manual.txt
b/Documentation/gituser-manual.txt
new file mode 100644
index 000..9fd4744
--- /dev/null
+++ b/Documentation/gituser-manual.txt
@@ -0,0 +1,34 @@
+gituser-manual(7)
+=
+
+NAME
+
+gituser-manual - a link to the user-manual docbook
+
+
+SYNOPSIS
+
+[verse]
+'git help user-manual'
+
+link:user-manual.html[Git User's Manual]
Is it just me, or is typing
$ git help user-manual
and not seeing the manual itself, but only a link you have to click
to get there a worthwhile addition?
I would not mind having a clickable link in the output from
$ git help git
or something that does already have other useful information, though.
+
+DESCRIPTION
+---
+Git is a fast, scalable, distributed revision control system with an
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+The link:user-manual.html[Git User's Manual] provides an
+in-depth introduction to Git.
+
+SEE ALSO
+
+linkgit:gittutorial[7],
+linkgit:giteveryday[7],
+linkgit:gitcli[7],
+linkgit:gitworkflows[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/builtin/help.c b/builtin/help.c
index 1fdefeb..be7c39d 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -427,6 +427,7 @@ static struct {
{ modules, N_(Defining submodule properties) },
{ revisions, N_(Specifying revisions and ranges for Git) },
{ tutorial, N_(A tutorial introduction to Git (for version 1.5.1 or
newer)) },
+ { user-manual, N_(A link to the user-manual docbook) },
{ workflows, N_(An overview of recommended workflows with Git) },
};
--
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] Fix documentation AsciiDoc links for external urls
Roberto Tyley roberto.ty...@gmail.com writes: Turns out that putting 'link:' before the 'http' is actually superfluous in AsciiDoc, as there's already a predefined macro to handle it. http, https, [etc] URLs are rendered using predefined inline macros. http://www.methods.co.nz/asciidoc/userguide.html#_urls Hypertext links to files on the local file system are specified using the link inline macro. http://www.methods.co.nz/asciidoc/userguide.html#_linking_to_local_documents Despite being superfluous, the reference implementation of AsciiDoc tolerates the extra 'link:' and silently removes it, giving a functioning link in the generated HTML. However, AsciiDoctor (the Ruby implementation of AsciiDoc used to render the http://git-scm.com/ site) does /not/ have this behaviour, and so generates broken links, as can be seen here: http://git-scm.com/docs/git-cvsimport (links to cvs2git parsecvs) http://git-scm.com/docs/git-filter-branch (link to The BFG) It's worth noting that after this change, the html generated by 'make html' in the git project is identical, and all links still work. --- Sign-off? The overall reasoning sounds good, and the patch also looks sensible. Thanks. Documentation/git-cvsimport.txt | 4 ++-- Documentation/git-filter-branch.txt | 4 ++-- Documentation/gitcore-tutorial.txt| 2 +- Documentation/gitcvs-migration.txt| 2 +- Documentation/gitweb.txt | 2 +- Documentation/technical/http-protocol.txt | 4 ++-- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 2df9953..260f39f 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -21,8 +21,8 @@ DESCRIPTION *WARNING:* `git cvsimport` uses cvsps version 2, which is considered deprecated; it does not work with cvsps version 3 and later. If you are performing a one-shot import of a CVS repository consider using -link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or -link:https://github.com/BartMassey/parsecvs[parsecvs]. +http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or +https://github.com/BartMassey/parsecvs[parsecvs]. Imports a CVS repository into Git. It will either create a new repository, or incrementally import into an existing one. diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 2eba627..09535f2 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -436,7 +436,7 @@ git-filter-branch allows you to make complex shell-scripted rewrites of your Git history, but you probably don't need this flexibility if you're simply _removing unwanted data_ like large files or passwords. For those operations you may want to consider -link:http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner], +http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner], a JVM-based alternative to git-filter-branch, typically at least 10-50x faster for those use-cases, and with quite different characteristics: @@ -455,7 +455,7 @@ characteristics: _is_ possible to write filters that include their own parallellism, in the scripts executed against each commit. -* The link:http://rtyley.github.io/bfg-repo-cleaner/#examples[command options] +* The http://rtyley.github.io/bfg-repo-cleaner/#examples[command options] are much more restrictive than git-filter branch, and dedicated just to the tasks of removing unwanted data- e.g: `--strip-blobs-bigger-than 1M`. diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 058a352..d2d7c21 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -1443,7 +1443,7 @@ Although Git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There is a nice illustration (page 17, Merges to Mainline) in -link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. +http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. It should be stressed that this hierarchy is purely *informal*. There is nothing fundamental in Git that enforces the chain of diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt index 5ea94cb..5f4e890 100644 --- a/Documentation/gitcvs-migration.txt +++ b/Documentation/gitcvs-migration.txt @@ -117,7 +117,7 @@ Importing a CVS archive --- First, install version 2.1 or higher of cvsps from -link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make +http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make sure it is in your path. Then cd to a checked out CVS working directory of the project you are
Question about the relationship between Star Wars and Git
Hi, Are git push and git pull based on force push and force pull from Star Wars? See: http://starwars.wikia.com/wiki/Telekinesis Also, is the --force option another reference to The Force? The similarity seems striking, especially when you realize that when you google force push you get Star Wars *and* Git related links. To me, Git usage represents one facet of being a Jedi and allows greater control of The Force present in your code and the internet. Upon meeting a fellow Git user, it is always immediately obvious that The Force is strong within this one. Respectfully, Jonathan Silverman -- 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] rev-parse: fix --resolve-git-dir argument handling
John Keeping j...@keeping.me.uk writes:
There are two problems here:
1) If no argument is provided, then the command segfaults
2) The argument is not consumed, so there will be excess output
Fix both of these in one go by restructuring the handler for this
option.
Reported-by: Daniel Hahler genml+git-2...@thequod.de
Signed-off-by: John Keeping j...@keeping.me.uk
---
Looks sensible; thanks.
builtin/rev-parse.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index aaeb611..645cc4a 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -738,9 +738,12 @@ int cmd_rev_parse(int argc, const char **argv, const
char *prefix)
continue;
}
if (!strcmp(arg, --resolve-git-dir)) {
- const char *gitdir = resolve_gitdir(argv[i+1]);
+ const char *gitdir;
+ if (++i = argc)
+ die(--resolve-git-dir requires an
argument);
+ gitdir = resolve_gitdir(argv[i]);
if (!gitdir)
- die(not a gitdir '%s', argv[i+1]);
+ die(not a gitdir '%s', argv[i]);
puts(gitdir);
continue;
}
--
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 gc --aggressive led to about 40 times slower git log --raw
Jonathan Nieder jrnie...@gmail.com writes:
David Kastrup wrote:
Duy Nguyen pclo...@gmail.com writes:
Likely because --aggressive passes --depth=250 to pack-objects. Long
delta chains could reduce pack size and increase I/O as well as zlib
processing signficantly.
[...]
Compression should reduce rather than increase the total amount of
reads.
--depth=250 means to allow chains of To get this object, first
inflate this object, then apply this delta of length 250.
That's absurdly long, and doesn't even help compression much in
practice (many short chains referring to the same objects tends to
work fine). We probably shouldn't make --aggressive do that.
Something like --depth=10 would make more sense.
Yes, my thinking indeed.
I didn't know --agressive was so aggressive myself, as I personally
never use it. git repack -a -d -f --depth=32 window=4000 is what I
often use, but I suspect most people would not be patient enough for
that 4k window.
Let's do something like this first and then later make --depth
configurable just like --width, perhaps? For aggressive, I think
the default width (hardcoded to 250 but configurable) is a bit too
narrow.
builtin/gc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 6be6c8d..0d010f0 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -204,7 +204,7 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (aggressive) {
argv_array_push(repack, -f);
- argv_array_push(repack, --depth=250);
+ argv_array_push(repack, --depth=20);
if (aggressive_window 0)
argv_array_pushf(repack, --window=%d,
aggressive_window);
}
--
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] diff: do not reuse_worktree_file for submodules
Thomas Rast t...@thomasrast.ch writes:
The GIT_EXTERNAL_DIFF calling code attempts to reuse existing worktree
files for the worktree side of diffs, for performance reasons.
However, that code also tries to do the same with submodules. This
results in calls to $GIT_EXTERNAL_DIFF where the old-file is a file of
the form Submodule commit $sha1, but the new-file is a directory in
the worktree.
Fix it by never reusing a worktree file in the submodule case.
Reported-by: Grégory Pakosz gregory.pak...@gmail.com
Signed-off-by: Thomas Rast t...@thomasrast.ch
---
diff.c | 5 +++--
t/t4020-diff-external.sh | 30 +-
2 files changed, 32 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 7c59bfe..e9a8874 100644
--- a/diff.c
+++ b/diff.c
@@ -2845,8 +2845,9 @@ static struct diff_tempfile *prepare_temp_file(const
char *name,
remove_tempfile_installed = 1;
}
- if (!one-sha1_valid ||
- reuse_worktree_file(name, one-sha1, 1)) {
+ if (!S_ISGITLINK(one-mode)
+ (!one-sha1_valid ||
+ reuse_worktree_file(name, one-sha1, 1))) {
I agree with the goal/end result, but I have to wonder if the
reuse_worktree_file() be the helper function that ought to
encapsulate such a logic?
Instead of feeding it an object name and a path, if we passed a
diff_filespec to the helper, it would have access to the mode as
well. It would result in a more intrusive change, so I'd prefer to
see your patch applied first and then build such a refactor on top,
perhaps like the attached.
diff.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/diff.c b/diff.c
index a96992a..74eec80 100644
--- a/diff.c
+++ b/diff.c
@@ -2582,11 +2582,13 @@ void fill_filespec(struct diff_filespec *spec, const
unsigned char *sha1,
* the work tree has that object contents, return true, so that
* prepare_temp_file() does not have to inflate and extract.
*/
-static int reuse_worktree_file(const char *name, const unsigned char *sha1,
int want_file)
+static int reuse_worktree_file(const struct diff_filespec *spec, int want_file)
{
const struct cache_entry *ce;
struct stat st;
int pos, len;
+ const char *name = spec-path;
+ const unsigned char *sha1 = spec-sha1;
/*
* We do not read the cache ourselves here, because the
@@ -2698,7 +2700,7 @@ int diff_populate_filespec(struct diff_filespec *s, int
size_only)
return diff_populate_gitlink(s, size_only);
if (!s-sha1_valid ||
- reuse_worktree_file(s-path, s-sha1, 0)) {
+ reuse_worktree_file(s, 0)) {
struct strbuf buf = STRBUF_INIT;
struct stat st;
int fd;
@@ -2844,17 +2846,17 @@ static struct diff_tempfile *prepare_temp_file(const
char *name,
if (!S_ISGITLINK(one-mode)
(!one-sha1_valid ||
-reuse_worktree_file(name, one-sha1, 1))) {
+reuse_worktree_file(one, 1))) {
struct stat st;
- if (lstat(name, st) 0) {
+ if (lstat(one-path, st) 0) {
if (errno == ENOENT)
goto not_a_valid_file;
- die_errno(stat(%s), name);
+ die_errno(stat(%s), one-path);
}
if (S_ISLNK(st.st_mode)) {
struct strbuf sb = STRBUF_INIT;
- if (strbuf_readlink(sb, name, st.st_size) 0)
- die_errno(readlink(%s), name);
+ if (strbuf_readlink(sb, one-path, st.st_size) 0)
+ die_errno(readlink(%s), one-path);
prep_temp_blob(name, temp, sb.buf, sb.len,
(one-sha1_valid ?
one-sha1 : null_sha1),
@@ -2864,7 +2866,7 @@ static struct diff_tempfile *prepare_temp_file(const char
*name,
}
else {
/* we can borrow from the file in the work tree */
- temp-name = name;
+ temp-name = one-path;
if (!one-sha1_valid)
strcpy(temp-hex, sha1_to_hex(null_sha1));
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
[PATCH v2 0/3] Allow to configure cherry-pick's record origin
The main motivation is to be able to configure repos that are used for maintaining backports/stable branches and not having to remember to use a special invocation of git cherry-pick. Changes from last version: * add --no-record-origin so scripts can make sure they'll never record a commit id * add --record-origin for symmetry with config file option and --no-record-origin * Add docs to git-config as well Guido Günther (3): revert.c: Allow to specify -x via git-config revert.c: Add --record-origin revert.c Allow to override cherrypick.recordOrigin Documentation/config.txt | 4 Documentation/git-cherry-pick.txt | 13 + builtin/revert.c | 22 -- 3 files changed, 37 insertions(+), 2 deletions(-) -- 1.9.0.rc3 -- 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 2/3] revert.c: Add --record-origin
This makes sure we have a command line option that corresponds with the
config file option.
---
Documentation/git-cherry-pick.txt | 1 +
builtin/revert.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index c0274bd..63db07d 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -57,6 +57,7 @@ OPTIONS
message prior to committing.
-x::
+--record-origin::
When recording the commit, append a line that says
(cherry picked from commit ...) to the original commit
message in order to indicate which commit this change was
diff --git a/builtin/revert.c b/builtin/revert.c
index 0c14af4..899f3e4 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -99,7 +99,7 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
if (opts-action == REPLAY_PICK) {
struct option cp_extra[] = {
- OPT_BOOL('x', NULL, opts-record_origin, N_(append
commit name)),
+ OPT_BOOL('x', record-origin, opts-record_origin,
N_(append commit name)),
OPT_BOOL(0, ff, opts-allow_ff, N_(allow
fast-forward)),
OPT_BOOL(0, allow-empty, opts-allow_empty,
N_(preserve initially empty commits)),
OPT_BOOL(0, allow-empty-message,
opts-allow_empty_message, N_(allow commits with empty messages)),
--
1.9.0.rc3
--
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 1/3] revert.c: Allow to specify -x via git-config
Without this when maintaining stable branches it's easy to forget to use
-x to track where a patch was cherry-picked from.
---
Documentation/config.txt | 4
Documentation/git-cherry-pick.txt | 8
builtin/revert.c | 14 +-
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5f4d793..a47d045 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -794,6 +794,10 @@ browser.tool.path::
browse HTML help (see '-w' option in linkgit:git-help[1]) or a
working repository in gitweb (see linkgit:git-instaweb[1]).
+cherrypick.recordOrigin::
+ When cherry picking patches record the sha1 of the original
+ commit in the commit message. Defaults to `false`.
+
clean.requireForce::
A boolean to make git-clean do nothing unless given -f,
-i or -n. Defaults to true.
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index c205d23..c0274bd 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -215,6 +215,14 @@ the working tree.
spending extra time to avoid mistakes based on incorrectly matching
context lines.
+CONFIGURATION
+-
+
+See linkgit:git-config[1] for core variables.
+
+cherrypick.recordOrigin::
+ Default for the `-x` option. Defaults to `false`.
+
SEE ALSO
linkgit:git-revert[1]
diff --git a/builtin/revert.c b/builtin/revert.c
index 87659c9..0c14af4 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -196,6 +196,18 @@ int cmd_revert(int argc, const char **argv, const char
*prefix)
return res;
}
+static int git_cherry_pick_config(const char *var, const char *value, void *cb)
+{
+ struct replay_opts *opts = cb;
+
+ if (!strcmp(var, cherrypick.recordorigin)) {
+ opts-record_origin = git_config_bool (var, value);
+ return 0;
+ } else {
+ return git_config(git_default_config, NULL);
+ }
+}
+
int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
struct replay_opts opts;
@@ -203,7 +215,7 @@ int cmd_cherry_pick(int argc, const char **argv, const char
*prefix)
memset(opts, 0, sizeof(opts));
opts.action = REPLAY_PICK;
- git_config(git_default_config, NULL);
+ git_config(git_cherry_pick_config, opts);
parse_args(argc, argv, opts);
res = sequencer_pick_revisions(opts);
if (res 0)
--
1.9.0.rc3
--
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 3/3] revert.c Allow to override cherrypick.recordOrigin
--no-record-origin can be used by scripts to be sure to not record
origin information when cherry-picking.
---
Documentation/git-cherry-pick.txt | 4
builtin/revert.c | 6 ++
2 files changed, 10 insertions(+)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index 63db07d..b063b76 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -58,6 +58,7 @@ OPTIONS
-x::
--record-origin::
+--no-record-origin::
When recording the commit, append a line that says
(cherry picked from commit ...) to the original commit
message in order to indicate which commit this change was
@@ -70,6 +71,9 @@ OPTIONS
maintenance branch for an older release from a
development branch), adding this information can be
useful.
++
+Use `--no-record-origin` if you want to avoid recording the commit id
+even when the `cherrypick.recordOrigin` option is in effect.
-r::
It used to be that the command defaulted to do `-x`
diff --git a/builtin/revert.c b/builtin/revert.c
index 899f3e4..14d90ba 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -76,6 +76,7 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
const char * const * usage_str = revert_or_cherry_pick_usage(opts);
const char *me = action_name(opts);
int cmd = 0;
+ int no_record_origin = 0;
struct option options[] = {
OPT_CMDMODE(0, quit, cmd, N_(end revert or cherry-pick
sequence), 'q'),
OPT_CMDMODE(0, continue, cmd, N_(resume revert or
cherry-pick sequence), 'c'),
@@ -95,11 +96,13 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
OPT_END(),
OPT_END(),
OPT_END(),
+ OPT_END(),
};
if (opts-action == REPLAY_PICK) {
struct option cp_extra[] = {
OPT_BOOL('x', record-origin, opts-record_origin,
N_(append commit name)),
+ OPT_BOOL(0, no-record-origin, no_record_origin,
N_(don't append commit name)),
OPT_BOOL(0, ff, opts-allow_ff, N_(allow
fast-forward)),
OPT_BOOL(0, allow-empty, opts-allow_empty,
N_(preserve initially empty commits)),
OPT_BOOL(0, allow-empty-message,
opts-allow_empty_message, N_(allow commits with empty messages)),
@@ -118,6 +121,9 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
if (opts-keep_redundant_commits)
opts-allow_empty = 1;
+ if (no_record_origin)
+ opts-record_origin = 0;
+
/* Set the subcommand */
if (cmd == 'q')
opts-subcommand = REPLAY_REMOVE_STATE;
--
1.9.0.rc3
--
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/2] tree-diff: rework diff_tree() to generate diffs for multiparent cases as well
Kirill Smelkov k...@navytux.spb.ru writes:
2) alloca(), for small arrays, is used for the same reason - if we change
it to xmalloc()/free() the timings get worse
Do you see any use of it outside compat/?
I thought we specifically avoid alloca() for portability. Also we
do not use variable-length-arrays on the stack either, I think.
No, no usage outside compat/ and I knew alloca and VLAs are not used in
Git codebase for portability, and I understand alloca will be
criticized, but wanted to start the discussion rolling.
I've actually started without alloca, and used xmalloc/free for
[nparent] vectors, but the impact was measurable, so it just had to be
changed to something more optimal.
For me, personally, alloca is ok, but I understand there could be
portability issues (by the way, what compiler/system Git cares about
does not have working alloca?). Thats why I propose we do the following
1. at configure time, determine, do we have working alloca, and define
#define HAVE_ALLOCA
if yes.
2. in code
#ifdef HAVE_ALLOCA
# define xalloca(size) (alloca(size))
# define xalloca_free(p)do {} while(0)
#else
# define xalloca(size) (xmalloc(size))
# define xalloca_free(p)(free(p))
#endif
and use it like
func() {
p = xalloca(size);
...
xalloca_free(p);
}
This way, for systems, where alloca is available, we'll have optimal
on-stack allocations with fast executions. On the other hand, on
systems, where alloca is not available, this gracefully fallbacks to
xmalloc/free.
Please tell me what you think.
I guess the above is clean enough, and we cannot do better than that,
if we want to use alloca() on platforms where we can.
--
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] Rename read_replace_refs to check_replace_refs
Michael Haggerty mhag...@alum.mit.edu writes: The semantics of this flag was changed in commit ecef23 inline lookup_replace_object() calls but wasn't renamed at the time to minimize code churn. Rename it now, and add a comment explaining its use. Signed-off-by: Michael Haggerty mhag...@alum.mit.edu --- This change doesn't conflict with anything in pu; perhaps we can squeeze it in now? I think it is a good time to do this kind of clean-up once the post-release dusts settle. 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
[PATCH] Fix documentation AsciiDoc links for external urls
Turns out that putting 'link:' before the 'http' is actually superfluous in AsciiDoc, as there's already a predefined macro to handle it. http, https, [etc] URLs are rendered using predefined inline macros. http://www.methods.co.nz/asciidoc/userguide.html#_urls Hypertext links to files on the local file system are specified using the link inline macro. http://www.methods.co.nz/asciidoc/userguide.html#_linking_to_local_documents Despite being superfluous, the reference implementation of AsciiDoc tolerates the extra 'link:' and silently removes it, giving a functioning link in the generated HTML. However, AsciiDoctor (the Ruby implementation of AsciiDoc used to render the http://git-scm.com/ site) does /not/ have this behaviour, and so generates broken links, as can be seen here: http://git-scm.com/docs/git-cvsimport (links to cvs2git parsecvs) http://git-scm.com/docs/git-filter-branch (link to The BFG) It's worth noting that after this change, the html generated by 'make html' in the git project is identical, and all links still work. Signed-off-by: Roberto Tyley roberto.ty...@gmail.com --- Documentation/git-cvsimport.txt | 4 ++-- Documentation/git-filter-branch.txt | 4 ++-- Documentation/gitcore-tutorial.txt| 2 +- Documentation/gitcvs-migration.txt| 2 +- Documentation/gitweb.txt | 2 +- Documentation/technical/http-protocol.txt | 4 ++-- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/Documentation/git-cvsimport.txt b/Documentation/git-cvsimport.txt index 2df9953..260f39f 100644 --- a/Documentation/git-cvsimport.txt +++ b/Documentation/git-cvsimport.txt @@ -21,8 +21,8 @@ DESCRIPTION *WARNING:* `git cvsimport` uses cvsps version 2, which is considered deprecated; it does not work with cvsps version 3 and later. If you are performing a one-shot import of a CVS repository consider using -link:http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or -link:https://github.com/BartMassey/parsecvs[parsecvs]. +http://cvs2svn.tigris.org/cvs2git.html[cvs2git] or +https://github.com/BartMassey/parsecvs[parsecvs]. Imports a CVS repository into Git. It will either create a new repository, or incrementally import into an existing one. diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt index 2eba627..09535f2 100644 --- a/Documentation/git-filter-branch.txt +++ b/Documentation/git-filter-branch.txt @@ -436,7 +436,7 @@ git-filter-branch allows you to make complex shell-scripted rewrites of your Git history, but you probably don't need this flexibility if you're simply _removing unwanted data_ like large files or passwords. For those operations you may want to consider -link:http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner], +http://rtyley.github.io/bfg-repo-cleaner/[The BFG Repo-Cleaner], a JVM-based alternative to git-filter-branch, typically at least 10-50x faster for those use-cases, and with quite different characteristics: @@ -455,7 +455,7 @@ characteristics: _is_ possible to write filters that include their own parallellism, in the scripts executed against each commit. -* The link:http://rtyley.github.io/bfg-repo-cleaner/#examples[command options] +* The http://rtyley.github.io/bfg-repo-cleaner/#examples[command options] are much more restrictive than git-filter branch, and dedicated just to the tasks of removing unwanted data- e.g: `--strip-blobs-bigger-than 1M`. diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 058a352..d2d7c21 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -1443,7 +1443,7 @@ Although Git is a truly distributed system, it is often convenient to organize your project with an informal hierarchy of developers. Linux kernel development is run this way. There is a nice illustration (page 17, Merges to Mainline) in -link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. +http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation]. It should be stressed that this hierarchy is purely *informal*. There is nothing fundamental in Git that enforces the chain of diff --git a/Documentation/gitcvs-migration.txt b/Documentation/gitcvs-migration.txt index 5ea94cb..5f4e890 100644 --- a/Documentation/gitcvs-migration.txt +++ b/Documentation/gitcvs-migration.txt @@ -117,7 +117,7 @@ Importing a CVS archive --- First, install version 2.1 or higher of cvsps from -link:http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make +http://www.cobite.com/cvsps/[http://www.cobite.com/cvsps/] and make sure it is in your path. Then cd to a checked out CVS working directory of the project you are interested in and run linkgit:git-cvsimport[1]: diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt index cca14b8..cd9c895 100644 --- a/Documentation/gitweb.txt +++
Re: error: src refspec refs/heads/master matches more than one.
David Kastrup d...@gnu.org writes: Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: + if (!force dwim_ref(name, strlen(name), sha1, real_ref)) + die(_(creating ref refs/heads/%s makes %s ambiguous.\n + Use -f to create it anyway.), + name, name); Does this check still allow you to create a branch refs/heads/next and then later create a branch next? The latter will introduce an ambiguity without any prevention, even though the prevention would trigger if the order in which these two branches are created is swapped--- the end result has ambiguity but the safety covers only one avenue to the confusing situation. And the only way I can think of to avoid that kind of confusion is to forbid creation of a subset of possible names by reserving a set of known (but arbitrary) prefixes---which I am not sure is a good way to go. At least not yet. Just for the record: after seeing the respective arguments, I consider it the sanest way. It's conceivable to give a configuration option for augmenting the set of reserved prefixes. That would allow to adapt the arbitrariness to match the policies or ref name choices of a particular project while keeping the set of references addressed by the standard git commands in check automagically. I am inclined to say that we should start by just giving a warning whenever git branch, git checkout -b, etc. tries to create a branch whose name begins with refs/ and other potentially ambiguous ones that match ref_rev_parse_rules[]. I personally do not think people name their branch with a name that begins with refs/ on purpose; I am not sure about other ones, like heads or tags. Personally I think it also is unlikely to want to have these words immediately followed by a slash in the branch name, so it may not even be necessary to give them any way to turn off the warning, which in turn would mean we can promote that warning to an die() that can be overridable with --force, but by going that first warn and see if people are annoyed route, we would hopefully find out soon enough that there may be some people who do want to name their branches in a funny way ;-) -- 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 release notes man page
Philip Oakley philipoak...@iee.org writes: A few days too late for the 1.9.0 release cycle :( This responds to Stefan Nwe's request for a 'git help' command that would access the release notes. ($gmane/240595 17 Jan 2014). I've used the full name release-notes for the help guide rather than Stefan's original 'git help relnotes'. The release-notes man page lists just the notes for the current release. The combined notes for all releases is nearing 15k lines. RelNotes are incremental and only useful for those who know what the immediately previous release contained, but for most people who get their Git from distros, I have this impression that the versions of Git they get skip versions, and seeing the notable changes since the previous source release will not give them wrong information---they may have this warm fuzzy feeling that they know what is going on, but they are missing information on all the accumulated changes that were added in earlier versions their distro skipped---these changes are still in the version they are running. I do not understand why it is even a good idea to show release notes from the command line git interface. -- 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] Provide a 'git help user-manual' route to the docbook
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
diff --git a/Documentation/gituser-manual.txt
b/Documentation/gituser-manual.txt
new file mode 100644
index 000..9fd4744
--- /dev/null
+++ b/Documentation/gituser-manual.txt
@@ -0,0 +1,34 @@
+gituser-manual(7)
+=
+
+NAME
+
+gituser-manual - a link to the user-manual docbook
+
+
+SYNOPSIS
+
+[verse]
+'git help user-manual'
+
+link:user-manual.html[Git User's Manual]
Is it just me, or is typing
$ git help user-manual
and not seeing the manual itself, but only a link you have to click
to get there a worthwhile addition?
It is a half-way house, partly because the current 'git help name'
processing always assumes that the target is a man page, and that the
page name will always be 'gitname. Thus the current user-manual isn't
immediately visible to the help system. Also it's not (quite reasonably)
formatted as a man page either.
This was an attempt to offer more ways for users to discover the
user-manual, as it would also be listed in the 'git help -g' output. To
make that work required a proper man-page, hence the patch. Also I was
avoiding the renaming of the user-manual.txt user-manual.html file
because of possible link breakages from external sources.
I would not mind having a clickable link in the output from
$ git help git
There is now a link within the git(1) page, though folk maybe leaping
past it to the list of commands and env variables, etc.
I'm generally in favour of providing more help sign-posting from more
directions where possible.
or something that does already have other useful information, though.
+
+DESCRIPTION
+---
+Git is a fast, scalable, distributed revision control system with an
+unusually rich command set that provides both high-level operations
+and full access to internals.
+
+The link:user-manual.html[Git User's Manual] provides an
+in-depth introduction to Git.
+
+SEE ALSO
+
+linkgit:gittutorial[7],
+linkgit:giteveryday[7],
+linkgit:gitcli[7],
+linkgit:gitworkflows[7]
+
+GIT
+---
+Part of the linkgit:git[1] suite
diff --git a/builtin/help.c b/builtin/help.c
index 1fdefeb..be7c39d 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -427,6 +427,7 @@ static struct {
{ modules, N_(Defining submodule properties) },
{ revisions, N_(Specifying revisions and ranges for Git) },
{ tutorial, N_(A tutorial introduction to Git (for version 1.5.1
or newer)) },
+ { user-manual, N_(A link to the user-manual docbook) },
{ workflows, N_(An overview of recommended workflows with
Git) },
};
--
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
--
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 gc --aggressive led to about 40 times slower git log --raw
On Wed, Feb 19, 2014 at 3:59 AM, Junio C Hamano gits...@pobox.com wrote:
Let's do something like this first and then later make --depth
configurable just like --width, perhaps? For aggressive, I think
the default width (hardcoded to 250 but configurable) is a bit too
narrow.
builtin/gc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 6be6c8d..0d010f0 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -204,7 +204,7 @@ int cmd_gc(int argc, const char **argv, const char
*prefix)
if (aggressive) {
argv_array_push(repack, -f);
- argv_array_push(repack, --depth=250);
+ argv_array_push(repack, --depth=20);
if (aggressive_window 0)
argv_array_pushf(repack, --window=%d,
aggressive_window);
}
Lower depth than default (50) does not sound aggressive to me, at
least from disk space utilization. I agree it should be configurable
though.
--
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 release notes man page
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: A few days too late for the 1.9.0 release cycle :( This responds to Stefan Nwe's request for a 'git help' command that would access the release notes. ($gmane/240595 17 Jan 2014). I've used the full name release-notes for the help guide rather than Stefan's original 'git help relnotes'. The release-notes man page lists just the notes for the current release. The combined notes for all releases is nearing 15k lines. RelNotes are incremental and only useful for those who know what the immediately previous release contained, but for most people who get their Git from distros, I have this impression that the versions of Git they get skip versions, and seeing the notable changes since the previous source release will not give them wrong information---they may have this warm fuzzy feeling that they know what is going on, but they are missing information on all the accumulated changes that were added in earlier versions their distro skipped---these changes are still in the version they are running. That's a reasonable argument. I did look at trying to get the stalenotes to work as an alternative, that is extract the stalenotes section from the git.txt, and create a release notes man page from that. However there were two issues there that I couldn't solve (noted in the cover letter). The first is that the man page generator does not expect more than 99 references so the link numbers repeat themselves. I'm sure that is fixable by someone who knows the insides of acsiidoc. The other was that the links for the main version documentation appear to been to be made at kernel.org, so that links back there are created. Again I wasn't sure how that should be resolved. I do not understand why it is even a good idea to show release notes from the command line git interface. My looking at this came from Stefan's suggestion noted above $gmane/240595. So it had at least one follower ;-) Philip -- -- 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 4/4] config: teach git config --file - to read from the standard input
The patch extends git config --file interface to allow read config from
stdin.
Editing stdin or setting value in stdin is an error.
Include by absolute path is allowed in stdin config, but not by relative
path.
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
builtin/config.c | 11 +++
cache.h | 1 +
config.c | 41 +++--
t/t1300-repo-config.sh| 17 +++--
t/t1305-config-include.sh | 16 +++-
5 files changed, 69 insertions(+), 17 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index de41ba50e9ca..5677c942b693 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -360,6 +360,9 @@ static int get_colorbool(int print)
static void check_write(void)
{
+ if (given_config_source.use_stdin)
+ die(writing to stdin is not supported);
+
if (given_config_source.blob)
die(writing config blobs is not supported);
}
@@ -472,6 +475,12 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
usage_with_options(builtin_config_usage,
builtin_config_options);
}
+ if (given_config_source.file
+ !strcmp(given_config_source.file, -)) {
+ given_config_source.file = NULL;
+ given_config_source.use_stdin = 1;
+ }
+
if (use_global_config) {
char *user_config = NULL;
char *xdg_config = NULL;
@@ -558,6 +567,8 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
check_argc(argc, 0, 0);
if (!given_config_source.file nongit)
die(not in a git directory);
+ if (given_config_source.use_stdin)
+ die(editing stdin is not supported);
if (given_config_source.blob)
die(editing blobs is not supported);
git_config(git_default_config, NULL);
diff --git a/cache.h b/cache.h
index 9d94bd69f7db..4db19b537059 100644
--- a/cache.h
+++ b/cache.h
@@ -1147,6 +1147,7 @@ extern int update_server_info(int);
#define CONFIG_GENERIC_ERROR 7
struct git_config_source {
+ unsigned int use_stdin:1;
const char *file;
const char *blob;
};
diff --git a/config.c b/config.c
index a21b0ddadecc..7b1febdf4af0 100644
--- a/config.c
+++ b/config.c
@@ -1031,24 +1031,35 @@ static int do_config_from(struct config_source *top,
config_fn_t fn, void *data)
return ret;
}
-int git_config_from_file(config_fn_t fn, const char *filename, void *data)
+static int do_config_from_file(config_fn_t fn,
+ const char *name, const char *path, FILE *f, void *data)
{
- int ret;
- FILE *f = fopen(filename, r);
+ struct config_source top;
- ret = -1;
- if (f) {
- struct config_source top;
+ top.u.file = f;
+ top.name = name;
+ top.path = path;
+ top.die_on_error = 1;
+ top.do_fgetc = config_file_fgetc;
+ top.do_ungetc = config_file_ungetc;
+ top.do_ftell = config_file_ftell;
- top.u.file = f;
- top.name = top.path = filename;
- top.die_on_error = 1;
- top.do_fgetc = config_file_fgetc;
- top.do_ungetc = config_file_ungetc;
- top.do_ftell = config_file_ftell;
+ return do_config_from(top, fn, data);
+}
- ret = do_config_from(top, fn, data);
+static int git_config_from_stdin(config_fn_t fn, void *data)
+{
+ return do_config_from_file(fn, stdin, NULL, stdin, data);
+}
+
+int git_config_from_file(config_fn_t fn, const char *filename, void *data)
+{
+ int ret = -1;
+ FILE *f;
+ f = fopen(filename, r);
+ if (f) {
+ ret = do_config_from_file(fn, filename, filename, f, data);
fclose(f);
}
return ret;
@@ -1190,7 +1201,9 @@ int git_config_with_options(config_fn_t fn, void *data,
* If we have a specific filename, use it. Otherwise, follow the
* regular lookup sequence.
*/
- if (config_source config_source-file)
+ if (config_source config_source-use_stdin)
+ return git_config_from_stdin(fn, data);
+ else if (config_source config_source-file)
return git_config_from_file(fn, config_source-file, data);
else if (config_source config_source-blob)
return git_config_from_blob_ref(fn, config_source-blob, data);
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 967359344dab..c9c426c273e5 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -475,15 +475,28 @@ ein.bahn=strasse
EOF
test_expect_success 'alternative GIT_CONFIG' '
- GIT_CONFIG=other-config git config -l output
+ GIT_CONFIG=other-config git config --list output
test_cmp expect output
'
[PATCH 2/4] builtin/config.c: rename check_blob_write() - check_write()
The function will be reused to check for other conditions which prevent
write.
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
builtin/config.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index 92ebf23f0a9a..a7c55e68883c 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -362,7 +362,7 @@ static int get_colorbool(int print)
return get_colorbool_found ? 0 : 1;
}
-static void check_blob_write(void)
+static void check_write(void)
{
if (given_config_blob)
die(writing config blobs is not supported);
@@ -572,7 +572,7 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
}
else if (actions == ACTION_SET) {
int ret;
- check_blob_write();
+ check_write();
check_argc(argc, 2, 2);
value = normalize_value(argv[0], argv[1]);
ret = git_config_set_in_file(given_config_file, argv[0], value);
@@ -582,21 +582,21 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
return ret;
}
else if (actions == ACTION_SET_ALL) {
- check_blob_write();
+ check_write();
check_argc(argc, 2, 3);
value = normalize_value(argv[0], argv[1]);
return git_config_set_multivar_in_file(given_config_file,
argv[0], value, argv[2],
0);
}
else if (actions == ACTION_ADD) {
- check_blob_write();
+ check_write();
check_argc(argc, 2, 2);
value = normalize_value(argv[0], argv[1]);
return git_config_set_multivar_in_file(given_config_file,
argv[0], value, ^$, 0);
}
else if (actions == ACTION_REPLACE_ALL) {
- check_blob_write();
+ check_write();
check_argc(argc, 2, 3);
value = normalize_value(argv[0], argv[1]);
return git_config_set_multivar_in_file(given_config_file,
@@ -623,7 +623,7 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
return get_urlmatch(argv[0], argv[1]);
}
else if (actions == ACTION_UNSET) {
- check_blob_write();
+ check_write();
check_argc(argc, 1, 2);
if (argc == 2)
return
git_config_set_multivar_in_file(given_config_file,
@@ -633,14 +633,14 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
argv[0], NULL);
}
else if (actions == ACTION_UNSET_ALL) {
- check_blob_write();
+ check_write();
check_argc(argc, 1, 2);
return git_config_set_multivar_in_file(given_config_file,
argv[0], NULL, argv[1],
1);
}
else if (actions == ACTION_RENAME_SECTION) {
int ret;
- check_blob_write();
+ check_write();
check_argc(argc, 2, 2);
ret = git_config_rename_section_in_file(given_config_file,
argv[0], argv[1]);
@@ -651,7 +651,7 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
}
else if (actions == ACTION_REMOVE_SECTION) {
int ret;
- check_blob_write();
+ check_write();
check_argc(argc, 1, 1);
ret = git_config_rename_section_in_file(given_config_file,
argv[0], NULL);
--
1.9.0.rc3
--
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 1/4] config: disallow relative include paths from blobs
From: Jeff King p...@peff.net
When we see a relative config include like:
[include]
path = foo
we make it relative to the containing directory of the file
that contains the snippet. This makes no sense for config
read from a blob, as it is not on the filesystem. Something
like HEAD:some/path could have a relative path within the
tree, but:
1. It would not be part of include.path, which explicitly
refers to the filesystem.
2. It would need different parsing rules anyway to
determine that it is a tree path.
The current code just uses the name field, which is wrong.
Let's split that into name and path fields, use the
latter for relative includes, and fill in only the former
for blobs.
Signed-off-by: Jeff King p...@peff.net
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
config.c | 10 ++
t/t1305-config-include.sh | 16
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/config.c b/config.c
index d969a5aefc2b..b295310d3c22 100644
--- a/config.c
+++ b/config.c
@@ -21,6 +21,7 @@ struct config_source {
} buf;
} u;
const char *name;
+ const char *path;
int die_on_error;
int linenr;
int eof;
@@ -97,12 +98,12 @@ static int handle_path_include(const char *path, struct
config_include_data *inc
if (!is_absolute_path(path)) {
char *slash;
- if (!cf || !cf-name)
+ if (!cf || !cf-path)
return error(relative config includes must come from
files);
- slash = find_last_dir_sep(cf-name);
+ slash = find_last_dir_sep(cf-path);
if (slash)
- strbuf_add(buf, cf-name, slash - cf-name + 1);
+ strbuf_add(buf, cf-path, slash - cf-path + 1);
strbuf_addstr(buf, path);
path = buf.buf;
}
@@ -1040,7 +1041,7 @@ int git_config_from_file(config_fn_t fn, const char
*filename, void *data)
struct config_source top;
top.u.file = f;
- top.name = filename;
+ top.name = top.path = filename;
top.die_on_error = 1;
top.do_fgetc = config_file_fgetc;
top.do_ungetc = config_file_ungetc;
@@ -1062,6 +1063,7 @@ int git_config_from_buf(config_fn_t fn, const char *name,
const char *buf,
top.u.buf.len = len;
top.u.buf.pos = 0;
top.name = name;
+ top.path = NULL;
top.die_on_error = 0;
top.do_fgetc = config_buf_fgetc;
top.do_ungetc = config_buf_ungetc;
diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index a70707620f14..6edd38b39a0b 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -122,6 +122,22 @@ test_expect_success 'relative includes from command line
fail' '
test_must_fail git -c include.path=one config test.one
'
+test_expect_success 'absolute includes from blobs work' '
+ echo [test]one = 1 one
+ echo [include]path=$(pwd)/one blob
+ blob=$(git hash-object -w blob)
+ echo 1 expect
+ git config --blob=$blob test.one actual
+ test_cmp expect actual
+'
+
+test_expect_success 'relative includes from blobs fail' '
+ echo [test]one = 1 one
+ echo [include]path=one blob
+ blob=$(git hash-object -w blob)
+ test_must_fail git config --blob=$blob test.one
+'
+
test_expect_success 'include cycles are detected' '
cat .gitconfig -\EOF
[test]value = gitconfig
--
1.9.0.rc3
--
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 3/4] config: change git_config_with_options() interface
We're going to have more options for config source.
Let's alter git_config_with_options() interface to accept struct with
all source options.
Signed-off-by: Kirill A. Shutemov kir...@shutemov.name
---
builtin/config.c | 75 ++--
cache.h | 8 --
config.c | 13 +-
3 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index a7c55e68883c..de41ba50e9ca 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -21,8 +21,7 @@ static char key_delim = ' ';
static char term = '\n';
static int use_global_config, use_system_config, use_local_config;
-static const char *given_config_file;
-static const char *given_config_blob;
+static struct git_config_source given_config_source;
static int actions, types;
static const char *get_color_slot, *get_colorbool_slot;
static int end_null;
@@ -55,8 +54,8 @@ static struct option builtin_config_options[] = {
OPT_BOOL(0, global, use_global_config, N_(use global config file)),
OPT_BOOL(0, system, use_system_config, N_(use system config file)),
OPT_BOOL(0, local, use_local_config, N_(use repository config
file)),
- OPT_STRING('f', file, given_config_file, N_(file), N_(use given
config file)),
- OPT_STRING(0, blob, given_config_blob, N_(blob-id), N_(read
config from given blob object)),
+ OPT_STRING('f', file, given_config_source.file, N_(file), N_(use
given config file)),
+ OPT_STRING(0, blob, given_config_source.blob, N_(blob-id),
N_(read config from given blob object)),
OPT_GROUP(N_(Action)),
OPT_BIT(0, get, actions, N_(get value: name [value-regex]),
ACTION_GET),
OPT_BIT(0, get-all, actions, N_(get all values: key
[value-regex]), ACTION_GET_ALL),
@@ -224,8 +223,7 @@ static int get_value(const char *key_, const char *regex_)
}
git_config_with_options(collect_config, values,
- given_config_file, given_config_blob,
- respect_includes);
+ given_config_source, respect_includes);
ret = !values.nr;
@@ -309,8 +307,7 @@ static void get_color(const char *def_color)
get_color_found = 0;
parsed_color[0] = '\0';
git_config_with_options(git_get_color_config, NULL,
- given_config_file, given_config_blob,
- respect_includes);
+ given_config_source, respect_includes);
if (!get_color_found def_color)
color_parse(def_color, command line, parsed_color);
@@ -339,8 +336,7 @@ static int get_colorbool(int print)
get_diff_color_found = -1;
get_color_ui_found = -1;
git_config_with_options(git_get_colorbool_config, NULL,
- given_config_file, given_config_blob,
- respect_includes);
+ given_config_source, respect_includes);
if (get_colorbool_found 0) {
if (!strcmp(get_colorbool_slot, color.diff))
@@ -364,7 +360,7 @@ static int get_colorbool(int print)
static void check_write(void)
{
- if (given_config_blob)
+ if (given_config_source.blob)
die(writing config blobs is not supported);
}
@@ -435,7 +431,7 @@ static int get_urlmatch(const char *var, const char *url)
}
git_config_with_options(urlmatch_config_entry, config,
- given_config_file, NULL, respect_includes);
+ given_config_source, respect_includes);
for_each_string_list_item(item, values) {
struct urlmatch_current_candidate_value *matched = item-util;
@@ -464,14 +460,14 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
int nongit = !startup_info-have_repository;
char *value;
- given_config_file = getenv(CONFIG_ENVIRONMENT);
+ given_config_source.file = getenv(CONFIG_ENVIRONMENT);
argc = parse_options(argc, argv, prefix, builtin_config_options,
builtin_config_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
if (use_global_config + use_system_config + use_local_config +
- !!given_config_file + !!given_config_blob 1) {
+ !!given_config_source.file + !!given_config_source.blob 1) {
error(only one config file at a time.);
usage_with_options(builtin_config_usage,
builtin_config_options);
}
@@ -493,24 +489,24 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
if (access_or_warn(user_config, R_OK, 0)
xdg_config !access_or_warn(xdg_config, R_OK, 0))
- given_config_file = xdg_config;
+ given_config_source.file = xdg_config;
else
-
Re: [PATCH] config: teach git config --file - to read from the standard input
Junio C Hamano gits...@pobox.com writes:
I think I preferred the earlier version where you had stdin in the
name field, and this hunk could just go away. I know you switched it to
NULL here to avoid making bogus relative filenames in includes.
Exactly the same comment here. I really like the way how this
series becomes more polished every time we see it.
But that would be pretty straightforward to fix by splitting the name
field into an additional path field. It looks like git config --blob
has the same problem (it will try relative lookups in the filesystem,
even though that is nonsensical from the blob). So we could fix the
existing bug at the same time. :)
Perhaps this could go at the start of your series?
Sounds like the right thing to do.
Thanks.
And [PATCH 3/3] rebased on the others may look like this.
builtin/config.c | 11 +++
cache.h | 1 +
config.c | 42 --
t/t1300-repo-config.sh| 17 +++--
t/t1305-config-include.sh | 16 +++-
5 files changed, 70 insertions(+), 17 deletions(-)
diff --git a/builtin/config.c b/builtin/config.c
index de41ba5..5677c94 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -360,6 +360,9 @@ static int get_colorbool(int print)
static void check_write(void)
{
+ if (given_config_source.use_stdin)
+ die(writing to stdin is not supported);
+
if (given_config_source.blob)
die(writing config blobs is not supported);
}
@@ -472,6 +475,12 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
usage_with_options(builtin_config_usage,
builtin_config_options);
}
+ if (given_config_source.file
+ !strcmp(given_config_source.file, -)) {
+ given_config_source.file = NULL;
+ given_config_source.use_stdin = 1;
+ }
+
if (use_global_config) {
char *user_config = NULL;
char *xdg_config = NULL;
@@ -558,6 +567,8 @@ int cmd_config(int argc, const char **argv, const char
*prefix)
check_argc(argc, 0, 0);
if (!given_config_source.file nongit)
die(not in a git directory);
+ if (given_config_source.use_stdin)
+ die(editing stdin is not supported);
if (given_config_source.blob)
die(editing blobs is not supported);
git_config(git_default_config, NULL);
diff --git a/cache.h b/cache.h
index 9d94bd6..4db19b5 100644
--- a/cache.h
+++ b/cache.h
@@ -1147,6 +1147,7 @@ extern int update_server_info(int);
#define CONFIG_GENERIC_ERROR 7
struct git_config_source {
+ unsigned int use_stdin:1;
const char *file;
const char *blob;
};
diff --git a/config.c b/config.c
index a21b0dd..9dd0bdb 100644
--- a/config.c
+++ b/config.c
@@ -1031,24 +1031,36 @@ static int do_config_from(struct config_source *top,
config_fn_t fn, void *data)
return ret;
}
-int git_config_from_file(config_fn_t fn, const char *filename, void *data)
+static int do_config_from_file(config_fn_t fn,
+ const char *filename, FILE *f,
+ const char *label, void *data)
{
- int ret;
- FILE *f = fopen(filename, r);
+ struct config_source top;
- ret = -1;
- if (f) {
- struct config_source top;
+ top.u.file = f;
+ top.name = label;
+ top.path = filename;
+ top.die_on_error = 1;
+ top.do_fgetc = config_file_fgetc;
+ top.do_ungetc = config_file_ungetc;
+ top.do_ftell = config_file_ftell;
+
+ return do_config_from(top, fn, data);
+}
- top.u.file = f;
- top.name = top.path = filename;
- top.die_on_error = 1;
- top.do_fgetc = config_file_fgetc;
- top.do_ungetc = config_file_ungetc;
- top.do_ftell = config_file_ftell;
+static int git_config_from_stdin(config_fn_t fn, void *data)
+{
+ return do_config_from_file(fn, NULL, stdin, stdin, data);
+}
- ret = do_config_from(top, fn, data);
+int git_config_from_file(config_fn_t fn, const char *filename, void *data)
+{
+ int ret = -1;
+ FILE *f;
+ f = fopen(filename, r);
+ if (f) {
+ ret = do_config_from_file(fn, filename, f, filename, data);
fclose(f);
}
return ret;
@@ -1190,7 +1202,9 @@ int git_config_with_options(config_fn_t fn, void *data,
* If we have a specific filename, use it. Otherwise, follow the
* regular lookup sequence.
*/
- if (config_source config_source-file)
+ if (config_source config_source-use_stdin)
+ return git_config_from_stdin(fn, data);
+ else if (config_source config_source-file)
Re: [PATCH] Git release notes man page
Junio C Hamano gits...@pobox.com writes: Philip Oakley philipoak...@iee.org writes: A few days too late for the 1.9.0 release cycle :( This responds to Stefan Nwe's request for a 'git help' command that would access the release notes. ($gmane/240595 17 Jan 2014). I've used the full name release-notes for the help guide rather than Stefan's original 'git help relnotes'. The release-notes man page lists just the notes for the current release. The combined notes for all releases is nearing 15k lines. RelNotes are incremental and only useful for those who know what the immediately previous release contained, but for most people who get their Git from distros, I have this impression that the versions of Git they get skip versions, and seeing the notable changes since the previous source release will not give them wrong information---they Ehh,, s/will not give them/will give them/; obviously... may have this warm fuzzy feeling that they know what is going on, but they are missing information on all the accumulated changes that were added in earlier versions their distro skipped---these changes are still in the version they are running. I do not understand why it is even a good idea to show release notes from the command line git interface. -- 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: [RFC/PATCH] Supporting non-blob notes
On Tue, Feb 18, 2014 at 9:46 PM, Johan Herland jo...@herland.net wrote: On Mon, Feb 17, 2014 at 11:48 AM, yann.dir...@bertin.fr wrote: The recent git-note -C changes commit type? thread (http://thread.gmane.org/gmane.comp.version-control.git/241950) looks like a good occasion to discuss possible uses of non-blob notes. The use-case we're thinking about is the storage of testrun logs as notes (think: being able to justify that a given set of tests were successfully run on a given revision). I think this is a good use of notes, and organizing the testrun logs into a tree of files seems like a natural way to proceed. Notes from the previous attempt to store trees as notes (something to watch out maybe, when you do it again) http://article.gmane.org/gmane.comp.version-control.git/197712 -- 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-contacts: do not fail parsing of good diffs
lar...@gullik.org (Lars Gullik Bjønnes) writes:
If a line in a patch starts with --- it will be deemed
malformed unless it also contains the proper diff header
format. This situation can happen with a valid patch if
it has a line starting with -- and that line is removed.
This patch just removes the check in git-contacts.
Signed-off-by: Lars Gullik Bjønnes lar...@gullik.org
---
If the script wanted to be more correct, it should be paying
attention to the $len it already parses out of the hunk headers to
make sure it does not mistake removal of a line that begins with --
as the beginning of a patch to a different path, but as the
original does not seem to aim to be so careful anyway, this change
should be OK, I would say.
The patch was whitespace damaged, by the way. It was easy to hand
tweak so there is no need to resend this particular patch, but if
you are planning to send more patches, please check your MUA and
tell it not to.
Thanks.
contrib/contacts/git-contacts | 2 --
1 file changed, 2 deletions(-)
diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
index 428cc1a..dbe2abf 100755
--- a/contrib/contacts/git-contacts
+++ b/contrib/contacts/git-contacts
@@ -96,8 +96,6 @@ sub scan_patches {
next unless $id;
if (m{^--- (?:a/(.+)|/dev/null)$}) {
$source = $1;
- } elsif (/^--- /) {
- die Cannot parse hunk source: $_\n;
} elsif (/^@@ -(\d+)(?:,(\d+))?/ $source) {
my $len = defined($2) ? $2 : 1;
push @{$sources-{$source}{$id}}, [$1, $len] if $len;
--
1.9.0
--
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 5/5] streaming: simplify attaching a filter
John Keeping j...@keeping.me.uk writes:
We are guaranteed that 'nst' is non-null because it is allocated with
xmalloc(), and in fact we rely on this three lines later by
unconditionally dereferencing it.
The intent of the original code is for attach_stream_filter() to
detect an error condition and return NULL, in which case it closes
the istream it allocated and signal error to the caller, I think,
and falling thru to use st-anything and return st when that happens
is *not* a guarantee that a-s-f will not detect an error ever, but
rather is a bug in the error codepath.
Signed-off-by: John Keeping j...@keeping.me.uk
---
streaming.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/streaming.c b/streaming.c
index d7c9f32..8a7135d 100644
--- a/streaming.c
+++ b/streaming.c
@@ -151,10 +151,7 @@ struct git_istream *open_istream(const unsigned char
*sha1,
}
if (filter) {
/* Add !is_null_stream_filter(filter) for performance */
- struct git_istream *nst = attach_stream_filter(st, filter);
- if (!nst)
- close_istream(st);
- st = nst;
+ st = attach_stream_filter(st, filter);
}
*size = st-size;
--
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 5/5] streaming: simplify attaching a filter
Junio C Hamano gits...@pobox.com writes:
John Keeping j...@keeping.me.uk writes:
We are guaranteed that 'nst' is non-null because it is allocated with
xmalloc(), and in fact we rely on this three lines later by
unconditionally dereferencing it.
The intent of the original code is for attach_stream_filter() to
detect an error condition and return NULL, in which case it closes
the istream it allocated and signal error to the caller, I think,
and falling thru to use st-anything and return st when that happens
is *not* a guarantee that a-s-f will not detect an error ever, but
rather is a bug in the error codepath.
In other words, something like this instead.
-- 8 --
Subject: [PATCH] open_istream(): do not dereference NULL in the error case
When stream-filter cannot be attached, it is expected to return NULL,
and we should close the stream we opened and signal an error by
returning NULL ourselves from this function.
However, we attempted to dereference that NULL pointer between the
point we detected the error and returned from the function.
Brought-to-attention-by: John Keeping j...@keeping.me.uk
Signed-off-by: Junio C Hamano gits...@pobox.com
---
streaming.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/streaming.c b/streaming.c
index d7c9f32..2ff036a 100644
--- a/streaming.c
+++ b/streaming.c
@@ -152,8 +152,10 @@ struct git_istream *open_istream(const unsigned char *sha1,
if (filter) {
/* Add !is_null_stream_filter(filter) for performance */
struct git_istream *nst = attach_stream_filter(st, filter);
- if (!nst)
+ if (!nst) {
close_istream(st);
+ return NULL;
+ }
st = nst;
}
--
1.9.0-279-gdc9e3eb
--
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 gc --aggressive led to about 40 times slower git log --raw
Duy Nguyen pclo...@gmail.com writes: Lower depth than default (50) does not sound aggressive to me, at least from disk space utilization. I agree it should be configurable though. Do you mean you want to keep --aggressive to mean too aggressive in resulting size, to the point that it is not useful to anybody? Shallow and wide will give us, with a large window, the most aggressively efficient packfiles that are useful, and we would rather want to fix it to be usable, I would think. -- 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] rev-parse: fix --resolve-git-dir argument handling
Junio C Hamano gits...@pobox.com writes: John Keeping j...@keeping.me.uk writes: There are two problems here: 1) If no argument is provided, then the command segfaults 2) The argument is not consumed, so there will be excess output Fix both of these in one go by restructuring the handler for this option. Reported-by: Daniel Hahler genml+git-2...@thequod.de Signed-off-by: John Keeping j...@keeping.me.uk --- Looks sensible; thanks. Ehh, I spoke too fast. Don't we already have this queued as a43219f2 (rev-parse: check i before using argv[i] against argc, 2014-01-28)? -- 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/3] introduce GIT_INDEX_VERSION environment variable
Thomas Gummerer t.gumme...@gmail.com writes:
diff --git a/Documentation/git.txt b/Documentation/git.txt
index aec3726..bc9eeea 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -712,6 +712,11 @@ Git so take care if using Cogito etc.
index file. If not specified, the default of `$GIT_DIR/index`
is used.
+'GIT_INDEX_VERSION'::
+ This environment variable allows the specification of an index
+ version for new repositories. It won't affect existing index
+ files. By default index file version 3 is used.
+
This is half-correct, isn't it? In-code variable may say version 3
but we demote it to version 2 unless we absolutely need to use the
version 3 ugliness.
diff --git a/read-cache.c b/read-cache.c
index 3f735f3..3993e12 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1223,6 +1223,22 @@ static struct cache_entry *refresh_cache_entry(struct
cache_entry *ce, int reall
#define INDEX_FORMAT_DEFAULT 3
+static unsigned int get_index_format_default()
+{
+ char *envversion = getenv(GIT_INDEX_VERSION);
+ if (!envversion) {
+ return INDEX_FORMAT_DEFAULT;
+ } else {
+ unsigned int version = strtol(envversion, NULL, 10);
If we are using strtol() to parse it carefully, we should make sure
it parses to the end by giving a non-NULL second argument and
checking where the parsing stopped.
diff --git a/t/t1600-index.sh b/t/t1600-index.sh
new file mode 100755
index 000..37fd84d
--- /dev/null
+++ b/t/t1600-index.sh
@@ -0,0 +1,24 @@
+#!/bin/sh
+
+test_description='index file specific tests'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ echo 1 a
+'
+
+test_expect_success 'out of bounds GIT_INDEX_VERSION issues warning' '
+ (
+ GIT_INDEX_VERSION=1
+ export GIT_INDEX_VERSION
+ git add a 21 | sed s/[0-9]// actual.err
+ sed -e s/ Z$/ / -\EOF expect.err
+ warning: GIT_INDEX_VERSION set, but the value is
invalid.
+ Using version Z
+ EOF
+ test_i18ncmp expect.err actual.err
+ )
+'
If we already have an index in version N when this test starts, what
should happen?
Will queue on 'pu', with some suggested fixups.
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 2/3] test-lib: allow setting the index format version
Thomas Gummerer t.gumme...@gmail.com writes: Allow adding a TEST_GIT_INDEX_VERSION variable to config.mak to set the index version with which the test suite should be run. ... diff --git a/Makefile b/Makefile index 287e6f8..c98d28f 100644 --- a/Makefile +++ b/Makefile @@ -342,6 +342,10 @@ all:: # Define DEFAULT_HELP_FORMAT to man, info or html # (defaults to man) if you want to have a different default when # git help is called without a parameter specifying the format. +# +# Define TEST_GIT_INDEX_FORMAT to 2, 3 or 4 to run the test suite s/_FORMAT/_VERSION/, I would think. Will queue on 'pu' with a fix-up on top. 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: git gc --aggressive led to about 40 times slower git log --raw
On Wed, Feb 19, 2014 at 7:10 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: Lower depth than default (50) does not sound aggressive to me, at least from disk space utilization. I agree it should be configurable though. Do you mean you want to keep --aggressive to mean too aggressive in resulting size, to the point that it is not useful to anybody? git-gc.txt is pretty vague about this --aggressive. I assume we would want both, better disk utilization and performance. But if it produces a tiny pack that takes forever to access, then it's definitely bad aggression. Shallow and wide will give us, with a large window, the most aggressively efficient packfiles that are useful, and we would rather want to fix it to be usable, I would think. fwiw this is the thread that added --depth=250 http://thread.gmane.org/gmane.comp.gcc.devel/94565/focus=94626 yes, if reducing depth leads to better performance and does not use much disk in general case, then of course we should do it. General case may be hard to define though. It'd be best if we have some sort of heuristics to try out different combinations on a specific repo and return the best combination of parameters. It could even take longer time, but once we have good parameters, they should remain good for a long time, I think. -- 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
