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...

▲

orwin 3 hours ago | parent | next [-]

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).

▲

hhjinks 3 hours ago | parent | prev | next [-]

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.

	▲	ratchetclank an hour ago \| parent [-]
		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.

▲

chungy 4 hours ago | parent | prev | next [-]

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#...

▲

smartmic 3 hours ago | parent [-]

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

	▲	fc417fc802 3 hours ago \| parent [-]
		> 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.

▲

codesnik 3 hours ago | parent | prev [-]

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.