There's a threshold where good integration does not trump shit product. Bitbucket sucks. I'm glad we're not using it even when we're still stuck with shit Jira and confluence.
I've found in-line completions/suggestions useful at times, but multi-line completions always irritating to the point that I disabled them completely. Much more often I want to read surrounding and following code, and not have it be pushed out of view, and rarely was it useful to me.
Of course, that may be largely the project and use case. (And quite limited experience with it.)
I've been using phind as a technical-focused AI search engine, which is a great addition to my toolset.
I'm mindful of using it vs searching [ref docs etc], not only in the kind of search and answer I'm looking for but also energy consumption impact, but it's definitely very useful. I'm a senior dev though, and know what to expect and I am able to assess plausibility, and phind provides sources I can inspect too.
As for code assistance, I find it plausible that it can be useful, even if from my personal experience I'm skeptical.
I watched an Microsoft talk from two devs, which was technically sound and plausible in that it was not just marketing but they talked about their experience, including limits of AI, and where they had to and to what degree they had to deal with hallucinations and cleanup. They talked about where they see usefulness in AI. They were both senior, and able to assess plausibility, and do corrections where necessary. What I remember; they used it to bounce ideas back and forth, to do an implementation draft they then go over and complete, etc.
Microsoft can do the investment of AI setup, code sharing to model, AI instructions/meta-description setup investment, etc.
My personal experience was in using copilot for Rust code, for Nushell plugins. I'm not very familiar with Rust, and it was very confusing, and with a lot of hallucinations.
The PR descriptions CodeRabbit did were verbose and not useful for smaller PRs I made. That has been a while ago.
At work we have a voluntary work group exploring AI. The whole generate your whole app kind of thing seems plausible for UI prototypes. But nothing more. And for that it's probably expensive.
I'm not sure how much the whole thing does or can do for efficiency. Seems situational - in terms of environment, setup, capabilities, and kind of work and approach.
The reinforcement learning is a good point, but the social aspect seems equally important to me. Humanity is a very social creature. We learn from others, we seek agreement and acknowledgment, if we see rejection from one end, we may be all too willing to seek out where we don't see rejection.
A trained chat bot hijacking this evolved mechanism is interesting, at least, if not ironic or absurd. We are so driven by the social mechanisms of communication and social ideation, that no human is needed for this mechanism to work - whether in good or bad effect.
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).
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.
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.
I don't think there's a need to switch away.
Many people in Lemmy think otherwise, and have thought so for a long time.
Nothing changed yet due to product integration into Corp.