CODEWITHSUNDEEP
gitdvcsbazaar
user1447278
user1447278

Reputation: 13

What's the downside of rewriting unpublished history?

I was wondering what in particular is the downside of "losing history" in a development process. One famous example is of course git rebase -i / git merge --squash, but also what is described here under "I want to clean up my commit history prior to submitting my changes to the mainline."

I can see that exporting patches and applying them to another branch would lose the "history" of the branch, but why would that branch and its commit history be useful after it has been merged?

Can someone elaborate on why such techniques are considered "dirty"? Why does it matter in which order changes were originally committed in the first place as long as they can be applied to the main branch?

Upvotes: 1

Views: 128

Answers (3)

ellotheth
ellotheth

Reputation: 4503

Consider this:

* (master) Merge feature-branch into master
|\
| * (feature-branch) Fix a comment typo
| * Add comments
| * Add feature task 3
| * Consolidate feature tasks 1 and 2
| * Add feature task 2
| * Forgot a semi-colon
| * Add feature task 1
|/
* Older commit on master

vs. this:

* (master, feature-branch) Add feature
* Older commit on master

The first one is a (--no-ff) merge of feature-branch into master, and the bottom is a squash/rebase of feature-branch onto master. The first is very detailed, which will make regression testing more focused, but which will get messy if you have lots of feature branches. The second is cleaner to read if you have lots of features, but loses the branch definition. Your own method will depend on the size of the project, the size of the team, etc.

Personally, I use a will anybody else care about this commit rule of thumb. Nobody downstream cares that e.g. I fixed a typo in a comment. I usually turn the first example into something like this (with rebase -i) before I push:

* (master) Merge feature-branch into master
|\
| * (feature-branch) Add feature task 3
| * Add feature task 2
| * Add feature task 1
|/
* Older commit on master

The relevant bits of the branch history are still obvious, and the rest is squashed.

Upvotes: 1

jthill
jthill

Reputation: 60275

In addition to managing production-quality code you can treat git as whole-product global unlimited malleable undo. "Unpublished history" can include typos, experiments that didn't pan out, minor unrelated fixes you made just 'cause you were there at the time and might split out later, what not. I've never understood the mindset that frowns on undo's.

Compare your rewrite to what you rewrote. If the new version meets your needs better, it's better. If something in the original meets a need the new version doesn't, then that's a downside. Particularly for unpublished stuff that stays in your own repo, what's in there is yours to do with as you like.

Upvotes: 0

KingCrunch
KingCrunch

Reputation: 131881

If you don't see any use for the history for yourself, than there is no downside. In fact many developers create new features in a separate branch (feature/1234) and then instead of merging they rebase/squash it onto the develop-branch and delete the feature branch. The reason is, that usually, if you implement a feature, you are usually not interested in every single implementation step later, but in the feature as a whole. However, you should avoid squashing commits, that don't have anything in common, just because to save commits. There is no downside in having many commits, too.

Upvotes: 0

Related Questions