On Sat, Aug 23, 2014 at 3:56 AM, Jeff King wrote:
> [+cc spearce, as I think this is a bug in code.google.com's sending
> side, and he can probably get the attention of the right folks]
...
> My guess is a bug on the sending side. We have seen duplicate pack
> objects before, but never (AFAIK) co
On Mon, Aug 25, 2014 at 10:59 AM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> A stateless nonce could look like:
>>
>> nonce = HMAC_SHA1( SHA1(site+path) + '.' + now, site_key )
>>
>> where site_key is a private key known to the server. It
The implementation sends an LF, but the protocol documentation was
missing this detail.
Signed-off-by: Shawn Pearce
---
Documentation/technical/pack-protocol.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation
On Wed, Aug 27, 2014 at 2:53 PM, Michael Haggerty wrote:
> On 08/26/2014 02:03 AM, Jonathan Nieder wrote:
>> Jonathan Nieder wrote:
>> [...]
>>> I've having trouble keeping track of how patches change, which patches
>>> have been reviewed and which haven't, unaddressed comments, and so on,
>>> so
On Fri, Aug 29, 2014 at 3:08 PM, Jeff King wrote:
> On Fri, Aug 29, 2014 at 02:56:18PM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > If a pack contains duplicates of an object, and if that
>> > object has any deltas pointing at it with REF_DELTA, we will
>> > try to resolve the delt
On Sat, Aug 30, 2014 at 6:16 AM, Jeff King wrote:
> On Fri, Aug 29, 2014 at 07:59:32PM -0700, Shawn Pearce wrote:
>
>> > I agree it is probably a bug on the sending side, but I think last time
>> > this came up we decided to try to be liberal in what we accept. c.f.
>
On Wed, Sep 3, 2014 at 1:53 AM, Christian Couder
wrote:
> On Tue, Sep 2, 2014 at 3:51 PM, Theodore Ts'o wrote:
>> On Tue, Sep 02, 2014 at 07:21:17AM -0400, Theodore Ts'o wrote:
>>> On Tue, Sep 02, 2014 at 08:20:42AM +0100, Luca Milanesio wrote:
>>> > Hi Chris,
>>> > Seattle is a very inconvenient
On Wed, Sep 3, 2014 at 2:47 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> I know you are talking about something potentially much larger than
>> this, but I wanted to note that Michael Haggerty, Ramkumar Ramachandra,
>> and I will all be in the Bay Area for the GSoC Reunion, October 23-26.
>
On Thu, Sep 4, 2014 at 1:04 PM, Junio C Hamano wrote:
> Record the URL of the intended recipient for a push (after
> anonymizing it if it has authentication material) on a new "pushee
> URL" header. Because the networking configuration (SSH-tunnels,
> proxies, etc.) on the pushing user's side var
On Thu, Sep 4, 2014 at 4:57 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> As you know, the stateless HTTP thing doesn't allow the nonce on the
>> server to be carried from the initial ref advertisement into the final
>> receive-pack. We would either need t
On Sun, Apr 20, 2014 at 1:42 PM, Richard Hansen wrote:
> I have discovered a minor security vulnerability. I could send the
> patch to the mailing list, but I wanted someone else to take a look
> first just to make sure it's minor enough that folks will think it's OK
> to publicly announce.
>
> W
On Fri, Apr 25, 2014 at 4:56 PM, David Kastrup wrote:
> The previous implementation used a single sorted linear list of blame
> entries for organizing all partial or completed work. Every subtask had
> to scan the whole list, with most entries not being relevant to the
> task. The resulting run-
On Sat, Apr 26, 2014 at 12:48 AM, David Kastrup wrote:
> Shawn Pearce writes:
>
>> On Fri, Apr 25, 2014 at 4:56 PM, David Kastrup wrote:
>>> The previous implementation used a single sorted linear list of blame
>>> entries for organizing all partial or completed w
On Sat, Apr 26, 2014 at 9:50 AM, David Kastrup wrote:
> Shawn Pearce writes:
>
>> On Sat, Apr 26, 2014 at 12:48 AM, David Kastrup wrote:
>>> Shawn Pearce writes:
>>>>
>>>> And JGit was already usually slower than git-core. Now it will be
>>
On Sat, Apr 26, 2014 at 10:30 AM, David Kastrup wrote:
> David Kastrup writes:
>
>> http://repo.or.cz/r/wortliste.git
>> git blame [-M / -C] wortliste
>>
>> The latter one is _really_ taking a severe hit from the O(n^2)
>> algorithms. If your benchmarks for that one still point mostly to the
>>
On Sat, Apr 26, 2014 at 2:39 PM, David Kastrup wrote:
>
> At least the stuff I fixed with regard to performance would seem to be
> done right in JGit to start with.
Hah! Its Java. We have to do things right, otherwise its too slow. :-)
>> Its still not as fast as I want it to be. :-)
>
> Most of
On Mon, Apr 28, 2014 at 3:55 AM, Nguyễn Thái Ngọc Duy wrote:
> I hinted about it earlier [1]. It now passes the test suite and with a
> design that I'm happy with (thanks to Junio for a suggestion about the
> rename problem).
>
> From the user point of view, this reduces the writable size of index
On Fri, May 2, 2014 at 2:05 PM, Leo Razoumov wrote:
> surprisingly, searching this list and by way of Google
> I cannot find an answer to a simple question:
>
> In presence of smudge/clean filters which SHA1 hash
> (clean content or smudged content) gets stored in the repository?
The clean versio
On Thu, Jun 26, 2014 at 5:42 AM, Kirill Likhodedov
wrote:
> is it possible to know which tags are not yet pushed to a remote via a
> completely local command?
>
> (e.g. the list of unpushed _commits_ may be received by ‘git log
> ..’)
>
> I know it is possible to execute 'git ls-remote’ or 'git
On Thu, Jun 26, 2014 at 10:50 PM, Christian Halstrick
wrote:
> Imagine git does a recursive merge between A and B and finds multiple
> common ancestors X1,X2 for these commits.
> - Does git try to create an implicit/temporary common ancestor X3 by
> merging X1 and X2?
Yes this is the point of the
On Fri, Jun 27, 2014 at 1:45 AM, Jarrad Hope wrote:
> As a software developer I've used git for years and have found it the
> perfect solution for source control.
>
> Lately I have found myself using git in a unique use-case - modifying
> DNA/RNA sequences and storing them in git, which are essent
On Fri, Jun 27, 2014 at 2:30 PM, Ronnie Sahlberg wrote:
> List,
>
> One of my ref transaction aims is to make define a stable public API
> for accessing refs.
> Once this is done I want to make it possible to replace the current
> .git/refs/* model with a
> different type of backend.
> In my case
On Mon, Jun 30, 2014 at 5:48 AM, Christian Halstrick
wrote:
>> They don't. The conflicts are preserved into the virtual ancestor. The
>> user only sees the final conflicts during merging of A and B with
>> virtual X3 as the common ancestor.
>
> Ah, now I understand. When I merge X1 and X2 into the
On Fri, Jul 4, 2014 at 10:51 AM, Allan Gardner wrote:
> Currently fetching a sha1 fails on git.kernel.org:
>
> $ git --version && uname -a
> git version 1.9.4
> Linux nixos 3.12.23 #1-NixOS SMP Thu Jan 1 00:00:01 UTC 1970 x86_64 GNU/Linux
>
> $ rm -rf test && mkdir test && cd test && git init
> In
On Sat, Jul 5, 2014 at 6:05 AM, Allan Gardner wrote:
> On Fri, Jul 4, 2014 at 10:41 PM, Shawn Pearce wrote:
>>
>> On Fri, Jul 4, 2014 at 10:51 AM, Allan Gardner
>> wrote:
>> > Currently fetching a sha1 fails on git.kernel.org:
>> >
>> > $
On Thu, Jul 31, 2014 at 3:31 PM, Philip Oakley wrote:
> I thought it worth bring to the list's attention a recent article on
> CodeProject that may be of interest to those looking at splitting binary
> files into deterministic hunks.
>
> http://www.codeproject.com/Articles/801608/Using-a-rolling-
On Tue, Aug 19, 2014 at 3:06 PM, Junio C Hamano wrote:
>
> + push-cert = PKT-LINE("push-cert" NUL capability-list LF)
Haha. NUL. I love our wire protocol.
> + PKT-LINE("certificate version 0.1" LF)
> + PKT-LINE("pusher" ident LF)
> +
On Thu, Nov 28, 2013 at 1:29 AM, Jeff King wrote:
> On Thu, Nov 28, 2013 at 04:09:18PM +0700, Duy Nguyen wrote:
>
>> > Git should be better support resume transfer.
>> > It now seems not doing better it’s job.
>> > Share code, manage code, transfer code, what would it be a VCS we imagine
>> > it
On Thu, Nov 28, 2013 at 1:29 AM, zhifeng hu wrote:
> Once using git clone —depth or git fetch —depth,
> While you want to move backward.
> you may face problem
>
> git fetch --depth=105
> error: Could not read 483bbf41ca5beb7e38b3b01f21149c56a1154b7a
> error: Could not read aacb82de3ff8ae7b0a9e4c
On Wed, Dec 4, 2013 at 2:53 AM, Duy Nguyen wrote:
> I was thinking of an alternative to apache for testing smart-http so
> that most of http tests could always run. Mongoose [1] looks like a
> good candidate to bundle with git. Just one pair of source files,
> mongoose.[ch], a mainloop wrapper and
On Wed, Dec 4, 2013 at 12:08 PM, Jeff King wrote:
> On Thu, Nov 28, 2013 at 11:15:27AM -0800, Shawn Pearce wrote:
>
>> >> - better integration with git bundles, provide a way to seamlessly
>> >> create/fetch/resume the bundles with "git clone" and "
On Thu, Dec 5, 2013 at 5:21 AM, Michael Haggerty wrote:
> This discussion has mostly been about letting small Git servers delegate
> the work of an initial clone to a beefier server. I haven't seen any
> explicit mention of the inverse:
>
> Suppose a company has a central Git server that is meant
are reasonably
> sure that two packs with the same name will contain the same
> objects.
Yay-by: Shawn Pearce
> ---
> pack-write.c | 8 +---
> pack.h| 2 +-
> t/t5302-pack-index.sh | 4 ++--
> 3 files changed, 4 insertions(+), 10 deletions(-)
On Wed, Jan 22, 2014 at 3:22 AM, Michael Haggerty wrote:
> I just noticed that there are exactly four Git manpages with an "AUTHOR"
> section and five with a "DOCUMENTATION" section:
>
> $ make doc
> $ grep -nIE -e '^\.SH "DOCUMENTATION|AUTHOR"' Documentation/*.[0-9]
> Documentation/gi
On Thu, Jan 23, 2014 at 10:33 AM, Jeff King wrote:
> On Wed, Jan 22, 2014 at 06:05:36PM -0800, Jonathan Nieder wrote:
>
>> Jeff King wrote:
>>
>> > EWAH is a word-aligned compressed variant of a bitset (i.e. a data
>> > structure that acts as a 0-indexed boolean array for many entries).
>>
>> I su
Make it easy to experiment what remote access to objects would be
like if the network ran at say 1 ms round trip latency to obtain
any object not on the local repository.
$ time git ls-tree -r HEAD
real 0m0.059s
$ time GIT_RTT=1 git ls-tree -r HEAD
real 0m27.283s
Yes kids, slowing down l
On Tue, Feb 11, 2014 at 11:29 AM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> Why would you do this? Perhaps you need more time in your day
>> to consume tea or coffee. Set GIT_RTT and enjoy a beverage.
>
> So the conclusion is that it is not practical to do a la
On Sun, Oct 26, 2014 at 8:39 AM, Dennis Kaarsemaker
wrote:
> On Wed, Oct 22, 2014 at 10:11:40AM -0700, Junio C Hamano wrote:
>> Dennis Kaarsemaker writes:
>>
>> > On di, 2014-10-21 at 10:56 -0700, Junio C Hamano wrote:
>> >> Dennis Kaarsemaker writes:
>> >>
>> >> > By not clearing the request bu
On Tue, Dec 9, 2014 at 4:37 PM, brian m. carlson
wrote:
> I have a repository that's just under 2 GiB in size and contains over
> 2 refs, with a copy of it on a server. Both sides are using Git
> 2.1.2. If I push a branch that contains a single commit, it takes about
> 15 seconds to push. H
On Mon, Feb 16, 2015 at 10:43 AM, Junio C Hamano wrote:
> Jeff King writes:
>
>> ... And the whole output is checksummed by a single sha1
>> over the whole stream that comes at the end.
>>
>> I think the most feasible thing would be to quickly spool it to a
>> server on the LAN, and then use an e
On Sun, Feb 15, 2015 at 10:45 PM, Jeff King wrote:
> On Sun, Feb 15, 2015 at 11:59:02PM -0500, Nicolas Pitre wrote:
>
>> Yet, I think the biggest problem with pack v4 at the moment is the
>> packing algorithm for tree objects. We are piggy-backing on the pack v2
>> object delta compression sortin
On Wed, Feb 18, 2015 at 4:25 PM, Junio C Hamano wrote:
> Checking out a random branch is absolutely the worst thing you can
> do. Personally, I would think that the best thing you can do is to
> educate your users not to clone from a void. Create some history
> that is worth sharing, and then push
On Wed, Feb 18, 2015 at 4:43 PM, Shawn Pearce wrote:
> On Wed, Feb 18, 2015 at 4:25 PM, Junio C Hamano wrote:
>> Checking out a random branch is absolutely the worst thing you can
>> do. Personally, I would think that the best thing you can do is to
>> educate your users not
On Wed, Oct 9, 2013 at 12:30 PM, Jeff King wrote:
> On Tue, Oct 08, 2013 at 08:48:06PM +, brian m. carlson wrote:
>
>> When using GSS-Negotiate authentication with libcurl, the authentication
>> provided will change every time, and so the probe that git uses to determine
>> if
>> authenticati
On Wed, Oct 9, 2013 at 6:35 PM, brian m. carlson
wrote:
> On Wed, Oct 09, 2013 at 05:37:42PM -0400, Jeff King wrote:
>> On Wed, Oct 09, 2013 at 02:19:36PM -0700, Shawn O. Pearce wrote:
>> > 206b099 was written because the Google web servers for
>> > android.googlesource.com and code.google.com do
On Fri, Oct 11, 2013 at 3:31 PM, brian m. carlson
wrote:
> On Thu, Oct 10, 2013 at 01:14:28AM -0700, Shawn Pearce wrote:
>> Even if you want to live in the fairy land where all servers support
>> 100-continue, I'm not sure clients should pay that 100-160ms latency
>&g
On Sat, Oct 19, 2013 at 7:41 AM, Nicolas Pitre wrote:
> On Sat, 19 Oct 2013, Duy Nguyen wrote:
>
>> On Wed, Oct 16, 2013 at 3:34 PM, Jeff King wrote:
>> > I was recently presented with a repository with a corrupted packfile,
>> > and was asked if the data was recoverable. This post-mortem describ
On Mon, Oct 21, 2013 at 8:41 AM, wrote:
> The change-id is exactly like a commit-id, it is an SHA-1 value, but it
> is a constant embedded in the commit message.
https://gerrit-review.googlesource.com/Documentation/user-changeid.html
goes into more detail about these.
> Commit-ids change all th
On Mon, Oct 21, 2013 at 9:38 AM, Ondřej Bílka wrote:
> On Mon, Oct 21, 2013 at 09:35:07AM -0700, Shawn Pearce wrote:
>> On Mon, Oct 21, 2013 at 8:41 AM, wrote:
>> > The change-id is exactly like a commit-id, it is an SHA-1 value, but it
>> > is a constant emb
On Mon, Oct 21, 2013 at 11:40 AM, wrote:
>
> On Mon, Oct 21, 2013, at 02:29 PM, Thomas Koch wrote:
>> As I understand, a UUID could also be used for the same purbose as the
>> change-
>> id. How is the change-id generated by the way? Would it be a good english
>> name
>> to call it enduring commi
On Tue, Oct 22, 2013 at 8:00 PM, brian m. carlson
wrote:
> On Tue, Oct 22, 2013 at 06:34:00PM -0700, Jonathan Nieder wrote:
>> Forgive my ignorance: is there a way to do something analagous to that
>> patch but for GSS-Negotiate authentication? In other words, after
>> using the first request to
On Fri, Oct 25, 2013 at 3:21 AM, Jeff King wrote:
> [+cc spearce; sorry, I really should have cc'd the whole series to you
> in the first place]
>
> On Fri, Oct 25, 2013 at 08:16:18AM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > + - A header appears at the beginning:
>> > +
>> > +
On Thu, Oct 24, 2013 at 6:03 PM, Jeff King wrote:
> If `prepare_bitmap_walk` runs successfully, the resulting bitmap is
> stored and the equivalent of a `traverse_commit_list` call can be
> performed by using `traverse_bitmap_commit_list`; the bitmap version
> of this call yields the objects strai
On Thu, Oct 24, 2013 at 6:06 PM, Jeff King wrote:
> Note that most of the time we spend for --count invocations is on
> generating the pack revindex. It may be worth storing a revidx (either
> in a separate file, as part of the .idx, or as an optional section in
> the .bitmap file).
This was disc
On Thu, Oct 24, 2013 at 6:04 PM, Jeff King wrote:
> For bitmaps to be used, the following must be true:
>
> 1. We must be packing to stdout (as a normal `pack-objects` from
> `upload-pack` would do).
>
> 2. There must be a .bitmap index containing at least one of the
> "have" objects
On Wed, Oct 30, 2013 at 7:50 AM, Jeff King wrote:
> On Fri, Oct 25, 2013 at 01:47:06PM +, Shawn O. Pearce wrote:
>
>> I think Colby and I talked about having additional optional sections
>> in this file, but Colby didn't want to overcomplicate the format early
>> on. So v1 is probably not very
On Wed, Oct 30, 2013 at 8:10 AM, Jeff King wrote:
> On Fri, Oct 25, 2013 at 01:55:13PM +, Shawn O. Pearce wrote:
>>
>> Yay! This is similar to the optimization we use in JGit to send the
>> entire pack, but the part about sending a leading prefix is new. Do
>> you have any data showing how wel
On Wed, Oct 30, 2013 at 8:21 AM, Jeff King wrote:
> On Fri, Oct 25, 2013 at 02:14:11PM +, Shawn O. Pearce wrote:
>> On Thu, Oct 24, 2013 at 6:04 PM, Jeff King wrote:
>> > For bitmaps to be used, the following must be true:
>> >
>> > 1. We must be packing to stdout (as a normal `pack-objects
On Wed, Oct 30, 2013 at 3:47 PM, Vicent Marti wrote:
> On Wed, Oct 30, 2013 at 9:10 AM, Jeff King wrote:
>>
>> In fact, I'm not quite sure that even a partial reuse up to an offset is
>> 100% safe. In a newly packed git repo it is, because we always put bases
>> before deltas (and OFS_DELTA objec
On Wed, Nov 6, 2013 at 1:41 PM, Carlos Martín Nieto wrote:
> On Wed, 2013-11-06 at 12:32 -0800, Junio C Hamano wrote:
>> I'll queue these for now, but I doubt the wisdom of this series,
>> given that the ship has already sailed long time ago.
>>
>> Currently, no third-party implementation of a rec
On Wed, Nov 6, 2013 at 2:54 PM, Jeff King wrote:
> If we instead introduced "no-thin", it is more like:
>
> 1. Receive-pack starts advertising "no-thin" (as dictated by
> circumstances, as Carlos describes).
>
> 2. Send-pack which does not understand no-thin will ignore it and send
>
On Thu, Feb 26, 2015 at 3:14 PM, Christoph Anton Mitterer
wrote:
>
> I saw that when plain git (i.e. git://) is used, the client tells the
> server the hostname specified on the client side.
> For http one has the same automatically via http's Host: header.
>
> But after watching the git's over-ss
On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller wrote:
> bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity
Indeed, a DVCS like Git or Hg does not fit everyone. And neither do
centralized systems like Subversion. Choice is good.
However... I found some passages troubling for Git
On Tue, Mar 3, 2015 at 5:54 PM, Duy Nguyen wrote:
> On Wed, Mar 4, 2015 at 12:13 AM, Junio C Hamano wrote:
>> My recollection is that the consensus from the last time we
>> discussed protocol revamping was to list one capability per packet
>> so that packet length limit does not matter, but you m
On Wed, Mar 4, 2015 at 4:05 AM, Duy Nguyen wrote:
> On Wed, Mar 4, 2015 at 11:27 AM, Shawn Pearce wrote:
>> Let me go on a different tangent a bit from the current protocol.
>>
>> http://www.grpc.io/ was recently released and is built on the HTTP/2
>> standard. I
On Mon, Mar 9, 2015 at 6:57 AM, Michael J Gruber
wrote:
>
> Since we're talking business: git-scm.com still looks a bit like a
> ProGit/Github promotion site. I don't have anything against either, and
> git-scm.com provides a lot of the information that users are looking
> for, and that are hard t
On Mon, Mar 9, 2015 at 9:06 AM, David Kastrup wrote:
> Shawn Pearce writes:
>
>> On Mon, Mar 9, 2015 at 6:57 AM, Michael J Gruber
>> wrote:
>>>
>>> Since we're talking business: git-scm.com still looks a bit like a
>>> ProGit/Github promoti
We keep seeing reports of Gerrit Code Review users who incorrectly do
something like:
git clone URL foo
cd foo
git commit --amend -m "My first change!" -a
git push URL HEAD:refs/for/master
Step #3 is where they get into trouble. They just amended the
published tip commit and pushed it bac
On Tue, Mar 10, 2015 at 10:11 PM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> We keep seeing reports of Gerrit Code Review users who incorrectly do
>> something like:
>>
>> git clone URL foo
>> cd foo
>> git commit --amend -m "My fi
On Mon, Jun 24, 2013 at 5:23 PM, Vicent Marti wrote:
> This is the technical documentation and design rationale for the new
> Bitmap v2 on-disk format.
> ---
> Documentation/technical/bitmap-format.txt | 235
> +
> 1 file changed, 235 insertions(+)
> create mode 100
On Tue, Jun 25, 2013 at 4:08 PM, Vicent Martí wrote:
> On Tue, Jun 25, 2013 at 11:17 PM, Junio C Hamano wrote:
>> What case are you talking about?
>>
>> The n-th object must be one of these four types and can never be of
>> more than one type at the same time, so a natural expectation from
>> the
On Tue, Jun 25, 2013 at 11:11 PM, Jeff King wrote:
> On Tue, Jun 25, 2013 at 09:33:11PM +0200, Vicent Martí wrote:
>
>> > One way we side-stepped the size inflation problem in JGit was to only
>> > use the bitmap index information when sending data on the wire to a
>> > client. Here delta reuse pl
On Wed, Jun 26, 2013 at 6:53 PM, Colby Ranger wrote:
>> + Generating this reverse index at runtime is **not** free (around 900ms
>> + generation time for a repository like `torvalds/linux`), and once again,
>> + this generation time needs to happen every time `pack-objects` is
>> + spawned.
9
On Wed, Jun 26, 2013 at 7:45 PM, Jeff King wrote:
>
> In particular, it seems like the slowness we saw with the v1 bitmap
> format is not what Shawn and Colby have experienced. So it's possible
> that our test setup is bad or different. Or maybe the C v1 reading
> implementation had some problems
On Mon, Jul 1, 2013 at 11:47 AM, Colby Ranger wrote:
>> But I think we are comparing
>> apples to steaks here, Vincent is (rightfully) concerned about process
>> startup performance, whereas our timings were assuming the process was
>> already running.
>>
>
> I did some timing on loading the rever
On Sun, Jul 7, 2013 at 2:46 AM, Jeff King wrote:
> On Mon, Jul 01, 2013 at 11:47:32AM -0700, Colby Ranger wrote:
>
>> > But I think we are comparing
>> > apples to steaks here, Vincent is (rightfully) concerned about process
>> > startup performance, whereas our timings were assuming the process w
On Sun, Jul 7, 2013 at 3:14 AM, Jeff King wrote:
> The pack revindex stores the offsets of the objects in the
> pack in sorted order, allowing us to easily find the on-disk
> size of each object. To compute it, we populate an array
> with the offsets from the sha1-sorted idx file, and then use
> q
On Mon, Jul 8, 2013 at 12:57 AM, Jeff King wrote:
> On Sun, Jul 07, 2013 at 04:52:23PM -0700, Shawn O. Pearce wrote:
>
>> On Sun, Jul 7, 2013 at 3:14 AM, Jeff King wrote:
>> > The pack revindex stores the offsets of the objects in the
>> > pack in sorted order, allowing us to easily find the on-d
Has anyone studied the impact of converting the pack idx fanout table
from 256 entries to 65536 entries?
Back of the envelope estimates for 3.1M objects in linux.git suggests
a 2^16 fanout table would decrease the number of binary search
iterations from ~14 to ~6. The increased table costs an extr
On Mon, Jul 8, 2013 at 10:37 AM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> Has anyone studied the impact of converting the pack idx fanout table
>> from 256 entries to 65536 entries?
>>
>> Back of the envelope estimates for 3.1M objects in linux.git suggest
On Tue, Nov 6, 2012 at 2:09 PM, Josef Wolf wrote:
>
> On Tue, Nov 06, 2012 at 09:41:29PM +, John McKown wrote:
> > Josef Wolf raven.inka.de> writes:
> > > Just for curiosity: what would happen if such a collision would occur
> > > within
> > > one repository?
>
> > In a sense, this cannot ha
On Wed, Nov 7, 2012 at 7:35 AM, Josef Wolf wrote:
> When using git-clone over an unreliable link (say, UMTS) and the network goes
> down, git-clone deletes everything what was downloaded. When the network goes
> up again and you restart git-clone, it has to start over from the
> beginning. Then, e
On Thu, Nov 22, 2012 at 10:39 AM, Yichao Yu wrote:
> I sent this email yesterday to the git mailing list but I cannot find
> it in any archive so I decide to send it again.
If it was HTML formatted it would have been silently dropped by the list.
> Does anyone know what has happened to the maili
On Wed, Nov 21, 2012 at 9:30 PM, Eric S. Raymond wrote:
> I have completed work on git-weave (the tool I had called 'gitpacker' in some
> previous postings). I want to submit a patch that integrates it into git;
> in hopes of smoothing the process I have some technical and procedural
> questions.
On Thu, Nov 22, 2012 at 11:44 AM, Yichao Yu wrote:
>> US holiday today? The list traffic tends to be down during holidays.
> This silent? 0 email from the kernel mailing list for 10+ hours?..
> anyway nvm...
Check your spam filters? I am having no trouble getting email for the
Git list. T
I don't think there is an issue the way you have tried to describe
this scenario.
On Sat, Nov 24, 2012 at 3:12 AM, Michael Hirshleifer <111...@caltech.edu> wrote:
> Evil Guy creates 2 files, 1 evil and 1 innocuous, with the same SHA-1
> checksum (including Git header). Mr. Evil creates a local bra
On Sat, Nov 24, 2012 at 4:02 AM, arif wrote:
> Is there any way so that i can tell how much i have to download to
> obtain a full clone (not a shallow one) of a respository?
Ask the repository owner to tell you?
There is no information sent by the server about size of repository,
so no, you can'
On Tue, Nov 27, 2012 at 12:48 PM, Eric S. Raymond wrote:
> Because I do a lot of work on repository conversion tools, I've had
> to learn a lot of detail about ontological mismatches between
> version-control systems - especially places where you lose metadata
> moving between them.
>
> In general
On Tue, Nov 27, 2012 at 3:04 PM, Eric S. Raymond wrote:
> Junio C Hamano :
>> fsck_ident() in fsck.c rejects anything but " [1-9][0-9]* " after
>> the author and committer ident (i.e. the timestamp has to be
>> integral number of seconds since the epoch, not before it, nor
>> with fractional secon
On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras
wrote:
> On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond wrote:
>> Shawn Pearce :
>>> Well... if we added a fractional seconds to a commit, older versions
>>> of Git will scream loudly and refuse to work with the
On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis wrote:
> We are using git with the smart HTTP protocol. We are seeing the client
> freeze with Jenkins poll. It stops the continuous build which is a bit
> of a pain. It happens with the latest release 1.8.0 on the client side.
> The server is using 1.7.
On Wed, Nov 28, 2012 at 9:25 AM, Ivan Kanis wrote:
> Shawn Pearce wrote:
>
>> On Wed, Nov 28, 2012 at 6:12 AM, Ivan Kanis
>> wrote:
>>>
>>> On the server we are seeing the following error message:
>>
>> Upgrade your server.
>
> OK we'
On Sat, Dec 1, 2012 at 6:31 PM, Sitaram Chamarty wrote:
> Background: I have a situation where I have to fix up a few hundred
> repos in terms of 'git gc' (the auto gc seems to have failed in many
> cases; they have far more than 6700 loose objects). I also found some
> corrupted objects in some
On Fri, Dec 7, 2012 at 9:59 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> The linked page has not been showing the promised "more complete
>> list" for more than 6 months by now, and nobody has resurrected
>> the list there nor elsewhere since then.
>>
>> Signed-off-by: Junio C Hamano
On Tue, Dec 11, 2012 at 11:46 AM, Junio C Hamano wrote:
> This is a companion to an ancient thread
>
> http://thread.gmane.org/gmane.comp.version-control.git/145311/focus=145337
>
> in which an error was dealt with while pushing into a "mirror"
> repository that has a symbolic reference refs/r
On Fri, Dec 21, 2012 at 11:53 AM, Dun Peal wrote:
> I need to share a symbolic reference - essentially, a named pointer to
> another reference - among multiple repositories.
>
> As shown in the code below, I can successfully create a local
> symbolic-ref `foo_ptr` to branch `foo`, but can't push i
This thread is pretty interesting. Unfortunately the holidays have
kept me busy. But I am excited by the work David and Peff are doing.
:-)
On Sun, Dec 30, 2012 at 1:31 PM, Jeff King wrote:
> On Sun, Dec 30, 2012 at 07:53:48PM +0700, Nguyen Thai Ngoc Duy wrote:
>
>> > $ cd objects/pack && ls
>>
On Tue, Jan 1, 2013 at 4:10 AM, Duy Nguyen wrote:
> On Tue, Jan 1, 2013 at 11:15 AM, Duy Nguyen wrote:
>>> Fix pack-objects to behave the way JGit does, cluster commits first in
>>> the pack stream. Now you have a dense space of commits. If I remember
>>> right this has a tiny positive improvemen
On Tue, May 21, 2013 at 3:33 PM, Chico Sokol wrote:
> It was git who created that object.
>
> We're trying to build a improved java library focused in our needs
> (jgit has a really confusing api focused in solving egit needs).
JGit code... is confusing because its fast. We spent a lot of time
tr
On Tue, May 21, 2013 at 9:51 PM, Andreas Krey wrote:
> On Tue, 21 May 2013 19:18:35 +, Chico Sokol wrote:
>> Ok, we discovered that the commit object actually contains the tree
>> object's sha1, by reading its contents with python zlib library.
>>
>> So the bug must be with our java code (we'r
101 - 200 of 263 matches
Mail list logo
