Re: Moving to git -- RFC: authors map

Joseph Myers : > 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 names (on

Action stamps (was: Re: Moving to git)

Andi Kleen : > 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 British friends call "t

Re: Moving to git

Jason Merrill 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 don't really

Re: Moving to git

Jason Merrill 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 completely different.

Re: Moving to git

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, b

Re: Moving to git

Jason Merrill : > 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 all, because g

Re: Moving to git

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 ol

Re: Moving to git

Jakub Jelinek writes: > On Mon, Aug 24, 2015 at 10:22:22AM +0200, Andreas Schwab wrote: >> Jakub Jelinek 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

Re: Moving to git

Jakub Jelinek 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 BAD8 1CE9 1970

Re: Moving to git

On Mon, Aug 24, 2015 at 10:22:22AM +0200, Andreas Schwab wrote: > Jakub Jelinek 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 ea

Re: Moving to git

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, read

Re: Moving to git

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 wan

Re: Moving to git

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

Re: Moving to git

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

Re: Moving to git

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 workf

Re: Moving to git

On 24/08/15 12:43, Jonathan Wakely wrote: > On 24 August 2015 at 11:42, Eric S. Raymond wrote: >> Jonathan Wakely : >>> 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 significa

Re: Moving to git

On 24 August 2015 at 11:42, Eric S. Raymond wrote: > Jonathan Wakely : >> 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 characte

Re: Moving to git

Jonathan Wakely : > 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 identi

Re: Moving to git - bibisect ...

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 w

Re: Moving to git

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

Re: Moving to git

Jakub Jelinek 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 describe gives you

Re: Moving to git

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

Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

* David Malcolm: > +The 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

Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

On Sat, Aug 22, 2015 at 10:59:31AM -0400, David Malcolm wrote: > > > +The 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; > > >

Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

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

Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

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;

Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

On 08/21/2015 07:54 PM, David Malcolm wrote: Here'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

Re: Moving to git

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

[PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)

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,

Re: Moving to git

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

Re: Moving to git

Jason Merrill writes: > On 08/21/2015 03:21 PM, Andreas Schwab wrote: >> Jason Merrill 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,

Re: Moving to git

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

Re: Moving to git

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 shoul

Re: Moving to git

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

Re: Moving to git

On Fri, 21 Aug 2015, Jason Merrill wrote: > On 08/21/2015 10:38 AM, Andreas Schwab wrote: > > Jason Merrill 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 namespa

Re: Moving to git

On 08/21/2015 03:21 PM, Andreas Schwab wrote: Jason Merrill 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 wou

Re: Moving to git

Jason Merrill 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 duplicated.

Re: Moving to git

On 08/21/2015 02:28 PM, Andreas Schwab wrote: Jason Merrill 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

Re: Moving to git

Jason Merrill 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 you see that

Re: Moving to git

Jason Merrill 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 the history o

Re: Moving to git

On 08/21/2015 10:38 AM, Andreas Schwab wrote: Jason Merrill 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 own purpose in t

Re: Moving to git

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 (m

Re: Moving to git

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 co

Re: Moving to git

"H.J. Lu" writes: > On Fri, Aug 21, 2015 at 9:01 AM, Andreas Schwab wrote: >> "H.J. Lu" 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 h

Re: Moving to git

On Fri, Aug 21, 2015 at 9:01 AM, Andreas Schwab wrote: > "H.J. Lu" 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 me bisect GCC trunk. -- H

Re: Moving to git

"H.J. Lu" 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 01D3 44D5 214

Re: Moving to git

On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner wrote: > On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote: >> Ramana Radhakrishnan writes: >> >> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely >> > wrote: >> >> Teams following a different model could use a separate repo shared by >> >

Re: Moving to git

On Fri, Aug 21, 2015 at 8:39 AM, Andreas Schwab wrote: > "H.J. Lu" 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 wo

Re: Moving to git

"H.J. Lu" 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 wide-int br

Re: Moving to git

On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner wrote: > On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote: >> Ramana Radhakrishnan writes: >> >> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely >> > wrote: >> >> Teams following a different model could use a separate repo shared by >> >

Re: Moving to git

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 shoul

Re: Moving to git

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 binaries

Re: Moving to git

On Fri, Aug 21, 2015 at 7:33 AM, Andreas Schwab wrote: > "H.J. Lu" 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? > > bisec

Re: Moving to git

On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote: > Ramana Radhakrishnan writes: > > > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely > > 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

Re: Moving to git

On Fri, Aug 21, 2015 at 6:59 AM, Markus Trippelsdorf 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 access to my local git r

Re: Moving to git

Jason Merrill writes: > On 08/21/2015 04:26 AM, Richard Biener wrote: >> On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill 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

Re: Moving to git

On Fri, Aug 21, 2015 at 3:09 PM, Andreas Schwab wrote: > Ramana Radhakrishnan writes: > >> On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely >> 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

Re: Moving to git

"H.J. Lu" 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, sch...@li

Re: Moving to git

On 08/21/2015 09:47 AM, H.J. Lu wrote: On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan wrote: On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely wrote: On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote: Absolutely, a non-fast-forward push is anathema for anything other people migh

Re: Moving to git

Ramana Radhakrishnan writes: > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely > 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 you are right they sure can, but one

Re: Moving to git

On 08/21/2015 04:26 AM, Richard Biener wrote: On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill 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, then later remove i

Re: Moving to git

On 2015.08.21 at 06:47 -0700, H.J. Lu wrote: > On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan > wrote: > > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely > > wrote: > >> On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote: > > Absolutely, a non-fast-forward push is anathem

Re: Moving to git

On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan wrote: > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely > 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

Re: Moving to git

On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely 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 push-reb

Re: Moving to git

Richard Biener 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, something that doesn't seem

Re: Moving to git

On 21 August 2015 at 12:25, Richard Biener wrote: > On Fri, Aug 21, 2015 at 12:52 PM, Jonathan Wakely > 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

Re: Moving to git

On Fri, Aug 21, 2015 at 12:52 PM, Jonathan Wakely 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, the future ba

Re: Moving to git

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,

Re: Moving to git

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

Re: Moving to git

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

Re: Moving to git

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

Re: Moving to git

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 tra

Re: Moving to git

On Thu, Aug 20, 2015 at 10: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

Re: Moving to git

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 gi

Re: Moving to git

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: https://www.gnu.org/

Re: Moving to git

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 idea

Re: Moving to git

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:

Re: Moving to git

> On Aug 20, 2015, at 4:24 PM, Jason Merrill 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 doesn't

Re: Moving to git

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

Re: Moving to git

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

Re: Moving to git

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 infor

Re: Moving to git

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 questions

Re: Moving to git

> On Aug 20, 2015, at 4:09 PM, Jason Merrill 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 others. >

Re: Moving to git

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 info

Re: Moving to git

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 t

Re: Moving to git

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? > > O

Re: Moving to git

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 tran

Moving to git

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: