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 13:40:03 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

On 09/12/2015 01:15 PM, Alan Mackenzie wrote:

Having "staged" a change with `git add', I then tried to commit it with
`git commit'.  Somebody else had got in before me, so I had to pull
their changes first - fair enough.

I don't get it. This sounds like the commit failed because someone has pushed to master in the upstream repo first. Which obviously can't happen because git doesn't have "bound branches" a la Bazaar.

But in general, you either 'git stage' and then 'git pull', or 'git add', 'git commit' (!), and then either rebase or merge upstream.

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.

So I did `git pull'.  I was then dumped into an editing session for a
merge operation for .../test/automated/file-notify-tests.el.  Eh?  I've
never touched this file in my life, and didn't even know it existed.  So
why is a merge necessary/why has a merge been (half-)done?  Why didn't
git pull simply merge the changes to this file into my repository and
working directory?

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.

How were you even "dumped into an editing session"? What tool did that?

So I aborted this merge operation, in order to see what it's doing
first.  git has kindly discarded my (staged) change, leaving no record
of its existence - good job I've still got a copy of the changed file in
Emacs.

That might be a good subject for a bug report.

How do I see what changes are in file-notify-tests.el, which is in the
staging area?  I would have thought some variety of `git diff' ought to
do the trick, but how to do this is not made obvious in the fine manual
for `git diff'.

git diff --cached (or --staged, it's a synonym)

It's pretty easy to find out in the output of 'man git diff' on my system. Not sure what manual you've been reading.



reply via email to

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