[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Stupid git!
Re: Stupid git!
Sat, 12 Sep 2015 12:29:00 +0000
On Sat, Sep 12, 2015 at 01:40:03PM +0300, Dmitry Gutov wrote:
> 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.
Sorry, I got confused. I thought I'd only half-committed the change
(with `git add'), whereas I had in fact fully committed it.
> But in general, you either 'git stage' and then 'git pull', or 'git
> add', 'git commit' (!), and then either rebase or merge upstream.
It's when first doing `git add', then `git pull' when I've lost changes
> 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.
> > 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.
There were no conflicts, just the other contributer's changes that my
`git pull' had pulled.
> How were you even "dumped into an editing session"? What tool did that?
git did, on my `git pull'. I think I can see what happened now - when
there's a pending push already committed, git refuses to merge in even
unrelated changes. Instead it merged the file in my working directory,
leaving me to commit it. I'm not sure why.
> > 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.
That was my mistake: the commit had already been fully committed, not
just half committed like I'd thought.
> > 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.
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. 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.
Anyhow, I used --staged to look at the file. Thanks!
Alan Mackenzie (Nuremberg, Germany).