Worktrees share the data stored in the .git folder. This saves storage (particularly on larger repos, and if you don’t fetch/clone only partial history), and could allow some other workflows or safeguards (backing up just one instead of multiple, centralized local state instead of spread across different workspaces). It also means it could share repo-local git settings - like remotes, local not checked-in ignores, etc. (I assume).
What do you mean in particular?
The only thing that comes to mind for me is the “restore after commit” being a different chunk-add workflow than add --patch - but I don’t think it’s worse.
TortoiseGit.
Through settings, I move the Show Log to the top context menu level, and it’s my entry point to every Git operation.
I see a history tree to see and immediately understand commit and branch relationships and states. I can commit, show changes, diff, rebase interactive or not, push, fetch, switch, create branches and tags, squash and split commits, commit chunk-wise through “restet after commit”, … And everything from a repo overview.
/edit: To add; other clients I tried never reached what I want from a UI/GUI, never reached TortoiseGit. Including IDE integrations where I’m already in the IDE; I prefer the separate better TortoiseGit.
GitButler is interesting for it’s different approach, but when I tried it out the git auth didn’t remember my key password. (Since trying out jj I found out it may have been due to disabled OpenSSH Service.)
Review iterations mean messy comits there though. And full documented history in Git seems preferable because you don’t have to switch tools, and for persistence and robustness too, in case of repo/review platform changes (switching platforms etc).
Enable squash commits. Each PR should be squashed to a single commit. This makes the master branch linear and simple. This ensures each individual commit on master has been reviewed and is in a working state.
In non-minimal changesets, I would miss information/documentation about individual logical changes that make up the changeset. Commit separation that is useful for review will also be useful for history.
I prefer a deliberate, rebase- and rewrite-heavy workflow with a semi-linear history. The linear history remains readable, while allowing sum-of-parts changesets/merges.
It’s an investment, but I think it guides into good structuring and thoughts, and whenever you look at history, you have more than a squashed potential mess.
Squash-on-merge is simpler to implement and justify, of course. Certainly much better than “never rebase, never rewrite, always merge”, which I am baffled some teams have no problem doing. The history tree quickly becomes unreadable.
While exploring solutions, I use f or ffto mean “follow-up/to-squash” and a to mean logically separate. Sometimes other (additional) short abbreviations to know where to move, squash, and edit the changes to.
Other than maybe initial development until the first stable/usable version, these never persist, though. And even then, only if it’s not a collaborative project. If it is shared or collaborative, “Iterate on x” is preferable as a non-descriptive title.
I guess my commit descriptions get better with project lifetime, not worse.
Unicode symbols is a good idea.
I’ll call my compiler 👷♂️and my debugger 😈.
I don’t think these are mutually exclusive concepts.
If they never deleted any data of close accounts, wouldn’t that be a lot of wasted storage space? Wouldn’t it be way too much data?
deleted by creator
It’s interesting that LLMs emotionally saved them, allowing them to bounce back from a destructive to a constructive mindset.
Reading another post of theirs, they seem to really love AI. Albeit in that post, it feels to me like they took AI responses too literally, with too much meaning (as if sentient, or ignoring potential training bias, etc).
Do you mean self-host on your own hardware and infrastructure? At home? Otherwise you’d still be dependent on the server or infrastructure providers.
That subheadline though…
Headline: “x or y?”
Subheadline: “Spoiler: Yes.”
🤨
Why even add a subheadline when it only makes sense with the content.
Do you see downsides to learning it?
If you can, do it. It’s common enough to be [potentially] useful. If you don’t have a concrete need, then it’s not necessary, though.
1 C
2 Pascal
…
When you add a dot after the number it becomes a numbered lists and you don’t have use a paragraph for each line.
Alternatively, you can use a backslash (\) or two spaces ( ) at the end of a line to use a line-break so you can but one line after the other instead of requiring paragraphs.
Discuss with your team management how to handle this.
For this discussion collecting the impacts, in terms of labor cost, labor motivation, short and long term cost, repeated helping-out cost to your teams tasks, etc can underline significance.
Why is it called toll booth simulator (primary title) when most of it is not toll booth handling/gameplay?
Always Godot.
Roblox is a closed, proprietary environment. Anything you learn will be within their environment by definition.
If Godot feels too hard, look for simpler onboarding or tutorials for it, or explore existing open projects and make modifications to them to see and explore and learn how it works and how projects can be structured and designed.
There’s other alternatives too. I would never go for Roblox.
No time for commas with how fast this tech is developing