I just pulled, and git log --graph does not show all

Hi

I am confused, I just pulled
but git log --graph --decorate
did not show all commits,

Only

git log --graph --decorate --all

and from the emails I received the commits shown by --all

Should be on a new branch.

I confess I am a mercurial user not a git user,

What is the reason for this behavior.

How can I now merge the new branch into master?

Thanks

Uwe Brauer

I hear you: I had a brief encounter with Mercurial not that long ago, and there were several things that didn't work the way I expected (or
rather: the way I got used to with Git). The subtle and sometimes not-so-subtle differences between the concepts and philosophy of the two systems might very well explain why Git didn't work the way you expected.

However, it's impossible to give any explanation or advice without knowing more about the situation, e.g. at least the exact commands that you run and what they outputted, if you still have them or at least if you can still reproduce the issue. (with potentially sensitive URLs and/or branchnames redacted, if necessary).

Thanks for your answer.

Could you please try out
git clone https://git.code.sf.net/p/matlab-emacs/src matlab-emacs-hg

Then you will see

That
git log --graph
and

git log --graph --all

Are giving two different results and I don't understand why the branch is not shown when using

git log --graph

Funny thing is when I use the hg-git plugin and run

hg clone https://git.code.sf.net/p/matlab-emacs/src matlab-emacs-hg

I see this branch, converted to a hg bookmark.

"git log --graph" has an implicit "HEAD" added on the end, to say "start walking from my current commit". The "--all" says "walk from all refs", so the set of commits to walk is larger.

"git log" defaults to showing history from your current position in history, so you can look at the recent commits that you have created or what changes led to your current state. Adding the "--all" gives you a higher-level view of the repository, but can be very noisy when trying to discover what has happened for your current state.

In particular, say you are trying to dig into a bug in Git 2.23.0. A "git checkout v2.23.0" will change your HEAD to be at the commit used to build that version. You can use "git log" to view the history leading to that release, and see if you can determine recent changes that would have caused a regression. If you use "git log --all", then the commits in the "master" branch will appear before your current HEAD, and you'll be looking at commits that "haven't happened yet" according to your current place in history.

I hope this helps.

-Stolee

This repository contains two branches: 'master' and 'strings'. From these two 'master' is the default branch, so that is that 'git clone' will check out for you; note the '*' in front of 'master':

  $ git branch --all
  * master
    remotes/origin/HEAD -> origin/master
    remotes/origin/master
    remotes/origin/strings

Without any ref parameter 'git log' shows the history starting at the currently checked out commit (in this respect it behaves the same way as 'hg log'), so it only shows the history of 'master'. 'git log --all' means "show the history of all refs in the repository", so it shows the history of the remote branch 'strings' as well.

As far as I can tell all Git commands above behave as they should.

For some reason after cloning that repository with Mercurial and its hg-git plugin it checks out the 'strings' branch:

  $ hg bookmarks 
     master                    170:6c03da83e522
   * strings                   195:b2396f3ceca3

Consequently, when you run 'hg log' without a branch/bookmark/whatever parameter it shows the history of the 'strings' branch.

I'm not sure what to think about 'hg clone' checking out a branch other than the default branch. In Git this would definitely be a bug. In Mercurial, I don't know; given my limited experience I don't want to outright call it a bug. I think it would be worth reporting it to the 'hg-git' project.

Anyway, in your first email you asked how you can merge that branch into 'master'. The command 'git merge origin/strings' will "merge" it without actually creating a merge commit, because 'strings' builds entirely on top of 'master'; this is what Git calls a "fast-forward merge". If you do want a merge commit, then run 'git merge --no-ff origin/strings'.

Ok hg does the same, so I see the difference is in the git log --graph command.

This is the difference, hg log -G always show all the commit starting with tip (basically the same as HEAD), the behavior you described would be

  hg log -G --follow

No I think the point is not the checkout the point is the hg log -G command.

I am now not so sure that really the strings branch/bookmark was checked out I rather think not.

As this is what I was looking for. I actually don't like fast forward, so I would use the --no-ff option.

That was very helpful, thanks

Uwe

Interestingly enough it is impossible in mercurial to have a (not ff) merge in mercurial in this situation, because you have only one head (linear history) and two bookmarks. That is one thing I dislike in mercurial, but it can be easily avoided by using named branches or topics, but any way this is off topic.