I'm kind of liking inserting an empty git commit at the beginning of a long-ish branch, that just has a commit message explaining the purpose of that branch.

@federicomena hmm, interesting idea! OTOH that's what WIP MR are for if you're using :gitlab:

@federicomena I had the opposite idea here the other day:

git reset --hard $(git commit-tree @: -p master -p @ -m "Summary of branch")

this creates a merge commit inside a branch *before* it's being merged. it's a place to write a summary of what happened inside this branch. the branch can then be fast-forward merged into master

@judofyr Nice. I guess they have different purposes, "document what I did" vs. "document what I'm going to do". I'm doing somewhat experimental branches, hence the latter.

@federicomena That'd certainly work better than naming branches after the SHA of the message explaining the branch's purpose.

@federicomena No. :)

(Sometimes I can't stop myself from suggesting really outrageous things. Sorry.)

@liw I am NOT getting nerdsniped into looking if "git checkout abcde" tries to disambiguate between branch name and commit name. I'm totally not.

@federicomena Kernel hacker Matt Mackall kind of taught me to not do that, but that's kind of because each commit is one email message and commits can be accepted in different order than you emailed them, so they can be detached from the context in which you originally wrote them.

Each commit's inseparable context is only its own commit message and everything should make sense on its own, is how I understood it.

@federicomena But I guess if nobody but you is going to be writing commits on the same branch, there's no risk of commits getting separated from their context.

@JordiGH Dunno; I like commit histories to tell a story. I could never get used to kernel-style one-mail-per-commit. It may work if the purpose is to be able to bikeshed on each separate commit... then gitlab appears and one sees how that's an extremely primitive model. Or something like that :)

@federicomena Well, you, can patchbomb a whole series of commits at once, telling a story, but there's no guarantee they won't cut out scenes out of your story if they don't like them or even rewrite your story before publication.

@federicomena Is gitlab different from github or bitbucket?

I don't like how github and bitbucket essentially hide the commits, making commit messages hard to find, and also smooth all of the diffs into one giant hairball diff full of context switches.

That encourages people to treat project history as junk, not worth their time to properly write it and therefore not worth reading either.

@JordiGH I'm very happy with how Gitlab does code review of merge requests. It shows a whole-branch diff by default, but it's easy to go into individual commits. (I find both useful; the former for bugfix branches, the latter for refactoring branches.)

I like how it presents rewritten histories within branches when they happen, and lets one compare versions. Sort of a nice version of git reflog.

I *think* github's PR review process is not as smooth, but haven't used it as extensively.

@federicomena Oh, man, if Heptapod ( ) ever gets accepted upstream, I'd be so happy to have evolve in there (even better than reflog: each commit has metadata saying what is the commit(s) that it replaced, creating a meta-history DAG)

Regístrate para participar en la conversación

La red social del futuro: ¡Sin anuncios, sin vigilancia corporativa, diseño ético, y descentralización! ¡Sé dueño de tu información con Mastodon!