From: Alex Riesen Date: Tue, 24 Jul 2007 15:37:43 GMT Subject: Re: workflow question Message-ID: <81b0412b0707240837l16844dbct52ffa426d8b8547b@mail.gmail.com> In-Reply-To: On 7/24/07, Patrick Doyle wrote: > 2) When I don't fork a branch, this is a confusing sentence: "fork" does not happen as an explicit operation (if at all). You just commit somewhere and depending on how you look at the history you either see or not see a "fork". > ... and I don't commit until I've completed > the particular feature I'm working on, I can get a fairly good idea of > where I am and what I was doing last (which might be 5-7 days ago, > given high priority interrupts on other projects, summer vacations, > etc...) just by running a "git status". I see that there are 7 new > files, and 2 modified files. I know that, when I fork my branch, I > can use "git diff master" to see what's different between my branch > and the master, but then I get the diff of all of the changes as well, > which is too much information. "git diff --name-only" and "git diff > --summary" are closer, but I can't tell what's been added vs. what's > been changed. Any suggestions? "git log -p ..master", or even simpler "gitk ..master" > As an aside, is there an undocumented option to "git status" to > produce a less verbose report of what's been changed and what's not > checked in? Perhaps a single line per file with a one or two letter > indication of the status of the file followed by the name? If not, > would there be any violent objections to my submitting a patch to add > such a feature? my_status() { git diff --cached --name-status -r -M -C HEAD -- "$@" && \ git diff --name-status -r -M -C -- "$@" } Use as: my_status [pathname-limiter]. Does not show untracked files, though.