with Xcode 14 I could hit ⌘⌥C, immediately type a commit message, then hit ⌘-return to complete the commit. git and I were both happy doing commits quickly.
with Xcode 15 I apparently have to first mouse click into the spot for the commit message... then I have do another mouse click on the Commit button.
Is there a way to set this back to the previous behavior?
#git and other source control repo maintainers: please add a blurb to your readme that explains what it is your product is supposed to do. Please start with explaining what problem it solves.
A clean Git history is the key to successful teamwork and quick bug fixes. Errors can only be successfully tracked down if it is always possible to trace when and where code was changed by whom and for what reason.
🥴 However, in the rush of the battle, the changes that are packaged in a commit are sometimes not taken very seriously. Who has never experienced this? A change that is actually unrelated to the current work package has made it into the commit because the file has already been saved temporarily.
💡The solution: With an "interactive add" (git add -i), you can pack partial changes ("hunks") into a commit and specify line by line what should be included in the next commit.
I know, Git is a mess. But, since we're stuck with it, we may as well try to learn how it works with resources like this, which aims to lead to some form of Git enlightenment.
Highlights: Haskell instead of Scheme, JSON instead of sexps, SSH instead of OpenPGP, additional features such as per-file authorizations and unsigned merge commits.
Then if I hit the situation from the video where there are new commit(s) on the remote, #git stops the merge and displays a message. At that point I can decide how to handle it.
Dear #logseq and #obsodian users, #git is not a backup system. Store your notes in a reposotory, if you must, but please configure a backup for your notes.
Folks who squash their #git merges, I’m curious why you are making that trade-off. I’m guessing the pro argument is a cleaner merge graph?
The big argument against it for me is that you lose granularity for git bisect. I've often been able to narrow down breakage (sometimes long past the merge) due to individual commits in the merge. If I'd merged in a giant blob all I'd have had to go by is that giant blob. (1/2)
I have a branch that says it's up to date with the upstream (fork of a repo). I'm trying to contribute a patch, but my commit history in the PR has 26 commits from things that have already been merged rather than my changes from the current head.
Is there an acceptable way to clean up that history so my PR is clean?
Manager: Lets teach a non-developer office worker how to push code to git. "It's just clicking a few buttons. I've done it before. It's not that hard."