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. > 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html