new mr patches on their way (not quite ready yet though)
joey at kitenet.net
Thu Dec 1 19:56:45 CET 2011
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
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:
> 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?
> - A plug-in module which allows tar balls / zip files etc. to be
> downloaded, unpacked, and used as repositories with minimal
> effort, e.g.
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 828 bytes
Desc: Digital signature
More information about the vcs-home