Re: Stupid git!

[Dmitry Gutov]

On 09/12/2015 03:29 PM, Alan Mackenzie wrote:

> Sorry, I got confused.  I thought I'd only half-committed the change
> (with `git add'), whereas I had in fact fully committed it.

Then you were simply doing a merge, which is the second step of 'git 
pull' ('git fetch' + 'git merge').

> It's when first doing `git add', then `git pull' when I've lost changes
> before.

Is this about some other, older situation?

> > The fact that git allows pulling after 'git add' sounds like a bug to
> > me, but apparently it sort-of fine because you can do two-way merge, or
> > even abort the merge and return to the previous state.
>
> I've always done a final `git pull' before committing in the past, so as
> to avoid merges as far as possible.  This is what has lost me changes.

That's inadvisable: one is most likely to lose changed by not committing 
them.

Committing before pull is the Git Way.

'git pull --rebase' can also be used if you want cleaner history, but 
judiciously: if you're absolutely sure that none of the new commits on 
the current branch have ever been published (pushed to the remote). So 
don't rebase if you've done any merges, just accept the default behavior 
of 'git pull'.

> > Was there a conflict in this file, or not? If yes, you can see the
> > diverging changes. If not, then you don't need to merge it at all, just
> > resolve the conflicts.
>
> There were no conflicts, just the other contributer's changes that my
> `git pull' had pulled.

Then you didn't need to open it, just needed to resolve any remaining 
conflicts (in other files), then type 'git commit'.

> > How were you even "dumped into an editing session"? What tool did that?
>
> git did, on my `git pull'.

I'm pretty sure Git launches $EDITOR only when asking the user for the 
commit message.

> I think I can see what happened now - when
> there's a pending push already committed, git refuses to merge in even
> unrelated changes.

That's implausible. If you could write a sample scenario step by step 
using two local repos, one close of another, we'll discuss this further.

> Instead it merged the file in my working directory,
> leaving me to commit it.  I'm not sure why.

Maybe you have '--no-commit' somewhere in your .gitconfig.

> It's not easy at all - I've got the collected edition of git man pages
> in an info file.  The one for git diff is 1036 lines long.

Why don't you check out the original man page, too? Do you have it 
installed?

> I tried
> searching for "index" and "staging", to no avail - I think I stopped the
> search after getting beyond the OPTIONS section.  Now that I know that
> "--cached" is the answer, that is specified in the EXAMPLES section.
> "--staged" doesn't appear at all.

In my git-diff man page (that comes with Git 2.1.0), the examples 
section is at the top (it's called DESCRIPTION). The third paragraph 
both includes the words "staged changes" and "--staged":

   git diff [--options] --cached [<commit>] [--] [<path>...]
     This form is to view the changes you staged for the next commit
     relative to the named <commit>. Typically you would want comparison
     with the latest commit, so if you do not give <commit>, it defaults
     to HEAD. If HEAD does not exist (e.g. unborn branches) and <commit>
     is not given, it shows all staged changes. --staged is a synonym of
     --cached.