From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 123119 invoked by alias); 30 Mar 2018 22:39:04 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 123105 invoked by uid 89); 30 Mar 2018 22:39:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=counting X-HELO: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Mar 2018 22:39:02 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w2UMTcbm130974; Fri, 30 Mar 2018 22:38:53 GMT Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2h1x2t00rr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Mar 2018 22:38:53 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w2UMcrYj006329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 30 Mar 2018 22:38:53 GMT Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w2UMcqnI010468; Fri, 30 Mar 2018 22:38:53 GMT Received: from [10.132.96.98] (/10.132.96.98) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 30 Mar 2018 15:38:52 -0700 Subject: Re: [PATCH5 PR gdb/16959] gdb hangs in infinite recursion To: Simon Marchi Cc: gdb-patches@sourceware.org References: <1522269884-129860-1-git-send-email-weimin.pan@oracle.com> <20cf4b23322670e4dc513183ef2dda45@polymtl.ca> <96ab9fda-2c03-a9c6-1da9-70e807e69e5c@oracle.com> <3505af0b-d303-b556-0a4c-c416ac88a064@polymtl.ca> From: Weimin Pan Message-ID: <337f2b1f-6fe8-07f3-f4cd-a9b5a3d5456d@oracle.com> Date: Fri, 30 Mar 2018 22:39:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <3505af0b-d303-b556-0a4c-c416ac88a064@polymtl.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8848 signatures=668697 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1803300222 X-SW-Source: 2018-03/txt/msg00626.txt.bz2 On 3/30/2018 3:04 PM, Simon Marchi wrote: > On 2018-03-30 05:43 PM, Weimin Pan wrote: >> Hi Simon, >> >> I just got started to work on this. Here is what I've done (I followed >> your lead to creat a different remote name): >> >> % git add >> % git commit -a >> % git remote add upstream ssh://sourceware.org/git/binutils-gdb.git >> % git fetch upstream >> >> I have a few questions: >> >>  * Do I need to do a "git merge" after "git fetch"? Or can I just >>    do "git pull" which is equivalent to "git fetch;git merge"? >>    (I was a Mercurial(hg) user, its typical workflow is like: >>     hg in; do work; hg commit; hg pull; hg rebase(if needed); hg push) > There are two different approaches to bringing the commits from upstream into the > branch where you did some work, rebase and merge (they probably exist in mercurial > too, maybe some other name). Many projects (including us) never use merging, > because it leads to a non-linear history, which is more difficult to follow and > bisect. > > To keep it simple, if you have some commits of yours on master and want to "update" > to get the new stuff from the official repo, I suggest doing "git pull --rebase", > which is the same as "git fetch; git rebase". It will basically try to apply your > commits on top of the "official" master branch. You may need to handle any conflicts, > I suggest looking on the web, there are plenty of tutorials for that. Yes, there are indeed many tutorials out there and I've been reading some of them to learn more about git :) >>  * In your previous email, you said: >> >>    Make sure you inserted the ChangeLog entries in the actual ChangeLog >> files >>    and amended your commit >> >>    It seems the "git commit -a" command will contain all the changes, >> including >>    those in ChangeLog files. Why do I have to insert the entries? > As you can see on the mailing list (though there are some variations), we usually > put the ChangeLog entry as part of the commit message when posting the patch to > the list. I think the historical reason for that is that otherwise, rebasing your > patches always gives some conflicts in the ChangeLog files*. Therefore, when comes > the time to push the patch to the upstream repo, we must not forget to actually > insert the ChangeLog entry at the top of the right ChangeLog file, and modify the > commit to contain that change. This can be done with > > $ ... copy ChangeLog entry to ChangeLog file ... > $ git add ChangeLog > $ git commit --amend > > The last command will modify the currently checked out commit with the stage changes. Thanks for the tips.  But I checked the ChangeLog files which seem to contains the entries. > * You can use this to mitigate the conflicts in ChangeLogs though: > http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c > > I personally avoid using "git commit -a", as it's easy to add unwanted changes. You > can try "git add -p" (with or without specifying a filename afteR). For each modified > hunk, it will ask you if you want to add it to the staged changes (what's about to be > committed). It's then easier to spot unintended changes. Yes, it looks like "git add -p" is better than "commit -a" which our group was told to use. >>  * Changing the commit title to be be more descriptive: >> >>    So I need to use "git commit --amend" to change the title? > Exactly, "git commit --amend" will allow you to change the commit message, including > the title (the first line). I just did my first patch: $ git push upstream fixes Enter passphrase for key '/home/wepan/.ssh/id_rsa': Counting objects: 17, done. Delta compression using up to 8 threads. Compressing objects: 100% (10/10), done. Writing objects: 100% (10/10), 2.43 KiB, done. Total 10 (delta 8), reused 0 (delta 0) To ssh://sourceware.org/git/binutils-gdb.git    0f59d5f..c9cf730  fixes -> fixes and hope I did it correctly. Thanks again for your help. I really appreciate it. Weimin > You are welcome, thanks for your perseverance! > > Simon