* Re: Benchmarks regarding git's gc
From: Nguyen Thai Ngoc Duy @ 2011-11-08 14:37 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s3E-YCMQQzJAU2wjjD-adpNy6bGb-=iUQ=p=bFTWxm+Ng@mail.gmail.com>
On Tue, Nov 8, 2011 at 6:34 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Has anybody seen these?
> http://draketo.de/proj/hg-vs-git-server/test-results.html#results
>
> Seems like a potential area of improvement.
The proportion between time and commits may have something to do with
reachability test, where we traverse all commits and trees (I think
twice in git-gc, one when it runs "reflog expire" and one "prune").
packv4 is supposed to make tree traversing faster. Although it'd be
best if we could avoid this test.
--
Duy
^ permalink raw reply
* git log --quiet bug?
From: Prasad Deshpande @ 2011-11-08 14:36 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I am new to the list so please let me know if I need to take this question somewhere else.
I am seeing a bug with git log --quiet. It doesn't seem to be quiet :-). Also I have seen cases where the exit status returned is not correct i.e. its 0 even if there is some output (although I cant seem to reproduce that problem at present).
--------------------------------------------------
[~/Work/ws/tools-common] git --version
git version 1.7.0.4
$ git log origin..HEAD
commit 632ff3eed4004ad76b7cd253643c66ce0f9223f1
Author: XXX
Date: Tue Nov 8 09:30:31 2011 -0500
test
$ git log origin..HEAD --quiet
commit 632ff3eed4004ad76b7cd253643c66ce0f9223f1
Author: XXX
Date: Tue Nov 8 09:30:31 2011 -0500
test
[~/Work/ws/tools-common] echo $?
1
--------------------------------------------------
thanks
-prasad
^ permalink raw reply
* Re: Checkout first version of each file?
From: Dario Rodriguez @ 2011-11-08 14:17 UTC (permalink / raw)
To: Fredrik Gustafsson; +Cc: Git Mailing List
In-Reply-To: <20111108140243.GA4866@kolya>
On Tue, Nov 8, 2011 at 11:02 AM, Fredrik Gustafsson <iveqy@iveqy.com> wrote:
> On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
>> Hello,
>>
>> My "issue" comes with my usage of git at work. I work with lots of
>> applications, each of them part of each system. There are lots of
>> processes and lots of subsystems, so I never clone the entire repo
>> into GIT, since it could be painful and slow. Even if I do so,
>> everyone else is using ClearCase, and their changes cannot be included
>> into my git repo until they "chickin". Sometimes, I must update
>> sources from FTP because the changes are not up to date in
>> ClearCase...
>>
>> So, I clone every file that I will need to work into GIT, so i can
>> work with these files having a better control (With ClearCase it's a
>> foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
>> don't know how many files I am going to change until I start coding
>> the requisites.
>>
>> In this cases, there is a situation that I don't know how to handle.
>> If I need to rollback every change made to every file I cannot just
>> checkout the initial commit, cause I've added files after that, and I
>> need their initial versions too.
>>
>> So, how can I checkout the first version of each file? (I know that
>> GIT tracks contents and not files, but the fact is that I need to keep
>> track on files, it's the real thing I work with)
>>
>> pd: Sorry about my Argentinian-English (if it sounds so)
>>
>> Thanks,
>> Dario
>> --
>> 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
>
> Is all files present in your latest commit? Or can there be deleted
> files that you also need to recover?
>
> --
> Med vänliga hälsningar
> Fredrik Gustafsson
>
> E-post: iveqy@iveqy.com
> Tel. nr.: 0733 60 82 74
>
Every file in the latest working tree is also a tracked file. The
files are being added to the git repo, but not removed from it.
In other words, the biggest set of files is the latest working tree,
and the smallest one is the first commit.
Dario
^ permalink raw reply
* Re: Checkout first version of each file?
From: Fredrik Gustafsson @ 2011-11-08 14:02 UTC (permalink / raw)
To: Dario Rodriguez; +Cc: Git Mailing List
In-Reply-To: <CABLeVKF5P_sWwNX+OR_FX4+SPCN+SovZ2QuMmGGvJ-EskK7=YQ@mail.gmail.com>
On Tue, Nov 08, 2011 at 10:58:05AM -0300, Dario Rodriguez wrote:
> Hello,
>
> My "issue" comes with my usage of git at work. I work with lots of
> applications, each of them part of each system. There are lots of
> processes and lots of subsystems, so I never clone the entire repo
> into GIT, since it could be painful and slow. Even if I do so,
> everyone else is using ClearCase, and their changes cannot be included
> into my git repo until they "chickin". Sometimes, I must update
> sources from FTP because the changes are not up to date in
> ClearCase...
>
> So, I clone every file that I will need to work into GIT, so i can
> work with these files having a better control (With ClearCase it's a
> foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
> don't know how many files I am going to change until I start coding
> the requisites.
>
> In this cases, there is a situation that I don't know how to handle.
> If I need to rollback every change made to every file I cannot just
> checkout the initial commit, cause I've added files after that, and I
> need their initial versions too.
>
> So, how can I checkout the first version of each file? (I know that
> GIT tracks contents and not files, but the fact is that I need to keep
> track on files, it's the real thing I work with)
>
> pd: Sorry about my Argentinian-English (if it sounds so)
>
> Thanks,
> Dario
> --
> 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
Is all files present in your latest commit? Or can there be deleted
files that you also need to recover?
--
Med vänliga hälsningar
Fredrik Gustafsson
E-post: iveqy@iveqy.com
Tel. nr.: 0733 60 82 74
^ permalink raw reply
* Checkout first version of each file?
From: Dario Rodriguez @ 2011-11-08 13:58 UTC (permalink / raw)
To: Git Mailing List
Hello,
My "issue" comes with my usage of git at work. I work with lots of
applications, each of them part of each system. There are lots of
processes and lots of subsystems, so I never clone the entire repo
into GIT, since it could be painful and slow. Even if I do so,
everyone else is using ClearCase, and their changes cannot be included
into my git repo until they "chickin". Sometimes, I must update
sources from FTP because the changes are not up to date in
ClearCase...
So, I clone every file that I will need to work into GIT, so i can
work with these files having a better control (With ClearCase it's a
foolish "checkout>>lots of changes>>checkin" flow). But sometimes I
don't know how many files I am going to change until I start coding
the requisites.
In this cases, there is a situation that I don't know how to handle.
If I need to rollback every change made to every file I cannot just
checkout the initial commit, cause I've added files after that, and I
need their initial versions too.
So, how can I checkout the first version of each file? (I know that
GIT tracks contents and not files, but the fact is that I need to keep
track on files, it's the real thing I work with)
pd: Sorry about my Argentinian-English (if it sounds so)
Thanks,
Dario
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2011, #02; Sun, 6)
From: Stefan Näwe @ 2011-11-08 12:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org
In-Reply-To: <7vehxl57lt.fsf@alter.siamese.dyndns.org>
Am 06.11.2011 21:17, schrieb Junio C Hamano:
> Here are the topics that have been cooking. Commits prefixed with '-' are
> only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
>
> [...]
>
> With all the topics and integration branches but not todo, html or man:
>
> https://github.com/gitster/git
>
> I will stop pushing the generated documentation branches to the above
> repositories, as they are not sources.
This breaks the 'quick-install-{doc,html,man}' make targets, btw.
> These branches are pushed to their own separate repositories instead:
>
> git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
> git://repo.or.cz/git-{htmldocs,manpages}.git/
> https://code.google.com/p/git-{htmldocs,manpages}.git/
> https://github.com/gitster/git-{htmldocs,manpages}.git/
I had to create remotes for those repositories (named htmldocs and manpages)
and put this into config.mak to make it work again:
HTML_REF=htmldocs/master
DOC_REF=manpages/master
Just FYI...
Stefan
--
----------------------------------------------------------------
/dev/random says: Brain: The apparatus with which we think that we think.
python -c "print '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
^ permalink raw reply
* Benchmarks regarding git's gc
From: Felipe Contreras @ 2011-11-08 11:34 UTC (permalink / raw)
To: git
Has anybody seen these?
http://draketo.de/proj/hg-vs-git-server/test-results.html#results
Seems like a potential area of improvement.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: git-receive-pack missing credentials ?
From: François Dagorn @ 2011-11-08 10:50 UTC (permalink / raw)
To: git
In-Reply-To: <4EB7FA3A.8070908@univ-rennes1.fr>
It was an ExecCGI issue :
when adding "Options ExecCGI" on the
directory hosting git repositories, everything was ok.
François
^ permalink raw reply
* Re: git-receive-pack missing credentials ?
From: François Dagorn @ 2011-11-08 10:17 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20111108T091907-908@post.gmane.org>
François Dagorn <Francois.Dagorn <at> univ-rennes1.fr> writes:
What happens : git-http-backend is not called at all !
ScriptAlias /git/ /usr/local/libexec/git-core/git-httpd-backend/
is not relevant, I don't know why.
François
^ permalink raw reply
* How to resolve git stash conflict without adding to index?
From: Sven Bachmann @ 2011-11-08 9:10 UTC (permalink / raw)
To: git
Hi Git-Group,
from time to time I've got to "git stash" a bunch of files (about 20).
My problem is, sometimes "git stash pop" conflicts and all files are
added to the index - which is not what I want.
I just want to have the same behavior like "git stash pop" without
conflict has. Resolving the conflict is okay, but not "git reset HEAD"
to all other files, which I don't want to commit now.
Is there a possibility that "git stash pop" does not add all files to
the index when a conflict appears?
I've already asked this question on stackoverflow (
http://stackoverflow.com/questions/7751555/how-to-resolve-git-stash-conflict-without-commit ) - maybe this helps a bit better to describe the
problem.
Please add me to CC if possible as I'm not subscribed to this list and
reading it in the browser.
Thanks a lot in advance!
Sven
^ permalink raw reply
* [fyi] patches used by git distributors
From: Jonathan Nieder @ 2011-11-08 9:02 UTC (permalink / raw)
To: git
Hi,
In an ideal world, each patch applied by downstream distributors would
fall into one of two categories: (a) adapting the package to some
esoteric distro-specific requirement (i.e., special-interest patches)
or (b) in the process of being generalized and reviewed for eventual
application upstream, so everyone can benefit from it. Unfortunately
that takes time. I should do better --- sorry about that.
As an experiment, here's a quick summary of the patches being used
in Debian, for people curious about that and for people interested in
grabbing useful patches to polish and not knowing where to start.
(Links point to relevant discussion, not necessarily the patch used):
Frédéric Brière (1):
gitk: Skip over AUTHOR/COMMIT_DATE when searching all fields [1]
Gerrit Pape (1):
bug#506445: hooks/post-receive-email: set encoding to utf-8 [2]
Jonathan Nieder (12):
remove shebang line from shell libraries [3]
pre-rebase hook: capture documentation in a <<here document [4]
gitk: use symbolic font names "sans" and "monospace"
transport: expose git_tcp_connect and friends in new tcp.h [5]
daemon: make host resolution into a separate function [5]
daemon: move locate_host to tcp.c [5]
tcp: unify ipv4 and ipv6 code paths [5]
daemon: check for errors retrieving IP address [5]
tcp: make dns_resolve return an error code [5]
transport: optionally honor DNS SRV records [5]
srv: make errors less quiet [5]
Makefile: add a knob to turn off hardlinks within same directory [6]
The patches listed above are on the candidate+patches branch of [7].
Questions and improvements can go to git@packages.debian.org.
A few other packaging projects:
- git://pkgs.fedoraproject.org/git.git master --- 3 patches (using
SERVER_NAME for home link, reviving vc-git.el, compatibility with
newer cvsps)
- http://www.freebsd.org/cgi/cvsweb.cgi/ports/devel/git/files/ ---
1 patch (capping individual reads and writes at INT_MAX chars)
- https://build.opensuse.org/package/files?package=git&project=devel%3Atools%3Ascm
--- 4 patches (a python build fix, making gitweb::prevent_xss
default to true, turning off hardlinks for builtins at installation
time, protecting COMP_WORDBREAKS from mangling in the completion
script)
- http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-vcs/git/files/
--- 1 patch (a NO_CVS knob for the makefile). Very nice.
- http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/scmgit-base/patches/
--- 3 patches (putting CFLAGS at the end of ALL_CFLAGS so it can
override BASIC_CFLAGS, setting INSTALLDIRS=vendor in perl makefile,
improving tk support on Darwin 8)
- http://www.openbsd.org/cgi-bin/cvsweb/ports/devel/git/patches/ ---
8 patches (updating OpenBSD makefile defaults, using raw perlio in
gitweb blob view, removing "set -e" in t9117, passing --text [well,
-a] to grep in t9200, avoiding nonportable regex \+ in t9400)
- ftp://ftp.cygwin.org/pub/cygwin/release/git/git-1.7.5.1-1-src.tar.bz2
--- 3 patches (tcl 8.4.1 support, updating Cygwin makefile defaults,
case-insensitive path comparison in makefile, special Windows-specific
wish script preamble)
[1] http://thread.gmane.org/gmane.comp.version-control.git/142160
[2] http://thread.gmane.org/gmane.comp.version-control.git/181737
[3] http://bugs.debian.org/368792
[4] http://thread.gmane.org/gmane.comp.version-control.git/150737
[5] http://thread.gmane.org/gmane.comp.version-control.git/175106
[6] http://thread.gmane.org/gmane.comp.version-control.git/183361
[7] http://smarden.org/git/git.git
gitweb: http://repo.or.cz/w/git/debian.org
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Bert Wesarg @ 2011-11-08 8:52 UTC (permalink / raw)
To: Jeff King; +Cc: Ori Avtalion, git
In-Reply-To: <20111107225508.GB28188@sigill.intra.peff.net>
On Mon, Nov 7, 2011 at 23:55, Jeff King <peff@peff.net> wrote:
> In the general case, you can't represent all failed hunks with conflict
> markers, can you? I'm thinking something where we couldn't find any
> relevant context. You know the lines from the original patch from the
> hunk header, so you can drop the failed content from the patch in the
> right spot. But how do you know how big a conflict marker to make for
> the "current" side? The same number of lines as were in the hunk?
> I think you'd end up with confusing conflict markers.
GNU patch can produce conflict markers with the --merge option.
Bert
>
> -Peff
^ permalink raw reply
* Re: git-receive-pack missing credentials ?
From: François Dagorn @ 2011-11-08 8:26 UTC (permalink / raw)
To: git
In-Reply-To: <CALUzUxpiOoY3Qy0oXzgioBGkZyBF_vpHV3OHm-DWfChR9pPHHA@mail.gmail.com>
Tay Ray Chuan <rctay89 <at> gmail.com> writes:
>
> On Mon, Nov 7, 2011 at 11:33 PM, François Dagorn
>
> Can you update your git installation and try again? v1.7.3.4 sounds
> pretty old (almost a year).
>
On the server side I'm using the last 1.7.7.2 and 1.7.3.4 is on
the client side used for testing.
When apache is configured to serve without authentication, everything
is ok !
PS: I don't know where to report but there are mistakes (IMHO) in the
git-http-backend man page : the LocationMatch directive cannot be used
to restrict access to "receive-pack" because "receive-pack" does not
take part of the URL but only in the QUERY_STRING.
GET /test13/info/refs?service=git-receive-pack
****
Cheers.
François
^ permalink raw reply
* Re: how to merge sub directory or file?
From: Emily Ren @ 2011-11-08 7:08 UTC (permalink / raw)
To: Konstantin Khomoutov; +Cc: git
In-Reply-To: <20111107193708.6cf2ae81.kostix@domain007.com>
Hi Kon,
Thank you ! I tried that method, it failed on read-tree because
B/dir3 already exists, Cannot bind.
$ git read-tree --prefix=dir3 -u A:dir3
error: Entry 'dir3/file1' overlaps with 'dir3/file1'. Cannot bind.
And my case is that not all A's sub direcotries are in B.
For example, in A's dir3, there are file1, dir4 and dir5. But in B's
dir3, only file1 and dir4 exist, there's no dir5. How to handle this
case ?
Thanks,
Emily
On Mon, Nov 7, 2011 at 11:37 PM, Konstantin Khomoutov
<flatworm@users.sourceforge.net> wrote:
>
> On Mon, 7 Nov 2011 22:54:18 +0800
> Emily <lingyan.ren@gmail.com> wrote:
>
> > I have two git projects A and B, content of B is subset of A. For
> > example, Project A and B's tree are as below:
> [...]
> > When there's new changes in project A, how can I merge them to
> > project B without changing B's directory structure?
> >
> > Your help will be highly appreciated.
> Subtree merging maybe?
> See http://progit.org/book/ch6-7.html
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Junio C Hamano @ 2011-11-08 6:15 UTC (permalink / raw)
To: Jeff King; +Cc: Ori Avtalion, git
In-Reply-To: <20111108054643.GC29643@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But I think there are two questions:
>
> 1. Should am's 3-way fallback be made more easily available to users
> of regular "apply"?
>
> 2. Short of doing a 3-way merge, are there better ways to represent
> failed hunks in the patch target itself, rather than saving ".rej"
> files?
>
> I'm actually not sure which one Ori was asking about.
Me neither, but if I have to guess it would be the former. If there were a
solution better than ".rej" in 2-way context, surely "patch" would have
implemented it 10 years before we started ;-).
^ permalink raw reply
* Re: pretty placeholders for reflog entries
From: Jeff King @ 2011-11-08 5:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jack Nagel, git
In-Reply-To: <7v8vnr1oww.fsf@alter.siamese.dyndns.org>
On Mon, Nov 07, 2011 at 03:41:19PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > It would be a little nicer to provide explicit date placeholders, but we
> > can't quite make them match the author-date specifiers, because "gd" is
> > taken. We could add %gt, %gr, etc. But in the long run, I'd like to
> > move to considering most of %ar, %at, etc to be historical, and have
> > something like "%ad(short)" be the official way of picking different
> > date formats[1]. And then the reflog placeholders could learn
> > "%gt(short)". So making more reflog placeholders right now just feels
> > like cluttering a namespace I'd like to get changed eventually.
>
> I tend to agree with the direction.
>
> As we are not adding anything new before the 1.7.8 final, I'd rather ask
> you to hold onto this and other changes in your footnote, instead of
> having me to carry them in 'pu', which is an integration branch even less
> official than it would otherwise be during the freeze period.
Sure. I'll re-send the patch once the release is out. That will also
give Jack and any other interested parties time to comment and test.
-Peff
^ permalink raw reply
* Re: git-apply that handles rejects like merge conflicts
From: Jeff King @ 2011-11-08 5:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ori Avtalion, git
In-Reply-To: <7v4nyf1opf.fsf@alter.siamese.dyndns.org>
On Mon, Nov 07, 2011 at 03:45:48PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > In the general case, you can't represent all failed hunks with conflict
> > markers, can you?
>
> Conflict markers come from the use of a 3-way merge, and if you were to do
> a 3-way merge, by definition, you would need some way to tell where the
> preimage of the patch and the target tree you are attempting to apply the
> patch forked from. That's done by fall-back-3way in "am -3".
>
> You _could_ lift that logic out of "am -3", but I do not think it is worth
> the effort to do so (IOW, I do not see a reason to avoid "am -3").
I think it would purely be "I have a patch produced by git diff, not by
git format-patch". If you want to use "am -3", you would have to dress
up your patch with mail headers.
In practice, this doesn't come up much for me. I think I was using "git
diff >patch" as a poor-man's stash (and I did just stick some fake
headers in, and "git reset HEAD^" afterwards). But maybe other workflows
deal with this more.
But I think there are two questions:
1. Should am's 3-way fallback be made more easily available to users
of regular "apply"?
2. Short of doing a 3-way merge, are there better ways to represent
failed hunks in the patch target itself, rather than saving ".rej"
files?
I'm actually not sure which one Ori was asking about.
-Peff
^ permalink raw reply
* Re: Find the size of git push in pre-receive hook
From: Jeff King @ 2011-11-08 5:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Manigandan S, git
In-Reply-To: <7vboso4hf6.fsf@alter.siamese.dyndns.org>
On Sun, Nov 06, 2011 at 09:42:37PM -0800, Junio C Hamano wrote:
> Manigandan S <etc.mani@gmail.com> writes:
>
> > Let me explain it in detail, if I was not clear.
>
> Do not top-post on this list.
>
> You said you wanted to restrict the size of a push, but what you are
> trying is to restrict the size of a repository after a push. If accepting
> this push will result in your repository go over the quota, the push will
> be denied. Otherwise the push will be accepted.
>
> If that is the case, how much the resulting repository weighs is what you
> are trying to measure, not the size of _this_ push, i.e. the amount of
> additional data this push will introduce, and "du -s" for the repository
> inside pre-receive-hook is the way to do so.
I'm not sure even "du -s" is a good method. That will tell you how big
this push is right _now_, which is at least a maximum. But most commits,
when packed with other commits, will take up a fraction of that space
due to deltas.
So you might receive a 100K thin pack on the network that git will
explode to a 5 megabyte full pack on disk. Next time you repack, it will
only increase the size of your existing packed data by 100K or so.
If receive-pack actually measured the incoming pack bytes in the thin
pack, that would probably be a more accurate guess (but again, it's
still just a guess).
-Peff
^ permalink raw reply
* Re: [PATCH] prune: show progress while marking reachable objects
From: Junio C Hamano @ 2011-11-08 5:40 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20111108053149.GA29643@sigill.intra.peff.net>
Both patches look sensible from a quick glance.
^ permalink raw reply
* Re: [PATCH v2 00/12] Pulling signed/annotated tags
From: Junio C Hamano @ 2011-11-08 5:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <CA+55aFyEuuT25m00uakL66YKSpT-zjoiBreymFSbuHmtARq6yw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> But I don't have any really strong opinions on it. I just think it's a
> good idea to make it easy to parse both mechanically and
> human-visually, and "number of lines" doesn't strike me as being very
> human-friendly.
Here is what I had in mind. An empty line in the tag payload would become
"mergetag \n" and a separate would become "mergetag\n". The consumer of
"cat-file commit" would be able to tell between the two anyway and if a
human _really_ cares, s/he can pipe it to "cat -e" or something.
Honestly, I do not care too much about human readability of "mergetag"
header. We could even store zlib-deflate-and-then-base85 the payload,
which _might_ be a better solution. For one thing, it would protect us
from potential NUL in the tag payload ;-).
commit.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/commit.c b/commit.c
index 7d471a3..6a5d40e 100644
--- a/commit.c
+++ b/commit.c
@@ -868,6 +868,8 @@ static void handle_signed_tag(struct strbuf *signed_tags, struct commit *parent)
* if (verify_signed_buffer(buf, len, buf + len, size - len, &sig))
* warn("warning: signed tag unverified.");
*/
+ if (signed_tags->len)
+ strbuf_addstr(signed_tags, "mergetag\n");
strbuf_add_lines(signed_tags, "mergetag ", buf, size);
free_return:
^ permalink raw reply related
* [PATCH 2/2] reachable: per-object progress
From: Jeff King @ 2011-11-08 5:37 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <20111108053149.GA29643@sigill.intra.peff.net>
The current progress code really just counts commits.
This patch makes it count all objects, giving us a "total"
count close to what a repack would show. This is nice when
using "git gc", which will usually have just repacked the
whole repo.
Signed-off-by: Jeff King <peff@peff.net>
---
This makes the change a lot more invasive, but it is at least confined
to reachable.c. I think matching repack's numbers is worth it. I did a
few basic measurements, and with "& 1023" trick and reasonable
optimizations, it doesn't seem to make prune any slower.
Again, I'd be OK if this is squashed into your original patch.
reachable.c | 51 +++++++++++++++++++++++++++++++++++++--------------
1 files changed, 37 insertions(+), 14 deletions(-)
diff --git a/reachable.c b/reachable.c
index 293d37d..bf79706 100644
--- a/reachable.c
+++ b/reachable.c
@@ -9,10 +9,23 @@
#include "cache-tree.h"
#include "progress.h"
+struct connectivity_progress {
+ struct progress *progress;
+ unsigned long count;
+};
+
+static void update_progress(struct connectivity_progress *cp)
+{
+ cp->count++;
+ if ((cp->count & 1023) == 0)
+ display_progress(cp->progress, cp->count);
+}
+
static void process_blob(struct blob *blob,
struct object_array *p,
struct name_path *path,
- const char *name)
+ const char *name,
+ struct connectivity_progress *cp)
{
struct object *obj = &blob->object;
@@ -21,6 +34,7 @@ static void process_blob(struct blob *blob,
if (obj->flags & SEEN)
return;
obj->flags |= SEEN;
+ update_progress(cp);
/* Nothing to do, really .. The blob lookup was the important part */
}
@@ -35,7 +49,8 @@ static void process_gitlink(const unsigned char *sha1,
static void process_tree(struct tree *tree,
struct object_array *p,
struct name_path *path,
- const char *name)
+ const char *name,
+ struct connectivity_progress *cp)
{
struct object *obj = &tree->object;
struct tree_desc desc;
@@ -47,6 +62,7 @@ static void process_tree(struct tree *tree,
if (obj->flags & SEEN)
return;
obj->flags |= SEEN;
+ update_progress(cp);
if (parse_tree(tree) < 0)
die("bad tree object %s", sha1_to_hex(obj->sha1));
add_object(obj, p, path, name);
@@ -58,23 +74,25 @@ static void process_tree(struct tree *tree,
while (tree_entry(&desc, &entry)) {
if (S_ISDIR(entry.mode))
- process_tree(lookup_tree(entry.sha1), p, &me, entry.path);
+ process_tree(lookup_tree(entry.sha1), p, &me, entry.path, cp);
else if (S_ISGITLINK(entry.mode))
process_gitlink(entry.sha1, p, &me, entry.path);
else
- process_blob(lookup_blob(entry.sha1), p, &me, entry.path);
+ process_blob(lookup_blob(entry.sha1), p, &me, entry.path, cp);
}
free(tree->buffer);
tree->buffer = NULL;
}
-static void process_tag(struct tag *tag, struct object_array *p, const char *name)
+static void process_tag(struct tag *tag, struct object_array *p,
+ const char *name, struct connectivity_progress *cp)
{
struct object *obj = &tag->object;
if (obj->flags & SEEN)
return;
obj->flags |= SEEN;
+ update_progress(cp);
if (parse_tag(tag) < 0)
die("bad tag object %s", sha1_to_hex(obj->sha1));
@@ -82,17 +100,17 @@ static void process_tag(struct tag *tag, struct object_array *p, const char *nam
add_object(tag->tagged, p, NULL, name);
}
-static void walk_commit_list(struct rev_info *revs, struct progress *progress)
+static void walk_commit_list(struct rev_info *revs,
+ struct connectivity_progress *cp)
{
int i;
struct commit *commit;
struct object_array objects = OBJECT_ARRAY_INIT;
- uint32_t count = 0;
/* Walk all commits, process their trees */
while ((commit = get_revision(revs)) != NULL) {
- process_tree(commit->tree, &objects, NULL, "");
- display_progress(progress, ++count);
+ process_tree(commit->tree, &objects, NULL, "", cp);
+ update_progress(cp);
}
/* Then walk all the pending objects, recursively processing them too */
@@ -100,17 +118,16 @@ static void walk_commit_list(struct rev_info *revs, struct progress *progress)
struct object_array_entry *pending = revs->pending.objects + i;
struct object *obj = pending->item;
const char *name = pending->name;
- display_progress(progress, ++count);
if (obj->type == OBJ_TAG) {
- process_tag((struct tag *) obj, &objects, name);
+ process_tag((struct tag *) obj, &objects, name, cp);
continue;
}
if (obj->type == OBJ_TREE) {
- process_tree((struct tree *)obj, &objects, NULL, name);
+ process_tree((struct tree *)obj, &objects, NULL, name, cp);
continue;
}
if (obj->type == OBJ_BLOB) {
- process_blob((struct blob *)obj, &objects, NULL, name);
+ process_blob((struct blob *)obj, &objects, NULL, name, cp);
continue;
}
die("unknown pending object %s (%s)", sha1_to_hex(obj->sha1), name);
@@ -199,6 +216,8 @@ static void add_cache_refs(struct rev_info *revs)
void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
struct progress *progress)
{
+ struct connectivity_progress cp;
+
/*
* Set up revision parsing, and mark us as being interested
* in all object types, not just commits.
@@ -217,11 +236,15 @@ void mark_reachable_objects(struct rev_info *revs, int mark_reflog,
if (mark_reflog)
for_each_reflog(add_one_reflog, revs);
+ cp.progress = progress;
+ cp.count = 0;
+
/*
* Set up the revision walk - this will move all commits
* from the pending list to the commit walking list.
*/
if (prepare_revision_walk(revs))
die("revision walk setup failed");
- walk_commit_list(revs, progress);
+ walk_commit_list(revs, &cp);
+ display_progress(cp.progress, cp.count);
}
--
1.7.7.2.7.g9f96f.dirty
^ permalink raw reply related
* [PATCH 1/2] prune: handle --progress/no-progress
From: Jeff King @ 2011-11-08 5:34 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <20111108053149.GA29643@sigill.intra.peff.net>
And have "git gc" pass no-progress when quiet.
Signed-off-by: Jeff King <peff@peff.net>
---
On top of the prune progress patch you sent earlier.
I did these as separate patches so you could see each change, but I'd
also be fine if they are just squashed into your patch.
builtin/gc.c | 4 +++-
builtin/prune.c | 11 +++++++++--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/builtin/gc.c b/builtin/gc.c
index 0498094..271376d 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -32,7 +32,7 @@
static const char *argv_pack_refs[] = {"pack-refs", "--all", "--prune", NULL};
static const char *argv_reflog[] = {"reflog", "expire", "--all", NULL};
static const char *argv_repack[MAX_ADD] = {"repack", "-d", "-l", NULL};
-static const char *argv_prune[] = {"prune", "--expire", NULL, NULL};
+static const char *argv_prune[] = {"prune", "--expire", NULL, NULL, NULL};
static const char *argv_rerere[] = {"rerere", "gc", NULL};
static int gc_config(const char *var, const char *value, void *cb)
@@ -243,6 +243,8 @@ int cmd_gc(int argc, const char **argv, const char *prefix)
if (prune_expire) {
argv_prune[2] = prune_expire;
+ if (quiet)
+ argv_prune[3] = "--no-progress";
if (run_command_v_opt(argv_prune, RUN_GIT_CMD))
return error(FAILED_RUN, argv_prune[0]);
}
diff --git a/builtin/prune.c b/builtin/prune.c
index 6b39d3f..58d7cb8 100644
--- a/builtin/prune.c
+++ b/builtin/prune.c
@@ -15,6 +15,7 @@
static int show_only;
static int verbose;
static unsigned long expire;
+static int show_progress = -1;
static int prune_tmp_object(const char *path, const char *filename)
{
@@ -125,10 +126,11 @@ static void remove_temporary_files(const char *path)
int cmd_prune(int argc, const char **argv, const char *prefix)
{
struct rev_info revs;
- struct progress *progress;
+ struct progress *progress = NULL;
const struct option options[] = {
OPT__DRY_RUN(&show_only, "do not remove, show only"),
OPT__VERBOSE(&verbose, "report pruned objects"),
+ OPT_BOOL(0, "progress", &show_progress, "show progress"),
OPT_DATE(0, "expire", &expire,
"expire objects older than <time>"),
OPT_END()
@@ -154,7 +156,12 @@ int cmd_prune(int argc, const char **argv, const char *prefix)
else
die("unrecognized argument: %s", name);
}
- progress = start_progress_delay("Checking connectivity", 0, 0, 2);
+
+ if (show_progress == -1)
+ show_progress = isatty(2);
+ if (show_progress)
+ progress = start_progress_delay("Checking connectivity", 0, 0, 2);
+
mark_reachable_objects(&revs, 1, progress);
stop_progress(&progress);
prune_object_dir(get_object_directory());
--
1.7.7.2.7.g9f96f.dirty
^ permalink raw reply related
* Re: [PATCH] prune: show progress while marking reachable objects
From: Jeff King @ 2011-11-08 5:31 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1320494408-6373-1-git-send-email-pclouds@gmail.com>
On Sat, Nov 05, 2011 at 07:00:08PM +0700, Nguyen Thai Ngoc Duy wrote:
> prune already shows progress meter while pruning. The marking part may
> take a few seconds or more, depending on repository size. Show
> progress meter during this time too.
Thanks, this is a nice start. It's missing a few things IMHO:
1. It actually counts commits, not all objects. I'm tempted to say
this doesn't matter, as any eye candy is helpful. Except that the
most common use of prune is as part of "git gc", in which case
pack-objects will have just done the "counting objects" phase and
come up with some number. If we count all objects, then our end
number is the same (modulo any .keep packs, but at least it's
probably in the same order of magnitude). That gives the user a
better sense of completion time.
2. Prune should learn --progress/--no-progress, isatty(2), etc. And
git-gc should pass --no-progress when it's told to be quiet.
Patches for both in a moment.
-Peff
^ permalink raw reply
* Re: [PATCH v2 00/12] Pulling signed/annotated tags
From: Linus Torvalds @ 2011-11-08 5:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsjlzyza7.fsf@alter.siamese.dyndns.org>
On Mon, Nov 7, 2011 at 9:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Eek.
>
> The mergetag stuff is a dump of "cat-file tag" so if you have a line that
> begins with "object " the parsing side (which does not exist yet) would
> have trouble. We would need to devise e.g. adding number of lines at the
> beginning, or something.
Might I suggest making it simpler still to parse?
Change "strbuf_add_lines()" to have two *different* prefixes: one for
the first line, and one for "continuation lines".
Then you can just use the same prefix if you want to - and get the
semantics you have now for that helper.
But instead of just having "mergetag" as the prefix for all the lines
copied from the merge, wouldn't it be nice and easy to have "mergetag"
as the prefix for the *first* line of each copied tag, but then have
some other tag for lines 2..n?
I think that would be *way* easier to parse, and I think something
like that could be a good generic model for any multi-line thing -
have the first line tagged, and the rest have just the continuation
marker. You don't really need to repeat the tag over and over again
each line, it just causes ambiguoity as shown by this example.
But I don't have any really strong opinions on it. I just think it's a
good idea to make it easy to parse both mechanically and
human-visually, and "number of lines" doesn't strike me as being very
human-friendly.
Linus
^ permalink raw reply
* Re: [PATCH v2 00/12] Pulling signed/annotated tags
From: Junio C Hamano @ 2011-11-08 5:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <CA+55aFxVsgNjGv2zAGR1VK34uG59+euJec_3i9JNyQ0VUdjyeA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Nov 7, 2011 at 7:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> This is a re-roll of the fourth iteration.
>
> Ok, this all looks fine to me.
>
> Clean series, and everything looks fine.
>
> The one thing I wondered about is what happens when you merge two
> signed tags. Maybe I read the patch wrong, but it *looks* to me like
> the code just appends them all together with nothing in between. Is it
> still parseable?
Eek.
The mergetag stuff is a dump of "cat-file tag" so if you have a line that
begins with "object " the parsing side (which does not exist yet) would
have trouble. We would need to devise e.g. adding number of lines at the
beginning, or something.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox