<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div><br></div><div><br><div><div>On Feb 14, 2012, at 4:44 PM, Na'Tosha Bard wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hello,<br><br>I am considering taking up development of the proposed Indexes Extension described on <a href="http://mercurial.selenic.com/wiki/IndexesExtension">http://mercurial.selenic.com/wiki/IndexesExtension</a><br clear="all">
<br>What I would like to know is why is it not implemented yet?  Is it only because no one had the time or desire, or are the core Mercurial developers opposed to this sort of functionality?<br></blockquote><div><br></div><div>Here is my 2c.</div><div><br></div><div><div><div>On a philosophical point I think such things are much better done in a GUI if</div><div>one needs to do them. Picking out a bunch of files and hunks from a list of</div><div>files, is something which GUI clients can excel at. (Actually, coincidentally</div><div>during off work time, I have been frantically working on this for MacHg and now</div><div>have had very nice hunk level selection going in my development versions of</div><div>MacHg for a while. (Along with many other new features flat file, and outline</div><div>views, etc.) I haven't released this to the world yet though...) (But I have</div><div>thought about this from a GUI perspective.)</div><div><br></div><div>The index (in git) can be quite confusing for new users, and is basically at</div><div>base a way to select a bunch of files and hunks from the existing set of</div><div>changes. And this, as commented would be best done in a gui, or with a little</div><div>more pain with the record extension. I can see that the index would be sort of</div><div>useful if you are restricting yourself to only have the command line, but still</div><div>it would be a rather poor substitute for a GUI. The one thing that users might</div><div>say is "I can add to the index as I go and then just commit at the end". My</div><div>response to this is if the commit is big enough that you would have trouble</div><div>remembering which bits to commit then you almost always necessarily have to</div><div>review the bits you would commit in any case, ie pick out the files and hunks</div><div>that would be part of the commit.</div><div><br></div><div><div>So I am not wild about this in core at the very least, since it is definitely a</div><div>big complication to normal work flow. As an extension I guess some people might</div><div>use it though...</div><div><br></div></div></div></div></div>Cheers,</div><div>   Jas</div></body></html>