git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Gilger <heipei@hackvalue.de>
To: Aghiles <aghilesk@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git log of remote repositories.
Date: Wed, 14 Apr 2010 21:45:52 +0200	[thread overview]
Message-ID: <20100414194552.GA5178@dualtron.lan> (raw)
In-Reply-To: <x2q3abd05a91004141208x6e154385l8b7ce6488d65f21b@mail.gmail.com>

On 14/04/10 15:08, Aghiles wrote:
> It seems to me like a major restriction! Especially that I am tracking
> a remote branch ... No possibilities to do a diff or a log without fetching?
> Very sad. :(

Major restriction? Have you understood how git works, internally? The
first thing you'd have to do is to get the data (i.e. your version or
their version) on one of the sides then do the diff there. Now, that
either means you have to upload your non-matching objects or they have
to upload their non-matching objects. Next up, you might not even have
the authority (or technical possibility) to put data on that server
(think http), so obviously the diff will have to be done at your side.

So, what will be transmitted? Data the server already has but you don't.
git determines this data and then packs it into an efficient format and
sends it to you. Which is what? A diff of your version vs. theirs.
Except we don't transmit plain diffs but pack them up nicely so the data
is smaller and (because you now effectively fetched it) can be reused
any time after that initial diff.

If you're worried you might be downloading GBs of data in the process
you can always interrupt a running fetch.

Now, one might think of some very limited form of log. Like "git
remote-log master..master@origin" (syntax made up). This would be
something which could only be used with smart protocols and would
display a log (which you couldn't trust because you can't verify the
integrity and still has not much metadata). And it would be a heap of
new functionality to implement for something that doesn't fit into the
workflow of a git user. For the user it would probably take the same
amount of time as simply fetching everything new in most cases.

Or you can use SVN and have real online-diffs with real speed ;)

Greetings,
Jojo

-- 
Johannes Gilger <heipei@hackvalue.de>
http://heipei.net
GPG-Key: 0xD47A7FFC
GPG-Fingerprint: 5441 D425 6D4A BD33 B580  618C 3CDC C4D0 D47A 7FFC

  parent reply	other threads:[~2010-04-14 19:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-13 23:25 git log of remote repositories Aghiles
2010-04-13 23:27 ` Shawn O. Pearce
2010-04-14  2:15   ` Dave Olszewski
2010-04-14 11:33 ` Johannes Gilger
2010-04-14 19:08   ` Aghiles
2010-04-14 19:43     ` Tomas Carnecky
2010-04-14 19:45     ` Johannes Gilger [this message]
2010-04-14 20:05       ` Aghiles
2010-04-14 20:11         ` Sverre Rabbelier
2010-04-14 20:18           ` Aghiles
2010-04-14 20:25             ` Sverre Rabbelier
2010-04-14 20:39             ` Johannes Gilger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100414194552.GA5178@dualtron.lan \
    --to=heipei@hackvalue.de \
    --cc=aghilesk@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).