+1
Git can be confusing for seasoned Subversion developers at first, as it
really is a fundamental paradigm shift in many respects. I'm not sure why
you're only able to do read-only access, though. The add/commit syntax for
Git is fairly similar to that of SVN. Have you tried creating a dummy r
On Wed, March 7, 2012 1:51 pm, Sebastian Bergmann wrote:
> Am 07.03.2012 19:46, schrieb Kris Craig:
>> As I and others have said already, using a Subversion branching
>> model
>> on Git just doesn't make any sense.
>
> How often does it have to be explained to you and others that we
> would
> lik
Kris Craig wrote:
As I and others have said already, using a Subversion
branching model on Git just doesn't make any sense. We may as well just
keep using SVN if we're not going to make use of Git's branching advantages.
I completely disagree. There's no need to completely switch your
branchi
Umm Sebastian, how many times do I have to explain that *I agree with you*?!
Please read my post before responding. Specifically, point #5. I hate
repeating myself, so I'll simply copy/paste it if you don't mind:
"when I draft it I'll propose a gradual adoption scheme"
--Kris
On Wed
Am 07.03.2012 19:46, schrieb Kris Craig:
> As I and others have said already, using a Subversion branching model
> on Git just doesn't make any sense.
How often does it have to be explained to you and others that we would
like to do this step by step? First we change the tool, then we change
th
On Wed, Mar 7, 2012 at 1:12 AM, David Soria Parra wrote:
> On 2012-03-07, Kris Craig wrote:
> > --f46d044304ec4e135704baa12342
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes
> wrote:
> >
> >> On Wed, Mar 7, 2012 at 6:03 AM, Drak wrote:
On 7 March 2012 11:54, Kiall Mac Innes wrote:
> On Wed, Mar 7, 2012 at 6:03 AM, Drak wrote:
>
>> [snip]
>> Forcing pushes to one's own topic branches in one's own fork can be
>> acceptable providing
>> upstream maintainers know before merging (for example squashing some work
>> after peer review
Sent from my iPhone
在 2012-3-7，17:12，David Soria Parra 写道：
> On 2012-03-07, Kris Craig wrote:
>> --f46d044304ec4e135704baa12342
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes wrote:
>>
>>> On Wed, Mar 7, 2012 at 6:03 AM, Drak wrote:
>>>
On 2012-03-07, Kris Craig wrote:
> --f46d044304ec4e135704baa12342
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes wrote:
>
>> On Wed, Mar 7, 2012 at 6:03 AM, Drak wrote:
>>
> I know I keep promising to draft an RFC for this lol, so I'll make it
On Tue, Mar 6, 2012 at 10:09 PM, Kiall Mac Innes wrote:
> On Wed, Mar 7, 2012 at 6:03 AM, Drak wrote:
>
> > [snip]
> > Forcing pushes to one's own topic branches in one's own fork can be
> > acceptable providing
> > upstream maintainers know before merging (for example squashing some work
> > af
On Wed, Mar 7, 2012 at 6:03 AM, Drak wrote:
> [snip]
> Forcing pushes to one's own topic branches in one's own fork can be
> acceptable providing
> upstream maintainers know before merging (for example squashing some work
> after peer review), but not to the central repo without some exceptional
On 5 March 2012 03:15, David Soria Parra wrote:
> No. We will always need to be able to delete branches created, or tags
> (we had situations were we needed to retag, for example). That in
> itself can be used to do a forced push:
>
[snip]
> I am also not a strong believer trying to forbid as
I was about to respond to Lester's comments but it looks like Jeremiah beat
me to it (again). Yeah he's correct in that "bad habits" refers to using
Git the same way you would use Subversion. It was not mean to refer to how
you've used Subversion itself.
@David Generally, I would resolve this by
13 matches
Mail list logo
