new mr patches on their way (not quite ready yet though)

[Joey Hess]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20111201/4da11d49/attachment.pgp>