From: Brad Malone 
  To: git-users@googlegroups.com 
  Sent: Thursday, May 10, 2012 5:07 PM
  Subject: Re: [git-users] Re: Basic question: confusing messages with git merge


  Thomas and Antony,


  Thank you both for taking time to write such detailed responses to my 
question! Now let me get to what you both have said individually.


  Thomas,


  Thanks for the notes on rebasing. From what I understood from reading git 
tutorials before was that rebasing was something which was usually nice to do 
whenever one has local changes (for which no commits have ever been made to the 
remote branch) so that the git history looks more linear. I have planned on 
using rebasing later on when my git usage becomes more complex, but currently I 
only work on my own private repo for which I *attempt* to always update before 
making local changes. So 99% of my work simply involves updating whatever local 
computer (I work on different computers) to the work that exists on my remote, 
doing my stuff, and then committing back. I believe that this current problem 
of mine is probably more due to the fact of an accidental 'git merge origin 
master' command.


  Antony,


  I'm glad you think that this may have been the problem (since I really would 
like to understand why it happened). I had seen the octopus merge when looking 
in the documentation and online and figured that what might have been what 
happened. What I did *not* know was that this was old and no one really uses it 
anymore. Glad to know this so I don't try to incorporate it into my workflow 
(presumably there would be no need anyway or other people would use it as 
well). 


  Yes, I see empty merge commits when this sort of thing happens. I am familiar 
(although probably no expert) with tracking of remote branches. My local master 
branches are always set up to track origin/master (see 'git remote' command 
below)


    bmalone@papabear:~/repos/my_codes$ git remote show origin
    Password for 'https://gammapo...@bitbucket.org': 
    * remote origin
      Fetch URL: https://gammapo...@bitbucket.org/GammaPoint/my_codes.git
      Push  URL: https://gammapo...@bitbucket.org/GammaPoint/my_codes.git
      HEAD branch: master
      Remote branch:
        master tracked
      Local branch configured for 'git pull':
        master merges with remote master
      Local ref configured for 'git push':
        master pushes to master (local out of date)


  , and so technically I should be able to use 'git pull' and merge 
automatically. This is actually what I did when I started using git a couple 
weeks ago. However, the reason I stopped doing was twofold:


  1). I found that when I used 'git pull' that if I used 'git status' I would 
always find out that my local branch was some number of commits ahead of 
origin/master (this was in fact unrelated to me having made any local commits). 
I think the cause of this was actually that 'git pull' doesn't update my local 
copy of where origin/master is (which is what 'git fetch' does I think). I 
suppose I could use 'git fetch' followed by 'git pull', but I wasn't sure if 
that was the correct thing to do, mostly because of reason #2. Edit: Also I 
think it is true that people say that 'git pull' IS equivalent to a fetch and 
then a merge, but this never seemed to be the case for me because origin/master 
position was never updated. If I have to type in something like 'git remote 
update origin' then it seems that 'git pull' isn't saving me any typing. I hope 
I am making sense here. This problem is discussed constantly online (see 
http://stackoverflow.com/questions/4843881/updating-branches-using-git-pull and 
http://stackoverflow.com/questions/277077/why-is-git-telling-me-your-branch-is-ahead-of-origin-master-by-11-commits-a)
  but I haven't seen anyone answer it to much satisfaction.


  2). This article: http://longair.net/blog/2009/04/16/git-fetch-and-merge/ 
suggests that one should fetch and then merge rather than pull. This made me 
think that the pair fetch/merge was the best replacement for pull, and since 
pull wasn't updating the position of origin/master, I stopped using it. 


  Is this understanding I have correct?


  Thanks again,
  Brad
Brad,

One useful resource is 
http://ndpsoftware.com/git-cheatsheet.html#loc=remote_repo; (linked from 
http://git-scm.com/docs). It shows most of the different places that your data 
may be located at, and the commands between them.  

