emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stupid git!


From: Dmitry Gutov
Subject: Re: Stupid git!
Date: Sat, 12 Sep 2015 23:14:03 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]