* Efficient retrieval of commit log info
From: Eirik Bjørsnøs @ 2007-12-12 14:36 UTC (permalink / raw)
To: git
Hi,
I'm developing a piece of software that grabs logs from various types
of SCMs and presents (hopefully) useful information about the history.
My current approach with Git is do a "git clone --n" and then parse
the output of "git log". To check for updates I do a "git pull"
followed by a new "git log".
This approach works fine, but cloning the whole repository just to get
the change log seems like a somewhat inefficient use of bandwidth and
storage.
What I would like to do is to fetch just the change log information
from the remote repository.
(Using the "CVS done right" tool I can do this with: "svn log --xml -v
-r<last, HEAD> http://svn.example.com/")
I haven't found a way to do this using the Git command line tools.
Is it at all possible using the git network protocols to fetch just
the commit log info, without transferring the contents?
I'd be happy to hear from anyone who has some insight into this.
Thanks,
Eirik.
^ permalink raw reply
* Re: [PATCH] clone: support cloning full bundles
From: Johannes Schindelin @ 2007-12-12 14:50 UTC (permalink / raw)
To: Santi Béjar; +Cc: Git Mailing List
In-Reply-To: <1197456485-22909-1-git-send-email-sbejar@gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 265 bytes --]
Hi,
On Wed, 12 Dec 2007, Santi Béjar wrote:
> It still fails for incremental bundles.
Of course it does. The whole point of incremental bundles is that they do
_not_ contain all objects, but rely on some objects being present on the
"fetch" side.
Hth,
Dscho
^ permalink raw reply
* Re: Efficient retrieval of commit log info
From: Johannes Schindelin @ 2007-12-12 14:55 UTC (permalink / raw)
To: Eirik Bjørsnøs; +Cc: git
In-Reply-To: <34660cca0712120636w149e2a82h84609f8ac7c958a9@mail.gmail.com>
Hi,
On Wed, 12 Dec 2007, Eirik Bj?rsn?s wrote:
> I'm developing a piece of software that grabs logs from various types of
> SCMs and presents (hopefully) useful information about the history.
>
> My current approach with Git is do a "git clone --n" and then parse the
> output of "git log". To check for updates I do a "git pull" followed by
> a new "git log".
>
> This approach works fine, but cloning the whole repository just to get
> the change log seems like a somewhat inefficient use of bandwidth and
> storage.
>
> What I would like to do is to fetch just the change log information
> from the remote repository.
>
> (Using the "CVS done right" tool I can do this with: "svn log --xml -v
> -r<last, HEAD> http://svn.example.com/")
>
> I haven't found a way to do this using the Git command line tools.
It is not possible to get just the metadata. Remember, svn can do it only
since the repository is purely remote. And git is a SCM (source code
management system), not a CMV (commit metadata viewer).
You might be able to cobble up something that works accessing gitweb, but
it might be even more inefficient.
Ciao,
Dscho
^ permalink raw reply
* Re: Invalid dates in git log
From: Johannes Schindelin @ 2007-12-12 14:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Eirik Bjørsnøs, git
In-Reply-To: <7vejds8ddf.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 12 Dec 2007, Junio C Hamano wrote:
> Author: Len Brown <len.brown@intel.com>
> AuthorDate: Fri Apr 5 00:07:45 2019 -0500
> Commit: Len Brown <len.brown@intel.com>
> CommitDate: Tue Jul 12 00:12:09 2005 -0400
>
> author Len Brown <len.brown@intel.com> 1554440865 -0500
> committer Len Brown <len.brown@intel.com> 1121141529 -0400
>
> [...] It looks like quite a random timestamp, and committer timestamp
> look reasonable, relative to the other commits around it.
It is quite possible that Len Brown had a similar problem to what I
experienced yesterday: my clock was set one hour and 22 years into the
future, but I have no idea how that happened. My only guess is a
half-succeeded ntpdate call, but somehow I doubt that.
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] ugit: a pyqt-based git gui // was: Re: If you would write git from scratch now, what would you change?
From: Jason Sewall @ 2007-12-12 15:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David, Marco Costalba, Andy Parkins, git
In-Reply-To: <20071212052329.GR14735@spearce.org>
On Dec 12, 2007 12:23 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > I use git-gui and gitk for my git graphical needs because they rock
> > and at the end of the day, the fonts and antialiasing aren't that big
> > of a deal, especially since I'm usually doing quick scans and searches
> > over the information those tools display, not reading novels in them.
>
> Good points. Features win over pretty most of the time. But at
> some point pretty is important; especially to new user adoption.
> Plus if you are looking at it all day long it shouldn't be jarring
> to the eyes. But git-gui still isn't even where I want it ot
> be feature-wise. E.g. I'd *love* to teach it inotify support,
> so you don't even need to have that Rescan button.
On that note, did you see what I wrote above, about having "split
hunk" functionality? That would be killer. I know, I know, I should
write a patch... well, I've got a paper deadline coming up, and the
time it takes me to run git add -i over some clicks in git-gui plus
the time to figure out how to add that feature doesn't balance...
Jason
^ permalink raw reply
* Re: Efficient retrieval of commit log info
From: Nicolas Pitre @ 2007-12-12 15:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eirik Bjørsnøs, git
In-Reply-To: <Pine.LNX.4.64.0712121453150.27959@racer.site>
On Wed, 12 Dec 2007, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 12 Dec 2007, Eirik Bj?rsn?s wrote:
>
> > I'm developing a piece of software that grabs logs from various types of
> > SCMs and presents (hopefully) useful information about the history.
> >
> > My current approach with Git is do a "git clone --n" and then parse the
> > output of "git log". To check for updates I do a "git pull" followed by
> > a new "git log".
> >
> > This approach works fine, but cloning the whole repository just to get
> > the change log seems like a somewhat inefficient use of bandwidth and
> > storage.
> >
> > What I would like to do is to fetch just the change log information
> > from the remote repository.
> >
> > (Using the "CVS done right" tool I can do this with: "svn log --xml -v
> > -r<last, HEAD> http://svn.example.com/")
> >
> > I haven't found a way to do this using the Git command line tools.
>
> It is not possible to get just the metadata. Remember, svn can do it only
> since the repository is purely remote. And git is a SCM (source code
> management system), not a CMV (commit metadata viewer).
>
> You might be able to cobble up something that works accessing gitweb, but
> it might be even more inefficient.
On the other hand, this is pretty trivial to extend the protocol so only
commit objects are transferred. Using 'git log' on the client side
would work, as long as you don't use any of the content walking options.
Nicolas
^ permalink raw reply
* Re: [PATCH] builtin-clone: Implement git clone as a builtin command.
From: Kristian Høgsberg @ 2007-12-12 15:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Daniel Barkalow, git
In-Reply-To: <Pine.LNX.4.64.0712121103510.27959@racer.site>
On Wed, 2007-12-12 at 11:12 +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 11 Dec 2007, Junio C Hamano wrote:
...
> > * --shared optimization
> >
> > This is a very easy addition to "git remote add". You make sure that
> > the added remote repository is on a local machine, and set up
> > alternates to point at its object store.
>
> Concur.
>
> Since I want to lose that dependency on cpio on Windows (which we fake by
> using tar), I'll implement this in C anyway.
It's not used for --shared (which is just writing an alternates file),
it's used for -l, hardlinking locally cloned repos. The code to replace
cpio is already in the patch I sent, look for clone_local().
cheers,
Kristian
^ permalink raw reply
* Re: [PATCH] Fix typo: we require Python 2.4, not 2.5
From: Jakub Narebski @ 2007-12-12 15:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, Git Mailing List
In-Reply-To: <b0943d9e0712120604m97aac2cyaf60cb33c51cf9a7@mail.gmail.com>
"Catalin Marinas" <catalin.marinas@gmail.com> writes:
> On 11/12/2007, Karl Hasselström <kha@treskal.com> wrote:
> > Yeah. So 0.14.1 (to be released very soon) should probably have this
> > fix. :-)
>
> OK, done. Thanks.
>
> On the RPM side, I found a way to specify the required Python version
> on the "setup.py bdist_rpm" command line but I don't think it makes
> any difference since the installed files will go into the python2.5
> directory.
>
> Anyway, I linked the SRPMS as well from the website's page.
Thanks. At least compiling SRPMS works:
$ stg version
Stacked GIT 0.14.1
git version 1.5.3.7
Python version 2.4.3 (#1, Jun 13 2006, 16:41:18)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)]
$ rpm -q stgit
stgit-0.14.1-1
--
Jakub Narebski http://www.ohloh.net/accounts/11224
ShadeHawk on #git Linux Registered User #239074
^ permalink raw reply
* Re: Efficient retrieval of commit log info
From: Eirik Bjørsnøs @ 2007-12-12 15:19 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.99999.0712121001430.555@xanadu.home>
> On the other hand, this is pretty trivial to extend the protocol so only
> commit objects are transferred. Using 'git log' on the client side
> would work, as long as you don't use any of the content walking options.
Nicolas,
So what you're suggesting is that:
1) git-clone could be changed such that the user could ask not to
fetch content, only commit objects.
2) git-daemon (or the protocol layer, again I'm not familiar with the
implementation) could be changed such that it only sends commit
objects on request.
3) Changes to git-log is not necessary.
Anybody have a clue how much work this would require and if this is
something that would be generally useful for the community?
Eirik.
^ permalink raw reply
* Re: [PATCH] builtin-clone: Implement git clone as a builtin command.
From: Kristian Høgsberg @ 2007-12-12 15:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vejdsbo7d.fsf@gitster.siamese.dyndns.org>
On Tue, 2007-12-11 at 19:12 -0800, Junio C Hamano wrote:
> Kristian Høgsberg <krh@redhat.com> writes:
>
> > On Tue, 2007-12-11 at 15:59 -0500, Daniel Barkalow wrote:
> >> On Tue, 11 Dec 2007, Kristian Høgsberg wrote:
> >>
> >> > Ok, don't flame me, I know this isn't appropriate at the moment with
> >> > stabilization for 1.5.4 going on, but I just wanted to post a heads up
> >> > on this work to avoid duplicate effort. It's one big patch at this point
> >> > and I haven't even run the test suite yet, but that will change.
> >>
> >> Is that why you misspelled Junio's email address? :)
> >
> > Hehe, yeah, do not mess with maintainers in release mode :)
>
> Actually this is a bit unfortunate, regardless of everybody being in
> release and bugfix only mode.
Well, let's just pick up the discussion in January, I have a lot of
other stuff I'm trying to do anyway :)
> I was hoping that the evolution path for clone would be to first make it
> a very thin wrapper around:
>
> git init
> git remote add -f
> git checkout
>
> sequence.
However, let me just say that the patch I sent is almost just that.
Part of the patch refactors init-db to be useful from clone, part of the
code is option parsing and figuring out the git dir, work tree. Also,
the part of the patch that does 'git checkout' is approximately 20 lines
that end up calling unpack_tre() and then write_cache(). The bulk of
the work here is really just builtin boilerplate code, option parsing
and the builtin-clone tasks you describe below (HEAD discovery, --shared
and --reference optimizations and the local hardlink optimization - all
these are in the 500 line builtin-clone.c I sent).
And maybe it makes sense to use builtin-remote for the remote add -f
part, but the fetch part of the patch is 10 lines to set up for
fetch_pack(). So while I do agree that it makes sense to keep remotes
handling in one place, doing the fetch_pack() in builtin-clone.c doesn't
seem like a big duplication of code. And either way, I agree with
Dscho, once we have either builtin-clone or builtin-fetch it's easier to
share code and refactor, and there is not a strong reason to do one or
the other first.
cheers,
Kristian
^ permalink raw reply
* Re: [PATCH] clone: support cloning full bundles
From: Santi Béjar @ 2007-12-12 15:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712121449310.27959@racer.site>
On Dec 12, 2007 3:50 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 12 Dec 2007, Santi Béjar wrote:
>
> > It still fails for incremental bundles.
>
> Of course it does. The whole point of incremental bundles is that they do
> _not_ contain all objects, but rely on some objects being present on the
> "fetch" side.
I know this. But then there is no bundle equivalent of the shallow
clones, as with:
git clone --depth <depth> <repo>
Santi
^ permalink raw reply
* Re: Efficient retrieval of commit log info
From: Santi Béjar @ 2007-12-12 15:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eirik Bjørsnøs, git
In-Reply-To: <Pine.LNX.4.64.0712121453150.27959@racer.site>
On Dec 12, 2007 3:55 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 12 Dec 2007, Eirik Bj?rsn?s wrote:
>
[...]
> > What I would like to do is to fetch just the change log information
> > from the remote repository.
> >
[ ... ]
>
> It is not possible to get just the metadata. Remember, svn can do it only
> since the repository is purely remote. And git is a SCM (source code
> management system), not a CMV (commit metadata viewer).
>
> You might be able to cobble up something that works accessing gitweb, but
> it might be even more inefficient.
You could see how it is done in the git-browser:
http://repo.or.cz/w/git-browser.git
It is a gitk-like browser written in javascript. But I suspect that it
should be enabled in the web server.
Santi
^ permalink raw reply
* Re: Efficient retrieval of commit log info
From: Jon Smirl @ 2007-12-12 15:34 UTC (permalink / raw)
To: Eirik Bjørsnøs; +Cc: git
In-Reply-To: <34660cca0712120719p2d7cda44s97ab770abd648742@mail.gmail.com>
On 12/12/07, Eirik Bjørsnøs <eirbjo@gmail.com> wrote:
> > On the other hand, this is pretty trivial to extend the protocol so only
> > commit objects are transferred. Using 'git log' on the client side
> > would work, as long as you don't use any of the content walking options.
>
> Nicolas,
>
> So what you're suggesting is that:
Write a script the runs the command locally on the remote sever and
emails you the info. Or ssh to the remote server and run the commands
locally.
>
> 1) git-clone could be changed such that the user could ask not to
> fetch content, only commit objects.
> 2) git-daemon (or the protocol layer, again I'm not familiar with the
> implementation) could be changed such that it only sends commit
> objects on request.
> 3) Changes to git-log is not necessary.
>
> Anybody have a clue how much work this would require and if this is
> something that would be generally useful for the community?
>
> Eirik.
> -
> 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
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [(not so) random thoughts] using git as its own caching tool
From: Andreas Ericsson @ 2007-12-12 15:35 UTC (permalink / raw)
To: Pierre Habouzit, Git ML
In-Reply-To: <20071212003813.GG29110@artemis.madism.org>
Pierre Habouzit wrote:
> That's an idea I have for quite some time, and I wonder why it's not
> used in git tools as a general rule.
>
> This idea is simple, git objects database has two (for this
> discussion) very interesting features: its delta compressed cached that
> is _very_ efficient, and the reflog.
>
> I wonder if that would be possible to write some git porcelains (and
> builtin API too) that would be more "map" oriented. I mean, we could use
> a reference as a pointer to a given tree that would be the map (where
> keys have a path form, which is nice). When I say that, I'm thinking
> about git-svn, that even with the recent improvements of its .rev_db's
> still eats a lot of space with the unhandled.log _and_ the indexes it
> stores for _each_ svn branch/tag. This way, instead of many:
> foo/index
> foo/.rev_map.6ef976f9-4de5-0310-a40d-91cae572ec18
> foo/unhandled.log
> we would just have a special refs/db/git-svn/foo reference that would be
> a tree with three blobs in it: index, rev_map.xxxx, unhandled.log. (or
> probably index would even be a tree but that's another matter). This
> way, all the unhandled.log that share a lot of common content would be
> nicely compressed by the delta-compression algorithms, with a negligible
> overhead (git-svn is _very_ slow because of svn anyways, we don't really
> care if it needs to get a blob contents instead opening a flat file).
>
>
> Another nifty usage we could have is memoization databases that don't
> require a specific tool to expire them, but use the reflog expiration
> for that. I remember that we discussed quite some time ago, the idea of
> annotating objects. We could use such annotations to link some objects
> to memoized datas under different namespaces for each caching scheme
> involved, and with one reference per namespace that will have in its
> reflog each of the linked objects created over time for caching. Good
> candidates to use that are the rr-cache, or git-annotate/blame caching.
> Of course that would need to write a tool that removes weak annotations
> that point to objects that don't exist anymore. We could also cache the
> rename/copies/… detection results, and make those really really cheap to
> use[0].
>
>
> I know that some will say something about hammers, problems and nails,
> though it would allow to develop quite efficient tools with a generic
> and easy to use API, that could directly benefit from already existing
> infrastructure in git. I mean it's silly to write yet-another cache
> expirer when you have the reflog. Or to speak about git-svn again, it
> could even version its state per branch the way I propose, it'll end up
> using less disk that what it does now, with the immediate gain that it
> would be fully clone-able[1] (which would be a _really_ nice feature).
>
>
> So am I having crazy thoughts and should I throw my crack-pipe away ?
> Or does parts of this mumbling makes any sense to someone ?
>
A bit of both ;-)
I like the idea to use the git object store, because that certainly
has an API that can't be done away with by user config. The reflog
and its expiration mechanism is subject to human control though, and
everyone doesn't even have them enabled. I don't for some repos where
I know I'll create a thousand-and-one loose objects by rebasing,
--amend'ing and otherwise fiddling with history rewrites.
Having a tool that works on some repos but not on others because it
relies on me living with an auto-gc after pretty much every operation
would be very tiresome indeed.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Something is broken in repack
From: Nicolas Pitre @ 2007-12-12 15:48 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, gcc, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0712112057390.555@xanadu.home>
On Wed, 12 Dec 2007, Nicolas Pitre wrote:
> Add memory fragmentation to that and you have a clogged system.
>
> Solution:
>
> pack.deltacachesize=1
> pack.windowmemory=16M
>
> Limiting the window memory to 16MB will automatically shrink the window
> size when big objects are encountered, therefore keeping much fewer of
> those objects at the same time in memory, which in turn means they will
> be processed much more quickly. And somehow that must help with memory
> fragmentation as well.
OK scrap that.
When I returned to the computer this morning, the repack was
completed... with a 1.3GB pack instead.
So... The gcc repo apparently really needs a large window to efficiently
compress those large objects.
But when those large objects are already well deltified and you repack
again with a large window, somehow the memory allocator is way more
involved, probably even
more so when there are several threads in parallel amplifying the issue,
and things probably get to a point of no return with regard to memory
fragmentation after a while.
So... my conclusion is that the glibc allocator has fragmentation issues
with this work load, given the notable difference with the Google
allocator, which itself might not be completely immune to fragmentation
issues of its own. And because the gcc repo requires a large window of
big objects to get good compression, then you're better not using 4
threads to repack it with -a -f. The fact that the size of the source
pack has such an influence is probably only because the increased usage
of the delta base object cache is playing a role in the global memory
allocation pattern, allowing for the bad fragmentation issue to occur.
If you could run one last test with the mallinfo patch I posted, without
the pack.windowmemory setting, and adding the reported values along with
those from top, then we could formally conclude to memory fragmentation
issues.
So I don't think Git itself is actually bad. The gcc repo most
certainly constitute a nasty use case for memory allocators, but I don't
think there is much we can do about it besides possibly implementing our
own memory allocator with active defragmentation where possible (read
memcpy) at some point to give glibc's allocator some chance to breathe a
bit more.
In the mean time you might have to use only one thread and lots of
memory to repack the gcc repo, or find the perfect memory allocator to
be used with Git. After all, packing the whole gcc history to around
230MB is quite a stunt but it requires sufficient resources to
achieve it. Fortunately, like Linus said, such a wholesale repack is not
something that most users have to do anyway.
Nicolas
^ permalink raw reply
* Re: [(not so) random thoughts] using git as its own caching tool
From: Mike Hommey @ 2007-12-12 15:48 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Pierre Habouzit, Git ML
In-Reply-To: <475FFFB7.4010102@op5.se>
On Wed, Dec 12, 2007 at 04:35:19PM +0100, Andreas Ericsson <ae@op5.se> wrote:
> A bit of both ;-)
>
> I like the idea to use the git object store, because that certainly
> has an API that can't be done away with by user config. The reflog
> and its expiration mechanism is subject to human control though, and
> everyone doesn't even have them enabled. I don't for some repos where
> I know I'll create a thousand-and-one loose objects by rebasing,
> --amend'ing and otherwise fiddling with history rewrites.
>
> Having a tool that works on some repos but not on others because it
> relies on me living with an auto-gc after pretty much every operation
> would be very tiresome indeed.
There is already a tool that relies on reflogs: stash.
Mike
^ permalink raw reply
* Re: Efficient retrieval of commit log info
From: Eirik Bjørsnøs @ 2007-12-12 15:50 UTC (permalink / raw)
To: Jon Smirl; +Cc: git
In-Reply-To: <9e4733910712120734r2618e882w1e6f930c74f3065a@mail.gmail.com>
> Write a script the runs the command locally on the remote sever and
> emails you the info. Or ssh to the remote server and run the commands
> locally.
Hi Jon,
Unfortunately that won't work for my use case since I'm fetching
change metadata from remote repositories that I don't have any kind of
control over.
Eirik.
^ permalink raw reply
* Re: Invalid dates in git log
From: Andreas Ericsson @ 2007-12-12 15:51 UTC (permalink / raw)
To: Eirik Bjørsnøs; +Cc: Jeff King, git
In-Reply-To: <34660cca0712120619r708ee7a8ta20a5458ca11a5ac@mail.gmail.com>
Eirik Bjørsnøs wrote:
>> Your best guess is probably the committer information. Try this:
>
> Thanks Jeff, Junio,
>
> I'll just use the committer date instead.
>
> Being a Git newbie (only started looking at it yesterday) I'm not sure
> my understanding of "author" and "committer" and how they releate to
> dates is correct:
>
They're often the same. They will end up being different if
* you cherry-pick a commit made by someone else.
("someone else" is author, you are the committer)
* you rebase a series of commit containing changes from others
("others" are the authors, you are the committer)
* you apply a patch using "git am" from someone
("someone" is the author, you are the committer)
* you "git commit --amend" a commit from someone else
("someone else" is author, you are the committer)
There are probably other cases, but those were the ones I could
think of right now.
In short, whenever a commit is modified in some way, it gets a
new committer. It might help if you think of author as "contributor"
and "committer" as "integrator", where various integrators merge
between each other. A merge obviously doesn't fiddle with commits,
so once a commit has entered an integrators repository, both author
and committer stays intact (that's not strictly true, but for the
sake of this argument, which concerns the linux kernel, it will
suffice and be mostly correct insofar as I understand the kernel
workflow).
> * author: Original source of the change. This person may typically
> have sent a committer an email with a patch. It's the commiter's
> responsibility to supply this information.
No, it's the author's responsibility to supply this information.
Author is hardly ever changed.
> * author date: The commiter is free to specify a date for the contribution.
>
No, the author does that too :)
> * committer: First committer to actually add this change to a repository
No, committer is the person who added the commit to the repository by
some other means than merging from another repository.
> * committer date: Date of the actual commit, added by the git client
> during the commit. Typically the system clock at the time of the
> commit.
>
Sort of, yes, although commits can be created by other means than
just running "git commit". The operations listed in bullets at the
top of this mail all create new commits, in the sense that they
can't have the same SHA1 as their original ones. Hence, committer
and commitdate must be updated.
> * A transfer of a commit across repositories (pull, push) will not
> change the author, commit or date information
>
True. Since neither ancestry nor content is allowed to change, the
commit will be exactly the same in the new repository as it was in
the old one.
> If I got some of this wrong, I'd be happy if someone would correct me.
>
I think I just did. Perhaps I missed something, but I'm sure someone
will correct me if that's the case.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What to do if git-cvsimport/cvsps hangs?
From: Andreas Ericsson @ 2007-12-12 15:54 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <824peojm4g.fsf@mid.bfk.de>
Florian Weimer wrote:
> This is probably more of a cvsps question than a GIT question, but
> AFAICT, the cvsps upstream is mostly inactive these days.
>
> I tried to import the PostgreSQL repository, using
>
> git-cvsimport -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot -k -C pgsql pgsql
>
> However, after a bit of activity, git-cvsimport hangs at the following
> line
>
> cvs rlog: Logging pgsql/src/win32
>
> strace doesn't show any system call activtiy in the cvsps process
> (which consumes 100% CPU). cvsps is Debian's 2.1-2 version.
>
> Is there some kind of replacement for cvsps which works more reliably?
>
I think "git fast-import" has a CVS frontend. I'm not sure though,
so I leave finding out and trying it as an exercise for you ;-)
It requires file access to the CVS repository, afaiu.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What to do if git-cvsimport/cvsps hangs?
From: Michael Haggerty @ 2007-12-12 15:58 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <824peojm4g.fsf@mid.bfk.de>
Florian Weimer wrote:
> This is probably more of a cvsps question than a GIT question, but
> AFAICT, the cvsps upstream is mostly inactive these days.
>
> I tried to import the PostgreSQL repository, using
>
> git-cvsimport -d :pserver:anoncvs@anoncvs.postgresql.org:/projects/cvsroot -k -C pgsql pgsql
>
> However, after a bit of activity, git-cvsimport hangs at the following
> line [...]
>
> Is there some kind of replacement for cvsps which works more reliably?
Yes, cvs2svn, which can now also output to git. But note: cvs2svn only
supports one-time conversions (not incremental), you need to use the
trunk version of cvs2svn, and using it to convert to git is not yet
documented very well. See the following thread:
http://marc.info/?l=git&m=118592701426175&w=4
Please let us know how it goes!
Michael
^ permalink raw reply
* Re: git-cvsexportcommit fails for huge commits
From: Linus Torvalds @ 2007-12-12 16:02 UTC (permalink / raw)
To: Jeff King; +Cc: Markus Klinik, git
In-Reply-To: <20071212083154.GB7676@coredump.intra.peff.net>
On Wed, 12 Dec 2007, Jeff King wrote:
>
> +sub xargs_safe_pipe_capture {
> + my $MAX_ARG_LENGTH = 1024;
Well, that's a bit extreme. Make it 16kB or something. Anything should be
able to handle that.
Btw, on Linux, the argument length is realy only limited by the stack size
limits these days (you have to have a fairly recent kernel, though). It's
limited to stack limit / 4, to be exact, iirc. So if you see these kinds
of problems, and are running a recent kernel, do something like
ulimit -s 65536
to give yourself a big stack and you can continue without these kinds of
changes..
Linus
^ permalink raw reply
* Re: [(not so) random thoughts] using git as its own caching tool
From: Andreas Ericsson @ 2007-12-12 16:03 UTC (permalink / raw)
To: Mike Hommey; +Cc: Pierre Habouzit, Git ML
In-Reply-To: <20071212154848.GA19294@glandium.org>
Mike Hommey wrote:
> On Wed, Dec 12, 2007 at 04:35:19PM +0100, Andreas Ericsson <ae@op5.se> wrote:
>> A bit of both ;-)
>>
>> I like the idea to use the git object store, because that certainly
>> has an API that can't be done away with by user config. The reflog
>> and its expiration mechanism is subject to human control though, and
>> everyone doesn't even have them enabled. I don't for some repos where
>> I know I'll create a thousand-and-one loose objects by rebasing,
>> --amend'ing and otherwise fiddling with history rewrites.
>>
>> Having a tool that works on some repos but not on others because it
>> relies on me living with an auto-gc after pretty much every operation
>> would be very tiresome indeed.
>
> There is already a tool that relies on reflogs: stash.
>
No, "git stash save" works anyway. It's when you want to use multiple
stashes that it becomes tricky, but even that works if you're willing
to put some effort into it (although I don't use stash a lot, and not
at all in the very rebase-heavy ones).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Something is broken in repack
From: Nicolas Pitre @ 2007-12-12 16:13 UTC (permalink / raw)
To: Jon Smirl; +Cc: Junio C Hamano, gcc, Git Mailing List
In-Reply-To: <alpine.LFD.0.99999.0712112057390.555@xanadu.home>
On Wed, 12 Dec 2007, Nicolas Pitre wrote:
> I did modify the progress display to show accounted memory that was
> allocated vs memory that was freed but still not released to the system.
> At least that gives you an idea of memory allocation and fragmentation
> with glibc in real time:
>
> diff --git a/progress.c b/progress.c
> index d19f80c..46ac9ef 100644
> --- a/progress.c
> +++ b/progress.c
> @@ -8,6 +8,7 @@
> * published by the Free Software Foundation.
> */
>
> +#include <malloc.h>
> #include "git-compat-util.h"
> #include "progress.h"
>
> @@ -94,10 +95,12 @@ static int display(struct progress *progress, unsigned n, const char *done)
> if (progress->total) {
> unsigned percent = n * 100 / progress->total;
> if (percent != progress->last_percent || progress_update) {
> + struct mallinfo m = mallinfo();
> progress->last_percent = percent;
> - fprintf(stderr, "%s: %3u%% (%u/%u)%s%s",
> - progress->title, percent, n,
> - progress->total, tp, eol);
> + fprintf(stderr, "%s: %3u%% (%u/%u) %u/%uMB%s%s",
> + progress->title, percent, n, progress->total,
> + m.uordblks >> 18, m.fordblks >> 18,
> + tp, eol);
Note: I didn't know what unit of memory those blocks represents, so the
shift is most probably wrong.
Nicolas
^ permalink raw reply
* Re: git-cvsexportcommit fails for huge commits
From: Jeff King @ 2007-12-12 16:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Markus Klinik, git
In-Reply-To: <alpine.LFD.0.9999.0712120753120.25032@woody.linux-foundation.org>
On Wed, Dec 12, 2007 at 08:02:35AM -0800, Linus Torvalds wrote:
> On Wed, 12 Dec 2007, Jeff King wrote:
> >
> > +sub xargs_safe_pipe_capture {
> > + my $MAX_ARG_LENGTH = 1024;
>
> Well, that's a bit extreme. Make it 16kB or something. Anything should be
> able to handle that.
Obviously it should be tweaked, and I just chose an absurdly low value.
However, "xargs --show-limit" claims that the POSIX minimum is 2048,
less the size of the environment. I have no idea what the original
problem reporter's platform is, or what sort of environment size is sane
there.
-Peff
^ permalink raw reply
* Re: Something is broken in repack
From: Paolo Bonzini @ 2007-12-12 16:17 UTC (permalink / raw)
To: gcc; +Cc: git
In-Reply-To: <alpine.LFD.0.99999.0712120743040.555@xanadu.home>
> When I returned to the computer this morning, the repack was
> completed... with a 1.3GB pack instead.
>
> So... The gcc repo apparently really needs a large window to efficiently
> compress those large objects.
So, am I right that if you have a very well-done pack (such as gcc's),
you might want to repack in two phases:
- first discarding the old deltas and using a small window, thus
producing a bad pack that can be repacked without humongous amounts of
memory...
- ... then discarding the old deltas and producing another
well-compressed pack?
Paolo
^ 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