5 ms·

The author describes the script in https://medium.com/@kentbeck_7670/limbo-on-the-cheap-e4cfae840330 https://medium.com/@kentbeck_7670/limbo-on-the-cheap-e4cfae

by hnruss 8y ago

The author describes the script in https://medium.com/@kentbeck_7670/limbo-on-the-cheap-e4cfae840330 https://medium.com/@kentbeck_7670/limbo-on-the-cheap-e4cfae8... "test && git commit -am working" This seems like a recipe for a useless commit history.

tzar 8y ago
Probably useless in terms of existing, standard development processes, but it seems to me like this Limbo effort is to come up with a new one (in which we can assume, by the principle of charity, that this is not entirely useless).
Rychard 8y ago
I assume that commits are being made to some sort of topical branch (Edit: I guess not? That seems like a poor decision). Personally, I encourage the developers across our organization to do an interactive rebase prior to pushing to a remote, to "curate" their commits (squash/fixup). This greatly improves the utility of the commit history, at the expense of losing the actual commit history as work progressed: - FeatureA should ensure valid user session - fix test - missing semicolon - null check - fix incompatibility with FeatureB - shit broke the build - address PR comments
derefr 8y ago
The workflow is using Git as a realtime state-synchronization primitive (like Operational Transformations in Google Docs), not an SCM. The point is to push the commits over to the other person as soon as they're created, and for the other person to pull them and rebase against them as soon as they're created. Unlike character-by-character OT sync, though, each synced Git commit does represent a working codebase. You could theoretically retroactively grab huge numbers of these commits and squash them down and describe the result—though multiple independent things might have happened in them that would be very difficult to untangle, given that, in this workflow, it's entirely possible that two separate people are working collaboratively on two separate features, in the same file, at the same time.

by hnruss 8y ago

tzar 8y ago

Probably useless in terms of existing, standard development processes, but it seems to me like this Limbo effort is to come up with a new one (in which we can assume, by the principle of charity, that this is not entirely useless).

Rychard 8y ago

I assume that commits are being made to some sort of topical branch (Edit: I guess not? That seems like a poor decision). Personally, I encourage the developers across our organization to do an interactive rebase prior to pushing to a remote, to "curate" their commits (squash/fixup). This greatly improves the utility of the commit history, at the expense of losing the actual commit history as work progressed: - FeatureA should ensure valid user session - fix test - missing semicolon - null check - fix incompatibility with FeatureB - shit broke the build - address PR comments

derefr 8y ago

The workflow is using Git as a realtime state-synchronization primitive (like Operational Transformations in Google Docs), not an SCM. The point is to push the commits over to the other person as soon as they're created, and for the other person to pull them and rebase against them as soon as they're created. Unlike character-by-character OT sync, though, each synced Git commit does represent a working codebase. You could theoretically retroactively grab huge numbers of these commits and squash them down and describe the result—though multiple independent things might have happened in them that would be very difficult to untangle, given that, in this workflow, it's entirely possible that two separate people are working collaboratively on two separate features, in the same file, at the same time.