Hi, On Sat, 5 Jul 2008, Alex Riesen wrote: > Junio C Hamano, Sat, Jul 05, 2008 00:09:41 +0200: > > Alex Riesen <raa.lkml@xxxxxxxxx> writes: > > > > > Stephan Beyer, Tue, Jul 01, 2008 04:38:30 +0200: > > >> > > >> here is the patchset for the git-sequencer prototype, > > >> documentation, test suite and a first git-am and git-rebase-i > > >> migration. Indeed, monster patches. ;) > > > > > > BTW, how about renaming it in something short: git seq. There is > > > already a seq(1) in GNU coreutils, which does roughly the same > > > (prints a sequence of numbers), why not reuse the name? > > > > Is it advantageous to use shorter but less descriptive name for this > > command? It will be a backend to am/rebase and not something the > > users will type from the command line, won't it? > > There is not a huge lot of possible meanings of "seq" in the given > context. Somehow I find it hard to believe someone will be confused by a > backend command with a short name "seq" (seq-uence-something?) It might be a bit confusing, since "seq" _produces_ sequences, and "sequencer" is kind of an assembly line, getting commits in a sequence and then applying the corresponding changes in order. > It'll make the lines shorter, less need to wrap them. By that reasoning, we should have git-a, git-b, ... but that would not improve readability. > BTW, what does "am" (git am) mean? It means "applymbox", but that name was already taken. And "am" turned out _not_ to replace "applymbox" right away as was expected, so it is a bit of unfortunate history. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
