* Re: [PATCH] git-for-each-ref: move GPG sigs off %(body) to %(signature).
From: Jeff King @ 2011-08-30 16:27 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Michał Górny, git
In-Reply-To: <4E5CB0D0.7000905@drmicha.warpmail.net>
On Tue, Aug 30, 2011 at 11:43:44AM +0200, Michael J Gruber wrote:
> > When grabbing a %(body) or %(contents) off a tag, one doesn't really
> > expect to get the GPG signature as well (as it's basically useless
> > without the complete signed text). Thus, strip it off those two tags,
> > and make available via %(signature) if anyone needs it.
>
> No, please do not change %(contents). It is the complete content which
> (together with the header) enters into the sha1 calculation.
>
> You will probably also face opposition as regards to %(body), changing
> existing behaviour.
Yeah. If it were 2005, I think it might make sense to have
non-overlapping individual keys to get each part of the tag. But it's
not worth breaking backwards compatibility of "%(body)" today. So it has
to remain as-is, and we have to introduce a new key for "the body
without the signature".
> In fact, I wish we didn't have %(body) but %(contents:body) just like
> other modifiers such as :short.
>
> I think I'd go for
>
> %(contents:signature)
That makes some sense to me, though it is a little weird that the
":signature" modifier works only for tags, and not commits. In other
cases, whole keys either work or don't work (e.g., "taggerdate"). But I
guess it is not that big a deal.
> %(contents:subject) the same as %(subject)
> %(contents:body) as contents minus subject minus signature
>
> and slowly deprecate %(subject) and %(body) (simply un-document for now).
That leaves no way to get what "%(body)" provides now, right? I wonder
if anyone cares. You can always ask for:
%(contents:body)%(contents:signature)
I guess.
> > + /* look for GPG signature */
>
> Again I have to say no. Please look at
>
> 3d5854e (tag: recognize rfc1991 signatures, 2010-11-10)
>
> which uses the factored out signature detection as introduced in the
> previous commits. Thanks!
Yeah. More correct, and it's less code, too. :)
-Peff
^ permalink raw reply
* Re: [PATCH] git-for-each-ref: move GPG sigs off %(body) to %(signature).
From: Michał Górny @ 2011-08-30 15:58 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Jeff King
In-Reply-To: <4E5CB0D0.7000905@drmicha.warpmail.net>
[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]
On Tue, 30 Aug 2011 11:43:44 +0200
Michael J Gruber <git@drmicha.warpmail.net> wrote:
> > When grabbing a %(body) or %(contents) off a tag, one doesn't really
> > expect to get the GPG signature as well (as it's basically useless
> > without the complete signed text). Thus, strip it off those two
> > tags, and make available via %(signature) if anyone needs it.
>
> No, please do not change %(contents). It is the complete content which
> (together with the header) enters into the sha1 calculation.
>
> You will probably also face opposition as regards to %(body), changing
> existing behaviour.
>
> In fact, I wish we didn't have %(body) but %(contents:body) just like
> other modifiers such as :short.
Yeah, I was wondering why it is like that.
> I think I'd go for
>
> %(contents:signature)
>
> and implement
>
> %(contents:subject) the same as %(subject)
> %(contents:body) as contents minus subject minus signature
How should I implement the ':' magic? Through adding a new type or just
putting ':' in place?
--
Best regards,
Michał Górny
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]
^ permalink raw reply
* Re: Overriding ~/.gitconfig using GIT_CONFIG
From: Jeff King @ 2011-08-30 15:56 UTC (permalink / raw)
To: Richard Purdie
Cc: David Aguilar, Junio C Hamano, Daniel Barkalow,
Nguy?? n Thái Ngọc Duy, GIT Mailing-list
In-Reply-To: <1314706381.5939.348.camel@rex>
On Tue, Aug 30, 2011 at 01:13:01PM +0100, Richard Purdie wrote:
> We've gone through several iterations of this but as things stand now,
> to initially clone things we're doing:
>
> git clone --bare --mirror <url> <dir>
>
> but if we already have some existing clone we'd update with:
>
> git remote prune origin
> git remote rm origin
> git remote add --mirror origin <url>
> git fetch --all -t
>
> [...]
>
> So if a user has an origin remote in their .gitconfig, can we ignore it?
Wouldn't:
git fetch --prune <url> refs/heads/*:refs/remotes/origin/*
do what you want, and not look at config at all?
-Peff
^ permalink raw reply
* Re: Idea: "git format-patch" should get more information out of git
From: Michael J Gruber @ 2011-08-30 15:41 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Michael Haggerty, git, Johan Herland,
Jonathan Nieder
In-Reply-To: <20110830152217.GA13022@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 30.08.2011 17:22:
> On Tue, Aug 30, 2011 at 02:21:13PM +0200, Michael J Gruber wrote:
...
>> Anyways, notes survive rebase etc.
>
> You still have to manually configure:
>
> git config notes.rewriteRef refs/notes/commits
>
> Perhaps that is something that should be changed.
Right, I've done that quite a while ago and forgot.
>> and at format-patch time you can decide whether you want to include
>> them or not (with my patch).
>
> Yeah. Don't get me wrong, I think putting "---" notes into git-notes is
> way more flexible. It's just that it's also more complex, and
> unnecessarily so for many use cases.
>
> We have some patches to hide that complexity, but I was at one point
> wondering if all of the complexity was worthwhile. But as I mentioned
> above, if you want to build anything more complex than a pure-patch
> workflow, the simple solution breaks down. So it probably is worth
> pursuing.
Reminds me of the ref namespace restructuring which could help sharing
notes... Oh, lots to do before git 3.0!
Michael
^ permalink raw reply
* Re: [PATCH 2/3] unpack-trees: allow pruning with pathspec
From: David Michael Barr @ 2011-08-30 15:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Nguyen Thai Ngoc Duy
In-Reply-To: <1314653603-7533-3-git-send-email-gitster@pobox.com>
On Tue, Aug 30, 2011 at 7:33 AM, Junio C Hamano <gitster@pobox.com> wrote:
> while running a merge, but the caller in diff-lib.c::diff_cache() should
> be able to take advanrage of it.
s/advanrage/advantage/ :)
Nice little hot-fix too. I love the understatement, "moderate speed up."
--
David Barr
^ permalink raw reply
* Re: Idea: "git format-patch" should get more information out of git
From: Jeff King @ 2011-08-30 15:22 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, Michael Haggerty, git, Johan Herland,
Jonathan Nieder
In-Reply-To: <4E5CD5B9.80306@drmicha.warpmail.net>
On Tue, Aug 30, 2011 at 02:21:13PM +0200, Michael J Gruber wrote:
> > After playing around a bit with my earlier series, I made the
> > realization (perhaps obvious to others :) ), that if you are in a
> > pure-patch workflow, keeping the "---" in your commit message locally is
> > much simpler. It follows the commit around through rebases
> > automatically, it gets put into format-patch output automatically, and
> > so forth.
>
> I'm confused: Does format-patch keep it or strip it as you say above?
Format-patch will include the whole commit message, including "---" and
what comes after. But an "am" recipient will strip it out of the commit
message. IOW, you locally treat your "---" notes as part of the commit
message, but in a pure-patch workflow, upstream treats it as something
to be stripped out.
So there is asymmetry in what is in your commit versus what is in
upstream's commit. But that's OK, because how you treat the commit
(something to be tweaked and rebased, and then mailed out) and how
upstream treats it (something to go into the long-term project history)
are different.
But that breaks down if you ever want to share actual commit objects
with upstream.
> Anyways, notes survive rebase etc.
You still have to manually configure:
git config notes.rewriteRef refs/notes/commits
Perhaps that is something that should be changed.
> and at format-patch time you can decide whether you want to include
> them or not (with my patch).
Yeah. Don't get me wrong, I think putting "---" notes into git-notes is
way more flexible. It's just that it's also more complex, and
unnecessarily so for many use cases.
We have some patches to hide that complexity, but I was at one point
wondering if all of the complexity was worthwhile. But as I mentioned
above, if you want to build anything more complex than a pure-patch
workflow, the simple solution breaks down. So it probably is worth
pursuing.
-Peff
^ permalink raw reply
* Re: [PATCH 2/3] unpack-trees: allow pruning with pathspec
From: Nguyen Thai Ngoc Duy @ 2011-08-30 13:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <1314653603-7533-3-git-send-email-gitster@pobox.com>
On Tue, Aug 30, 2011 at 4:33 AM, Junio C Hamano <gitster@pobox.com> wrote:
> and this codepath probably should not be enabled while running a merge
But do you think if it works with merge (ie. a partial merge)?
There's probably no interest in partial merge now, but if narrow clone
comes, index will be also narrowed and at least fast-forward merge
should work. I think it may work, but I'm not sure. unpack_callback()
and traverse_trees() look like magic to me. There may be some
interactions between index and unpacked trees that make partial merge
fail in a subtle way.
--
Duy
^ permalink raw reply
* Re: Pointers to setup an internal git repository with access control
From: Konstantin Khomoutov @ 2011-08-30 12:59 UTC (permalink / raw)
To: robert mena; +Cc: Konstantin Khomoutov, git
In-Reply-To: <CAAZ43xYhFQzBVmjfnvRoboNPQ1OLtyq57=0ZL3B6p+dRWnJZ-g@mail.gmail.com>
On Tue, 30 Aug 2011 08:35:22 -0400
robert mena <robert.mena@gmail.com> wrote:
[...]
> I don't have to use https+dav, it can be ssh as long as it is
> encrypted and I have some sort of access control. The branches item
> is to be able to control who can merge/commit things back to, for
> example, the trunk or whatever I call the "live" branch.
>
> This way the devs can do what they want but the final merge to the
> "live" branch would be done after the Q&A approves.
Go for gitolite then.
^ permalink raw reply
* Re: [PATCH 1/3] traverse_trees(): allow pruning with pathspec
From: Nguyen Thai Ngoc Duy @ 2011-08-30 12:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <1314653603-7533-2-git-send-email-gitster@pobox.com>
On Tue, Aug 30, 2011 at 4:33 AM, Junio C Hamano <gitster@pobox.com> wrote:
> @@ -316,10 +328,18 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
Not related to the patch, but a bit of comment how this function works
and how it expects info->fn() to return would be appreciated.
> struct name_entry *entry = xmalloc(n*sizeof(*entry));
> int i;
> struct tree_desc_x *tx = xcalloc(n, sizeof(*tx));
> + struct strbuf base = STRBUF_INIT;
> + int interesting = 1;
I suspect making "base" an argument to traverse_trees() may save us a
few more alloc/free (or a lot, depends on how crowded the tree is).
There are only two users of traverse_trees(): merge-tree.c and
unpack-trees.c, changes should be manageable.
> @@ -376,16 +396,22 @@ int traverse_trees(int n, struct tree_desc *t, struct traverse_info *info)
> mask |= 1ul << i;
> if (S_ISDIR(entry[i].mode))
> dirmask |= 1ul << i;
> + e = &entry[i];
> }
Why? "e" is not used in that loop or anywhere after that.
> if (!mask)
> break;
> - ret = info->fn(n, mask, dirmask, entry, info);
> - if (ret < 0) {
> - error = ret;
> - if (!info->show_all_errors)
> - break;
> + interesting = prune_traversal(e, info, &base, interesting);
> + if (interesting < 0)
> + break;
I don't really understand this function to comment. But I guess when
interesting < 0, we only skip info->fn() and assume it returns "mask"
(its user unpack_callback() only returns either "mask" or -1). So the
code at the end of the main loop
for (i = 0; i < n; i++)
if (mask & (1ul << i))
update_extended_entry(tx + i, entry + i);
should not be skipped (by putting a break here). IOW, there should be
no "break;" here.
> }
> - mask &= ret;
> ret = 0;
While at there, remove "ret = 0;" too? I think this statement is useless.
--
Duy
^ permalink raw reply
* Re: Pointers to setup an internal git repository with access control
From: Konstantin Khomoutov @ 2011-08-30 12:22 UTC (permalink / raw)
To: robert mena; +Cc: git
In-Reply-To: <CAAZ43xZPsw2CnqOtb6wO7dRC1eMd0eweQ30w-wfzUHL5cqw=Yw@mail.gmail.com>
On Tue, 30 Aug 2011 08:01:44 -0400
robert mena <robert.mena@gmail.com> wrote:
> I am trying to migrate from SVN to git and so I am looking for tools
> that help me create an interal repository. I currently use SVN over
> HTTPS/Dav using the access.conf to be able to control which uses can
> read/write to the repos or given branches.
>
> Ideally I am looking for tools that enable me to do the same with git.
Possibly look at smart http protocol [1], [2].
I may be wrong, but this access method cannot be used to implemet
access control with branch-level granularity. If you really need this,
use gitolite [3].
1. http://progit.org/2010/03/04/smart-http.html
2. http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
3. https://github.com/sitaramc/gitolite
^ permalink raw reply
* Re: Pointers to setup an internal git repository with access control
From: robert mena @ 2011-08-30 12:35 UTC (permalink / raw)
To: Konstantin Khomoutov; +Cc: git
In-Reply-To: <20110830162223.1cbf9f98.kostix@domain007.com>
Hi,
Thanks for the reply. I'll take a look.
I don't have to use https+dav, it can be ssh as long as it is
encrypted and I have some sort of access control. The branches item
is to be able to control who can merge/commit things back to, for
example, the trunk or whatever I call the "live" branch.
This way the devs can do what they want but the final merge to the
"live" branch would be done after the Q&A approves.
On Tue, Aug 30, 2011 at 8:22 AM, Konstantin Khomoutov
<flatworm@users.sourceforge.net> wrote:
> On Tue, 30 Aug 2011 08:01:44 -0400
> robert mena <robert.mena@gmail.com> wrote:
>
>> I am trying to migrate from SVN to git and so I am looking for tools
>> that help me create an interal repository. I currently use SVN over
>> HTTPS/Dav using the access.conf to be able to control which uses can
>> read/write to the repos or given branches.
>>
>> Ideally I am looking for tools that enable me to do the same with git.
> Possibly look at smart http protocol [1], [2].
>
> I may be wrong, but this access method cannot be used to implemet
> access control with branch-level granularity. If you really need this,
> use gitolite [3].
>
> 1. http://progit.org/2010/03/04/smart-http.html
> 2. http://www.kernel.org/pub/software/scm/git/docs/git-http-backend.html
> 3. https://github.com/sitaramc/gitolite
>
^ permalink raw reply
* Re: Idea: "git format-patch" should get more information out of git
From: Michael J Gruber @ 2011-08-30 12:21 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Michael Haggerty, git, Johan Herland,
Jonathan Nieder
In-Reply-To: <20110829185546.GD756@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 29.08.2011 20:55:
> On Sat, Aug 27, 2011 at 11:34:13PM -0700, Junio C Hamano wrote:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>>
>>>> 4. There is no place to store the "additional information" (the part
>>>> that comes in patch emails between the "---" and the diffstat) while
>>>> working on the patch series;...
>>>
>>> I thought there was a RFC floating around to do this using notes and also
>>> teach it to "commit -e" a few months ago? I vaguelly recall that Peff and
>>> one of the J's were involved, so I am CC'ing them.
>>
>> Also, when I prepare a commit to be sent with an additional piece of
>> information, I often write "---" and the additional message after my
>> S-o-b: line while preparing the commit log message. Unlike format-patch
>> that strips that off, commit keeps it, which is handy.
>
> After playing around a bit with my earlier series, I made the
> realization (perhaps obvious to others :) ), that if you are in a
> pure-patch workflow, keeping the "---" in your commit message locally is
> much simpler. It follows the commit around through rebases
> automatically, it gets put into format-patch output automatically, and
> so forth.
I'm confused: Does format-patch keep it or strip it as you say above?
Anyways, notes survive rebase etc., and at format-patch time you can
decide whether you want to include them or not (with my patch).
> The only real downside is that you can never tell git "don't show me the
> cover letter cruft". Which is probably OK for your own local patches.
You can with notes...
> But the point of the "---" is that information should never make it into
> a repo, which means in any workflow that involves pulling actual git
> commits, it won't work (after reading Michael's response in another
> thread, though, I think he would be interested in a hybrid
> pull-or-apply-via-mail system).
The only difficulty would be sharing notes in a push-pull workflow (for
lack of tool support, though we do have merge support).
Cheers,
Michael
^ permalink raw reply
* Re: Overriding ~/.gitconfig using GIT_CONFIG
From: Richard Purdie @ 2011-08-30 12:13 UTC (permalink / raw)
To: David Aguilar
Cc: Junio C Hamano, Daniel Barkalow,
Nguy?? n Thái Ngọc Duy, GIT Mailing-list
In-Reply-To: <20110830031022.GA64106@gmail.com>
On Mon, 2011-08-29 at 20:10 -0700, David Aguilar wrote:
> On Mon, Aug 29, 2011 at 01:16:06PM +0100, Richard Purdie wrote:
> > On Sun, 2011-08-28 at 06:05 -0700, David Aguilar wrote:
> > > On Fri, Aug 12, 2011 at 09:44:13PM +0100, Richard Purdie wrote:
> > > > My problem isn't that I want to specify a specific .gitconfig file, I
> > > > just need it to ignore the one in $HOME. I'm happy for the .git/config
> > > > file to be used, in fact I need it to be.
> > >
> > > If you're writing a tool then it should restrict itself to
> > > git's plumbing commands. You should be able to do just about
> > > anything without needing to worry about differences in
> > > configuraiton. Git commands almost always provide a way to
> > > override configuration through the use of flags.
> > >
> > > The plumbing commands are listed in the main git manpage.
> > > See "Low-level commands (plumbing)" here:
> > > http://www.kernel.org/pub/software/scm/git/docs/
> > >
> > > What is the specific problem solved by overriding the
> > > configuration? It may be possible to solve it without needing
> > > to get too complicated.
> >
> > I'm not sure writing my own porcelain makes sense in this case.
>
> True... luckily we don't have to go that far.
>
> > The tool in question is a build system which is primarily interested in
> > building software. Sometimes the software we want to build is "bleeding
> > edge" and hence rather than download tarballs, we want to interact
> > directly with SCMs like git to obtain it.
> >
> > The commands I'm using are the likes of "git clone" and "git fetch"
> > although we do use commands listed under the plumbing section too such
> > as ls-remote and read-tree. We do "cache" checkouts and support
> > automatically noticing changes and updating/building.
> >
> > What I do want to be able to say is "ignore whatever the user might have
> > put in their ~/.gitconfig file" since I've open bug reports about people
> > putting things in there that break builds.
> >
> > The fetch/clone commands do what I need, apart from being influenced by
> > userconfig so reimplementing them myself doesn't seem like a good
> > approach.
>
> This is what we're interested in.
>
> Do you have the specifics of exactly what in the user
> ~/.gitconfig file broke the build?
>
> What I'm suggesting is that there's probably a way to avoid
> the user-dependent behavior by being explicit on
> the command-line.
>
> Specifically regarding fetch -- if you're doing "git fetch"
> and relying on the configuration then we can probably come
> up with a more explicit fetch command that has an explicit
> and predictable behavior independent of the user's
> configuraiton.
>
> Using the explicit form of the command can make the build system
> more robust.
>
> Let us know what you're cooking, it sounds interesting.
We've gone through several iterations of this but as things stand now,
to initially clone things we're doing:
git clone --bare --mirror <url> <dir>
but if we already have some existing clone we'd update with:
git remote prune origin
git remote rm origin
git remote add --mirror origin <url>
git fetch --all -t
I have a strong suspicion that the fetch --all doesn't do us any favours
since if the user defines other remotes in their local config it will
also fetch them. We could probably change this to be "git fetch origin
-t" which would be safer however the .gitconfig file that someone
reported causing problems actually defined an origin remote. I don't
want to debate whether that is sane or not, I just want to be 100% sure
we work regardless of what the user may have defined.
For reference, the reasons for the remote commands above is to be 100%
sure that we fetch the right thing if <url> has changed, or if upstream
has deleted any branches in incompatible ways. We've tried not using any
remotes at all but that seems to bring its own set of problems as we
have seen issues with fetch not downloading everything from the upstream
repo (which is what we need since this is a cache/mirror copy). We ended
up needing to be very precise about what we wanted.
When we actually come to build something we make a referenced clone that
contains an actual checkout with the commands:
git clone -s -n <dir> <dir>
git checkout <revision>
which has the nice effect of being kind on disk space and fast :).
Or in some cases where we only want a specific subdirectory:
git read-tree <revision>:<subdir>
git checkout-index -q -f -a
which is fairly evil and leaves the tree in a nasty state but its what
some people need.
In case you're interested, the code in question is part of a tool called
bitbake and is one of several different fetcher modules:
http://git.openembedded.org/cgit.cgi/bitbake/tree/lib/bb/fetch2/git.py
So if a user has an origin remote in their .gitconfig, can we ignore it?
Cheers,
Richard
--
Linux Foundation
http://www.yoctoproject.org/
^ permalink raw reply
* Pointers to setup an internal git repository with access control
From: robert mena @ 2011-08-30 12:01 UTC (permalink / raw)
To: git
Hi,
I am trying to migrate from SVN to git and so I am looking for tools
that help me create an interal repository. I currently use SVN over
HTTPS/Dav using the access.conf to be able to control which uses can
read/write to the repos or given branches.
Ideally I am looking for tools that enable me to do the same with git.
Regards.
^ permalink raw reply
* Re: git tab completion shows ansi escape sequences
From: Mike Gant @ 2011-08-30 11:59 UTC (permalink / raw)
To: git
In-Reply-To: <20110830021707.GA27166@gantsfort.com>
On Mon, Aug 29, 2011 at 8:17 PM, Mike Gant <mwgant@gmail.com> wrote:
> Tab completion results in this output:
>
> $ git <TAB><TAB>
> ^[[31m^[[K c^[[m^[[Kount-objects g^[[m^[[Ket-tar-commit-id replace
> a^[[m^[[Kdd c^[[m^[[Kvsexportcommit g^[[m^[[Krep request-pull
> a^[[m^[[Km c^[[m^[[Kvsimport g^[[m^[[Kui reset
> a^[[m^[[Knnotate c^[[m^[[Kvsserver help revert
> a^[[m^[[Kpply ci imap-send rl
> a^[[m^[[Krchive co init rm
> b^[[m^[[Kisect d^[[m^[[Kaemon instaweb send-email
> b^[[m^[[Klame d^[[m^[[Kescribe log shortlog
> b^[[m^[[Kranch d^[[m^[[Kiff logk show
> b^[[m^[[Kundle d^[[m^[[Kiff-files lol show-branch
> br d^[[m^[[Kiff-index lola st
> c^[[m^[[Kat-file d^[[m^[[Kiff-tree ls sta
> c^[[m^[[Kheck-attr d^[[m^[[Kifftool merge stage
> c^[[m^[[Kheck-ref-format f^[[m^[[Kast-export mergetool stash
> c^[[m^[[Kheckout f^[[m^[[Kast-import mv status
> c^[[m^[[Kheckout-index f^[[m^[[Ketch name-rev sts
> c^[[m^[[Kherry f^[[m^[[Ketch-pack notes submodule
> c^[[m^[[Kherry-pick f^[[m^[[Kilter-branch pull svn
> c^[[m^[[Kitool f^[[m^[[Kmt-merge-msg push tag
> c^[[m^[[Klean f^[[m^[[Kor-each-ref rebase tlog
> c^[[m^[[Klone f^[[m^[[Kormat-patch reflog unstage
> c^[[m^[[Kommit f^[[m^[[Ksck relink whatchanged
> c^[[m^[[Kommit-tree f^[[m^[[Ksck-objects remote
> c^[[m^[[Konfig g^[[m^[[Kc repack
>
> This is on Linux Mint 11 but it also happens on openSuse 11.4.
Update it does not do this on openSuse 11.4.
>
> $ echo $SHELL
> bash
>
> $ echo $BASH_VERSION
> 4.2.8(1)-release
>
> $ echo $TERM
> xterm-256color
>
> The same result when TERM is set to xterm, rxvt, rxvt-256color, rxvt-unicode.
>
> Does anyone know why I'm getting this output?
>
> Thanks,
> Mike
> --
> 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
>
^ permalink raw reply
* Re: [PATCH 0/3] Un-pessimize "diff-index $commit -- $pathspec"
From: Michael J Gruber @ 2011-08-30 10:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds, Nguyen Thai Ngoc Duy
In-Reply-To: <1314653603-7533-1-git-send-email-gitster@pobox.com>
Junio C Hamano venit, vidit, dixit 29.08.2011 23:33:
> "git diff A B -- $pathspec" to compare two tree-ishes knew how to apply
> pathspec to avoid opening trees that fall outside the area of interest,
> but "git diff A -- $pathspec" used unpack_trees() machinery that was meant
> for full-tree merges, and ended up reading the whole tree only to discard
> potentially major part of the work it does.
Seems my analysis wasn't that far off (though, admittedly, unspecific):
MG:
> Well, we have to read the full tree before diffing. But I can't
...
> I meant: The way "git diff" is now, it does that.
JC:
> anything to do with it (iow, your "The way 'git diff' is now, it does
> that" is not just incorrect---we don't read the full tree to begin
> with---but irrelevant).
Anyways, as MR writes:
MR:
> 30s without patch and 0.3s with it. You rock ;)
I agree with all of that ;)
Michael
^ permalink raw reply
* Re: [PATCH] git-for-each-ref: move GPG sigs off %(body) to %(signature).
From: Michael J Gruber @ 2011-08-30 9:43 UTC (permalink / raw)
To: Michał Górny; +Cc: git, Jeff King
In-Reply-To: <1314694641-24148-1-git-send-email-mgorny@gentoo.org>
Michał Górny venit, vidit, dixit 30.08.2011 10:57:
Welcome to yet another MG (and a fresh spelling of Michael) on the list ;)
> When grabbing a %(body) or %(contents) off a tag, one doesn't really
> expect to get the GPG signature as well (as it's basically useless
> without the complete signed text). Thus, strip it off those two tags,
> and make available via %(signature) if anyone needs it.
No, please do not change %(contents). It is the complete content which
(together with the header) enters into the sha1 calculation.
You will probably also face opposition as regards to %(body), changing
existing behaviour.
In fact, I wish we didn't have %(body) but %(contents:body) just like
other modifiers such as :short.
I think I'd go for
%(contents:signature)
and implement
%(contents:subject) the same as %(subject)
%(contents:body) as contents minus subject minus signature
and slowly deprecate %(subject) and %(body) (simply un-document for now).
Jeff will have more to say about this. Please see below for the sig
detection:
> Signed-off-by: Michał Górny <mgorny@gentoo.org>
> ---
> Documentation/git-for-each-ref.txt | 3 ++-
> builtin/for-each-ref.c | 35 +++++++++++++++++++++++++++++------
> 2 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
> index 152e695..7145c46 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for-each-ref.txt
> @@ -103,7 +103,8 @@ and `date` to extract the named component.
>
> The first line of the message in a commit and tag object is
> `subject`, the remaining lines are `body`. The whole message
> -is `contents`.
> +is `contents`. If the message is GPG-signed, the signature is
> +`signature`.
>
> For sorting purposes, fields with numeric values sort in numeric
> order (`objectsize`, `authordate`, `committerdate`, `taggerdate`).
> diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
> index 89e75c6..fa5c292 100644
> --- a/builtin/for-each-ref.c
> +++ b/builtin/for-each-ref.c
> @@ -10,6 +10,9 @@
> #include "parse-options.h"
> #include "remote.h"
>
> +/* Used to strip signature off body */
> +#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----\n"
> +
> /* Quoting styles */
> #define QUOTE_NONE 0
> #define QUOTE_SHELL 1
> @@ -69,6 +72,7 @@ static struct {
> { "subject" },
> { "body" },
> { "contents" },
> + { "signature" },
> { "upstream" },
> { "symref" },
> { "flag" },
> @@ -458,7 +462,7 @@ static void grab_person(const char *who, struct atom_value *val, int deref, stru
> }
> }
>
> -static void find_subpos(const char *buf, unsigned long sz, const char **sub, const char **body)
> +static void find_subpos(const char *buf, unsigned long sz, const char **sub, const char **body, const char **sig)
> {
> while (*buf) {
> const char *eol = strchr(buf, '\n');
> @@ -478,18 +482,34 @@ static void find_subpos(const char *buf, unsigned long sz, const char **sub, con
> buf = strchr(buf, '\n');
> if (!buf) {
> *body = "";
> + *sig = *body;
> return; /* no body */
> }
> while (*buf == '\n')
> buf++; /* skip blank between subject and body */
> *body = buf;
> + *sig = *body;
> +
> + /* look for GPG signature */
Again I have to say no. Please look at
3d5854e (tag: recognize rfc1991 signatures, 2010-11-10)
which uses the factored out signature detection as introduced in the
previous commits. Thanks!
> + while (*buf) {
> + const char *eol = strchr(buf, '\n');
> + if (!eol) {
> + *sig = buf + strlen(buf);
> + return;
> + }
> + if (!strncmp(eol + 1, PGP_SIGNATURE, ARRAY_SIZE(PGP_SIGNATURE)-1)) {
> + *sig = eol + 1;
> + break; /* found end of body */
> + }
> + buf = eol + 1;
> + }
> }
>
> /* See grab_values */
> static void grab_sub_body_contents(struct atom_value *val, int deref, struct object *obj, void *buf, unsigned long sz)
> {
> int i;
> - const char *subpos = NULL, *bodypos = NULL;
> + const char *subpos = NULL, *bodypos = NULL, *sigpos = NULL;
>
> for (i = 0; i < used_atom_cnt; i++) {
> const char *name = used_atom[i];
> @@ -500,19 +520,22 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct obj
> name++;
> if (strcmp(name, "subject") &&
> strcmp(name, "body") &&
> - strcmp(name, "contents"))
> + strcmp(name, "contents") &&
> + strcmp(name, "signature"))
> continue;
> if (!subpos)
> - find_subpos(buf, sz, &subpos, &bodypos);
> + find_subpos(buf, sz, &subpos, &bodypos, &sigpos);
> if (!subpos)
> return;
>
> if (!strcmp(name, "subject"))
> v->s = copy_line(subpos);
> else if (!strcmp(name, "body"))
> - v->s = xstrdup(bodypos);
> + v->s = xstrndup(bodypos, sigpos - bodypos);
> else if (!strcmp(name, "contents"))
> - v->s = xstrdup(subpos);
> + v->s = xstrndup(subpos, sigpos - subpos);
> + else if (!strcmp(name, "signature"))
> + v->s = xstrdup(sigpos);
> }
> }
>
^ permalink raw reply
* [PATCH v2] Documentation: clarify effects of -- <path> arguments
From: Thomas Rast @ 2011-08-30 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbov74w25.fsf@alter.siamese.dyndns.org>
'git log -- <path>' does not "show commits that affect the specified
paths" in a literal sense unless --full-history is given (for example,
a file that only existed on a side branch will turn up no commits at
all!).
Reword it to specify the actual intent of the filtering, and point to
the "History Simplification" section.
The first new sentence was suggested by Junio.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Junio C Hamano wrote:
> Thomas Rast <trast@student.ethz.ch> writes:
>
> > 'git log -- <path>' does not "show commits that affect the specified
> > paths" in a literal sense unless --full-history is given (for example,
> > a file that only existed on a side branch will turn up no commits at
> > all!).
> >
> > Point the user to the "History Simplification" section to avoid
> > surprises.
>
> Hmm, or perhaps replace it with a brief explanation instead of redirecting
> the readers to a separate section without telling them anything here?
>
> Show only commits that are enough to explain how the files that match
> the specified paths came to be.
>
> (this is my attempt to paraphrase $gmane/90659)
Or both? I really like your version; I tried to come up with a
concise wording and couldn't. But the user may still want to read
about it in detail.
Documentation/git-log.txt | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 6c93466..249fc87 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -69,10 +69,13 @@ produced by --stat etc.
its size is not included.
[\--] <path>...::
- Show only commits that affect any of the specified paths. To
- prevent confusion with options and branch names, paths may need
- to be prefixed with "\-- " to separate them from options or
- refnames.
+ Show only commits that are enough to explain how the files
+ that match the specified paths came to be. See "History
+ Simplification" below for details and other simplification
+ modes.
++
+To prevent confusion with options and branch names, paths may need to
+be prefixed with "\-- " to separate them from options or refnames.
include::rev-list-options.txt[]
--
1.7.7.rc0.370.gdcae57
^ permalink raw reply related
* [PATCH] git-for-each-ref: move GPG sigs off %(body) to %(signature).
From: Michał Górny @ 2011-08-30 8:57 UTC (permalink / raw)
To: git; +Cc: Jeff King, Michał Górny
In-Reply-To: <20110829213757.GB14299@sigill.intra.peff.net>
When grabbing a %(body) or %(contents) off a tag, one doesn't really
expect to get the GPG signature as well (as it's basically useless
without the complete signed text). Thus, strip it off those two tags,
and make available via %(signature) if anyone needs it.
Signed-off-by: Michał Górny <mgorny@gentoo.org>
---
Documentation/git-for-each-ref.txt | 3 ++-
builtin/for-each-ref.c | 35 +++++++++++++++++++++++++++++------
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 152e695..7145c46 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -103,7 +103,8 @@ and `date` to extract the named component.
The first line of the message in a commit and tag object is
`subject`, the remaining lines are `body`. The whole message
-is `contents`.
+is `contents`. If the message is GPG-signed, the signature is
+`signature`.
For sorting purposes, fields with numeric values sort in numeric
order (`objectsize`, `authordate`, `committerdate`, `taggerdate`).
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 89e75c6..fa5c292 100644
--- a/builtin/for-each-ref.c
+++ b/builtin/for-each-ref.c
@@ -10,6 +10,9 @@
#include "parse-options.h"
#include "remote.h"
+/* Used to strip signature off body */
+#define PGP_SIGNATURE "-----BEGIN PGP SIGNATURE-----\n"
+
/* Quoting styles */
#define QUOTE_NONE 0
#define QUOTE_SHELL 1
@@ -69,6 +72,7 @@ static struct {
{ "subject" },
{ "body" },
{ "contents" },
+ { "signature" },
{ "upstream" },
{ "symref" },
{ "flag" },
@@ -458,7 +462,7 @@ static void grab_person(const char *who, struct atom_value *val, int deref, stru
}
}
-static void find_subpos(const char *buf, unsigned long sz, const char **sub, const char **body)
+static void find_subpos(const char *buf, unsigned long sz, const char **sub, const char **body, const char **sig)
{
while (*buf) {
const char *eol = strchr(buf, '\n');
@@ -478,18 +482,34 @@ static void find_subpos(const char *buf, unsigned long sz, const char **sub, con
buf = strchr(buf, '\n');
if (!buf) {
*body = "";
+ *sig = *body;
return; /* no body */
}
while (*buf == '\n')
buf++; /* skip blank between subject and body */
*body = buf;
+ *sig = *body;
+
+ /* look for GPG signature */
+ while (*buf) {
+ const char *eol = strchr(buf, '\n');
+ if (!eol) {
+ *sig = buf + strlen(buf);
+ return;
+ }
+ if (!strncmp(eol + 1, PGP_SIGNATURE, ARRAY_SIZE(PGP_SIGNATURE)-1)) {
+ *sig = eol + 1;
+ break; /* found end of body */
+ }
+ buf = eol + 1;
+ }
}
/* See grab_values */
static void grab_sub_body_contents(struct atom_value *val, int deref, struct object *obj, void *buf, unsigned long sz)
{
int i;
- const char *subpos = NULL, *bodypos = NULL;
+ const char *subpos = NULL, *bodypos = NULL, *sigpos = NULL;
for (i = 0; i < used_atom_cnt; i++) {
const char *name = used_atom[i];
@@ -500,19 +520,22 @@ static void grab_sub_body_contents(struct atom_value *val, int deref, struct obj
name++;
if (strcmp(name, "subject") &&
strcmp(name, "body") &&
- strcmp(name, "contents"))
+ strcmp(name, "contents") &&
+ strcmp(name, "signature"))
continue;
if (!subpos)
- find_subpos(buf, sz, &subpos, &bodypos);
+ find_subpos(buf, sz, &subpos, &bodypos, &sigpos);
if (!subpos)
return;
if (!strcmp(name, "subject"))
v->s = copy_line(subpos);
else if (!strcmp(name, "body"))
- v->s = xstrdup(bodypos);
+ v->s = xstrndup(bodypos, sigpos - bodypos);
else if (!strcmp(name, "contents"))
- v->s = xstrdup(subpos);
+ v->s = xstrndup(subpos, sigpos - subpos);
+ else if (!strcmp(name, "signature"))
+ v->s = xstrdup(sigpos);
}
}
--
1.7.6.1
^ permalink raw reply related
* Re: [PATCH v3] Makefile: Improve compiler header dependency check
From: Jonathan Nieder @ 2011-08-30 8:33 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Fredrik Kuivinen, git
In-Reply-To: <1314692855-75113-1-git-send-email-davvid@gmail.com>
David Aguilar wrote:
> The Makefile enables CHECK_HEADER_DEPENDENCIES when the
> compiler supports generating header dependencies.
> Make the check use the same flags as the invocation
> to avoid a false positive when user-configured compiler
> flags contain incompatible options.
>
> For example, without this patch, trying to build universal
> binaries on a Mac using CFLAGS='-arch i386 -arch x86_64'
> produces:
>
> gcc-4.2: -E, -S, -save-temps and -M options are
> not allowed with multiple -arch flags
>
> Make the check use the same flags as the invocation to avoid
> false positives when user-configured compiler flags contain
> incompatible options.
What happened with this third paragraph? It seems to repeat
the first one...
^ permalink raw reply
* Re: [PATCH 1/2] am: preliminary support for hg patches
From: Giuseppe Bilotta @ 2011-08-30 8:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd3fo53oe.fsf@alter.siamese.dyndns.org>
On Mon, Aug 29, 2011 at 11:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> Nope, it doesn't have index .... lines. Still, the patches seems to
>> apply correctly. Well, the couple of patches I tested did, at least,
>> even though they were marked as diff --git and they were lacking the
>> index ... lines.
>
> Does "am -3" do the right thing when the patch does not apply cleanly, for
> example?
three-way merges are impossible because all hash information is being
stripped (hg stores them in the Node ID and Parent metadata, which we
strip, and has no index metadata for the actual diff blocks). This is
correctly detected by -3, with
Applying: Threeway test
fatal: sha1 information is lacking or useless (dir.h).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 Threeway test
The message is a bit misleading (it's not the repo lacking the blobs,
it's the patch missing the information), but the process fails as
expected.
> What about renaming patches?
They lack similarity indices, but they seem to be properly formated
(and the simple cases I tested apply correctly).
In fact, stripping the --git from an hg patch containing a rename
makes the patch unusable:
error: datetime.move: does not exist in index
Patch failed at 0001 Move
So I think that keeping the --git is the right choice.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH v3] Makefile: Improve compiler header dependency check
From: David Aguilar @ 2011-08-30 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Fredrik Kuivinen, git
In-Reply-To: <20110830040515.GC6647@elie.gateway.2wire.net>
The Makefile enables CHECK_HEADER_DEPENDENCIES when the
compiler supports generating header dependencies.
Make the check use the same flags as the invocation
to avoid a false positive when user-configured compiler
flags contain incompatible options.
For example, without this patch, trying to build universal
binaries on a Mac using CFLAGS='-arch i386 -arch x86_64'
produces:
gcc-4.2: -E, -S, -save-temps and -M options are
not allowed with multiple -arch flags
Make the check use the same flags as the invocation to avoid
false positives when user-configured compiler flags contain
incompatible options.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index aa67142..0ea1a2b 100644
--- a/Makefile
+++ b/Makefile
@@ -1250,9 +1250,9 @@ COMPUTE_HEADER_DEPENDENCIES =
USE_COMPUTED_HEADER_DEPENDENCIES =
else
ifndef COMPUTE_HEADER_DEPENDENCIES
-dep_check = $(shell sh -c \
- '$(CC) -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
- echo $$?')
+dep_check = $(shell $(CC) $(ALL_CFLAGS) \
+ -c -MF /dev/null -MMD -MP -x c /dev/null -o /dev/null 2>&1; \
+ echo $$?)
ifeq ($(dep_check),0)
COMPUTE_HEADER_DEPENDENCIES=YesPlease
endif
--
1.7.7.rc0.326.gf688b5
^ permalink raw reply related
* Re: [PATCH 0/3] Un-pessimize "diff-index $commit -- $pathspec"
From: Marat Radchenko @ 2011-08-30 6:16 UTC (permalink / raw)
To: git
In-Reply-To: <7vfwkj4wff.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster <at> pobox.com> writes:
> Marat, if/when you have a chance could you try a patched git on your
> original use case and see if it produces correct output with shorter
> amount of time?
30s without patch and 0.3s with it. You rock :)
^ permalink raw reply
* Re: [PATCH v2] Makefile: Improve compiler header dependency check
From: Jonathan Nieder @ 2011-08-30 4:05 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: David Aguilar, Junio C Hamano, git
In-Reply-To: <CALx8hKTx3r=ow+=jsCyvZGRJ6Yr+w9TT7=Uyi4y4+beOou45AA@mail.gmail.com>
Hi,
Fredrik Kuivinen wrote:
> On Sat, Aug 27, 2011 at 23:00, David Aguilar <davvid@gmail.com> wrote:
>> I'm not sure if "sh -c" is necessary but I did notice that other
>> parts of the Makefile use $(SHELL_PATH). The check was adjusted
>> to use that as well.
>
> I'm not sure either. I just used what I saw at other places in the Makefile.
It is not needed, and imho it makes it harder to read. I believe the
current uses of "sh -c" near the top of the Makefile are to emphasize
that a POSIX shell has not been determined yet (so POSIXy constructs
cannot be used at that point on platforms like Solaris).
Aside from that, this seems good, though. While at it, the log
message could be simplified to something closer to the original
version:
The Makefile enables CHECK_HEADER_DEPENDENCIES when the
compiler supports generating header dependencies.
Make the check use the same flags as the invocation
to avoid a false positive when user-configured compiler
flags contain incompatible options.
For example, without this patch, trying to build universal
binaries on a Mac using CFLAGS='-arch i386 -arch x86_64'
produces
gcc-4.2: -E, -S, -save-temps and -M options are
not allowed with multiple -arch flags
While at it, remove "sh -c" in the command passed to $(shell);
at this point in the Makefile, SHELL has already been set to
a sensible shell and it is better not to override that.
Thanks again and sorry for the fuss.
Cheers,
Jonathan
^ permalink raw reply
* Re: [PATCH 2/2] Add a remote helper to interact with mediawiki (fetch & push)
From: Jonathan Nieder @ 2011-08-30 3:56 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Matthieu Moy, git, Jeremie Nikaes, Arnaud Lacurie,
Claire Fousse, David Amouyal, Matthieu Moy, Sylvain Boulmé,
Ramkumar Ramachandra, Dmitry Ivankov
In-Reply-To: <CAGdFq_jwLGZ+tLKramRrLJmwyY_uDtj7JXUwYBO9pSqOmZ20xQ@mail.gmail.com>
Sverre Rabbelier wrote:
> On Mon, Aug 29, 2011 at 08:05, Junio C Hamano <gitster@pobox.com> wrote:
>> Does this exchange suggest that at least we would need an update to
>> documentation around "done", as Matthieu's "why is 'done' needed even
>> though I am not calling with --done?" sounds like a very fair question.
>
> No I think the documentation for fast-import is correct.
However, the documentation for git-remote-helpers is hopelessly outdated.
Here's an old attempt to make the documentation a little easier to read,
and hopefully also to add to. The text from "Capabilities for Pushing"
on needs help to avoid seeming redundant in light of the list of
capabilities before, but I'm sending it now to get comments and
hopefully help from other interested people.
It does _not_ document recent changes; patches for that would
presumably come on top. Last time I sent this to list[1], it brought
to life some inconsistencies in how the various "list" commands are
used. Another response was to flesh out what a capability for
fetching a single tree ("git archive --remote") would look like[2],
for which I was very grateful (and I'd happy to see it come to life).
[1] http://thread.gmane.org/gmane.comp.version-control.git/169341
[2] http://colabti.org/irclogger/irclogger_log/git-devel?date=2011-03-19#l434
-- >8 --
Subject: Documentation/remote-helpers: explain capabilities first
The current remote helper documentation is from the perspective of
git, so to speak: it presents a full menu of commands for a person
invoking a remote helper to choose from. In practice, that's less
useful than it could be, since the daunted novice remote-helper author
probably just wanted a list of commands needs to implement to get
started. So preface the command list with an overview of each
capability, its purpose, and what commands it requires.
As a side effect, this makes it a little clearer that git doesn't
choose arbitrary commands to run, even if the remote helper advertises
all capabilities --- instead, there are well defined command sequences
for various tasks.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-remote-helpers.txt | 159 +++++++++++++++++++++++++++-------
1 files changed, 129 insertions(+), 30 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 58f6ad49..f3fd63a4 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -23,22 +23,141 @@ output. Because a remote helper runs as an independent process from
git, there is no need to re-link git to add a new helper, nor any
need to link the helper with the implementation of git.
-Every helper must support the "capabilities" command, which git will
-use to determine what other commands the helper will accept. Other
-commands generally concern facilities like discovering and updating
-remote refs, transporting objects between the object database and
-the remote repository, and updating the local object store.
-
-Helpers supporting the 'fetch' capability can discover refs from the
-remote repository and transfer objects reachable from those refs to
-the local object store. Helpers supporting the 'push' capability can
-transfer local objects to the remote repository and update remote refs.
+Every helper must support the "capabilities" command, which git
+uses to determine what other commands the helper will accept. Those
+other commands can be used to discover and update remote refs,
+transport objects between the object database and the remote repository,
+and update the local object store.
Git comes with a "curl" family of remote helpers, that handle various
transport protocols, such as 'git-remote-http', 'git-remote-https',
'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities
'fetch', 'option', and 'push'.
+INPUT FORMAT
+------------
+
+Git sends the remote helper a list of commands on standard input, one
+per line. The first command is always the 'capabilities' command, in
+response to which the remote helper must print a list of the
+capabilities it supports (see below) followed by a blank line. The
+response to the capabilities command determines what commands Git uses
+in the remainder of the command stream.
+
+The command stream is terminated by a blank line. In some cases
+(indicated in the documentation of the relevant commands), this blank
+line is followed by a payload in some other protocol (e.g., the pack
+protocol), while in others it indicates the end of input.
+
+Capabilities
+~~~~~~~~~~~~
+
+Each remote helper is expected to support only a subset of commands.
+The operations a helper supports are declared to git in the response
+to the `capabilities` command (see COMMANDS, below).
+
+'option'::
+ For specifying settings like `verbosity` (how much output to
+ write to stderr) and `depth` (how much history is wanted in the
+ case of a shallow clone) that affect how other commands are
+ carried out.
+
+'connect'::
+ For fetching and pushing using git's native packfile protocol
+ that requires a bidirectional, full-duplex connection.
+
+'push'::
+ For listing remote refs and pushing specified objects from the
+ local object store to remote refs.
+
+'fetch'::
+ For listing remote refs and fetching the associated history to
+ the local object store.
+
+'import'::
+ For listing remote refs and fetching the associated history as
+ a fast-import stream.
+
+'refspec' <refspec>::
+ This modifies the 'import' capability, allowing the produced
+ fast-import stream to modify refs in a private namespace
+ instead of writing to refs/heads or refs/remotes directly.
+ It is recommended that all importers providing the 'import'
+ capability use this.
++
+A helper advertising the capability
+`refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}`
+is saying that, when it is asked to `import refs/heads/topic`, the
+stream it outputs will update the `refs/svn/origin/branches/topic`
+ref.
++
+This capability can be advertised multiple times. The first
+applicable refspec takes precedence. The left-hand of refspecs
+advertised with this capability must cover all refs reported by
+the list command. If no 'refspec' capability is advertised,
+there is an implied `refspec {asterisk}:{asterisk}`.
+
+Capabilities for Pushing
+~~~~~~~~~~~~~~~~~~~~~~~~
+'connect'::
+ Can attempt to connect to 'git receive-pack' (for pushing),
+ 'git upload-pack', etc for communication using the
+ packfile protocol.
++
+Supported commands: 'connect'.
+
+'push'::
+ Can discover remote refs and push local commits and the
+ history leading up to them to new or existing remote refs.
++
+Supported commands: 'list for-push', 'push'.
+
+If a helper advertises both 'connect' and 'push', git will use
+'connect' if possible and fall back to 'push' if the helper requests
+so when connecting (see the 'connect' command under COMMANDS).
+
+Capabilities for Fetching
+~~~~~~~~~~~~~~~~~~~~~~~~~
+'connect'::
+ Can try to connect to 'git upload-pack' (for fetching),
+ 'git receive-pack', etc for communication using the
+ packfile protocol.
++
+Supported commands: 'connect'.
+
+'fetch'::
+ Can discover remote refs and transfer objects reachable from
+ them to the local object store.
++
+Supported commands: 'list', 'fetch'.
+
+'import'::
+ Can discover remote refs and output objects reachable from
+ them as a stream in fast-import format.
++
+Supported commands: 'list', 'import'.
+
+If a helper advertises 'connect', git will use it if possible and
+fall back to another capability if the helper requests so when
+connecting (see the 'connect' command under COMMANDS).
+When choosing between 'fetch' and 'import', git prefers 'fetch'.
+Other frontends may have some other order of preference.
+
+'refspec' <refspec>::
+ This modifies the 'import' capability.
++
+A helper advertising
+`refspec refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}`
+in its capabilities is saying that, when it handles
+`import refs/heads/topic`, the stream it outputs will update the
+`refs/svn/origin/branches/topic` ref.
++
+This capability can be advertised multiple times. The first
+applicable refspec takes precedence. The left-hand of refspecs
+advertised with this capability must cover all refs reported by
+the list command. If no 'refspec' capability is advertised,
+there is an implied `refspec {asterisk}:{asterisk}`.
+
INVOCATION
----------
@@ -167,26 +286,6 @@ completing a valid response for the current command.
Additional commands may be supported, as may be determined from
capabilities reported by the helper.
-CAPABILITIES
-------------
-
-'fetch'::
-'option'::
-'push'::
-'import'::
-'connect'::
- This helper supports the corresponding command with the same name.
-
-'refspec' 'spec'::
- When using the import command, expect the source ref to have
- been written to the destination ref. The earliest applicable
- refspec takes precedence. For example
- "refs/heads/{asterisk}:refs/svn/origin/branches/{asterisk}" means
- that, after an "import refs/heads/name", the script has written to
- refs/svn/origin/branches/name. If this capability is used at
- all, it must cover all refs reported by the list command; if
- it is not used, it is effectively "{asterisk}:{asterisk}"
-
REF LIST ATTRIBUTES
-------------------
--
1.7.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox