Re: Re: [rfc] git: combo-blobs

From: Petr Baudis (pasky_at_ucw.cz)
Date: 04/11/05

  • Next message: Petr Baudis: "Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)"
    Date:	Mon, 11 Apr 2005 20:40:34 +0200
    To: Chris Wedgwood <cw@f00f.org>
    
    

    Dear diary, on Mon, Apr 11, 2005 at 08:13:19PM CEST, I got a letter
    where Chris Wedgwood <cw@f00f.org> told me that...
    > On Mon, Apr 11, 2005 at 09:01:51AM -0700, Linus Torvalds wrote:
    >
    > > I disagree. Yes, the thing is designed to be replicated, so most of
    > > the time the easiest thing to do is to just rsync with another copy.
    >
    > It's not clear how any of this is going to give me something like
    >
    > bk changes -R
    >
    > or
    > bk changes -L
    >
    > functionality. I'm guessing I will have to sync locally and check
    > between two trees in those cases? Or at least sync enough metadata as
    > to make this possible... but not the entire tree right?

    Checking "what will be transferred when I push" doesn't sound hard - the
    push itself is not too trivial, but solvable. Perhaps even by pure
    rsync, if you won't support updating tracked trees (does not sound
    overwhelmingly useful anyway).

    Checking "what will be transferred if I pull" is much worse. Perhaps you
    could make a parallel objects repository, fetch all the newer commit and
    tree metadata there, and then do diff-tree. I think you need something
    smarter than rsync for that, though.

    [git-pasky] As long as you are not pulling from a tracked branch, the
    worst what can happen is that the enemy will trick you to pulling some
    terabytes of data. Or overwrite existing objects with garbage, but
    --ignore-existing would solve that trivially.

    -- 
    				Petr "Pasky" Baudis
    Stuff: http://pasky.or.cz/
    98% of the time I am right. Why worry about the other 3%.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Petr Baudis: "Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)"

    Relevant Pages

    • Re: Kernel SCM saga..
      ... We'd need a regenerated coherent copy of BKCVS to pipe into those SCM to ... It looks similar to a diff -ur of two hardlinked trees, ... worthless after using rsync in the network, ...
      (Linux-Kernel)
    • Re: [PATCH] adding two new options to cp
      ... > I'm tired of trying to use rsync or gcp (which doesn't like symlinks ... > often) to copy trees of files/directories using hard links, ...
      (freebsd-hackers)
    • Re: [rfc] git: combo-blobs
      ... > the time the easiest thing to do is to just rsync with another copy. ... between two trees in those cases? ... send the line "unsubscribe linux-kernel" in ... Please read the FAQ at http://www.tux.org/lkml/ ...
      (Linux-Kernel)
    • Re: Documentation - how to apply patches for various trees
      ... > trees and b) get asked this question less often. ... > the various patches. ... download slowly change so it needs to be kept up-to-date, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: BK kernel workflow
      ... > I was looking to the trees used by mantainers. ... But even so it's a moving target and labeling a set of people as ... maintainers implies that other people aren't. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)