5 ms·
Don't take this as career advice! This is an amusing anecdote. But the only lesson to be learned is to commit early, commit often.
by dotancohen 1y ago
Don't take this as career advice!
This is an amusing anecdote. But the only lesson to be learned is to commit early, commit often.
- f1shy 1y agoAnd in general maybe have a better working methodic, or however you name it. Sounds like messing around to me.
- onionisafruit 1y agoI like to mess around. Some of my best work comes out of messing around. The trick is making sure you mess around in a way that lets you easily hold onto whatever improvements you make. For me that means committing obsessively.
- SketchySeaBeast 1y agoAnd branches are free.
- dotancohen 1y agoIn git. It took me a while to get out of the SVN mindset when branches were expensive and slow to create.
- cranium 1y agoCommit even as a WIP before cleaning up! I don't really like polluting the commit history like that but with some interactive rebase it can be as if the WIP version never existed. (Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?)
- SketchySeaBeast 1y agoAssuming you squash when you merge the PR (and if you don't, why not?), why even care? Do people actually look through the commit history to review a PR? When I review I'm just looking at the finished product.
- globular-toast 1y agoIndiscriminate squashing sucks. Atomic commits are great if you want the git history to actually represent a logical changelog for a project, as opposed to a pointless literal keylog of what changes each developer made and when. It will help you if you need to bisect a regression later. It sucks if you bisect and find the change happened in some enormous incohesive commit. Squashing should be done carefully to reform WIP and fix type commits into proper commits that are ready for sharing.
- SketchySeaBeast 1y ago> It sucks if you bisect and find the change happened in some enormous incohesive commit. But why are any PRs like this? Each PR should represent an atomic action against the codebase - implementing feature 1234, fixing bug 4567. The project's changelog should only be updated at the end of each PR. The fact that I went down the wrong path three times doesn't need to be documented.
- monsieurbanana 1y ago> Each PR should represent an atomic action against the codebase We can bikeshed about this for days. Not every feature can be made in an atomic way.
- withinboredom 1y agoThis simply isn’t true unless you have to put everything in one commit? To be honest, I usually get this with people who have never realized that you can merge dead code (code that is never called). You can basically merge an entire feature this way, with the last PR “turning it on” or adding a feature flag — optionally removing the old code at this point as well.
- monsieurbanana 1y agoSo maintaining old and new code for X amounts of time? That sounds acceptable in some limited cases, and terrible in many others. If the code is being changed for another reason, or the new feature needs to update code used in many places, etc. It can be much more practical to just have a long-lived branch, merge changes from upstream yourself, and merge when it's ready. My industry is also fairly strictly regulated and we plainly cannot do that even if we wanted to, but that's admittedly a niche case.
- globular-toast 1y agoGit is a distributed version control system. You can do whatever you like locally and it won't "pollute" anything. Just don't merge that stuff into shared branches. I automatically commit every time my editor (emacs) saves a file and I've been doing this for years (magit-wip). Nobody should be afraid of doing this!
- thanksgiving 1y agoExactly this. I can make a hundred commits that are one file per commit and I can later go back and git reset --soft HEAD~100 and that will cleanly leave it as the hundred commits never happened.
- throwaway-18 1y agoHonest question - What DO you merge into shared branches? And, when your local needs to "catch up", don't you have to pull in those shared commits which conflict with your magit-wip commits because they touch the same code, but are different commit hashes?
- Crespyl 1y agoFeature branches that have been cleaned up and peer-reviewed/CI-tested, at least in the last few places I worked. Every so often this still means that devs working on a feature will need to rebase back on the latest version of the shared branch, but if your code is reasonably modular and your project management doesn't have people overlapping too much this shouldn't be terribly painful.
- globular-toast 1y agoThe magit-wip commits go on a separate branch and ideally I'm never even aware of them. They just disappear eventually. They exist purely in case of a disaster à la the article. I make "real" commits as I go and use a combination of `git commit --amend` and fixup commits (via git-autofixup) and `rebase --autosquash`. I periodically (daily, at least) fetch upstream and rebase on to my target branch. I find if you keep on top of things you won't end up with some enormous conflict that you can't remember how to resolve.
- bayindirh 1y agoI always commit when wrapping up the day. I add [WIP] in the subject, and add "NOTE: This commit doesn't build" if it's in a very half-baked state.
- SketchySeaBeast 1y agoI do a bunch of context switching, and I commit every time I switch as stashing would be miserable. I never expect those WIP commits to reviewed and it'd be madness to try.
- elSidCampeador 1y agosame - my eod commits are always titled 'checkpoint commit: <whatever>' and push to remote. Then before the MR is made (or turned from draft to final) I squash the checkpoint commits - gives me a psychological feeling of safety more than anything else imo
- hiccuphippo 1y agoI assume Jujutsu only commits the file when you use one of the jj commands. I don't think it keeps a daemon running and checking for changes in the files.
- steveklabnik 1y agoIt does the former by default, and the latter if you configure it.
- Imustaskforhelp 1y agoI have heard of jj. I have tried jj, I love jj but I couldn't get myself towards using it. This itself seems to me the thing which will make me push towards jj. So if I am correct, you are telling me that I can have jj where I can then write anything in the project and it can sort of automatically record it to jj and afterwards by just learning some more about jj, I can then use that history to create a sane method for me to create git commits and do other thing without having to worry too much. Like I like git but it scares me a little bit, having too many git commits would scare me even further but I would love to use jj if it can make things less scary Like what would be the command / exact workflow which I am asking in jj and just any details since I am so curious about it. I have also suffered so much of accidentally deleting files or looking through chat logs if I was copy pasting from chatgpt for some one off scripts and wishing for a history of my file but not wanting git everytime since it would be more friction than not of sorts...
- baq 1y agoI can’t see myself going back to git after I actually went back and was very confused for a second I need to stash before rebase.
- BeetleB 1y ago> I can then use that history to create a sane method for me to create git commits and do other thing without having to worry too much. It's easier than that. Your jj commits are the commits that will be pushed - not all the individual git commits. Conceptually, think of two types of commits: jj and git. When you do `jj new`, you are creating a jj commit.[1] While working on this, every time you run a command like `jj status`, it will make a git commit, without changing the jj commit. When you're done with the feature and type `jj new` again, you now have two jj commits, and many, many git commits.[2] When you do a `jj git push`, it will send the jj commits, without all the messiness of the git commits. Technically, the above is inaccurate. It's all git commits anyway. However, jj lets you distinguish between the two types of commits: I call them coarse and fine grained commits. Or you can think hierarchically: Each jj commit has its own git repository to track the changes while you worked on the feature.[2] So no, you don't need to intentionally use that history to create git commits. jj should handle it all for you. I think you should go back to it and play some more :-) [1] changeset, whatever you want to call it. [2] Again - inaccurate, but useful.
- steveklabnik 1y ago> (Side ask to people using Jujutsu: isn't it a use case where jujutsu shines?) Yes! For the case discussed in the article, I actually just wrote a comment yesterday on lobsters about the 'evolog': https://lobste.rs/s/xmlpu8/saving_my_commit_with_jj_evolog#c_nftvhe https://lobste.rs/s/xmlpu8/saving_my_commit_with_jj_evolog#c... Basically, jj will give you a checkpoint every time you run a jj command, or if you set up file watching, every time a file changes. This means you could recover this sort of thing, assuming you'd either run a commend in the meantime or had turned that on. Beyond that, it is true in my experience that jj makes it super easy to commit early, commit often, and clean things up afterwards, so even though I was a fan of doing that in git, I do it even more with jj.
- BryantD 1y agoI think maybe one other lesson, although I certainly agree with yours, and with the other commenters who talk about the unreliability of this particular method? This feels like an argument for using an editor that autosaves history. "Disk is cheap," as they say -- so what if your undo buffer for any given file goes back seven days, or a month? With a good interface to browse through the history? I'm sure there's an emacs module for this.
- vidarh 1y agoMy editor syncs the total editing state to disk every few minutes, across all open instances. I eventually added support for killing buffers, but I rarely do (only if there's stuff I need to purge for e.g. liability reasons). After a few years use, I now have 5726 buffers open (just checked). I guess I should garbage collect this at some point and/or at least migrate it from the structure that gets loaded on every startup (it's client-server, so this only happens on reboot, pretty much), but my RAM has grown many times faster than my open buffers.
- compiler-guy 1y agoMost of Google's internal development happens on a filesystem that saves absolutely everything in perpetuity. If you save it, the snapshot lives on forever--deleting stuff requires filing a ticket with justification. It is amazingly useful and has saved me many times. Version control is separate, but built on it. When I eventually move on, I will likely find or implement something similar. It is just so useful.
- julian_t 1y agoI used to rely on this on the old DEC systems, when editing and saving foo.dat;3 gave you foo.dat;4. It didn't save everything forever - and you could PURGE older versions - but it saved enough to get me out of trouble many times.
- mosdl 1y agoJetbrain's local history has saved my bacon several times. Its a good use of all that unused disc space.
- zobzu 1y agohopefully most folks understand that its tongue-in-cheek. with that said its true that it works =)
- bogzz 1y agoif you like it, then you shoulda git commit on it
- bdangubic 1y agodo it even if you don't like it :)
- superxpro12 1y agoEmergency Building Fire Procedure: 1. Commit 2. Push 3. Evacuate
- rossant 1y ago1. Commit with a full, detailed, well-formatted commit message, as always.
- beefnugs 1y agoThe lesson is to trust microsoft Recall. "Hey copilot, what are all my passwords and credit card numbers"