From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Artur Malabarba Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master f9fabb2 2/2: Merge branch 'master' of git.sv.gnu.org:/srv/git/emacs Date: Thu, 28 May 2015 17:24:30 +0100 Message-ID: References: <20150527165006.32357.80915@vcs.savannah.gnu.org> <87egm13yrm.fsf@gmx.de> <838uc8yd3c.fsf@gnu.org> Reply-To: bruce.connor.am@gmail.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c3875050d44d051726cb26 X-Trace: ger.gmane.org 1432830342 22094 80.91.229.3 (28 May 2015 16:25:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 May 2015 16:25:42 +0000 (UTC) Cc: Michael Albinus , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 28 18:25:35 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Yy0cc-0007o2-2W for ged-emacs-devel@m.gmane.org; Thu, 28 May 2015 18:25:30 +0200 Original-Received: from localhost ([::1]:59945 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy0cb-0003HQ-7A for ged-emacs-devel@m.gmane.org; Thu, 28 May 2015 12:25:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34411) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy0bj-0001yG-80 for emacs-devel@gnu.org; Thu, 28 May 2015 12:24:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Yy0bh-0007rT-Om for emacs-devel@gnu.org; Thu, 28 May 2015 12:24:35 -0400 Original-Received: from mail-la0-x22d.google.com ([2a00:1450:4010:c03::22d]:33894) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Yy0bf-0007qn-IY; Thu, 28 May 2015 12:24:31 -0400 Original-Received: by laat2 with SMTP id t2so36095930laa.1; Thu, 28 May 2015 09:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kQg1eJxLDsL0f8dHlk9UehxcpxjiGnLIUCoeWJ1fYjQ=; b=rpSoPigM2F0cHkIdGZN/0JyEJgRXkj5z2Qp/MMVHjFUqjRhvuQQoJO6kUJxoKYyCzB nM1fRIzAE4i6cmHKLm01hCzPZtebJ44B//UrdoYGPqKGrBM9xpdO1PzCfSjbtcFNFONW TMor1clgIdZpPhi75pGIrG6hx0DlYC2mxTvZPPGTGBk9kP4bG7Ynkfqtsd0bZg8OtV+6 VO4qKIzQa2M0vtL9jkg5LyI5b/F3KvAdFevDafm+o1To/Dp6GWXBq41xl+bhz63Gxsc3 P+0ZZrq3cweaDqRJtt461GBPGuSLZ65THVI3HweVauxAWB6UwLg1+FdU+wuYhmxJSk3N AsiA== X-Received: by 10.112.200.230 with SMTP id jv6mr3670367lbc.21.1432830270819; Thu, 28 May 2015 09:24:30 -0700 (PDT) Original-Received: by 10.25.150.1 with HTTP; Thu, 28 May 2015 09:24:30 -0700 (PDT) In-Reply-To: <838uc8yd3c.fsf@gnu.org> X-Google-Sender-Auth: 5e_w4qqRRWNouV3RnX3NV0mvUGU X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::22d X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186919 Archived-At: --001a11c3875050d44d051726cb26 Content-Type: text/plain; charset=UTF-8 >> As a general tip. Next time you try to pull and find out someone >> already has already done what you just did, don't resolve the merge >> conflict. Instead, abort the merge with git merge --abort (this will >> get you back to the state you had right before the pull), and then >> locally revert your commit. > > I don't see how this advice will be able to keep Michael out of > trouble next time. AFAICT, it will just get him in a different > situation, one that isn't simpler or safer to deal with. Locally > reverting commits risks losing them, for example. Yes, that was the point. If I wrote a commit to fix something that's already fixed, that commit is now useless, so I discard it. The reason I prefer that instead of merging is that it's just easier and simpler that way (at least to me), mainly because: 1. Reverting a commit only affects code I've just written, so it takes very little mental energy. I know what I'm changing with 100% certainty. 2. Resolving a merge conflict involves both mine and someone else's code, so I'll need to invest some energy to read and interpret that code (might be a little or a lot, depending on the code). 3. Even after I've read and interpreted the new remote code, there's always a small chance I miss some tiny detail inside a large diff when resolving the conflict. (I've introduced bugs this way a couple of times, whereas I've never introduced a bug while reverting). 4. Even when the conflict is simple and I know I can solve it without risk, doing the merge will still keep redundant commits in the history. It's not a huge deal, but there's no reason to have two commits doing the exact same thing. I'm not saying merge conflicts are the devil, or that they're any reason to panick. But if I can prevent the conflict by killing a redundant commit, then that is easier, safer, and cleaner. However, you're right that a person who is not very familiar with git is better off not mucking around with things like reset, revert, and rebase. OTOH, you can always just create a branch wherever you are and use that as a backup. When I was first learning git, that was the first thing I did everytime I panicked, and it never failed me. > OTOH, merge conflicts are nothing to be afraid of, the procedure to > handle them is simple and straightforward. Michael (and every one > else here) should IMO master that simple procedure, instead of > avoiding it. > > In a dVCS, you cannot rely on being able to avoid merges all the time > anyway. There are always races with other developers. Agreed. Merge conflicts are just part of the deal. I was just explaining how I avoid one specific type of conflict. --001a11c3875050d44d051726cb26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

>> As a general tip. Next time you try to pull an= d find out someone
>> already has already done what you just did, don't resolve the = merge
>> conflict. Instead, abort the merge with git merge --abort (this will
>> get you back to the state you had right before the pull), and then=
>> locally revert your commit.
>
> I don't see how this advice will be able to keep Michael out of > trouble next time.=C2=A0 AFAICT, it will just get him in a different <= br> > situation, one that isn't simpler or safer to deal with.=C2=A0 Loc= ally
> reverting commits risks losing them, for example.

Yes, that was the point. If I wrote a commit to fix something that's= already fixed, that commit is now useless, so I discard it.

The reason I prefer that instead of merging is that it's just easier= and simpler that way (at least to me), mainly because:

1. Reverting a commit only affects code I've just written, so it t= akes very little mental energy. I know what I'm changing with 100% cert= ainty.
2. Resolving a merge conflict involves both mine and someone else= 's code, so I'll need to invest some energy to read and interpret t= hat code (might be a little or a lot, depending on the code).
3. Even af= ter I've read and interpreted the new remote code, there's always a= small chance I miss some tiny detail inside a large diff when resolving th= e conflict. (I've introduced bugs this way a couple of times, whereas I= 've never introduced a bug while reverting).
4. Even when the confli= ct is simple and I know I can solve it without risk, doing the merge will s= till keep redundant commits in the history. It's not a huge deal, but t= here's no reason to have two commits doing the exact same thing.

I'm not saying merge conflicts are the devil, or that they're an= y reason to panick. But if I can prevent the conflict by killing a redundan= t commit, then that is easier, safer, and cleaner.

However, you're right that a person who is not very familiar with gi= t is better off not mucking around with things like reset, revert, and reba= se. OTOH, you can always just create a branch wherever you are and use that= as a backup. When I was first learning git, that was the first thing I did= everytime I panicked, and it never failed me.

> OTOH, merge conflicts are nothing to be afraid of, the procedure to=
> handle them is simple and straightforward.=C2=A0 Michael (and every on= e
> else here) should IMO master that simple procedure, instead of
> avoiding it.
>
> In a dVCS, you cannot rely on being able to avoid merges all the time =
> anyway.=C2=A0 There are always races with other developers.

Agreed. Merge conflicts are just part of the deal. I was just explaining= how I avoid one specific type of conflict.

--001a11c3875050d44d051726cb26--