kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

I only need a snapshot of the current 4 stable branch r6308 tag 4.0.4.
I'm the only one with commit access so I can guarantee it wont change.
If you update your stable 4 branch, I'll pull this into my repo and then
push it to the kicad repo as the stable 4 branch and then make the bzr
stable 4 repo read only.  The help would be greatly appreciated.

Thanks,

Wayne

On 8/22/2016 2:12 PM, Niki Guldbrand wrote:
> Hi All.
> 
> I Have a copy of 4.0.x in my git repo at github [1], although I havent
> updated it in som time, but the setup is still there, I just need to
> install the git bzr plugin again, and I can keep it updated for some
> time if you wish ?
> 
> I also have an suggestion, that you might want to adopt the git flow
> development model, the github repo i [1] is setup for that, with the
> develop, and feature branches.
> It currently contains 2 feature branches I was considering sending
> patches in for.
> 
> [1] https://github.com/nikgul/kicad-source-mirror
> 
> 
> 
> On man, 2016-08-22 at 17:22 +0200, Nick Østergaard wrote:
>> FYI the guy syncing bzr to the kicad-source-mirror managed to make it
>> work. Although it seems like he only pushed the 4.0 branch once.
>> There is a 4.0 branch in that. (Sorry I don't remember his name
>> exactly now)
>>
>> Den 22/08/2016 16.34 skrev "Chris Pavlina" <pavlina.chris@xxxxxxxxx>:
>>> I'm used to git repo surgery enough to make the branch - if nobody
>>> else
>>> does it before I get out of work tonight, I'll do it then.
>>>
>>> As Shane says it should be very easy though, assuming there's
>>> nothing
>>> funny going on.
>>>
>>> On Mon, Aug 22, 2016 at 10:26:46AM -0400, Shane Burrell wrote:
>>>> It should be really easy.  Create a branch and overlay stable 4
>>> branch via
>>>> manual or checkout the hash mark you need and commit to branch. 
>>> I
>>>> typically do a develop branch (bleeding edge) and branch of
>>> stable without
>>>> any issues and created stable in same fashion the first time.
>>>>
>>>> On Mon, Aug 22, 2016 at 10:20 AM, Wayne Stambaugh <stambaughw@gma
>>> il.com>
>>>> wrote:
>>>>
>>>>> On 8/22/2016 10:13 AM, Chris Pavlina wrote:
>>>>>> On Mon, Aug 22, 2016 at 09:57:26AM -0400, Wayne Stambaugh
>>> wrote:
>>>>>>> On 8/22/2016 9:53 AM, Clemens Koller wrote:
>>>>>>>> Hi, Wayne!
>>>>>>>>
>>>>>>>> On 2016-08-22 14:09, Wayne Stambaugh wrote:
>>>>>>>>> I wasn't planning on migrating the stable 4 branch to
>>> git.  I'm hoping
>>>>>>>>> there wont be too many more 4 stable releases so I'm not
>>> sure it's
>>>>> worth
>>>>>>>>> the effort.
>>>>>>>>
>>>>>>>> Ok, I was wondering...
>>>>>>>> I was missing the stable branch, too - as well as all the
>>> tags of the
>>>>> old
>>>>>>>> releases, etc. I personally don't need them, but it could
>>> be useful
>>>>>>>> and interesting to get all former references (r6994, rev
>>> 6994,
>>>>> 4.0.0-rc...)
>>>>>>>> migrated over to the git side once.
>>>>>>>
>>>>>>> My one gripe about git is the commit hash tags.  They really
>>> are not
>>>>>>> very user friendly.  The tags you mention above are all in 4
>>> stable
>>>>>>> branch so if you continue to use bzr for the stable 4
>>> branch, you should
>>>>>>> not have any issues.  I will tag future stable versions in
>>> git when we
>>>>>>> get to that point so you will be able to use git tags in the
>>> same
>>>>>>> manner.  I'm not sure how maintaining a stable branch in git
>>> is going to
>>>>>>> work.  I'm guessing that it will be a completely separate
>>> repo like we
>>>>>>> do with bzr but I'm going to worry about that when the time
>>> comes.
>>>>>>
>>>>>> Personally I would do a stable branch as a literal branch in
>>> git rather
>>>>>> than a repository. This makes it much easier to move code
>>> between the
>>>>>> branches - when you want to pull a commit onto stable, just
>>> 'git
>>>>>> checkout stable' and 'git cherry-pick 1234567'. Makes it easy
>>> for
>>>>>> developers to switch between them, as well - I would very
>>> much
>>>>>> appreciate stable being a proper branch as it would make
>>> developing
>>>>>> fixes on stable and forward-porting them to devel, as you
>>> said we
>>>>>> should, much simpler.
>>>>>>
>>>>>> I suspect most developers familiar with git will be strongly
>>> in favor of
>>>>>> this - it's how branches are meant to work in git. Fairly
>>> standard
>>>>>> workflow.
>>>>>>
>>>>>> Then just use tags to mark releases in the stable branch.
>>>>>>
>>>>>> Easy as pie. :)
>>>>>
>>>>> For future stable releases, this is fine but I don't think
>>> there is any
>>>>> easy way to reassemble the separate bzr stable 4 branch into a
>>> git
>>>>> branch that we could commit to the main development repo.  If
>>> someone
>>>>> knows of an easy way to do this or better yet actually creates
>>> the
>>>>> branch, I would be more that happy to start using git to track
>>> the
>>>>> stable 4 branch.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Clemens
>