* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jakub Narebski @ 2006-12-09 11:51 UTC (permalink / raw)
To: Martin Langhoff, Git Mailing List
Cc: Linus Torvalds, Jeff Garzik, H. Peter Anvin, Rogan Dawes,
Kernel Org Admin
In-Reply-To: <46a038f90612081756w1ab4609epcb4a2cbd9f4d8205@mail.gmail.com>
Martin Langhoff wrote:
> We can make gitweb to detect mod_perl and a few smarter things if it
> is running inside of it. In fact, we can (ab)use mod_perl and perl
> facilities a bit to do some serialization which will be a big win for
> some pages. What we need for that is to set a sensible the ETag and
> use some IPC to announce/check if other apache/modperl processes are
> preparing content for the same ETag. The first-process-to-announce a
> given ETag can then write it to a common temp directory (atomically -
> write to a temp-name and move to the expected name) while other
> processes wait, polling for the file. Once the file is in place the
> latecomers can just serve the content of the file and exit.
First, it would (and could) work only for serving gitweb over mod_perl.
I'm not sure if overhead with IPC and complications implementing are
worth it: this perhaps be better solved by caching engine.
But let us put aside for a while actual caching (writing HTML version
of the page to a common temp directory, and serving this static page
if possible), and talk a bit what gitweb can do with respect to
cache validation.
In addition to setting either Expires: header or Cache-Control: max-age
gitweb should also set Last-Modified: and ETag headers, and also
probably respond to If-Modified-Since: and If-None-Match: requests.
Would be worth implementing this?
> (I am calling the "state we are serving" identifier ETag because I
> think we should also set it as the ETag in the HTTP headers, so well
> be able to check the ETag of future requests for staleness - all we
> need is a ref lookup, and if the SHA1 matches, we are sorted). So
> having this 'unique request identifier' doubles up nicely...
For some pages ETag is natural; for other Last-Modified: would be more
natural.
> The ETag should probably be:
> - SHA1+displaytype+args for pages that display an object identified
> by SHA1
What uniquely identifies contents in "object" views ("commit", "tag",
"tree", "blob") is either h=SHA1, or hb=SHA1;f=FILENAME (with absence
of h=SHA1). If both h=SHA1 and hb=SHA1 is present, hb=SHA1 serves as
backlink. The "diff" views ("commitdiff", "blobdiff") are uniquely
identified by pair of object identifiers (pairs of SHA1, or pairs of
hb SHA1 + FILENAME).
Three of those views ("blob", "commitdiff", "blobdiff") have their
"plain" version; so ETag should include displaytype (action, 'a'
parameter).
The hb=SHA1;f=FILENAME indentifier can be converted at cost of one
call to git command (but which is a bit expensive as it recurses
trees), namely to git-ls-tree.
ETag can be simply args (query), if all h/hb/hbp parameters are SHA1.
Or ETag can be SHA1 of an object (or pair of SHA1 in the case of diff),
but this is little more costly to verify. Although we usually (always?)
convert hb=SHA1;f=FILENAME to h=SHA1 anyway when displaying/generating
page.
Usualy you can compare ETags base on URL alone.
> - refname+SHA!+displaytype+args for pages that display something
> identified by a ref
For objects views we can simply convert refname to SHA1. I'm not sure if
it is worth it. In the cases when for view we have to calculate SHA1 of
object anyway, we can return (and validate) ETag with SHA1 as above.
- ETag and/or Last-Modified headers for "log" views: "log",
"shortlog" (is part of summary view), "history", "rss"/"atom" views.
On one hand all log views (at least now) are identified by their
parameters (action/view name, and filename in the case of history view)
and SHA1 of top commit. On the other hand it might be easier to use
Last-Modified with date of top commit... Verifying SHA1 based ETag
could add some overhead in the case of miss.
> - SHA1(names and sha1s of all refs) for the summary page
Wouldn't it be simplier to just set Last-Modified: header (and check
it?)
P.S. Can anyone post some benchmark comparing gitweb deployed under
mod_perl as compared to deployed as CGI script? Does kernel.org use
mod_perl, or CGI version of gitweb?
--
Jakub Narebski
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-09 9:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael K. Edwards, H. Peter Anvin, Rogan Dawes, Kernel Org Admin,
Git Mailing List, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612081648160.3516@woody.osdl.org>
Linus Torvalds wrote:
> That said, I'm not personally convinced that there is much point to using
> netfilter for transparent proxying. Why not just use separate ports for
> squid and for apache?
That's what most people using squid in "http accelerator" mode do. They
put Apache on port 8080 or somesuch.
Jeff
^ permalink raw reply
* RFC PATCH: support for default remote in StGIT
From: Pavel Roskin @ 2006-12-09 9:23 UTC (permalink / raw)
To: "Catalin Marinas catalin.marinas"; +Cc: git
Hello, Catalin!
It's very important for me to have default remote support in StGIT. I'm
trying to track different Linux branches, and I don't want to remember
what branch I'm on when I run "stg pull".
I have tried two approaches, and both work, but I'm not particular fond
of either of them, so I think I'll just send both, and maybe we'll come
to a satisfactory solution.
One approach is to leave the default remote selection completely to git.
The downside is that StGIT prints the remote it's pulling from. Now
StGIT will have to print common words that it's pulling something. Or
maybe it shouldn't print anything?
Also, git-pull doesn't allow to specify the refspec without the remote.
This limitation seems artificial to me, but we have to pass this
limitation to the StGIT users.
The positive side if that StGIT is completely unaware of the word
"origin", and any changes in git handling of the default remote will
propagate to StGIT immediately.
diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index 227249e..3ef582e 100644
--- a/stgit/commands/pull.py
+++ b/stgit/commands/pull.py
@@ -50,7 +50,7 @@ def func(parser, options, args):
if len(args) > 2:
parser.error('incorrect number of arguments')
- repository = 'origin'
+ repository = None
refspec = None
if len(args) >= 1:
repository = args[0]
@@ -73,7 +73,11 @@ def func(parser, options, args):
print 'done'
# pull the remote changes
- print 'Pulling from "%s"...' % repository
+ if repository:
+ print 'Pulling from "%s"...' % repository
+ else:
+ print 'Pulling from the default repository'
+
git.pull(repository, refspec)
print 'done'
diff --git a/stgit/git.py b/stgit/git.py
index eb8da4e..7aed357 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -790,14 +790,20 @@ def reset(files = None, tree_id = None, check_out = True):
if not files:
__set_head(tree_id)
-def pull(repository = 'origin', refspec = None):
+def pull(repository = None, refspec = None):
"""Pull changes from the remote repository. At the moment, just
use the 'git-pull' command
"""
# 'git-pull' updates the HEAD
__clear_head_cache()
- args = [repository]
+ if repository:
+ args = [repository]
+ else:
+ if refspec:
+ raise GitException, 'git-pull requires repository with refspec'
+ args = []
+
if refspec:
args.append(refspec)
The other approach is to calculate the default remote in StGIT. This
would allow StGIT to tell the user where it's pulling from.
However, I had to introduce a function that ignores errors except there
is any output on stderr. This is because git-repo-config returns error
code 1 if it cannot find the key. Maybe git-repo-config should have an
option not to fail in this case? Perhaps a default value to return?
diff --git a/stgit/commands/pull.py b/stgit/commands/pull.py
index 227249e..7824dc3 100644
--- a/stgit/commands/pull.py
+++ b/stgit/commands/pull.py
@@ -54,6 +54,9 @@ def func(parser, options, args):
refspec = None
if len(args) >= 1:
repository = args[0]
+ else:
+ repository = git.get_default_remote()
+
if len(args) == 2:
refspec = args[1]
diff --git a/stgit/git.py b/stgit/git.py
index eb8da4e..ed08d7d 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -186,6 +186,20 @@ def _output_one_line(cmd, file_desc = None):
p.childerr.read().strip())
return output
+def _output_one_line_try(cmd, file_desc = None):
+ """ Read one line of cmd output, fail only on stderr messages
+ """
+ p=popen2.Popen3(cmd, True)
+ if file_desc != None:
+ for line in file_desc:
+ p.tochild.write(line)
+ p.tochild.close()
+ output = p.fromchild.readline().strip()
+ errors = p.childerr.read().strip()
+ if errors:
+ raise GitException, '%s failed (%s)' % (str(cmd), errors)
+ return output
+
def _output_lines(cmd):
p=popen2.Popen3(cmd, True)
lines = p.fromchild.readlines()
@@ -285,6 +299,20 @@ def get_head_file():
return strip_prefix('refs/heads/',
_output_one_line('git-symbolic-ref HEAD'))
+def get_default_remote():
+ """Returns default remote to pull
+ """
+ branch = get_head_file()
+
+ repository = _output_one_line_try(['git-repo-config', '--get',
+ 'branch.%s.remote' % branch])
+
+ if not repository:
+ repository = 'origin'
+
+ return repository
+
+
def set_head_file(ref):
"""Resets HEAD to point to a new ref
"""
--
Regards,
^ permalink raw reply related
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Jeff Garzik @ 2006-12-09 9:16 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Rogan Dawes, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612081640400.3516@woody.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 8 Dec 2006, Jeff Garzik wrote:
>> This is a bit cheesy, and completely untested, but since mod_cache never
>> worked for me either, I bet it works better ;-)
>
> Ok, this doesn't do the locking either, so on cache misses or expiry,
> you're still going to be that thundering herd.
Well, gdbm does reader/write locking.
You still bit a bit of a thundering herd, though. I suppose I could
open the gdbm db for writing before calling the CGI, which would
effectively get what you're looking for.
> Also, if you want to be nice to clients, I'd seriously suggest that when
> you hit in the cache, but it's expired (or it's close to expired), you
> still serve the cached data back, but you set up a thread in the
> background (with some maximum number of active threads, of course!) that
> refreshes the cached entry and then you extend the expiration time so that
> you won't end up doing this "refresh" _again_.
>
> It's kind of silly to have people wait for 20 seconds just because a cache
> expired five seconds ago. Much nicer to say "ok, we allow a certain
> grace-period during which we'll do the real lookup, but to make things
> _look_ really responsive, we still use the old cached value".
True, should work with gitweb data at least.
Jeff
^ permalink raw reply
* Re: cygwin, 44k files: how to commit only index?
From: Torgil Svensson @ 2006-12-09 8:27 UTC (permalink / raw)
To: Christian MICHON; +Cc: git
In-Reply-To: <46d6db660612071326m4817165l992e8d6e7bd673c5@mail.gmail.com>
On 12/7/06, Christian MICHON <christian.michon@gmail.com> wrote:
> On 12/7/06, Shawn Pearce <spearce@spearce.org> wrote:
> > Shawn Pearce <spearce@spearce.org> wrote:
> > > Its Cygwin/NTFS. lstat() is slow. readdir() is slow. I have the
> > > same problem on my Cygwin systems.
> >
> > Just to be clear, I'm not trying to blame Cygwin here.
> >
> > Windows' dir command is slow. Windows Explorer is slow while
> > browsing directories.
I think this is a very common scenario costing hideous amounts of
money around the globe.
If you have lot's of files in a folder, don't even think of
accidentally touching those folders in Windows Explorer, if you do -
keep Process Explorer or similar ready. I've ended up using (even w/o
Cygwin) scripts, automatic compressing and even a database functioning
as directory cache - basically creating accessibility layers for a
disabled file-system.
>
> before buying any new hardware, you could easily imagine the
> following scenario (I'm also "stuck" with windows, so it's an idea
> I've been toying around for a week or so).
>
> There're virtualizers around, on which networking capabilities can
> be activated. And we could easily create a vm with linux+git
> inside, using ext2/ext3/ext4 fs virtual disks (you'd benefit from
> windows cache actually...)
>
> example: YTech_Subversion_Appliance_v1.1 (ubuntu + subversion).
>
> I've no prototype yet, but I've 2 scenario possible:
> 1) use vmplayer and a minimal uclibc initramfs with git onboard
> 2) use qemu+kqemu and a similar mini-distro (but right now networking
> is an issue on windows hosts: I'm exploring tunneling)
>
> The 1st scenario is "easy". And I start to prefer this idea over
> even mingw porting of git (I tried and it's hard, really).
>
> But again, maybe jgit would be a better universal solution.
>
> --
> Christian
> -
Very interesting! Have you a time-frame for this? Maybe even
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Steven Grimm @ 2006-12-09 7:56 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0612081453430.3516@woody.osdl.org>
Linus Torvalds wrote:
> Looking at the memcached operations, they have the "read" op (aka "get"),
> but they seem to have no "read-for-fill" op. So memcached fundamentally
> doesn't fix this problem, at least without explicit serialization by the
> client.
>
Actually, memcached does support an operation that would work for this:
the "add" request, which creates a new cache entry if and only if the
key is not already in the cache. If the key is already present, the
request fails. You can use that to implement a simple named mutex, and
it supports a client-specified timeout. The one thing it doesn't support
that you described is a notion of deleting a key when a particular
client disconnects, but as you say, that should only happen in the case
of buggy clients anyway.
Mind you, I'm not convinced memcached is necessarily the right answer
for this problem, but it does provide a way to implement the required
locking semantics.
BTW, I'm one of the main contributors to memcached, so if it does end up
looking like a good choice except for some minor issue or another, I may
be able to tweak it to cover whatever is missing. For example, the
"delete a key on disconnect" thing would be fairly straightforward, if
it's actually necessary in practice.
-Steve
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Sean @ 2006-12-09 7:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pazu, git, Petr Baudis
In-Reply-To: <7vpsaui4cn.fsf@assigned-by-dhcp.cox.net>
On Fri, 08 Dec 2006 11:18:16 -0800
Junio C Hamano <junkio@cox.net> wrote:
> Personally, I would refuse to use such a modified git, because
> often the first thing I would do in the commit log buffer is
> check the listed files and remove the '# ...' lines while
> typing. I do not want that to affect the set of changes I
> staged in any way.
Your usage should not affected at all by the addition of this
feature. One of the comment lines could be magic, in that if
it is missing the feature is disabled. Something like:
# *** Editable Commit List ***
Or some such at the top of the list, where if it is missing after
commit message editing, the post processing of the file list
will be completely disabled. Another alternative would be to
just enable the feature with an -A or some other commit command
line option, so that those uninterested in such a feature don't
have to even see it.
It would be interesting to hear from Pasky on how this feature
has worked out in practice for Cogito users and whether he thinks
it would be a good addition to Git.
^ permalink raw reply
* [PATCH] Documentation/git-commit: rewrite to make it more end-user friendly.
From: Junio C Hamano @ 2006-12-09 5:48 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git, J. Bruce Fields
In-Reply-To: <Pine.LNX.4.64.0612082141260.2630@xanadu.home>
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* So how about this?
Documentation/git-commit.txt | 227 ++++++++++++++++++++++++++++--------------
1 files changed, 154 insertions(+), 73 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 517a86b..8fe42cb 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -14,25 +14,47 @@ SYNOPSIS
DESCRIPTION
-----------
-Updates the index file for given paths, or all modified files if
-'-a' is specified, and makes a commit object. The command specified
-by either the VISUAL or EDITOR environment variables are used to edit
-the commit log message.
+Use 'git commit' when you want to record your changes into the repository
+along with a log message describing what the commit is about. All changes
+to be committed must be explicitly identified using one of the following
+methods:
-Several environment variable are used during commits. They are
-documented in gitlink:git-commit-tree[1].
+1. by using gitlink:git-add[1] to incrementally "add" changes to the
+ next commit before using the 'commit' command (Note: even modified
+ files must be "added");
+2. by using gitlink:git-rm[1] to identify content removal for the next
+ commit, again before using the 'commit' command;
+
+3. by directly listing files containing changes to be committed as arguments
+ to the 'commit' command, in which cases only those files alone will be
+ considered for the commit;
+
+4. by using the -a switch with the 'commit' command to automatically "add"
+ changes from all known files i.e. files that have already been committed
+ before, and perform the actual commit.
+
+Note that the contents of the paths that resolved cleanly by a
+conflicted merge are automatically staged for the next commit;
+you still need to explicitly identify what you want in the
+resulting commit using one of the above methods before
+recording the merge commit.
+
+The gitlink:git-status[1] command can be used to obtain a
+summary of what is included by any of the above for the next
+commit by giving the same set of parameters you would give to
+this command.
+
+If you make a commit and then found a mistake immediately after
+that, you can recover from it with gitlink:git-reset[1].
-This command can run `commit-msg`, `pre-commit`, and
-`post-commit` hooks. See link:hooks.html[hooks] for more
-information.
OPTIONS
-------
-a|--all::
- Update all paths in the index file. This flag notices
- files that have been modified and deleted, but new files
- you have not told git about are not affected.
+ Tell the command to automatically stage files that have
+ been modified and deleted, but new files you have not
+ told git about are not affected.
-c or -C <commit>::
Take existing commit object, and reuse the log message
@@ -55,16 +77,13 @@ OPTIONS
-s|--signoff::
Add Signed-off-by line at the end of the commit message.
--v|--verify::
- Look for suspicious lines the commit introduces, and
- abort committing if there is one. The definition of
- 'suspicious lines' is currently the lines that has
- trailing whitespaces, and the lines whose indentation
- has a SP character immediately followed by a TAB
- character. This is the default.
-
--n|--no-verify::
- The opposite of `--verify`.
+--no-verify::
+ By default, the command looks for suspicious lines the
+ commit introduces, and aborts committing if there is one.
+ The definition of 'suspicious lines' is currently the
+ lines that has trailing whitespaces, and the lines whose
+ indentation has a SP character immediately followed by a
+ TAB character. This option turns off the check.
-e|--edit::
The message taken from file with `-F`, command line with
@@ -95,16 +114,16 @@ but can be used to amend a merge commit.
--
-i|--include::
- Instead of committing only the files specified on the
- command line, update them in the index file and then
- commit the whole index. This is the traditional
- behavior.
+ Before making a commit out of staged contents so far,
+ stage the contents of paths given on the command line
+ as well. This is usually not what you want unless you
+ are concluding a conflicted merge.
-o|--only::
- Commit only the files specified on the command line.
- This format cannot be used during a merge, nor when the
- index and the latest commit does not match on the
- specified paths to avoid confusion.
+ Commit only the files specified on the command line;
+ this is the default when pathnames are given on the
+ command line, so you usually do not have to give this
+ option. This format cannot be used during a merge.
\--::
Do not interpret any more arguments as options.
@@ -114,50 +133,112 @@ but can be used to amend a merge commit.
different between `--include` and `--only`. Without
either, it defaults `--only` semantics.
-If you make a commit and then found a mistake immediately after
-that, you can recover from it with gitlink:git-reset[1].
-
-
-Discussion
-----------
-
-`git commit` without _any_ parameter commits the tree structure
-recorded by the current index file. This is a whole-tree commit
-even the command is invoked from a subdirectory.
-
-`git commit --include paths...` is equivalent to
-
- git update-index --remove paths...
- git commit
-
-That is, update the specified paths to the index and then commit
-the whole tree.
-
-`git commit paths...` largely bypasses the index file and
-commits only the changes made to the specified paths. It has
-however several safety valves to prevent confusion.
-
-. It refuses to run during a merge (i.e. when
- `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
- that the traditional semantics now needs -i flag.
-
-. It refuses to run if named `paths...` are different in HEAD
- and the index (ditto about reminding). Added paths are OK.
- This is because an earlier `git diff` (not `git diff HEAD`)
- would have shown the differences since the last `git
- update-index paths...` to the user, and an inexperienced user
- may mistakenly think that the changes between the index and
- the HEAD (i.e. earlier changes made before the last `git
- update-index paths...` was done) are not being committed.
-
-. It reads HEAD commit into a temporary index file, updates the
- specified `paths...` and makes a commit. At the same time,
- the real index file is also updated with the same `paths...`.
-
-`git commit --all` updates the index file with _all_ changes to
-the working tree, and makes a whole-tree commit, regardless of
-which subdirectory the command is invoked in.
+EXAMPLES
+--------
+When recording your own work, the contents of modified files in
+your working tree are temporarily stored to a staging area
+called the "index" with gitlink:git-add[1]. Removal
+of a file is staged with gitlink:git-rm[1]. After building the
+state to be committed incrementally with these commands, `git
+commit` (without any pathname parameter) is used to record what
+has been staged so far. This is the most basic form of the
+command. An example:
+
+------------
+$ edit hello.c
+$ git rm goodbye.c
+$ git add hello.c
+$ git commit
+------------
+
+////////////
+We should fix 'git rm' to remove goodbye.c from both index and
+working tree for the above example.
+////////////
+
+Instead of staging files after each individual change, you can
+tell `git commit` to notice the changes to the tracked files in
+your working tree and do corresponding `git add` and `git rm`
+for you. That is, this example does the same as the earlier
+example if there is no other change in your working tree:
+
+------------
+$ edit hello.c
+$ rm goodbye.c
+$ git commit -a
+------------
+
+The command `git commit -a` first looks at your working tree,
+notices that you have modified hello.c and removed goodbye.c,
+and performs necessary `git add` and `git rm` for you.
+
+After staging changes to many files, you can alter the order the
+changes are recorded in, by giving pathnames to `git commit`.
+When pathnames are given, the command makes a commit that
+only records the changes made to the named paths:
+
+------------
+$ edit hello.c hello.h
+$ git add hello.c hello.h
+$ edit Makefile
+$ git commit Makefile
+------------
+
+This makes a commit that records the modification to `Makefile`.
+The changes staged for `hello.c` and `hello.h` are not included
+in the resulting commit. However, their changes are not lost --
+they are still staged and merely held back. After the above
+sequence, if you do:
+
+------------
+$ git commit
+------------
+
+this second commit would record the changes to `hello.c` and
+`hello.h` as expected.
+
+After a merge (initiated by either gitlink:git-merge[1] or
+gitlink:git-pull[1]) stops because of conflicts, cleanly merged
+paths are already staged to be committed for you, and paths that
+conflicted are left in unmerged state. You would have to first
+check which paths are conflicting with gitlink:git-status[1]
+and after fixing them manually in your working tree, you would
+stage the result as usual with gitlink:git-add[1]:
+
+------------
+$ git status | grep unmerged
+unmerged: hello.c
+$ edit hello.c
+$ git add hello.c
+------------
+
+After resolving conflicts and staging the result, `git ls-files -u`
+would stop mentioning the conflicted path. When you are done,
+run `git commit` to finally record the merge:
+
+------------
+$ git commit
+------------
+
+As with the case to record your own changes, you can use `-a`
+option to save typing. One difference is that during a merge
+resolution, you cannot use `git commit` with pathnames to
+alter the order the changes are committed, because the merge
+should be recorded as a single commit. In fact, the command
+refuses to run when given pathnames (but see `-i` option).
+
+
+ENVIRONMENT VARIABLES
+---------------------
+The command specified by either the VISUAL or EDITOR environment
+variables is used to edit the commit log message.
+
+HOOKS
+-----
+This command can run `commit-msg`, `pre-commit`, and
+`post-commit` hooks. See link:hooks.html[hooks] for more
+information.
Author
------
--
1.4.4.2.g7d2d-dirty
^ permalink raw reply related
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Martin Langhoff @ 2006-12-09 5:34 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Jakub Narebski, Rogan Dawes, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <457A44ED.4080606@zytor.com>
On 12/9/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Martin Langhoff wrote:
> > I posted separately about those. And I've been mulling about whether
> > the thundering herd is really such a big problem that we need to
> > address it head-on.
>
> Uhm... yes it is.
Got some more info, discussion points or links to stuff I should read
to appreciate why that is? I am trying to articulate why I consider it
is not a high-payoff task, as well as describing how to tackle it.
To recap, the reasons it is not high payoff is that:
- the main benefit comes from being cacheable and able to revalidate
the cache cheaply (with the ETags-based strategy discussed above)
- highly distributed caches/proxies means we'll seldom see a true
cold cache situation
- we have a huge set of URLs which are seldom hit, and will never see
a thundering anything
- we have a tiny set of very popular URLs that are the key target for
the thundering herd - (projects page, summary page, shortlog, fulllog)
- but those are in the clear as soon as the caches are populated
Why do we have to take it head-on? :-)
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-09 5:09 UTC (permalink / raw)
To: Martin Langhoff
Cc: Jakub Narebski, Rogan Dawes, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <46a038f90612081852u63e05da1qe57504636f3578fd@mail.gmail.com>
Martin Langhoff wrote:
> I posted separately about those. And I've been mulling about whether
> the thundering herd is really such a big problem that we need to
> address it head-on.
Uhm... yes it is.
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: J. Bruce Fields @ 2006-12-09 4:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vpsatelvv.fsf@assigned-by-dhcp.cox.net>
On Fri, Dec 08, 2006 at 08:25:24PM -0800, Junio C Hamano wrote:
> Hmmm. I was merely trying to respond with recent requests on
> the list (might have been #git log) to make common usage
> examples more prominent. While I feel that following the UNIXy
> manpage tradition to push examples down is the right thing to
> do, you and I are not the primary audience of Porcelain
> manpages, so...
I think manpages are primarily reference documents, so it's more
important to be able to get to the list of options without paging down
too far....
We could always say "see EXAMPLES below for more detail", or "see the
chapter 3 of the tutorial/user manual/whatever".
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Michael K. Edwards @ 2006-12-09 4:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff Garzik, H. Peter Anvin, Rogan Dawes, Kernel Org Admin,
Git Mailing List, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612081648160.3516@woody.osdl.org>
On 12/8/06, Linus Torvalds <torvalds@osdl.org> wrote:
> That said, I'm not personally convinced that there is much point to using
> netfilter for transparent proxying. Why not just use separate ports for
> squid and for apache?
Just a question of whether you want to be able to yank the squid box
out if it goes pear-shaped, without touching configs on the apache
box. Some people like to stick the proxy in as a no-op at first, then
tell netfilter to divert 1% of sessions to squid and see how it holds
up, retune, ease it in, ease it out, figure out how much operational
flexibility you will have as demand continues to scale. If the squid
and apache are on the same box it's probably less of an issue.
Cheers,
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: J. Bruce Fields @ 2006-12-09 4:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7pik51b.fsf@assigned-by-dhcp.cox.net>
On Fri, Dec 08, 2006 at 03:20:32AM -0800, Junio C Hamano wrote:
> I think I went overboard and ended up not using the word
> "index", but eradicating the word was not my intention.
Yeah, "index" is a perfectly OK word, and it's already used all over the
documentation.
I think what you want to avoid is a huge digression into blobs, trees,
SHA1's, and the structure of the index file when you could just slip it
in there without a lot of fanfare, maybe like:
> +When recoring your own work, the contents of modified files in
> +your working tree are staged with gitlink:git-add[1].
^^^
...are temporarily stored to a staging area called the "index" with...
(though maybe that's a little cumbersome).
Also, I don't think there's anything wrong with the verb "stage", but I
think it may be a little less commonly used (in this meaning) than the
term "staging area", so people might catch on faster if we started with
"staging area".
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Junio C Hamano @ 2006-12-09 4:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612082141260.2630@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> Frankly I feel unconfortable with this.
>
> 1) too many examples.
>
> Yes, examples are good, but somehow there is something in the current
> text that make me feel they are not providing the clarification they
> should. Dunno... I think I'd still push them after option list.
Hmmm. I was merely trying to respond with recent requests on
the list (might have been #git log) to make common usage
examples more prominent. While I feel that following the UNIXy
manpage tradition to push examples down is the right thing to
do, you and I are not the primary audience of Porcelain
manpages, so...
> 2) explanation of how to resolve and commit a conflicting merge should
> really be found in git-merge.txt not in git-commit.txt.
>
> It feels a bit awkward to suddenly start talking about git ls-files and
> merge here.
I agree that it looks a bit out of place; the primary reason I
talked about the merge was to make it clear that a conflicted
merge will still stage the changes for cleanly auto-resolved
paths. In other words, it makes me feel uneasy that there is no
mention of it in the list in your version that follows this
sentence:
> +... All changes
> +to be committed must be explicitly identified using one of the following
> +methods:
It would make me happier if you had, at the end of enumeration,
something like:
Note that the contents of the paths that resolved
cleanly by a conflicted merge are automatically staged
for the next commit; you still need to explicitly
identify what you want in the resulting commit using one
of the above methods before concluding the merge.
Another reason I described the merge workflow is it would become
much less clear why --only is useless in merge situation if the
reader does not know that a conflicted merge stages the
auto-resolved changes.
^ permalink raw reply
* [PATCH] shortlog: fix segfault on empty authorname
From: Jeff King @ 2006-12-09 4:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0612082205240.2630@xanadu.home>
The old code looked backwards from the email address to parse the name,
allowing an arbitrary number of spaces between the two. However, in the case
of no name, we looked back too far to the 'author' (or 'Author:') header.
Instead, remove at most one space between name and address.
The bug was triggered by commit febf7ea4bed from linux-2.6.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-shortlog.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-shortlog.c b/builtin-shortlog.c
index f1124e2..7a2ddfe 100644
--- a/builtin-shortlog.c
+++ b/builtin-shortlog.c
@@ -188,7 +188,7 @@ static void read_from_stdin(struct path_list *list)
bob = buffer + strlen(buffer);
else {
offset = 8;
- while (isspace(bob[-1]))
+ if (isspace(bob[-1]))
bob--;
}
@@ -236,7 +236,7 @@ static void get_from_rev(struct rev_info *rev, struct path_list *list)
author = scratch;
authorlen = strlen(scratch);
} else {
- while (bracket[-1] == ' ')
+ if (bracket[-1] == ' ')
bracket--;
author = buffer + 7;
--
1.4.4.2.g3528-dirty
On Fri, Dec 08, 2006 at 10:23:14PM -0500, Nicolas Pitre wrote:
> On the Linux kernel repository, doing "git shortlog v2.6.18.." works
> fine. "git shortlog v2.6.17.." works fine. "git shortlog v2.6.16.." also
> works fine. But "git shortlog v2.6.15.." dies with a segmentation
> fault. Trying "git log v2.6.15.. | git shortlog" also produces the same
> crash while "git log v2.6.16.. | git shortlog" works fine.
>
> The old perl version doesn't have any such issue with those test cases,
> not even with the whole kernel history.
>
>
> Nicolas
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
^ permalink raw reply related
* Re: [PATCH] Documentation: reorganize cvs-migration.txt
From: J. Bruce Fields @ 2006-12-09 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz5yn92a.fsf@assigned-by-dhcp.cox.net>
On Thu, Dec 07, 2006 at 11:25:17PM -0800, Junio C Hamano wrote:
> Well, this does not apply at all, as I do not have a commit with
> 4fab0d7 blob and already applied the reordering patch from you.
OK, sorry for the confusion.
> Could you fix up and send again after I push out the latest?
Definitely. Is this better?
--b.
Documentation: simpler shared repository creation
Take Johannes Schindelin's suggestions for a further simplification of
the shared repository creation using git --bare init-db --shared, and
for a simplified cvsimport using an existing CVS working directory.
Also insert more man page references.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
cvs-migration.txt | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
---
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 47846bd..b657f45 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -43,8 +43,8 @@ Pull: refs/heads/master:refs/remotes/origin/master
------------
================================
-You can update the shared repository with your changes by first commiting
-your changes, and then using:
+You can update the shared repository with your changes by first committing
+your changes, and then using the gitlink:git-push[1] command:
------------------------------------------------
$ git push origin master
@@ -76,11 +76,15 @@ possibly created from scratch or from a tarball (see the
link:tutorial.html[tutorial]), or imported from an already existing CVS
repository (see the next section).
-If your project's working directory is /home/alice/myproject, you can
-create a shared repository at /pub/repo.git with:
+Assume your existing repo is at /home/alice/myproject. Create a new "bare"
+repository (a repository without a working tree) and fetch your project into
+it:
------------------------------------------------
-$ git clone -bare /home/alice/myproject /pub/repo.git
+$ mkdir /pub/my-repo.git
+$ cd /pub/my-repo.git
+$ git --bare init-db --shared
+$ git --bare fetch /home/alice/myproject master:master
------------------------------------------------
Next, give every team member read/write access to this repository. One
@@ -93,10 +97,7 @@ Put all the committers in the same group, and make the repository
writable by that group:
------------------------------------------------
-$ cd /pub
-$ chgrp -R $group repo.git
-$ find repo.git -mindepth 1 -type d |xargs chmod ug+rwx,g+s
-$ GIT_DIR=repo.git git repo-config core.sharedrepository true
+$ chgrp -R $group /pub/my-repo.git
------------------------------------------------
Make sure committers have a umask of at most 027, so that the directories
@@ -107,15 +108,15 @@ 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
-sure it is in your path. The magic command line is then
+sure it is in your path. Then cd to a checked out CVS working directory
+of the project you are interested in and run gitlink:git-cvsimport[1]:
-------------------------------------------
-$ git cvsimport -v -d <cvsroot> -C <destination> <module>
+$ git cvsimport -C <destination>
-------------------------------------------
This puts a git archive of the named CVS module in the directory
-<destination>, which will be created if necessary. The -v option makes
-the conversion script very chatty.
+<destination>, which will be created if necessary.
The import checks out from CVS every revision of every file. Reportedly
^ permalink raw reply related
* builtin git-shortlog still broken
From: Nicolas Pitre @ 2006-12-09 3:23 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
On the Linux kernel repository, doing "git shortlog v2.6.18.." works
fine. "git shortlog v2.6.17.." works fine. "git shortlog v2.6.16.." also
works fine. But "git shortlog v2.6.15.." dies with a segmentation
fault. Trying "git log v2.6.15.. | git shortlog" also produces the same
crash while "git log v2.6.16.. | git shortlog" works fine.
The old perl version doesn't have any such issue with those test cases,
not even with the whole kernel history.
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Nicolas Pitre @ 2006-12-09 2:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7pik51b.fsf@assigned-by-dhcp.cox.net>
On Fri, 8 Dec 2006, Junio C Hamano wrote:
> I attempted to rewrite the git-commit documentation.
>
> I think I went overboard and ended up not using the word
> "index", but eradicating the word was not my intention. I think
> we should hint how the index is used to implement the semantics
> somewhere near the end where it is not distracting to ordinary
> users but is accessbile by people who are interested in the
> plumbing-Porcelain interface.
[...]
Frankly I feel unconfortable with this.
1) too many examples.
Yes, examples are good, but somehow there is something in the current
text that make me feel they are not providing the clarification they
should. Dunno... I think I'd still push them after option list.
2) explanation of how to resolve and commit a conflicting merge should
really be found in git-merge.txt not in git-commit.txt.
It feels a bit awkward to suddenly start talking about git ls-files and
merge here. It would be much clearer to simply say "when done just
commit your changes as usual" in the merge doc than bringing in merge
concepts in the commit doc.
[...]
I started to insert my comments inline, but at some point it became too
messy. So I decided to give it a try of my own instead. Here what I
think would be a better direction for improving the commit man page
(would need a few examples inserted towards the end like usual, and the
env vars too):
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 517a86b..6a9cec9 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -14,25 +14,43 @@ SYNOPSIS
DESCRIPTION
-----------
-Updates the index file for given paths, or all modified files if
-'-a' is specified, and makes a commit object. The command specified
-by either the VISUAL or EDITOR environment variables are used to edit
-the commit log message.
+Use 'git commit' when you want to record your changes into the repository
+along with a log message describing what the commit is about. All changes
+to be committed must be explicitly identified using one of the following
+methods:
-Several environment variable are used during commits. They are
-documented in gitlink:git-commit-tree[1].
+1) by using gitlink:git-add[1] to incrementally "add" changes to the
+ next commit before using the 'commit' command (Note: even modified
+ files must be "added");
+2) by using gitlink:git-rm[1] to identify content removal for the next
+ commit, again before using the 'commit' command;
+
+3) by directly listing files containing changes to be committed as arguments
+ to the 'commit' command, in which cases only those files alone will be
+ considered for the commit;
+
+4) by using the -a switch with the 'commit' command to automatically "add"
+ changes from all known files i.e. files that have already been committed
+ before, and perform the actual commit.
+
+The 'git status' command can be used to obtain a summary of what is included
+by (1) and (2) for the next commit.
+
+If you make a commit and then found a mistake immediately after
+that, you can recover from it with gitlink:git-reset[1].
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
information.
+
OPTIONS
-------
-a|--all::
- Update all paths in the index file. This flag notices
- files that have been modified and deleted, but new files
- you have not told git about are not affected.
+ Tell the command to automatically stage files that have
+ been modified and deleted, but new files you have not
+ told git about are not affected.
-c or -C <commit>::
Take existing commit object, and reuse the log message
@@ -95,68 +113,18 @@ but can be used to amend a merge commit.
--
-i|--include::
- Instead of committing only the files specified on the
- command line, update them in the index file and then
- commit the whole index. This is the traditional
- behavior.
-
--o|--only::
- Commit only the files specified on the command line.
- This format cannot be used during a merge, nor when the
- index and the latest commit does not match on the
- specified paths to avoid confusion.
+ Before making a commit out of staged contents so far,
+ stage the contents of paths given on the command line
+ as well. This is usually not what you want unless you
+ are concluding a conflicted merge.
\--::
Do not interpret any more arguments as options.
<file>...::
- Files to be committed. The meaning of these is
- different between `--include` and `--only`. Without
- either, it defaults `--only` semantics.
-
-If you make a commit and then found a mistake immediately after
-that, you can recover from it with gitlink:git-reset[1].
-
-
-Discussion
-----------
-
-`git commit` without _any_ parameter commits the tree structure
-recorded by the current index file. This is a whole-tree commit
-even the command is invoked from a subdirectory.
-
-`git commit --include paths...` is equivalent to
-
- git update-index --remove paths...
- git commit
-
-That is, update the specified paths to the index and then commit
-the whole tree.
-
-`git commit paths...` largely bypasses the index file and
-commits only the changes made to the specified paths. It has
-however several safety valves to prevent confusion.
-
-. It refuses to run during a merge (i.e. when
- `$GIT_DIR/MERGE_HEAD` exists), and reminds trained git users
- that the traditional semantics now needs -i flag.
-
-. It refuses to run if named `paths...` are different in HEAD
- and the index (ditto about reminding). Added paths are OK.
- This is because an earlier `git diff` (not `git diff HEAD`)
- would have shown the differences since the last `git
- update-index paths...` to the user, and an inexperienced user
- may mistakenly think that the changes between the index and
- the HEAD (i.e. earlier changes made before the last `git
- update-index paths...` was done) are not being committed.
-
-. It reads HEAD commit into a temporary index file, updates the
- specified `paths...` and makes a commit. At the same time,
- the real index file is also updated with the same `paths...`.
-
-`git commit --all` updates the index file with _all_ changes to
-the working tree, and makes a whole-tree commit, regardless of
-which subdirectory the command is invoked in.
+ Files to be committed. If provided, only those files are
+ considered FOR COMMIT. If `-i` or `--include` is also provided
+ then the staged content is included as well.
^ permalink raw reply related
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Martin Langhoff @ 2006-12-09 2:52 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Jakub Narebski, Rogan Dawes, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <457A1962.6000401@zytor.com>
On 12/9/06, H. Peter Anvin <hpa@zytor.com> wrote:
> Martin Langhoff wrote:
> > On 12/9/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >> Perhaps gitweb should generate it's own ETag instead of messing with
> >> 'expires' header?
> >
> > That'll be the winning solution.
>
> Doesn't solve the thundering herd problem or the timeout problem at all,
> though.
I posted separately about those. And I've been mulling about whether
the thundering herd is really such a big problem that we need to
address it head-on. If we doHTTP caching headers right (that is, a
bit better than now) then the fact that web caches are distributed
means that even a cache restart or cache invalidation won't trigger a
thundering herd.
And gitweb rarely has a "new" URL that gets a ton of hits immediately.
Our real problem is the summary page, and the fact that we aren't
setting an effecting ETag there. If we do, a front-end cache plus the
ability to revalidate the ETag cheaply will get us through.
We get 99% of the benefit from ETags and cheap revalidations,
specially if they are coupled with a reverse caching proxy,. The
remaining 1% of dealing with the highly infrequent thundering herd can
be addressed with the scheme I've posted 5 minutes ago.
cheers
^ permalink raw reply
* Re: [PATCH] git-diff: Introduce --index and deprecate --cached.
From: Junio C Hamano @ 2006-12-09 2:29 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <7vac1xg61s.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Although I've applied this long time ago (in git timescale
> anyway), this patch and the above rationale is wrong.
>
> 'diff --cached' is more in line with how 'apply --cached' works,
> not how 'apply --index' works.
Side note. I do not think --index and --cached are a good pair
of words to express the different semantics (the former works on
the working tree through the index, the latter works only on the
cached data and not on the working tree). I was only pointing
out that making 'diff --index' a synonym to 'diff --cached'
closes the door for the possibility to have these two semantics
that are consistently spelled (well, maybe "confusingly
spelled", but still consistently) between diff and apply.
^ permalink raw reply
* Re: [PATCH] git-diff: Introduce --index and deprecate --cached.
From: Junio C Hamano @ 2006-12-09 2:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <20061130115913.EA36C5BA19@nox.op5.se>
Andreas Ericsson <ae@op5.se> writes:
> 'git diff --cached' still works, but its use is discouraged
> in the documentation. 'git diff --index' does the same thing
> and is consistent with how 'git apply --index' works.
Although I've applied this long time ago (in git timescale
anyway), this patch and the above rationale is wrong.
'diff --cached' is more in line with how 'apply --cached' works,
not how 'apply --index' works.
With apply, --cached and --index both tell the command to be
aware of the index, but --cached means "operate on the index,
and never look at working tree", while --index means "operate
both on the index and working tree at the same time". In
particular, the former does not care if the file in the working
tree matches the index, while the latter does.
'diff --cached' is about the tree and the index without looking
at the working tree. Since there is no mode of operation that
looks at both the index and the working tree in the underlying
diff-index, I made the mistake of applying this patch, but it is
conceivable that we may want to have a 'diff --index' that
compares HEAD, the index and the working tree, perhaps in a
combined diff format.
I think we should revert this patch.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-09 2:03 UTC (permalink / raw)
To: Martin Langhoff
Cc: Jakub Narebski, Rogan Dawes, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <46a038f90612081728s65d65ccewe64fa1a496de76fa@mail.gmail.com>
Martin Langhoff wrote:
> On 12/9/06, Jakub Narebski <jnareb@gmail.com> wrote:
>> Perhaps gitweb should generate it's own ETag instead of messing with
>> 'expires' header?
>
> That'll be the winning solution.
Doesn't solve the thundering herd problem or the timeout problem at all,
though.
-hpa
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Martin Langhoff @ 2006-12-09 1:56 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff Garzik, H. Peter Anvin, Rogan Dawes, Kernel Org Admin,
Git Mailing List, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0612081453430.3516@woody.osdl.org>
On 12/9/06, Linus Torvalds <torvalds@osdl.org> wrote:
> Actually, just looking at the examples, it looks like memcached is
> fundamentally flawed, exactly the same way Apache mod_cache is
> fundamentally flawed.
I don't know if fundamentally flawed but (having used memcached) I
don't think it's a big win for this at all.
We can make gitweb to detect mod_perl and a few smarter things if it
is running inside of it. In fact, we can (ab)use mod_perl and perl
facilities a bit to do some serialization which will be a big win for
some pages. What we need for that is to set a sensible the ETag and
use some IPC to announce/check if other apache/modperl processes are
preparing content for the same ETag. The first-process-to-announce a
given ETag can then write it to a common temp directory (atomically -
write to a temp-name and move to the expected name) while other
processes wait, polling for the file. Once the file is in place the
latecomers can just serve the content of the file and exit.
(I am calling the "state we are serving" identifier ETag because I
think we should also set it as the ETag in the HTTP headers, so well
be able to check the ETag of future requests for staleness - all we
need is a ref lookup, and if the SHA1 matches, we are sorted). So
having this 'unique request identifier' doubles up nicely...
The ETag should probably be:
- SHA1+displaytype+args for pages that display an object identified by SHA1
- refname+SHA!+displaytype+args for pages that display something
identified by a ref
- SHA1(names and sha1s of all refs) for the summary page
> You can't have a cache architecture where the client just does a "get",
> like memcached does. You need to have a "read-for-fill" operation, which
> says:
You _could_ make do with a convention of polling for "entryname" and
"workingon-entryname" and if "workingon-entryname" is set to 1, you
can expect entryname to be filled real soon now. However, memcached is
completely memorybound, so it is only nice for really small stuff or
for a large server farm which has gobs of spare ram.
(Note that memcached does have timeouts which means that the
'workingon' value could have a short timeout in case the request is
cancelled or the process dies - the nasty bit in the above plan would
be the polling.)
> I still don't understand why apache doesn't do it. I guess it wants to be
> stateless or something.
Apache doesn't do it because most web applications don't use the HTTP
procol correctly - specially when it comes to the idempotency of GET.
So in 99% of the cases, web apps serve truly different pages for the
same GET request, depending on your cookie, IP address, time-of-day,
etc.
Most websites deal with very little traffic, so this isn't a problem.
And many large sites that serve a lot of traffic from a dynamic web
app want to be serving custom ads, let you login and see your
personalised toolbar, etc,etc, so this wouldn't work for them either.
So in practice, serialising speculatively on GET requests for the same
URL has very little payoff except for static content. And that's quite
fast anyway.... specially if the underlying OS is smokin' fast ;-)
cheers,
^ permalink raw reply
* Re: [RFC] Light-weight checkouts via ".gitlink"
From: Josef Weidendorfer @ 2006-12-09 1:46 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612090053.48186.jnareb@gmail.com>
On Saturday 09 December 2006 00:53, Jakub Narebski wrote:
> Josef Weidendorfer wrote:
> > On Friday 08 December 2006 23:54, Josef Weidendorfer wrote:
> >> Jakub Narebski wrote:
> >>> NAME = name
> >
> > Forgot to mention in the proposal:
> > If you recursively have light-weight checkouts inside each other,
> > the real "name" (for .git/external/<name/ and for further submodule
> > configuration e.g. in .git/modules of the base repository)
> > should of course be the concatenation of the names in the .gitlink
> > files while going up to the base repository.
>
> Why concatenation? I thought the name would be ID of submodule,
> and should be just somehow unique.
>
> And if concatenation, pehaps some forbidden character inserted between
> them? Like '/' for example ;-)
Yes, you are right.
Nesting of submodules really is an important issue. The .gitlink
file allows us to put the submodule GITDIR somewhere in the supermodul's
GITDIR. The idea is that you can clone the submodule GITDIR if you
want. With submodule "inner" nesting inside of submodule "outer",
the GITDIR of "outer" should have the GITDIR of inner inside to allow
for cloning "outer" together with its submodule "inner".
So it is not enough to have a submodule "outer" and a submodule
"outer/inner" in the supermodule. We want
super.git/ext/outer.git/
to be the GITDIR for submodule "outer", and inside
super.git/ext/outer.git/ext/inner.git
.
Actually, it would be nice if this .gitlink proposal did not have to
deal with it. Instead, a .gitlink should be so flexible to allow such
nesting if needed.
^ permalink raw reply
* [PATCH] Add branch.*.merge warning and documentation update
From: Josef Weidendorfer @ 2006-12-09 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu006ez1i.fsf@assigned-by-dhcp.cox.net>
This patch clarifies the meaning of the branch.*.merge option.
Previously, if branch.*.merge was specified but did not match any
ref, the message "No changes." was not really helpful regarding
the misconfiguration. This patch adds a warning for this.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
---
On Saturday 09 December 2006 00:41, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > But the previous documentation simply was way to short.
>
> Yes, your documentation updates seems to make it much clearer.
>
> > Should I send a "simplified" patch?
>
> Thanks, appreciated.
Done.
Josef
Documentation/config.txt | 11 +++++++++--
git-parse-remote.sh | 11 +++++++++++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 9090762..21ec557 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -125,10 +125,17 @@ apply.whitespace::
branch.<name>.remote::
When in branch <name>, it tells `git fetch` which remote to fetch.
+ If this option is not given, `git fetch` defaults to remote "origin".
branch.<name>.merge::
- When in branch <name>, it tells `git fetch` the default remote branch
- to be merged.
+ When in branch <name>, it tells `git fetch` the default refspec to
+ be marked for merging in FETCH_HEAD. The value has exactly to match
+ a remote part of one of the refspecs which are fetched from the remote
+ given by "branch.<name>.remote".
+ The merge information is used by `git pull` (which at first calls
+ `git fetch`) to lookup the default branch for merging. Without
+ this option, `git pull` defaults to merge the first refspec fetched.
+ Specify multiple values to get an octopus merge.
pager.color::
A boolean to enable/disable colored output when the pager is in
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index da064a5..d72f061 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -134,6 +134,8 @@ canon_refs_list_for_fetch () {
# or the first one otherwise; add prefix . to the rest
# to prevent the secondary branches to be merged by default.
merge_branches=
+ found_mergeref=
+ curr_branch=
if test "$1" = "-d"
then
shift ; remote="$1" ; shift
@@ -171,6 +173,10 @@ canon_refs_list_for_fetch () {
dot_prefix= && break
done
fi
+ if test -z $dot_prefix
+ then
+ found_mergeref=true
+ fi
case "$remote" in
'') remote=HEAD ;;
refs/heads/* | refs/tags/* | refs/remotes/*) ;;
@@ -191,6 +197,11 @@ canon_refs_list_for_fetch () {
fi
echo "${dot_prefix}${force}${remote}:${local}"
done
+ if test -z "$found_mergeref" -a "$curr_branch"
+ then
+ echo >&2 "Warning: No merge candidate found because value of config option
+ \"branch.${curr_branch}.merge\" does not match any remote branch fetched."
+ fi
}
# Returns list of src: (no store), or src:dst (store)
--
1.4.4.2.g1d08-dirty
^ permalink raw reply related
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