* git-http-push and hooks
From: Bertrand Jacquin (Beber) @ 2006-02-06 20:52 UTC (permalink / raw)
To: git
Hi,
Just a silly question :
Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?
Also if i push with cg-push on the same repo but with git+ssh
protocol, hooks are execute.
Thanks
--
/* Beber : beber (AT) setibzh (DOT) com
* http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
* Guybrush @ Melee */
^ permalink raw reply
* Re: Push or merge certain commitid
From: Petr Baudis @ 2006-02-06 21:04 UTC (permalink / raw)
To: git
In-Reply-To: <20060206204935.GA20274@guybrush.melee>
Hello,
your email address is broken. I'm replying just to the mailing list.
Dear diary, on Mon, Feb 06, 2006 at 09:49:35PM CET, I got a letter
where "Bertrand Jacquin (Beber)" <beber@guybrush.melee> said that...
> I don't know if it's really possible to do but I would like to know if
> there is a way to push or merge just certain commitid specified ?
> I think it can trouble parents, trees, etc, but here I need that.
As I already said on IRC, you can merge a specified commit by using
the git-cherry-pick(1) command.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: Push or merge certain commitid
From: Bertrand Jacquin (Beber) @ 2006-02-06 21:09 UTC (permalink / raw)
To: pasky; +Cc: git
In-Reply-To: <4fb292fa0602061307q370443fdlf1f5e2ff575150f7@mail.gmail.com>
On Mon, Feb 06, 2006 at 10:07:18PM +0100, Bertrand Jacquin wrote:
> Hello,
>
> your email address is broken. I'm replying just to the mailing list.
Sorry, my mutt is quiet dead, and didn't send old mails :/
>
> Dear diary, on Mon, Feb 06, 2006 at 09:49:35PM CET, I got a letter
> where "Bertrand Jacquin (Beber)" <beber@guybrush.melee> said that...
> > I don't know if it's really possible to do but I would like to know if
> > there is a way to push or merge just certain commitid specified ?
> > I think it can trouble parents, trees, etc, but here I need that.
>
> As I already said on IRC, you can merge a specified commit by using
> the git-cherry-pick(1) command.
Yes, I read it, and wrote mail befode, sorry for noise
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> Of the 3 great composers Mozart tells us what it's like to be human,
> Beethoven tells us what it's like to be Beethoven and Bach tells us
> what it's like to be the universe. -- Douglas Adams
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
> --
> Beber
> #e.fr@freenode
--
/* Beber : beber (AT) setibzh (DOT) com
* http://guybrush.ath.cx, irc://irc.freenode.net/#{e.fr,gentoofr}
* Guybrush @ Melee */
^ permalink raw reply
* Re: [Census] So who uses git?
From: Chuck Lever @ 2006-02-06 21:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ray Lehtiniemi, Alex Riesen, Radoslaw Szkodzinski, Keith Packard,
Junio C Hamano, cworth, Martin Langhoff, Git Mailing List,
Trond Myklebust
In-Reply-To: <Pine.LNX.4.64.0601311747360.7301@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
Linus Torvalds wrote:
>>for comparison, one of our sandboxes is sitting on an NTFS file system,
>>accessed via SMB:
>>
>> smbfs$ time git update-index --refresh
>> real 11m36.502s
>> user 0m6.830s
>> sys 0m5.086s
>
>
> Ouch, ouch, ouch.
>
> Sounds like every single stat() will go out the wire. I forget what the
> Linux NFS client does, but I _think_ it has a metadata timeout that avoids
> this. But it might be as bad under NFS.
>
> Has anybody used git over NFS? If it's this bad (or even close to), I
> guess the "mark files as up-to-date in the index" approach is a really
> good idea..
>
> Of course, the whole point of git is that you should keep your repository
> close, but sometimes NFS - or similar - is enforced upon you by other
> issues, like the fact that the powers-that-be want anonymous workstations
> and everybody should work with a home-directory automounted over NFS..
yes, i keep my Linux kernel repository in NFS (and my stgit and git
repositories too).
there are some things that are slow precisely because my think time is
longer than the NFS client's attribute timeout, which means that all of
git's lstat()s turn into GETATTRs.
using the "noatime,nodiratime,actimeo=7200" mount options can have some
benefit. however, i found that keeping the repository packed provides
the greatest positive impact. that means that most of the objects are
in a single file, and can be validated with just one GETATTR.
one thing we might conclude from this is that making "packing" an
efficient operation (or even an incremental one) would go a long way to
helping performance on network file systems.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ permalink raw reply
* problem with gitweb I don't understand
From: Alan Chandler @ 2006-02-06 21:35 UTC (permalink / raw)
To: git
I am running with a (slightly) modified version of gitweb. The only
modifications are to allow it to pick up my site header and footer.
I have just added a new project "txpg.git" to the directory where all my git
projects are stored for public display. This was some old code that I
packaged up into a repository. There are two disconnected branches - "orig"
which contains the initial check-in of the original code I started with, and
"master" which is also an initial check-in but of the result after some
incomplete hacking. HEAD is a symlink I made manually to point to master.
I have been able to clone this (via git:// protocol) add a tag, and then with
a post-update hook in the repository successfully generate a tarball of the
code using git-tar-tree when pushing a tag using ssh. So I am pretty
confident I have a real repository
But gitweb is not displaying it (see http://www.chandlerfamily.org.uk/git).
However if I do http://www.chandlerfamily.org.uk/git/?p=txpg.git;a=summary
the error message I get is "403 Forbidden - No such project." whereas if I
had used any random characters for the project I would have got "403
Forbidden - No such directory"
Looking at the gitweb code, all I can see is the non-existance of the HEAD
file as causing this error. but it is definately there as seen from the
following output.
alan@roo git$ find . -name HEAD
./txpg.git/HEAD
./gitweb.git/HEAD
./border.git/HEAD
./blog.git/HEAD
./famtree.git/HEAD
./akcmoney.git/HEAD
alan@roo git$ pwd
/var/lib/git
alan@roo git$ ls -l akcmoney.git/HEAD
lrwxrwxrwx 1 alan git 17 Jan 29 19:14 akcmoney.git/HEAD -> refs/heads/master
alan@roo git$ ls -l txpg.git/HEAD
lrwxrwxrwx 1 alan git 17 Feb 6 19:48 txpg.git/HEAD -> refs/heads/master
So I am stumped as to what could be wrong.
Anyone any ideas.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* git-bisect doesnt record bad commits
From: Olaf Hering @ 2006-02-06 21:54 UTC (permalink / raw)
To: git
Is there a reason why git-bisect does only record good ones? I would
really like to know which commits did crash for me. :(
2006-02-05 14:07 .git/refs/bisect/good-a020ff412f0ecbb1e4aae1681b287e5785dd77b5
2006-02-05 21:25 .git/refs/bisect/good-f61ea1b0c825a20a1826bb43a226387091934586
2006-02-06 07:02 .git/refs/bisect/good-f2e46561cc1afa82b18b2fc6efc8510ec57c7d7d
2006-02-06 10:24 .git/refs/bisect/good-d779188d2baf436e67fe8816fca2ef53d246900f
2006-02-06 14:37 .git/refs/bisect/good-1cb9e8e01d2c73184e2074f37cd155b3c4fdaae6
2006-02-06 17:43 .git/refs/bisect/good-54e08a2392e99ba9e48ce1060e0b52a39118419c
2006-02-06 19:52 .git/refs/bisect/bad
2006-02-06 21:57 .git/refs/bisect/good-4a4efbdee278b2f4ed91aad2db5c006ff754276e
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: git-bisect doesnt record bad commits
From: Linus Torvalds @ 2006-02-06 22:21 UTC (permalink / raw)
To: Olaf Hering; +Cc: git
In-Reply-To: <20060206215442.GA12209@suse.de>
On Mon, 6 Feb 2006, Olaf Hering wrote:
>
> Is there a reason why git-bisect does only record good ones? I would
> really like to know which commits did crash for me. :(
It does. Look in the bisection log (".git/BISECT_LOG").
Now, the reason it doesn't actually save them away as _tags_ is because
technically, it doesn't need to. The algorithm itself only really cares
about the most recently marked-bad commit, and the others are totally
uninteresting from an algorithmic standpoint.
That said, if you want the visualization tools (for example) to show them,
you could certainly _create_ the tags, if you want to. The fact that they
wouldn't be used by the bisection algorithm doesn't mean that you can't
create the ".git/refs/bisect/bad-<sha1>" file in _addition_ to the one
that marks the latest one.
Linus
^ permalink raw reply
* Re: git-bisect doesnt record bad commits
From: Olaf Hering @ 2006-02-06 22:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602061417510.3854@g5.osdl.org>
On Mon, Feb 06, Linus Torvalds wrote:
>
>
> On Mon, 6 Feb 2006, Olaf Hering wrote:
> >
> > Is there a reason why git-bisect does only record good ones? I would
> > really like to know which commits did crash for me. :(
>
> It does. Look in the bisection log (".git/BISECT_LOG").
Thats good enough for me to restore my steps, I think. Thanks.
--
short story of a lazy sysadmin:
alias appserv=wotan
^ permalink raw reply
* Re: problem with gitweb I don't understand
From: Alan Chandler @ 2006-02-06 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <200602062135.27652.alan@chandlerfamily.org.uk>
On Monday 06 February 2006 21:35, Alan Chandler wrote:
...>
> But gitweb is not displaying it (see http://www.chandlerfamily.org.uk/git).
>
> However if I do http://www.chandlerfamily.org.uk/git/?p=txpg.git;a=summary
>
> the error message I get is "403 Forbidden - No such project." whereas if I
> had used any random characters for the project I would have got "403
> Forbidden - No such directory"
Cracked it. I set repository permissions using the following (from the
tutorial)
find repo.git -type d -print | xargs chmod ug+rwx,g+s
but directories need o+x as well so that the web server can read the refs
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [PATCH 3/9] http-fetch: Abort requests for objects which arrived in packs
From: Nick Hengeveld @ 2006-02-06 23:11 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrndu1rk9.2i8.mdw@metalzone.distorted.org.uk>
On Wed, Feb 01, 2006 at 05:23:21PM +0000, Mark Wooding wrote:
> I'm by no means a Curl expert. But I scoured the docs for another way
> of interrupting the current fetch and I couldn't find anything. It
> really didn't seem like a good idea to leave the handle as it was,
> having (possibly) half-fetched a thing we weren't actually interested in
> -- that way lies confusion.
My impression from the curl documentation was that removing the curl
handle from the multi session was enough, but the documentation doesn't
describe what happens to such a request.
> Besides, in practice, what's happened is that the object we asked for is
> in a pack which we've just collected. Unless the upstream repository
> hasn't been git-prune-packed, our fetch is going to fail with a 404
> anyway, at which point Curl /will/ close the connection and make another
> one next time. So, in real life, it makes no difference.
Good point, and it does seem safer to fully clean up the connection
rather than leave it in a questionable state.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Tracking and committing back to Subversion?
From: Sam Vilain @ 2006-02-06 23:12 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List
In-Reply-To: <20060204054056.GB24314@Muzzle>
Eric Wong wrote:
>> 1. file properties - such as mime type, ignores and custom properties.
>> Linus, when I asked you about this in Dunedin, you mentioned that
>> there is a place at the end of the directory entry where this could
>> fit without breaking backwards compatibility. Perhaps this could
>> be an optional pointer to another directory node;
> Mostly ignore-able, imho. svn:executable is the one that makes the most
> sense (and is easiest) to support.
[...]
> svn:keywords: I don't think there's a way to disable this like there
> is with CVS, is there? keywords are evil imho.
> I don't use or know much about the other properties...
Right, but it is also possible to hang directory or file properties,
with any name, off any file or directory. It is often important to
at least preserve or be able to update these when dealing with some SVN
repositories, where people are using them for their own purpose.
Perhaps a "standard" mapping to dotfiles would be the best solution
then. A .svnprops file or something like that.
>> 2. "forensic" file movement history - as opposed to the uncached,
>> (and unversioned), automatic "analytical" file movement history.
>>
>> It would be easy for a tool to provide 100% interface compatibility
>> with SVN client/SVK using properties, but properties that hang off
>> the head rather than the file itself (so that they don't stuff up
>> the ability to merge identical trees reached via independent
>> paths). SVN calls these "revision properties". If a good
>> convention is adopted for this, it could be used as a nice way to
>> supplement git's automatic analysis of the revision history.
> Just parsing the output of diff-tree -C and marking them in SVN as
> copies/renames should be sufficient for letting SVN do its thing.
>
> Doing this kind of file movement history on the git side sounds like
> overkill to me. I was a _huge_ fan of logical file-identities in GNU
> Arch in the past, but the complexity destroyed it from both a UI and
> performance perspective.
Right now, tagging gets an exemption from this requirement, as does the
extra state required by tools like StGIT. I think this could be
generalised to support this kind of application; however we will see
whether this has any real effect or just operational side effect (eg, to
make sure renames are tracked correctly then commit before changing the
copied version, etc).
Sam.
^ permalink raw reply
* Re: git-http-push and hooks
From: Nick Hengeveld @ 2006-02-06 23:22 UTC (permalink / raw)
To: Bertrand Jacquin (Beber); +Cc: git
In-Reply-To: <20060206205203.GA20973@guybrush.melee>
On Mon, Feb 06, 2006 at 09:52:03PM +0100, Bertrand Jacquin (Beber) wrote:
> Why aren't excute hooks/* (with +x perms) when I do a git-http-push ?
> Also if i push with cg-push on the same repo but with git+ssh
> protocol, hooks are execute.
Hooks must run on the destination server when you're doing a push. If
you use the git+ssh protocol, that server is running a git daemon that
knows how to execute hooks; if you use the http/DAV protocol, that
server does not.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: Tracking and committing back to Subversion?
From: Sam Vilain @ 2006-02-06 23:23 UTC (permalink / raw)
To: Brian Smith; +Cc: git
In-Reply-To: <200602040727.30965.linuxfood@linuxfood.net>
Brian Smith wrote:
>>Has anyone done any work on bidirectional access to SVN repositories?
>>ie, tracking and committing.
> I'm working on something that does just that, I haven't gotten to the
> bidirectional part just yet. (The only reason I didn't use git-svnimport is
> that it has a /terrible/ time importing from the KDE svn repo. )
Indeed, mirroring SVN repositories via SVN::Mirror (which is used by
SVK) can take hours for large projects with thousands of commits.
> My take on the properties, though I like your thoughts on how to handle at
> least svn:ignore, is to basically just let svn deal with them. I will make a
> couple tools that will modify them, for interface reasons, but they'll just
> be wrappers around the svn commands themselves.
> At the moment, the tools are written as bash shell scripts with an
> interface I'm trying to keep as intuitive as cogito (even though I use
> the core-git tools now.)
Right; I was looking for an approach that did not require working copies
of the remote subversion repository to be kept locally. Still, perhaps
that approach has merit, though I would probably start in Perl and use
SVK::Simple (see CPAN) to give a richer SVN mirroring API.
Are you planning on publishing these scripts?
Sam.
^ permalink raw reply
* Re: Two ideas for improving git's user interface
From: Carl Worth @ 2006-02-06 23:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <Pine.LNX.4.64.0602031752160.3969@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
On Fri, 3 Feb 2006 18:08:19 -0800 (PST), Linus Torvalds wrote:
>
> If you deny the index file, you really deny git itself.
>
[And the novice nearly reaches enlightenment.]
OK. I now thoroughly understand that this use of the index is by
design, not accident. So I won't propose modifying the index again.
But, I'm still not yet sure how to reconcile my personal workflow with
git yet. I don't think I'm yet an index-embracer that would relish
using "update-index <file>; commit" for everything. At the same time,
I can appreciate the disdain for "commit -a" to the extent that it
does deny the index.
I suspect that what I want might fall somewhere in between, with
something like "mark <file>; commit-marked" where commit-marked would
update the index of all marked files, then commit. This would allow me
to still use update-index for the times that I actually need to take
advantage of what that provides.
So, maybe I'll try scripting up something for that myself, (at the
risk of re-inventing cogito). Or maybe I'll just learn to live with
(and love?) what git provides already.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Cogito] Various bugs
From: Petr Baudis @ 2006-02-07 0:36 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20060131041318.GC30744@diku.dk>
Dear diary, on Tue, Jan 31, 2006 at 05:13:18AM CET, I got a letter
where Jonas Fonseca <fonseca@diku.dk> said that...
> A few Cogito bugs I found yesterday.
>
> - cg-fetch between local repos fails when the cloned branch URL does
> not point to a .git directory and a needed object from the repository
> being cloned is packed. git-local-fetch expects a .git directory.
Can't reproduce and I don't buy it. The very first line of local fetch
handler is
[ -d "$uri/.git" ] && uri="$uri/.git"
> - cg-commit -c will do the wrong thing (use the invokers gecos info)
> when the author name is empty. One workaround is to make
> pick_author_script append a space at the end of the GIT_* variables.
> GIT will strip those and no gecos info is used.
I'd rather fix this in GIT than workaround in Cogito. Will follow up
with a patch.
...
Hmm.
...
I'm puzzled. GIT should handle this fine.
export GIT_AUTHOR_NAME=''
git-commit-tree $(cg-object-id -t)
works as expected, but for some reason escaping me it does not work
inside of cg-commit. Insights welcomed.
> - cg-status reports a deleted file both as deleted and as unknown:
>
> fonseca@antimatter:~/src/elinks/0.12 > git --version
> git version 1.1.6.g1506
> fonseca@antimatter:~/src/elinks/0.12 > cg --version
> cogito-0.17pre.GIT (d3aa9a2b3375e36c774ea477492db76baa1db03e)
> fonseca@antimatter:~/src/elinks/0.12 > cg rm AUTHORS
> Removing file AUTHORS
> fonseca@antimatter:~/src/elinks/0.12 > cg status | grep AUTHORS
> ? AUTHORS
> D AUTHORS
This is fine, I'd say. The file was not deleted from the tree, either do
that manually by rm or say cg-rm -f.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: cogito: cannot add dangling symlinks whereas git can
From: Petr Baudis @ 2006-02-07 0:58 UTC (permalink / raw)
To: git, 313596, 313596-submitter
In-Reply-To: <20060102120912.13409.qmail@c3aed7b85ae352.315fe32.mid.smarden.org>
Dear diary, on Mon, Jan 02, 2006 at 01:15:17PM CET, I got a letter
where Gerrit Pape <pape@smarden.org> said that...
> forwarded 313596 upstream
> quit
>
> Hi, cg-add refuses to add special files such as dangling symlinks while
> git can handle them just fine. Please see http://bugs.debian.org/313596
>
> I'm not sure why cg-add checks files to commit with test -f.
Because you really do not want to add character specials or named pipes.
;-) I have changed the test to also check for symlinks.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [Cogito] Various bugs
From: Junio C Hamano @ 2006-02-07 2:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jonas Fonseca, git
In-Reply-To: <20060207003643.GJ31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I'm puzzled. GIT should handle this fine.
>
> export GIT_AUTHOR_NAME=''
> git-commit-tree $(cg-object-id -t)
>
> works as expected, but for some reason escaping me it does not work
> inside of cg-commit. Insights welcomed.
They probably do not have anything to do with the problem at
hand, but I just noticed your version of pick-author code in
cg-commit lacks two changes I added to git-commit:
(1) the pick_author_script you have in cg-commit lacks the
support for names with single-quotes in them
(aa66c7ec77d474b737da607d6cb2d07f56628def).
(2) I run the sed script with LANG and LC_ALL set to C locale.
I think I had some trouble without them with high-bit
names, (e3e291fc07b49b74bb655ca854bdb19e849e044c) but the
detail escapes me.
^ permalink raw reply
* Re: [Cogito] Various bugs
From: Petr Baudis @ 2006-02-07 2:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonas Fonseca, git
In-Reply-To: <7vfymw3oym.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Feb 07, 2006 at 03:03:13AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > I'm puzzled. GIT should handle this fine.
> >
> > export GIT_AUTHOR_NAME=''
> > git-commit-tree $(cg-object-id -t)
> >
> > works as expected, but for some reason escaping me it does not work
> > inside of cg-commit. Insights welcomed.
>
> They probably do not have anything to do with the problem at
> hand, but I just noticed your version of pick-author code in
> cg-commit lacks two changes I added to git-commit:
>
> (1) the pick_author_script you have in cg-commit lacks the
> support for names with single-quotes in them
> (aa66c7ec77d474b737da607d6cb2d07f56628def).
>
> (2) I run the sed script with LANG and LC_ALL set to C locale.
> I think I had some trouble without them with high-bit
> names, (e3e291fc07b49b74bb655ca854bdb19e849e044c) but the
> detail escapes me.
Thanks, I've updated the cg-commit version. Note that the empty
GIT_AUTHOR_NAME problem seems to exist in git-commit as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* git-am: "Patch fragment without a header"
From: H. Peter Anvin @ 2006-02-07 2:59 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 896 bytes --]
git-am from git-1.1.6 refuses to apply the following two patches,
whereas patch(1) sees nothing wrong with them...
The error messages look like:
: smyrno 46 ; git-am /tmp/\[klibc]\ Add\ swap\ support\ to\ fstype,\
second\ version.eml
Applying 'Add swap support to fstype, second version'
error: patch fragment without header at line 4: @@ -7,7 +7,7 @@
error: patch fragment without header at line 13: @@ -20,6 +20,7 @@
error: patch fragment without header at line 21: @@ -49,6 +50,9 @@
error: patch fragment without header at line 31: @@ -182,6 +186,19 @@
error: patch fragment without header at line 50: @@ -189,17 +206,18 @@
error: patch fragment without header at line 83: @@ -0,0 +1,18 @@
fatal: No changes
Patch failed at 0001.
The patches are meant to be apply to the top of:
git://git.kernel.org/pub/scm/libs/klibc/klibc.git
HEAD = ea6af2b08cb18ba60e55c5e8f0f65ddac1672ca0
-hpa
[-- Attachment #2: [klibc] Add LUKS support to fstype, second version.eml --]
[-- Type: message/rfc822, Size: 6160 bytes --]
[-- Attachment #2.1.1: Type: text/plain, Size: 526 bytes --]
The attached patch adds support for detecting LUKS partitions (Linux
Unified Key Setup - http://luks.endorphin.org/) to fstype. This makes it
easier to automatically detect and activate encrypted (root) partitions
from an initramfs image.
The patch is now against klibc's git tree instead of klibc-1.2.
Signed-off-by: David Härdeman <david@2gen.com>
--
fstype.c | 17 ++++++++++++++++-
luks_fs.h | 45 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+), 1 deletion(-)
[-- Attachment #2.1.2: klibc-add-luks-to-fstype-v2 --]
[-- Type: text/plain, Size: 2769 bytes --]
Index: klibc/usr/kinit/fstype/fstype.c
===================================================================
--- klibc.orig/usr/kinit/fstype/fstype.c 2006-02-05 10:53:51.000000000 +0100
+++ klibc/usr/kinit/fstype/fstype.c 2006-02-05 11:09:31.000000000 +0100
@@ -7,7 +7,7 @@
* FSSIZE - filesystem size (if known)
*
* We currently detect (in order):
- * gzip, cramfs, romfs, xfs, minix, ext3, ext2, reiserfs, jfs
+ * gzip, cramfs, romfs, xfs, luks, minix, ext3, ext2, reiserfs, jfs
*
* MINIX, ext3 and Reiserfs bits are currently untested.
*/
@@ -29,6 +29,7 @@
#include "ext2_fs.h"
#include "ext3_fs.h"
#include "xfs_sb.h"
+#include "luks_fs.h"
/*
* Slightly cleaned up version of jfs_superblock to
@@ -168,6 +169,19 @@
return 0;
}
+static int luks_image(const unsigned char *buf, unsigned long long *blocks)
+{
+ const struct luks_partition_header *lph =
+ (const struct luks_partition_header *)buf;
+
+ if (!memcmp(lph->magic, LUKS_MAGIC, LUKS_MAGIC_L)) {
+ /* FSSIZE is dictated by the underlying fs, not by LUKS */
+ *blocks = 0;
+ return 1;
+ }
+ return 0;
+}
+
struct imagetype {
off_t block;
const char name[12];
@@ -179,6 +193,7 @@
{ 0, "cramfs", cramfs_image },
{ 0, "romfs", romfs_image },
{ 0, "xfs", xfs_image },
+ { 0, "luks", luks_image },
{ 1, "minix", minix_image },
{ 1, "ext3", ext3_image },
{ 1, "ext2", ext2_image },
Index: klibc/usr/kinit/fstype/luks_fs.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ klibc/usr/kinit/fstype/luks_fs.h 2006-02-05 10:57:52.000000000 +0100
@@ -0,0 +1,45 @@
+#ifndef __LINUX_LUKS_FS_H
+#define __LINUX_LUKS_FS_H
+
+/* The basic structures of the luks partition header */
+#define LUKS_MAGIC_L 6
+#define LUKS_CIPHERNAME_L 32
+#define LUKS_CIPHERMODE_L 32
+#define LUKS_HASHSPEC_L 32
+#define LUKS_UUID_STRING_L 40
+
+#define LUKS_MAGIC "LUKS\xBA\xBE"
+#define LUKS_DIGESTSIZE 20
+#define LUKS_SALTSIZE 32
+#define LUKS_NUMKEYS 8
+#define LUKS_MKD_ITER 10
+#define LUKS_KEY_DISABLED 0x0000DEAD
+#define LUKS_KEY_ENABLED 0x00AC71F3
+#define LUKS_STRIPES 4000
+
+
+/* On-disk "super block" */
+struct luks_partition_header {
+ char magic[LUKS_MAGIC_L];
+ __be16 version;
+ char cipherName[LUKS_CIPHERNAME_L];
+ char cipherMode[LUKS_CIPHERMODE_L];
+ char hashSpec[LUKS_HASHSPEC_L];
+ __be32 payloadOffset;
+ __be32 keyBytes;
+ char mkDigest[LUKS_DIGESTSIZE];
+ char mkDigestSalt[LUKS_SALTSIZE];
+ __be32 mkDigestIterations;
+ char uuid[LUKS_UUID_STRING_L];
+
+ struct {
+ __be32 active;
+ /* Parameters for PBKDF2 processing */
+ __be32 passwordIterations;
+ char passwordSalt[LUKS_SALTSIZE];
+ __be32 keyMaterialOffset;
+ __be32 stripes;
+ } keyblock[LUKS_NUMKEYS];
+};
+
+#endif
[-- Attachment #2.1.3: Type: text/plain, Size: 127 bytes --]
_______________________________________________
klibc mailing list
klibc@zytor.com
http://www.zytor.com/mailman/listinfo/klibc
[-- Attachment #3: [klibc] Add swap support to fstype, second version.eml --]
[-- Type: message/rfc822, Size: 6293 bytes --]
[-- Attachment #3.1.1: Type: text/plain, Size: 388 bytes --]
This patch adds support for swap detection to fstype (to be applied on
top of the previous luks patch).
The patch is now against klibc's git tree instead of klibc-1.2.
Signed-off-by: David Härdeman <david@2gen.com>
--
fstype.c | 42 ++++++++++++++++++++++++++++++------------
swap_fs.h | 18 ++++++++++++++++++
2 files changed, 48 insertions(+), 12 deletions(-)
[-- Attachment #3.1.2: klibc-add-swap-to-fstype-v2 --]
[-- Type: text/plain, Size: 3040 bytes --]
Index: klibc/usr/kinit/fstype/fstype.c
===================================================================
--- klibc.orig/usr/kinit/fstype/fstype.c 2006-02-05 11:09:31.000000000 +0100
+++ klibc/usr/kinit/fstype/fstype.c 2006-02-05 11:11:15.000000000 +0100
@@ -7,7 +7,7 @@
* FSSIZE - filesystem size (if known)
*
* We currently detect (in order):
- * gzip, cramfs, romfs, xfs, luks, minix, ext3, ext2, reiserfs, jfs
+ * gzip, cramfs, romfs, xfs, luks, minix, ext3, ext2, reiserfs, jfs, swap
*
* MINIX, ext3 and Reiserfs bits are currently untested.
*/
@@ -20,6 +20,7 @@
#include <endian.h>
#include <netinet/in.h>
#include <sys/vfs.h>
+#include <asm/page.h>
#define cpu_to_be32(x) __cpu_to_be32(x) /* Needed by romfs_fs.h */
@@ -49,6 +50,9 @@
#define BLOCK_SIZE 1024
+/* Swap needs the definition of block size */
+#include "swap_fs.h"
+
static int gzip_image(const unsigned char *buf, unsigned long long *bytes)
{
if (buf[0] == 037 && (buf[1] == 0213 || buf[1] == 0236)) {
@@ -182,6 +186,19 @@
return 0;
}
+static int swap_image(const unsigned char *buf, unsigned long long *blocks)
+{
+ const struct swap_super_block *ssb =
+ (const struct swap_super_block *)buf;
+
+ if (!memcmp(ssb->magic, SWAP_MAGIC_1, SWAP_MAGIC_L) ||
+ !memcmp(ssb->magic, SWAP_MAGIC_2, SWAP_MAGIC_L)) {
+ *blocks = 0;
+ return 1;
+ }
+ return 0;
+}
+
struct imagetype {
off_t block;
const char name[12];
@@ -189,17 +206,18 @@
};
static struct imagetype images[] = {
- { 0, "gzip", gzip_image },
- { 0, "cramfs", cramfs_image },
- { 0, "romfs", romfs_image },
- { 0, "xfs", xfs_image },
- { 0, "luks", luks_image },
- { 1, "minix", minix_image },
- { 1, "ext3", ext3_image },
- { 1, "ext2", ext2_image },
- { 8, "reiserfs", reiserfs_image },
- { 64, "reiserfs", reiserfs_image },
- { 32, "jfs", jfs_image }
+ { 0, "gzip", gzip_image },
+ { 0, "cramfs", cramfs_image },
+ { 0, "romfs", romfs_image },
+ { 0, "xfs", xfs_image },
+ { 0, "luks", luks_image },
+ { 1, "minix", minix_image },
+ { 1, "ext3", ext3_image },
+ { 1, "ext2", ext2_image },
+ { 8, "reiserfs", reiserfs_image },
+ { 64, "reiserfs", reiserfs_image },
+ { 32, "jfs", jfs_image },
+ { SWAP_OFFSET, "swap", swap_image }
};
int identify_fs(int fd, const char **fstype,
Index: klibc/usr/kinit/fstype/swap_fs.h
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ klibc/usr/kinit/fstype/swap_fs.h 2006-02-05 11:10:01.000000000 +0100
@@ -0,0 +1,18 @@
+#ifndef __LINUX_SWAP_FS_H
+#define __LINUX_SWAP_FS_H
+
+/* The basic structures of the swap super block */
+#define SWAP_RESERVED_L BLOCK_SIZE - 10
+#define SWAP_MAGIC_L 10
+#define SWAP_MAGIC_1 "SWAP-SPACE"
+#define SWAP_MAGIC_2 "SWAPSPACE2"
+/* The super block is the last block in the first page */
+#define SWAP_OFFSET ((PAGE_SIZE - BLOCK_SIZE) / BLOCK_SIZE)
+
+/* On-disk "super block" */
+struct swap_super_block {
+ char reserved[SWAP_RESERVED_L];
+ char magic[SWAP_MAGIC_L];
+};
+
+#endif
[-- Attachment #3.1.3: Type: text/plain, Size: 127 bytes --]
_______________________________________________
klibc mailing list
klibc@zytor.com
http://www.zytor.com/mailman/listinfo/klibc
^ permalink raw reply
* Re: [Cogito] Various bugs
From: Junio C Hamano @ 2006-02-07 3:03 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060207021006.GM31278@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> > I'm puzzled. GIT should handle this fine.
>> >
>> > export GIT_AUTHOR_NAME=''
>> > git-commit-tree $(cg-object-id -t)
>> >
>> > works as expected, but for some reason escaping me it does not work
>> > inside of cg-commit. Insights welcomed.
>> ...
> Thanks, I've updated the cg-commit version. Note that the empty
> GIT_AUTHOR_NAME problem seems to exist in git-commit as well.
It depends on what you expect, but it meets _my_ expectation:
$ GIT_AUTHOR_NAME='' git-commit-tree $(git-write-tree) </dev/null
Committing initial tree a2b59c3848164a2c9c3c75fbaadccaed9485da92
ef90563fa278735af367e7606ea7eb2559121ca7
$ git-cat-file commit ef90563fa278735af367e7606ea7eb2559121ca7
tree a2b59c3848164a2c9c3c75fbaadccaed9485da92
author <junkio@cox.net> 1139281078 -0800
committer Junio C Hamano <junkio@cox.net> 1139281078 -0800
That is, the user said GIT_AUTHOR_NAME is empty, so he gets a
commit with an empty author name.
get_ident() in ident.c does this. getenv("GIT_AUTHOR_NAME") and
friends are passed to it, and git_default_* are takenfrom gecos.
It might match some peoples' expectation (but not mine) if we
did this instead.
diff --git a/ident.c b/ident.c
index 0461b8b..7ec7516 100644
--- a/ident.c
+++ b/ident.c
@@ -163,9 +163,9 @@ static const char *get_ident(const char
char date[50];
int i;
- if (!name)
+ if (!name || !*name)
name = git_default_name;
- if (!email)
+ if (!email || !*email)
email = git_default_email;
strcpy(date, git_default_date);
if (date_str)
^ permalink raw reply related
* Re: git-am: "Patch fragment without a header"
From: Junio C Hamano @ 2006-02-07 3:20 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43E80D23.4070007@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> git-am from git-1.1.6 refuses to apply the following two patches,
> whereas patch(1) sees nothing wrong with them...
Linus would have said "Say No to MIME". I am a bit too busy
right now so if you are inclined to take a look, the problem is
in mailinfo.
It tries to do a limited form of MIME and fails. The problem is
that it does not handle different content transfer encodings
used in the same message. The first part of the multipart (log
message) does this:
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
and it then switches to:
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline; filename=klibc-add-luks-to-fstype-v2
Index: klibc/usr/kinit/fstype/fstype.c
===================================================================
--- .....
in the second part. The mailinfo splits them alright but it
still thinks it needs to help with quoted printable, and ends up
eating these ===== marks and spitting out garbage.
^ permalink raw reply
* [PATCH 2/3] Docs: move git url and remotes text to separate sections
From: J. Bruce Fields @ 2006-02-07 3:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1139282428.ec02f402.0@fieldses.org>
The sections on git urls and remotes files in the git-fetch,
git-pull, and git-push manpages seem long enough to be worth a
manpage section of their own.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-fetch.txt | 2 +-
Documentation/git-pull.txt | 3 ++-
Documentation/git-push.txt | 5 +++--
Documentation/pull-fetch-param.txt | 3 +--
Documentation/urls.txt | 32 +++++++++++++++++++-------------
5 files changed, 26 insertions(+), 19 deletions(-)
6f35b7d338781d0ad18980045cdc6ff4fe0a7b98
diff --git a/Documentation/git-fetch.txt b/Documentation/git-fetch.txt
index d1b45f9..a67dc34 100644
--- a/Documentation/git-fetch.txt
+++ b/Documentation/git-fetch.txt
@@ -27,7 +27,7 @@ include::fetch-options.txt[]
include::pull-fetch-param.txt[]
-
+include::urls.txt[]
SEE ALSO
--------
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 3a7d385..20175f4 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -29,8 +29,9 @@ include::fetch-options.txt[]
include::pull-fetch-param.txt[]
-include::merge-strategies.txt[]
+include::urls.txt[]
+include::merge-strategies.txt[]
EXAMPLES
--------
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 7e9452e..ce909f5 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -24,8 +24,8 @@ documentation for gitlink:git-receive-pa
OPTIONS
-------
<repository>::
- The "remote" repository that is destination of a push operation.
-include::urls.txt[]
+ The "remote" repository that is destination of a push
+ operation. See the section <<URLS,GIT URLS>> below.
<refspec>::
The canonical format of a <refspec> parameter is
@@ -65,6 +65,7 @@ Some short-cut notations are also suppor
This flag disables the check. This can cause the
remote repository to lose commits; use it with care.
+include::urls.txt[]
Author
------
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 9011ffb..e852f41 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -1,7 +1,6 @@
<repository>::
The "remote" repository that is the source of a fetch
- or pull operation.
-include::urls.txt[]
+ or pull operation. See the section <<URLS,GIT URLS>> below.
<refspec>::
The canonical format of a <refspec> parameter is
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
index e027c71..7477413 100644
--- a/Documentation/urls.txt
+++ b/Documentation/urls.txt
@@ -1,6 +1,9 @@
+GIT URLS[[URLS]]
+----------------
+
One of the following notations can be used
to name the remote repository:
-+
+
===============================================================
- rsync://host.xz/path/to/repo.git/
- http://host.xz/path/to/repo.git/
@@ -11,39 +14,42 @@ to name the remote repository:
- ssh://host.xz/~user/path/to/repo.git/
- ssh://host.xz/~/path/to/repo.git
===============================================================
-+
+
SSH Is the default transport protocol and also supports an
scp-like syntax. Both syntaxes support username expansion,
as does the native git protocol. The following three are
identical to the last three above, respectively:
-+
+
===============================================================
- host.xz:/path/to/repo.git/
- host.xz:~user/path/to/repo.git/
- host.xz:path/to/repo.git
===============================================================
-+
+
To sync with a local directory, use:
-+
+
===============================================================
- /path/to/repo.git/
===============================================================
-+
+
+REMOTES
+-------
+
In addition to the above, as a short-hand, the name of a
file in `$GIT_DIR/remotes` directory can be given; the
named file should be in the following format:
-+
+
URL: one of the above URL format
Push: <refspec>
Pull: <refspec>
-+
-When such a short-hand is specified in place of
+
+Then such a short-hand is specified in place of
<repository> without <refspec> parameters on the command
line, <refspec> specified on `Push:` lines or `Pull:`
lines are used for `git-push` and `git-fetch`/`git-pull`,
respectively. Multiple `Push:` and and `Pull:` lines may
be specified for additional branch mappings.
-+
+
The name of a file in `$GIT_DIR/branches` directory can be
specified as an older notation short-hand; the named
file should contain a single line, a URL in one of the
@@ -52,11 +58,11 @@ name of remote head (URL fragment notati
`$GIT_DIR/branches/<remote>` file that stores a <url>
without the fragment is equivalent to have this in the
corresponding file in the `$GIT_DIR/remotes/` directory.
-+
+
URL: <url>
Pull: refs/heads/master:<remote>
-+
+
while having `<url>#<head>` is equivalent to
-+
+
URL: <url>
Pull: refs/heads/<head>:<remote>
--
0.99.8b.g3480-dirty
^ permalink raw reply related
* [PATCH 3/3] Docs: minor git-push copyediting
From: J. Bruce Fields @ 2006-02-07 3:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1139282428.ec02f402.1@fieldses.org>
Minor git-push copyediting
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-push.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
a9a95125f25c8f70fe52ab0e30fe5ff6473d7679
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index ce909f5..5b89110 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -16,7 +16,7 @@ DESCRIPTION
Updates remote refs using local refs, while sending objects
necessary to complete the given refs.
-You can make "interesting" things to happen on the repository
+You can make interesting things happen to a repository
every time you push into it, by setting up 'hooks' there. See
documentation for gitlink:git-receive-pack[1].
@@ -51,8 +51,8 @@ Some short-cut notations are also suppor
in the source.
\--all::
- Instead of naming each ref to push, specifies all refs
- to be pushed.
+ Instead of naming each ref to push, specifies that all
+ refs be pushed.
\--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
--
0.99.8b.g3480-dirty
^ permalink raw reply related
* [PATCH 1/3] Docs: split up pull-fetch-param.txt
From: J. Bruce Fields @ 2006-02-07 3:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The push and pull man pages include a bunch of shared text from
pull-fetch-param.txt. This simplifies maintenance somewhat, but
there's actually quite a bit of text that applies only to one or the
other.
So, separate out the push- and pull/fetch-specific text into
pull-fetch-param.txt and git-push.txt, then include the largest chunk
of common stuff (the description of protocols and url's) from
urls.txt. That cuts some irrelevant stuff from the man pages without
making us duplicate too much.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-push.txt | 27 +++++++++++
Documentation/pull-fetch-param.txt | 86 +++---------------------------------
Documentation/urls.txt | 62 ++++++++++++++++++++++++++
3 files changed, 94 insertions(+), 81 deletions(-)
create mode 100644 Documentation/urls.txt
be7ed0ba1dc97ad215f0785095930902597ca886
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index a0ef61d..7e9452e 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -23,7 +23,32 @@ documentation for gitlink:git-receive-pa
OPTIONS
-------
-include::pull-fetch-param.txt[]
+<repository>::
+ The "remote" repository that is destination of a push operation.
+include::urls.txt[]
+
+<refspec>::
+ The canonical format of a <refspec> parameter is
+ `+?<src>:<dst>`; that is, an optional plus `+`, followed
+ by the source ref, followed by a colon `:`, followed by
+ the destination ref.
++
+The <src> side can be an
+arbitrary "SHA1 expression" that can be used as an
+argument to `git-cat-file -t`. E.g. `master~4` (push
+four parents before the current master head).
++
+The local ref that matches <src> is used
+to fast forward the remote ref that matches <dst>. If
+the optional plus `+` is used, the remote ref is updated
+even if it does not result in a fast forward update.
++
+Some short-cut notations are also supported.
++
+* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+* A parameter <ref> without a colon is equivalent to
+ <ref>`:`<ref>, hence updates <ref> in the destination from <ref>
+ in the source.
\--all::
Instead of naming each ref to push, specifies all refs
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 4524fee..9011ffb 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -1,68 +1,7 @@
<repository>::
The "remote" repository that is the source of a fetch
- or pull operation, or the destination of a push operation.
- One of the following notations can be used
- to name the remote repository:
-+
-===============================================================
-- rsync://host.xz/path/to/repo.git/
-- http://host.xz/path/to/repo.git/
-- https://host.xz/path/to/repo.git/
-- git://host.xz/path/to/repo.git/
-- git://host.xz/~user/path/to/repo.git/
-- ssh://host.xz/path/to/repo.git/
-- ssh://host.xz/~user/path/to/repo.git/
-- ssh://host.xz/~/path/to/repo.git
-===============================================================
-+
-SSH Is the default transport protocol and also supports an
-scp-like syntax. Both syntaxes support username expansion,
-as does the native git protocol. The following three are
-identical to the last three above, respectively:
-+
-===============================================================
-- host.xz:/path/to/repo.git/
-- host.xz:~user/path/to/repo.git/
-- host.xz:path/to/repo.git
-===============================================================
-+
-To sync with a local directory, use:
-+
-===============================================================
-- /path/to/repo.git/
-===============================================================
-+
-In addition to the above, as a short-hand, the name of a
-file in `$GIT_DIR/remotes` directory can be given; the
-named file should be in the following format:
-+
- URL: one of the above URL format
- Push: <refspec>
- Pull: <refspec>
-+
-When such a short-hand is specified in place of
-<repository> without <refspec> parameters on the command
-line, <refspec> specified on `Push:` lines or `Pull:`
-lines are used for `git-push` and `git-fetch`/`git-pull`,
-respectively. Multiple `Push:` and and `Pull:` lines may
-be specified for additional branch mappings.
-+
-The name of a file in `$GIT_DIR/branches` directory can be
-specified as an older notation short-hand; the named
-file should contain a single line, a URL in one of the
-above formats, optionally followed by a hash `#` and the
-name of remote head (URL fragment notation).
-`$GIT_DIR/branches/<remote>` file that stores a <url>
-without the fragment is equivalent to have this in the
-corresponding file in the `$GIT_DIR/remotes/` directory.
-+
- URL: <url>
- Pull: refs/heads/master:<remote>
-+
-while having `<url>#<head>` is equivalent to
-+
- URL: <url>
- Pull: refs/heads/<head>:<remote>
+ or pull operation.
+include::urls.txt[]
<refspec>::
The canonical format of a <refspec> parameter is
@@ -70,17 +9,7 @@ while having `<url>#<head>` is equivalen
by the source ref, followed by a colon `:`, followed by
the destination ref.
+
-When used in `git-push`, the <src> side can be an
-arbitrary "SHA1 expression" that can be used as an
-argument to `git-cat-file -t`. E.g. `master~4` (push
-four parents before the current master head).
-+
-For `git-push`, the local ref that matches <src> is used
-to fast forward the remote ref that matches <dst>. If
-the optional plus `+` is used, the remote ref is updated
-even if it does not result in a fast forward update.
-+
-For `git-fetch` and `git-pull`, the remote ref that matches <src>
+The remote ref that matches <src>
is fetched, and if <dst> is not empty string, the local
ref that matches it is fast forwarded using <src>.
Again, if the optional plus `+` is used, the local ref
@@ -135,10 +64,7 @@ is often useful.
Some short-cut notations are also supported.
+
* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`;
- used with pull or fetch, it requests fetching everything up to
- the given tag.
+ it requests fetching everything up to the given tag.
* A parameter <ref> without a colon is equivalent to
- <ref>: when pulling/fetching, and <ref>`:`<ref> when
- pushing. That is, do not store it locally if
- fetching, and update the same name if pushing.
-
+ <ref>: when pulling/fetching, so it merges <ref> into the current
+ branch without storing the remote branch anywhere locally
diff --git a/Documentation/urls.txt b/Documentation/urls.txt
new file mode 100644
index 0000000..e027c71
--- /dev/null
+++ b/Documentation/urls.txt
@@ -0,0 +1,62 @@
+One of the following notations can be used
+to name the remote repository:
++
+===============================================================
+- rsync://host.xz/path/to/repo.git/
+- http://host.xz/path/to/repo.git/
+- https://host.xz/path/to/repo.git/
+- git://host.xz/path/to/repo.git/
+- git://host.xz/~user/path/to/repo.git/
+- ssh://host.xz/path/to/repo.git/
+- ssh://host.xz/~user/path/to/repo.git/
+- ssh://host.xz/~/path/to/repo.git
+===============================================================
++
+SSH Is the default transport protocol and also supports an
+scp-like syntax. Both syntaxes support username expansion,
+as does the native git protocol. The following three are
+identical to the last three above, respectively:
++
+===============================================================
+- host.xz:/path/to/repo.git/
+- host.xz:~user/path/to/repo.git/
+- host.xz:path/to/repo.git
+===============================================================
++
+To sync with a local directory, use:
++
+===============================================================
+- /path/to/repo.git/
+===============================================================
++
+In addition to the above, as a short-hand, the name of a
+file in `$GIT_DIR/remotes` directory can be given; the
+named file should be in the following format:
++
+ URL: one of the above URL format
+ Push: <refspec>
+ Pull: <refspec>
++
+When such a short-hand is specified in place of
+<repository> without <refspec> parameters on the command
+line, <refspec> specified on `Push:` lines or `Pull:`
+lines are used for `git-push` and `git-fetch`/`git-pull`,
+respectively. Multiple `Push:` and and `Pull:` lines may
+be specified for additional branch mappings.
++
+The name of a file in `$GIT_DIR/branches` directory can be
+specified as an older notation short-hand; the named
+file should contain a single line, a URL in one of the
+above formats, optionally followed by a hash `#` and the
+name of remote head (URL fragment notation).
+`$GIT_DIR/branches/<remote>` file that stores a <url>
+without the fragment is equivalent to have this in the
+corresponding file in the `$GIT_DIR/remotes/` directory.
++
+ URL: <url>
+ Pull: refs/heads/master:<remote>
++
+while having `<url>#<head>` is equivalent to
++
+ URL: <url>
+ Pull: refs/heads/<head>:<remote>
--
0.99.8b.g3480-dirty
^ permalink raw reply related
* Re: git-am: "Patch fragment without a header"
From: H. Peter Anvin @ 2006-02-07 3:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtg73ld7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Linus would have said "Say No to MIME". I am a bit too busy
> right now so if you are inclined to take a look, the problem is
> in mailinfo.
>
Unfortunately git-mailinfo is in C, otherwise I'd have suggested using
the Perl MIME-tools, which seems to have all this stuff in it.
It might just be easier to try to rewrite git-mailinfo in Perl...
-hpa
^ 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