* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Junio C Hamano @ 2006-12-08 22:34 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Santi Béjar, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <200612082301.57037.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Friday 08 December 2006 22:38, Junio C Hamano wrote:
>> "Santi Béjar" <sbejar@gmail.com> writes:
>>
>> > On 12/8/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
>> >> Clarify the meaning of branch.*.merge option and add a similar
>> >> branch.*.localmerge option, which can be used to specify a local
>> >> tracking branch to be merged by default.
>>
>> I am not so sure about the "localmerge" stuff anymore.
>>
>> What convenience would it buy us (including but not limited to
>> new people), and if there is any, would that outweigh the
>> potential confusion factor to have two different configuration
>> variables that do exactly the same thing whose sole difference
>> is which side of the fetched branch namespace it uses to specify
>> the merge source?
>
> I just came up with a concrete patch.
> I am not saying that this is the only true solution.
I admit that I do not use branch.*.merge and I do not know what
people find lacking in what Santi did in late September with
commit 5372806. What problem are we trying to solve (not a
rhetorical question -- I am truly lost here)? Is it only a
confusion between remote and local, or is there something that
cannot be expressed with the current scheme?
> Actually, Jakubs one with allowing arbitrary refspecs is nice.
> The only problem is that it is not consistent which refspec
> shortcuts otherwise, or?
Actually I had a quite opposite reaction about allowing src:dst
notation there. Does it solve any real problem? It is unclear
to me. On the other hand, it gives a false impression that it
can be used instead of remote.*.fetch to copy the remote branch
into local tracking branch, and raises other questions such as
what should happen when you have both, i.e. src:dst is given to
both remote.*.fetch and branch.*.merge, and they do not agree.
Which means it only adds to the confusion.
So I do not think it is worth spending brain cycles talking
about that particular one; it does not even have a patch to
implement it.
But you have a concrete patch, and if it is fixing a real
problem, then that is worth talking about. I just do not know
if a problem exists, other than that people can get confused and
write local tracking branch name by mistake when it should be
remote branch name.
^ permalink raw reply
* Re: [RFC] Light-weight checkouts via ".gitlink"
From: Josef Weidendorfer @ 2006-12-08 22:54 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <elco6p$uku$1@sea.gmane.org>
On Friday 08 December 2006 23:18, Jakub Narebski wrote:
> A few (very few) comments:
>
> Josef Weidendorfer wrote:
>
> > This can be implemented by enhancing git to ignore any subdirectory which
> > has a file .gitlink in it.
>
> If I remember correctly, while git ignores .git, it does not ignore
> by default (i.e. without entry in either GIT_DIR/info/excludes, or
> .gitignore) the directory which has .git directory in it.
I know. But this is essential. We _have_ to ignore all the files and
subdirectories in the directory which contains the .gitlink file,
as these files/subdirectories belong to the submodule.
There is no other way. You could try to use a special name for the
whole directory with the light-weight checkout, e.g. ".checkout".
But then, this is useless for submodules, as for submodules, we want to
be able to specify the root directory name of the submodule, as that
is the name which will end up in the tree object of the supermodule.
> And that should not change for .gitlink. You can always add
> .gitignore file with * .* patterns in it (ignore all).
That is not possible:
.gitignore file has its own meaning inside of the light-weight
checkout aka submodule, as this directory is the root directory of
a git checkout.
AFAIK, Martin's submodule support does it the same, only for directories
with .git, as he stores the GITDIR directly in the submodule
checkout.
> > * Gitdir = "<Path to base git repository>"
> [...]
> > * Name: <explicit name for this checkout>
>
> Why use once "key = value", once "key: value" form? Better to stick
> with one. I Would prefer "key = value" one.
Sorry. Typo ;-)
> GIT_DIR = path to base git repository
> it is equivalent to setting the following:
>
> GIT_INDEX_FILE = path to index file
> GIT_OBJECT_DIRECTORY = path to object directory
> GIT_HEAD_FILE = path to HEAD file
> GIT_REFS_DIRECTORY = path to refs directory
AFAIK the latter two do not exist yet, or do they?
I would also be fine with .gitlink looking like some shell script,
defining these variables. However, we need the smart directory
lookup.
And IMHO the keys can be case insensitive as in .git/config.
I am not sure we want to allow the freedom of being able to put any of
GIT_INDEX_FILE, GIT_OBJECT_DIRECTORY, GIT_HEAD_FILE, GIT_REFS_DIRECTORY
in the .gitlink file.
It is enough if GITDIR and NAME is given. With GITDIR_REAL after the
smart lookup, e.g. GIT_INDEX_FILE would default to $GITDIR_REAL/external/$NAME
and so on.
However, for submodules we really _want_ to have fully independent GITDIRs
for each submodule somewhere, and we would have to warn:
# Warning: if you change one GIT_INDEX, ... in this file, you
# will screw up the possibility to clone from the GITDIR directory
> NAME = name
> should match "name subdirectory" entry in modules file in superproject.
Yes.
This would be in my next proposal about how to build the submodule support
on light-checkouts ;-)
> Perhaps instead of adding arbitrary number of .. in front of relative
> path, we better use some magic, like ... for finding somewhere up?
I thought about it. But why whould you need it?
If the value of GITDIR in .gitlink begins with "/", it is an absolute path.
If not, I think you always want the smart lookup the go upwards, i.e.
looking for
../<relpath>.git
../../<relpath>.git
../../../<relpath>.git
So there is no need to add "..." in front of the relative path.
Or do you see a usecase for
rel/path/start/.../rel/path/end
Ah, yes, I see. Perhaps this makes sense with absolute paths:
/home/user/repos/.../linux
Josef
^ permalink raw reply
* Re: Documentation/git-commit.txt
From: Alan Chandler @ 2006-12-08 22:56 UTC (permalink / raw)
To: git
In-Reply-To: <4579529F.9030401@Intel.com>
On Friday 08 December 2006 11:55, Salikh Zakirov wrote:
> Junio Hamano wrote:
> > +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.
>
> This part is confusing as hell to anyone having any experience
> with either CVS, SVN, Hg or Monotone, as doing "corresponding `git
> add` and `git rm`" commands automatically will be interpreted as
> adding untracked files automatically, which is not the case here.
I thought the wording here was a little weird too. I think this stems
from the mistake of saying "tracked files" instead of "tracked content"
which then leads to you falling back to the git add and git rm
commands..
How about the following wording here
Instead of staging the content of each file immediately after changing
it, you can wait until you have completed all the changes you want to
make and then use the `-a` option to tell `git commit` to look for all
changes to the content it is tracking and commit it automatically. That
is, this example ...
--
Alan Chandler
^ permalink raw reply
* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Josef Weidendorfer @ 2006-12-08 23:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Santi Béjar, Aneesh Kumar K.V, Johannes Schindelin, git
In-Reply-To: <7v1wnaggp7.fsf@assigned-by-dhcp.cox.net>
On Friday 08 December 2006 23:34, Junio C Hamano wrote:
> >> What convenience would it buy us (including but not limited to
> >> new people), and if there is any, would that outweigh the
> >> potential confusion factor to have two different configuration
> >> variables that do exactly the same thing whose sole difference
> >> is which side of the fetched branch namespace it uses to specify
> >> the merge source?
> >
> > I just came up with a concrete patch.
> > I am not saying that this is the only true solution.
>
> I admit that I do not use branch.*.merge and I do not know what
> people find lacking in what Santi did in late September with
> commit 5372806. What problem are we trying to solve (not a
> rhetorical question -- I am truly lost here)? Is it only a
> confusion between remote and local, or is there something that
> cannot be expressed with the current scheme?
More or less, yes.
When this thread started, I remembered being bitten exactly by
this issue. And I only understood my problem after looking and
trying to understand the code.
Therefore, it was quite easy to come up with this patch.
IMHO, a problem really is the people do not want to read documentation.
They see the branch.*.merge option in .git/config, and try to build
their own mental model how it works.
Perhaps the warning I added now would have been enough for me to see
my error; it points at the misconfigured option. For sure, I would
have looked up the manual for the meaning of this option after seeing
the warning.
But the previous documentation simply was way to short.
Should I send a "simplified" patch?
^ permalink raw reply
* Re: [RFC] Light-weight checkouts via ".gitlink"
From: Jakub Narebski @ 2006-12-08 23:24 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200612082354.34488.Josef.Weidendorfer@gmx.de>
Dnia piątek 8. grudnia 2006 23:54, Josef Weidendorfer napisał:
> On Friday 08 December 2006 23:18, Jakub Narebski wrote:
>> A few (very few) comments:
>>
>> Josef Weidendorfer wrote:
>>
>>> This can be implemented by enhancing git to ignore any subdirectory which
>>> has a file .gitlink in it.
>>
>> If I remember correctly, while git ignores .git, it does not ignore
>> by default (i.e. without entry in either GIT_DIR/info/excludes, or
>> .gitignore) the directory which has .git directory in it.
>
> I know. But this is essential. We _have_ to ignore all the files and
> subdirectories in the directory which contains the .gitlink file,
> as these files/subdirectories belong to the submodule.
>
> There is no other way. You could try to use a special name for the
> whole directory with the light-weight checkout, e.g. ".checkout".
>
> But then, this is useless for submodules, as for submodules, we want to
> be able to specify the root directory name of the submodule, as that
> is the name which will end up in the tree object of the supermodule.
>
>> And that should not change for .gitlink. You can always add
>> .gitignore file with * .* patterns in it (ignore all).
>
> That is not possible:
> .gitignore file has its own meaning inside of the light-weight
> checkout aka submodule, as this directory is the root directory of
> a git checkout.
I have forgot about that. Right.
The only possibility would be to use GIT_DIR/info/excludes with path
to submodule, and this conflict with the ability to rename and move
submodules.
> AFAIK, Martin's submodule support does it the same, only for directories
> with .git, as he stores the GITDIR directly in the submodule
> checkout.
Ah.
[...]
>> GIT_DIR = path to base git repository
>> it is equivalent to setting the following:
>>
>> GIT_INDEX_FILE = path to index file
>> GIT_OBJECT_DIRECTORY = path to object directory
>> GIT_HEAD_FILE = path to HEAD file
>> GIT_REFS_DIRECTORY = path to refs directory
>
> AFAIK the latter two do not exist yet, or do they?
They do not exist; perhaps they should for completeness.
[...]
> It is enough if GITDIR and NAME is given. With GITDIR_REAL after the
> smart lookup, e.g. GIT_INDEX_FILE would default to $GITDIR_REAL/external/$NAME
> and so on.
Not $GITDIR_REAL/submodules/<name>/index (or modules instead of
submodules)?
>> NAME = name
>> should match "name subdirectory" entry in modules file in superproject.
>
> Yes.
> This would be in my next proposal about how to build the submodule support
> on light-checkouts ;-)
I have thought that with "each submodule as separate repository" approach
to submodules the modules file would have module name and either
subdirectory in which submodule resides, or GIT_DIR of submodule. And
this file could be generated on checkout... which doesn't survive closer
scrutiny.
But this would work well with submodules, that's a fact.
>> Perhaps instead of adding arbitrary number of .. in front of relative
>> path, we better use some magic, like ... for finding somewhere up?
>
> I thought about it. But why whould you need it?
> If the value of GITDIR in .gitlink begins with "/", it is an absolute path.
> If not, I think you always want the smart lookup the go upwards, i.e.
> looking for
>
> ../<relpath>.git
> ../../<relpath>.git
> ../../../<relpath>.git
>
> So there is no need to add "..." in front of the relative path.
> Or do you see a usecase for
> rel/path/start/.../rel/path/end
>
> Ah, yes, I see. Perhaps this makes sense with absolute paths:
>
> /home/user/repos/.../linux
You mean that the above means to check the following paths:
/home/user/repos/linux
/home/user/linux
/home/linux
/linux
not the searching subdirectories of /home/user/repos for linux
directory (there can be many)? BTW web2c implementation of TeX,
namely kpathsea(rch) uses // for that, i.e. a//b means b which
is somwehere in subdirectories of a.
--
Jakub Narebski
^ permalink raw reply
* Re: [RFC] Light-weight checkouts via ".gitlink"
From: Josef Weidendorfer @ 2006-12-08 23:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612082354.34488.Josef.Weidendorfer@gmx.de>
On Friday 08 December 2006 23:54, Josef Weidendorfer 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.
> > Perhaps instead of adding arbitrary number of .. in front of relative
> > path, we better use some magic, like ... for finding somewhere up?
No need. Something like
> /home/user/.../linux
is crazy. Do you want to scan all of your home directory everytime this
lookup is needed? So "..." really only makes sense in front of the
relative path, but there, you also can leave it out.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Linus Torvalds @ 2006-12-08 23:27 UTC (permalink / raw)
To: Jeff Garzik
Cc: H. Peter Anvin, Rogan Dawes, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <457998C8.3050601@garzik.org>
On Fri, 8 Dec 2006, Jeff Garzik wrote:
>
> This is quite nice and easy, if memory-only caching works for the situation:
> http://www.danga.com/memcached/
>
> There are APIs for C, Perl, and plenty of other languages.
Actually, just looking at the examples, it looks like memcached is
fundamentally flawed, exactly the same way Apache mod_cache is
fundamentally flawed.
Exactly like mod_perl, it appears that if something isn't cached, the
memcached server will just return "not cached" to everybody, and all the
clients will, like a stampeding herd, all do the uncached access. Even if
they have the exact same query. And you're back to square one: your server
load went through the roof.
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:
- get this cache entry
- if this cache entry does not exist, get an exclusive lock
- if you get that exclusive lock, return NULL, and the client promises
that it will fill it (inside the kernel, see for example
"find_get_page()" vs "grab_cache_page()" - the latter will return a
locked page whether it exists or not, and if it didn't exist, it will
have inserted it into the cache datastructures so that you don't have
multiple concurrent readers trying to all create different pages)
- if you block on the exclusive lock, that means that some other client
is busy fulfilling it. When you unblock, do a regular "read" operation
(not a "repeat": we only block once, and if that fails, that's it).
- any cachefill operation will release the lock (and allow pending
cache queries to succeed)
- the locking client going away will release the lock (and allow pending
cache queries to fail, and hopefully cause a "set cache" operation)
- a timeout (settable by some method) will also force-release a lock in
the case of buggy clients that do "read-for-modify" but never do the
"modify".
The "timeout" thing is to handle the case of buggy clients that crash
after trying to get - it will slow down things _enormously_ if that
happens, but hey, it's a buggy client. And it will still continue to work.
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.
(The serialization could be done by the client, but that would serialize
_everything_, and mean that a uncached lookup will hold up all the cached
ones too - which is why you do NOT want to serialize in the caller: you
really want to serialize in the layer that does the caching).
It's fairly easy to do the lock. You could just hash the lookup key using
some reasonable hash. It doesn't even have to be a _big_ hash: it's ok to
have just a few bits for lock hashing, since it's only going to be for
misses.
So hashing to eight bits and using 256 locks is probably fine, as long as
this is done by the cache server. That means that the cache server only
ever needs to track that many timeouts, for example (it also indirectly
sets a limit on the number of possible "outstanding uncached requests",
which is _exactly_ what you want - but hash collissions will also
potentially unlock the _wrong_ bucket, so if you have too many of them, it
can make the "only one outstanding unhashed request per key" not be as
effective).
So assuming you get good cache hit statistics, the locking shouldn't be a
big issue. But you definitely want to do it, because the whole point of
caching was to not do the same op multiple times.
I still don't understand why apache doesn't do it. I guess it wants to be
stateless or something.
^ permalink raw reply
* Re: [RFC] Light-weight checkouts via ".gitlink"
From: Josef Weidendorfer @ 2006-12-08 23:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612090024.17065.jnareb@gmail.com>
On Saturday 09 December 2006 00:24, Jakub Narebski wrote:
> > That is not possible:
> > .gitignore file has its own meaning inside of the light-weight
> > checkout aka submodule, as this directory is the root directory of
> > a git checkout.
>
> I have forgot about that. Right.
>
> The only possibility would be to use GIT_DIR/info/excludes with path
> to submodule, and this conflict with the ability to rename and move
> submodules.
Yes. This whole .gitlink thing more or less is about trying to
avoid as far as possible any path configuration in the supermodule
which would have to be changed when the user moves or even deletes
the submodule. Exactly for the latter, we want the GITDIR for submodules
better be separate.
> >> GIT_DIR = path to base git repository
> >> it is equivalent to setting the following:
> >>
> >> GIT_INDEX_FILE = path to index file
> >> GIT_OBJECT_DIRECTORY = path to object directory
> >> GIT_HEAD_FILE = path to HEAD file
> >> GIT_REFS_DIRECTORY = path to refs directory
> >
> > AFAIK the latter two do not exist yet, or do they?
>
> They do not exist; perhaps they should for completeness.
Actually, I am fine with allowing them in .gitlink. This makes
the whole thing much more flexible.
> [...]
> > It is enough if GITDIR and NAME is given. With GITDIR_REAL after the
> > smart lookup, e.g. GIT_INDEX_FILE would default to $GITDIR_REAL/external/$NAME
> > and so on.
>
> Not $GITDIR_REAL/submodules/<name>/index (or modules instead of
> submodules)?
Ooops, yes.
I am not actually sure what's the best name here: "external", "submodule", ... ?
I thought the the SVN name also fits for the submodule case. The submodule
is independent, and possibliy comes from an external git repository.
> >> NAME = name
> >> should match "name subdirectory" entry in modules file in superproject.
> >
> > Yes.
> > This would be in my next proposal about how to build the submodule support
> > on light-checkouts ;-)
>
> I have thought that with "each submodule as separate repository" approach
> to submodules the modules file would have module name and either
> subdirectory in which submodule resides, or GIT_DIR of submodule. And
> this file could be generated on checkout... which doesn't survive closer
> scrutiny.
Of course, that is a more simple approach. But I think the .gitlink thing
really is more flexible without being more complex.
> > Ah, yes, I see. Perhaps this makes sense with absolute paths:
> >
> > /home/user/repos/.../linux
>
> You mean that the above means to check the following paths:
>
> /home/user/repos/linux
> /home/user/linux
> /home/linux
> /linux
No.
> not the searching subdirectories of /home/user/repos for linux
> directory (there can be many)?
Yes. But you can scratch this.
^ permalink raw reply
* Re: [PATCH] Add branch.*.localmerge and documentation update
From: Junio C Hamano @ 2006-12-08 23:41 UTC (permalink / raw)
To: git
In-Reply-To: <200612090017.44105.Josef.Weidendorfer@gmx.de>
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.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Michael K. Edwards @ 2006-12-08 23:46 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/8/06, Linus Torvalds <torvalds@osdl.org> wrote:
> 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 ...
In Squid 2.6:
collapsed_forwarding on
refresh_stale_window <seconds>
(apply the latter only to stanzas where you want "readahead" of
about-to-expire cache entries)
Brief design description at http://devel.squid-cache.org/collapsed_forwarding/.
(I didn't write this code, everything I know about squid leaked
through the Google-shaped pinhole in my tinfoil hat, etc. But if you
go this way I'd like to be in the loop to understand the scalability
issues around netfilter-assisted transparent proxying.)
Cheers,
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-08 23:49 UTC (permalink / raw)
To: Michael K. Edwards
Cc: Linus Torvalds, Jeff Garzik, Rogan Dawes, Kernel Org Admin,
Git Mailing List, Jakub Narebski
In-Reply-To: <f2b55d220612081546u1ffa98e5q75be55d31da82a2f@mail.gmail.com>
Michael K. Edwards wrote:
> On 12/8/06, Linus Torvalds <torvalds@osdl.org> wrote:
>> 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 ...
>
> In Squid 2.6:
> collapsed_forwarding on
> refresh_stale_window <seconds>
> (apply the latter only to stanzas where you want "readahead" of
> about-to-expire cache entries)
>
> Brief design description at
> http://devel.squid-cache.org/collapsed_forwarding/.
>
> (I didn't write this code, everything I know about squid leaked
> through the Google-shaped pinhole in my tinfoil hat, etc. But if you
> go this way I'd like to be in the loop to understand the scalability
> issues around netfilter-assisted transparent proxying.)
>
There is another thing that probably will be required, and I'm not sure
if something in front of Apache (like Squid) rather than behind it can
easily deal with: on timeout, the process needs to continue in order to
feed the cache. Otherwise, you're still in a failure scenario as soon
as timeout happens.
^ permalink raw reply
* Re: [RFC] Light-weight checkouts via ".gitlink"
From: Jakub Narebski @ 2006-12-08 23:53 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200612090025.24234.Josef.Weidendorfer@gmx.de>
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 ;-)
>>> Perhaps instead of adding arbitrary number of .. in front of
>>> relative path, we better use some magic, like ... for finding
>>> somewhere up?
>
> No need. Something like
>
>> /home/user/.../linux
>
> is crazy. Do you want to scan all of your home directory everytime
> this lookup is needed? So "..." really only makes sense in front of
> the relative path, but there, you also can leave it out.
No. I meant /home/user/.../linux to mean searching for
/home/user/linux
/home/linux
/linux
but I don't think it is useful. As to relative path matching in any
parent directory... well, that differs only in direction (up instead of
down) in matching filename in .gitignore when path does not contain /
(well, actually it is taken as fileglob).
--
Jakub Narebski
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Seth Falcon @ 2006-12-08 23:59 UTC (permalink / raw)
To: git
In-Reply-To: <200612082310.24140.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> On Friday 08 December 2006 21:45, Luben Tuikov wrote:
>> This is how perforce does it*, and while it is useful, git is NOT perforce,
>> and I agree with Junio and Jakub.
>
> However, the idea itself is not bad. AFAIK, cogito does it this way.
> It could be done as separate command, e.g. "git add --interactive",
> and would only update the index.
I think such a feature could be quite useful and it would seem to be
an easy thing to provide in an optional or configurable fashion so
that those that don't like it could avoid it.
Spelling out a bunch of files spread around your tree for update-index
can be annoying. Some way of marking a list seems natural. Maybe
that is a separate issue.
+ seth
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Jakub Narebski @ 2006-12-09 0:07 UTC (permalink / raw)
To: git
In-Reply-To: <m2lkli9bwv.fsf@ziti.local>
Seth Falcon wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
>> On Friday 08 December 2006 21:45, Luben Tuikov wrote:
>>> This is how perforce does it*, and while it is useful, git is NOT perforce,
>>> and I agree with Junio and Jakub.
>>
>> However, the idea itself is not bad. AFAIK, cogito does it this way.
>> It could be done as separate command, e.g. "git add --interactive",
>> and would only update the index.
>
> I think such a feature could be quite useful and it would seem to be
> an easy thing to provide in an optional or configurable fashion so
> that those that don't like it could avoid it.
>
> Spelling out a bunch of files spread around your tree for update-index
> can be annoying. Some way of marking a list seems natural. Maybe
> that is a separate issue.
Perhaps git-commit should also accept --exclude=<pattern> option?
Would that help?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Michael K. Edwards @ 2006-12-09 0:18 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Linus Torvalds, Jeff Garzik, Rogan Dawes, Kernel Org Admin,
Git Mailing List, Jakub Narebski
In-Reply-To: <4579F9FF.7050701@zytor.com>
On 12/8/06, H. Peter Anvin <hpa@zytor.com> wrote:
> There is another thing that probably will be required, and I'm not sure
> if something in front of Apache (like Squid) rather than behind it can
> easily deal with: on timeout, the process needs to continue in order to
> feed the cache. Otherwise, you're still in a failure scenario as soon
> as timeout happens.
I would think this would be a great deal easier to handle in an
arm's-length "accelerator" than in the origin server. Only restart
the hit to the origin server if you think that something has actually
gone wrong there. Serve stale data to the client if you have to.
From the page I quoted:
"In addition an option to shortcut the cache revalidation of
frequently accessed objects is added, making further requests
immediately return as a cache hit while a cache revalidation is
pending. This may temporarily give slightly stale information to the
clients, but at the same time allows for optimal response time while a
frequently accessed object is being revalidated. This too is an
optimization only intended for accelerators, and only for accelerators
where minimizing request latency is morer important than freshness."
I don't know how sophisticated this logic is currently, but I would
think that it wouldn't be that hard to tune up.
Cheers,
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-09 0:23 UTC (permalink / raw)
To: Michael K. Edwards
Cc: Linus Torvalds, Jeff Garzik, Rogan Dawes, Kernel Org Admin,
Git Mailing List, Jakub Narebski
In-Reply-To: <f2b55d220612081618v26f7c714l7d4ea5315a964aa@mail.gmail.com>
Michael K. Edwards wrote:
> On 12/8/06, H. Peter Anvin <hpa@zytor.com> wrote:
>> There is another thing that probably will be required, and I'm not sure
>> if something in front of Apache (like Squid) rather than behind it can
>> easily deal with: on timeout, the process needs to continue in order to
>> feed the cache. Otherwise, you're still in a failure scenario as soon
>> as timeout happens.
>
> I would think this would be a great deal easier to handle in an
> arm's-length "accelerator" than in the origin server
True, but it needs to run behind Apache rather than in front of it.
-hpa
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Seth Falcon @ 2006-12-09 0:37 UTC (permalink / raw)
To: git
In-Reply-To: <elcujo$g61$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Seth Falcon wrote:
>> Spelling out a bunch of files spread around your tree for update-index
>> can be annoying. Some way of marking a list seems natural. Maybe
>> that is a separate issue.
>
> Perhaps git-commit should also accept --exclude=<pattern> option?
> Would that help?
I don't think I understand what an --exclude=<pattern> option would
do, but I'm pretty sure it doesn't help the use case I'm thinking of:
Editing away, you've made changes in 8 files.
Reviewing diff, you want to commit 6 of those and continue working
on the other two.
It seems that there could be a less manual way than
git update-index f1 f2 ... f6
Hmm, maybe I could do:
git diff --name-only > changed
## edit changed
cat changed|xargs git update-index
I suppose this could be wrapped in a simple way to bring up an editor.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Linus Torvalds @ 2006-12-09 0:45 UTC (permalink / raw)
To: Jeff Garzik
Cc: H. Peter Anvin, Rogan Dawes, Kernel Org Admin, Git Mailing List,
Jakub Narebski
In-Reply-To: <4579FABC.5070509@garzik.org>
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.
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".
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-09 0:47 UTC (permalink / raw)
To: Linus Torvalds
Cc: Jeff Garzik, 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:
>
> 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".
>
Yup, DNS does this, and it's a Very Good Thing.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Linus Torvalds @ 2006-12-09 0:49 UTC (permalink / raw)
To: Michael K. Edwards
Cc: Jeff Garzik, H. Peter Anvin, Rogan Dawes, Kernel Org Admin,
Git Mailing List, Jakub Narebski
In-Reply-To: <f2b55d220612081546u1ffa98e5q75be55d31da82a2f@mail.gmail.com>
On Fri, 8 Dec 2006, Michael K. Edwards wrote:
>
> In Squid 2.6:
> collapsed_forwarding on
> refresh_stale_window <seconds>
> (apply the latter only to stanzas where you want "readahead" of
> about-to-expire cache entries)
Yeah, those look like the Right Thing (tm) to do.
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?
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: H. Peter Anvin @ 2006-12-09 0:51 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael K. Edwards, Jeff Garzik, 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:
>
> On Fri, 8 Dec 2006, Michael K. Edwards wrote:
>> In Squid 2.6:
>> collapsed_forwarding on
>> refresh_stale_window <seconds>
>> (apply the latter only to stanzas where you want "readahead" of
>> about-to-expire cache entries)
>
> Yeah, those look like the Right Thing (tm) to do.
>
> 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?
>
Yeah, this is pretty trivial since one can just do redirects. However,
I still think a backend cache is better, since it can detach itself from
Apache when appropriate (e.g. the background refresh scenario, or timeout.)
^ permalink raw reply
* Re: git-commit: select which files to commit while editing the commit message
From: Junio C Hamano @ 2006-12-09 0:59 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m2d56taoqu.fsf@ziti.local>
Seth Falcon <sethfalcon@gmail.com> writes:
> I don't think I understand what an --exclude=<pattern> option would
> do, but I'm pretty sure it doesn't help the use case I'm thinking of:
>
> Editing away, you've made changes in 8 files.
>
> Reviewing diff, you want to commit 6 of those and continue working
> on the other two.
>
> It seems that there could be a less manual way than
> git update-index f1 f2 ... f6
>
>
> Hmm, maybe I could do:
>
> git diff --name-only > changed
> ## edit changed
> cat changed|xargs git update-index
>
> I suppose this could be wrapped in a simple way to bring up an editor.
Note that output of cat piped to anything is almost always a bad
programming ;-)
Maybe the "git add --interactive" would give you a transcript
like this:
$ git add --interactive '*.c' '*.h'
showing list of modified files...
1) bozbar.c 2) filfre.c 3) frotz.h 4) nitfol.c 5) rezrov.h
6) xyzzy.c 7) yomin.h 8) z.c
choice> 2 3 5 6 7
showing list of modified files...
1) bozbar.c 2* filfre.c 3* frotz.h 4) nitfol.c 5* rezrov.h
6* xyzzy.c 7* yomin.h 8) z.c
choice> 4+
showing "git diff -- nitfol.c"...
diff --git a/nitfol.c b/nitfol.c
@@ -22,x +22,y @@
{
- int i;
+ long i;
+ i = 314;
stage this hunk [Yes/No/All/Done]? y
...
The latter half is to come up with a subset of diff and then run
"git-apply --cached" to update only the index with the chosen
hunks.
^ permalink raw reply
* Re: [PATCH] Allow building GIT in a different directory from the source directory
From: Alex Riesen @ 2006-12-09 1:16 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <elc6j2$vej$1@sea.gmane.org>
Han-Wen Nienhuys, Fri, Dec 08, 2006 18:15:25 +0100:
> -my %pm = ('Git.pm' => '$(INST_LIBDIR)/Git.pm');
> +
> +$src_prefix = '';
> +if (!($ENV{'PERL_SRCDIR'} eq "")) {
> + $src_prefix = $ENV{'PERL_SRCDIR'} . "/"
> +}
Hurts my eyes :)
$src_prefix = defined($ENV{PERL_SRCDIR}) ? "$ENV{PERL_SRCDIR}/": '';
could be shorter, unless you want (you do) strict syntax check.
^ permalink raw reply
* Re: kernel.org mirroring (Re: [GIT PULL] MMC update)
From: Martin Langhoff @ 2006-12-09 1:28 UTC (permalink / raw)
To: Jakub Narebski
Cc: Rogan Dawes, H. Peter Anvin, Linus Torvalds, Kernel Org Admin,
Git Mailing List, Petr Baudis
In-Reply-To: <200612081438.25493.jnareb@gmail.com>
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. A combination of
- cache SHA1-based requests forever
- cache ref-based requests a longish time, setting an ETag that
contains headname+SHA1
- on 'revalidate', check the ETag vs the ref and only recompute if
things have changed
In the meantime, the code on kernel.org needs to be updated to the
latest gitweb. On our server, I'd say the newer gitweb is 3~4 times
faster serving the "expensive" summary pages. And much smarter in
terms of caching headers.
cheers
^ 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