* Re: Questions about the new
From: Christian Couder @ 2009-10-12 21:54 UTC (permalink / raw)
To: Sergio Callegari; +Cc: Johannes Sixt, git
In-Reply-To: <4AD3619C.6010808@gmail.com>
On Monday 12 October 2009, Sergio Callegari wrote:
> Thanks Johannes for all the detailed explanations
>
> Johannes Sixt <j.sixt <at> viscovery.net> writes:
[...]
> > With grafts you can only change parenthood; with replace entries you
> > can change parenthood *and* all other aspects of a commit (message,
> > author, committer, dates).
> >
> > Hence, replace entries are more general than grafts.
>
> Limiting the discussion to commit objects, I think there are two
> possible scenarios.
>
> 1) You create new commits objects as needed
> 2) You do not.
>
> If you follow 1), I believe grafts and replace entries have exactly the
> same flexibility.
>
> If I happen not to like commit B in A---B---C and I want A---B'---C
> where B' has
> completely different aspects from B I can either replace B by B' or
> graft away
> B, pretending that the parent of A is B
You mean "pretending that the parent of C is A", right?
> But there are many things that can be done with grafts merely adding a
> graft (e.g. cutting away a part of history, joining history), that
> cannot be done with replace entries without creating new commits objects.
Yes, but when you create a graft, you add a new line in the graft file. You
don't get the grafts for free.
> I was asking because I was wandering whether replace entries were first
> or later
> meant to make grafts deprecated. I hope not, because for a few things
> working on
> arcs seems still nice.
I don't think they will be deprecated soon. And anyway there will probably
be a warning when a graft is used if it is deprecated.
[...]
> > > Conversely, I guess
> > > you can always simulate a replace entry with the graft mechanism,
>
> without the
>
> > > need to add any extra commit object. Am I overlooking something?
> >
> > You cannot; see above.
>
> Well, I meant for what regards commit objects only.
>
> If I want to replace some commit X by some commit X' I merely need to
> modify the
> parent information of all the commits that are child of X so that they
> pretend
> to be child of X', or am I missing something?
If you use git replace you just need to create commit X' and then use "git
replace X X'". If you use grafts, yes, you have to modify the parent
information of all the commits that are child of X.
> > You can even replace tree objects and blob objects
> > using replace entries, IIUC, but you cannot do that with grafts.
>
> Definitely right!
>
> > > 2) Is it currently possible to use a replace entry to replace a
>
> commit object
>
> > > with nothing? Namely if B has A as its sole parent, is it possible
>
> to have a
>
> > > replace entry such as A-sha1 becomes null, to pretend that B is a
>
> hierarchy
>
> > > root?
> >
> > Sure. Just make a commit object that does not have parents.
>
> OK, you need to create a new commit object. At the beginning for some
> reason I
> thought that you could replace an object
> with "nothing" or 00000000000000000000000000000000000000000000
>
> > > 3) If I remember correctly, there was a reason why grafts were not
>
> considered
>
> > > suitable for transferring across repos. Can someone remind me about
>
> it? How
>
> > > does the replace mechanism address this issue?
> >
> > The problem with grafts was that, for example, git-pack-objects
>
> obeyed the
>
> > graft, and could create a broken repository by removing grafted-away
> > objects. And since git-fsck also obeyed the graft, it did not notice
> > the breakage.
> >
> > OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck
> > never obey replace entries in the history. But they do keep track of
> > them (and the history that they reference) because they are referenced
>
> from the
>
> > refs/replace namespace.
>
> Thanks for the explanation. Can this be made possible for grafts too?
> Wouldn't
> it be a matter of having history walkers never obey grafts but keep track
> of them (i.e. of the history of the parenthood they reference)?
The problem is that grafts are special, so all the history walking commands
should be changed to deal with them specially. With the replace mechanism,
commits and refs are used, and all the commands already know how to deal
with them.
> Like we have "annotated" or heavyweight tags living as objects in the
> database,
> would it be possible or make sense to have annotated grafts or replace
> entries,
> so that one can express why, by whom and when history was changed?
There is a patch series about "notes" floating around that deals with
annotating any commit. So it could be used for that.
And anyway when you create the replacement commit, you can state in the
commit message that it is a replacement commit, who created it, etc.
Regards,
Christian.
^ permalink raw reply
* Re: [RFC PATCH 0/5] Pretty formats for reflog data
From: Thomas Rast @ 2009-10-12 21:52 UTC (permalink / raw)
To: Jeff King; +Cc: Jef Driesen, Nanako Shiraishi, git
In-Reply-To: <20091012213756.GA12166@coredump.intra.peff.net>
Jeff King wrote:
>
> I'm not sure if people will like having a longer [stash] list in a
> pager than a shorter list without one (I personally can't remember
> ever using "git stash list", so I have no strong opinion).
True. Then again we patched git-stash(1) to recommend stash/pop over
stash/apply, so we should actively show the user that s/he has a long
stash list and may want to apply them somewhere.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Avery Pennarun @ 2009-10-12 21:57 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <1255383459.15646.10.camel@localhost>
On Mon, Oct 12, 2009 at 5:37 PM, Daniele Segato <daniele.bilug@gmail.com> wrote:
> can I have a git report of $HOME/.* (without . and ..)? (all user
> setting)
>
> Or better: provide a list of directory under $HOME I want to track
>
> Instead of providing the list of directory I want to ignore i would like
> to provide the list of the directory and files I want to track :)
You can probably do pretty much anything you want by twiddling with
options in .gitignore. You should be able to add "don't ignore" names
by starting them with !, iirc.
Avery
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: sylvain @ 2009-10-12 22:04 UTC (permalink / raw)
To: Daniele Segato; +Cc: git
In-Reply-To: <1255383459.15646.10.camel@localhost>
Quoting Daniele Segato <daniele.bilug@gmail.com>:
> Il giorno lun, 12/10/2009 alle 01.28 -0400, sylvain@demarque.qc.ca ha
> scritto:
>> localhost / # git init
>
> I don't see the point of using git on the root directory :)
>
> but that made me think that it could actually be a good idea
> for /etc/ :)
> I happen to modify some configuration and then I forgot which one... and
> sometimes updates broke something
>
>
> And that make me think of another question...
>
> is there a way to have a git repo for a subset of directory that match a
> pattern?
>
> for instance...
>
> can I have a git report of $HOME/.* (without . and ..)? (all user
> setting)
>
> Or better: provide a list of directory under $HOME I want to track
>
> Instead of providing the list of directory I want to ignore i would like
> to provide the list of the directory and files I want to track :)
>
> I probably am going out of topic here but I hope you forgive me :)
I am still a Git newbee, but I am using GNU/Linux for a long time now.
I have just reformatted my disk and installed Gentoo and I have to
setup all these little things all over again. Since I clean install
only every couple of years, I often forget some details, etc.
So I am trying something new. I have my "home Git" at "~/.git" and the
"root Git" at "/root/.git" with the GIT_WORK_TREE at "/". Both have
"*" in "info/exclude", so I do provide my list of directories and
files I want to track explicitly by adding them one by one.
My home Git takes care of .bash* .vim* .emacs*, firefox passwords and
bookmarks, etc. My root git takes care of some "/etc", "/var" configs,
etc. (That is the reason why I wanted it on "/", because some
configuration tweaks are done outside of "/etc". Oh, I forgot to
mention "/usr/src/linux/.config")
My hope is that next time I'll clean install my system, I won't have
to backup my whole disk and then mount it again to recover configs
pieces by pieces. I'll just copy my two Git repositories and I'll
should be OK.
All praise the Git. :-)
^ permalink raw reply
* Re: Filesystem has no item: Working copy path [...] does not exist in repository at /usr/bin/git-svn line 3856
From: Eric Wong @ 2009-10-12 22:45 UTC (permalink / raw)
To: Daniele Segato; +Cc: Git Mailing List
In-Reply-To: <1255382764.15646.5.camel@localhost>
Daniele Segato <daniele.bilug@gmail.com> wrote:
> In this case the repo was public, what should I do to debug some git-svn
> issue like that if I encounter a problem with a non-public repo?
> May be there is some debug flag I could enable? Or I had to
> guess/explore the svn tree?
I rely on the output of "svn log -v" extensively.
I'll also use strace, ltrace, tcpdump and/or put print statements
(combined with Data::Dumper) in various places of git-svn.
Unfortunately the git-svn code is quite ugly and I still haven't had the
time or energy to clean it up myself :<
--
Eric Wong
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-12 22:49 UTC (permalink / raw)
To: Thomas Rast
Cc: Johannes Schindelin, Euguess, Mikael Magnusson, Matthieu Moy,
Jeff King, Jay Soffian, git
In-Reply-To: <200910122340.13366.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Your idea is also a backwards incompatible change, so we can just as
> well implement the original suggestion and force scripts (or us) to
> use some other means when they want to detach. Say, why not just
> invent an option along the lines of
>
> git checkout {-d|--detach} $ref
>
> to make it explicit.
Or can't you go the other way, say
git checkout -t $remote_tracking
to create a local branch forking from the named remote tracking branch?
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2009, #02; Sun, 11)
From: Junio C Hamano @ 2009-10-12 22:52 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091012051442.GB23007@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Oct 11, 2009 at 08:18:17PM -0700, Junio C Hamano wrote:
>
>> * jk/1.7.0-status (2009-09-05) 5 commits.
>> - docs: note that status configuration affects only long format
>> (merged to 'next' on 2009-10-11 at 65c8513)
>> + commit: support alternate status formats
>> + status: add --porcelain output format
>> + status: refactor format option parsing
>> + status: refactor short-mode printing to its own function
>> (this branch uses jc/1.7.0-status.)
>>
>> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
>> is similar to that of post 1.7.0 "git status".
>>
>> * jc/1.7.0-status (2009-09-05) 4 commits.
>> (merged to 'next' on 2009-10-11 at 9558627)
>> + status: typo fix in usage
>> + git status: not "commit --dry-run" anymore
>> + git stat -s: short status output
>> + git stat: the beginning of "status that is not a dry-run of commit"
>> (this branch is used by jk/1.7.0-status.)
>>
>> With this, "git status" is no longer "git commit --dry-run".
>
> Hmm. I thought you wanted to re-order some of these for to put the
> porcelain and short formats into v1.6.6, but leave the status switchover
> for v1.7.0.
We could build an alternate history between 3fa509d..46b77a6, revert the
merges 9558627 and 65c8513, and merge the alternate history. But is the
short format support so solid that it deserves to be in 1.6.6 in the
current shape?
^ permalink raw reply
* git-pack-objects gitattributes?
From: Nasser Grainawi @ 2009-10-12 23:00 UTC (permalink / raw)
To: Git Mailing List
Hello,
I'm trying to avoid doing delta compression on a number of large binary files.
I got a suggestion to use $GIT_DIR/info/attributes and a line like this:
*.bin -delta
This doesn't seem to show a big improvement (and honestly I can't find where in
the git-pack-objects source the value of this attribute is used).
Could someone shed some light on this attribute and any other improvements I
could make for efficiently serving up a repo over git-daemon with near-weekly
revisions of 100MB+ files?
Thanks,
Nasser
^ permalink raw reply
* Re: gitweb - bare repos integration - owner info in description file
From: Miklos Vajna @ 2009-10-12 23:19 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <76c5b8580910121448q67edd935wb189c8a6f9af2f2e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 492 bytes --]
On Mon, Oct 12, 2009 at 05:48:14PM -0400, Eugene Sajine <euguess@gmail.com> wrote:
> Yes, I might be stubborn, but is just because i feel that i can
> contribute into making git better, although I'm not a developer.
In a distrubuted environment, there is no need to define who is a
developer and who is not. And contributing is allowed to anyone as long
as you sign the Develoer's Certificate of Origin. :)
(See
http://repo.or.cz/w/git.git?a=blob;f=Documentation/SubmittingPatches;hb=HEAD)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC 3/4] git check-ref-format --print
From: Shawn O. Pearce @ 2009-10-12 23:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Jens Lehmann, git
In-Reply-To: <7veip8e302.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> I understand that you prefer the latter between "there is no tool; the
> caller is responsibile to make sure it feeds us canonical representation"
> and "there is a tool that makes a slightly malformed string into canonical
> form for the callers to use before calling us." And that would be my
> preference between these two as well.
...
> But now I have spelled this out, I do not see much upside for rejecting,
> and more importantly, I think it would be an independent issue. We can
> reject or just keep normalizing silently, and a tool to show the
> normalized name would be useful and necessary regardless of that.
I agree with the last paragraph here, we shouldn't reject, but
instead keep the current state but encourage tools to use the new
canonical print tool to clean up a name if they want to hang onto the
string the user entered and it needs to exactly match for-each-ref
sort of output.
--
Shawn.
^ permalink raw reply
* Re: [PATCH/RFC 3/4] git check-ref-format --print
From: Junio C Hamano @ 2009-10-12 23:36 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jens Lehmann, git, Shawn O. Pearce
In-Reply-To: <20091012053141.GD11106@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> In the future, it would be very nice if this command could be
> modified to transform Unicode ref names to some appropriate
> normalization form, to make Unicode ref names usable in Mac OS X,
> too, and less confusing everywhere.
I do not disagree with a desire to help fixing the unicode insanity on
that platform, but I suspect that check-ref-format is a wrong place to
tackle the issue. You would need a similar filter for outputs from the
likes of ls-files and "diff --name-only", iow, anything that deal with
pathnames, no?
It would have be something like "check-ref-format --print | iconv ..."
pipeline (conceptually, if not forcing the pipeline to the end users, that
is).
Also are people happy with "--print"? I was waiting for others to reword
it to "--normalize" or something like that. In your documentation you
explain it to "canonicalize", and in your tests you name the output
"normalized". I am fine with either wording, but would like to see us
using only one, not both.
Thanks.
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Junio C Hamano @ 2009-10-12 23:41 UTC (permalink / raw)
To: Anders Kaseorg; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0910121708030.5105@dr-wily.mit.edu>
Anders Kaseorg <andersk@MIT.EDU> writes:
> I had in mind only one case where ‘git bisect reset <commit>’ would be
> useful. I often don’t even remember what commit I was on before I started
> a bisect, much less believe that I want to immediately switch back to it.
> I would prefer to be able to clean the bisection state without checking
> out another commit at all, because that takes forever and invalidates my
> compiled tree. This is what ‘git bisect reset HEAD’ would do if it
> worked.
I am not sure what "removing bisect states" really buys you.
If having bisect states somehow interferes what you need to do in order to
decide which commit you want to switch to, it may make sense to do 'git
bisect reset HEAD' or 'git bisect stop', before starting whatever you need
to do to make that decision.
But I do not know how it hurts to still have bisect states around, in
order to find where you want to go next. Could you elaborate?
But your explanation "I often don't even remember" makes sense to me.
I would understand it, if not agreeing that I also am often in that
situation myself", if somebody does not even care which commit he was on
before starting the bisection, but knows (or is willing to decide at that
point) which branch (or even a specific commit, while still being
detached) he wants to switch to. And it would make sense to avoid an
extra checkout that snaps back to the pre-bisection commit before
switching to the new state he has chosen.
So in that sense, I would agree with your original patch more than I would
agree with what you suggested as an alternative (i.e. "git bisect stop"
which is what "git bisect reset HEAD" would do if we do not verify the
argument is the name of an existing branch) in your response.
I am inclined to ask you to come up with a paragraph in the documentation
to discuss how the optional <branch> (now it will be <commit>) parameter
to the reset subcommand is meant to be used and re-submit the original
patch, perhaps with an updated commit log message. "Allow resetting to
any" said only what the patch does, without saying why such a mode of
operation was even a good thing to begin with.
Thanks.
^ permalink raw reply
* Re: [PATCH] bash completion: complete refs for git-grep
From: Junio C Hamano @ 2009-10-12 23:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Thomas Rast, git
In-Reply-To: <20091012142710.GI9261@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Thomas Rast <trast@student.ethz.ch> wrote:
>> > So I'll roll a simpler patch that just always (before --) completes
>> > refs instead, if that's ok.
>
> Hard to argue with that logic. :-)
>
> Acked-by: Shawn O. Pearce <spearce@spearce.org>
Thanks.
>
>> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
>> index 6fd7e1d..b08cd77 100755
>> --- a/contrib/completion/git-completion.bash
>> +++ b/contrib/completion/git-completion.bash
>> @@ -1048,7 +1048,8 @@ _git_grep ()
>> return
>> ;;
>> esac
>> - COMPREPLY=()
>> +
>> + __gitcomp "$(__git_refs)"
>> }
>
> --
> Shawn.
> --
> 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: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Junio C Hamano @ 2009-10-12 23:42 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git, Jakub Narebski
In-Reply-To: <1255328340-28449-1-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> It's nice to search for an author by merely clicking on their name in
> gitweb. This is usually faster than selecting the name, copying the
> selection, pasting it into the search box, selecting between
> author/committer and then hitting enter.
The intent makes sense to me, although I somehow suspect that with avatar
support the user might be tempted to click on the icon not necessarily on
the name string.
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> Cc'ed Jakub as he seems to be resident gitweb expert.
>
> I thought this might be a nice addition.
>
> The problem is I can't get it to work with UTF-8 characters. I'm not sure
> if it's my system or not, so I'm just posting here to see if others
> experience the same problem and if there's interest.
>
> gitweb/gitweb.perl | 18 ++++++++++++++----
> 1 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 24b2193..349e734 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1604,7 +1604,10 @@ sub format_author_html {
> my $author = chop_and_escape_str($co->{'author_name'}, @_);
> return "<$tag class=\"author\">" .
> git_get_avatar($co->{'author_email'}, -pad_after => 1) .
> - $author . "</$tag>";
> + $cgi->a({-href => href(action=>"search", hash=>$hash,
> + searchtext=>$co->{'author_name'},
> + searchtype=>"author"), class=>"list"}, $author) .
> + "</$tag>";
> }
>
> # format git diff header line, i.e. "diff --(git|combined|cc) ..."
> @@ -3373,10 +3376,13 @@ sub git_print_authorship {
> my $co = shift;
> my %opts = @_;
> my $tag = $opts{-tag} || 'div';
> + my $author = $co->{'author_name'};
>
> my %ad = parse_date($co->{'author_epoch'}, $co->{'author_tz'});
> print "<$tag class=\"author_date\">" .
> - esc_html($co->{'author_name'}) .
> + $cgi->a({-href => href(action=>"search", searchtext=>$author,
> + searchtype=>"author"), class=>"list"},
> + esc_html($author)) .
> " [$ad{'rfc2822'}";
> print_local_time(%ad) if ($opts{-localtime});
> print "]" . git_get_avatar($co->{'author_email'}, -pad_before => 1)
> @@ -3395,8 +3401,12 @@ sub git_print_authorship_rows {
> @people = ('author', 'committer') unless @people;
> foreach my $who (@people) {
> my %wd = parse_date($co->{"${who}_epoch"}, $co->{"${who}_tz"});
> - print "<tr><td>$who</td><td>" . esc_html($co->{$who}) . "</td>" .
> - "<td rowspan=\"2\">" .
> + print "<tr><td>$who</td><td>" .
> + $cgi->a({-href => href(action=>"search",
> + searchtext=>$co->{"${who}_name"},
> + searchtype=>$who), class=>"list"},
> + esc_html($co->{$who})) .
> + "</td><td rowspan=\"2\">" .
> git_get_avatar($co->{"${who}_email"}, -size => 'double') .
> "</td></tr>\n" .
> "<tr>" .
> --
> 1.6.5.1.g53fd
^ permalink raw reply
* Re: [PATCH] git-add--interactive: never skip files included in index
From: Junio C Hamano @ 2009-10-12 23:42 UTC (permalink / raw)
To: Jeff King; +Cc: Pauli Virtanen, git
In-Reply-To: <20091012051157.GA23007@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Subject: [PATCH] ls-files: excludes should not impact tracked files
>
> In all parts of git, .gitignore and other exclude files
> impact only how we treat untracked files; they should have
> no effect on files listed in the index.
>
> This behavior was originally implemented very early on in
> 9ff768e, but only for --exclude-from. Later, commit 63d285c
> accidentally caused us to trigger the behavior for
> --exclude-per-directory.
>
> This patch totally ignores excludes for files found in the
> index. This means we are reversing the original intent of
> 9ff768e, while at the same time fixing the accidental
> behavior of 63d285c. This is a good thing, though, as the
> way that 9ff768e behaved does not really make sense with the
> way exclusions are used in modern git.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
Makes sense; thanks.
> I also still think that Pauli's patch makes sense; there is no point in
> passing --exclude-standard there. It should be a no-op.
Yeah, that is also queued independent from this one.
^ permalink raw reply
* Re: [PATCH] git: add --no-replace-objects option to disable replacing
From: Junio C Hamano @ 2009-10-12 23:42 UTC (permalink / raw)
To: Christian Couder
Cc: git, Jakub Narebski, Johannes Sixt, bill lam, Andreas Schwab
In-Reply-To: <20091012203033.8939.43473.chriscool@tuxfamily.org>
Thanks.
I understand that the replace mechanism is lazily initialized so it would
be Ok to flip this variable as long as it is done before anybody makes the
first call to read_sha1_file(). I am guessing the assignment the patch
adds is early enough but I didn't audit the code.
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Stephen Boyd @ 2009-10-13 0:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jakub Narebski
In-Reply-To: <7vy6ng5gdr.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> The intent makes sense to me, although I somehow suspect that with avatar
> support the user might be tempted to click on the icon not necessarily on
> the name string.
Ok if the utf8 thing can be solved I'll make sure to linkify the icon too.
^ permalink raw reply
* Re: [JGit-io-RFC-PATCH v2 2/4] Add JGit IO SPI and default implementation
From: Imran M Yousuf @ 2009-10-13 1:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, egit-dev, Imran M Yousuf
In-Reply-To: <20091012145741.GM9261@spearce.org>
On Mon, Oct 12, 2009 at 9:57 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> imyousuf@gmail.com wrote:
>> The SPI mainly focus's in providing an API to JGit to be able to perform
>> similar operations to that of java.io.File. All direct I/O is based on the
>> java.io.Input/OutputStream classes.
>>
>> Different JGit IO SPI provider is designed to be URI scheme based and thus
>> the default implementation is that of "file" scheme. SPI provider will be
<snip />
> I think this may be a bit in the wrong direction for what we are
> trying to accomplish.
>
> A number of people really want to map Git onto what is essentially
> Google's BigTable schema. Aside from Google's own BigTable product
> (which I want to use Git on at work, because it would vastly simplfiy
> my system administration duties at $DAYJOB) there is Cassandra and
> Hadoop HBase which implement the same schema semantics.
>
> None of those systems implement file streams, they implement cell
> storage in a non-transactional system with a semi-dynamic schema.
>
> Some people have built transactional semantics on top of these
> storage layers, e.g. Google AppEngine provides multiple row
> transactions through some magic sauce layered on top of BigTable.
> I'm sure people will build similar tools on top of Cassandra
> and HBase.
>
> Where I'm trying to go with this is that things that are stored
> in files on the filesystem in traditional Git wouldn't normally be
> mapped into "byte streams" in a BigTable-ish system, or even the
> JDBC-ish system you were describing.
>
> For .git/config we might want to map config variable names into
> keys in the table, with values stored in cells. This makes it
> easier to query or edit the data.
>
> Fortunately, "Config" is abstract enough that we could subclass
> it with a CassandraConfig and simply use that instance when on a
> based Cassandra storage system. No file streams required. Ditto
> for a JdbcConfig.
>
Firstly, I am sorry but I am not intelligent enough to perceive, how
do the user decide which instance of Config to use? I personally think
that there is no API to achieve what you just mentioned :(; i.e. the
user will have know CassandraConfig directly. Secondly, I instead was
thinking of porting JGit for that matter to any system supporting
streams (not any specific sub-class of them), such HBase/BigTable or
HDFS anything.... Thirdly, I think we actually have several task in
hand and I would state them as -
1. First introduce the I/O API such that it completely replaces java.io.File
2. Secondly segregate persistence of for config (or config like
objects) and introduce a SPI for them for smarter storage.
I am not thinking of storing "only" the bare content of a git
repository, but I intent to be able to also store the versioned
contents it self as well. If we choose the above 2 steps I mentioned I
am of the opinion that we will be able
to achieve both our ideas. In addition I hope that if one day Git
itself introduces a similar I/O API then Git can also support the I/O
SPI implementations JGit will.
Waiting eagerly to learn what you think :).
Best regards,
Imran
> For RefDatabase, we'd want to do the same and avoid the concept of
> packed-refs altogether. Each Ref should go into its own row in a
> Cassandra storage system, and essentially act as a loose object.
> Ditto with JDBC.
>
> We'd probably never need to read-or-write the info/refs or
> objects/info/packs listings.
>
> And I think that's everything that a bare repository needs, aside
> from ObjectDatabase, which is already mostly abstract anyway.
>
> --
> Shawn.
>
--
Imran M Yousuf
Entrepreneur & Software Engineer
Smart IT Engineering
Dhaka, Bangladesh
Email: imran@smartitengineering.com
Blog: http://imyousuf-tech.blogs.smartitengineering.com/
Mobile: +880-1711402557
^ permalink raw reply
* Re: Git: "No you can't handle my root!" (?)
From: Jeff King @ 2009-10-13 1:43 UTC (permalink / raw)
To: Daniele Segato; +Cc: sylvain, git
In-Reply-To: <1255383459.15646.10.camel@localhost>
On Mon, Oct 12, 2009 at 11:37:39PM +0200, Daniele Segato wrote:
> I don't see the point of using git on the root directory :)
>
> but that made me think that it could actually be a good idea
> for /etc/ :)
> I happen to modify some configuration and then I forgot which one... and
> sometimes updates broke something
Take a look at:
http://joey.kitenet.net/code/etckeeper/
> can I have a git report of $HOME/.* (without . and ..)? (all user
> setting)
This seems to work:
$ cd ~
$ git init
$ echo '*' >.gitignore
$ echo '!.*' >.gitignore
> Or better: provide a list of directory under $HOME I want to track
Same thing, but make your ! pattern more specific.
-Peff
^ permalink raw reply
* Re: quote in help code example
From: bill lam @ 2009-10-13 2:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20091012194016.GS23777@genesis.frugalware.org>
On Mon, 12 Oct 2009, Miklos Vajna wrote:
> On Mon, Oct 12, 2009 at 06:29:26PM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > In git man, eg. git help filter-branch
> > The code examples for command line or shell scripts inside .ft pairs
> > use (smart?) quote instead of single quotes, like
> >
> > .ft C
> > git filter-branch --tree-filter ´rm filename´ HEAD
> > .ft
> >
> > Is this intentional or just some configuration problem during
> > compiling.
>
> Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
> ASCIIDOC_NO_ROFF?
>
> Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
I'm not familiar with how to twist git makefile. By adding a line to ./Makefile
# Platform specific tweaks
#
# We choose to avoid "if .. else if .. else .. endif endif"
# because maintaining the nesting to match is a pain. If
# we had "elif" things would have been much nicer...
ASCIIDOC_NO_ROFF = YesPlease # <--- this line added
ifeq ($(uname_S),Linux)
However, the man page still display the same
.ft C
git filter-branch --tree-filter ´rm filename´ HEAD
.ft
I use debian lenny 64bit with
Package: docbook-xsl
Version: 1.73.2.dfsg.1-5
Package: asciidoc
Version: 8.2.7-3~lenny1
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* [RFC PATCH v2 00/16] Return of smart HTTP
From: Shawn O. Pearce @ 2009-10-13 2:24 UTC (permalink / raw)
To: git
The series has gotten a lot larger since my last posting, but I have
what appears to be a fully working client *AND* server implementation
for both fetch and push, and the client should be supporting deeping
shallow repositories over the smart variant of HTTP.
I've dropped the documentation patch from the series for now as
I have quite a few edits queued up from folks in the last round
(thanks for those!) that I have not yet applied. So there is no
point in sending that particular patch again.
This series is still lacking:
* The HTTP protocol documentation
* Manual page for git-http-backend
* Tests for the smart http transport code (existing tests pass)
* ack from the CC'd maintainers :-)
For those who are really curious, this applies to 'master' and I'm
running my local server under Apache with this as my configuration:
-- httpd.conf <8--
LoadModule cgi_module /usr/libexec/apache2/mod_cgi.so
LoadModule alias_module /usr/libexec/apache2/mod_alias.so
LoadModule env_module /usr/libexec/apache2/mod_env.so
Listen 127.0.0.1:8079
ServerRoot /home/spearce/test
ErrorLog error_log
PidFile httpd.pid
LockFile httpd.lock
<IfModule mime_module>
TypesConfig /etc/mime.types
</IfModule>
DocumentRoot /home/spearce/test/www
SetEnv GIT_EXEC_PATH /home/spearce/cgit
ScriptAlias /git/ /home/spearce/cgit/git-http-backend/
--<8--
$ httpd -f httpd.conf
$ git clone --bare foo.git /home/spearce/test/www/test.git
URL is ... http://localhost:8070/git/test.git
Shawn O. Pearce (16):
pkt-line: Add strbuf based functions
pkt-line: Make packet_read_line easier to debug
fetch-pack: Use a strbuf to compose the want list
Move "get_ack()" back to fetch-pack
Add multi_ack_2 capability to fetch-pack/upload-pack
remote-curl: Refactor walker initialization
remote-helpers: Fetch more than one ref in a batch
remote-helpers: Support custom transport options
Move WebDAV HTTP push under remote-curl
Git-aware CGI to provide dumb HTTP transport
Add one shot RPC options to upload-pack, receive-pack
Smart fetch and push over HTTP: server side
Discover refs via smart HTTP server when available
Smart push over HTTP: client side
Smart fetch over HTTP: client side
Smart HTTP fetch: gzip requests
.gitignore | 1 +
Documentation/config.txt | 8 +
Documentation/git-remote-helpers.txt | 79 ++++
Makefile | 1 +
builtin-fetch-pack.c | 210 ++++++++--
builtin-receive-pack.c | 26 +-
builtin-send-pack.c | 116 +++++-
cache.h | 1 -
commit.c | 10 +-
commit.h | 2 +-
connect.c | 21 -
fetch-pack.h | 3 +-
http-backend.c | 451 +++++++++++++++++++++
http-push.c | 43 ++-
pkt-line.c | 83 ++++-
pkt-line.h | 4 +
remote-curl.c | 729 +++++++++++++++++++++++++++++++--
send-pack.h | 3 +-
sideband.c | 11 +-
transport-helper.c | 264 ++++++++++++-
transport.c | 32 +--
upload-pack.c | 71 +++-
22 files changed, 1955 insertions(+), 214 deletions(-)
create mode 100644 http-backend.c
^ permalink raw reply
* [RFC PATCH v2 02/16] pkt-line: Make packet_read_line easier to debug
From: Shawn O. Pearce @ 2009-10-13 2:25 UTC (permalink / raw)
To: git
In-Reply-To: <1255400715-10508-1-git-send-email-spearce@spearce.org>
When there is an error parsing the 4 byte length component we now
NUL terminate the string and display it as part of the die message,
this may hint as to what data was misunderstood by the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
pkt-line.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/pkt-line.c b/pkt-line.c
index 2333d96..350f173 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -125,11 +125,13 @@ static int packet_length(unsigned *ret_len, const char *linelen)
int packet_read_line(int fd, char *buffer, unsigned size)
{
unsigned len;
- char linelen[4];
+ char linelen[5];
safe_read(fd, linelen, 4);
- if (packet_length(&len, linelen))
- die("protocol error: bad line length character");
+ if (packet_length(&len, linelen)) {
+ linelen[4] = '\0';
+ die("protocol error: bad line length character: %s", linelen);
+ }
if (!len)
return 0;
len -= 4;
--
1.6.5.52.g0ff2e
^ permalink raw reply related
* [RFC PATCH v2 03/16] fetch-pack: Use a strbuf to compose the want list
From: Shawn O. Pearce @ 2009-10-13 2:25 UTC (permalink / raw)
To: git
In-Reply-To: <1255400715-10508-1-git-send-email-spearce@spearce.org>
This change is being offered as a refactoring to make later
commits in the smart HTTP series easier.
By changing the enabled capabilities to be formatted in a strbuf
it is easier to add a new capability to the set of supported
capabilities.
By formatting the want portion of the request into a strbuf and
writing it as a whole block we can later decide to hold onto
the req_buf (instead of releasing it) to recycle in stateless
communications.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-fetch-pack.c | 52 ++++++++++++++++++++++++++++++++-----------------
commit.c | 10 +++-----
commit.h | 2 +-
3 files changed, 39 insertions(+), 25 deletions(-)
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 629735f..783c2b0 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -165,6 +165,7 @@ static int find_common(int fd[2], unsigned char *result_sha1,
const unsigned char *sha1;
unsigned in_vain = 0;
int got_continue = 0;
+ struct strbuf req_buf = STRBUF_INIT;
if (marked)
for_each_ref(clear_marks, NULL);
@@ -175,6 +176,7 @@ static int find_common(int fd[2], unsigned char *result_sha1,
fetching = 0;
for ( ; refs ; refs = refs->next) {
unsigned char *remote = refs->old_sha1;
+ const char *remote_hex;
struct object *o;
/*
@@ -192,27 +194,36 @@ static int find_common(int fd[2], unsigned char *result_sha1,
continue;
}
- if (!fetching)
- packet_write(fd[1], "want %s%s%s%s%s%s%s%s\n",
- sha1_to_hex(remote),
- (multi_ack ? " multi_ack" : ""),
- (use_sideband == 2 ? " side-band-64k" : ""),
- (use_sideband == 1 ? " side-band" : ""),
- (args.use_thin_pack ? " thin-pack" : ""),
- (args.no_progress ? " no-progress" : ""),
- (args.include_tag ? " include-tag" : ""),
- (prefer_ofs_delta ? " ofs-delta" : ""));
- else
- packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+ remote_hex = sha1_to_hex(remote);
+ if (!fetching) {
+ struct strbuf c = STRBUF_INIT;
+ if (multi_ack) strbuf_addstr(&c, " multi_ack");
+ if (use_sideband == 2) strbuf_addstr(&c, " side-band-64k");
+ if (use_sideband == 1) strbuf_addstr(&c, " side-band");
+ if (args.use_thin_pack) strbuf_addstr(&c, " thin-pack");
+ if (args.no_progress) strbuf_addstr(&c, " no-progress");
+ if (args.include_tag) strbuf_addstr(&c, " include-tag");
+ if (prefer_ofs_delta) strbuf_addstr(&c, " ofs-delta");
+ packet_buf_write(&req_buf, "want %s%s\n", remote_hex, c.buf);
+ strbuf_release(&c);
+ } else
+ packet_buf_write(&req_buf, "want %s\n", remote_hex);
fetching++;
}
+
+ if (!fetching) {
+ strbuf_release(&req_buf);
+ packet_flush(fd[1]);
+ return 1;
+ }
+
if (is_repository_shallow())
- write_shallow_commits(fd[1], 1);
+ write_shallow_commits(&req_buf, 1);
if (args.depth > 0)
- packet_write(fd[1], "deepen %d", args.depth);
- packet_flush(fd[1]);
- if (!fetching)
- return 1;
+ packet_buf_write(&req_buf, "deepen %d", args.depth);
+ packet_buf_flush(&req_buf);
+
+ safe_write(fd[1], req_buf.buf, req_buf.len);
if (args.depth > 0) {
char line[1024];
@@ -296,6 +307,8 @@ done:
multi_ack = 0;
flushes++;
}
+ strbuf_release(&req_buf);
+
while (flushes || multi_ack) {
int ack = get_ack(fd[0], result_sha1);
if (ack) {
@@ -809,6 +822,7 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
if (args.depth > 0) {
struct cache_time mtime;
+ struct strbuf sb = STRBUF_INIT;
char *shallow = git_path("shallow");
int fd;
@@ -826,12 +840,14 @@ struct ref *fetch_pack(struct fetch_pack_args *my_args,
fd = hold_lock_file_for_update(&lock, shallow,
LOCK_DIE_ON_ERROR);
- if (!write_shallow_commits(fd, 0)) {
+ if (!write_shallow_commits(&sb, 0)
+ || write_in_full(fd, sb.buf, sb.len) != sb.len) {
unlink_or_warn(shallow);
rollback_lock_file(&lock);
} else {
commit_lock_file(&lock);
}
+ strbuf_release(&sb);
}
reprepare_packed_git();
diff --git a/commit.c b/commit.c
index fedbd5e..471efb0 100644
--- a/commit.c
+++ b/commit.c
@@ -199,7 +199,7 @@ struct commit_graft *lookup_commit_graft(const unsigned char *sha1)
return commit_graft[pos];
}
-int write_shallow_commits(int fd, int use_pack_protocol)
+int write_shallow_commits(struct strbuf *out, int use_pack_protocol)
{
int i, count = 0;
for (i = 0; i < commit_graft_nr; i++)
@@ -208,12 +208,10 @@ int write_shallow_commits(int fd, int use_pack_protocol)
sha1_to_hex(commit_graft[i]->sha1);
count++;
if (use_pack_protocol)
- packet_write(fd, "shallow %s", hex);
+ packet_buf_write(out, "shallow %s", hex);
else {
- if (write_in_full(fd, hex, 40) != 40)
- break;
- if (write_str_in_full(fd, "\n") != 1)
- break;
+ strbuf_addstr(out, hex);
+ strbuf_addch(out, '\n');
}
}
return count;
diff --git a/commit.h b/commit.h
index f4fc5c5..817c75c 100644
--- a/commit.h
+++ b/commit.h
@@ -131,7 +131,7 @@ extern struct commit_list *get_octopus_merge_bases(struct commit_list *in);
extern int register_shallow(const unsigned char *sha1);
extern int unregister_shallow(const unsigned char *sha1);
-extern int write_shallow_commits(int fd, int use_pack_protocol);
+extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol);
extern int is_repository_shallow(void);
extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
--
1.6.5.52.g0ff2e
^ permalink raw reply related
* [RFC PATCH v2 01/16] pkt-line: Add strbuf based functions
From: Shawn O. Pearce @ 2009-10-13 2:25 UTC (permalink / raw)
To: git
In-Reply-To: <1255400715-10508-1-git-send-email-spearce@spearce.org>
These routines help to work with pkt-line values inside of a strbuf,
permitting simple formatting of buffered network messages.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
pkt-line.c | 81 +++++++++++++++++++++++++++++++++++++++++++++++++++---------
pkt-line.h | 4 +++
2 files changed, 73 insertions(+), 12 deletions(-)
diff --git a/pkt-line.c b/pkt-line.c
index b691abe..2333d96 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -42,17 +42,19 @@ void packet_flush(int fd)
safe_write(fd, "0000", 4);
}
+void packet_buf_flush(struct strbuf *buf)
+{
+ strbuf_add(buf, "0000", 4);
+}
+
#define hex(a) (hexchar[(a) & 15])
-void packet_write(int fd, const char *fmt, ...)
+static char buffer[1000];
+static unsigned format_packet(const char *fmt, va_list args)
{
- static char buffer[1000];
static char hexchar[] = "0123456789abcdef";
- va_list args;
unsigned n;
- va_start(args, fmt);
n = vsnprintf(buffer + 4, sizeof(buffer) - 4, fmt, args);
- va_end(args);
if (n >= sizeof(buffer)-4)
die("protocol error: impossibly long line");
n += 4;
@@ -60,9 +62,31 @@ void packet_write(int fd, const char *fmt, ...)
buffer[1] = hex(n >> 8);
buffer[2] = hex(n >> 4);
buffer[3] = hex(n);
+ return n;
+}
+
+void packet_write(int fd, const char *fmt, ...)
+{
+ va_list args;
+ unsigned n;
+
+ va_start(args, fmt);
+ n = format_packet(fmt, args);
+ va_end(args);
safe_write(fd, buffer, n);
}
+void packet_buf_write(struct strbuf *buf, const char *fmt, ...)
+{
+ va_list args;
+ unsigned n;
+
+ va_start(args, fmt);
+ n = format_packet(fmt, args);
+ va_end(args);
+ strbuf_add(buf, buffer, n);
+}
+
static void safe_read(int fd, void *buffer, unsigned size)
{
ssize_t ret = read_in_full(fd, buffer, size);
@@ -72,15 +96,11 @@ static void safe_read(int fd, void *buffer, unsigned size)
die("The remote end hung up unexpectedly");
}
-int packet_read_line(int fd, char *buffer, unsigned size)
+static int packet_length(unsigned *ret_len, const char *linelen)
{
int n;
- unsigned len;
- char linelen[4];
-
- safe_read(fd, linelen, 4);
+ unsigned len = 0;
- len = 0;
for (n = 0; n < 4; n++) {
unsigned char c = linelen[n];
len <<= 4;
@@ -96,8 +116,20 @@ int packet_read_line(int fd, char *buffer, unsigned size)
len += c - 'A' + 10;
continue;
}
- die("protocol error: bad line length character");
+ return -1;
}
+ *ret_len = len;
+ return 0;
+}
+
+int packet_read_line(int fd, char *buffer, unsigned size)
+{
+ unsigned len;
+ char linelen[4];
+
+ safe_read(fd, linelen, 4);
+ if (packet_length(&len, linelen))
+ die("protocol error: bad line length character");
if (!len)
return 0;
len -= 4;
@@ -107,3 +139,28 @@ int packet_read_line(int fd, char *buffer, unsigned size)
buffer[len] = 0;
return len;
}
+
+int packet_get_line(struct strbuf *out,
+ char **src_buf, size_t *src_len)
+{
+ unsigned len;
+
+ if (*src_len < 4 || packet_length(&len, *src_buf))
+ return -1;
+ if (!len) {
+ *src_buf += 4;
+ *src_len -= 4;
+ return 0;
+ }
+ if (*src_len < len)
+ return -2;
+
+ *src_buf += 4;
+ *src_len -= 4;
+ len -= 4;
+
+ strbuf_add(out, *src_buf, len);
+ *src_buf += len;
+ *src_len -= len;
+ return len;
+}
diff --git a/pkt-line.h b/pkt-line.h
index 9df653f..1e5dcfe 100644
--- a/pkt-line.h
+++ b/pkt-line.h
@@ -2,14 +2,18 @@
#define PKTLINE_H
#include "git-compat-util.h"
+#include "strbuf.h"
/*
* Silly packetized line writing interface
*/
void packet_flush(int fd);
void packet_write(int fd, const char *fmt, ...) __attribute__((format (printf, 2, 3)));
+void packet_buf_flush(struct strbuf *buf);
+void packet_buf_write(struct strbuf *buf, const char *fmt, ...) __attribute__((format (printf, 2, 3)));
int packet_read_line(int fd, char *buffer, unsigned size);
+int packet_get_line(struct strbuf *out, char **src_buf, size_t *src_len);
ssize_t safe_write(int, const void *, ssize_t);
#endif
--
1.6.5.52.g0ff2e
^ permalink raw reply related
* [RFC PATCH v2 04/16] Move "get_ack()" back to fetch-pack
From: Shawn O. Pearce @ 2009-10-13 2:25 UTC (permalink / raw)
To: git
In-Reply-To: <1255400715-10508-1-git-send-email-spearce@spearce.org>
In 41cb7488 Linus moved this function to connect.c for reuse inside
of the git-clone-pack command. That was 2005, but in 2006 Junio
retired git-clone-pack in commit efc7fa53. Since then the only
caller has been fetch-pack. Since this ACK/NAK exchange is only
used by the fetch-pack/upload-pack protocol we should keep move
it back to a private detail of fetch-pack.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-fetch-pack.c | 21 +++++++++++++++++++++
cache.h | 1 -
connect.c | 21 ---------------------
3 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/builtin-fetch-pack.c b/builtin-fetch-pack.c
index 783c2b0..7c09d46 100644
--- a/builtin-fetch-pack.c
+++ b/builtin-fetch-pack.c
@@ -157,6 +157,27 @@ static const unsigned char *get_rev(void)
return commit->object.sha1;
}
+static int get_ack(int fd, unsigned char *result_sha1)
+{
+ static char line[1000];
+ int len = packet_read_line(fd, line, sizeof(line));
+
+ if (!len)
+ die("git fetch-pack: expected ACK/NAK, got EOF");
+ if (line[len-1] == '\n')
+ line[--len] = 0;
+ if (!strcmp(line, "NAK"))
+ return 0;
+ if (!prefixcmp(line, "ACK ")) {
+ if (!get_sha1_hex(line+4, result_sha1)) {
+ if (strstr(line+45, "continue"))
+ return 2;
+ return 1;
+ }
+ }
+ die("git fetch_pack: expected ACK/NAK, got '%s'", line);
+}
+
static int find_common(int fd[2], unsigned char *result_sha1,
struct ref *refs)
{
diff --git a/cache.h b/cache.h
index a5eeead..4e283be 100644
--- a/cache.h
+++ b/cache.h
@@ -856,7 +856,6 @@ extern struct ref *find_ref_by_name(const struct ref *list, const char *name);
extern struct child_process *git_connect(int fd[2], const char *url, const char *prog, int flags);
extern int finish_connect(struct child_process *conn);
extern int path_match(const char *path, int nr, char **match);
-extern int get_ack(int fd, unsigned char *result_sha1);
struct extra_have_objects {
int nr, alloc;
unsigned char (*array)[20];
diff --git a/connect.c b/connect.c
index 7945e38..839a103 100644
--- a/connect.c
+++ b/connect.c
@@ -107,27 +107,6 @@ int server_supports(const char *feature)
strstr(server_capabilities, feature) != NULL;
}
-int get_ack(int fd, unsigned char *result_sha1)
-{
- static char line[1000];
- int len = packet_read_line(fd, line, sizeof(line));
-
- if (!len)
- die("git fetch-pack: expected ACK/NAK, got EOF");
- if (line[len-1] == '\n')
- line[--len] = 0;
- if (!strcmp(line, "NAK"))
- return 0;
- if (!prefixcmp(line, "ACK ")) {
- if (!get_sha1_hex(line+4, result_sha1)) {
- if (strstr(line+45, "continue"))
- return 2;
- return 1;
- }
- }
- die("git fetch_pack: expected ACK/NAK, got '%s'", line);
-}
-
int path_match(const char *path, int nr, char **match)
{
int i;
--
1.6.5.52.g0ff2e
^ 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