Re: Status of all files (was: Re: How can I tell if a file is ignored by git?
- From
Daniel Grace <negativeview@gmail.com>
- Date
- Apr 9, 2010, 23:18 UTC
- Message-ID
- <t2w62a3a9cb1004091618i13fff1a7iad65e073e2292848@mail.gmail.com>
- In-Reply-To
- <z2h62a3a9cb1004091615q52bd5f5aqc24079de7f0038ba@mail.gmail.com>
Eric,
I am working on a similar program (not ready for announcing yet). I have not gotten to the part that would need this, but I would be happy to start planning that stage and work with you to make sure that this feature met both of our needs, and help write the documentation if need be.
(Sorry for the double everyone in To/Cc, gmail defaulted to HTML email and it was rejected from the list. I had to To/Cc you all again so that Reply All from list members would work as expected.)
Daniel http://www.doomstick.com
On Fri, Apr 9, 2010 at 6:15 PM, Daniel Grace <negativeview@gmail.com> wrote:
Show 48 quoted lines
> > Eric, > I am working on a similar program (not ready for announcing yet). I have not gotten to the part that would need this, but I would be happy to start planning that stage and work with you to make sure that this feature met both of our needs, and help write the documentation if need be. > Daniel > http://www.doomstick.com > > > On Fri, Apr 9, 2010 at 11:24 AM, Eric Raymond <esr@thyrsus.com> wrote: >> >> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>: >> > Eric Raymond <esr@thyrsus.com> writes: >> > >> > > (The ls-files -t codes need better documentation. If I get detailed enough >> > > answers, I will write some.) >> > >> > http://thread.gmane.org/gmane.comp.version-control.git/126516 >> > >> > In short, "git ls-files -t" was written long ago, never tested, and >> > probably mostly used by no one. It has a very strange behavior, it's >> > not just the doc. I'd advise against using it. >> >> It sounds very much to me as though this feature should be scheduled >> for deletion. >> >> > "git status --porcelain" is probably what you want: >> > >> > --porcelain >> > Give the output in a stable, easy-to-parse format for >> > scripts. Currently this is identical to --short output, but >> > is guaranteed not to change in the future, making it safe >> > for scripts. >> >> Yes, this looks like what I would want, all right - if the status >> codes were actually *comprehensible*! >> >> We should tackle this right now, because VC is not the last front end >> that will need to parse the format and at least I am willing to patch >> your docs based on what I learn. Most of your other customers won't >> do that. >> >> I'm going to start a separate thread about this. >> -- >> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >