In many parts of the dev world - every commit should be shippable, meaning atomic - particularly with the use of CI systems (Travis, Gitlab etc) that build on every commit. Of course you can choose to work a different way - but our tools shouldn’t force a very common practice to be awkward, should they? I don’t understand why many of you guys are so anti such a common thing. In fact our community pioneered this way of working - a build machine where you loaded all your code and ran all your tests before committing. Also, a large number of agile teams will council to work on master (and avoid branches - a technique we also pioneered). In today’s world where we live in a wider polyglot stack this is one of the reasons why git is so attractive as it should easily embraces that. I get that it’s not quite possible yet - but there are some decent ways to accommodate this (a staging operation, or perhaps a better way to make use of the #addToIndex: which I will experiment with). Anyway, I’ll shut up - and possibly will learn how to implement it myself. Thinking more, I may also be able run with commit and no push , which I will try - as it’s probably the easiest mechanism if the CI will recognise that (I think it will). Thanks for the enlightening conversation, and as always the hard work on iceberg that made this conversation even possible. Tim Sent from my iPhone
|
Hi Tim,
On Fri, Jun 15, 2018 at 10:31 AM Tim Mackinnon <[hidden email]> wrote:
Please don't shut up ^^. I really value the feedback. I see myself the value of both small and atomic/self-contained/complete commits. In general what happens is that we are few modifying iceberg. But on the other side we really had given a thought to many of these topics, and many decisions had a reason (even if it is that it is not implemented because it would be too much work :)). I try to explain them as better as I can, I can probably do better :) |
In reply to this post by Tim Mackinnon
but then, you mean every *push* should be shippable :) that’s something I agree :)
I’m not anti. Being “anti” requires a lot of effort I prefer to spend on something else :) But in general, I prefer many small commits of tasks. And yes, I prefer those commits to be atomic, but when is not possible I just make sure I do not push until something is finished.
hah… we pioneered it as a technique basically because our tools were not capable of branching properly, but well, It can be a way to minimise integration problems, yes (depends on the team, of course).
I think the easiest/fastest way to handle this is to add a “special commit” plugin which could export sources and then delegate commit to an external tool. And it could be a plugin because then people wanting to work with it can load it independently.
do not shut up :) your opinions and considerations are good and a good way to see a different pov that may be better than ours.
thank you
|
In reply to this post by Tim Mackinnon
To be honest I don’t like such comments. Do you have a proof for „many parts of the world“? I do not get why every commit should be shippable. To me it sounds like a misplaced constraint. And for every project that is not pretty simple I doubt it can work at all. Commits are commits and a shippable product is shippable product not much in common. Again. Where is this common practice? You cannot just state such things without proof in order to back your argument. I can see that in some scenarios it comes in handy that such commits ease some things. But I do not agree to see that this is or should be the common case. I don’t think I am anti. I don’t get your point making this a common thing. I think that wanting commits spawning multiple repos is much more common. No, do no shut up. Just proof your point. We cannot support every possible use case. Norbert
|
In reply to this post by EstebanLM
The way we run projects - pushing to master is forbidden. You push your work to a feature specific branch, a CI server runs all the tests in the branch every push. We create pull requests from the github project page, people review them and when the tests are green and reviewers approve, we perform the merge on github. Never touch master (or whatever branch you pick for main trunk) outside of github. Always perform new work in new branch. |
Tod/Norbert - I won’t shy away from answering your comments on this - but if its ok - lets move that conversation to a new thread. I don’t want to distract away from how one actually does some form of atomic checkin (and I’m talking a small one - one Smalltalk class, one associated text file).
I earlier tried doing a change on a class - committing, but not pushing and then switching to IntelliJ to then commit and push my config file change - and it didn’t seem to work - which surprised me, so I’m gong to redo my test again with the the latest Iceberg 1.1 in a new image (and also make sure my IntelliJ is attached to the same local repo). This seems like the closest root to how I would like to work (albeit a slightly bit more complicated than I would like, but certainly doable). Tim
|
In reply to this post by tblanchard
Phew - I can confirm that (unsurprisingly I guess) - just committing in Iceberg (without ticking - push changes to origin/master) does then let you easily overlay the same checked out project (typically ./iceberg/ProjectName) in a tool like VSCode or IntelliJ where you can then also commit further changes to files that Iceberg is ignoring (essentially everything not in the src directory - typically candidates would be your Readme.md file and possibly a ./scripts or ./assets directory).
In that other tool you can then issue a push which will then atomically push all commits to a pipeline. It can be a little more tricky to understand what the pipeline is building - in Gitlab it will show you the comment of the most recent commit in the pipeline, however if you then click on the branch the pipeline is running on, you will get a list of commits and can see all the commits that are between the running pipeline and the previously run pipeline. For many of you - this might be pleadingly obvious - but when you have a different workflow mindset in your head, it might be trickier to spot this subtlety. Tim p.s. Thanks for all the useful debate in this thread. I should add that when I wrote “I’ll shut up” - a meant more that I felt the conversation was going in a cycle and repeating itself, not that I was offended or frustrated. I can probably live with the above nuance for my desire for atomic commits. p.p.s It hadn’t occurred to me that the most common use case where people will hit a similar problem to me - is that Readme.md file. Definitely that is one where it should possibly automatically added to the index, or catered for - as it is really just a text file right?
|
On 15/06/2018 20:00, Tim Mackinnon wrote:
> Phew - I can confirm that (unsurprisingly I guess) - just committing in > Iceberg (without ticking - push changes to origin/master) does then let > you easily overlay the same checked out project (typically > ./iceberg/ProjectName) in a tool like VSCode or IntelliJ where you can > then also commit further changes to files that Iceberg is ignoring > (essentially everything not in the src directory - typically candidates > would be your Readme.md file and possibly a ./scripts or ./assets > directory). That could work as a *workaround* to a design decision that made the image the "staging" of a git commit. > In that other tool you can then issue a push which will then atomically > push all commits to a pipeline. It can be a little more tricky to > understand what the pipeline is building - in Gitlab it will show you > the comment of the most recent commit in the pipeline, however if you > then click on the branch the pipeline is running on, you will get a list > of commits and can see all the commits that are between the running > pipeline and the previously run pipeline. > > For many of you - this might be pleadingly obvious - but when you have a > different workflow mindset in your head, it might be trickier to spot > this subtlety. But it's not what I'd expect when using git, in particular if you use commit commands and/or CI, because if you add a comment like like "Fixes Issue #2345" in your Iceberg commit, then your secondary commit (the one done "externally" will look detached, you should replicate the commit comment, so your CI will show the comment of the commit on which it's building, etc. Git favors small commits, but other tools expect atomic commits. They're not exclusive. > p.s. Thanks for all the useful debate in this thread. I should add that > when I wrote “I’ll shut up” - a meant more that I felt the conversation > was going in a cycle and repeating itself, not that I was offended or > frustrated. I can probably live with the above nuance for my desire for > atomic commits. We're grown ups trying to improve Pharo, so unless stated otherwise or clear agressions are visible (ad-hominems, passive agressiveness, etc.), it's healthier to assume all comments are honest, constructive and with good intentions. Let's avoid the meta-disussion. :) Regards, -- Esteban A. Maringolo |
Free forum by Nabble | Edit this page |