* Re: [RFD] My thoughts about implementing gitweb output caching
From: Jakub Narebski @ 2011-01-08 11:44 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, J.H., John 'Warthog9' Hawley
In-Reply-To: <20110108002643.GD15495@burratino>
On Sat, 8 Jan 2011, Jonathan Nieder wrote:
>
> [...] A few uninformed reactions.
Thanks for your comments.
> Jakub Narebski wrote:
>
> > There was request to support installing gitweb modules in a separate
> > directory, but that would require changes to "gitweb: Prepare for
> > splitting gitweb" patch (but it is doable). Is there wider interest
> > in supporting such feature?
>
> If you are referring to my suggestion, I see no reason to wait on
> that. The lib/ dir can be made configurable later.
You are right. Thanks for sanity check. Though I'd prefer that we get
it right from the first time.
For the record, the changes to support configurable gitweblibdir are:
gitweb/Makefile:
----------------
gitweblibdir_SQ = $(subst ','\'',$(gitwebdir)/lib)#'
to
gitweblibdir ?= $(gitwebdir)/lib
...
gitweblibdir_SQ = $(subst ','\'',$(gitweblibdir))#'
GITWEB_REPLACE = \
...
-e 's|++GITWEBLIBDIR++|$(gitweblibdir)|g' \
gitweb/gitweb.perl:
-------------------
# __DIR__ is taken from Dir::Self __DIR__ fragment
sub __DIR__ () {
File::Spec->rel2abs(join '', (File::Spec->splitpath(__FILE__))[0, 1]);
}
use lib __DIR__ . '/lib';
to
use lib $ENV{'GITWEBLIBDIR'} || "++GITWEBLIBDIR++";
or something like that
t/gitweb-lib.sh:
----------------
gitweb_run () {
...
GITWEBLIBDIR="$GIT_BUILD_DIR/gitweb/lib"
export GITWEBLIBDIR
or the change to gitweb config in gitweb_init()
> > Simplest solution is to use $cgi->self_url() (note that what J.H. v8
> > uses, i.e.: "$my_url?". $ENV{'QUERY_STRING'}, where $my_url is just
> > $cgi->url() is not enough - it doesn't take path_info into account).
> >
> > Alternate solution, which I used in my rewrite, is to come up with
> > "canonical" URL, e.g. href(-replay => 1, -full => 1, -path_info => 0);
> > with this solution using path_info vs query parameters or reordering
> > query parameters still gives the same key.
>
> It is easy to miss dependencies on parts of the URL that are being
> fuzzed out. For example, the <base href...> tag is only inserted with
> path_info. Maybe it would be less risky to first use self_url(), then
> canonicalize it in a separate patch?
You are right; it is only in the latest version of my rewrite that
I remembered that <base href=...> must be added also when caching is
enabled (c.f. using always "text/html" content type when caching is
enabled).
> > J.H. patches up and including v7, and my rewrite up and including v6,
> > excluded error pages from caching. I think that the original resoning
> > behind choosing to do it this way was that A.), each of specific error
> > pages is usually accessed only once, so caching them would only take up
> > space bloating cache, but what is more important B.) that you can't
> > cache errors from caching engine.
>
> Perhaps there is a user experience reason? If I receive an error page
> due to a problem with my repository, all else being equal, I would
> prefer that the next time I reload it is fixed. By comparison, having
> to reload multiple times to forget an obsolete non-error response
> would be less aggravating and perhaps expected.
True, there are errors that are transient (e.g. load too high), there are
errors that need webmaster / admin intervention (e.g. no disk space, or
cache permissions problem), and there are errors that are not fixable
(e.g. page not found).
> But the benefit from caching e.g. a response from a broken link would
> outweigh that.
The problem is _only_ if there is progress info indicator for set.
The issue you mentioned might be solved if we are able to set cache
expiration time individually (perhaps with the hint from within gitweb),
e.g. by using the fact that we cache HTTP response which can include
'Expires:' or 'Cache-Control: max-age=' header... or by manipulating
mtime.
> > Second is if there is no stale data to serve (or data is too stale), but
> > we have progress indicator. In this case the foreground process is
> > responsible for rendering progress indicator, and background process is
> > responsible for generating data. In this case foreground process waits
> > for data to be generated (unless progress info subroutine exits), so
> > strictly spaking we don't need to detach background process in this
> > case.
>
> What happens when the client gets tired of waiting and closes the
> connection?
Hmmm... I don't know what happens to worker in non-persistent (CGI),
wrapped persistent (mod_perl via ModPerl::Registry, PSGI via gitweb.psgi)
and persistent (FastCGI) environments. Well, detaching also in the case
of background generation because of progress_info wouldn't hurt, and
could help...
Thanks again for your comments.
Hoping to hear from J,H. soon...
--
Jakub Narebski
Poland
^ permalink raw reply
* Creating CVS-style patch headers with git-diff
From: David Chanters @ 2011-01-08 11:23 UTC (permalink / raw)
To: git; +Cc: David Chanters
Hi all,
[ Please Cc me on any replies as I am not subscribed to this list, thanks. ]
I am wondering if I can get git diff to create "CVS-style patches"?
What do I mean by that? Well, whenever I do:
git diff
I get patch headers in the form:
diff --git a/foo.c b/foo.c
index 57b9527..a2d947b 100644
--- a/foo.c
+++ b/foo.c
This is fine for git, but if I then want to import the same patch into
CVS I have to either edit the patch, or mess around with the -p option
to patch(1).
I have seen that git-diff has options to change the a/ b/ headers --
can anyone shed some light on this as to what I can do?
The reason I am wanting to do this, is rather than importing
changesets from git -> CVS, I have a git clone outright of a CVS
project (which I update with git-cvsimport) and often want to import
diffs to CVS directly after I'm done, and then I publish my topic
branches in Git when I'm done. The key thing though is to be able to
apply patches from git -- and I am hoping the easiest thing to do is
to try and get git-diff to change the headers.
Any help greatly received.
Kindly,
David
^ permalink raw reply
* Re: [RFD] My thoughts about implementing gitweb output caching
From: Jakub Narebski @ 2011-01-08 11:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jonathan Nieder, git, J.H., John 'Warthog9' Hawley
In-Reply-To: <alpine.LFD.2.00.1101072142550.22191@xanadu.home>
Nicolas Pitre wrote:
> On Fri, 7 Jan 2011, Jonathan Nieder wrote:
> > Jakub Narebski wrote:
> > > With output caching gitweb can also support 'Range' requests, which
> > > means that it would support resumable download. This would mean hat we
> > > would be able to resume downloading of snapshot (or in the future
> > > bundle)... if we cannot do this now. This would require some more code
> > > to be added.
> >
> > Exciting stuff.
> >
> > Teaching gitweb to generate bundles sounds like a recipe for high server
> > loads, though. I suspect manual (or by cronjob) generation would work
> > better, with a possible exception of very frequently cloned and
> > infrequently pushed-to repos like linus's linux-2.6.
>
> Even for Linus' linux repo, it is not a good idea to auto create bundle,
> except maybe once every major release which is every 3 months or so. I
> really don't think this is a good idea to put this in the realm of
> gitweb caching.
You are right, making gitweb aware of bundles (if they are put in some
specified place, e.g. .git/objects/pack or .git/objects/bundle) is I guess
a better idea than allowing for gitweb to generate bundles, perhaps
only if caching is enabled, and perhaps with very long expiration time.
Of course the standard way should be also the standard place for git
clients to find bundles in proposed extension to git-clone.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] commit: suggest --amend --reset-author to fix commiter identity
From: Matthieu Moy @ 2011-01-08 10:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjx45w7g.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I don't think making the "cheat-sheet" insn longer by offering more
> choices is a good idea. These are messages for lazy and busy
> people.
The reason I kept both forms was that the message is designed to be
seen once (or once for each new machine one works on), and the most
scary it is, the most efficient ;-).
> Wouldn't it work better to just get rid of the longer form and say
> something like:
>
> ... here is how to tell your name to git (existing message) ...
>
> After doing the above, run
>
> git commit --amend --reset-author
>
> to fix the identity used for this commit.
I'm fine with that proposal too. I'll resend with that if no one
objects. Probalby rewording it to
After doing this, you can fix the identity used for this commit with:
git commit --amend --reset-author
would make it even concisier (no break of the sentence with a
command).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [RFC/PATCH] t9157-*.sh: Add an svn version check
From: Anders Kaseorg @ 2011-01-08 9:19 UTC (permalink / raw)
To: Ramsay Jones; +Cc: git, Junio C Hamano, stevenrwalter, normalperson
In-Reply-To: <4D260A03.90903@ramsay1.demon.co.uk>
On Thu, 2011-01-06 at 18:29 +0000, Ramsay Jones wrote:
> +svn_ver="$(svn --version --quiet)"
> +case $svn_ver in
> +[0-1].[0-4].[0-6])
Thanks for the patch. Can I suggest the more precise
0.* | 1.[0-4].*)
Anders
^ permalink raw reply
* [PATCH] Avoid unportable nested double- and backquotes in shell scripts.
From: Ralf Wildenhues @ 2011-01-08 9:01 UTC (permalink / raw)
To: git
Some shells parse them wrongly, esp. pdksh. On the other hand,
the right-hand side of assignments is not word-split, so they
can be used as workarounds.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
contrib/examples/git-fetch.sh | 2 +-
t/t9107-git-svn-migrate.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/examples/git-fetch.sh b/contrib/examples/git-fetch.sh
index a314273..06caf6b 100755
--- a/contrib/examples/git-fetch.sh
+++ b/contrib/examples/git-fetch.sh
@@ -67,7 +67,7 @@ do
keep='-k -k'
;;
--depth=*)
- shallow_depth="--depth=`expr "z$1" : 'z-[^=]*=\(.*\)'`"
+ shallow_depth=--depth=`expr "z$1" : 'z-[^=]*=\(.*\)'`
;;
--depth)
shift
diff --git a/t/t9107-git-svn-migrate.sh b/t/t9107-git-svn-migrate.sh
index 289fc31..3d2ae3e 100755
--- a/t/t9107-git-svn-migrate.sh
+++ b/t/t9107-git-svn-migrate.sh
@@ -94,7 +94,7 @@ test_expect_success 'migrate --minimize on old inited layout' '
echo "$svnrepo"$path > "$GIT_DIR"/svn/$ref/info/url ) || exit 1;
done &&
git svn migrate --minimize &&
- test -z "`git config -l | grep "^svn-remote\.git-svn\."`" &&
+ ! git config -l | grep "^svn-remote\.git-svn\." &&
git config --get-all svn-remote.svn.fetch > fetch.out &&
grep "^trunk:refs/remotes/trunk$" fetch.out &&
grep "^branches/a:refs/remotes/a$" fetch.out &&
--
1.7.4.rc1
^ permalink raw reply related
* Re: different name and email address depending on folder
From: Ramkumar Ramachandra @ 2011-01-08 8:29 UTC (permalink / raw)
To: Rich Eakin; +Cc: git
In-Reply-To: <A1770B45-1A98-49C3-8CD0-C61A51FFB66E@gmail.com>
Hi Rich,
Rich Eakin writes:
> I am currently using git-config in a bash script to set my user / email. I was wondering if it was possible to tell git that if I am in a certain directory to use a specific user / email other than what is in my global config.
It's possible on a per-repository basis, as I pointed out in the last
email; but no- I don't think it's possible on a per-directory basis
within the same repository. You might consider separting your private
work from your company's repository.
p.s- I think you've used the term "global" incorrectly here. Global
configuration applies to all repositories. Per-repository
configuration overrides the global configuration for that repository.
-- Ram
^ permalink raw reply
* Re: different name and email address depending on folder
From: Rich Eakin @ 2011-01-08 8:16 UTC (permalink / raw)
To: Ramkumar Ramachandra, git
In-Reply-To: <20110108073928.GD27334@kytes>
I am currently using git-config in a bash script to set my user / email. I was wondering if it was possible to tell git that if I am in a certain directory to use a specific user / email other than what is in my global config.
On 08/01/2011, at 6:39 PM, Ramkumar Ramachandra wrote:
> Hi Rich,
>
> Rich Eakin writes:
>> I am using git for development with a company and myself on the same computer and the name / user fields need to be different for each. As I keep all my company's repos in one directory and my private stuff in another, I was wondering if there is a way to tell git to use a separate user and email whenever I make commits from within a specified directory.
>
> Yes. Please see the 'user.name' and 'user.email' configuration options
> in git-config(1). You can set them globally or on a per-repository
> basis.
>
> -- Ram
^ permalink raw reply
* [PATCH] Introduce new configuation option to override committer information
From: Ramkumar Ramachandra @ 2011-01-08 8:03 UTC (permalink / raw)
To: Git Mailing List; +Cc: Stephen Kelly, Thomas Rast, Erik Faye-Lund
In-Reply-To: <ig73o1$lbg$1@dough.gmane.org>
Currently, there is no way to set committer information on a
per-repository basis. The 'user.name' and 'user.email' configuration
options set both author and committer information. To solve this,
introduce 'user.committername' and 'user.committeremail' configuration
options to override committer name and email respectively.
Reported-by: Stephen Kelly <steveire@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
---
Documentation/config.txt | 29 +++++++++++++++++++++++------
builtin/blame.c | 2 +-
builtin/commit.c | 4 ++--
cache.h | 4 +++-
config.c | 15 +++++++++++++++
environment.c | 2 ++
ident.c | 18 ++++++++++++------
7 files changed, 58 insertions(+), 16 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 6a6c0b5..5405a4c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1842,14 +1842,31 @@ url.<base>.pushInsteadOf::
setting for that remote.
user.email::
- Your email address to be recorded in any newly created commits.
- Can be overridden by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and
- 'EMAIL' environment variables. See linkgit:git-commit-tree[1].
+ The email address to be recorded in any newly created commits.
+ Sets both author and committer email. To override only
+ committer email, use 'user.committeremail'. Can be overridden
+ by the 'GIT_AUTHOR_EMAIL', 'GIT_COMMITTER_EMAIL', and 'EMAIL'
+ environment variables. See linkgit:git-commit-tree[1].
user.name::
- Your full name to be recorded in any newly created commits.
- Can be overridden by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME'
- environment variables. See linkgit:git-commit-tree[1].
+ The full name to be recorded in any newly created commits.
+ Sets both author and committer name. To override only
+ committer name, use 'user.committername'. Can be overridden
+ by the 'GIT_AUTHOR_NAME' and 'GIT_COMMITTER_NAME' environment
+ variables. See linkgit:git-commit-tree[1].
+
+user.committeremail::
+ The email address of the committer to use while recording
+ newly created commits. Used to override committer email
+ specified in 'user.email'. Can be overridden by the
+ 'GIT_COMMITTER_EMAIL', and 'EMAIL' environment variables. See
+ linkgit:git-commit-tree[1].
+
+user.committername::
+ The full name of the committer to use while recording newly
+ created commits. Used to override committer name specified in
+ 'user.name'. Can be overridden by the 'GIT_COMMITTER_NAME'
+ environment variable. See linkgit:git-commit-tree[1].
user.signingkey::
If linkgit:git-tag[1] is not selecting the key you want it to
diff --git a/builtin/blame.c b/builtin/blame.c
index f5fccc1..1f47130 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2146,7 +2146,7 @@ static struct commit *fake_working_tree_commit(struct diff_options *opt,
cache_tree_invalidate_path(active_cache_tree, path);
commit->buffer = xmalloc(400);
- ident = fmt_ident("Not Committed Yet", "not.committed.yet", NULL, 0);
+ ident = fmt_ident("Not Committed Yet", "not.committed.yet", NULL, 0, 0);
snprintf(commit->buffer, 400,
"tree 0000000000000000000000000000000000000000\n"
"parent %s\n"
diff --git a/builtin/commit.c b/builtin/commit.c
index 4fd1a16..a449a13 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1352,8 +1352,8 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
}
if (commit_tree(sb.buf, active_cache_tree->sha1, parents, commit_sha1,
- fmt_ident(author_name, author_email, author_date,
- IDENT_ERROR_ON_NO_NAME))) {
+ fmt_ident(author_name, author_email, author_date,
+ 0, IDENT_ERROR_ON_NO_NAME))) {
rollback_index_files();
die("failed to write commit object");
}
diff --git a/cache.h b/cache.h
index 33decd9..91740c0 100644
--- a/cache.h
+++ b/cache.h
@@ -833,7 +833,7 @@ enum date_mode parse_date_format(const char *format);
#define IDENT_NO_DATE 4
extern const char *git_author_info(int);
extern const char *git_committer_info(int);
-extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int);
+extern const char *fmt_ident(const char *name, const char *email, const char *date_str, int, int);
extern const char *fmt_name(const char *name, const char *email);
extern const char *git_editor(void);
extern const char *git_pager(int stdout_is_tty);
@@ -1008,6 +1008,8 @@ extern const char *config_exclusive_filename;
#define MAX_GITNAME (1000)
extern char git_default_email[MAX_GITNAME];
extern char git_default_name[MAX_GITNAME];
+extern char git_default_committeremail[MAX_GITNAME];
+extern char git_default_committername[MAX_GITNAME];
#define IDENT_NAME_GIVEN 01
#define IDENT_MAIL_GIVEN 02
#define IDENT_ALL_GIVEN (IDENT_NAME_GIVEN|IDENT_MAIL_GIVEN)
diff --git a/config.c b/config.c
index c63d683..ba130dc 100644
--- a/config.c
+++ b/config.c
@@ -665,6 +665,21 @@ static int git_default_user_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "user.committername")) {
+ if (!value)
+ return config_error_nonbool(var);
+ strlcpy(git_default_committername, value,
+ sizeof(git_default_committername));
+ return 0;
+ }
+
+ if (!strcmp(var, "user.committeremail")) {
+ if (!value)
+ return config_error_nonbool(var);
+ strlcpy(git_default_committeremail, value,
+ sizeof(git_default_committeremail));
+ return 0;
+ }
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index de5581f..1277764 100644
--- a/environment.c
+++ b/environment.c
@@ -11,6 +11,8 @@
char git_default_email[MAX_GITNAME];
char git_default_name[MAX_GITNAME];
+char git_default_committeremail[MAX_GITNAME];
+char git_default_committername[MAX_GITNAME];
int user_ident_explicitly_given;
int trust_executable_bit = 1;
int trust_ctime = 1;
diff --git a/ident.c b/ident.c
index 9e24388..b3dcaaa 100644
--- a/ident.c
+++ b/ident.c
@@ -183,7 +183,7 @@ static const char *env_hint =
"\n";
const char *fmt_ident(const char *name, const char *email,
- const char *date_str, int flag)
+ const char *date_str, int committer_info, int flag)
{
static char buffer[1000];
char date[50];
@@ -193,9 +193,15 @@ const char *fmt_ident(const char *name, const char *email,
int name_addr_only = (flag & IDENT_NO_DATE);
setup_ident();
- if (!name)
+ if (committer_info) {
+ if (!name)
+ name = git_default_committername;
+ if (!email)
+ email = git_default_committeremail;
+ }
+ if (!name || !*name)
name = git_default_name;
- if (!email)
+ if (!email || !*email)
email = git_default_email;
if (!*name) {
@@ -237,7 +243,7 @@ const char *fmt_ident(const char *name, const char *email,
const char *fmt_name(const char *name, const char *email)
{
- return fmt_ident(name, email, NULL, IDENT_ERROR_ON_NO_NAME | IDENT_NO_DATE);
+ return fmt_ident(name, email, NULL, 0, IDENT_ERROR_ON_NO_NAME | IDENT_NO_DATE);
}
const char *git_author_info(int flag)
@@ -245,7 +251,7 @@ const char *git_author_info(int flag)
return fmt_ident(getenv("GIT_AUTHOR_NAME"),
getenv("GIT_AUTHOR_EMAIL"),
getenv("GIT_AUTHOR_DATE"),
- flag);
+ 0, flag);
}
const char *git_committer_info(int flag)
@@ -257,7 +263,7 @@ const char *git_committer_info(int flag)
return fmt_ident(getenv("GIT_COMMITTER_NAME"),
getenv("GIT_COMMITTER_EMAIL"),
getenv("GIT_COMMITTER_DATE"),
- flag);
+ 1, flag);
}
int user_ident_sufficiently_given(void)
--
1.7.2.2.409.gdbb11.dirty
^ permalink raw reply related
* Re: different name and email address depending on folder
From: Ramkumar Ramachandra @ 2011-01-08 7:39 UTC (permalink / raw)
To: Rich Eakin; +Cc: git
In-Reply-To: <3178E076-FA22-4C3C-BEB2-2581A0E12086@gmail.com>
Hi Rich,
Rich Eakin writes:
> I am using git for development with a company and myself on the same computer and the name / user fields need to be different for each. As I keep all my company's repos in one directory and my private stuff in another, I was wondering if there is a way to tell git to use a separate user and email whenever I make commits from within a specified directory.
Yes. Please see the 'user.name' and 'user.email' configuration options
in git-config(1). You can set them globally or on a per-repository
basis.
-- Ram
^ permalink raw reply
* Re: [BUG] git rev-list --no-walk A B C sorts by commit date incorrectly
From: Kevin Ballard @ 2011-01-08 5:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vk4ig7y0t.fsf@alter.siamese.dyndns.org>
On Jan 7, 2011, at 9:41 PM, Junio C Hamano wrote:
> Kevin Ballard <kevin@sb.org> writes:
>
>> It almost works, but not quite. My inclination is to say
>> `git rev-list --no-walk A B C` should emit A B C in that order. Implemented
>> this way, `git rev-list --no-walk ^HEAD~3 HEAD` emits commits in the wrong
>> order,
>
> "git rev-list --no-walk ^HEAD~3 HEAD"? Isn't it a nonsense? If it is "no
> walk", then why do you even list a negative one?
That seemed odd to me too, but t3508 tests to make sure git cherry-pick accepts
that syntax. Specifically it tests `git cherry-pick ^first fourth`. It does
make a certain sense, though; it should be (and, I believe, is) equivalent to
saying `git rev-list --no-walk HEAD~3..HEAD`, though I don't know if it's
handled the same internally.
> As to cherry-pick, I wouldn't be surprised if it relies on the current
> internal working of pushing commits in the date order to the queue
> regardless of how they were given from the command line.
My belief is that it doesn't. It sets the reverse flag, so it gets the oldest
commit first. I think it's always just been tested taking commits in the same
order that they were committed, which seems fine except when two commits have
the same date. In that case, if A and B have the same date, then A B C will
get transformed to B A C. It's possible that this one quirk can be fixed by
changing the date test in commit_list_insert_by_date to use <= instead of <,
but that still leaves the issue where `git cherry-pick A B C` will sort those
commits even if the user explicitly wanted to apply them in the given order.
I suspect this just wasn't noticed before because cherry-pick didn't used to
accept multiple commits, and after that support was added, nobody's tried to
cherry-pick commits in a different order than they were committed.
> Indeed, it does exactly that, and then tries to compensate it---notice
> that builtin/revert.c:prepare_revs() gives "revs->reverse" to it. That
> also needs to be fixed.
I did see that, I just left it out of my explanation.
-Kevin Ballard
^ permalink raw reply
* Re: [BUG] git rev-list --no-walk A B C sorts by commit date incorrectly
From: Junio C Hamano @ 2011-01-08 5:41 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git list
In-Reply-To: <BB84A2F6-E6B0-49E4-9DC7-6BA8860623E6@sb.org>
Kevin Ballard <kevin@sb.org> writes:
> It almost works, but not quite. My inclination is to say
> `git rev-list --no-walk A B C` should emit A B C in that order. Implemented
> this way, `git rev-list --no-walk ^HEAD~3 HEAD` emits commits in the wrong
> order,
"git rev-list --no-walk ^HEAD~3 HEAD"? Isn't it a nonsense? If it is "no
walk", then why do you even list a negative one?
As to cherry-pick, I wouldn't be surprised if it relies on the current
internal working of pushing commits in the date order to the queue
regardless of how they were given from the command line.
Indeed, it does exactly that, and then tries to compensate it---notice
that builtin/revert.c:prepare_revs() gives "revs->reverse" to it. That
also needs to be fixed.
^ permalink raw reply
* Re: [BUG] git rev-list --no-walk A B C sorts by commit date incorrectly
From: Kevin Ballard @ 2011-01-08 3:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v62u043ba.fsf@alter.siamese.dyndns.org>
On Jan 7, 2011, at 5:00 PM, Junio C Hamano wrote:
> Kevin Ballard <kevin@sb.org> writes:
>
>> Is there any rationale for this behavior?
>
> Not a rationale, but an explanation is that most of the time we walk the
> history and sorting by date is the first thing that needs to be done, and
> the --no-walk option was an afterthought that was tucked in.
>
> I suspect that a three-liner patch to revision.c:prepare_revision_walk()
> would give you what you want. Instead of calling insert-by-date, you
> append to the tail when revs->no_walk is given, or something.
It almost works, but not quite. My inclination is to say
`git rev-list --no-walk A B C` should emit A B C in that order. Implemented
this way, `git rev-list --no-walk ^HEAD~3 HEAD` emits commits in the wrong
order, and I can't figure out how to change that. If I implement
`git rev-list --no-walk A B C` to emit C B A instead, then the test for
`git cherry-pick --stdin` fails (t3508), and I don't know why.
-Kevin Ballard
^ permalink raw reply
* Re: [RFD] My thoughts about implementing gitweb output caching
From: Nicolas Pitre @ 2011-01-08 2:46 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jakub Narebski, git, J.H., John 'Warthog9' Hawley
In-Reply-To: <20110108002643.GD15495@burratino>
On Fri, 7 Jan 2011, Jonathan Nieder wrote:
> > With output caching gitweb can also support 'Range' requests, which
> > means that it would support resumable download. This would mean hat we
> > would be able to resume downloading of snapshot (or in the future
> > bundle)... if we cannot do this now. This would require some more code
> > to be added.
>
> Exciting stuff.
>
> Teaching gitweb to generate bundles sounds like a recipe for high server
> loads, though. I suspect manual (or by cronjob) generation would work
> better, with a possible exception of very frequently cloned and
> infrequently pushed-to repos like linus's linux-2.6.
Even for Linus' linux repo, it is not a good idea to auto create bundle,
except maybe once every major release which is every 3 months or so. I
really don't think this is a good idea to put this in the realm of
gitweb caching.
Nicolas
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Nguyen Thai Ngoc Duy @ 2011-01-08 2:40 UTC (permalink / raw)
To: Maaartin-1; +Cc: git
In-Reply-To: <4D27B828.8020108@seznam.cz>
On Sat, Jan 8, 2011 at 8:04 AM, Maaartin-1 <grajcar1@seznam.cz> wrote:
>> Listing all those commits in linux-2.6.git takes 160k*20=3M (I suppose
>> compressing is useless because SHA-1 is random). A compressed listing
>> of those 46k paths takes 200k.
>
> Sure, Linux has only 4 times as much commits as paths, but the commits
> need 30 times more storage. What does it tell us?
>
> IMHO it speaks in favor of my proposal. Imagine a path changing with
> nearly every commit. The root directory is such a path and near top
> directories come close to (as may other files like todo-lists do). For
> each such file you need 3MB for storing the commits SHAs only. Of
> course, you can invent a schema making storing all the SHAs unnecessary,
> but this is another complication.
>
> OTOH, with the commits used as directory entries we get quite a large
> directory. Is this a problem you wanted me to get aware of?
I merely point out that if we use commit sha-1 as "pieces". Then when
a new peer comes in and ask a running peer "what pieces have you got
(so that I can start fetching from you)?", you will need more
bandwidth for that kind of information.
>> The point is you need to fetch its parent commits first in order to
>> verify a commit. Fetching a whole commit is more expensive than a
>> file. So while you can fetch a few commit bases and request for packs
>> from those bases in parallel, the cost of initial commit bases will be
>> high.
>
> You've lost me. I assume you mean that something like that there may be
> very large commits (e.g., in a project not versioned from the very
> beginning). I'd suggest to split such commits in two parts by
> classifying the blobs (and trees) using a fixed bit of their SHAs. Of
> course, this can be repeated in order to get even smaller parts. Let's
> assume a commit X gets split into X0 and X1. As before, for compressing
> of X0 you may use the content any predecessor of X. For compressing of
> X0 you may additionally use the content of X0. This way the compression
> rate could stay close to optimal, IMHO.
Well if you are going to split a commit, then splitting by paths
sounds more natural to me (assume that people don't often move files).
>> They are interchangeable as a whole, yes. But you cannot fetch half
>> the pack from server A and the other half from server B. You can try
>> to recover as many deltas as possible in a broken pack, but how do you
>> request a server to send the rest of the pack to you?
>
> Indeed, it's not resumable. For most commits it's not needed since they
> are very small. Why? There are more commits than paths, so the commits
> are smaller than paths on the average. I expect my schema to allow for
> nearly as good compression as git usually does, especially I'd hope it's
> no worse than when packing paths.
A commit diff consists of all tree and blobs diff compared to the
parent commit (let's ignore merges). How can it be smaller than just a
single tree/blob diff (of the same path, compared to the parent
commit)?
> However, there may be very large commits in my schema (and maybe also
> very large "path-packs" in yours). Such large commits get split as I
> described above. Small commits get paired (possibly multiple times) as I
> described earlier. You end up with only reasonably sized pieces of data,
> let's say between 256 and 512 kB, so you don't need to resume.
Yeah, I started thinking how to transfer effieciently and I came to
similar thing: assume we have good order of packing and know what to
pack, then we close the pack when its size is greater than a limit and
start sending another pack. If this pack stream is corrupt, resume
from the corrupt pack forward. I currently hardcode the limit 4k, not
greater because pack overhead is very low already (12 header bytes and
20 sha1 trailer bytes each pack).
> Actually, with a really bad connection, you could ask the very server
> from which you obtained an incomplete pack to resume from a given byte
> offset (similar to HTTP ranges). The server may or may not have it. This
> time it should try to keep it available for you in case you connections
> abort again. Don't get me wrong -- this is just an additional help for
> very badly connected people.
Replace "byte range" with rev-list syntax (SHA1~10..SHA1-20) then we
have quite fine-grained way of asking for data. Deltas are usually
very small (I observed cache.h only so this could be a wrong
assumption). But if SHA1~10..SHA1~11 has too big diff that keeps
failing, sending byte ranges of the blob in SHA1~11 is probably the
only way left.
--
Duy
^ permalink raw reply
* Re: debugging git clone via git-daemon "cannot handle daemon internally"
From: John Griessen @ 2011-01-08 2:37 UTC (permalink / raw)
To: git
In-Reply-To: <20110107234210.GB15495@burratino>
On 01/07/2011 05:42 PM, Jonathan Nieder wrote:
> Perhaps you have inetd set up to try to run git with argv[0] set
> to git-daemon? git-daemon (daemon.c) has its own "main" so it
> would take something of that nature to produce this symptom.
Hmm.. My debian server has no control for inetd in /etc/init.d/
so I rebooted it to see if anything is different. I was using an
inetd entry before... maybe it was still running when I did that test.
After reboot:
--------------
john@toolbench:~/FABprojects/VRBO_apt$ telnet mail.cibolo.us 9418
Trying 76.191.252.85...
Connected to mail.cibolo.us.
Escape character is '^]'.
Connection closed by foreign host.
-----------------
So, the symptom changed. No "cannot handle daemon internally" response.
Your powers of deduction are equal to any nefarious Moriarty-like character
out there it seems!
I'll test further soon.
JG
--
Ecosensory Austin TX
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Nguyen Thai Ngoc Duy @ 2011-01-08 2:17 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <AANLkTikKn1+2OX1KPy+9US_yX=E6+CiaCTTB6yqnAWwW@mail.gmail.com>
On Fri, Jan 7, 2011 at 10:59 PM, Luke Kenneth Casson Leighton
<luke.leighton@gmail.com> wrote:
> bottom line: my take on this is (sorry to say, nguyen) that i don't
> believe bittorrent "pieces" map well to the chains concept, unless the
> chains are perfectly fixed identical sizes [which they could well be?
> am i mistaken about this?]
there are a few characteristics of bittorrent pieces that i see:
verifiable, resumable, uniquely identifiable across peers and
reasonbly small in count.
The fixed size helps peers uniquely identify any pieces by splitting
the whole transfer equally and indexing them in 1-dimension. It's a
rule to help identify pieces, not the only valid rule. In git, given a
commit SHA-1 we can identify any parts (or "pieces") that are
reachable from that commit using rev-list syntax. Therefore the
"identifiable" characteristics still holds even we don't split in
fixed size pieces.
--
Duy
^ permalink raw reply
* Re: Resumable clone/Gittorrent (again)
From: Maaartin-1 @ 2011-01-08 1:04 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <AANLkTikXcrZqhCw+2u2HObUZz5QCStY6BCHTTYYfngMN@mail.gmail.com>
On 11-01-06 07:36, Nguyen Thai Ngoc Duy wrote:
> On Thu, Jan 6, 2011 at 10:34 AM, Maaartin-1 <grajcar1@seznam.cz> wrote:
>> In theory, I could create many commits per seconds. I could create many
>> unique paths per seconds, too. But I don't think it really happens. I do
>> know no larger repository than git.git and I don't want to download it
>> just to see how many commits, paths, and object it contains, but I'd
>> suppose it's less than one million commits, which should be manageable,
>> especially when commits get grouped together as I described below.
>
> In pratice, commits are created every day in an active project. Paths
> on the other hand are added less often (perhaps except webkit).
>
> I've got some numbers:
>
> - wine.git has 72k commits, 260k trees, 200k blobs, 12k paths
> - git.git has 24k commits, 39k trees, 24k blobs, 2.7k paths
> - linux-2.6.git has 160k commits, 760k trees, 442k blobs, 46k paths
>
> Large repos are more interesting because small ones can be cloned with
> git-clone.
Sure. Linux is the winner and has 4 times as much commits as paths.
> Listing all those commits in linux-2.6.git takes 160k*20=3M (I suppose
> compressing is useless because SHA-1 is random). A compressed listing
> of those 46k paths takes 200k.
Sure, Linux has only 4 times as much commits as paths, but the commits
need 30 times more storage. What does it tell us?
IMHO it speaks in favor of my proposal. Imagine a path changing with
nearly every commit. The root directory is such a path and near top
directories come close to (as may other files like todo-lists do). For
each such file you need 3MB for storing the commits SHAs only. Of
course, you can invent a schema making storing all the SHAs unnecessary,
but this is another complication.
OTOH, with the commits used as directory entries we get quite a large
directory. Is this a problem you wanted me to get aware of?
> The point is you need to fetch its parent commits first in order to
> verify a commit. Fetching a whole commit is more expensive than a
> file. So while you can fetch a few commit bases and request for packs
> from those bases in parallel, the cost of initial commit bases will be
> high.
You've lost me. I assume you mean that something like that there may be
very large commits (e.g., in a project not versioned from the very
beginning). I'd suggest to split such commits in two parts by
classifying the blobs (and trees) using a fixed bit of their SHAs. Of
course, this can be repeated in order to get even smaller parts. Let's
assume a commit X gets split into X0 and X1. As before, for compressing
of X0 you may use the content any predecessor of X. For compressing of
X0 you may additionally use the content of X0. This way the compression
rate could stay close to optimal, IMHO.
> They are interchangeable as a whole, yes. But you cannot fetch half
> the pack from server A and the other half from server B. You can try
> to recover as many deltas as possible in a broken pack, but how do you
> request a server to send the rest of the pack to you?
Indeed, it's not resumable. For most commits it's not needed since they
are very small. Why? There are more commits than paths, so the commits
are smaller than paths on the average. I expect my schema to allow for
nearly as good compression as git usually does, especially I'd hope it's
no worse than when packing paths.
However, there may be very large commits in my schema (and maybe also
very large "path-packs" in yours). Such large commits get split as I
described above. Small commits get paired (possibly multiple times) as I
described earlier. You end up with only reasonably sized pieces of data,
let's say between 256 and 512 kB, so you don't need to resume.
Actually, with a really bad connection, you could ask the very server
from which you obtained an incomplete pack to resume from a given byte
offset (similar to HTTP ranges). The server may or may not have it. This
time it should try to keep it available for you in case you connections
abort again. Don't get me wrong -- this is just an additional help for
very badly connected people.
^ permalink raw reply
* Re: [BUG] git rev-list --no-walk A B C sorts by commit date incorrectly
From: Junio C Hamano @ 2011-01-08 1:00 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git list
In-Reply-To: <CEF26B82-4281-4B8F-A994-DE32EFB92BA7@sb.org>
Kevin Ballard <kevin@sb.org> writes:
> Is there any rationale for this behavior?
Not a rationale, but an explanation is that most of the time we walk the
history and sorting by date is the first thing that needs to be done, and
the --no-walk option was an afterthought that was tucked in.
I suspect that a three-liner patch to revision.c:prepare_revision_walk()
would give you what you want. Instead of calling insert-by-date, you
append to the tail when revs->no_walk is given, or something.
^ permalink raw reply
* What's cooking in git.git (Jan 2011, #02; Fri, 7)
From: Junio C Hamano @ 2011-01-08 0:52 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
I'll start paying much less attention to any new features and enhancements
and shift the focus almost entirely on trivial fixes and regressions from
now on. Hopefully lists will do the same and we can have a fairly short
rc period this cycle. Please remind if there are patches that ought to be
in 1.7.4 but are forgotten.
--------------------------------------------------
[Graduated to "master"]
* ao/t9001-fix (2011-01-04) 1 commit
+ t/t9001-send-email.sh: fix '&&' chain in some tests
* mg/cvsimport (2010-12-29) 2 commits
+ cvsimport: handle the parsing of uppercase config options
+ cvsimport: partial whitespace cleanup
* pw/convert-pathname-substitution (2010-12-22) 2 commits
+ t0021: avoid getting filter killed with SIGPIPE
+ convert filter: supply path to external driver
--------------------------------------------------
[New Topics]
* rj/svn-test (2010-12-30) 1 commit
(merged to 'next' on 2011-01-05 at ff38429)
+ lib-git-svn.sh: Move web-server handling code into separate function
Looked low-impact and trivial. Might merge to 'master' sometime before
1.7.4, but we are in no hurry.
* sr/gitweb-hilite-more (2010-12-30) 2 commits
(merged to 'next' on 2011-01-05 at 6b52e7e)
+ gitweb: remove unnecessary test when closing file descriptor
+ gitweb: add extensions to highlight feature map
Looked low-impact and trivial. Might merge to 'master' sometime before
1.7.4, especially highlighting itself is a new feature.
* mz/rebase (2010-12-28) 31 commits
- rebase -i: remove unnecessary state rebase-root
- rebase -i: don't read unused variable preserve_merges
- git-rebase--am: remove unnecessary --3way option
- rebase -m: don't print exit code 2 when merge fails
- rebase -m: remember allow_rerere_autoupdate option
- rebase: remember strategy and strategy options
- rebase: remember verbose option
- rebase: extract code for writing basic state
- rebase: factor out sub command handling
- rebase: make -v a tiny bit more verbose
- rebase -i: align variable names
- rebase: show consistent conflict resolution hint
- rebase: extract am code to new source file
- rebase: extract merge code to new source file
- rebase: remove $branch as synonym for $orig_head
- rebase -i: support --stat
- rebase: factor out call to pre-rebase hook
- rebase: factor out clean work tree check
- rebase: factor out reference parsing
- rebase: reorder validation steps
- rebase -i: remove now unnecessary directory checks
- rebase: factor out command line option processing
- rebase: align variable content
- rebase: align variable names
- rebase: stricter check of standalone sub command
- rebase: act on command line outside parsing loop
- rebase: improve detection of rebase in progress
- rebase: remove unused rebase state 'prev_head'
- rebase: read state outside loop
- rebase: refactor reading of state
- rebase: clearer names for directory variables
I personally haven't finished reading this one yet; Thomas said the
general direction of the series basically seemed sound (with nits here
and there), which I trust. Hopefully we will see a re-roll of this
series sometime soon, but we are not in a hurry.
* ef/alias-via-run-command (2011-01-07) 1 commit
(merged to 'next' on 2011-01-06 at 1fbd4a0)
+ alias: use run_command api to execute aliases
* jc/rename-degrade-cc-to-c (2011-01-06) 3 commits
- diffcore-rename: fall back to -C when -C -C busts the rename limit
- diffcore-rename: record filepair for rename src
- diffcore-rename: refactor "too many candidates" logic
* jc/rerere-remaining (2011-01-06) 1 commit
- rerere "remaining"
* uk/checkout-ambiguous-ref (2011-01-07) 3 commits
- checkout $branch: really favor branch over tag
- checkout $branch: favor branch over tag
- bug? in checkout with ambiguous refnames
--------------------------------------------------
[Stalled]
* nd/index-doc (2010-09-06) 1 commit
- doc: technical details about the index file format
Half-written but it is a good start. I may need to give some help in
describing more recent index extensions.
* cb/ignored-paths-are-precious (2010-08-21) 1 commit
- checkout/merge: optionally fail operation when ignored files need to be overwritten
This needs tests; also we know of longstanding bugs in related area that
needs to be addressed---they do not have to be part of this series but
their reproduction recipe would belong to the test script for this topic.
It would hurt users to make the new feature on by default, especially the
ones with subdirectories that come and go.
* jk/tag-contains (2010-07-05) 4 commits
- Why is "git tag --contains" so slow?
- default core.clockskew variable to one day
- limit "contains" traversals based on commit timestamp
- tag: speed up --contains calculation
The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.
* rj/test-fixes (2010-12-14) 4 commits
. t4135-*.sh: Skip the "backslash" tests on cygwin
. t3032-*.sh: Do not strip CR from line-endings while grepping on MinGW
. t3032-*.sh: Pass the -b (--binary) option to sed on cygwin
. t6038-*.sh: Pass the -b (--binary) option to sed on cygwin
I don't think people on different vintage of Cygwin agreed they are good
workarounds---please correct me if I am mistaken.
--------------------------------------------------
[Cooking]
* jn/gitweb-no-logo (2010-09-03) 1 commit
(merged to 'next' on 2011-01-04 at a5d186c)
+ gitweb: make logo optional
Seems trivial but came a bit too late for the cycle.
* cb/setup (2010-12-27) 1 commit
(merged to 'next' on 2011-01-05 at 790b288)
+ setup: translate symlinks in filename when using absolute paths
Seems trivial but came a bit too late for the cycle.
* ae/better-template-failure-report (2010-12-18) 1 commit
(merged to 'next' on 2011-01-05 at d3f9142)
+ Improve error messages when temporary file creation fails
* jc/unpack-trees (2010-12-22) 2 commits
- unpack_trees(): skip trees that are the same in all input
- unpack-trees.c: cosmetic fix
* jn/cherry-pick-strategy-option (2010-12-10) 1 commit
(merged to 'next' on 2011-01-05 at 3ccc590)
+ cherry-pick/revert: add support for -X/--strategy-option
* jn/perl-funcname (2010-12-27) 2 commits
(merged to 'next' on 2011-01-05 at 20542ed)
+ userdiff/perl: catch BEGIN/END/... and POD as headers
+ diff: funcname and word patterns for perl
Looked low-impact and trivial. Might merge to 'master' sometime before
1.7.4, but we are in no hurry.
* tr/maint-branch-no-track-head (2010-12-14) 1 commit
- branch: do not attempt to track HEAD implicitly
Probably needs a re-roll to exclude either (1) any ref outside the
hierarchies for branches (i.e. refs/{heads,remotes}/), or (2) only refs
outside refs/ hierarchies (e.g. HEAD, ORIG_HEAD, ...). The latter feels
safer and saner.
* hv/mingw-fs-funnies (2010-12-14) 5 commits
- mingw_rmdir: set errno=ENOTEMPTY when appropriate
- mingw: add fallback for rmdir in case directory is in use
- mingw: make failures to unlink or move raise a question
- mingw: work around irregular failures of unlink on windows
- mingw: move unlink wrapper to mingw.c
Will be rerolled (Heiko, 2010-12-23)
* jn/svn-fe (2010-12-06) 17 commits
- vcs-svn: Allow change nodes for root of tree (/)
- vcs-svn: Implement Prop-delta handling
- vcs-svn: Sharpen parsing of property lines
- vcs-svn: Split off function for handling of individual properties
- vcs-svn: Make source easier to read on small screens
- vcs-svn: More dump format sanity checks
- vcs-svn: Reject path nodes without Node-action
- vcs-svn: Delay read of per-path properties
- vcs-svn: Combine repo_replace and repo_modify functions
- vcs-svn: Replace = Delete + Add
- vcs-svn: handle_node: Handle deletion case early
- vcs-svn: Use mark to indicate nodes with included text
- vcs-svn: Unclutter handle_node by introducing have_props var
- vcs-svn: Eliminate node_ctx.mark global
- vcs-svn: Eliminate node_ctx.srcRev global
- vcs-svn: Check for errors from open()
- vcs-svn: Allow simple v3 dumps (no deltas yet)
Some RFC patches, to give them early and wider exposure.
* nd/struct-pathspec (2010-12-15) 21 commits
- t7810: overlapping pathspecs and depth limit
- grep: drop pathspec_matches() in favor of tree_entry_interesting()
- grep: use writable strbuf from caller for grep_tree()
- grep: use match_pathspec_depth() for cache/worktree grepping
- grep: convert to use struct pathspec
- Convert ce_path_match() to use match_pathspec_depth()
- Convert ce_path_match() to use struct pathspec
- struct rev_info: convert prune_data to struct pathspec
- pathspec: add match_pathspec_depth()
- tree_entry_interesting(): optimize wildcard matching when base is matched
- tree_entry_interesting(): support wildcard matching
- tree_entry_interesting(): fix depth limit with overlapping pathspecs
- tree_entry_interesting(): support depth limit
- tree_entry_interesting(): refactor into separate smaller functions
- diff-tree: convert base+baselen to writable strbuf
- glossary: define pathspec
- Move tree_entry_interesting() to tree-walk.c and export it
- tree_entry_interesting(): remove dependency on struct diff_options
- Convert struct diff_options to use struct pathspec
- diff-no-index: use diff_tree_setup_paths()
- Add struct pathspec
(this branch is used by en/object-list-with-pathspec.)
On hold, perhaps in 'next', til 1.7.4 final.
* en/object-list-with-pathspec (2010-09-20) 2 commits
- Add testcases showing how pathspecs are handled with rev-list --objects
- Make rev-list --objects work together with pathspecs
(this branch uses nd/struct-pathspec.)
On hold, perhaps in 'next', til 1.7.4 final.
* tr/merge-unborn-clobber (2010-08-22) 1 commit
- Exhibit merge bug that clobbers index&WT
* ab/i18n (2010-10-07) 161 commits
- po/de.po: complete German translation
- po/sv.po: add Swedish translation
- gettextize: git-bisect bisect_next_check "You need to" message
- gettextize: git-bisect [Y/n] messages
- gettextize: git-bisect bisect_replay + $1 messages
- gettextize: git-bisect bisect_reset + $1 messages
- gettextize: git-bisect bisect_run + $@ messages
- gettextize: git-bisect die + eval_gettext messages
- gettextize: git-bisect die + gettext messages
- gettextize: git-bisect echo + eval_gettext message
- gettextize: git-bisect echo + gettext messages
- gettextize: git-bisect gettext + echo message
- gettextize: git-bisect add git-sh-i18n
- gettextize: git-stash drop_stash say/die messages
- gettextize: git-stash "unknown option" message
- gettextize: git-stash die + eval_gettext $1 messages
- gettextize: git-stash die + eval_gettext $* messages
- gettextize: git-stash die + eval_gettext messages
- gettextize: git-stash die + gettext messages
- gettextize: git-stash say + gettext messages
- gettextize: git-stash echo + gettext message
- gettextize: git-stash add git-sh-i18n
- gettextize: git-submodule "blob" and "submodule" messages
- gettextize: git-submodule "path not initialized" message
- gettextize: git-submodule "[...] path is ignored" message
- gettextize: git-submodule "Entering [...]" message
- gettextize: git-submodule $errmsg messages
- gettextize: git-submodule "Submodule change[...]" messages
- gettextize: git-submodule "cached cannot be used" message
- gettextize: git-submodule $update_module say + die messages
- gettextize: git-submodule die + eval_gettext messages
- gettextize: git-submodule say + eval_gettext messages
- gettextize: git-submodule echo + eval_gettext messages
- gettextize: git-submodule add git-sh-i18n
- gettextize: git-pull "rebase against" / "merge with" messages
- gettextize: git-pull "[...] not currently on a branch" message
- gettextize: git-pull "You asked to pull" message
- gettextize: git-pull split up "no candidate" message
- gettextize: git-pull eval_gettext + warning message
- gettextize: git-pull eval_gettext + die message
- gettextize: git-pull die messages
- gettextize: git-pull add git-sh-i18n
- gettext docs: add "Testing marked strings" section to po/README
- gettext docs: the Git::I18N Perl interface
- gettext docs: the git-sh-i18n.sh Shell interface
- gettext docs: the gettext.h C interface
- gettext docs: add "Marking strings for translation" section in po/README
- gettext docs: add a "Testing your changes" section to po/README
- po/pl.po: add Polish translation
- po/hi.po: add Hindi Translation
- po/en_GB.po: add British English translation
- po/de.po: add German translation
- Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease
- gettext docs: add po/README file documenting Git's gettext
- gettextize: git-am printf(1) message to eval_gettext
- gettextize: git-am core say messages
- gettextize: git-am "Apply?" message
- gettextize: git-am clean_abort messages
- gettextize: git-am cannot_fallback messages
- gettextize: git-am die messages
- gettextize: git-am eval_gettext messages
- gettextize: git-am multi-line getttext $msg; echo
- gettextize: git-am one-line gettext $msg; echo
- gettextize: git-am add git-sh-i18n
- gettext tests: add GETTEXT_POISON tests for shell scripts
- gettext tests: add GETTEXT_POISON support for shell scripts
- Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT
- Makefile: add GNU_GETTEXT, set when we expect GNU gettext
- gettextize: git-shortlog basic messages
- gettextize: git-revert split up "could not revert/apply" message
- gettextize: git-revert literal "me" messages
- gettextize: git-revert "Your local changes" message
- gettextize: git-revert basic messages
- gettextize: git-notes "Refusing to %s notes in %s" message
- gettextize: git-notes GIT_NOTES_REWRITE_MODE error message
- gettextize: git-notes basic commands
- gettextize: git-gc "Auto packing the repository" message
- gettextize: git-gc basic messages
- gettextize: git-describe basic messages
- gettextize: git-clean clean.requireForce messages
- gettextize: git-clean basic messages
- gettextize: git-bundle basic messages
- gettextize: git-archive basic messages
- gettextize: git-status "renamed: " message
- gettextize: git-status "Initial commit" message
- gettextize: git-status "Changes to be committed" message
- gettextize: git-status shortstatus messages
- gettextize: git-status "nothing to commit" messages
- gettextize: git-status basic messages
- gettextize: git-push "prevent you from losing" message
- gettextize: git-push basic messages
- gettextize: git-tag tag_template message
- gettextize: git-tag basic messages
- gettextize: git-reset "Unstaged changes after reset" message
- gettextize: git-reset reset_type_names messages
- gettextize: git-reset basic messages
- gettextize: git-rm basic messages
- gettextize: git-mv "bad" messages
- gettextize: git-mv basic messages
- gettextize: git-merge "Wonderful" message
- gettextize: git-merge "You have not concluded your merge" messages
- gettextize: git-merge "Updating %s..%s" message
- gettextize: git-merge basic messages
- gettextize: git-log "--OPT does not make sense" messages
- gettextize: git-log basic messages
- gettextize: git-grep "--open-files-in-pager" message
- gettextize: git-grep basic messages
- gettextize: git-fetch split up "(non-fast-forward)" message
- gettextize: git-fetch update_local_ref messages
- gettextize: git-fetch formatting messages
- gettextize: git-fetch basic messages
- gettextize: git-diff basic messages
- gettextize: git-commit advice messages
- gettextize: git-commit "enter the commit message" message
- gettextize: git-commit print_summary messages
- gettextize: git-commit formatting messages
- gettextize: git-commit "middle of a merge" message
- gettextize: git-commit basic messages
- gettextize: git-checkout "Switched to a .. branch" message
- gettextize: git-checkout "HEAD is now at" message
- gettextize: git-checkout describe_detached_head messages
- gettextize: git-checkout: our/their version message
- gettextize: git-checkout basic messages
- gettextize: git-branch "(no branch)" message
- gettextize: git-branch "git branch -v" messages
- gettextize: git-branch "Deleted branch [...]" message
- gettextize: git-branch "remote branch '%s' not found" message
- gettextize: git-branch basic messages
- gettextize: git-add refresh_index message
- gettextize: git-add "remove '%s'" message
- gettextize: git-add "pathspec [...] did not match" message
- gettextize: git-add "Use -f if you really want" message
- gettextize: git-add "no files added" message
- gettextize: git-add basic messages
- gettextize: git-clone "Cloning into" message
- gettextize: git-clone basic messages
- gettext tests: test message re-encoding under C
- po/is.po: add Icelandic translation
- gettext tests: mark a test message as not needing translation
- gettext tests: test re-encoding with a UTF-8 msgid under Shell
- gettext tests: test message re-encoding under Shell
- gettext tests: add detection for is_IS.ISO-8859-1 locale
- gettext tests: test if $VERSION exists before using it
- gettextize: git-init "Initialized [...] repository" message
- gettextize: git-init basic messages
- gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
- gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter
- gettext.c: use libcharset.h instead of langinfo.h when available
- gettext.c: work around us not using setlocale(LC_CTYPE, "")
- builtin.h: Include gettext.h
- Makefile: use variables and shorter lines for xgettext
- Makefile: tell xgettext(1) that our source is in UTF-8
- Makefile: provide a --msgid-bugs-address to xgettext(1)
- Makefile: A variable for options used by xgettext(1) calls
- gettext tests: locate i18n lib&data correctly under --valgrind
- gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions
- gettext tests: rename test to work around GNU gettext bug
- gettext: add infrastructure for translating Git with gettext
- builtin: use builtin.h for all builtin commands
- tests: use test_cmp instead of piping to diff(1)
- t7004-tag.sh: re-arrange git tag comment for clarity
It is getting ridiculously painful to keep re-resolving the conflicts with
other topics in flight, even with the help with rerere.
Needs a bit more minor work to get the basic code structure right.
^ permalink raw reply
* different name and email address depending on folder
From: Rich Eakin @ 2011-01-08 0:52 UTC (permalink / raw)
To: git
Hi,
I am using git for development with a company and myself on the same computer and the name / user fields need to be different for each. As I keep all my company's repos in one directory and my private stuff in another, I was wondering if there is a way to tell git to use a separate user and email whenever I make commits from within a specified directory.
If anyone can tell me how to do this, or some other way to achieve my needs, I am very thankful.
Best Regards,
Rich
^ permalink raw reply
* Re: clone breaks replace
From: Phillip Susi @ 2011-01-08 0:43 UTC (permalink / raw)
To: Jeff King; +Cc: Jonathan Nieder, git, Christian Couder, Stephen Bash
In-Reply-To: <20110107220942.GB10343@sigill.intra.peff.net>
On 01/07/2011 05:09 PM, Jeff King wrote:
> I think there are two separate issues here:
>
> 1. Should transport protocols respect replacements (i.e., if you
> truncate history with a replacement object and I fetch from you,
> should you get the full history or the truncated one)?
>
> 2. Should clone fetch refs from refs/replace (either by default, or
> with an option)?
>
> Based on previous discussions, I think the answer to the first is no.
> The resulting repo violates a fundamental assumption of git. Yes,
> because of the replacement object, many things will still work. But many
> parts of git intentionally do not respect replacement, and they will be
> broken.
What parts do not respect replacement? More importantly, what parts
will be broken? The man page seems to indicate that about the only
thing that does not by default is reachability testing, which to me
means fsck and prune. It seems to be the purpose of replace to
/prevent/ breakage and be respected by default, unless doing so would
cause harm, which is why fsck and prune do not.
> Instead, I think of replacements as a specific view into history, not a
> fundamental history-changing operation itself. Which means you can never
> save bandwidth or space by truncating history with replacements. You can
> only give somebody the full history, and share with them your view. If
> you want to truncate, you must rewrite history[1].
Right, but if you only care about that view, then there is no need to
waste bandwidth fetching the original one. It goes without saying that
people pulling from the repository mainly care about the view upstream
chooses to publish. Upstream can choose to rewrite, which will cause
breakage and is a sort of sneaky way to hide the original history, or
they can use replace, which avoids the breakage and gives the client the
choice of which view to use.
^ permalink raw reply
* Re: [RFD] My thoughts about implementing gitweb output caching
From: Jonathan Nieder @ 2011-01-08 0:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, J.H., John 'Warthog9' Hawley
In-Reply-To: <201101080042.36156.jnareb@gmail.com>
Hi,
Thanks for these design notes. A few uninformed reactions.
Jakub Narebski wrote:
> There was request to support installing gitweb modules in a separate
> directory, but that would require changes to "gitweb: Prepare for
> splitting gitweb" patch (but it is doable). Is there wider interest
> in supporting such feature?
If you are referring to my suggestion, I see no reason to wait on
that. The lib/ dir can be made configurable later.
> Simplest solution is to use $cgi->self_url() (note that what J.H. v8
> uses, i.e.: "$my_url?". $ENV{'QUERY_STRING'}, where $my_url is just
> $cgi->url() is not enough - it doesn't take path_info into account).
>
> Alternate solution, which I used in my rewrite, is to come up with
> "canonical" URL, e.g. href(-replay => 1, -full => 1, -path_info => 0);
> with this solution using path_info vs query parameters or reordering
> query parameters still gives the same key.
It is easy to miss dependencies on parts of the URL that are being
fuzzed out. For example, the <base href...> tag is only inserted with
path_info. Maybe it would be less risky to first use self_url(), then
canonicalize it in a separate patch?
> J.H. patches up and including v7, and my rewrite up and including v6,
> excluded error pages from caching. I think that the original resoning
> behind choosing to do it this way was that A.), each of specific error
> pages is usually accessed only once, so caching them would only take up
> space bloating cache, but what is more important B.) that you can't
> cache errors from caching engine.
Perhaps there is a user experience reason? If I receive an error page
due to a problem with my repository, all else being equal, I would
prefer that the next time I reload it is fixed. By comparison, having
to reload multiple times to forget an obsolete non-error response
would be less aggravating and perhaps expected.
But the benefit from caching e.g. a response from a broken link would
outweigh that.
> Second is if there is no stale data to serve (or data is too stale), but
> we have progress indicator. In this case the foreground process is
> responsible for rendering progress indicator, and background process is
> responsible for generating data. In this case foreground process waits
> for data to be generated (unless progress info subroutine exits), so
> strictly spaking we don't need to detach background process in this
> case.
What happens when the client gets tired of waiting and closes the
connection?
> With output caching gitweb can also support 'Range' requests, which
> means that it would support resumable download. This would mean hat we
> would be able to resume downloading of snapshot (or in the future
> bundle)... if we cannot do this now. This would require some more code
> to be added.
Exciting stuff.
Teaching gitweb to generate bundles sounds like a recipe for high server
loads, though. I suspect manual (or by cronjob) generation would work
better, with a possible exception of very frequently cloned and
infrequently pushed-to repos like linus's linux-2.6.
Jonathan
^ permalink raw reply
* [BUG] git rev-list --no-walk A B C sorts by commit date incorrectly
From: Kevin Ballard @ 2011-01-08 0:19 UTC (permalink / raw)
To: git list
-----------------------------------------------------------------------------
Running the command `git rev-list --no-walk A B C` should be expected to emit
the commits in the same order as they were specified. This is especially
important as the same machinery is used for `git cherry-pick`, and so saying
`git cherry-pick A B C` can be expected to pick A before B, and B before C.
This does not happen.
Instead, it appears to be sorting the given commits according to the commit
timestamp. To make matters worse, it's not a stable sort. If commits A and
B have the same timestamp (for example, if they were rebased together), then
git cherry-pick tends to apply B before A.
Is there any rationale for this behavior? Any place where it makes sense to
reorder the commits in this fashion? As far as I'm concerned, typing
`git cherry-pick A B C` should behave identically to typing
git cherry-pick A
git cherry-pick B
git cherry-pick C
regardless of the actual commit dates on A, B, and C.
-Kevin Ballard
^ permalink raw reply
* Re: bug in gitk: history moves right when scrolling up and down with mouse wheel
From: Neal Kreitzinger @ 2011-01-08 0:17 UTC (permalink / raw)
To: Stefan Haller; +Cc: Uwe Kleine-König, git
In-Reply-To: <1juqtpt.1dxkc9x1ho9gxzM%lists@haller-berlin.de>
On 1/7/2011 2:24 PM, Stefan Haller wrote:
> Neal Kreitzinger<nkreitzinger@gmail.com> wrote:
>
>> Actually, I've wanted the ability to scroll left and right in the
>> history pane for quite a while. Resorting to shrinking the fontsize and
>> the other columns only goes so far when trying to see a list of
>> equivalent refs. If the ability to scroll left and right can be kept
>> that would be cool.
>
> Interesting. On the Mac it *is* possible to scroll left and right, and
> it absolutely drives me nuts, so I disabled it in my private build.
> I guess it's ok with a mouse, where shift-wheel scrolls horizontally,
> but on a track-pad with two-finger scrolling, where you can scroll both
> horizontally and vertically with a single guesture, it is completely
> undesirable.
>
I agree. What would be ideal is a left-right scroll bar like the
up-down scrollbar.
v/r,
Neal
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox