Comment by jonhohle | Hacker News Reader

Comment by jonhohle | Hacker News Reader

Parent Full thread

I'm not fond of broken commits in a public timeline, and often my local commits are broken - they are snapshots of development milestones that make sense to me, but have no business being made public in the persisted timeline of a package.

I see this a lot in public timelines:

    Commit A - splendid new feature
    Commit B - oops, missed a semicolon
    Commit C - typo
    Commit D - addressing code review
    Commit E - typo

That 5 commits for one new feature, and the commit I want to build from has a commit message which has nothing to do with the feature in question.

Rebasing that to a single commit takes little effort or time, and makes the timeline clear. On top of that, if you are using a code review tool which persists changes you may already have history of commit C which is probably the only other relevant commit you'd care to be able to find in the future.

It seems like this is something that should be handled by flags/tagging or some other object rather than destroying history.

Like, instead of collapsing A-E into a single commit, A should be marked as the start of project/feature/milestone/whatever Foo, and E as the completion of it, and A-E shown as a single object when viewing the history but allowing the user to drill-down to expose the internal commits.

Destroying information is never good.

Yes. This. The whole religion about keeping history "clean" would collapse if we had this single technical ability.

You can get some of the way there now by making use of tags or branch labels or something.

At one point, i wrote a Mercurial hook that would sit in the central repository add a tag every time someone pushed. Then, only tagged commits would be considered first-class parts of history. There are numerous problems with this, not least that none of the existing tooling is aware of this convention. The fact that Mercurial tags live in commits, which pushers then have to immediately pull, was also very awkward.

You can use branches in a similar way: do all the intermediate, historical-footnote, commits in a development branch, and merge into a master branch to publish them. Then only consider commits in the master branch to be first-class. This is roughly Git Flow, isn't it? Again, the tooling doesn't quite do everything you'd want it to around this.

Yes, you can still rebase to one commit in a Trunk model. Git-Svn and Perforce's Git-Fusion allow you to knock yourself out with DVCS (squash, local-branches) before you dcommit / push back to the canonical repo.

Reply on news.ycombinator.com