• 0 Posts
  • 18 Comments
Joined 2 years ago
cake
Cake day: June 11th, 2023

help-circle


  • I found basic functioning of worktrees to fail with submodules. The worktree doesn’t know about submodules, and again and again messes up the links to it. Basic pulling, switching branches, …, all of this frequently fails to work because the link to the submodule is broken. I ended up creating the submodules as worktrees of a separate checkout of the submodule repo, and recreating these submodule worktrees over and over. I pretty much stopped using worktrees at that point.

    Have you tried the global git config to enable recursive over sub modules by default?

    Nope, fingers crossed it helps for you ;) Unrelated to worktrees but: in the end I like submodules in theory but found them to be absolutely terrible in practice, that’s without even factoring in the worktrees. So we went back to a monorepo.


  • I’m a C++ dev, I have one checkout of the main repo and 3 worktrees. Switching branches can be expensive because of recompiles, so to do e.g. quick fixes I’ll use worktree 1 where I typically don’t even compile the code, just make the fix and push it to the CI system. Worktrees 2 and 3 I keep at older releases so I can immediately fire up development and one of those releases side by side and compare results as well as the code.

    The cool thing about worktrees instead of multiple checkouts is that you only have one .git folder, so less disk space. But more importantly local branches (well everything actually) are shared, so you can create a local branch in the main checkout, and later come back to it in a worktree. You also don’t need fetching/… in the worktrees, as they share the same .git folder.

    Only thing that I found virtually impossible to work with is worktree + submodules.





  • As a researcher: all the professional software engineers here have no idea about the requirements for code in a research setting.

    As someone with extensive experience in both: my first requirement would be readability. Single python file? Fine with that. 1k+ lines single python file without functions or other means of structuring the code: please no.

    The nice thing about python is that your IDE let’s you jump into the code of the libraries you’re using, I find that to be a good way to look at how experienced python devs write code.


  • Odd take imo. OP is a programmer, albeit perhaps not a very good one. Did a PhD (computational astrophysics), been working as a professional dev for 10 years after that. Imo a good programmer writes code that solves the problem at hand, I don’t see that much of a difference between the problem being scientific or a backend service. It doesn’t mean “write lots of boilerplate-y factories, interfaces and other layers” to me, neither in research nor outside of it.

    That being said, there is so much time lost in research institutes because of shoddy programming by researchers, or simply ignorance, not knowing a debugger exists for instance. OP wanting to level up their game would almost certainly result in getting to research results faster, + they may be able to help their peers become better as well.







  • I think motivation is a bit more nuanced than that. Also what is said isn’t restricted to programmers. Money is an external motivator, which means it isn’t really motivating as in providing fulfillment and energy when doing a job. It can give you a reason to to the job, “it pays the bills” or “it pays the bills extremely well”, but that’s something different.

    That being said, I do look for jobs where I am motivated about the projects and the environment. In fact this is the main thing I evaluate when applying for a position. I also expect to be (and am) well-paid but I’m not aiming for the top bucks, because those jobs don’t interest me. I’m spending 8 hours a day doing this work, a big majority of the high-quality hours of the week are sunk into the job. I’m happy I get to spend them doing things I enjoy, with people I enjoy working with, as opposed to having to slog through them just because I need the money.


  • I rebase almost daily. I (almost) never merge the main branch into a feature branch, always rebase. I don’t see the point of polluting the history with this commit (assuming I’m the only dev on this branch). I also almost always do an interactive rebase before actually pushing a branch for the first time, in order to clean up commits. I mostly recreate my commits from scratch before pushing, but even then I sometimes forget to include a change in a commit I’ve just made so I then do an interactive rebase to fold fixup commits into the commits they should’ve been in.

    I like merging for actually adding commits from a feature branch to main (or release or …)