You then fetch and repair
your local version and try again.
This breaks your model of applying every commit ref by ref.
I'm all for trying to avoid extra work/stability but we already have
added a layer of testing every change before commit. I'm not going to
accept we need to also add a layer of testing before every merge.
On Thu, May 7, 2015 at 10:36 AM, Benedict Elliott Smith
<belliottsm...@datastax.com> wrote:
>>
>> wouldn't you need to force push?
>
>
> git push --force-with-lease
>
> This works essentially like CAS; if the remote repositories are not the
> same as the one you have modified, it will fail. You then fetch and repair
> your local version and try again.
>
> So what does this buy us?
>
>
> This buys us a clean development process. We bought into "always
> releasable". It's already a tall order; if we start weakening the
> constraints before we even get started, I am unconvinced we will
> successfully deliver. A monthly release cycle requires *strict* processes,
> not *almost* strict, or strict*ish*.
>
> Something that could also help make a more streamlined process: if actual
> commits were constructed on development branches ready for commit, with a
> proper commit message and CHANGES.txt updated. Even more ideally: with git
> rerere data for merging up to each of the branches. If we had that, and
> each of the branches had been tested in CI, we would be much closer than we
> are currently, as the risk-at-commit is minimized.
>
> On Thu, May 7, 2015 at 2:48 PM, Jake Luciani <jak...@gmail.com> wrote:
>
>> git rebase -i trunk_staging <ref~1>
>> fix the problem
>> git rebase --continue
>>
>> In this situation, if there was an untested follow on commit wouldn't
>> you need to force push?
>>
>> On Thu, May 7, 2015 at 9:28 AM, Benedict Elliott Smith
>> <belliottsm...@datastax.com> wrote:
>> >>
>> >> If we do it, we'll end up in weird situations which will be annoying for
>> >> everyone
>> >
>> >
>> > Such as? I'm not disputing, but if we're to assess the relative
>> > strengths/weaknesses, we need to have specifics to discuss.
>> >
>> > If we do go with this suggestion, we will most likely want to enable a
>> > shared git rerere cache, so that rebasing is not painful when there are
>> > future commits.
>> >
>> > If instead we go with "repairing" commits, we cannot have a "queue" of
>> > things to merge up to. Say you have a string of commits waiting for
>> > approval C1 to C4; you made C1, and it broke something. You introduce C5
>> to
>> > fix it, but the tests are still broken. Did you not really fix it? Or
>> > perhaps one of C2 to C4 are to blame, but which? And have you
>> accidentally
>> > broken *them* with your commit? Who knows. Either way, we definitely
>> cannot
>> > fast forward. At the very best we can hope that the new merge did not
>> > conflict or mess up the other people's C2 to C4 commits, and they have to
>> > now merge on top. But what if another merge comes in, C6, in the
>> meantime;
>> > and C2 really did also break the tests in some way; how do we determine
>> C2
>> > was to blame, and not C6, or C3 or C4? What do the committers for each of
>> > these do? We end up in a lengthy tussle, and aren't able to commit any of
>> > these to the mainline until all of them are resolved. Really we have to
>> > prevent any merges to the staging repository until the mistakes are
>> fixed.
>> > Since our races in these scenario are the length of time taken for cassci
>> > to vet them, these problems are much more likely than current race to
>> > commit.
>> >
>> > In the scheme I propose, in this scenario, the person who broke the build
>> > rebases everyone's branches to his now fixed commit, and the next broken
>> > commit gets blamed, and all other commits being merged in on top can go
>> in
>> > smoothly. The only pain point I can think of is the multi-branch rebase,
>> > but this is solved by git rerere.
>> >
>> > I agree running tests is painful, but at least for the build, this should
>> >> be the responsibility of the committer to build before merging
>> >
>> >
>> > Why make the distinction if we're going to have staging commits? It's a
>> bit
>> > of a waste of time to run three ant real-clean && ant tasks, and
>> increases
>> > the race window for merging (which is painful whether or not involves a
>> > rebase), and it is not a *typical* occurrence ("alarming" is subjective)
>> >
>> > On Thu, May 7, 2015 at 2:12 PM, Sylvain Lebresne <sylv...@datastax.com>
>> > wrote:
>> >
>> >> > If one of them breaks, we go and edit the _staging branch in place to
>> >> correct
>> >> > the problem, and let CI run again.
>> >>
>> >> I would strongly advise against *in place* edits. If we do it, we'll
>> end up
>> >> in
>> >> weird situations which will be annoying for everyone. Editing commits
>> that
>> >> have
>> >> been shared is almost always a bad idea and that's especially true for
>> >> branch
>> >> that will have some amount of concurrency like those staging branches.
>> >>
>> >> Even if such problems are rare, better to avoid them in the first place
>> by
>> >> simply
>> >> commit new "fixup" commits as we currently do. Granted this give you a
>> >> slightly
>> >> less clean history but to the best of my knowledge, this hasn't been a
>> pain
>> >> point so far.
>> >>
>> >> > wait for CI; all clear
>> >> >
>> >> > git checkout cassandra-2.0; git merge cassandra-2.0_staging
>> >> > git checkout cassandra-2.1; git merge cassandra-2.1_staging
>> >> > git checkout trunk; git merge trunk_staging
>> >> >
>> >> > This does introduce some extra steps to the merge process
>> >>
>> >> If we do this, we should really automate that last part (have the CI
>> >> environment merge the staging branch to the non-staging ones on
>> success).
>> >>
>> >> > It seems if we want an "always releasable" set of branches, we need
>> >> something
>> >> > along these lines.
>> >>
>> >> Agreed as far as having staging branches vetoed by CI goes. Less sure
>> about
>> >> the edit-commit-in-place part as said above.
>> >>
>> >> > I certainly break tests by mistake, or the build itself, with alarming
>> >> regularity.
>> >>
>> >> I agree running tests is painful, but at least for the build, this
>> should
>> >> be
>> >> the responsibility of the committer to build before merging. We all
>> forget
>> >> it from
>> >> times to times and that's ok, but it's not ok if it's "alarmingly
>> regular".
>> >>
>> >> --
>> >> Sylvain
>> >>
>>
>>
>>
>> --
>> http://twitter.com/tjake
>>
--
http://twitter.com/tjake
