Hacker News Reader

Comment by ratchetclank | Hacker News Reader

I never understood why rebase is such a staple in the git world. For me "loosing" historical data, like on which branch my work was done is a real issue.

In the same class, for commit to not have on which branch they were created as a metadata is a rel painpoint. It always a mess to find what commit were done for what global feature/bugfix in a global gitflow process...

I'll probably be looking into adding an commit auto suffix message with the current branch in the text, but it will only work for me, not any contributors...

View on HN

Ideally you only rebase your own commit on your own feature branch, just before merging. Having a clean commit history before merging make the main branch/trunk more readable.

Also (and especially) it make it way easier to revert a single feature if all the relevant commits to that feature are already grouped.

For your issue about not knowing which branch the commits are from: that why I love merge commits and tree representation (I personally use 'tig', but git log also have a tree representation and GUI tools always have it too).

Sounds like you'd be a fan of Fossil (https://fossil-scm.org). See for instance: https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#...

Let me expand on this with a link to the article "Rebase Considered Harmful" [0].

I also prefer Fossil to Git whenever possible, especially for small or personal projects.

[0] https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

> Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying

From your link. The actual issue that people ought to be discussing in this comment section imo.

THIS is the hill I will die on.

Why do we advocate destroying information/data about the dev process when in reality we need to solve a UI/display issue?

The amount of times in the last 15ish years I've solved something by looking back at the history and piecing together what happened (eg. refactor from A to B as part of a PR, then tweak B to eventually become C before getting it merged, but where there are important details that only resulted because of B, and you don't realize they are important until 2 years later) is high enough that I consider it very poor practice to remove the intermediate commits that actually track the software development process.

Because nobody cares about the dev process. The number of times I’ve looked back in the history and seen a branch with a series of twenty commits labeled “fix thing”, “oops”, “typo”, “remove thing I tried that didn’t work”, or just a chain of WIP WIP WIP WIP is useless, irritating, and pointless.

One commit per logical change. One merge per larger conceptual change. I will rewrite my actual dev process so that individual commits can be reviewed as small, independent PRs when possible, and so that bigger PRs can be reviewed commit-by-commit to understand the whole. Because I care about my reviewers, and because I want to review code like this.

Care about your goddamn craft, even just a little bit.

Isn't this just `--first-parent`? I think that should probably be the default in git. Maybe the only way this will happen is with a new SCM.

But the git authors are adamant that there's no convention for linearity, and somehow extended that to why there shouldn't be a "theirs" merge strategy to mirror "ours" (writing it out it makes even less sense, since "theirs" is what you'd want in a first-parent-linear repo, not "ours").

Which branch your work was done on is noise, not signal. There is absolutely zero signal lost by rebasing, and it prunes a lot of noise. If your branch somehow carries information, that information should be in your commit message.

I disagree, without this info, I can't easily tell if any commit is part of a feature or is a simple hotfix. I need to rely on the commiter to include the info in the commit message, which is almost always not the case.

Nothing stops you from doing both renade and merge commits.

Except perhaps crappy gui options in GitHub. I really wish they added that option as a button.

But you are still relying on them to name the branch in such a way it encodes that info. It is unclear why this is superior to messages in commits.

It's worse than that: the branch name is lost after a merge. That "merge branch xyz" is simply the default commit message. So it doesn't matter what you do, commit messages are all you have!

Every commit message starts with the ticket number of whatever issue tracking system you're using. If you're not using issue tracking with a system large enough for multiple devs, you've got a much bigger problem.

it's just "gitflow" is unnecessary complex (for most applications). with rebase you can work more or less as with "patches" and a single master, like many projects did in 90x, just much more comfortably and securely.

Reply on news.ycombinator.com