Re: git log of remote repositories.

From: Aghiles <aghilesk@gmail.com>
Date: Apr 14, 2010, 20:05 UTC
Message-ID: <w2s3abd05a91004141305h28d69d44g2fcb69abe578dbcc@mail.gmail.com>
In-Reply-To: <20100414194552.GA5178@dualtron.lan>

Hello Johannes,

On Wed, Apr 14, 2010, Johannes Gilger wrote:

> Major restriction? Have you understood how git works, internally?

I don't need to understand how gits works _internally_ to know what is a restriction to _me_. ;)

Having a sneak peek on what's going upstream seems like a natural thing to do, no ?

For example, I want to write a script to say to the user what are files that could be potentially in conflict from upstream. As I understand it now, I have to fetch and then check. No biggie but I am must say I am surprised.

Show 8 quoted lines

> 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.
>

Understood.

Show 6 quoted lines

> 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.

Understood.

>
> Now, one might think of some very limited form of log.

In my case, just a list of modified files would be fine actually. Maybe this is something I can do already ?

Thanks for the insight.

  -- aghiles