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

[Simon Marchi <simon.marchi@polymtl.ca>]

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.

>   * 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