>
> You are right, Peter. But the way the rest of the world (and many people
> using git from Pharo or other Smalltalk implementations) is that you
> propose patches which I believe are quite similar to commits. That would be
> the equivalent of our slice, I guess.


I don't think that slice has equivalence in git, because we have changes
much more fine-grained.
Git patch is simply a diff between two different versions. And even though
github (or bitbucket) offer things like "pull requests", they are only a
nicer way of presenting a diff.
But this doesn't really matter, because the result will be still the same.

Now what might be an interesting work flow would be when an issue is tagged
> Fix Review Needed and the CI monkey validates the issue it pushes the slice
> to a new IssueNNNNN branch in github and branch diff emailed from there.


Unless we want to migrate from fogzbugz to github and do code-reviews there
in pull requests there's really no reason to create new branches. You can
just create detached commits. (But then again, creating branches is dirt
cheap). Actually for a diff you don't need to even commit, because you can
compare your current code to the commited one (just like in Monticello).

Peter

Reply via email to