Joseph Myers jos...@codesourcery.com:
On Thu, 27 Aug 2015, Jason Merrill wrote:
On 08/20/2015 04:33 PM, Joseph Myers wrote:
I think a proper conversion to git as the master repository should
reconvert all the history with author ids properly mapped
Here's an initial mapping of user
Jason Merrill ja...@redhat.com writes:
So that seems like a suitable monotonically increasing identifier.
Git does not guarantee it, though.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something
Andi Kleen a...@firstfloor.org:
But I don't really understand the problem. Just run git log
and generate your own list of numbers. Should be straight forward
to script.
I can tell you from experience with lots of conversions that this, and
the other proposals in the thread, are what our
Jason Merrill ja...@redhat.com writes:
You don't even need to worry about the hash code, you can use the
timestamp by itself. Given the timestamp,
git log -1 --until 1440153969
Consider tree merges. There's no guarantee a time stamp maps to
monotonically increasing commit numbers.
But I
Jason Merrill ja...@redhat.com:
git-svn find-rev takes r123456 and returns a commit hash based on the
git-svn-id in the git log; I don't see why we would need to break that
moving forward, though I'm not sure how well it would work without reference
to an actual SVN server.
It won't work at
On 08/24/2015 11:49 AM, Jeff Law wrote:
On 08/24/2015 09:43 AM, Jakub Jelinek wrote:
Not to mention we should keep the existing r123456 comments in bugzilla
working, and I'm not convinced keeping a SVN version of the repository
(frozen) for that purpose is the best idea.
I'd like to keep the
On 08/24/2015 11:54 AM, Richard Earnshaw wrote:
Why not use the output of 'git show -s --format=%ct-%h'?
$ git show -s --format=%ct-%h master
1440153969-f57da59
That gives you a unix timestamp for the commit, followed by the hash.
Now you've got a fully ordered way of referring to the commit,
Jakub Jelinek ja...@redhat.com writes:
On Mon, Aug 24, 2015 at 10:22:22AM +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com writes:
And for those really identifying them by sha1 hashes is significantly
worse than using monotonically increasing small number, sha1 hashes
are
On 24/08/15 12:43, Jonathan Wakely wrote:
On 24 August 2015 at 11:42, Eric S. Raymond wrote:
Jonathan Wakely jwakely@gmail.com:
On 24 August 2015 at 09:17, Jakub Jelinek wrote:
The revision ids are also useful for bugzilla, r123456
links in text pointing to http://gcc.gnu.org/r123456 is
On 08/24/2015 02:17 AM, Jakub Jelinek wrote:
On Thu, Aug 20, 2015 at 04:09:39PM -0400, Jason Merrill wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his
On Mon, Aug 24, 2015 at 09:34:41AM -0600, Jeff Law wrote:
On 08/24/2015 02:17 AM, Jakub Jelinek wrote:
On Thu, Aug 20, 2015 at 04:09:39PM -0400, Jason Merrill wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see some kind commit hook to
associate something
On 08/24/2015 09:43 AM, Jakub Jelinek wrote:
On Mon, Aug 24, 2015 at 09:34:41AM -0600, Jeff Law wrote:
On 08/24/2015 02:17 AM, Jakub Jelinek wrote:
On Thu, Aug 20, 2015 at 04:09:39PM -0400, Jason Merrill wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see
On Mon, 24 Aug 2015, Jakub Jelinek wrote:
Not to mention we should keep the existing r123456 comments in bugzilla
working, and I'm not convinced keeping a SVN version of the repository
(frozen) for that purpose is the best idea.
Of course you keep the SVN repository there indefinitely,
On 24/08/15 16:43, Jakub Jelinek wrote:
On Mon, Aug 24, 2015 at 09:34:41AM -0600, Jeff Law wrote:
On 08/24/2015 02:17 AM, Jakub Jelinek wrote:
On Thu, Aug 20, 2015 at 04:09:39PM -0400, Jason Merrill wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see some
On Mon, Aug 24, 2015 at 10:22:22AM +0200, Andreas Schwab wrote:
Jakub Jelinek ja...@redhat.com writes:
And for those really identifying them by sha1 hashes is significantly
worse than using monotonically increasing small number, sha1 hashes
are impossible to remember, and you don't know
Jakub Jelinek ja...@redhat.com writes:
But it is not unique across different branches, and furthermore, what is the
fast way to go from the number to a commit?
The git describe output is a valid ref by itself.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196
On Thu, Aug 20, 2015 at 04:09:39PM -0400, Jason Merrill wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his workflow where the SVN ids are associated with
Jakub Jelinek ja...@redhat.com writes:
And for those really identifying them by sha1 hashes is significantly
worse than using monotonically increasing small number, sha1 hashes
are impossible to remember, and you don't know what is earlier and
what is later from just looking at it.
git
Jonathan Wakely jwakely@gmail.com:
On 24 August 2015 at 09:17, Jakub Jelinek wrote:
The revision ids are also useful for bugzilla, r123456
links in text pointing to http://gcc.gnu.org/r123456 is significantly
shorter
The first six characters of the sha1 is usually enough to
Hi Jakub,
On Mon, 2015-08-24 at 10:17 +0200, Jakub Jelinek wrote:
Jakub: How about using git bisect instead, and identify the compiler
binaries with the git commit sha1?
That is really not useful. While you speed it bisection somewhat by avoiding
network traffic and communication with a
On 24 August 2015 at 09:17, Jakub Jelinek wrote:
The revision ids are also useful for bugzilla, r123456
links in text pointing to http://gcc.gnu.org/r123456 is significantly
shorter
The first six characters of the sha1 is usually enough to
unambiguously identify a commit, so we could easily
On 24 August 2015 at 11:42, Eric S. Raymond wrote:
Jonathan Wakely jwakely@gmail.com:
On 24 August 2015 at 09:17, Jakub Jelinek wrote:
The revision ids are also useful for bugzilla, r123456
links in text pointing to http://gcc.gnu.org/r123456 is significantly
shorter
The first six
On Fri, Aug 21, 2015 at 07:54:11PM -0400, David Malcolm wrote:
In the git world, the first line of the commit message has special
meaning, being treated as the title of the commit.
It would be nice if we could use a real commit message, not just a short
title line; for example,
On Sat, 2015-08-22 at 05:55 -0500, Segher Boessenkool wrote:
On Fri, Aug 21, 2015 at 07:54:11PM -0400, David Malcolm wrote:
In the git world, the first line of the commit message has special
meaning, being treated as the title of the commit.
It would be nice if we could use a real
* David Malcolm:
+pThe log message for a checkin should be a single line giving a
+descriptive title for the checkin, followed by a blank line, followed by
+the complete ChangeLog entry for the change. This is the git convention;
+giving titles to checkins makes life easier for developers
On Sat, Aug 22, 2015 at 10:59:31AM -0400, David Malcolm wrote:
+pThe log message for a checkin should be a single line giving a
+descriptive title for the checkin, followed by a blank line, followed by
+the complete ChangeLog entry for the change. This is the git convention;
+giving
On 08/21/2015 07:54 PM, David Malcolm wrote:
pHere's an actual check-in session for a patch John Carr recently
Can this really be described as an actual check-in session when we're
changing the contents? :)
Jason
On 08/21/2015 06:44 PM, Mikhail Maltsev wrote:
On 08/20/2015 11:09 PM, Jason Merrill wrote:
Absolutely, a non-fast-forward push is anathema for anything other people might
be working on. The git repository already prohibits this; people that want to
push-rebase-push their own branches need to
Absolutely, a non-fast-forward push is anathema for anything other people
might be working on. The git repository already prohibits this; people that
want to push-rebase-push their own branches need to delete the branch before
pushing again.
On the FSF trunk and the main release branches -
On 21 August 2015 at 09:26, Richard Biener wrote:
Btw, I've done this once now and it kind of works. You need to write your
tests in a way to support gits limited way of searching (the past has to be
always good, the future bad) - I've tried to find a change that was _fixing_
a problem,
On Fri, Aug 21, 2015 at 12:52 PM, Jonathan Wakely jwakely@gmail.com wrote:
On 21 August 2015 at 09:26, Richard Biener wrote:
Btw, I've done this once now and it kind of works. You need to write your
tests in a way to support gits limited way of searching (the past has to be
always good,
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward push is anathema for anything other people
might be working on. The git repository already prohibits this; people that
want to push-rebase-push their own branches need to delete the branch before
pushing
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward push is anathema for anything other
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill ja...@redhat.com wrote:
ISTM that within that namespace, folks ought to have the freedom to use
whatever works for them. If folks want to create a transient
On 2015.08.21 at 06:47 -0700, H.J. Lu wrote:
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a
H.J. Lu hjl.to...@gmail.com writes:
One very frustrating thing for me is git bisect doesn't always
work. I think cherry-pick is OK, but probably not rebase nor merge.
Can we enforce that git bisect must work on official branches?
bisect works fine with merges.
Andreas.
--
Andreas Schwab,
On Fri, Aug 21, 2015 at 6:59 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
BTW while I have your attention: Why are you constantly creating
(rebasing) and deleting branches? Why not simply use a local git tree
for this purpose?
I want to share my branches with people who have no
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward push is anathema for anything other people
might be working on. The git repository already prohibits this; people that
want to
Richard Biener richard.guent...@gmail.com writes:
Btw, I've done this once now and it kind of works. You need to write your
tests in a way to support gits limited way of searching (the past has to be
always good, the future bad) - I've tried to find a change that was _fixing_
a problem,
On Fri, Aug 21, 2015 at 3:09 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a different model could use a separate repo shared by
those
On 08/21/2015 09:47 AM, H.J. Lu wrote:
On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan
ramana@googlemail.com wrote:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com wrote:
On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
Absolutely, a non-fast-forward
On 08/21/2015 04:26 AM, Richard Biener wrote:
On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill ja...@redhat.com wrote:
ISTM that within that namespace, folks ought to have the freedom to use
whatever works for them. If folks want to create a transient branch,
push-rebase-push on that branch,
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a different model could use a separate repo shared by
those developers, not the gcc.gnu.org one. It's much easier to do that
with git.
Yes
On 08/20/2015 02:09 PM, Jason Merrill wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his workflow where the SVN ids are associated with the compiler
On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner berg...@vnet.ibm.com wrote:
On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a
On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner berg...@vnet.ibm.com wrote:
On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a
H.J. Lu hjl.to...@gmail.com writes:
On Fri, Aug 21, 2015 at 9:01 AM, Andreas Schwab sch...@linux-m68k.org wrote:
H.J. Lu hjl.to...@gmail.com writes:
git bisect good/git bisect bad land my tree not on trunk when
they are used on commits from wide-int branch merge.
Yes, that is bisect
On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
Ramana Radhakrishnan ramana@googlemail.com writes:
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely jwakely@gmail.com
wrote:
Teams following a different model could use a separate repo shared by
those developers, not the
On Fri, Aug 21, 2015 at 7:33 AM, Andreas Schwab sch...@linux-m68k.org wrote:
H.J. Lu hjl.to...@gmail.com writes:
One very frustrating thing for me is git bisect doesn't always
work. I think cherry-pick is OK, but probably not rebase nor merge.
Can we enforce that git bisect must work on
On Fri, 21 Aug 2015, H.J. Lu wrote:
Can we enforce that git bisect must work on official branches?
I think a good principle independent of moving to git is that commits
should be bisectable. In particular, if a patch series is committed as
separate commits, each commit should be intended
H.J. Lu hjl.to...@gmail.com writes:
git bisect good/git bisect bad land my tree not on trunk when
they are used on commits from wide-int branch merge.
Yes, that is bisect working as designed.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756
On Fri, Aug 21, 2015 at 8:39 AM, Andreas Schwab sch...@linux-m68k.org wrote:
H.J. Lu hjl.to...@gmail.com writes:
up to date by git merge origin/master. I never tried git bisect
on it since I know that commits on that branch aren't consecutive.
bisect works with any kind of repository.
Also
H.J. Lu hjl.to...@gmail.com writes:
up to date by git merge origin/master. I never tried git bisect
on it since I know that commits on that branch aren't consecutive.
bisect works with any kind of repository.
Also git bisect doesn't work on gcc trunk in GCC git mirror
for commits around
On Fri, Aug 21, 2015 at 9:01 AM, Andreas Schwab sch...@linux-m68k.org wrote:
H.J. Lu hjl.to...@gmail.com writes:
git bisect good/git bisect bad land my tree not on trunk when
they are used on commits from wide-int branch merge.
Yes, that is bisect working as designed.
But this doesn't help
Jason Merrill ja...@redhat.com writes:
Hmm, it occurs to me that a squash commit (or series of commits) followed
by a merge -s ours could have the advantages of both approaches: the
patches land on trunk in a sensible order, but the history is available.
That would be worse, since changes are
One other thing to watch out for in the conversion:
* Where trunk got accidentally deleted and recreated as a copy of the
trunk version before the deletion (recreations r130805, r184997), make
sure this doesn't get represented as deletion followed by recreation of
all files on trunk. (It
On 08/21/2015 04:10 PM, Joseph Myers wrote:
On Fri, 21 Aug 2015, Jason Merrill wrote:
On 08/21/2015 10:38 AM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
Can we limit the namespace one can create branches in? Like force all
On 08/21/2015 03:21 PM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
Hmm, it occurs to me that a squash commit (or series of commits) followed
by a merge -s ours could have the advantages of both approaches: the
patches land on trunk in a sensible order, but the history is
On Fri, 21 Aug 2015, Jason Merrill wrote:
On 08/21/2015 10:38 AM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
Can we limit the namespace one can create branches in? Like force all
branches created by $user to be in
On Fri, 21 Aug 2015, Jason Merrill wrote:
We should also talk about a policy for when we delete branches; there are a
bunch of ancient feature and testing branches in SVN that I think are no
longer interesting.
My view is don't delete (except for leaving user / company branches up to
those
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 03:21 PM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
Hmm, it occurs to me that a squash commit (or series of commits) followed
by a merge -s ours could have the advantages of both approaches: the
patches land on trunk in
On 08/21/2015 11:26 AM, Joseph Myers wrote:
On Fri, 21 Aug 2015, H.J. Lu wrote:
Can we enforce that git bisect must work on official branches?
I think a good principle independent of moving to git is that commits
should be bisectable. In particular, if a patch series is committed
On 08/21/2015 10:38 AM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
On 08/21/2015 04:26 AM, Richard Biener wrote:
Can we limit the namespace one can create branches in? Like force all
branches created by $user to be in namespace $user?
git will create new namespaces for its
On 08/21/2015 11:30 AM, Ramana Radhakrishnan wrote:
My query was whether allowing for rebase (rewriting history) in
published feature branches was a decision to be left to the branch
maintainers or was this going to be a repository wide restriction. It
also seems odd to me that trunk follows a
Jason Merrill ja...@redhat.com writes:
I had been thinking of namespace as a subdirectory of refs/heads.
If Richard wants something not pulled by default, then he must have
thought of something outside of refs/heads.
But now I see that there is something called namespace in git.
Where did
Jason Merrill ja...@redhat.com writes:
I would expect feature branches to merge from trunk when needed during
development. When merging the feature into trunk the developer can just
use git merge --squash and then decide whether to commit it in one hunk or
several.
This will of course lose
On 08/21/2015 02:28 PM, Andreas Schwab wrote:
Jason Merrill ja...@redhat.com writes:
I would expect feature branches to merge from trunk when needed during
development. When merging the feature into trunk the developer can just
use git merge --squash and then decide whether to commit it in
On 08/20/2015 11:09 PM, Jason Merrill wrote:
Absolutely, a non-fast-forward push is anathema for anything other people
might
be working on. The git repository already prohibits this; people that want to
push-rebase-push their own branches need to delete the branch before pushing
again.
On 21 August 2015 at 12:25, Richard Biener wrote:
On Fri, Aug 21, 2015 at 12:52 PM, Jonathan Wakely jwakely@gmail.com
wrote:
On 21 August 2015 at 09:26, Richard Biener wrote:
Btw, I've done this once now and it kind of works. You need to write your
tests in a way to support gits
On Thu, 2015-08-20 at 18:37 -0400, Jason Merrill wrote:
On 08/20/2015 06:32 PM, Segher Boessenkool wrote:
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add
On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill ja...@redhat.com wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his workflow where the SVN ids are
Hi,
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote:
I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that
Hi,
On Thu, Aug 20, 2015 at 05:32:26PM -0500, Segher Boessenkool wrote:
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add meaningful
titles to commits?
On 20 August 2015 at 23:32, Jason Merrill wrote:
On 08/20/2015 04:33 PM, Joseph Myers wrote:
* Make sure whatever process updates the github mirror is kept going after
the conversion (actually it looks like it broke two weeks ago...).
I have no idea how this mirror is updated. Its github
On 08/20/2015 11:57 AM, Jason Merrill wrote:
I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that transition. Does anyone have more information about
this discussion?
Our current workflow
I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that transition. Does anyone have more information about
this discussion?
Our current workflow translates over to a git master pretty easily:
On 08/20/2015 03:31 PM, David Malcolm wrote:
On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote:
I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that transition. Does anyone have more
On Aug 20, 2015, at 4:09 PM, Jason Merrill ja...@redhat.com wrote:
On 08/20/2015 02:23 PM, Jeff Law wrote:
...As far as the trunk and release branches, are there any best practices
out there that we can draw from? Obviously doing things like
push-rebase-push is bad. Presumably there's
On 08/20/2015 04:22 PM, paul_kon...@dell.com wrote:
Let's make sure the procedures that people are supposed to follow are clearly
documented. I recently went looking for the equivalent in the binutils/gdb
project and it doesn't seem to be written down there, though if you ask enough
* Jeff Law:
I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his workflow where the SVN ids are associated with the compiler
binaries he keeps around for very fast bisection.
As long as we do not
On 20 August 2015 at 19:23, Jeff Law wrote:
On 08/20/2015 11:57 AM, Jason Merrill wrote:
I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that transition. Does anyone have more information
On Aug 20, 2015, at 4:24 PM, Jason Merrill ja...@redhat.com wrote:
On 08/20/2015 04:22 PM, paul_kon...@dell.com wrote:
Let's make sure the procedures that people are supposed to follow are
clearly documented. I recently went looking for the equivalent in the
binutils/gdb project and it
On 08/20/2015 02:23 PM, Jeff Law wrote:
I suspect Jakub will strongly want to see some kind commit hook to
associate something similar to an SVN id to each git commit to support
his workflow where the SVN ids are associated with the compiler
binaries he keeps around for very fast bisection. I
On Thu, 20 Aug 2015, Jason Merrill wrote:
It should be pretty straightforward to use the existing git mirror as the
master repository; the main adjustment I'd want to make is rewriting the
I think using the existing git mirror for this is a bad idea. To quote
http://esr.ibiblio.org/?p=6778:
On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote:
I hear that at Cauldron people were generally supportive of switching
over to git as the primary GCC repository, and talked about me being
involved in that transition. Does anyone have more information about
this discussion?
Our
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add meaningful
titles to commits?
Currently:
https://www.gnu.org/software/gcc/svnwrite.html#checkin says:
On 08/20/2015 04:33 PM, Joseph Myers wrote:
On Thu, 20 Aug 2015, Jason Merrill wrote:
It should be pretty straightforward to use the existing git mirror as the
master repository; the main adjustment I'd want to make is rewriting the
I think using the existing git mirror for this is a bad
On 08/20/2015 06:32 PM, Segher Boessenkool wrote:
On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
If we're going to migrate to git (I hope so), can we also please
*slightly* revise the policy on commit messages, to add meaningful
titles to commits?
Currently:
88 matches
Mail list logo
