Re: git newbie problems

Graham Percival [off-list ref] writes:

Trying really trivial in-index merge...
Documentation/user/advanced-notation.itely: needs merge
fatal: you need to resolve your current index first

You got from a "git pull", which means you were already in
another merge (perhaps failed).  That is a no-no.

The error messages need to be cleaned up and be more helpful.
There is no question about it.

Nope.
Merging HEAD with c21d3f3e1c77722e50d994763442e6f994b03ac2
Merging:
038b7fc Misc small updates (trying to make git work).
c21d3f3 Merge branch 'master' of
ssh+git://hanwen@git.sv.gnu.org/srv/git/lilypond
found 1 common ancestor(s):
84219bb don't have input/templates/ any longer.
fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
No merge strategy handled the merge.

So the question is what you did _before_ initiating this "git pull".

For new people, we recommend to:

 * make sure you were on a right branch (I think you are.  You
   are on your 'master' branch and may not even have any other
   branches, which is fine.)

 * make sure all your changes are committed.

before initiating a "git pull".  And after a conflicted "git
pull", if you choose to punt,

	$ git reset --hard

would take you back to the state before you started the pull.

SUGGESTIONS

The "tutorial introduction to git" looks like a nice document, but it
assumes that you are in control of the project.  For users who aren't in
control (ie me) this is a problem, because it starts me skimming.
"Importing a project"... nah, that's not me.  "Merging branches"... I
don't care; I'm going to shove everything into the main branch.  "Using
git for collaboration"... hmm, maybe this is the stuff I need to read.
But by this point, I've already skimmed through five screens of info, so
I'm not reading very carefully.

Yes, git caters to too many classes of people.

I've heard people talk about "everyday" document as a good
table-of-contents, primarily because it first breaks down the
userbase into roles and talks about common commands for each
role of the user.  I am not in the position to judge the quality
of the document, though.

On Tue, 5 Dec 2006, Junio C Hamano wrote:

For new people, we recommend to:

 * make sure you were on a right branch (I think you are.  You
   are on your 'master' branch and may not even have any other
   branches, which is fine.)

 * make sure all your changes are committed.

before initiating a "git pull".  And after a conflicted "git
pull", if you choose to punt,

	$ git reset --hard

would take you back to the state before you started the pull.

If there are uncommitted changes, and there are conflicts, shouldn't it 
leave you in the state before the pull, especially if the uncommitted 
changes conflict with the merge? Git has determined that it can't present 
all of the conflicts to the user, so the user can't possibly resolve all 
of the conflicts, except by discarding new work or pushing it into the 
merge inappropriately. 

I think that a lot of new users will pull with uncommitted changes, and 
they'd benefit from just being told that you're supposed to commit first 
and then merge. It should definitely roll back perfectly to the state 
before the pull if it wasn't able to present all the conflicts, since even 
somebody who knows what's going on is going to have to roll back here.

Possibly there should even be an option (defaulting to true) which 
completely blocks "pull" with uncommitted changes. Even if the in-index 
merge works (and the working directory is entirely unneeded), it's pretty 
likely that the user would do better to be in the habit of doing it in the 
other order anyway.

	-Daniel