* Re: [RFC 1/2] Use remote information in .git/config
From: Ben Clifford @ 2005-11-24 22:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v4q65sst3.fsf@assigned-by-dhcp.cox.net>
On 22 Nov 2005, at 05:29, Junio C Hamano wrote:
>
> Personally I do not mind moving remotes/branches information
> there, except that I suspect the git-config-set interface makes
> it cumbersome to (1) find out what remotes I defined (i.e. an
> equivalent of "ls .git/remotes")
(1) is useful to be able to do in a very lightweight way when doing
tab completion on remotes. Having heads, tags, remotes in nicely
named separate files makes that pretty straightforward; I don't know
if using a git-config- accessor would make this noticeably worse,
though, as I haven't tried anything out there yet.
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Re: Problem merging
From: Ben Clifford @ 2005-11-24 10:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0511231546330.8191@wbgn013.biozentrum.uni-wuerzburg.de>
On 24 Nov 2005, at 00:49, Johannes Schindelin wrote:
>
> I think nobody is. Since there are infinitely many files having the
> same
> SHA1 (pigeon-hole principle),
>
hmm... pigeon-hole principle is just that there exists two files that
have the same SHA-1 as each other... doesn't say anything about *all*
SHA-1s, though?
--
Ben • ベン • Бэн • 벤 • 班明
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS number(s) at above URL.
^ permalink raw reply
* Re: [PATCH] Support username and password inside URL
From: Junio C Hamano @ 2005-11-24 23:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511242321500.26651@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> even if HTTP authentication is not really strong, we could permit at least
> the username to be specified. The password could come from .netrc. In this
> manner, it would be possible to use different user names on the same
> server.
I did not say HTTP authentication in general is not adequate (I
did say that at least digest should be used not basic, though).
How well does curl work with username but without password in a
UR,(e.g. http://joe@host.example.com/frotz/nitfol)?
^ permalink raw reply
* Re: [PATCH] Support username and password inside URL
From: Johannes Schindelin @ 2005-11-24 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kalle Valo, git
In-Reply-To: <7vbr09n16w.fsf@assigned-by-dhcp.cox.net>
Hi,
even if HTTP authentication is not really strong, we could permit at least
the username to be specified. The password could come from .netrc. In this
manner, it would be possible to use different user names on the same
server.
I don't have a need for this, though.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Support username and password inside URL
From: Junio C Hamano @ 2005-11-24 22:14 UTC (permalink / raw)
To: Kalle Valo; +Cc: git
In-Reply-To: <87d5kraxsr.fsf@litku.valo.iki.fi>
Kalle Valo <Kalle.Valo@iki.fi> writes:
> Actually I'm going to be only user of the private git repository and
> it's going to be permanent. I have multiple computers in different
> locations (servers, workstations, laptops) and I would like to
> distribute my private files (configuration files, scripts etc.) to all
> of them using git.
Fair enough. Is "git-push ssh://these.machines/" (or from
these.machines "git-fetch ssh://mother.ship/") more trouble than
having HTTP server on your mother ship machine?
> ... The problem with randomized URL (like you
> suggested) is that if some person or a search engine finds the URL
> somehow, then there's nothing stopping the information leak.
Hmph. I had an impression that the obscure URL scheme like in
my example http://members.cox.net/junkio/r0ZIEF/5S54m/ is as
robot safe as auth embedding URL. That is, if somebody feeds
auth-embedding URL to robots I suspect they can follow it just
fine. Of course obscure URL needs to be protected by forbidding
dirindex at higher level directories and not posting it to
public forum [*1*], for the same reason you have to keep the
auth embedding URL from public.
[Footnote]
*1* I suspect some robots have already tried to harvest what is
found at that URL since I posted the message to the list.
^ permalink raw reply
* Re: [PATCH] Rename git-config-set to git-repo-config
From: Johannes Schindelin @ 2005-11-24 21:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzjtn3h1.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 455 bytes --]
Hi,
On Thu, 24 Nov 2005, Junio C Hamano wrote:
> - Natively, they work only from the project toplevel. Period.
How about changing *that*? Like, define a GIT_CWD_PREFIX, and checking in
the C parts?
After all, the biggest problem with the scripts in a subdirectory is that
they do not necessarily know which parameter means what, i.e. when to
prefix it and when not.
A small helper a là git_path() should do, right?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Rename git-config-set to git-repo-config
From: Junio C Hamano @ 2005-11-24 21:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511241419390.14297@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Well, there are differences:
Thanks; I took yours (big thanks to Tony for teaching us how
great topic branches are -- I can just blow my "hold/repoconfig"
branch which had only one patch away, apply yours to "master"
and merge with other topics), with one minor adjustment.
> - I did not adjust the length of the "=====" line in the dox,
In "make doc", asciidoc barfs if they do not match, so I
adjusted this.
> Well, I don't use Emacs any longer, since it was such a hassle to install
> it on every machine. I still like it, though.
I do not encourge use of Emacs to others; I was using it as an
excuse for not debugging nor testing it personally myself ;-).
> As for git-mv: looks like we need a "git-perl-setup.perl", right?
Depends on what that git-$lang-setup.$lang does, but I am not
quite sure. Currently, using git-sh-setup implies you run only
from toplevel, with fairly convoluted logic.
I was looking at git-sh-setup does for the last couple of days;
and it is really hard to decide what the best approach is to
make various pieces subdirectory safe.
Currently git C-level tools works like this:
- Natively, they work only from the project toplevel. Period.
- GIT_DIR defaults to ".git". GIT_OBJECT_DIRECTORY defaults
to "$GIT_DIR/objects".
- If GIT_DIR environment variable does not exist, tools that
use setup_git_directory() try to find a directory that has a
subdirectory that looks like a valid GIT_DIR, and chdir() to
that directory. They remember the relative path from the new
cwd() to the original. If you started from a subdirectory,
they work at the toplevel, but know where it came from
e.g. "Documentation/howto/".
The users of setup_git_directory() are responsible for
prepending that relative path to user supplied repository
relative pathnames. Two functions, prefix_path() and
get_pathspec(), are supplied to help this process.
If GIT_DIR environment variable exists, setup_git_directory()
does not do any ".git/" discovery (there is no point doing so
because the user told us where it is). HOWEVER, as a side
effect of having GIT_DIR, they cannot know where their
current directory is relative to the project toplevel. IOW,
they require to be started at the project toplevel if GIT_DIR
environment variable exists, and I think this behaviour is
the only one that makes sense [*1*].
- The ones that use enter_repo() takes user supplied path,
chdir() to it and sets GIT_DIR=. environment. They work in
naked repository without associated working tree so this is a
sane behaviour.
- The ones that use neither assume that they are at the project
toplevel if they need to access working tree.
Among the scripts, the ones that do _not_ use git-sh-setup but
can work in subdirectories work this way:
- Do not do project toplevel discovery, do not do chdir.
- Use only tools that use setup_git_directory().
- If an access to ".git" is needed, find out where it is by
running "git-rev-parse --git-dir", but _do_ _not_ export it
as GIT_DIR; otherwise the tools that use
setup_git_directory() would not work as expected.
- They do _not_ work from subdirectory if the user has GIT_DIR
environment set [*2*].
The ones that do use git-sh-setup can use GIT_DIR shell variable
given by git-sh-setup, but git-sh-setup does _not_ export it
(very important). If GIT_DIR environment was given by the user,
the commands would not work from subdirectory because many
C-level tools they use have setup_git_directory() internally as
mentioned before. Otherwise, GIT_DIR is set to .git by this
script, which means these commands can run from the toplevel
only.
[Footnote]
*1* This is because GIT_DIR can point at totally out-of-tree.
Your working tree can live in tmpfs filesystem and GIT_DIR on
safer location. You may lose uncommitted changes in exchange
for etter filesystem performance this way.
We _could_ special case when GIT_DIR is set to "/some/path/.git"
and "/some/path/" is (grand)*parent directory of the current
directory (e.g. /some/path/Documentation/howto), and do the
usual chdir() + prefix, but I suspect this leads to more
confusion not less. The rules when things work and do not in
subdirectories become too complex.
*2* This cannot be helped; see *1* above.
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Junio C Hamano @ 2005-11-24 21:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Ed Tomlinson, git, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0511241154340.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Since git-pack-objects has to generate the pack _anyway_, it might as well
> save it away when it does - so that if you have lots of people doing
> clones or pulling, you'd only need to run it once for a particular set of
> objects, and you'd not have to do any extra (or unnecessary) maintenance.
Caching itself is relatively easy (just implement an equivalent
of tee inside pack-objects ourselves). More problematic is
pruning. We could do it from cron based on atime _if_ the
filesystem is not mounted noatime but without arranging a
reasonably way for automated pruning this would become a disk
hog and extra maintenance burden, which is why I did not
implement the dynamic caching part in the initial round.
Since git-daemon would be the primary user of pack-cache/, this
implies a repository writable by git-daemon user on public
machine (not master), which is an extra thing to note.
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Linus Torvalds @ 2005-11-24 19:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Andreas Ericsson, Ed Tomlinson, git, Linux Kernel Mailing List
In-Reply-To: <7v4q61suhi.fsf@assigned-by-dhcp.cox.net>
On Thu, 24 Nov 2005, Junio C Hamano wrote:
>
> Performance perceived by cloners is helped by
>
> $ mkdir -p .git/pack-cache
> $ git-rev-list --objects --all | git-pack-objects .git/pack-cache/pack
That really doesn't work very well. I push to that tree often several
times a day, and you'd have to re-do the cache each time.
So it would be much better if git-pack-objects would just always cache its
output in .git/pack-cache - along with some logic to just get rid of old
ones regularly.
Since git-pack-objects has to generate the pack _anyway_, it might as well
save it away when it does - so that if you have lots of people doing
clones or pulling, you'd only need to run it once for a particular set of
objects, and you'd not have to do any extra (or unnecessary) maintenance.
Linus
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Nick Hengeveld @ 2005-11-24 19:52 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ed Tomlinson, Junio C Hamano, git, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0511241020050.13959@g5.osdl.org>
On Thu, Nov 24, 2005 at 10:37:15AM -0800, Linus Torvalds wrote:
> I just repacked and updated it now, so how http should work too, although
> inefficiently (because it will get a whole new pack - just one of the
> disadvantages of the non-native protocols).
There's room to improve on that particular inefficiency. The http
commit walker could use Range: headers to fetch loose objects directly
from inside a pack if it didn't make sense to fetch the entire pack.
For this to work, pack fetches would need to be deferred until the
entire tree had been walked, and the commit walker could decide whether
to fetch the pack or loose objects based on the percentage of packed
objects it needed to fetch. It would also need to fetch all
tag/commit/tree objects using ranges to be able to fully walk the tree.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Junio C Hamano @ 2005-11-24 19:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andreas Ericsson, Ed Tomlinson, git, Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0511241037400.13959@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> (This is in no way really fundamental, and the server could cache the
> packs it generates for initial clones, but that isn't implemented yet, and
> probably won't be for some times).
Performance perceived by cloners is helped by
$ mkdir -p .git/pack-cache
$ git-rev-list --objects --all | git-pack-objects .git/pack-cache/pack
on the server side. This exact example of preparing by the
repository maintainer is optimizing for a wrong case, and I do
not think it is worth doing in practice, but this will give you
the lower bound when server side cache is implemented to do it
on demand.
^ permalink raw reply
* Re: [PATCH 1/9] archimport: first, make sure it still compiles
From: Linus Torvalds @ 2005-11-24 18:54 UTC (permalink / raw)
To: Eric Wong; +Cc: Martin Langhoff, git list, Martin Langhoff
In-Reply-To: <20051124074739.GB4789@mail.yhbt.net>
Eric,
I don't know about Junio, but if I were him, I'd have preferred that all
your patches had a
archimport: ..
prefix in the subject line, not just the first one.
For example, if you just merge the patches as-is now, and then look at the
end result with gitk (or any of the tools that show the shortlog format:
just the first line of the commit), you get explanations like
fix -t tmpdir switch
which is clearly _correct_, but it's much nicer if they show which area
was implied, ie
archimport: fix -t tmpdir switch
so that you can tell from the shortlog whether it was a "global" change,
or somethign that affected a specific program.
Just a suggestion,
Linus
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Linus Torvalds @ 2005-11-24 18:44 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Ed Tomlinson, Junio C Hamano, git, Linux Kernel Mailing List
In-Reply-To: <4385BAFC.7070906@op5.se>
On Thu, 24 Nov 2005, Andreas Ericsson wrote:
>
> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 2.6
>
> which works flawlessly for me although it takes quite some time to transfer
> all the data.
The initial clone is very expensive for the native git protocol: the
protocol is designed to scale well for incremental updates (ie you have a
_huge_ repository that has changed just a bit, and the protocol should
work well for that), and that makes the initial clone quite expensive as
it marshalls the whole damn repository into this nice packed format.
So it's often nicer (certainly on the remote server) to use "rsync" for
the initial clone, and then only after that start using the git protocol.
(This is in no way really fundamental, and the server could cache the
packs it generates for initial clones, but that isn't implemented yet, and
probably won't be for some times).
Of course, especially if you're mostly bandwidth-constrained and the
server side is not under a big load, using the native git protocol may
actually be faster anyway. Because it's always going to generate the
nicest packing, while rsync:// will just use whatever packing that the
server happens to have at that point (but I do repack every few weeks, so
rsync for the initial clone should never be horribly bad - and since I
just repacked, it should get that "perfect" pack too).
Linus
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Linus Torvalds @ 2005-11-24 18:37 UTC (permalink / raw)
To: Ed Tomlinson; +Cc: Junio C Hamano, git, Linux Kernel Mailing List
In-Reply-To: <200511240737.59153.tomlins@cam.org>
On Thu, 24 Nov 2005, Ed Tomlinson wrote:
>
> What is happening?
The http transport isn't very good for git, so git adds various special
files to make it work at all. They need to be specially updated, and I
hadn't done that.
Using the native git protocol through git://git.kernel.org/.. gets around
it, as does using rsync.
I just repacked and updated it now, so how http should work too, although
inefficiently (because it will get a whole new pack - just one of the
disadvantages of the non-native protocols).
Linus
^ permalink raw reply
* Re: [PATCH] Rename git-config-set to git-repo-config
From: Johannes Schindelin @ 2005-11-24 13:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xveth4l.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 24 Nov 2005, Junio C Hamano wrote:
> Thanks for the patch. I unfortunately was doing the same,
> because I wanted to get the repo-format-validation stuff into a
> presentable shape, and I thought this would interfere with it
> and wanted to do it first (fortunately it didn't). They are
> both in the proposed updates branch. At a quick glance, I think
> your patch is identical to what I did (there aren't that many
> different ways to rename a command after all).
Well, there are differences:
- I did not adjust the length of the "=====" line in the dox,
- I adjusted the punch line to "Get and set options in .git/config."
(both in git-repo-config and git, but you have it in git, exchanged...),
and
- I did not rename the usage string in repo-config.c.
> At least we should work on 5.6, if not 5.5.
Agree. I don't find too many bad things about
open F, 'git-ls-files -z |' or die 'blabla';
> I do not use git-mv myself. It does not work in subdirectories,
> and typing Documentation/ twice to move just one file is a
> chore, so I tend to just 'R' (rename) the file, move to the
> renamed file, and '!' (run shell command on the specified path)
> with 'git-add', all within a single Emacs dired buffer.
Well, I don't use Emacs any longer, since it was such a hassle to install
it on every machine. I still like it, though.
As for git-mv: looks like we need a "git-perl-setup.perl", right?
> An option to git-format-patch _might_ make sense someday. Maybe
> after the world domination ;-).
>
> Oh, wait. It already can produce renaming patches, just does
> not do it by default.
>
> Junio "again I forgot what I implemented before;
> sheesh I even used it myself to feed some patches
> to Linus" Hamano
*grin* Thanks for pointing that out, Oh Merciful Maintainer (OMM)!
Ciao,
Dscho "trying to find a place to put his flagellations which is hard in
the absence of a last name in his typical signature"
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Andreas Ericsson @ 2005-11-24 13:07 UTC (permalink / raw)
To: Ed Tomlinson
Cc: Linus Torvalds, Junio C Hamano, git, Linux Kernel Mailing List
In-Reply-To: <200511240737.59153.tomlins@cam.org>
Ed Tomlinson wrote:
> Something strange here. After a cg-update, I had no tag for rc2. Checking
> showed no problems so I used cg-clone to get another copy of the repository.
> Still no rc2.
>
> ed@grover:/usr/src/2.6$ cg-version
> cogito-0.16rc2 (73874dddeec2d0a8e5cd343eec762d98314def63)
> ed@grover:/usr/src/2.6$ git --version
> git version 0.99.9.GIT
>
> cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 2.6
>
This happened a while ago to someone else too. Apparently the http
transport needs serverside help (git-update-server-info or some such
must be run on the remote side).
Unless you're restricted by firewalls and other you could try
git clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 2.6
which works flawlessly for me although it takes quite some time to
transfer all the data.
Linus, HPA: Are the packs cached on kernel.org? It seems to be at least
a minute before the transfers start.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Linux 2.6.15-rc2
From: Ed Tomlinson @ 2005-11-24 12:37 UTC (permalink / raw)
To: Linus Torvalds, Junio C Hamano, git; +Cc: Linux Kernel Mailing List
In-Reply-To: <Pine.LNX.4.64.0511191934210.8552@g5.osdl.org>
On Saturday 19 November 2005 22:40, Linus Torvalds wrote:
> There it is (or will soon be - the tar-ball and patches are still
> uploading, and mirroring can obviously take some time after that).
Something strange here. After a cg-update, I had no tag for rc2. Checking
showed no problems so I used cg-clone to get another copy of the repository.
Still no rc2.
ed@grover:/usr/src/2.6$ cg-version
cogito-0.16rc2 (73874dddeec2d0a8e5cd343eec762d98314def63)
ed@grover:/usr/src/2.6$ git --version
git version 0.99.9.GIT
cg-clone http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 2.6
It looks to be the tag that is missing, gitk show commits after Nov 19.
Both git and cg were updated just prior to the cg-update (~Nov 22 8pm EST).
What is happening?
TIA
Ed Tomlinson
^ permalink raw reply
* Re: [PATCH] Rename git-config-set to git-repo-config
From: Junio C Hamano @ 2005-11-24 11:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511241127020.12985@wbgn013.biozentrum.uni-wuerzburg.de>
Thanks for the patch. I unfortunately was doing the same,
because I wanted to get the repo-format-validation stuff into a
presentable shape, and I thought this would interfere with it
and wanted to do it first (fortunately it didn't). They are
both in the proposed updates branch. At a quick glance, I think
your patch is identical to what I did (there aren't that many
different ways to rename a command after all).
> Sorry, git-mv did not work on my system. I can now confirm that
> there is *at least* one perl 5.6 version out there which does not
> like lists in open statements at all. Grmpf.
Yeah, perl5.8delta says that is 5.8 feature. As discussed on
the list with Merlyn, we have a fair amount of backporting, I
suspect. At least we should work on 5.6, if not 5.5.
I do not use git-mv myself. It does not work in subdirectories,
and typing Documentation/ twice to move just one file is a
chore, so I tend to just 'R' (rename) the file, move to the
renamed file, and '!' (run shell command on the specified path)
with 'git-add', all within a single Emacs dired buffer.
> Further grpmf: Is it intended behaviour that git-diff *detects*
> renames, while git-format-patch *doesn't*?
I do not want to force all the kernel subsystem maintainers to
use git (namely, git-apply) to process e-mails, so format-patch
should not default to git specific renaming patches.
An option to git-format-patch _might_ make sense someday. Maybe
after the world domination ;-).
Oh, wait. It already can produce renaming patches, just does
not do it by default.
Junio "again I forgot what I implemented before;
sheesh I even used it myself to feed some patches
to Linus" Hamano
^ permalink raw reply
* Re: files are disappearing in git
From: Nico -telmich- Schottelius @ 2005-11-24 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfypmwgny.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]
Junio C Hamano [Thu, Nov 24, 2005 at 01:15:13AM -0800]:
> Nico -telmich- Schottelius <nico-linux-git@schottelius.org> writes:
>
> > Linus Torvalds [Wed, Nov 23, 2005 at 09:20:28AM -0800]:
> >> On Wed, 23 Nov 2005, Nico -telmich- Schottelius wrote:
> >>...
> >> I bet somebody just messed up the index before that commit.
> >
> > What would be the best things to corrupt the index?
> > Our developers here do the following each day:
> >
> > - cg-update
> > - <work>
> > - cg-commit
> > - cg-update + merge if there are changes
> > - cg-push origin
>
> Was any of the CG:F line changed/removed by the developer during
> cg-commit?
He said it could be possible. In fact the situation that we delete those lines
are not so seldem.
> Does any of the files under Code/Spikes/Statistik/ have funny
> characters in their pathnames?
No:
Code/Spikes/Statistik/Project.dpr [new file with mode: 0644] blob
Code/Spikes/Statistik/Statistik.pas [new file with mode: 0644] blob
Code/Spikes/Statistik/Statistik.xfm [new file with mode: 0644] blob
Nico
--
Latest project: cinit-0.2.1 (http://linux.schottelius.org/cinit/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: Why not clone to a remote directory over SSH
From: Johannes Schindelin @ 2005-11-24 10:36 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Andreas Ericsson, git
In-Reply-To: <20051124010409.GQ3968@reactrix.com>
Hi,
On Wed, 23 Nov 2005, Nick Hengeveld wrote:
> On Thu, Nov 24, 2005 at 12:45:18AM +0100, Johannes Schindelin wrote:
>
> > For that matter, is it possible to generate the file(s) needed for a dumb
> > server on the client side?
>
> Which files are those? I've been working on a way to update info/refs
> and eventually objects/info/packs.
These I meant.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Rename git-config-set to git-repo-config
From: Johannes Schindelin @ 2005-11-24 10:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vsltmwiky.fsf@assigned-by-dhcp.cox.net>
... and adjust all references.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Thu, 24 Nov 2005, Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > git-config-set handles configuration for a particular repo, so
> > git-repo-config is better, IMO.
>
> Ok, so git-repo-config that is. Johannes?
Sorry, git-mv did not work on my system. I can now confirm that
there is *at least* one perl 5.6 version out there which does not
like lists in open statements at all. Grmpf.
Further grpmf: Is it intended behaviour that git-diff *detects*
renames, while git-format-patch *doesn't*?
.gitignore | 2 +
Documentation/git-repo-config.txt | 36 +++++++++++++-------------
Documentation/git.txt | 6 ++--
Makefile | 2 +
repo-config.c | 2 +
t/t1300-repo-config.sh | 52 +++++++++++++++++++------------------
6 files changed, 50 insertions(+), 50 deletions(-)
diff --git a/.gitignore b/.gitignore
index 074ebe9..0876525 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,7 +17,6 @@ git-clone
git-clone-pack
git-commit
git-commit-tree
-git-config-set
git-convert-objects
git-count-objects
git-cvsexportcommit
@@ -77,6 +76,7 @@ git-receive-pack
git-relink
git-rename
git-repack
+git-repo-config
git-request-pull
git-reset
git-resolve
diff --git a/Documentation/git-config-set.txt b/Documentation/git-repo-config.txt
similarity index 82%
rename from Documentation/git-config-set.txt
rename to Documentation/git-repo-config.txt
index bfbd421..92b9156 100644
--- a/Documentation/git-config-set.txt
+++ b/Documentation/git-repo-config.txt
@@ -1,19 +1,19 @@
-git-config-set(1)
+git-repo-config(1)
===============
NAME
----
-git-config-set - Set options in .git/config.
+git-repo-config - Get and set options in .git/config.
SYNOPSIS
--------
-'git-config-set' name [value [value_regex]]
-'git-config-set' --replace-all name [value [value_regex]]
-'git-config-set' --get name [value_regex]
-'git-config-set' --get-all name [value_regex]
-'git-config-set' --unset name [value_regex]
-'git-config-set' --unset-all name [value_regex]
+'git-repo-config' name [value [value_regex]]
+'git-repo-config' --replace-all name [value [value_regex]]
+'git-repo-config' --get name [value_regex]
+'git-repo-config' --get-all name [value_regex]
+'git-repo-config' --unset name [value_regex]
+'git-repo-config' --unset-all name [value_regex]
DESCRIPTION
-----------
@@ -89,7 +89,7 @@ Given a .git/config like this:
you can set the filemode to true with
------------
-% git config-set core.filemode true
+% git repo-config core.filemode true
------------
The hypothetic proxy command entries actually have a postfix to discern
@@ -97,7 +97,7 @@ to what URL they apply. Here is how to c
to "ssh".
------------
-% git config-set proxy.command '"ssh" for kernel.org' 'for kernel.org$'
+% git repo-config proxy.command '"ssh" for kernel.org' 'for kernel.org$'
------------
This makes sure that only the key/value pair for kernel.org is replaced.
@@ -105,7 +105,7 @@ This makes sure that only the key/value
To delete the entry for renames, do
------------
-% git config-set --unset diff.renames
+% git repo-config --unset diff.renames
------------
If you want to delete an entry for a multivar (like proxy.command above),
@@ -114,45 +114,45 @@ you have to provide a regex matching the
To query the value for a given key, do
------------
-% git config-set --get core.filemode
+% git repo-config --get core.filemode
------------
or
------------
-% git config-set core.filemode
+% git repo-config core.filemode
------------
or, to query a multivar:
------------
-% git config-set --get proxy.command "for kernel.org$"
+% git repo-config --get proxy.command "for kernel.org$"
------------
If you want to know all the values for a multivar, do:
------------
-% git config-set --get-all proxy.command
+% git repo-config --get-all proxy.command
------------
If you like to live dangerous, you can replace *all* proxy.commands by a
new one with
------------
-% git config-set --replace-all proxy.command ssh
+% git repo-config --replace-all proxy.command ssh
------------
However, if you really only want to replace the line for the default proxy,
i.e. the one without a "for ..." postfix, do something like this:
------------
-% git config-set proxy.command ssh '! for '
+% git repo-config proxy.command ssh '! for '
------------
To actually match only values with an exclamation mark, you have to
------------
-% git config-set section.key value '[!]'
+% git repo-config section.key value '[!]'
------------
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 694fee8..a518249 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -84,9 +84,6 @@ gitlink:git-checkout-index[1]::
gitlink:git-commit-tree[1]::
Creates a new commit object
-gitlink:git-config-set[1]::
- Set options in .git/config.
-
gitlink:git-hash-object[1]::
Computes the object ID from a file.
@@ -111,6 +108,9 @@ gitlink:git-prune-packed[1]::
gitlink:git-read-tree[1]::
Reads tree information into the directory index
+gitlink:git-repo-config[1]::
+ Get and set options in .git/config.
+
gitlink:git-unpack-objects[1]::
Unpacks objects out of a packed archive.
diff --git a/Makefile b/Makefile
index 53bba2f..c47eeec 100644
--- a/Makefile
+++ b/Makefile
@@ -134,7 +134,7 @@ PROGRAMS = \
git-unpack-objects$X git-update-index$X git-update-server-info$X \
git-upload-pack$X git-verify-pack$X git-write-tree$X \
git-update-ref$X git-symbolic-ref$X git-check-ref-format$X \
- git-name-rev$X git-pack-redundant$X git-config-set$X git-var$X
+ git-name-rev$X git-pack-redundant$X git-repo-config$X git-var$X
# what 'all' will build and 'install' will install.
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS) git$X
diff --git a/config-set.c b/repo-config.c
similarity index 98%
rename from config-set.c
rename to repo-config.c
index d938f96..b2569b7 100644
--- a/config-set.c
+++ b/repo-config.c
@@ -2,7 +2,7 @@
#include <regex.h>
static const char git_config_set_usage[] =
-"git-config-set [--get | --get-all | --replace-all | --unset | --unset-all] name [value [value_regex]]";
+"git-repo-config [--get | --get-all | --replace-all | --unset | --unset-all] name [value [value_regex]]";
static char* key = NULL;
static char* value = NULL;
diff --git a/t/t1300-config-set.sh b/t/t1300-repo-config.sh
similarity index 81%
rename from t/t1300-config-set.sh
rename to t/t1300-repo-config.sh
index 7a5849a..5e994ff 100644
--- a/t/t1300-config-set.sh
+++ b/t/t1300-repo-config.sh
@@ -3,13 +3,13 @@
# Copyright (c) 2005 Johannes Schindelin
#
-test_description='Test git-config-set in different settings'
+test_description='Test git-repo-config in different settings'
. ./test-lib.sh
test -f .git/config && rm .git/config
-git-config-set core.penguin "little blue"
+git-repo-config core.penguin "little blue"
cat > expect << EOF
#
@@ -22,7 +22,7 @@ EOF
test_expect_success 'initial' 'cmp .git/config expect'
-git-config-set Core.Movie BadPhysics
+git-repo-config Core.Movie BadPhysics
cat > expect << EOF
#
@@ -36,7 +36,7 @@ EOF
test_expect_success 'mixed case' 'cmp .git/config expect'
-git-config-set Cores.WhatEver Second
+git-repo-config Cores.WhatEver Second
cat > expect << EOF
#
@@ -52,7 +52,7 @@ EOF
test_expect_success 'similar section' 'cmp .git/config expect'
-git-config-set CORE.UPPERCASE true
+git-repo-config CORE.UPPERCASE true
cat > expect << EOF
#
@@ -70,10 +70,10 @@ EOF
test_expect_success 'similar section' 'cmp .git/config expect'
test_expect_success 'replace with non-match' \
- 'git-config-set core.penguin kingpin !blue'
+ 'git-repo-config core.penguin kingpin !blue'
test_expect_success 'replace with non-match (actually matching)' \
- 'git-config-set core.penguin "very blue" !kingpin'
+ 'git-repo-config core.penguin "very blue" !kingpin'
cat > expect << EOF
#
@@ -106,7 +106,7 @@ EOF
cp .git/config .git/config2
test_expect_success 'multiple unset' \
- 'git-config-set --unset-all beta.haha'
+ 'git-repo-config --unset-all beta.haha'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -122,7 +122,7 @@ test_expect_success 'multiple unset is c
mv .git/config2 .git/config
test_expect_success '--replace-all' \
- 'git-config-set --replace-all beta.haha gamma'
+ 'git-repo-config --replace-all beta.haha gamma'
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -136,7 +136,7 @@ EOF
test_expect_success 'all replaced' 'cmp .git/config expect'
-git-config-set beta.haha alpha
+git-repo-config beta.haha alpha
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -150,7 +150,7 @@ EOF
test_expect_success 'really mean test' 'cmp .git/config expect'
-git-config-set nextsection.nonewline wow
+git-repo-config nextsection.nonewline wow
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -165,8 +165,8 @@ EOF
test_expect_success 'really really mean test' 'cmp .git/config expect'
-test_expect_success 'get value' 'test alpha = $(git-config-set beta.haha)'
-git-config-set --unset beta.haha
+test_expect_success 'get value' 'test alpha = $(git-repo-config beta.haha)'
+git-repo-config --unset beta.haha
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -180,7 +180,7 @@ EOF
test_expect_success 'unset' 'cmp .git/config expect'
-git-config-set nextsection.NoNewLine "wow2 for me" "for me$"
+git-repo-config nextsection.NoNewLine "wow2 for me" "for me$"
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -196,18 +196,18 @@ EOF
test_expect_success 'multivar' 'cmp .git/config expect'
test_expect_success 'non-match' \
- 'git-config-set --get nextsection.nonewline !for'
+ 'git-repo-config --get nextsection.nonewline !for'
test_expect_success 'non-match value' \
- 'test wow = $(git-config-set --get nextsection.nonewline !for)'
+ 'test wow = $(git-repo-config --get nextsection.nonewline !for)'
test_expect_failure 'ambiguous get' \
- 'git-config-set --get nextsection.nonewline'
+ 'git-repo-config --get nextsection.nonewline'
test_expect_success 'get multivar' \
- 'git-config-set --get-all nextsection.nonewline'
+ 'git-repo-config --get-all nextsection.nonewline'
-git-config-set nextsection.nonewline "wow3" "wow$"
+git-repo-config nextsection.nonewline "wow3" "wow$"
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -222,15 +222,15 @@ EOF
test_expect_success 'multivar replace' 'cmp .git/config expect'
-test_expect_failure 'ambiguous value' 'git-config-set nextsection.nonewline'
+test_expect_failure 'ambiguous value' 'git-repo-config nextsection.nonewline'
test_expect_failure 'ambiguous unset' \
- 'git-config-set --unset nextsection.nonewline'
+ 'git-repo-config --unset nextsection.nonewline'
test_expect_failure 'invalid unset' \
- 'git-config-set --unset somesection.nonewline'
+ 'git-repo-config --unset somesection.nonewline'
-git-config-set --unset nextsection.nonewline "wow3$"
+git-repo-config --unset nextsection.nonewline "wow3$"
cat > expect << EOF
[beta] ; silly comment # another comment
@@ -244,12 +244,12 @@ EOF
test_expect_success 'multivar unset' 'cmp .git/config expect'
-test_expect_failure 'invalid key' 'git-config-set inval.2key blabla'
+test_expect_failure 'invalid key' 'git-repo-config inval.2key blabla'
-test_expect_success 'correct key' 'git-config-set 123456.a123 987'
+test_expect_success 'correct key' 'git-repo-config 123456.a123 987'
test_expect_success 'hierarchical section' \
- 'git-config-set 1.2.3.alpha beta'
+ 'git-repo-config 1.2.3.alpha beta'
cat > expect << EOF
[beta] ; silly comment # another comment
^ permalink raw reply related
* Re: simple git repository browser with vim
From: Junio C Hamano @ 2005-11-24 10:28 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20051124093322.GA3899@mail.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> It relies on a simple shell script I wrote called 'git-show' that picks
> a reasonable way to display each of the blob, tree, or commit object
> types. I'm fairly sure somebody else has written something like
> git-show before, I just couldn't find it. I'd imagine it's pretty
> useful standalone without vim, too.
Aha.
It strikes me that the blob case could be enhanced to do
git-unpack-file, run "file -i" on it to figure out the file's
mimetype, and then give it to an appropriate MIME type viewer
;-).
For a tag object, you might want to deref it, and also if it is
a signed kind, you may want to do git-verify-tag it.
The following should not taken too seriously, but you might find
it instructive to learn how to unwrap tag objects, verify them
for signature, and pretty-print a single commit without running
whatchanged. I suspect the script as posted by you shows the
commit message twice, BTW.
-- >8 --
#!/bin/sh
extract_tag_info='
s/^object /sha1=/p
/^type /{
s//type=/
p
q
}
'
for sha1
do
type=`git-cat-file -t "$sha1"` || continue
while case "$type" in tag) ;; *) break ;; esac
do
echo "*** tag $sha1 ***"
git-cat-file tag "$sha1"
git-verify-tag "$sha1"
echo
eval `git-cat-file tag "$sha1" | sed -n -e "$extract_tag_info"`
done
case "$type" in
tree)
echo "*** $type $sha1 ***"
git-ls-tree -r "$sha1"
;;
blob)
temp=`git-unpack-file "$sha1"`
mimetype=`file -i "$temp" | sed -e 's/^[^:]*: *//'`
echo "*** $type ($mimetype) $sha1 ***"
case "$mimetype" in
image/*)
display "$temp" ;;
audio/*)
cat "$temp" >/dev/audio ;; # sorry I do not do audio
text/html)
links -dump "$temp" ;; # hello, Pasky
*)
cat "$temp" ;;
esac
rm -f $temp
;;
commit)
echo "*** $type $sha1 ***"
git-diff-tree --pretty -m -C --find-copies-harder -p "$sha1"
;;
esac
echo
done
^ permalink raw reply
* simple git repository browser with vim
From: Eric Wong @ 2005-11-24 9:33 UTC (permalink / raw)
To: git list
Here's a really quick and easy way to browse git repositories for vim
users. Hopefully somebody else finds this useful, I know I do.
The idea is just to open a temporary file with git sha1sums (say git-log
output) in vim, move your cursor over any one of the object sha1sums,
and then hit ,G (or any shortcut of your choice) in normal mode to
show what one of those was.
It relies on a simple shell script I wrote called 'git-show' that picks
a reasonable way to display each of the blob, tree, or commit object
types. I'm fairly sure somebody else has written something like
git-show before, I just couldn't find it. I'd imagine it's pretty
useful standalone without vim, too.
If you :set foldmethod=marker in vim, you can pass the -f
flag to git-show and it'll enclose the output with the the default
vim fold markers: {{{ }}}
This is the line I've added to my .vimrc:
map ,G yaw:.!git-show -f <c-r>" <CR>
And here is git-show in all it's glory:
---
#!/bin/sh
while : ; do
case "$1" in
-f|--fold-marker)
fold_marker=1
;;
*)
if [ -z "$sha1sum" ]; then
sha1sum="$1"
fi
break
;;
esac
shift
done
type=`git-cat-file -t $sha1sum`
if [ -n "$fold_marker" ]; then
echo "$type($1) {{{"
fi
case "$type" in
tree)
git-ls-tree -r $1
;;
blob)
git-cat-file blob $1
;;
commit)
git-cat-file commit $1
echo ''
git-whatchanged --max-count=1 -C -p -r $1
;;
esac
if [ -n "$fold_marker" ]; then
echo '}}}'
fi
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] archimport improvements
From: Martin Langhoff @ 2005-11-24 9:25 UTC (permalink / raw)
To: Eric Wong; +Cc: git list
In-Reply-To: <20051124074605.GA4789@mail.yhbt.net>
On 11/24/05, Eric Wong <normalperson@yhbt.net> wrote:
> Ok, I didn't expect you guys to have 12k of files in your trees. None
> of your source trees are remotely close to that size (but I have many
> more changesets). I'm surprised you guys were able to put up
> with Arch in the first place!
>
> 125m58.431s with my method.
> 8m24.504s with yours :)
>
> All of my usual source trees imported 1k changesets in 10-15 minutes
:-) I'm happy that you managed to wait patiently for it to complete --
all my attempts to run your import code were ended by a sleepy ctrl-c.
> Patches on the way.
Cool -- will review, but may take a couple days, as I'm away from home
this week.
> OTOH, the time spent importing the bulk of the history is a one-time
> operation for most people and I'd much rather it get things as right as
> possible and move on.
Hmmm. Some teams -- such as mine -- just run it every couple hours to
maintain an Arch2cvs gateway.
More later,
martin
^ permalink raw reply
* Re: files are disappearing in git
From: Junio C Hamano @ 2005-11-24 9:15 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git
In-Reply-To: <20051124084633.GA3361@schottelius.org>
Nico -telmich- Schottelius <nico-linux-git@schottelius.org> writes:
> Linus Torvalds [Wed, Nov 23, 2005 at 09:20:28AM -0800]:
>> On Wed, 23 Nov 2005, Nico -telmich- Schottelius wrote:
>>...
>> I bet somebody just messed up the index before that commit.
>
> What would be the best things to corrupt the index?
> Our developers here do the following each day:
>
> - cg-update
> - <work>
> - cg-commit
> - cg-update + merge if there are changes
> - cg-push origin
Was any of the CG:F line changed/removed by the developer during
cg-commit?
Does any of the files under Code/Spikes/Statistik/ have funny
characters in their pathnames?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox