Re: [ros-dev] Microsoft switched to Git

[Brandin L Claar]

Just move everything to GitHub:

https://github.com/blog/966-improved-subversion-client-support

-brandin

>   On Feb 15, 2017, at 06:32, ros-dev-request(a)reactos.org
> wrote:
>  
>  Send Ros-dev mailing list submissions to
>     ros-dev(a)reactos.org
>  
>  To subscribe or unsubscribe via the World Wide Web, visit
>     http://www.reactos.org/mailman/listinfo/ros-dev
>  or, via email, send a message with subject or body 'help' to
>     ros-dev-request(a)reactos.org
>  
>  You can reach the person managing the list at
>     ros-dev-owner(a)reactos.org
>  
>  When replying, please edit your Subject line so it is more specific
>  than "Re: Contents of Ros-dev digest..."
>  
>  
>  Today's Topics:
>  
>    1. Re: Microsoft switched to Git (Ged Murphy)
>    2. Re: Microsoft switched to Git (David Quintana (gigaherz))
>    3. Re: Microsoft switched to Git (Colin Finck)
>    4. Re: Microsoft switched to Git (David Quintana (gigaherz))
>    5. Re: Microsoft switched to Git (Colin Finck)
>  
>  
>  ----------------------------------------------------------------------
>  
>  Message: 1
>  Date: Wed, 15 Feb 2017 11:04:52 -0000
>  From: "Ged Murphy" <gedmurphy.maillists(a)gmail.com>
>  To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
>  Subject: Re: [ros-dev] Microsoft switched to Git
>  Message-ID: <004701d2877b$55983010$00c89030$(a)gmail.com>
>  Content-Type: text/plain;    charset="utf-8"
>  
>  I think the easiest path is to switch to a centralized style model using git.
>  That is, we have a master copy (aka trunk) that gives the feel of our existing model.
> That would allow devs that prefer SVN to mostly continue working as before, and give the
> devs who want to use git in a more traditional way the ability to branch off and work in a
> git style manner, then sync their changes back into 'trunk'.
>  
>  
>  -----Original Message-----
>  From: Ros-dev [mailto:[e-mail]] On Behalf Of Colin Finck
>  Sent: 15 February 2017 10:53
>  To: ros-dev(a)reactos.org
>  Subject: Re: [ros-dev] Microsoft switched to Git
>  
> >   Am 15.02.2017 um 11:35 schrieb David Quintana
> > (gigaherz):
> >  The number doesn't matter. The ReactOS project can't afford to lost 
> >  any long-time members. Git would be a benefit for all of us, but it 
> >  has to be a benefit for ALL of us. 
>  
>  Let's not forget:
>  
>  - Part of the reasons developers had against Git may have been resolved by now.
>  - Part of the problem may be that "Git is so different" to some devs, but I
> think this can be resolved by a detailed Wiki article showing how to do the same thing in
> SVN and Git. We already wrote such articles for TortoiseSVN after all!
>  - And finally, we first need a plan for a Git move that doesn't suck. We tried SubGit
> and it failed for us. Then there is the "Merge workflow", which is supported
> very well by all tools, but creates a lot of parallel history. The "Rebase
> workflow" is more like what SVN does (keeping a linear history), but no idea how to
> enforce that with TortoiseGit.
>  
>  I think if a team could look after these things and help moving each and every developer
> towards Git, it may even be doable for us.
>  
>  Cheers,
>  
>  Colin
>  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
>  
>  
>  
>  ------------------------------
>  
>  Message: 2
>  Date: Wed, 15 Feb 2017 12:18:40 +0100
>  From: "David Quintana (gigaherz)" <gigaherz(a)gmail.com>
>  To: ReactOS Development List <ros-dev(a)reactos.org>
>  Subject: Re: [ros-dev] Microsoft switched to Git
>  Message-ID:
>     <CADD3+ruo18pQos1QO+jCHg5V2-hyrrjSZ7Va1pfgm+tprDbDZw(a)mail.gmail.com>
>  Content-Type: text/plain; charset="utf-8"
>  
>  My belief is that the best path would be:
>  
>  Phase 0: This is how we are now. We have SVN master (trunk), and a
>  read-only git mirror, and a semi-updated github mirror for when a
>  contributor really wants to submit git PRs.
>  
>  Phase 1: Switch to using Git with PRs for submitting patches (Github's PR
>  system is really really nice these days, but other solutions exist). Setup
>  a SVN mirror "bot" that creates one svn commit for each push/merge detected
>  in the master branch, and allows the buildbots to continue working as they
>  do now.
>  
>  This would allow the existing svn-patch workflow to continue working, but
>  commits on svn wouldn't be allowed anymore. Developers are expected to at
>  least TRY to learn to use git (it's not that hard! I promise!).
>  
>  Phase 2: We switch the buildbots and testbots to pull from git, enable
>  testbot access for git PRs (such as with a github bot that responds to
>  "@rosbot runtest" or similar). The SVN mirror remains, for archival
>  purposes, but git commits aren't merged so regularly. Release tags/branches
>  can still be published through SVN, for ease of access.
>  
>  Phase 3: Everyone ends up agreeing that maintaining the svn mirror is no
>  longer worth the effort.
>  
>  Of course, anything like this will only happen if the entire team agrees to
>  it.
>  
>  On 15 February 2017 at 12:04, Ged Murphy <gedmurphy.maillists(a)gmail.com>
>  wrote:
>  
> >   I think the easiest path is to switch to a
> > centralized style model using
> >  git.
> >  That is, we have a master copy (aka trunk) that gives the feel of our
> >  existing model. That would allow devs that prefer SVN to mostly continue
> >  working as before, and give the devs who want to use git in a more
> >  traditional way the ability to branch off and work in a git style manner,
> >  then sync their changes back into 'trunk'.
> >  
> >  
> >  -----Original Message-----
> >  From: Ros-dev [mailto:[e-mail]] On Behalf Of Colin
> >  Finck
> >  Sent: 15 February 2017 10:53
> >  To: ros-dev(a)reactos.org
> >  Subject: Re: [ros-dev] Microsoft switched to Git
> >  
> > >   Am 15.02.2017 um 11:35 schrieb David Quintana
> > > (gigaherz):
> > >  The number doesn't matter. The ReactOS project can't afford to lost
> > >  any long-time members. Git would be a benefit for all of us, but it
> > >  has to be a benefit for ALL of us. 
> >  
> >  Let's not forget:
> >  
> >  - Part of the reasons developers had against Git may have been resolved by
> >  now.
> >  - Part of the problem may be that "Git is so different" to some devs, but
> >  I think this can be resolved by a detailed Wiki article showing how to do
> >  the same thing in SVN and Git. We already wrote such articles for
> >  TortoiseSVN after all!
> >  - And finally, we first need a plan for a Git move that doesn't suck. We
> >  tried SubGit and it failed for us. Then there is the "Merge workflow",
> >  which is supported very well by all tools, but creates a lot of parallel
> >  history. The "Rebase workflow" is more like what SVN does (keeping a linear
> >  history), but no idea how to enforce that with TortoiseGit.
> >  
> >  I think if a team could look after these things and help moving each and
> >  every developer towards Git, it may even be doable for us.
> >  
> >  Cheers,
> >  
> >  Colin
> >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
> >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >   
>

[Javier Agustìn Fernàndez Arroyo]

why change a working solution?

its a questin i have done myself many times :P

On Wed, Feb 15, 2017 at 3:18 PM, Brandin L Claar <brandin(a)remodulate.com>
wrote:

>   Just move everything to GitHub:
>
>  https://github.com/blog/966-improved-subversion-client-support
>
>  -brandin
>
>  On Feb 15, 2017, at 06:32, ros-dev-request(a)reactos.org wrote:
>
>  Send Ros-dev mailing list submissions to
>     ros-dev(a)reactos.org
>
>  To subscribe or unsubscribe via the World Wide Web, visit
>     http://www.reactos.org/mailman/listinfo/ros-dev
>  or, via email, send a message with subject or body 'help' to
>     ros-dev-request(a)reactos.org
>
>  You can reach the person managing the list at
>     ros-dev-owner(a)reactos.org
>
>  When replying, please edit your Subject line so it is more specific
>  than "Re: Contents of Ros-dev digest..."
>
>
>  Today's Topics:
>
>    1. Re: Microsoft switched to Git (Ged Murphy)
>    2. Re: Microsoft switched to Git (David Quintana (gigaherz))
>    3. Re: Microsoft switched to Git (Colin Finck)
>    4. Re: Microsoft switched to Git (David Quintana (gigaherz))
>    5. Re: Microsoft switched to Git (Colin Finck)
>
>
>  ----------------------------------------------------------------------
>
>  Message: 1
>  Date: Wed, 15 Feb 2017 11:04:52 -0000
>  From: "Ged Murphy" <gedmurphy.maillists(a)gmail.com>
>  To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
>  Subject: Re: [ros-dev] Microsoft switched to Git
>  Message-ID: <004701d2877b$55983010$00c89030$(a)gmail.com>
>  Content-Type: text/plain;    charset="utf-8"
>
>  I think the easiest path is to switch to a centralized style model using
>  git.
>  That is, we have a master copy (aka trunk) that gives the feel of our
>  existing model. That would allow devs that prefer SVN to mostly continue
>  working as before, and give the devs who want to use git in a more
>  traditional way the ability to branch off and work in a git style manner,
>  then sync their changes back into 'trunk'.
>
>
>  -----Original Message-----
>  From: Ros-dev [mailto:[e-mail]
>  <ros-dev-bounces(a)reactos.org>] On Behalf Of Colin Finck
>  Sent: 15 February 2017 10:53
>  To: ros-dev(a)reactos.org
>  Subject: Re: [ros-dev] Microsoft switched to Git
>
>  Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):
>
>  The number doesn't matter. The ReactOS project can't afford to lost
>
>  any long-time members. Git would be a benefit for all of us, but it
>
>  has to be a benefit for ALL of us.
>
>
>  Let's not forget:
>
>  - Part of the reasons developers had against Git may have been resolved by
>  now.
>  - Part of the problem may be that "Git is so different" to some devs, but
>  I think this can be resolved by a detailed Wiki article showing how to do
>  the same thing in SVN and Git. We already wrote such articles for
>  TortoiseSVN after all!
>  - And finally, we first need a plan for a Git move that doesn't suck. We
>  tried SubGit and it failed for us. Then there is the "Merge workflow",
>  which is supported very well by all tools, but creates a lot of parallel
>  history. The "Rebase workflow" is more like what SVN does (keeping a linear
>  history), but no idea how to enforce that with TortoiseGit.
>
>  I think if a team could look after these things and help moving each and
>  every developer towards Git, it may even be doable for us.
>
>  Cheers,
>
>  Colin
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
>
>  ------------------------------
>
>  Message: 2
>  Date: Wed, 15 Feb 2017 12:18:40 +0100
>  From: "David Quintana (gigaherz)" <gigaherz(a)gmail.com>
>  To: ReactOS Development List <ros-dev(a)reactos.org>
>  Subject: Re: [ros-dev] Microsoft switched to Git
>  Message-ID:
>     <CADD3+ruo18pQos1QO+jCHg5V2-hyrrjSZ7Va1pfgm+tprDbDZw(a)mail.gmail.com>
>  Content-Type: text/plain; charset="utf-8"
>
>  My belief is that the best path would be:
>
>  Phase 0: This is how we are now. We have SVN master (trunk), and a
>  read-only git mirror, and a semi-updated github mirror for when a
>  contributor really wants to submit git PRs.
>
>  Phase 1: Switch to using Git with PRs for submitting patches (Github's PR
>  system is really really nice these days, but other solutions exist). Setup
>  a SVN mirror "bot" that creates one svn commit for each push/merge detected
>  in the master branch, and allows the buildbots to continue working as they
>  do now.
>
>  This would allow the existing svn-patch workflow to continue working, but
>  commits on svn wouldn't be allowed anymore. Developers are expected to at
>  least TRY to learn to use git (it's not that hard! I promise!).
>
>  Phase 2: We switch the buildbots and testbots to pull from git, enable
>  testbot access for git PRs (such as with a github bot that responds to
>  "@rosbot runtest" or similar). The SVN mirror remains, for archival
>  purposes, but git commits aren't merged so regularly. Release tags/branches
>  can still be published through SVN, for ease of access.
>
>  Phase 3: Everyone ends up agreeing that maintaining the svn mirror is no
>  longer worth the effort.
>
>  Of course, anything like this will only happen if the entire team agrees to
>  it.
>
>  On 15 February 2017 at 12:04, Ged Murphy <gedmurphy.maillists(a)gmail.com>
>  wrote:
>
>  I think the easiest path is to switch to a centralized style model using
>
>  git.
>
>  That is, we have a master copy (aka trunk) that gives the feel of our
>
>  existing model. That would allow devs that prefer SVN to mostly continue
>
>  working as before, and give the devs who want to use git in a more
>
>  traditional way the ability to branch off and work in a git style manner,
>
>  then sync their changes back into 'trunk'.
>
>
>
>  -----Original Message-----
>
>  From: Ros-dev [mailto:[e-mail]
>  <ros-dev-bounces(a)reactos.org>] On Behalf Of Colin
>
>  Finck
>
>  Sent: 15 February 2017 10:53
>
>  To: ros-dev(a)reactos.org
>
>  Subject: Re: [ros-dev] Microsoft switched to Git
>
>
>  Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):
>
>  The number doesn't matter. The ReactOS project can't afford to lost
>
>  any long-time members. Git would be a benefit for all of us, but it
>
>  has to be a benefit for ALL of us.
>
>
>  Let's not forget:
>
>
>  - Part of the reasons developers had against Git may have been resolved by
>
>  now.
>
>  - Part of the problem may be that "Git is so different" to some devs, but
>
>  I think this can be resolved by a detailed Wiki article showing how to do
>
>  the same thing in SVN and Git. We already wrote such articles for
>
>  TortoiseSVN after all!
>
>  - And finally, we first need a plan for a Git move that doesn't suck. We
>
>  tried SubGit and it failed for us. Then there is the "Merge workflow",
>
>  which is supported very well by all tools, but creates a lot of parallel
>
>  history. The "Rebase workflow" is more like what SVN does (keeping a linear
>
>  history), but no idea how to enforce that with TortoiseGit.
>
>
>  I think if a team could look after these things and help moving each and
>
>  every developer towards Git, it may even be doable for us.
>
>
>  Cheers,
>
>
>  Colin
>
>
>  _______________________________________________
>
>  Ros-dev mailing list
>
>  Ros-dev(a)reactos.org
>
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>
>  _______________________________________________
>
>  Ros-dev mailing list
>
>  Ros-dev(a)reactos.org
>
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>

[Hermès BÉLUSCA-MAÏTO]

Because a « working solution » does not mean it is still optimal / efficient…

 

De : Ros-dev [mailto:[e-mail]] De la part de Javier Agustìn Fernàndez
Arroyo
Envoyé : mercredi 15 février 2017 16:04
À : ReactOS Development List
Objet : Re: [ros-dev] Microsoft switched to Git

 

why change a working solution?

its a questin i have done myself many times :P

 

On Wed, Feb 15, 2017 at 3:18 PM, Brandin L Claar <brandin(a)remodulate.com> wrote:

Just move everything to GitHub:

 

https://github.com/blog/966-improved-subversion-client-support

-brandin


On Feb 15, 2017, at 06:32, ros-dev-request(a)reactos.org wrote:

Send Ros-dev mailing list submissions to
   ros-dev(a)reactos.org

To subscribe or unsubscribe via the World Wide Web, visit
   http://www.reactos.org/mailman/listinfo/ros-dev
or, via email, send a message with subject or body 'help' to
   ros-dev-request(a)reactos.org

You can reach the person managing the list at
   ros-dev-owner(a)reactos.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ros-dev digest..."


Today's Topics:

  1. Re: Microsoft switched to Git (Ged Murphy)
  2. Re: Microsoft switched to Git (David Quintana (gigaherz))
  3. Re: Microsoft switched to Git (Colin Finck)
  4. Re: Microsoft switched to Git (David Quintana (gigaherz))
  5. Re: Microsoft switched to Git (Colin Finck)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 Feb 2017 11:04:52 -0000
From: "Ged Murphy" <gedmurphy.maillists(a)gmail.com>
To: "'ReactOS Development List'" <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] Microsoft switched to Git
Message-ID: <004701d2877b$55983010$00c89030$(a)gmail.com>
Content-Type: text/plain;    charset="utf-8"

I think the easiest path is to switch to a centralized style model using git.
That is, we have a master copy (aka trunk) that gives the feel of our existing model. That
would allow devs that prefer SVN to mostly continue working as before, and give the devs
who want to use git in a more traditional way the ability to branch off and work in a git
style manner, then sync their changes back into 'trunk'.


-----Original Message-----
From: Ros-dev [mailto:[e-mail]] On Behalf Of Colin Finck
Sent: 15 February 2017 10:53
To: ros-dev(a)reactos.org
Subject: Re: [ros-dev] Microsoft switched to Git

Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):



The number doesn't matter. The ReactOS project can't afford to lost 

any long-time members. Git would be a benefit for all of us, but it 

has to be a benefit for ALL of us.


Let's not forget:

- Part of the reasons developers had against Git may have been resolved by now.
- Part of the problem may be that "Git is so different" to some devs, but I
think this can be resolved by a detailed Wiki article showing how to do the same thing in
SVN and Git. We already wrote such articles for TortoiseSVN after all!
- And finally, we first need a plan for a Git move that doesn't suck. We tried SubGit
and it failed for us. Then there is the "Merge workflow", which is supported
very well by all tools, but creates a lot of parallel history. The "Rebase
workflow" is more like what SVN does (keeping a linear history), but no idea how to
enforce that with TortoiseGit.

