Hello Johannes,

On Wed, Apr 14, 2010, Johannes Gilger wrote:
quoted text
> 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.


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

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

quoted text
>
> 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
--
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