VIMR QUIT UNEXPECTEDLY PATCH
This used to be full of patch + diff + rsync in the past, but when you build stuff remotely and do diffs, but add new files to the codebase, it is so much easier to just use git.įor my personal projects, I think CSS files are the most common things I've edited in this sort of loop - my web-app folders are generally just git clone -depth 1, which also takes care of the other loop where I edit locally and deploy to remote. Then do a git clone on the remote box from that repo, then I can push changes back to that local repo and when I'm done with the day, I can just pull it all back to my laptop with a git pull. Git remote add clusterx remotebox:dev/project.git I do most of my work on a remote box, but I still like to edit locally in an IDE, but occasionally I make a change on the remote side. You can extend it to remote-history too, because git makes it almost trivial to create a repo that you want to work over the network (without a running server of any kind). > It's kind like a snapshot-based local history.
VIMR QUIT UNEXPECTEDLY SERIES
I've seen patch series which refactor whole subsystems, where each patch in the series was an obviously correct transformation, while the final result was completely different. And that was a simple example it's not rare to have patch series with over 15 patches, and even longer patch series are not unheard of. When reviewing this sequence, it's easier to see that each patch is correct. The next patch changes both the field and the helper functions to use the new representation. Patches 2-5 might each change a separate subsystem to use the new helper functions, instead of accessing the field directly. The first patch of your series might introduce a couple of helper functions to access the structure fields. For instance, suppose you want to change the way a field in a particular structure is stored. Each patch should contain a single logical change, and will be reviewed individually. Whenever someone proposes a change to the Linux kernel, it's sent as a sequence of patches. To understand why git is the way it is, you have to understand the workflow of the original git-using project (other than git itself), the Linux kernel. > Who do we really help by pretending that we're more organized, coherent, and linear than we actually were? Taken to its logical extreme, that would mean every keypress and editor command.īut "why not delete all of history" is not an example of "carefully crafted commits" taken to an extreme. This view suggests that a more detailed history is preferable. Some people argue rebase should never be used. Without preserving these to history the reader is left without understanding these. Maybe there were false starts and mistakes made along the way. The counter argument to that was that it presents a false view of history.
Look at git itself for an example of this type of history. That makes changes easier to reason about, and enables the use of tools such as bisect. Every commit should build cleanly, preferably even pass tests. The argument here is that one should rebase and carefully craft commits that isolates each functional change into a separate commit, where each change is motivated and builds on previous, before pushing anything. > why not squash and rebase entire months or years of project work into single commits? Note that even for single-developer projects I run, I tend to make PRs even for my own changes (once it's gotten off the ground). The force-rebase workflow is just as confounding to me as the no-rebase workflow (the former de-parallelizes your MR merge process and the latter tends to make a terrible commit history). The `rebase & merge -ff-only` pattern and `merge -squashed` are both terrible, IME, at making useful history. Note that this only works with a `merge -no-ff` workflow too. So once I get it down to a particular MR, being able to inspect that topic is still a useful property. That one in particular was meant to be bisectable because when rebasing on top of new development, I wanted fixes to be in the "port this library over" commit instead of after some random merge commit based on when I decided to sync up that week (it took a year to do it).
VIMR QUIT UNEXPECTEDLY SOFTWARE
I do software process and other things, so some of my branches tend to be gigantic (e.g., revamping the build system) and can be 200+ commits because one cannot meaningfully land a build system rewrite incrementally.
It finally exists now, so yes that helps, but is not a complete solution.Įven with `bisect -first-parent`, I still want useful commit messages which "fixup" commits, again, are uniquely terrible at being on the whole. Yes, `git bisect -first-parent` was a feature I wanted for a long time.
0 kommentar(er)
