git merge/pull/rebase (was Re: [csmith-project/csmith] cef528: More paths wrong...)

[Eric Eide <eeide@cs.utah.edu>]

	John> Would this have been avoided if I had not forgotten to do a "git
	John> pull" before the "git commit"?

Sometimes that does help, yes.

My original message said "No, that wouldn't have changed things," but while
writing this email I did some experiments, and in fact sometimes it did work.

Git is happy to pull and do a fast-forward merge if doing so won't wipe our
your local work.  I thought that git would refuse to pull in this case, but I
just learned that was not the case.

But note this bit of the "git-pull" man page:

	Warning: In older versions of git, running git pull with uncommitted
	changes is discouraged: while possible, it leaves you in a state that
	may be hard to back out of in the case of a conflict.

	If any of the remote changes overlap with local uncommitted changes,
	the merge will be automatically cancelled and the work tree untouched.
	It is generally best to get any local changes in working order before
	pulling or stash them away with git-stash(1).

All that said, it is still useful to know "git rebase", so that you can avoid
merges even after you have committed to your local repository.

Eric.

-----

PS --- Since I wrote the following before rewriting the first part of this
email :-), I'll include it for anyone who might be wondering where these merges
are coming from.  They are made automatically by "git pull" when the current
local tracking branch (commonly, "master") has diverged from the tracked remote
branch (typically, "origin/master").

Here's the scenario:

	# Assume up-to-date local repo at start.

	# Work work work, add to-do.
	[zin:~/csmith] eeide% git add TODO
	[zin:~/csmith] eeide% git commit TODO -m "Added another to-do item."

	# The above commit will always work, because you are committing to your
	# local repo.  Now suppose that you want to push to GitHub (what git
	# calls our project's "origin"), but while you were working, somebody
	# else pushed something.

	[zin:~/csmith] eeide% git push
	To ...
	 ! [rejected]        master -> master (non-fast-forward)
	error: failed to push some refs to '...'
	To prevent you from losing history, non-fast-forward updates were
	rejected Merge the remote changes (e.g. 'git pull') before pushing
	again.  See the 'Note about fast-forwards' section of 'git push --help'
	for details.

	# But you are clever...

	[zin:~/tmp/yyy/csmith2] eeide% git pull
	remote: Counting objects: 5, done.
	...
	   672b340..3ca3915  master -> origin/master
	Merge made by recursive.
	 other-file |    2 ++
	 1 files changed, 2 insertions(+), 0 deletions(-)

	# Note that the "git pull" command made a merge commit ("merge by
	# recursive"), which you can now push up along with your actual
	# changes.

	[zin:~/csmith] eeide% git push
	Counting objects: 8, done.
	...
	   3ca3915..4f4ed49  master -> master

	# See the merge commit.

	[zin:~/csmith] git log --oneline --graph -n 4

One can avoid these little history branches in simple cases by doing "git pull"
before making a commit.  But more generally, it is good to know "git rebase" so
that you can avoid unwanted branches that would otherwise occur after you have
made a commit, but before you have pushed it to another repository (e.g.,
GitHub).

-- 
-------------------------------------------------------------------------------
Eric Eide <eeide@cs.utah.edu>  .         University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX