From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127368 invoked by alias); 30 Mar 2018 22:05:10 -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 127358 invoked by uid 89); 30 Mar 2018 22:05:10 -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_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=plenty, hunk, variations, yours X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 30 Mar 2018 22:05:07 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id w2UM4rKv018764 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Mar 2018 18:04:58 -0400 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 01C051E073; Fri, 30 Mar 2018 18:04:52 -0400 (EDT) Subject: Re: [PATCH5 PR gdb/16959] gdb hangs in infinite recursion To: Weimin Pan 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> From: Simon Marchi Message-ID: <3505af0b-d303-b556-0a4c-c416ac88a064@polymtl.ca> Date: Fri, 30 Mar 2018 22:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <96ab9fda-2c03-a9c6-1da9-70e807e69e5c@oracle.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Fri, 30 Mar 2018 22:04:53 +0000 X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00625.txt.bz2 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. >  * 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. * 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. > >  * 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). > > Thanks very much for your help. > > Weimin You are welcome, thanks for your perseverance! Simon