This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH5 PR gdb/16959] gdb hangs in infinite recursion
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