Re: [PATCH5 PR gdb/16959] gdb hangs in infinite recursion

[Weimin Pan <weimin.pan@oracle.com>]

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 <newfile>
>> % 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