Re: How to check new commit availability without full fetch?

Nicolas Pitre [off-list ref] writes:

quoted

I am sure I am not the only one with such an itch.

Maybe you are. There is very little point knowing that the remote repo 
has new commits if you're not going to fetch them, so I don't understand 
why you need this.

A feel good factor is in play?  IOW, "I am short of time, so I won't be
able to really afford to 'git pull' and test the result of re-integrating
my changes to what happened on the other end.  If I can learn that there
is nothing happening over there, then I won't have to do anything and know
that I am up to date."

On Sun, 10 Jan 2010, Junio C Hamano wrote:

Nicolas Pitre [off-list ref] writes:

quoted

quoted

I am sure I am not the only one with such an itch.

Maybe you are. There is very little point knowing that the remote repo 
has new commits if you're not going to fetch them, so I don't understand 
why you need this.

A feel good factor is in play?  IOW, "I am short of time, so I won't be
able to really afford to 'git pull' and test the result of re-integrating
my changes to what happened on the other end.  If I can learn that there
is nothing happening over there, then I won't have to do anything and know
that I am up to date."

Just do a fetch then.  If the fetch progress display looks like if it is 
going to take a while then just interrupt it and go home.  If the fetch 
looks trivial then just merge it.  In any case, the "feel good" factor 
can't be that great by only knowing if the remote has changed or not.  

Well maybe if it hasn't changed then you know right away how to feel 
about it (equally with a fetch in that case), and if the remote is 
indeed different then you can't tell whether the changes are trivial or 
not without actually fetching them.


Nicolas

On 2010-01-10, Nicolas Pitre [off-list ref] wrote:

On Sun, 10 Jan 2010, Junio C Hamano wrote:
 >
 > A feel good factor is in play?  IOW, "I am short of time, so I won't be
 > able to really afford to 'git pull' and test the result of re-integrating
 > my changes to what happened on the other end.  If I can learn that there
 > is nothing happening over there, then I won't have to do anything and know
 > that I am up to date."


Just do a fetch then.  If the fetch progress display looks like if it is
 going to take a while then just interrupt it and go home.  If the fetch
 looks trivial then just merge it.  In any case, the "feel good" factor
 can't be that great by only knowing if the remote has changed or not.

Forced interruption is not such a good idea. I would favor a
non-destructive way to monitor availability of remote commits.

BTW, pull and push are in a way symmetric operations. Is there any
deep reason why push supports --dry-run but pull/fetch does not??

--Leo--

Hi,

On Mon, Jan 11, 2010 at 9:36 AM, Leo Razoumov [off-list ref] wrote:

On 2010-01-10, Nicolas Pitre [off-list ref] wrote:

quoted

On Sun, 10 Jan 2010, Junio C Hamano wrote:
 >
 > A feel good factor is in play?  IOW, "I am short of time, so I won't be
 > able to really afford to 'git pull' and test the result of re-integrating
 > my changes to what happened on the other end.  If I can learn that there
 > is nothing happening over there, then I won't have to do anything and know
 > that I am up to date."


Just do a fetch then.  If the fetch progress display looks like if it is
 going to take a while then just interrupt it and go home.  If the fetch
 looks trivial then just merge it.  In any case, the "feel good" factor
 can't be that great by only knowing if the remote has changed or not.

Forced interruption is not such a good idea. I would favor a
non-destructive way to monitor availability of remote commits.

