Thread (8 messages) flat view 8 messages, 3 authors, 2016-06-15

Re: [HELP] Adding git awareness to the darning patch management system.

From: Jeff King <hidden>
Date: 2016-06-15 22:52:33

On Fri, Dec 02, 2011 at 09:32:50AM +1000, Peter Williams wrote:
Yes, I think your right.  For most of my purposes, I think that it's
irrelevant whether a change is staged or not and the choices that I
offer allow the user to do what he thinks is right for a file with
changes that are staged but uncommitted.  For me to automatically do
something based on whether the file was staged for a commit would be
a mistake as I would be reducing the user's options.

However, the distinction might be worth making in the file tree
display to remind the user what's staged and what's not?
I'd personally start with ignoring the distinction, and then wait for
some enterprising user to suggest how it would be marked. That takes the
burden off of you for guessing what representation would be best.
As an aside, I found it easier to delve into git's innards to find
out how to implement git binary patches than I did finding out how to
do things from the CLI :-).
Heh. I think that is because the CLI is written by people (myself
included) who want it to give them access to git's innards. ;)
quoted
In your case, I think "status" is the most convenient level of
abstraction for you, because you are interesting in looking at
differences to both the index and HEAD (i.e., the prior commit). But if
you find as you implement that want more flexibility, you can switch to
using the lower-level commands yourself.
I'll investigate this approach.  How easy is it to distinguish low
level commands from high level commands?
git(1) has a list of "porcelain" and "plumbing" commands. If you are
scripting, you generally want to stick with plumbing commands,
lower-level whose output and behavior remains stable across releases.

However, some porcelain commands offer a "plumbing" mode (despite the
name, the "--porcelain" flag to some commands is what you want; it is
about offering parseable output that a custom porcelain could use. In
git lingo, your interface is one such porcelain).

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help