On Mon, Nov 7, 2011 at 3:11 PM, Mikko Rapeli wrote:
> Which is why I have had problems with NetBSD: bad breaking commits were left
> in the CVS tree instead of reverted once users started complaining.
Pointless, FreeBSD != NetBSD. :)
> Sometimes commits, say a new feature or rewrite, looks good
On Mon, Nov 07, 2011 at 03:00:33PM +0100, Alberto Villa wrote:
> On Mon, Nov 7, 2011 at 9:56 AM, Mikko Rapeli wrote:
> >> Reverting sets of commits is definitely not a solution.
> >
> > Yes it is. If a set of commits breaks other functionality, those patches
> > should either be fixed or reverted.
On Mon, Nov 7, 2011 at 9:56 AM, Mikko Rapeli wrote:
>> Reverting sets of commits is definitely not a solution.
>
> Yes it is. If a set of commits breaks other functionality, those patches
> should either be fixed or reverted. That's how Linux kernel is maintained.
This is not a good point to disc
On Mon, Nov 07, 2011 at 12:15:47AM +0100, Alberto Villa wrote:
> On Friday 04 November 2011 15:51:30 Mikko Rapeli wrote:
> > Branching, merging and rebasing (fast forwarding branches to newer
> > baseline) are so easy in git that they don't need to be defined. Just
> > treat git master branch as sv
On Friday 04 November 2011 15:51:30 Mikko Rapeli wrote:
> Branching, merging and rebasing (fast forwarding branches to newer
> baseline) are so easy in git that they don't need to be defined. Just
> treat git master branch as svn trunk, but revert commits or features if
> they cause problems, and u
On Friday 04 November 2011 16:19:34 Yuri Chornoivan wrote:
> It can be done on the translation side (just add CCMAIL:
> kde-i18n-...@kde.org to the commit message when creating the
stable branch
> to let translation coordinator that stable translation should be
switched
> to the stable branch [1]
On Friday 04 November 2011 15:55:19 jb wrote:
> Thanks for the explanations! I now have read your mail 3 times and I
think
> I understood!
Eheh, sorry! :D
> So if I put it in other words, it would work like this:
>
> * If I want to fix a simple thing:
>
> - I work on it on my local copy of mas
написане Fri, 04 Nov 2011 16:55:19 +0200, jb :
> 1) What about string freeze? My proposal to wait a few weeks before
> merging
> new features after a release was to make sure that no new string is
> introduced
> if we make a .1 release. But then it would block development, so I think
> that
On Friday 04 November 2011 15:11:40 you wrote:
> On Friday 04 November 2011 15:05:18 Alberto Villa wrote:
> > Last case I can think of: *.1 revision. You tag 0.x.y from master, and
> > then merge feature A to it. But people starts screaming that 0.x.y
> > removes root partition. So you checkout tag
Just my 2¢:
I've followed mlt and kdenlive from git past few years and developed some
fixes in feature branches, and if needed rebased those fixes to newer master
branch versions.
Branching, merging and rebasing (fast forwarding branches to newer baseline)
are so easy in git that they don't need
On Friday 04 November 2011 15:05:18 Alberto Villa wrote:
> Last case I can think of: *.1 revision. You tag 0.x.y from master, and then
> merge feature A to it. But people starts screaming that 0.x.y removes
> root partition. So you checkout tag 0.x.y (all these tasks are *instant*
in
> Git), branc
On Friday 04 November 2011 09:23:09 Simon A. Eugster wrote:
> Hey Alberto, hey jb!
>
> On 11/03/2011 04:36 PM, jb wrote:
> > I have no experience with git, so I am not the best person to
comment.
> > However it seems a good idea to have "master" that would always be
in a
> > "releasable" state (
Hey Alberto, hey jb!
On 11/03/2011 04:36 PM, jb wrote:
> On Thursday 03 November 2011 08:49:22 Alberto Villa wrote:
>> Hi all!
>>
>> To complete svn2git rules I need your opinion on what will be our
>> preferred workflow in Git.
>>
>> First thing first, have a look here:
>> http://community.kde.or
On Thursday 03 November 2011 08:49:22 Alberto Villa wrote:
> Hi all!
>
> To complete svn2git rules I need your opinion on what will be our
> preferred workflow in Git.
>
> First thing first, have a look here:
> http://community.kde.org/KDE_Core/Platform_11/Git_Workflow
>
> We could adopt it comp
14 matches
Mail list logo