I think if a team could look after these things and help moving each and every developer
towards Git, it may even be doable for us.

Cheers,

Colin

_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev




------------------------------

Message: 2
Date: Wed, 15 Feb 2017 12:18:40 +0100
From: "David Quintana (gigaherz)" <gigaherz(a)gmail.com>
To: ReactOS Development List <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] Microsoft switched to Git
Message-ID:
   <CADD3+ruo18pQos1QO+jCHg5V2-hyrrjSZ7Va1pfgm+tprDbDZw(a)mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

My belief is that the best path would be:

Phase 0: This is how we are now. We have SVN master (trunk), and a
read-only git mirror, and a semi-updated github mirror for when a
contributor really wants to submit git PRs.

Phase 1: Switch to using Git with PRs for submitting patches (Github's PR
system is really really nice these days, but other solutions exist). Setup
a SVN mirror "bot" that creates one svn commit for each push/merge detected
in the master branch, and allows the buildbots to continue working as they
do now.

This would allow the existing svn-patch workflow to continue working, but
commits on svn wouldn't be allowed anymore. Developers are expected to at
least TRY to learn to use git (it's not that hard! I promise!).

Phase 2: We switch the buildbots and testbots to pull from git, enable
testbot access for git PRs (such as with a github bot that responds to
"@rosbot runtest" or similar). The SVN mirror remains, for archival
purposes, but git commits aren't merged so regularly. Release tags/branches
can still be published through SVN, for ease of access.

Phase 3: Everyone ends up agreeing that maintaining the svn mirror is no
longer worth the effort.

Of course, anything like this will only happen if the entire team agrees to
it.

On 15 February 2017 at 12:04, Ged Murphy <gedmurphy.maillists(a)gmail.com>
wrote:




I think the easiest path is to switch to a centralized style model using

git.

That is, we have a master copy (aka trunk) that gives the feel of our

existing model. That would allow devs that prefer SVN to mostly continue

working as before, and give the devs who want to use git in a more

traditional way the ability to branch off and work in a git style manner,

then sync their changes back into 'trunk'.

 

 

-----Original Message-----

From: Ros-dev [mailto:[e-mail]] On Behalf Of Colin

Finck

Sent: 15 February 2017 10:53

To: ros-dev(a)reactos.org

Subject: Re: [ros-dev] Microsoft switched to Git

 

Am 15.02.2017 um 11:35 schrieb David Quintana (gigaherz):

The number doesn't matter. The ReactOS project can't afford to lost

any long-time members. Git would be a benefit for all of us, but it

has to be a benefit for ALL of us.

 

Let's not forget:

 

- Part of the reasons developers had against Git may have been resolved by

now.

- Part of the problem may be that "Git is so different" to some devs, but

I think this can be resolved by a detailed Wiki article showing how to do

the same thing in SVN and Git. We already wrote such articles for

TortoiseSVN after all!

- And finally, we first need a plan for a Git move that doesn't suck. We

tried SubGit and it failed for us. Then there is the "Merge workflow",

which is supported very well by all tools, but creates a lot of parallel

history. The "Rebase workflow" is more like what SVN does (keeping a linear

history), but no idea how to enforce that with TortoiseGit.

 

I think if a team could look after these things and help moving each and

every developer towards Git, it may even be doable for us.

 

Cheers,

 

Colin

 

_______________________________________________

Ros-dev mailing list

Ros-dev(a)reactos.org

http://www.reactos.org/mailman/listinfo/ros-dev

 

 

_______________________________________________

Ros-dev mailing list

Ros-dev(a)reactos.org

http://www.reactos.org/mailman/listinfo/ros-dev

[Magnus Johnsson]

Why use a hammer as a screwdriver just because it has worked before?

2017-02-15 16:04 GMT+01:00 Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com
>  : 
>   why change a working solution?
>
>  its a questin i have done myself many times :P
>
>
>

[Zachary Gorden]

Until the following clumsiness in git get resolved, it remains in my
opinion an inferior revision control system to svn.

1) Attempts to push changes should not require any intervention on the part
of the user to pull and rebase if someone else got in a commit ahead of
time, this should be done automatically. I don't care that someone else
might have gotten a commit in first, especially if they're working on an
entirely different part of the repo. The only case where it should require
manual intervention is if a merge fails because we touched the same block
of code in the same file. Anything else, including touching different parts
of the same file, should be transparent.

2) Attempts to pull in general should not stumble because I've made changes
to a file and not added it. Git should be tracking changes automatically
and only require user intervention if, again, the pulled changes outright
conflicts with a local change, regardless of whether it's "added" or not.

3) If I commit multiple files at once, I should be able to roll back any
arbitrary number of those files instead of having to revert the entire
commit.

As a user, I should not need to have to fight with the revision control
software every time I need to make a change, nor should I need to tell the
revision control software what to track and how to track it. It's its
bloody job to do that, why should I suddenly have to take on additional
management responsibilities when I gain nothing of benefit in return? I
should not need to care about what anyone else is doing UNLESS we happen to
be trying to do the same thing. Considering every project wherein I've used
git the quickest solution to deal with git's merge cockups is to do a clean
checkout, I am unsure why everyone seems so enthusiastic about it. Are all
of you expecting to work in complete isolation from each other and never
have to deal with the inevitable when you try to commit? Cause avoiding
these sorts of problems in git requires a discipline and level of
coordination that this project has historically not demonstrated, whereas
our usage of svn has basically kept people relatively insulated from these
issues by virtue of the fact that svn handles most of them for you.

On Wed, Feb 15, 2017 at 9:11 AM, Magnus Johnsson <magnusjjj(a)gmail.com>
wrote:

>   Why use a hammer as a screwdriver just because it has
> worked before?
>
>  2017-02-15 16:04 GMT+01:00 Javier Agustìn Fernàndez Arroyo <
>  elhoir(a)gmail.com&gt;gt;:
>
> >   why change a working solution?
> >
> >  its a questin i have done myself many times :P
> >
> >
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Magnus Johnsson]

Zachary, that is some seriously valuable input :). I was going to write a
longer answer, with super simple answers, but I found that the super simple
solutions to these are all the top results on google, stackoverflow. Seems
like the situation has cleared up to be a *lot* simpler these days, like 2
to 3 commands copy paste, with helpfull comments on the what and why's :).
Check it out?

[Zachary Gorden]

Why is there a need for anything beyond "git commit" or "git push" or
"git
pull" to do anything? Why should I, as a developer, be required to
micromanage the revision control mechanism? That's the fundamental point of
my previous message. If I have to spend more time getting a commit through
to the canonical repo than I do making a change to the code, that suggests
to me whatever tool I'm using for revision control is not fit for purpose.
If dealing with the common case, of someone committing before you, cannot
be automated cleanly by git out of the box, how is it a better tool than
the likes of svn?

On Wed, Feb 15, 2017 at 10:46 AM, Magnus Johnsson <magnusjjj(a)gmail.com>
wrote:

>   Zachary, that is some seriously valuable input :). I
> was going to write a
>  longer answer, with super simple answers, but I found that the super simple
>  solutions to these are all the top results on google, stackoverflow. Seems
>  like the situation has cleared up to be a *lot* simpler these days, like 2
>  to 3 commands copy paste, with helpfull comments on the what and why's :).
>  Check it out?
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Andreas Bjerkeholt]

If ReactOS at some point decides to actually move to Git, it would be nice
if Github is considered for hosting. It might lower the barrier of entry
for developers new to ReactOS, if they can look at the code, send PRs etc
like they're used to for other projects.
Github issues can of course be disabled in favour of continuing to use JIRA.

2017-02-15 18:01 GMT+01:00 Zachary Gorden <drakekaizer666(a)gmail.com>om>:

>   Why is there a need for anything beyond "git
> commit" or "git push" or "git
>  pull" to do anything? Why should I, as a developer, be required to
>  micromanage the revision control mechanism? That's the fundamental point of
>  my previous message. If I have to spend more time getting a commit through
>  to the canonical repo than I do making a change to the code, that suggests
>  to me whatever tool I'm using for revision control is not fit for purpose.
>  If dealing with the common case, of someone committing before you, cannot
>  be automated cleanly by git out of the box, how is it a better tool than
>  the likes of svn?
>
>  On Wed, Feb 15, 2017 at 10:46 AM, Magnus Johnsson <magnusjjj(a)gmail.com>
>  wrote:
>
> >   Zachary, that is some seriously valuable input
> > :). I was going to write a
> >  longer answer, with super simple answers, but I found that the super simple
> >  solutions to these are all the top results on google, stackoverflow. Seems
> >  like the situation has cleared up to be a *lot* simpler these days, like 2
> >  to 3 commands copy paste, with helpfull comments on the what and why's :).
> >  Check it out?
> >
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>