I think it's a bad idea to name your project after a very, very popular childrens' character and then go 1 step further and use the same color scheme for your page.
My understanding of copyright laws is that they only apply when the term is being used in the same space as another copyright. So if I made another cartoon character named tigger that would be illegal, but creating something completely separate (especially something like OS software where I'm not really selling anything) the copyright doesn't really apply. I'm gathering from HN that this is an incorrect interpretation, can anyone explain it to me?
Consider: even if your interpretation were legally correct, what matters is your ability to convince a court to say so when Disney sues you.
That's probably an enormous expense that you'd be better off avoiding altogether by changing the name. Rebranding is also a lot easier now than once you've grown large enough to have shown up on Disney's radar.
If it has potential to cause customer confusion, it might be a trademark violation. A company is required to defend their trademarked terms, otherwise they may become generic terms.
(Standard I Am Not a Lawyer disclaimer. Go talk to a real one if you're worried.)
Definitely legitimate concerns. It grew out of reversing the word git since it's git integrated task management and adding an extra ger. I'll definitely think about changing it - maybe shorten it to tig?
Searching is a serious consideration, but I think most people will search for something like 'tigger task manager' or 'tigger cli'. There's enough differentiation between this app and the children's character.
On the other end of the spectrum is 'Numbers', Apple's spreadsheet app. Try Googling for help with that one. Same thing with 'Pages'.
If you need help managing you animated big cat project with pooh and eeyore thru Tigger, then you might be in trouble.
$ hg task Fix the data-eating bug.
$ hg task
e - Fix the data-eating bug.
$ vim myproject.py
... fix the bug ...
$ hg task -f e
$ hg commit 'Fix the big data-eating bug.'
Ooooh, you're about two months too late for me! If I hadn't discovered taskwarrior a few months back I would be all over this, though I must admit having all my tasks in git is nice.
- why "sudo make"? Wouldn't it be cleaner to separate the compilation part and the installation part, and only run the second one as root (and if you want to install system-wide)?
- what's the license of this code?
By the way, you might want to steal ideas from Taskwarrior, which is very similar (but without the git part).
- You might want to drop object files, backup files and the like from your repo.
- The limitation to 255 chars is weird. Not sure if C was the best tool for this kind of job, but if you're using it, you might want to check getline(3).
- Maybe it would make sense to have a way to store the task db as a visible TODO file, and store it in a human-editable format? That way, people who aren't using tigger can just see and manage tasks with a text editor, and you're just providing convenient hooks and commands to edit the TODO file. It's probably a bad idea to use this name by default because projects tend to have TODO files already, but maybe it would be a useful option.
So if you wanted to add a task without using the command line you just open up the .tigger file in the project directory - maybe I should make this visible to the average user?
I literally only chose C by looking at what Git is written and deciding that I wanted to try going back to C after a few years away from it. I'm curious what you think would have been a better choice and why?
Well, I don't see any good reason to write this in C. The operations performed are very basic, and it only obscures what you're doing. Further, your program relies on Ruby and Grit (that gem itself an onerous dependency) to do things that require neither tool. This seems to be the sort of thing that should either be in pure C if you really want that, or as a standalone script that requires nothing, given its simplicity. And if it were a standalone Python script, for instance, you could easily use the "inspect" module to write some inline source to file. All that Ruby source in a C header is a very odd decision to me.
If I were writing this with the understanding that it were not to work on Windows (which you seem to have decided, upon reading the source), I think I'd just use a simple shell script.
I will add that there is no good reason at all to require an "init" command, as that could be a simple get-or-set method when another command is used.
Viewing the commit history, you need to be far more careful with how you use git and how you define your .gitignore.
That's a good idea to separate the installation from compilation. This is my first command-line utility, and I wrote it pretty quickly so I haven't thought about a few things like that, nor have I thought about the license.
Is there a good way to choose between the different open-source licenses?
I saw taskwarrior in another comment and I'll definitely check it out. Thanks for the feedback!
First, this is a really cool idea, and something that I need.
Second, at the risk of disrupting the author's groove (and further belaboring the established criticism of the project name), I've become accustomed to git's convention for commands. A synonymous git-task command would be nice to have for something like this.
Thank you so much for the feedback, I'm really happy I was able to create something that people need.
I'm sorry but I'm a little confused as to what the second part of your comment is suggesting. Are you saying that the name should be changed to something like git-task, or that the commands for the utility should follow git's command conventions?
Oh awesome I didn't know about that I'll definitely look into it. Do you think people would be more likely to use it because they can type 'git' instead of 'tigger' (or whatever name it ends up being)?
It would definitely fit into git's naming convention for commands better. Whether or not that makes it stickier with users is probably an question only focus testing can answer :)
I don't like having to specify the task in the comment, simply because the risk of typos. It would be nicer if I could issue a command prior to committing that would let me flag the tasks complete, then it automatically adds it to the comment/handles finishing the task.
ie,
tigger mark
> 1) re-factor classes
> 2) improve optimization
> Enter numbers to mark task for completion, or blank to end:
That would be simply enough to implement. I will look into it a little more. I think part of the reason I didn't do that is because I wanted it to be automatically marked off based on your git commits. But that's not as important as better usability in the long run.
This is pretty cool. Not to steal dan's thunder, but there is a similar project called git-issues that uses a separate branch instead of a dot file. Might be an approach worth checking out.
That's actually a really well put together implementation of what I was trying to do. Thanks for showing it to me.
I wonder what the benefits/drawbacks of using a separate branch vs keeping it on the current branch are. One thing I can think of is that with Tigger you can maintain different task lists based on which branch you're on. Having it on a separate branch does seem like it might make it easier to manage though.
Having a Git history of my tasks is nice, but this is functionally equivalent to Gina Trapani's Todo.txt (todotxt.com) CLI app/mobile app, which uses Dropbox rather than Git to host the list in the cloud.
It is standard for a command to accept a -h/--help option and display usage, and for commands with subcommands to accept a "help" command to do the same. It appears in your source that usage is only displayed when an invalid command is specified, or a command is not used properly.
Check out the pomo gem. It works in a very similar way plus it adds a 25-minute timer for pomodoros. If you add your .pomo file to git would do the same integration.
This looks really cool. Like other people have said, I'd take a look at TaskWarrior and some of their functionality.
Having it inside a git repo is really, really awesome.
Tigger will mark as completed any task that it finds in your commit message. So if you have a task called "fix homepage" and your commit message contains the string "fix homepage" then Tigger will mark the "fix homepage" task as completed. Hope that clears things up
So when you activate Tigger in a directory that is also a Git repo Tigger automatically adds a file called .tigger to the repo. This file contains all of your tasks. So when you push your repo to Github it also pushes the .tigger file. From there whoever pulls the repo down will also get the task list. Hope that helps.
1, It's going to incur wrath.
2, It's really, really hard to search for.