4 ms·

What came to mind personally was overuse of rebasing to turn a commit log into something artificially pristine at merge time. People do want some minimum of co

by chipsy 13y ago

What came to mind personally was overuse of rebasing to turn a commit log into something artificially pristine at merge time. People do want some minimum of commit hygiene so that the repo avoids being a mystery vortex. But because distributed VCS lets you hide everything about how you actually work, people are able to get unnecessarily competitive about it.

jonhohle 13y ago
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.
- paul_h 13y ago
  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.
- Pxtl 13y ago
  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.
  - twic 13y ago
    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.

by chipsy 13y ago

jonhohle 13y ago

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.

paul_h 13y ago
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.
Pxtl 13y ago
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.
- twic 13y ago
  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.