[dead]
Git commands I run before reading any code
91–100 of 546 posts
Re: Git commands I run before reading any code
#92I have a summary alias that kind of does similar things # summary: print a helpful summary of some typical metrics summary = "!f() { \ printf \"Summary of this branch...\n\"; \ printf \"%s\n\" $(git rev-parse --abbrev-ref HEAD); \ printf \"%s first commit timestamp\n\" $(git log --date-order --format=%cI | tail -1); \ printf \"%s latest commit timestamp\n\" $(git log -1 --date-order --format=%cI); \ printf \"%d commi…
You could make a local `man` page.
Re: Git commands I run before reading any code
#93Earlier quoted context omitted.
What if the shared place is the place where you run a bunch of CI? Then you push your work early to a branch to see the results, fix them etc.
You can always force-push a cleaned up version of your branch when you are ready for review, or start a new one and delete the WIP one.
You can, but instead you can also just squash merge in one click. And avoid that people merge there dozens of fixes if you allow anything but squash merge.
Re: Git commands I run before reading any code
#94Earlier quoted context omitted.
You can always force-push a cleaned up version of your branch when you are ready for review, or start a new one and delete the WIP one.
I hate (and fear) force-pushing and "cleaning up" git history as much as other people dislike squash-merging =) It just feels wrong to force push, destroying stuff that used to be there. And I don't have the time or energy to bisect through my shitty PR commits and combine them into something clean looking - I can just squash instead.
Nothing is destroyed by a force push. It just overwrites a single pointer, and even keeps its old value in reflog.
Things that aren't referenced by anything anymore will eventually get garbage collected and actually destroyed, but you can just keep a reference somewhere to prevent that from happening if you need. Or even disable garbage collection completely.
Looks like people's fears about git come just from not knowing what it does.
Re: Git commands I run before reading any code
#95I put it into a gist :)
https://gist.github.com/aeimer/8edc0b25f3197c0986d3f2618f036...
Re: Git commands I run before reading any code
#96Earlier quoted context omitted.
> If someone uses git commits like the save function of their editor I use it like that too and yet the reviewers don't get to see these commits. Git has very powerful tools for manipulating the commit graph that many people just don't bother to learn. Imagine if I sent a patchset to the Linux Kernel Mailing List containing such "fix typo", "please work now", "wtf" patches - my shamelessness has its limits!
Seems like a lot of extra effort (save, add, commit, come up with some message even if it's a prayer to work now) only to undo it again later and create a patch or alternate history out of the final version. Why bother with the intermediate commits if you're not planning for it to be part of the history?
If the team is using a PR workflow, the PR is a working place to produce one single commit. The individual commits are just timestamped changes and comments. Think of it as the equivalent of annotated diff in mailing list conversation.
Re: Git commands I run before reading any code
#97Earlier quoted context omitted.
if you mean better messages, it's not really that. those junk messages should be rewritten and if the commits don't stand alone, merged together with rebase. it's the "logical chunks" the parent mentioned. it's hard to say fully, but unless a changeset is quite small or otherwise is basically 0% or 100%, there are usually smaller steps. like kind of contrived but say you have one function that uses a helper. if there…
If the code base is idempotent, I don't think showing commit history is helpful. It also makes rebases more complex than needed down the line. Thus I'd rather squash on merge. I've never considered how an engineer approaches a problem. As long as I can understand the fundamental change and it passes preflights/CI I don't care if it was scryed from a crystal ball. This does mean it is on the onus of the engineer to ex…
Commits don't show "how an engineer approaches a problem". Commits are the unit of change that are supposed to go into the final repository, purposefully prepared by the engineer and presented for review. The only thing you do by squashing on merge is to artificially limit the review unit to a single commit to optimize the workflow towards people who don't know how to use git. Personally I don't think it's a good thing to optimize for.
Re: Git commands I run before reading any code
#98Earlier quoted context omitted.
These commits reaching the reviewer are a sign of either not knowing how to use git or not respecting their time. You clean things up and split into logical chunks when you get ready to push into a shared place.
Haha, good luck working with a team with more than 2 people. A good reviewer looks at the end-state and does not care about individual commits. If im curious about a specific change i just look at the blame.
Sometimes I have to go back and fix a bug that appeared during another branch. Having the original commits helps me bisect it.
Not often, but given that it costs me nothing to have it all in my tree, I'd rather have it than not.
Re: Git commands I run before reading any code
#99Dying or stabilizing?
Most good projects end up solving a problem permanently and if there is no salary to protect with bogus new features it is then to be considered final?
Re: Git commands I run before reading any code
#100Earlier quoted context omitted.
Haha, good luck working with a team with more than 2 people. A good reviewer looks at the end-state and does not care about individual commits. If im curious about a specific change i just look at the blame.
> A good reviewer looks at the end-state and does not care about individual commits. Then I must be a bad reviewer. In a past job, I had a colleague who meticulously crafted his commits - his PRs were a joy to review because I could go commit by commit in logical chunks, rather than wading through a single 3k line diff. I tried to do the same for him and hope I succeeded.
Why are those not just separate PRs? Or if they really needed to be merged at once - they should still be separate PRs but on a feature branch