git pull conflict question

[Paul Johnson]

Today my GRA added some stuff in git and I ran git pull. Up pops vi
asking me to explain what I did to cause a merge to happen. I gave the
reason that I ran git pull, then this

$ git pull
remote: Counting objects: 10, done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 8 (delta 2), reused 0 (delta 0)
Unpacking objects: 100% (8/8), done.
From ssh://hpc.acf.ku.edu/crmda/projects/git/workshops
e3cbf32..d1410da master -> origin/master
Merge made by the 'recursive' strategy.
topics/simulation-montecarlo/R/montecarlo-01.R | 397
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
topics/simulation-montecarlo/presentation/montecarlo-1.pptx | Bin 0 ->
68217 bytes
2 files changed, 397 insertions(+)
create mode 100644 topics/simulation-montecarlo/R/montecarlo-01.R
create mode 100644
topics/simulation-montecarlo/presentation/montecarlo-1.pptx


After this, all seems well. Yes? If it was wrong, how would I know?

If this were SVN, I would understand what to do. There would be >> and
<< all over some files where changes were blended. I don't find any
such noise in the files mentioned.

Noticing no problem, I tested to see what happens

$ git push
Counting objects: 6, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 657 bytes | 0 bytes/s, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://paul...@hpc.acf.ku.edu/crmda/projects/git/workshops
d1410da..1ba792d master -> master

$ git pull
Already up-to-date.

How can you help.

1. Help me understand what the merge message means.

2. Tell me if the advice here is correct:

https://www.lullabot.com/blog/article/handling-git-pull-automatic-merges

That says never run git pull, but rather

$ git pull --ff-only


By the way, same site recommends embellishment of git log. This one is
color coded

$ git log --all --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s'
* 1ba792d - (HEAD, master) I ran git pull at 12:39.
|\
| * d1410da - (origin/master, origin/HEAD) Added the monte carlo
presentation and R files
* | 5476005 - distributions readme empty
|/
* e3cbf32 - calculus
* 621b210 - incorporate probability content
* d8700e0 - Pascal's files
* c52bb1b - 3 empty files to make git acknowledge the directories
* 1d73fb6 - Imported from SI2014
* e35a2b5 - Imported from SI2014
* 3fbc52c - Transferred BS's 2014 lecture materials
* d09e9d7 - imported the functions lecture from 2014, revised it so it
can compile in lyx 2.1 without any special configuration. Added the pdf
output to the repo.
* 0a88f5e - The first commit!
* 495cc86 - Removed README.txt.
* 2c4a297 - Added README.txt.
--
Paul E. Johnson University of Kansas
Professor Director, Center for Research
Political Science Methods & Data Analysis
http://pj.freefaculty.org http://crmda.ku.edu
paul...@ku.edu
1541 Lilac Lane 1425 Jayhawk Blvd.
Blake Hall, Rm. 504 Watson Library, Rm. 470
Lawrence, Kansas Lawrence, Kansas
66045-3129 66045-0001
Ph: (785) 864-3353

[Jim Ford]

Hey, a question on here I can answer!

See my (admittedly wordy) responses below (marked with <JF></JF>). :)

Jim

<JF> This means that when you did the 'git pull' (functionally a git fetch followed by a git merge) a merge was required. Recursive strategy is git's default merge strategy, details of which you can read with 'man git-merge' if interested in the implementation specifics.

The great news is that git was able to automatically resolve all conflicts! Depending on what language this is in (looks like R from the file names) and whether or not you can execute the affected code/tests and everything passes, git probably did the right thing. Though syntactically correct is not always semantically correct, so be sure to run regression tests before pushing this to your remote origin/master (whoops just re-read and see that you already pushed this branch…oh well).

If there were manual merge conflicts requiring your intervention, then the merge would have stopped after finding all conflicts and prompted you to make changes to resolve said conflicts. The merge markers are very similar to your experiences in SVN. </JF>

2. Tell me if the advice here is correct:

https://www.lullabot.com/blog/article/handling-git-pull-automatic-merges

That says never run git pull, but rather

$ git pull --ff-only

<JF> This is probably someone that has been burned when trying to update to latest from their remote master. Essentially what the --ff-only means is only perform a merge if it can be a fast-forward, meaning that there are no commits in the local tree that aren't in the remote tree (see man git-merge).

A successful strategy for me is to keep all work in topic branches and remote backed branches (e.g. origin/master) are left purely for the purposes of getting latest code for things like 'git rebase'.

You will have to find a strategy that works for you, but this advice is geared toward people that are wanting to prevent from accidentally performing merges without realizing it is happening. Take it or leave it IMHO. </JF>

By the way, same site recommends embellishment of git log. This one is
color coded

<JF> Meh, that seems like an awful lot to type out to me, either alias it or turn on colors for git repos, 'git config --global color.ui true' will turn them on for all the git repos on your system (options are set in user home dir, provided you are on some flavor of *nix). </JF> 

$ git log --all --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s'
*   1ba792d - (HEAD, master) I ran git pull at 12:39.
|\

<JF> I know you didn't really ask about this, but I thought I would point out that you had some work in here that wasn't pushed to the origin remote repo (5476005), hence the merge on 'git pull'.

If you wanted to preserve the format of the origin/master branch, then you should have done a 'git rebase' instead of a git pull. This  would put your local commit on top of what looks like the remote origin/master branch.

FYI, I require my users to do this, but it is an organizational decision to do rebase or merge.

To get that state, then you can do this, but this is purely academic as you have already pushed to the remote and changing that now could make things more confusing:

git checkout -b distributions 5476005 # checkout a topic branch named distributions and set it to commit hash 5476005

git checkout master # checkout local master

git reset --hard origin/master # reset local master to local origin/master

git pull # this should happen with no merge and get your GRAs work in to local master and origin/master

git checkout distributions # switch back to topic branch

git rebase master # rebase topic branch to local master

Depending on whether your GRA has done additional work on his local repo, your git push might cause them to need to do some similar acrobatics…or they can just merge and push away and not really care what history looks like. :)

</JF>

| * d1410da - (origin/master, origin/HEAD) Added the monte carlo
presentation and R files
* | 5476005 - distributions readme empty
|/
* e3cbf32 - calculus
* 621b210 - incorporate probability content
* d8700e0 - Pascal's files
* c52bb1b - 3 empty files to make git acknowledge the directories
* 1d73fb6 - Imported from SI2014
* e35a2b5 - Imported from SI2014
* 3fbc52c - Transferred BS's 2014 lecture materials
* d09e9d7 - imported the functions lecture from 2014, revised it so it
can compile in lyx 2.1 without any special configuration. Added the pdf
output to the repo.

* 0a88f5e - The first commit! <JF> Ha, nice. I like that the third commit is tagged as the first commit! </JF>

* 495cc86 - Removed README.txt.
* 2c4a297 - Added README.txt.

--
Paul E. Johnson                 University of Kansas
Professor                       Director, Center for Research
Political Science               Methods & Data Analysis
http://pj.freefaculty.org       http://crmda.ku.edu
                                paul...@ku.edu
1541 Lilac Lane                 1425 Jayhawk Blvd.
Blake Hall, Rm. 504             Watson Library, Rm. 470
Lawrence, Kansas                Lawrence, Kansas
66045-3129                      66045-0001
                                Ph: (785) 864-3353

--
You received this message because you are subscribed to the Google Groups "kulua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kulua-l+u...@googlegroups.com.
To post to this group, send email to kul...@googlegroups.com.
Visit this group at http://groups.google.com/group/kulua-l.
For more options, visit https://groups.google.com/d/optout.