One of the areas that can confuse is the distinction between the true remote 
repository, and your local copy based on last time that particicular computer 
looked at it (e.g. upstream/master) .

Clicking on "Upstream" column will show the commands that will transfer data 
between the upstream remote, and you are using Bitbucket as your common 
reference point.  So you do need to remember to look at it i.e. 'fetch' 
immediately you start on the other computer, and at the end of the session, 
'push' your latest and greatest back to Bitbucket.

The status that reports the both "ahead xx comits" and "clean: nothing to 
commit" is because they are different comparisons. The first is between the 
upstream [1], and your last local commit, while the second is between your last 
local commit and your actual files. If you are sharing a project, your mate may 
have pushed an extra commit that you weren't aware of (or that you'd forgotten).

[1] - I think the difference is between your local copy of the remote, and your 
last local commit, rather than going to the actual remote and your last local 
commit. Without a fetch[2], you can't do the merge of the commits sourced from 
the distant repo, hence my expectation.

[2] - There has been a lot of dicussion on the main git list about an upcoming 
change about which brances are pushed by default which can suprise some, 
especially as which branches are being fetched isn't the same.

Philip


  On Thu, May 10, 2012 at 4:39 AM, Antony <antony.m...@gmail.com> wrote:

    Hi,


    On Thursday, 10 May 2012 00:49:15 UTC+1, Brad wrote:

      What do these things mean? I'd imagine that 'Merge remote-tracking branch 
origin/master' should have been what happens when I type 'git merge 
origin/master', but what about the other? Could 'Merge branch master, 
remote-tracking branch origin' be what happens if I accidentally typed "git 
merge origin master"? If I do this, what happens exactly? 

    Good guesswork! 

    One of git's merge algorithms is called an 'octopus merge', and merges more 
than two branches together. When you run 'git merge origin master', the fact 
that you named two branches (OK, 'origin' isn't a branch, but bear with me) 
causes the octopus merge algorithm to be invoked. 

    However, this algorithm is pretty old, no-one really uses it any more, and 
it's normally regarded as nothing more than a curiosity. Therefore it doesn't 
receive much love, and has some rather odd corner cases and bugs. 

    One such corner case is when one of the branches it's given to merge isn't 
a branch at all, and is instead the name of a remote. When this happens, you 
get the message you described, and some other stuff -- an empty merge commit I 
think? And I seem to recall there's another very strange oddness. 

    So, long story short, do not type 'git merge origin master'. 
    If you want an easier way to merge (with less typing) read on... 

    Do you know about git's branch tracking stuff? Basically, you can assign 
each branch an 'upstream' branch (defined in git's config). When you run 'git 
pull', git will merge in this upstream branch by default. ('git push' follows a 
different set of rules by default, although this might change. Read 
push.default in man git-config for now). 

    When a branch has an upstream configured, '@{upstream}', or '@{u}' points 
to that upstream branch. You can also see whether a branch has an upstream by 
typing 'git branch -vv' -- the upstream appears in square brackets. 

    So, to configure an upstream (if you don't have one set already), use 'git 
branch --set-upstream master origin/master', or 'git push -u origin master' if 
you want to push at the same time. 
    Having done this, you can type 'git merge @{u}' (with master checked out) 
to merge origin/master into master. 

    Hope that cleared up some confusion. 

    Antony 


    -- 
    You received this message because you are subscribed to the Google Groups 
"Git for human beings" group.

    To view this discussion on the web visit 
https://groups.google.com/d/msg/git-users/-/y9PMXsscTQgJ.

    To post to this group, send email to git-users@googlegroups.com.
    To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
    For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.




  -- 
  You received this message because you are subscribed to the Google Groups 
"Git for human beings" group.
  To post to this group, send email to git-users@googlegroups.com.
  To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
  For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

  No virus found in this message.
  Checked by AVG - www.avg.com
  Version: 2012.0.1913 / Virus Database: 2425/4989 - Release Date: 05/10/12

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Reply via email to