Git:
This is a pretty simple
There is no tracking information for the current branch.
Please specify which branch you want to merge with.
even if you go pull
You asked to pull from the remote ‘–all’, but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.
I think this occurs if you create a branch locally, but didn’t set the -u flag, which would copy the origin info. The fix is to
$ git push -u
Branch bias_analysis set up to track remote branch bias_analysis from origin.
Branch brake set up to track remote branch brake from origin.
Branch comparison set up to track remote branch comparison from origin.
Branch extnd_circ_leg set up to track remote branch extnd_circ_leg from origin.
Branch extnd_circ_leg_second_try set up to track remote branch extnd_circ_leg_second_try from origin.
Branch extnd_circ_leg_third_try set up to track remote branch extnd_circ_leg_third_try from origin.
Branch main set up to track remote branch main from origin.
Branch old set up to track remote branch old from origin.
Branch pipeline set up to track remote branch pipeline from origin.
Branch shifted_LEG_peak set up to track remote branch shifted_LEG_peak from origin.
Need to re-read and follow this often.
Easy to forget untracked files under repo dir that are needed for a speicic piece of software to run.
get report using git check-ignore
find . -not -path './.git/*' -not -path '**/.venv/*' | git check-ignore --stdin > /tmp/report.txt
git clean -ndX
is a good onr
Learn jujitsu
I wonder if it would make sense to take a more active role in curating the commit history.
- squashing non-essential commits (little 1 char changes and reverts, syntax erros) together
- rewriting messages with findings with the benefit of hindsight
- creating commits with no file changes using
--allow-emptywith just notes and explanation of runtime observations
to make git a bit more like a logbook.
for example, I just switched from ansible-pull to ansible-playbook.
There are a few notes regarding this which I don’t want to get buried in the commit log; I think it’s a pretty notable. In some cases I might pull this out in to e.g. a post like this on Whimsy, but it might be more effective to keep it in the git history and then link to it.
fairly often I will write something interesting - maybe a cool matplotlib setup, say, and then it gets committed, but even though technically it’s recorded I never end up looking back at it later, I guess because there’s so much noise in the git history, and also never really record when a certain feature was “done”.
- I also just committed half a dozen “syntax error” trials which clutters up the history.
in sysadmin/ I have been keeping a lot of this “procedural knowledge” info in log.md, but I feel like it might actually be more useful to keep this in git log.
- and the converse of empty commits, using
--allow-empty-messagein preference toCommit: blah blah bugfix syntax error.
ansible-pull has an interesting side effect of forcing you to commit every time you want to test a single small change. If combined with disciplined post-hoc squashing and curation above, this might actually be a good way to force good recordkeeping
https://www.reddit.com/r/programming/comments/ujd11l/your_git_commit_history_should_read_like_a/
The only way I see conventional commits working well is if you rebase yourself commits before merging to manually organize and edit them. The worst case scenario, in my mind, is for a developer to choose when to commit based on how their messages will read rather than committing at regular and frequent intervals. If you commit every 15 minutes your commits are unlikely to read like a nice book, however hard you try otherwise, unless you’re a wizard who never spends more than 15 minutes on the same chunk of work. Committing this frequently will also make it easier for you to backtrack when needed without losing work.
I also think that putting this much effort into commit messages is usually wasted anyway, because IMO squash merging pull requests is the right choice for most teams in most cases. PRs feel like a much more natural chunk of work to document, and if you want good documentation for each one you can update a changelog.
…
I commit a lot locally then squash my changes with a pretty message for the PR.
git-notes
easily edited & updated with runtime experience without needing to change
Git Notes: git's coolest, most unloved feature (2022) | Lobsters
Using GIT as a storage · ligurio/testres Wiki · GitHub - puts test results in the git notes
Git - Tagging annotated tags
https://stackoverflow.com/questions/20099671/can-additional-data-be-put-into-a-git-commit-object trailers
thinking about how machining youtube had me thinking about pre-process and separating planning from doing way more than any blogs or CS courses managed to encourage
I never thought of pre-writing my commits and then doing the thing I said until I watched someone talking about their workflow in a biology lab
(it is a failing of most git tooling that this is a hard mode to discover because there’s a lot of friction until you know you want to do it)
https://ericmjl.github.io/essays-on-data-science/workflow/effective-commit-messages/
commit -eF