Re: [PATCH] RFC - Say goodbye to the rodent

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Aug 05, 2009 at 05:51:40PM +0800, Nazri Ramliy wrote:

> The idea is that "git status --id" shows a unique id for each file in
> its output (modified/staged/unknown/etc). The ids and the
> corresponding filenames are stored in .git/FILE_IDS. This file gets
> overwritten everytime you run "git status --id"

But files _already_ have a unique id: the filename. You never say why
those unique ids must be cut-and-pasted using the mouse when your unique
ids would be suitable for typing, but I'll assume it's because your
unique ids are much shorter than your filenames.

There are already two classes of solutions to this problem:

  1. Make typing the filenames easier. Generally, this is accomplished
     by tab completion. Even stock bash (and other shells) should
     complete filenames easily, but you can also complete much more
     using the programmable bash completion included with git.

     The main advantage of this approach is that it is totally
     generalizable. Anytime you have to input a filename, you can use
     it.

  2. Structure your workflow to iterate over the list of items to be
     acted on, and then select actions for each item. This is what "git
     add -i" does, as well as "git mergetool" and "git difftool".

     This can save a lot of typing over (1), but requires a new script
     for every such workflow (e.g., the scripts above cover only adding,
     resolving merges, and diffing; you would need a new script to
     iterate over files, doing "git checkout" on each one, for example).

I think your solution is a third class, which is to assign a mapping of
shorter ids to items that persists over multiple commands. But it's not
clear to me where it has an advantage over the existing two solutions.
It is actually less general than (1), because you have to have assigned
the mappings beforehand. But it is not nearly as convenient as (2).

In addition, it's more complicated to implement and use, because you
have to care about the persistence of the mapping (i.e., how long does
it last, which commands reset it, etc).

So while it is somewhat clever, I don't think it is worth merging to
mainline git; it introduces complexity to solve a problem that already
has overlapping solutions.

-Peff
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]