Re: git conversion in progress
All (annotated) release tags are misnamed. For example, refs/tags/releases/gcc-9.2.0 is really named gcc_9_2_0_release: $ git cat-file -p releases/gcc-9.2.0 object a0c06cc27d2146b7d86758ffa236516c6143d62c type commit tag gcc_9_2_0_release tagger Jakub Jelinek 1565595539 +0200 Tagging source as tags/gcc_9_2_0_release That breaks git describe: $ git describe releases/gcc-9.2.0 warning: tag 'gcc_9_2_0_release' is really 'releases/gcc-9.2.0' here gcc_9_2_0_release Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [wwwdocs] Generalize instructions and remove notes on repository mirroring via rsync.
[ gcc-patches -> gcc ] On Sat, 18 Jan 2020, Gerald Pfeifer wrote: > Remove all references how to perform local checkouts, to SVN, and > mirroring the repository. Instead generalize descriptions since > with the move to Git syncing the repository with rsync and then > checking out locally became mostly pointless. The rsync overview shows gcc-svn gcc svn repository () gcc-cvs gcc cvs repository () I assume it's intentional that git is not listed there? Should gcc-cvs really be listed there still? (If no, should we at this point prune the old CVS tree on the server?) Gerald
Let's remove all (or the largest) diffs from gcc-cvs@
TL;DR: See subject. Verbosity follows. The git transition is mostly for the better. Thanks to those investing time and effort. There's always fallout. Here's one dustcloud: In the distant past with svn, there messages to gcc-cvs@ were somewhat like git show --stat, i.e. without the actual changes: > Author: gccadmin Date: Wed Dec 25 00:16:22 2019 New Revision: 279730 URL: https://gcc.gnu.org/viewcvs?rev=279730&root=gcc&view=rev Log: Daily bump. Modified: trunk/gcc/DATESTAMP < Now after the git transition, patches *always* come with a diff, as below. > https://gcc.gnu.org/g:d8998708ca316249e475d139c89ae7d169e64d34 commit d8998708ca316249e475d139c89ae7d169e64d34 Author: GCC Administrator Date: Wed Jan 15 00:16:26 2020 + Daily bump. Diff: --- gcc/DATESTAMP | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/DATESTAMP b/gcc/DATESTAMP index 3a0695d..ba948c5 100644 --- a/gcc/DATESTAMP +++ b/gcc/DATESTAMP @@ -1 +1 @@ -20200114 +20200115 < (No, not just the daily bump, I just wanted to avoid a person being pointed out and had no commits myself "within reach".) Why the diff? I don't remember the absence of a diff being a problem in the svn era (or at least wasn't argued much on the mailing lists). Compare also to traffic on binutils-cvs@ and gdb-cvs@, where there *are* diffs posted, but apparently there's a size limit; I see "[diff truncated at 10 bytes]" for a post on gdb-cvs. Still, I very much prefer no diff at all. Does someone actually (not theoretically) have a need that is fulfilled by those diffs? Can we remove them altogether? If not, can we cap the messages at a size limit? Note: I'm aware of the discussion regarding limiting posts for certain branches to gcc-cvs; that's incidental. Note also that my own needs are handled by means of procmail, I was just bothered enough to bring it up, and less email traffic on sourceware means more bandwidth for actual commit traffic. :) brgds, H-P
Re: gcc-cvs mails for personal/vendor branches for merge commits
On Wed, Jan 15, 2020 at 04:37:49PM +, Iain Sandoe wrote: > I’m guessing that public development branches will probably gravitate to the > no non-FF mode, if they are to be used by people other than the primary author > > .. although that does somewhat limit things; rebasing WIP onto trunk and > reorganising / squashing is useful as well. If a branch does rebase all people who commit to it need to make sure not to overwrite others' work. Your pushes are always non-fast-forward, so you do not notice you did not incorporate someone else's new work if you do not take care. One easy way to avoid this is to just have only one person pushing to a certain branch. Segher
Re: gcc-cvs mails for personal/vendor branches for merge commits
Le 18/01/2020 à 18:49, Segher Boessenkool a écrit : On Wed, Jan 15, 2020 at 04:37:49PM +, Iain Sandoe wrote: I’m guessing that public development branches will probably gravitate to the no non-FF mode, if they are to be used by people other than the primary author .. although that does somewhat limit things; rebasing WIP onto trunk and reorganising / squashing is useful as well. If a branch does rebase all people who commit to it need to make sure not to overwrite others' work. Your pushes are always non-fast-forward, so you do not notice you did not incorporate someone else's new work if you do not take care. There is the git push --force-with-lease option to avoid that. Its goal is to force a non-fast-forward push, but only if the remote position (HEAD) is actually where you expect it to, that is no work you don't know about has been pushed in the mean time. I strongly recommend to use --force-with-lease on non-user branches. User branches you usually control totally and are the only one to push to, so that's less an issue. One easy way to avoid this is to just have only one person pushing to a certain branch. Segher
gcc-9-20200118 is now available
Snapshot gcc-9-20200118 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20200118/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 41fd95e6dbd1980c1dd065da356f6557c16946c5 You'll find: gcc-9-20200118.tar.xzComplete GCC SHA256=23e63cee0095f440eaa119bd147d860e1feb770c3dec0bcb9f1e38358164e197 SHA1=5db33102b70394bb328473a99e2091b85150a6b8 Diffs from 9-20200111 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
