Skip to content
This repository

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse code

added explanation for fork

  • Loading branch information...
commit b971b2cfbd609205538ca8f67508ec4d23cbd523 1 parent 379a4e4
Mark Burns authored
2  bin/boom
@@ -3,6 +3,6 @@
3 3
 
4 4
 $:.unshift File.join(File.dirname(__FILE__), *%w[.. lib])
5 5
 
6  
-require 'boom'
  6
+require 'kaboom'
7 7
 
8 8
 Boom::Command.execute(*ARGV)
2  bin/kaboom
@@ -3,6 +3,6 @@
3 3
 
4 4
 $:.unshift File.join(File.dirname(__FILE__), *%w[.. lib])
5 5
 
6  
-require 'boom'
  6
+require 'kaboom'
7 7
 args = %w{remote} + ARGV
8 8
 Boom::Command.execute(*args)
43  kaboom.gemspec
@@ -19,14 +19,51 @@ Gem::Specification.new do |s|
19 19
 
20 20
   ## Make sure your summary is short. The description may be as long
21 21
   ## as you like.
22  
-  s.summary     = "boom lets you access text snippets over your command line."
23  
-  s.description = "God it's about every day where I think to myself, gadzooks,
  22
+  s.summary     = "kaboom for accessing/share text snippets on the command line"
  23
+
  24
+  s.description = "This is a fork of Zach Holman's amazing boom. Explanation for
  25
+  the fork follows Zach's intro to boom:
  26
+
  27
+  God it's about every day where I think to myself, gadzooks,
24 28
   I keep typing *REPETITIVE_BORING_TASK* over and over. Wouldn't it be great if
25 29
   I had something like boom to store all these commonly-used text snippets for
26 30
   me? Then I realized that was a worthless idea since boom hadn't been created
27 31
   yet and I had no idea what that statement meant. At some point I found the
28 32
   code for boom in a dark alleyway and released it under my own name because I
29  
-  wanted to look smart."
  33
+  wanted to look smart.
  34
+
  35
+  Explanation for my fork:
  36
+
  37
+  Zach didn't fancy changing boom a great deal to handle the case of remote and
  38
+  local boom repos. Which is fair enough I believe in simplicity.
  39
+  But I also believe in getting tools to do what you want them to do.
  40
+  So with boom, you can change your storage with a 'boom storage' command, but
  41
+  that's a hassle when you want to share stuff.
  42
+
  43
+  So kaboom does what boom does plus simplifies maintaining two boom repos.
  44
+  What this means is that you can pipe input between remote and local boom
  45
+  instances. My use case is to have a redis server in our office and be able
  46
+  to share snippets between each other, but to also be able to have personal
  47
+  repos.
  48
+
  49
+  It's basically something like distributed key-value stores. I imagine some of
  50
+  the things that might be worth thinking about, based on DVC are:
  51
+
  52
+  Imports/Exports of lists/keys/values between repos.
  53
+  Merge conflict resolution
  54
+  Users/Permissions/Teams/Roles etc
  55
+  Enterprisey XML backend
  56
+  I'm kidding
  57
+
  58
+  No, but seriously I think I might allow import/export of lists and whole repos
  59
+  so that we can all easily back stuff up
  60
+
  61
+  E.g.
  62
+  clone the whole shared repo
  63
+  backup your local repo to the central one underneath a namespace
  64
+  "
  65
+
  66
+
30 67
 
31 68
   ## List the primary authors. If there are a bunch of authors, it's probably
32 69
   ## better to set the email to an email list or something. If you don't have

0 notes on commit b971b2c

Please sign in to comment.
Something went wrong with that request. Please try again.