emacs-devel
[Top][All Lists]
Advanced

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

Re: Understanding a recent commit in emacs-25 branch [ed19f2]


From: Alan Mackenzie
Subject: Re: Understanding a recent commit in emacs-25 branch [ed19f2]
Date: Sun, 3 Apr 2016 12:14:58 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Ingo.

On Sun, Apr 03, 2016 at 01:40:10PM +0200, Ingo Lohmar wrote:
> Hi Alan,

> On Sun, Apr 03 2016 11:17 (+0000), Alan Mackenzie wrote:

> > That massive commit happened because of git.  I attempted a 'git pull'
> > prior to making a (moderately small) commit.  There was a one-letter
> > typo in one of my existing files (which I think had been committed).
> > Because of that, git failed to merge in all the stuff which it had just
> > fetched from savannah, instead prompting me to do a manual merge, which
> > I then did.

> I think 'git pull' has been discussed on this list before.  Others feel
> differently about this issue, but I strongly advise anyone against using
> 'git pull', and instead suggest you do 'git fetch' (maybe --all).

> *After* seeing what has happened to the remote branches, you can decide
> whether a merge or a rebase is in order.  Or you spot an unwanted
> discrepancy, and can fix it, instead of git telling you to manually
> merge (although admittedly I do not quite follow that part).

Is there a way of asking "if I attempt git merge, will there be any
conflicts?"?  It would be nice to find this out before one's working
directory gets lots of uncommitted changes.

Is there a way of recovering after doing git pull, when git has already
written all the pulled changes to the working directory?  Is there some
way of saying git undo-partial-pull, leaving the working directory as it
was before the pull, and cancelling the merge which git has started?

> > It would also be nice if such "pseudo merges" could be handled locally,
> > rather than being pushed back to the remote repository, causing
> > confusion.

> Please note that *all* commits and merges happen locally.  The user can
> only push changes back to the remote by an explicit action, with all
> intended and unintended effects.

Sorry, I wasn't very clear.  What I meant was, is there a way of
finishing the merge locally, then pushing real changes without the
confusing "pseudo-merge" escaping upstream with them?

When I did git pull, there were, let's say, 20 commits.  19 of these
could have been moved directly into my local repository; only one had a
conflict.  It would be nice to be able to fix the local repo, so that
the "pseudo-merge" of these 19 blameless commits remains a purely local
affair, and doesn't get pushed upstream.

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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