Adam Spiers wrote: > I've made a lot of progress since this last mail, and I'm conscious > that my branch is now approximately 50 commits ahead of the official > master branch, so I think it's time to work on convergence if > possible.
It would be helpful if you: * separated the stow stuff into its own branch When adding a feature, I need something I can diff against; a chain of commits is ok, or a squashed commit is ok; a chain of commits mixed in with other unrelated changes is not * wrote commit messages that were longer than one line I need to understand a commit before I can apply it, and the choice is either that you type a little but more, or that I spend significant time guessing and likely miss something. A commit such as a2515e7e89f35c8d3291da9a5908b42a8d0bb277 is simple on its face, but is entirely lacking in an explanation of why the change was necessary; in what situation is there a dangling symlink and how did mr fail? Why is adding an error message of "BUG: this shouldn't happen" justified? Similarly, commit 655f0002ae80e21329ace97447a3a16c577949ec says it fixes "a small bug", but neglects to say what the bug is. A commit such as 49163f09b8ff2c70c64076040be772b8d37c84aa or 1dd662640b946d681683c260f1b693cd0522b09f needs significant justification -- how does hardcoded VT100 color codes or a lot of different debug levels make mr better? Only a patch such as 96f2c8875bba4f7225decb60ee905815e2aeaa4a doesn't need more than one line of explanation. * avoid entangling different lines of development I was about to cherry-pick c4a8af985f525c2a1061576e72d526aa515151be until I noticed the last line ties it into the logging level stuff. Here's a summary of the main features of my branch: > - A plug-in module for integration with the GNU Stow symlink > manager, now well-tested and stable. I have recently become > co-maintainer of GNU Stow, and its current git master branch and > next official release contain enhancements which make it > compatible with mr out-of-the-box. This makes tracking your $HOME > dotfiles as easy as: > > [shell-config] > checkout = git clone ... > stowable = true Is there really no way to detect that a given repository is "stowable" by looking at the content of the repository or some other thing? Why not? > - A plug-in module which allows tar balls / zip files etc. to be > downloaded, unpacked, and used as repositories with minimal > effort, e.g. > > [foo] > checkout = mr_download_checkout http://example.com/foo.tar.bz2 A weird feature IMHO, but I use lib/* is sort of a contrib area and I'm willing to accept most any type of module into it. -- see shy jo
Description: Digital signature
_______________________________________________ vcs-home mailing list firstname.lastname@example.org http://lists.madduck.net/listinfo/vcs-home