git log of remote repositories.

git log of remote repositories.

[Aghiles]

Hello,

I have a local branch that is a tracking a remote branch. I want to see
what are the modifications upstream, _before_ I pull. I tried
'git log origin' but that's only the point from where I pulled last.

Is there a way to do that?

I see a --remote option in recent git versions, does it have something
to do with I want to achieve?

Thank you,

  -- aghiles

Re: git log of remote repositories.

[Shawn O. Pearce]

Aghiles <aghilesk@gmail.com> wrote:
> I have a local branch that is a tracking a remote branch. I want to see
> what are the modifications upstream, _before_ I pull. I tried
> 'git log origin' but that's only the point from where I pulled last.
> 
> Is there a way to do that?

git fetch
git log ..origin
 
-- 
Shawn.

Re: Re: git log of remote repositories.

[Dave Olszewski]

On Tue, 13 Apr 2010, Shawn O. Pearce wrote:

> Aghiles <aghilesk@gmail.com> wrote:
>> I have a local branch that is a tracking a remote branch. I want to see
>> what are the modifications upstream, _before_ I pull. I tried
>> 'git log origin' but that's only the point from where I pulled last.
>>
>> Is there a way to do that?
>
> git fetch
> git log ..origin

Or the more portable and concise, since 1.7.0:

git log ..@{u}

Re: git log of remote repositories.

[Johannes Gilger]

On 2010-04-13, Aghiles <aghilesk@gmail.com> wrote:
> I have a local branch that is a tracking a remote branch. I want to see
> what are the modifications upstream, _before_ I pull. I tried
> 'git log origin' but that's only the point from where I pulled last.
>
> Is there a way to do that?
AFAIK no, the operations have to be local.

In order to see if there are any new changes to be pulled you could do
this: git fetch --dry-run

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

Re: git log of remote repositories.

[Aghiles]

On Wed, Apr 14, 2010, Johannes Gilger  wrote:
> AFAIK no, the operations have to be local.
>
> In order to see if there are any new changes to be pulled you could do
> this: git fetch --dry-run

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

  -- aghiles

Re: git log of remote repositories.

[Tomas Carnecky]

On 4/14/10 9:08 PM, Aghiles wrote:
> On Wed, Apr 14, 2010, Johannes Gilger  wrote:
>> AFAIK no, the operations have to be local.
>>
>> In order to see if there are any new changes to be pulled you could do
>> this: git fetch --dry-run
>
> 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. :(

If you are interested in the actual commits (say, you want to merge 
them), you need to fetch them anyway. And if you just want to look at 
the history, most repos provide a web interface which you can use.

tom

Re: git log of remote repositories.

[Johannes Gilger]

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

Re: git log of remote repositories.

[Aghiles]

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

Re: git log of remote repositories.

[Sverre Rabbelier]

Heya,

On Wed, Apr 14, 2010 at 22:05, Aghiles <aghilesk@gmail.com> wrote:
> Having a sneak peek on what's going upstream seems like a natural
> thing to do, no ?

This can be done as said before, by fetching (which does not touch
your working copy, it only adds some objects to your store). Can you
explain what your hesitation to doing the fetch is? Are the objects
stored on the server (potentially) very large?

-- 
Cheers,

Sverre Rabbelier

Re: git log of remote repositories.

[Aghiles]

On Wed, Apr 14, 2010, Sverre Rabbelier wrote:
> This can be done as said before, by fetching (which does not touch
> your working copy, it only adds some objects to your store). Can you
> explain what your hesitation to doing the fetch is? Are the objects
> stored on the server (potentially) very large?

Yes, size can be an issue. Additionally, git fetch will probably update
some references, like FETCH_HEAD, no ? I might want these
untouched, if possible.

  -- aghiles

Re: git log of remote repositories.

[Sverre Rabbelier]

Heya,

On Wed, Apr 14, 2010 at 22:18, Aghiles <aghilesk@gmail.com> wrote:
> Yes, size can be an issue. Additionally, git fetch will probably update
> some references, like FETCH_HEAD, no ? I might want these
> untouched, if possible.

I don't think it's a good idea to rely on FETCH_HEAD; if it contains
anything you care about you should make a branch or tag for it. Other
than FETCH_HEAD 'git fetch' will only update refs in the
'refs/remotes/<remote>/' namespace.

-- 
Cheers,

Sverre Rabbelier

Re: git log of remote repositories.

[Johannes Gilger]

On 14/04/10 16:18, Aghiles wrote:
> Yes, size can be an issue. Additionally, git fetch will probably update
> some references, like FETCH_HEAD, no ? I might want these
> untouched, if possible.

Besides the space-problem: If you worry about losing already-fetched
history (because the guy upstream forgot to take his meds and has
deleted all the history and your remote is configured to accept non-ff
refs) you still have the reflog to get back.

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