history missing

Hi,

I cloned a remote repository to check recent changes in origin/master I do: git fetch origin master git log origin master

recently I found out that log doesn't show recent commits I know that on server there were several commits let's say on the 19th but log shows that recent commit was done on the 17th the most strange thing I'm sure I have seen those commits fetched already I did git fetch origin master several times but it didn't help the log says that recent commit was done on 17th after I performed git remote update log again shows recent commits on 19th Has anyone faced such behaviour? I'm relatively new git user, what do I do wrong?

Thanks in advance, Vitaliy S

Heya,

On Tue, Oct 26, 2010 at 12:47, Vitaliy Semochkin <vitaliy.se@gmail.com> wrote:

So, you can either of:

$ git pull origin master # fetches and merges $ git log origin/master # looks at what upstream has but that you have not merged yet $ git rebase origin/master # rebase your changes on top of upstream $ git merge origin/master # merge with upstream

Hi Vitaliy,

Vitaliy Semochkin wrote:

Yes, this can be confusing.

The "git fetch" command can be used in two ways: to update remote-tracking branches and to grab some particular branch (or other ref) quickly.

Updating remote-tracking branches ---------------------------------

Use "git fetch <remote>", or "git fetch --all" if you want to update all remote-tracking branches.

Inspecting a particular branch ------------------------------

Use "git fetch <remote> <branch>"; this will fetch that branch and store it as FETCH_HEAD. You can "git log FETCH_HEAD", "git merge FETCH_HEAD", etc, to interact with the branch head you just downloaded.

If you want to fetch a branch to a local branch, you could use

	git fetch <remote> <branch>
	git branch <local-branch-name> FETCH_HEAD

but there is also a shorter way to write that:

	git fetch <remote> <branch>:<local-branch-name>

This form is especially useful for grabbing a subtree of the branch hierarchy all at once:

	git fetch junio refs/heads/sg/*:gabor/*

The "git fetch <remote>" form is syntactic sugar for this syntax. The 'fetch' lines in .git/config describe what remote:local ref specifiers will be implicitly added to the command line after the name of a configured remote repository.

See the "git fetch" manual for details and examples.

Hope that helps, Jonathan

On Mon, Nov 8, 2010 at 4:02 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

I agree and I believe this has come up a lot of times before. I talked to Jeff and Junio about this at GitTogether and Jeff said he has a patch for it that he would try to get up to date in a while. (Thanks, Jeff!)

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

This fetches into FETCH_HEAD _only_ from "origin" *remote*.

This show log of 'origin/HEAD', which probably is 'origin/master'... but which didn't get updated, and local branch 'master'.

How can this issue be solved? The meaning of parameters in 'git fetch' is different from meaning of parameters in 'git log'.

Unless it is about adding hint / advice for when doing 'git fetch <remote> <branch>'...

On Mon, Nov 8, 2010 at 8:29 AM, Jakub Narebski <jnareb@gmail.com> wrote:

Sorry, maybe I misunderstood what the confusion was about. What I was referring to was the confusion caused by 'git fetch origin master' not updating 'refs/remotes/origin/master'.

/Martin

On Mon, 8 Nov 2010, Martin von Zweigbergk wrote:

Should it really do it? What if it does not exist? What if <remote> is specified via URL?

If I understand correctly current behavior of 'git fetch <remote> <branch>' wrt. FETCH_HEAD was meant for one-off 'git pull <remote> <branch>', or rather 'git pull <URL> <branch>'.

Sidenote: if original poster used

  $ git fetch origin
  $ git log origin

I think everything would be all right.

On Mon, Nov 8, 2010 at 8:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:

I would probably not expect it to be updated (even if the URL matches a configured remove). If the reference does not yet exist, I think I would expect it to be created.

Also see http://thread.gmane.org/gmane.comp.version-control.git/127163/. Junio, Jeff and Avery can argue much better for and against this than I can. I read it at some point, but I don't quite remember now if they did discuss the historical reasons for the current behavior in that thread.

/Martin

On Mon, Nov 08, 2010 at 09:14:27AM -0500, Martin von Zweigbergk wrote:

Yeah, the patch I posted a while back (and referenced below) does not convert URLs into remote names (nor do I think it should). But if you give it the name of a configured remote, and it is fetching a ref from the remote that is mentioned on the LHS of a configured fetch refspec, it will update the matching RHS of that refspec opportunistically.

So it should be pretty unsurprising to the user (see the thread below for some discussion of when it could be surprising).

I took a look at cleaning up the patch from that thread. It causes 4 of the test scripts to fail. Most disturbing is this one:

  $ grep explicit.fetch t/t5510-fetch.sh
  test_expect_success 'explicit fetch should not update tracking' '

which checks for the direct opposite of the behavior we are discussing. The test was added by Junio in late 2007. However, I can't seem to find any discussion on the mailing list about it. Junio, do you remember anything about this?

-Peff

On Tue, Oct 26, 2010 at 21:47, Vitaliy Semochkin <vitaliy.se@gmail.com> wrote:

The command "git log origin master" lists all commits of the branch "origin" affecting the file "master". Are you sure that is what you want? Maybe you meant:

  $ git log origin/master # the history of upstream ("origin") branch "master"

or

  $ git log origin/master.. # changes in the active branch not merged
into upstream