Thread (35 messages) flat view 35 messages, 14 authors, 2016-06-15

Re: Using StGIT for tweaking already-committed stuff

From: Yann Dirson <hidden>
Date: 2016-06-15 22:43:09

On Fri, May 11, 2007 at 12:23:47AM +0200, Karl Hasselström wrote:
On 2007-05-10 22:02:53 +0200, Petr Baudis wrote:
quoted
Yes, I fear that StGIT hides the index in a similar way that Cogito
does. It seems like user index usage is undergoing kind of
renaissance these days in Git community (at least it seems to me
this way, maybe it's always been this way), it would probably make
sense to allow making use of index in StGIT as well.
I agree. It's bad UI for StGIT to behave different from git, given
that easy interoperation is a goal.
Well, that's an idea that already appeared in some discussions - I
can't speak for Catalin, but I too think it could be a good thing.

Eg, if we're going to use the patchlogs a bit more (and I wish so), it
will be much less cluttered by using the index to select what to
commit with several git-add's, than when using several stg-refresh's.

As noted elsewhere, there are some commands that are a bit superfluous
(add, rm, and the branch-switching feature directly come to mind).  It
is especially annoying, eg when "stg rm" behaves differently than "git
rm", by not removing the real file.  I have tried recently to avoid
using "git add" and "stg rm", and I am quite pleased with that :)

quoted
And yes, it would be cool if stg new could guess patch name from the
subject line in a similar manner that stg uncommit does.
Good idea. This would be embarrassingly easy to do.

But you can kind of do it today. Just commit with git (my favorite
here is the emacs modes) and "stg assimilate"!
Well, that's arguably a non-orthodox way of doing things, I like the
idea your "stg new" patch much better :)

Best regards,
-- 
Yann.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help