By default, when you add a remote (with git remote add), git sets up
the fetch refspec in your config that looks like

  [remote "foo"]
    url = git://foo.com/git/foo.git
    fetch = refs/heads/*:refs/remotes/foo/*

That is to say, branches on the remote repo will be fetched into a
"safe" area, refs/remotes/foo/, away from the branches that you
normally work with in refs/heads/.

However, if you have a different config and you're fetching directly
into refs/heads/, then I can see why you would want to "peek" first
with --dry-run before fetching. Are you doing this?

BTW, pull and push are in a way symmetric operations. Is there any
deep reason why push supports --dry-run but pull/fetch does not??

It's more accurate to say that push and fetch are symmetric, because
pull is fetch with merge or rebase tacked on.

Even then, push and fetch are not _that_ symmetric...

-- 
Cheers,
Ray Chuan

On Sun, 10 Jan 2010, Leo Razoumov wrote:

On 2010-01-10, Nicolas Pitre [off-list ref] wrote:

quoted

On Sun, 10 Jan 2010, Junio C Hamano wrote:
 >
 > A feel good factor is in play?  IOW, "I am short of time, so I won't be
 > able to really afford to 'git pull' and test the result of re-integrating
 > my changes to what happened on the other end.  If I can learn that there
 > is nothing happening over there, then I won't have to do anything and know
 > that I am up to date."


Just do a fetch then.  If the fetch progress display looks like if it is
 going to take a while then just interrupt it and go home.  If the fetch
 looks trivial then just merge it.  In any case, the "feel good" factor
 can't be that great by only knowing if the remote has changed or not.

Forced interruption is not such a good idea. I would favor a
non-destructive way to monitor availability of remote commits.

You still don't answer my question though.  Again, _why_ do you need to 
know about remote commit availability without fetching them?

BTW, pull and push are in a way symmetric operations. Is there any
deep reason why push supports --dry-run but pull/fetch does not??

Pushing involves resource usage on your own machine while 
pulling/fetching involves the remote machine.  Your choice to "waste" 
CPU cycles on your own machine is not the same as having anybody do the 
same on a central server.


Nicolas

On Sun, Jan 10, 2010 at 08:36:44PM -0500, Leo Razoumov wrote:

BTW, pull and push are in a way symmetric operations.

Not really... 'pull' = 'fetch' + 'merge', while 'push' only propagates
changes without any merging. You can say 'fetch' and 'push' are in a way
symmetric operations, but this symmetry is limited due to difference in
usage between local and remote branches.

Is there any
deep reason why push supports --dry-run but pull/fetch does not??

I guess it is because no one needs it. 'push' has --dry-run, because
it updates local references in a remote repository. So, you may want
to be sure that you are pushing the right thing. On the other hand,
I see no reason to have --dry-run for 'fetch', because it updates only
remote references, making them to point to the current state of the
corresponding branches. 'fetch' does not change any local branch, so
I see no reason for --dry-run.

What use case do you have in mind that needs --dry-run for 'fetch'?


Dmitry

On 2010-01-10, Nicolas Pitre [off-list ref] wrote:

You still don't answer my question though.  Again, _why_ do you need to
 know about remote commit availability without fetching them?

I use git to track almost all my data (code and otherwise) and spread
it between several computers. I end up with several local repos having
the same local branches. It happens once in a while that I fetch into
a given remote/foo from several local foo branches from different
machines and the operation fails. It happens because the commits have
not been yet consistently distributed among the repos. To do the
forensics and figure out who should update whom first I need a quick
and non-destructive way to fetch dry-run.

--Leo--

On Mon, 11 Jan 2010, Leo Razoumov wrote:

On 2010-01-10, Nicolas Pitre [off-list ref] wrote:

quoted

You still don't answer my question though.  Again, _why_ do you need to
 know about remote commit availability without fetching them?

I use git to track almost all my data (code and otherwise) and spread
it between several computers. I end up with several local repos having
the same local branches. It happens once in a while that I fetch into
a given remote/foo from several local foo branches from different
machines and the operation fails. It happens because the commits have
not been yet consistently distributed among the repos. To do the
forensics and figure out who should update whom first I need a quick
and non-destructive way to fetch dry-run.

There is probably something awkward about your setup then.

Normally you should have a remote description for any of the remote 
repositories you fetch from.  So if you have, say, remote machine_a with 
repo foo, machine_b with repo bar, and machine_c with repo baz, then 
fetching any of those will _only_ mirror locally the state of those 
remote repositories.  There is no ordering required as there can't be 
any conflicts in the mere fact of mirroring what the other guys have.  
That's what remote tracking branches are for: they follow the state of a 
remote repository and are never altered by local changes.  And you can 
have as many of those as you wish and they will never conflict with each 
other as each remote description is independent. And this is true 
whether or not the remote repository lives on the same machine (that 
would be a remote directory in that case).

And even if most if not all those remotes are actually copies of each 
others, then the first fetch to occur will transfer the new objects 
while fetching the other ones will simply notice that the required 
objects are already available locally and only the ref will be updated.

The ordering comes into play when it is time to _merge_ those remote 
branches into, say, the local master branch.  That's why it is probably 
a good thing to use fetch+merge instead of pull in this case.  But this 
is then a local matter and nothing that depends on the fetch ordering.


Nicolas

On 2010-01-11, Nicolas Pitre [off-list ref] wrote:

On Mon, 11 Jan 2010, Leo Razoumov wrote:

 > On 2010-01-10, Nicolas Pitre [off-list ref] wrote:
 > >
 > > You still don't answer my question though.  Again, _why_ do you need to
 > >  know about remote commit availability without fetching them?
 > >
 >
 > I use git to track almost all my data (code and otherwise) and spread
 > it between several computers. I end up with several local repos having
 > the same local branches. It happens once in a while that I fetch into
 > a given remote/foo from several local foo branches from different
 > machines and the operation fails. It happens because the commits have
 > not been yet consistently distributed among the repos. To do the
 > forensics and figure out who should update whom first I need a quick
 > and non-destructive way to fetch dry-run.


There is probably something awkward about your setup then.

 Normally you should have a remote description for any of the remote
 repositories you fetch from.  So if you have, say, remote machine_a with
 repo foo, machine_b with repo bar, and machine_c with repo baz, then
 fetching any of those will _only_ mirror locally the state of those
 remote repositories.  There is no ordering required as there can't be
 any conflicts in the mere fact of mirroring what the other guys have.
 That's what remote tracking branches are for: they follow the state of a
 remote repository and are never altered by local changes.  And you can
 have as many of those as you wish and they will never conflict with each
 other as each remote description is independent. And this is true
 whether or not the remote repository lives on the same machine (that
 would be a remote directory in that case).

Setup might be, indeed, awkward but it handles very diverse tasks.
As I said in my earlier emails different repos fetch into the *same* remote/foo.
So there could be conflicts and using fetch -f could cause loss of data.

Before switching to git I used mercurial for the same purpose and it
has command that are equivalent to fetch --dry-run.

--Leo--