Thanks, Leo
Yeah, being able to essentially "mark" a commit as NOT needing to be merged
(in fact, merging is wrong in this case) to a newer branch is key, I think,
to helping solve our branching issues.
On Fri, Oct 24, 2014 at 12:36 AM, Leo Simons
wrote:
> Hey Mike,
>
> In git you accomplish th
On Fri, Oct 24, 2014 at 8:36 AM, Leo Simons wrote:
> Hey Mike,
>
> In git you accomplish these kinds of things with merge strategies. There’s a
> lot to choose from. What you’re describing sounds a bit like a variant on the
> “theirs” strategy.
...
doh, will give it another spin. I used 'ours' i
Hey Mike,
In git you accomplish these kinds of things with merge strategies. There’s a
lot to choose from. What you’re describing sounds a bit like a variant on the
“theirs” strategy. You can also do a recursive merge with a “theirs” conflict
resolution choice, and there’s many other options. (
If we had something like that, then we could still have the general rule:
Everything put in 4.5 must be merged to master (but the person to merge
would have to decide if they just need to do a --record-only kind of merge).
On Thu, Oct 23, 2014 at 6:29 PM, Mike Tutkowski <
mike.tutkow...@solidfire
That would be way better than cherry picking since we could then trace
related commits across branches easily.
On Thu, Oct 23, 2014 at 6:30 PM, Mike Tutkowski <
mike.tutkow...@solidfire.com> wrote:
> If we had something like that, then we could still have the general rule:
>
> Everything put in 4
Maybe we need something like this in Git (maybe it's already there?):
http://stackoverflow.com/questions/18074697/subversion-mark-as-merged-without-changing-anything
The ability to record a commit has having been merged to another branch,
but nothing was really merged.
Then when you checked code
Just to be clear (I've now had a couple questions about this)
4.5 branch is still open for bug fixes from folks. It is closed to new
functionality/features, but remains open to bug fixes.
master already has a few new features in it (compared to 4.5)
Code freeze will happen for 4.5, but will be a
If we just did merges (instead of cherry picks) to 4.5, does Git allow us
to ONLY merge that particular (merge) commit from 4.5 to master?
In other words, I'd want to make sure we were only merging from 4.5 to
master what we want to (and, as I mentioned earlier, not bring along
commits to 4.5 that
On Thu, Oct 23, 2014 at 10:05 AM, Daan Hoogland wrote:
> not nice, so merge back is no longer an option. I think I am almost
> ready to admit to that.
>
>
I came to that conclusion a week or so ago.
If we could keep master as the release branch until we were imminently
releasing, it might not be
Yes, certain things checked into a version like 4.5 need to make sure they
never make it to master.
SVN has a way to mark a commit so it would not be merged to another branch
like master is for us. I don't know if I Git has such a feature.
On Thursday, October 23, 2014, Daan Hoogland
wrote:
> n
not nice, so merge back is no longer an option. I think I am almost
ready to admit to that.
On Thu, Oct 23, 2014 at 3:31 PM, Mike Tutkowski
wrote:
> Actually...this was a 4.5-only change.
>
> On Thursday, October 23, 2014, Daan Hoogland
> wrote:
>
>> great hope you didn't check it into master so
Actually...this was a 4.5-only change.
On Thursday, October 23, 2014, Daan Hoogland
wrote:
> great hope you didn't check it into master so wecan see if the merge
> strategy works:)
>
> On Wed, Oct 22, 2014 at 11:57 PM, Mike Tutkowski
> > wrote:
> > Just an FYI that I checked code directly into 4
great hope you didn't check it into master so wecan see if the merge
strategy works:)
On Wed, Oct 22, 2014 at 11:57 PM, Mike Tutkowski
wrote:
> Just an FYI that I checked code directly into 4.5 today, but it was only
> related to the SolidFire driver (no general-purpose CloudStack code was
> part
Just an FYI that I checked code directly into 4.5 today, but it was only
related to the SolidFire driver (no general-purpose CloudStack code was
part of the commit).
2d7187e002e6b5b164c226fdde994a3a92cb9dda
On Tue, Oct 21, 2014 at 10:50 AM, David Nalley wrote:
> We are well past feature freeze
Tutkowski
wrote:
> I would hold off on that, Edison.
>
> We need to make sure the policy is clear (and probably documented) first.
>
> On Tue, Oct 21, 2014 at 10:57 AM, Edison Su wrote:
>
>> Sorry, I am not aware of the 4.5 release policy, I'll revert my commits o
I would hold off on that, Edison.
We need to make sure the policy is clear (and probably documented) first.
On Tue, Oct 21, 2014 at 10:57 AM, Edison Su wrote:
> Sorry, I am not aware of the 4.5 release policy, I'll revert my commits on
> 4.5.
>
> > -Original Message
So, in the past, feature freeze has been when we branch from master (in
this case, 4.5) and then people check directly into 4.5 until the RM has
called code freeze (at which point, we started using that -forward concept).
Where did we land on that? Once code freeze has passed, do people need to
cr
Sorry, I am not aware of the 4.5 release policy, I'll revert my commits on 4.5.
> -Original Message-
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com]
> Sent: Tuesday, October 21, 2014 12:22 AM
> To: dev; David Nalley
> Subject: commits on 4.5
>
> David,
We are well past feature freeze - but I haven't started a hard code
freeze; though it is imminent.
--David
On Tue, Oct 21, 2014 at 12:46 PM, Mike Tutkowski
wrote:
> Hi Daan,
>
> Do you know if the check-in protocol for 4.5 (or rather for any branched
> release) is formally documented on the Wiki
Hi Daan,
Do you know if the check-in protocol for 4.5 (or rather for any branched
release) is formally documented on the Wiki somewhere?
If it's not, it's probably harder to "enforce" it.
Thanks!
Mike
On Tue, Oct 21, 2014 at 1:21 AM, Daan Hoogland
wrote:
> David,
>
> I keep seeing commits pas
David,
I keep seeing commits passing to the 4.5 branch. As you are the RM I am not
reverting them. Should I? Not one of them has come from a hotfix branch for
weeks.
--
Daan
21 matches
Mail list logo
