<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">
Hi,</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">
thank you for the interesting discussion. I just wanted to follow up on the comment about VS Code. It is really easy to set it up to work via SSH seamlessly as you would on a local computer. You can follow the guide here:
<a href="https://code.visualstudio.com/docs/remote/ssh" id="LPlnk530187">https://code.visualstudio.com/docs/remote/ssh</a>. You can also use the official extension for C/C++ to get auto-completion, Intellisense squiggles, etc. If you are on Windows and want
to use your local PC, developing in WSL has also worked for me perfectly (after building the toolchain from source).</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">
Regards,</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Arial, Helvetica, sans-serif; font-size: 10pt; color: rgb(0, 0, 0);">
OR<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> NSWI004 <nswi004-bounces@d3s.mff.cuni.cz> on behalf of Vojtech Horky <horky@d3s.mff.cuni.cz><br>
<b>Sent:</b> Monday, November 9, 2020 10:32 AM<br>
<b>To:</b> nswi004@d3s.mff.cuni.cz <nswi004@d3s.mff.cuni.cz><br>
<b>Subject:</b> Re: [NSWI004] Several notes on Git, GitLab and CI</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Hello.<br>
<br>
Dne 09. 11. 20 v 9:51 Luká¹ Bastián napsal(a):<br>
> Hi,<br>
> <br>
> might have some additional questions and remarks regarding the git <br>
> workflow that you want us to use:<br>
> <br>
> 1. One of the ways to develop is to have so-called feature branches - <br>
> the problem with those is commits can add up and to keep master clean <br>
> after merging the pull request (or merge request on GitLab) you should <br>
> squash the commits but that is messing with the history if multiple <br>
> people committed to the feature branch (I don't think it does on GitHub <br>
> but on GitLab, I think I saw it happening). How should we deal with <br>
> that? Should we use squash or does it impact the grading script? <br>
> (Depending on the answer I might need to contact you separately and <br>
> solve some issues with points).<br>
<br>
Personally, I am not a big fan of commit squashing - you should keep <br>
even your feature branch in such state that merging it as is (with <br>
--no-ff) should not break things. I have no problem with history changes <br>
in not-yet-merged branches.<br>
<br>
We definitely do not enforce that you have to squash/rebase/... in your <br>
team or even use branches. Use what you like, what you are comfortable with.<br>
<br>
However, our activity points scripts are counting only commits that made <br>
it into master. Hence, if you squash your branch, you will have only one <br>
commit. I do not think it is possible to count it in any other way (i.e. <br>
no way to see the commits before the squash as the branch would seem <br>
dead or would be GCed anyway).<br>
<br>
If squashing the commits is a big deal and you want to have it, let's <br>
see how the points will look at the end of the semester. If you would <br>
(by then) miss some points, we can look at the merge requests and <br>
manually recompute.<br>
<br>
<br>
> It is a good practice to always commit code that compiles. For<br>
> master/main branch, the rule is usually to commit code that compiles and<br>
> passes the tests.<br>
> <br>
> In this case, this means completing the task - which doesn't go hand in <br>
> hand with the fact that you are trying to get us to collaborate and <br>
> "work as a team in a real company" (or at least that's what I felt like) <br>
> - I wouldn't be able to reasonably share code with my colleagues - there <br>
> are ways to get around this by having let's say a02-master and we all <br>
> branch from there but that might be problematic again when it comes to <br>
> what I mentioned above - squash on merge and the change of author when used.<br>
<br>
The word usually applies here. Note that some of your colleagues are <br>
seeing Git for the first time in this course hence I decided to add what <br>
is the usual rule in long-running projects. I.e. there is a difference <br>
when your project is being born and thousands of lines are added <br>
compared to a maintenance of a mature project. Sorry, I should have made <br>
this point more clear.<br>
<br>
<br>
> As a matter of fact, if you commit/push every minute to debug your<br>
> knowledge of C syntax and/or for every word in one code comment, two<br>
> things may happen. We may consider this as a gaming of the activity<br>
> points. And we might be forced to setup some type of accounting for the<br>
> use of CI to ensure fairness (I already received a complaint from GitLab<br>
> administrator about overloading the CI machines).<br>
> <br>
> Is there a way to set up the CI so that doesn't build before opening a <br>
> PR or that it cancels the previous pipeline if a new commit is made? <br>
> That is the approach that is used in the company I work for to prevent <br>
> what we are encountering here. At least on the feature branches - master <br>
> should always run with each commit/merge given the small team size - <br>
> there is also the option to make the build periodical if there were <br>
> changes in the last X amount of time.<br>
<br>
The pipelines are configured that redundant jobs shall be canceled <br>
automatically. You can also add interruptible [1] flag to CI manually.<br>
<br>
[1] <a href="https://gitlab.mff.cuni.cz/help/ci/yaml/README.md#interruptible">https://gitlab.mff.cuni.cz/help/ci/yaml/README.md#interruptible</a><br>
<br>
But I do not think it should be necessary. If you work normally and <br>
simply do not push every commit (if you are in a private feature branch, <br>
there really is no reason to do so) all should be fine.<br>
<br>
<br>
> Mostly my comments come from a place of<br>
> a) interest and previous experience with some GitHub workflows - from <br>
> what I see the unit of work in your opinion should be a commit which in <br>
> my opinion is not easily accessible given the nature of the task and the <br>
> need to collaborate - I am used to using a PR as a unit of work which <br>
> would probably require some changes in the CI pipeline.<br>
<br>
I am not sure I follow what you mean by your understanding of PR.<br>
<br>
However, I strongly believe that commit should represent a logical unit <br>
of change. In this sense: if I add a code that detects available memory, <br>
it is a logical unit even if all tests still fail.<br>
<br>
And personally I would add it directly to master as it will be needed by <br>
my team mates very soon. But I would create a PR later on when <br>
refactoring the code.<br>
<br>
<br>
> And also b) slight frustration because I am one of the ones that were <br>
> probably overloading the GitLab machines (although I tried to minimize <br>
> it once I had a look at the queue, saw what was happening, and was <br>
> canceling some runs manually) - but the reason for it was that the <br>
> instructions on how to reproduce the dev environment on a local Linux VM <br>
> were not enough for me to successfully do it so I develop on a feature <br>
> branch in the mentioned VM which gives me more freedom when it comes to <br>
> reasonable IDE etc, push whenever I want to because I will open a PR and <br>
> squash anyway, and then pull the branch on a Rotunda machine and debug <br>
> and test there. The CI run results are not really what interests me at <br>
> that point but they run every time (hence my comments about automatic <br>
> cancellation on a new commit) and when I included some printing the logs <br>
> were getting out of hand (which is probably where most of the pressure <br>
> on the GitLab CI machine comes from - the amount of logs generated).<br>
<br>
I am sorry to hear that the instructions were not clear enough. Perhaps <br>
can you elaborate on this a bit more?<br>
<br>
You can also disable CI for a specific commit but I believe that if you <br>
are using Git to synchronize code between two machines to only allow you <br>
to code on one and test on another (if I understand the issue <br>
correctly), then your setup should be fixed first. Just to make it more <br>
comfortable for you.<br>
<br>
Note that you can also mount the remote disks via SSHFS and VSCode can <br>
also work in remote mode somehow. Perhaps your colleagues that are using <br>
it that way (I see several .vscode directories on lab.d3s) can share <br>
some links and comments about this.<br>
<br>
Hope this explain things a bit more.<br>
<br>
Cheers,<br>
- VH<br>
<br>
<br>
> <br>
> Looking forward to your reply hoping it will bring more clarity so I can <br>
> adjust and prevent future problems of this nature.<br>
> <br>
> Regards<br>
> Luká¹ Bastián<br>
> <br>
> <br>
> On Mon, Nov 9, 2020 at 7:07 AM Vojtech Horky <horky@d3s.mff.cuni.cz <br>
> <<a href="mailto:horky@d3s.mff.cuni.cz">mailto:horky@d3s.mff.cuni.cz</a>>> wrote:<br>
> <br>
> Hello,<br>
> <br>
> just few notes in no particular ordering.<br>
> <br>
> It is possible to setup your Git commit identity (e-mail) in GitLab<br>
> instead of the default one.<br>
> <br>
> When you are using Git for the first time on a given machine (e.g.<br>
> lab.d3s.mff.cuni.cz <<a href="http://lab.d3s.mff.cuni.cz">http://lab.d3s.mff.cuni.cz</a>> or Rotunda<br>
> servers), you should set your Git name<br>
> and e-mail via "git config" command (probably with the --global<br>
> switch).<br>
> Note that Git will warn you during every commit that you have not<br>
> done so.<br>
> <br>
> It is a good practice to always commit code that compiles. For<br>
> master/main branch, the rule is usually to commit code that compiles<br>
> and<br>
> passes the tests.<br>
> <br>
> GitLab CI is not your development environment. You are supposed to<br>
> develop, debug and test on your machine and push to GitLab only<br>
> reasonable commits. There is no reason to push every single commit to<br>
> GitLab to see whether it compiles.<br>
> <br>
> As a matter of fact, if you commit/push every minute to debug your<br>
> knowledge of C syntax and/or for every word in one code comment, two<br>
> things may happen. We may consider this as a gaming of the activity<br>
> points. And we might be forced to setup some type of accounting for the<br>
> use of CI to ensure fairness (I already received a complaint from<br>
> GitLab<br>
> administrator about overloading the CI machines).<br>
> <br>
> Note that it is completely fine and highly recommended to create very<br>
> small, focused commits but each commit should represent a<br>
> compact/logical/atomic change of your project. Think always about a<br>
> reviewer that clicks on your commit - are there only changes related to<br>
> the topic and are there all the changes related to the topic?<br>
> <br>
> Note that "git add -p" allows you to split big change into multiple<br>
> commits quite easily.<br>
> <br>
> As a further reading, I would recommend [1] about good commit messages<br>
> and perhaps [2] as well as it reiterates some notes about committing in<br>
> general.<br>
> <br>
> [1] <a href="https://chris.beams.io/posts/git-commit/">https://chris.beams.io/posts/git-commit/</a><br>
> [2]<br>
> <a href="https://koukia.ca/git-some-commit-best-practices-and-how-to-undo-your-recent-commits-d13c9dc3144f">
https://koukia.ca/git-some-commit-best-practices-and-how-to-undo-your-recent-commits-d13c9dc3144f</a><br>
> <br>
> Hope this helps,<br>
> - VH<br>
> _______________________________________________<br>
> NSWI004 mailing list<br>
> NSWI004@d3s.mff.cuni.cz <<a href="mailto:NSWI004@d3s.mff.cuni.cz">mailto:NSWI004@d3s.mff.cuni.cz</a>><br>
> <a href="https://d3s.mff.cuni.cz/mailman/listinfo/nswi004">https://d3s.mff.cuni.cz/mailman/listinfo/nswi004</a><br>
> <br>
> <br>
> _______________________________________________<br>
> NSWI004 mailing list<br>
> NSWI004@d3s.mff.cuni.cz<br>
> <a href="https://d3s.mff.cuni.cz/mailman/listinfo/nswi004">https://d3s.mff.cuni.cz/mailman/listinfo/nswi004</a><br>
> <br>
_______________________________________________<br>
NSWI004 mailing list<br>
NSWI004@d3s.mff.cuni.cz<br>
<a href="https://d3s.mff.cuni.cz/mailman/listinfo/nswi004">https://d3s.mff.cuni.cz/mailman/listinfo/nswi004</a><br>
</div>
</span></font></div>
</body>
</html>