开云体育

[email protected]> wrote: This last one is another common usage for me: when I struggle to integrate with Someone Else's Stuff, I often interleave writing a bit of my domain code with writing a bit

wrote: I do. I mostly amend the most-recent commit because "Oh, shit, I meant to do that, too", such as cleaning up import statements or realizing that I made a change in 3 places and missed the

wrote: The poster child environment for this trick is embedded / real time / multithreaded. The further you're away from that the less benefit it provides. On an embedded target events are firing

on top of the mainline, it would rebuild and check _every_ changeset. But that's a lot of compute power and tooling. That system exists: https://www.gerritcodereview.com/ Arnaud >

I'm still trying to grok all this, despite having no earthly reason ever to do it ... I think I don't get how you use it as well as why. Will ask essentially the same question every time: how does

Partly the invariant... the rule for playing this game is keep _every_ point on the branch green. Ideally you would have a magic CI system that if, for example, you rebase on top of the mainline, it

I see the benefit of being able to take a subset of changes which matches when you made your changes and push those changes safely up the stack. You really need to be working with a number of teams to

It's not the pretending so much as making the commit history tell an easy to understand (well organized) story about what changes were being made to the code.? The extreme opposite is a commit

more I want it to be correct. That means it should reflect what I did in the order that I did it. I admit I used to do that, I wanted the commit log to be static so it reflected the experimentation

I'm with Ron on this. I want the history to be clean, for sure, but even more I want it to be correct. That means it should reflect what I did in the order that I did it. For example, maybe I got

Hi Al, sent from iPad, probably via Mars. Errors, if any, are not mine. ronjeffries@... is a better address for me, maybe. Yes, sounds similar. Why do you want to pretend those things? Do you go

I can't remember or quickly find the blog post where I first saw it espoused to treat your private "feature" (in Git Flow terminology) as your own to rewrite commit history as you wish. I do it very

Hi Edwin, Do you actually edit / add to anything but the tip of your branch? If so, why? If not, what advantage do you get from pushing some change backward in time? Thanks, Ron

Thanks, can you add a small running example along the post? so it will be more realistic and concrete

I fail to understand what this is all about. Do you have a concrete example, with actual code, somewhere? -- Arnaud Bailly - @dr_c0d3 [email protected]> wrote:

This was an interesting formalism of what I, and most of my co-workers, already do with our VCS of choice. I think the "A-ha!" moment for me was when I realized that pushing my own branch does not

As with many things, this technique becomes more or less compelling depending on your situation. The larger the herd of cats you're working with, the more compelling. ie. If you hang off the

John, I confess I'm not seeing the shine on this. I freely grant that I'm not doing any version control with a team of people, so that could be the whole reason. However, it seems to me that if the

So there is a new tool on the block that permits new approaches to software development. This is my first attempt at describing what can be done with it. Ultimately this will grow in a blog post and

Thanks, everyone for your feedback/comments. So far a couple of interesting ideas and thoughts that I could apply for our team: 1) extract sql formatting to its own class (which is what we did and