4 ms·
>No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream.
by vonuebelgarten 10y ago
>No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream.
But forcing this approach precludes you of, for example, easily splitting your existing changes in two commits if required. If changes to the same file are to be committed separately, a non-zero amount of copy-pasting, resetting, temporary files, etc. will be required.
I see Git's separation of concerns of a strict superset for your use case. Just add an alias "git commit -a; git pull; git push".
- rkeene2 10y agoFossil's default mode, autosync, is more closely modeled by: git pull && if stillCommitingToBranchTip; then git commit -a; else echo "Not committing to the tip of the current branch" >&2; false; fi && git push You can turn autosync off in which case the fossil/git push/pull doesn't happen and your commit goes straight to the repository -- still without a staging area. This is my personal usage but, if two changes to the same file are to be committed separately (e.g., git add -p) then the commit that should have happened for those separate changes that was tested just got missed, or the commit that is occurring is untested and perhaps incoherent. That is to say, I build my staging area out of files on disk at the same time rather than building a changeset that may have never actually existed on disk.
- lvh 10y agoThat's true, but also means that there's a fake intermediate stage that never actually existed in the WT, and hence definitionally was never linted or tested.
- vonuebelgarten 10y agoIep. Running the tests over the new commits before pushing is still required. Usually not a big problem.