# workflow question 8 messages from 2007-07-24 to 2007-07-24. Participants: Patrick Doyle, Alex Riesen, Julian Phillips, J. Bruce Fields, Linus Torvalds. Thread: https://gitlist.dev/t/9202 ## Patrick Doyle, 2007-07-24 13:53 Subject: workflow question Message-ID: URL: https://gitlist.dev/e/e2a1d0aa0707240653x55dd82b3pf9e3986f5c3bb344%40mail.gmail.com ``` I'm still trying to figure out how to adapt my workflow to git or git to my workflow, and I've come up with yet another question or two... I tend to work detached from our central SVN server, and I'm attracted to the fact that I can work on my laptop, commit changes as I go along, and later synchronize them back to the server. On my current project, I am sole developer (at present) and the central SVN server serves primarly as an off-site backup and historical archive. Enough of the setup, here are the questions... 1) I would like to make a (git) branch on which I can commit hourly/daily/periodically as I add in a new feature (so that I can roll back to the "Gee, I thought it was behaving yesterday -- what does that code look like?" commit when I need to), but I don't want to send all of the "commit as of 12:32 on Thursday" commits back to the SVN server when I'm done. Do I want to use a "squash" merge to merge my changes back to the master branch before I synchronize with the subversion server? Or do I use the "--no-commit" option to merge? Or do I try something else? The first/last time I tried this, I ended up with a fast-forward merge back into master, which included all of my stupid little commit messages. I would rather one commit message that read "Added XYZ feature". 2) When I don't fork a branch, 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? 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? That's enough for now. Thanks for reading this far :-) --wpd ``` ## Alex Riesen, 2007-07-24 15:37 Subject: Re: workflow question Message-ID: <81b0412b0707240837l16844dbct52ffa426d8b8547b@mail.gmail.com> URL: https://gitlist.dev/e/81b0412b0707240837l16844dbct52ffa426d8b8547b%40mail.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. ``` ## Patrick Doyle, 2007-07-24 16:30 Subject: Re: workflow question Message-ID: URL: https://gitlist.dev/e/e2a1d0aa0707240930gb99cb0csd1ce9946d33982d%40mail.gmail.com In-Reply-To: <81b0412b0707240837l16844dbct52ffa426d8b8547b@mail.gmail.com> ``` On 7/24/07, Alex Riesen wrote: > 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". ok, I probably should have said, "When I don't create a branch, and when I have not yet committed any changes for the particular feature..." > > > ... 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" I was hoping for something less verbose than a diff or a patch file -- something that just listed what has changed -- I'll have to investigate whether your "my_status()" macro provides the information for which I was looking -- thanks for the pointer. And, as for gitk, there is something about the combination of the screen on my laptop, my Linux installation (FC6), my X server configuration, and/or me that makes the fonts totally unreadable. I keep meaning to follow up on that, but I'm stuck in a chicken-and-the-egg situation. I don't see the utility of gitk because I can't read the display that it produces. I don't look for the time to fix the display that it produces because, thus far, I don't see the utility of gitk. Sigh... > 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. > Ahhh... I was looking around git-status instead of git-diff. That makes sense now that you mention it. Someday I may have the intuitive understanding of git that would point me in that direction myself, but I ain't there yet :-) Thanks. --wpd ``` ## Julian Phillips, 2007-07-24 16:35 Subject: Re: workflow question Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0707241733370.29908%40reaper.quantumfyre.co.uk In-Reply-To: ``` On Tue, 24 Jul 2007, Patrick Doyle wrote: >> > ... 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" > I was hoping for something less verbose than a diff or a patch file -- > something that just listed what has changed -- I'll have to > investigate whether your "my_status()" macro provides the information > for which I was looking -- thanks for the pointer. "git log --stat ..master" perhaps? -- Julian --- The future isn't what it used to be. (It never was.) ``` ## Alex Riesen, 2007-07-24 20:54 Subject: Re: workflow question Message-ID: <20070724205457.GC6004@steel.home> URL: https://gitlist.dev/e/20070724205457.GC6004%40steel.home In-Reply-To: ``` Julian Phillips, Tue, Jul 24, 2007 18:35:15 +0200: > On Tue, 24 Jul 2007, Patrick Doyle wrote: > > >>> ... 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" > >I was hoping for something less verbose than a diff or a patch file -- > >something that just listed what has changed -- I'll have to > >investigate whether your "my_status()" macro provides the information > >for which I was looking -- thanks for the pointer. > > "git log --stat ..master" perhaps? > yep. Or just use the same options as with diff: $ git log -r --name-status -M -C ..master ``` ## Alex Riesen, 2007-07-24 20:57 Subject: Re: workflow question Message-ID: <20070724205702.GD6004@steel.home> URL: https://gitlist.dev/e/20070724205702.GD6004%40steel.home In-Reply-To: ``` Patrick Doyle, Tue, Jul 24, 2007 18:30:12 +0200: > And, as for gitk, there is something about the combination of the > screen on my laptop, my Linux installation (FC6), my X server > configuration, and/or me that makes the fonts totally unreadable. I > keep meaning to follow up on that, but I'm stuck in a > chicken-and-the-egg situation. I don't see the utility of gitk > because I can't read the display that it produces. I don't look for > the time to fix the display that it produces because, thus far, I > don't see the utility of gitk. Sigh... That's a real pity, because it is very powerful. Try removing ~/.gitk, or look into it and try changing the font. Here is mine, for reference: set mainfont {Helvetica 11} set textfont {Courier 11} set uifont {Helvetica 9 bold} set tabstop 8 set findmergefiles 0 set maxgraphpct 50 set maxwidth 16 set cmitmode patch set wrapcomment none set showneartags 1 set showlocalchanges 1 set bgcolor white set fgcolor black set colors {green red blue magenta darkgrey brown orange} set diffcolors {red "#00a000" blue} set selectbgcolor gray85 set geometry(main) 1005x850+1417+41 set geometry(topwidth) 1001 set geometry(topheight) 458 set geometry(pwsash0) "684 2" set geometry(pwsash1) "878 2" set geometry(botwidth) 725 set geometry(botheight) 372 set permviews {} ``` ## J. Bruce Fields, 2007-07-24 21:00 Subject: Re: workflow question Message-ID: <20070724210024.GC5040@fieldses.org> URL: https://gitlist.dev/e/20070724210024.GC5040%40fieldses.org In-Reply-To: <20070724205702.GD6004@steel.home> ``` On Tue, Jul 24, 2007 at 10:57:02PM +0200, Alex Riesen wrote: > Patrick Doyle, Tue, Jul 24, 2007 18:30:12 +0200: > > And, as for gitk, there is something about the combination of the > > screen on my laptop, my Linux installation (FC6), my X server > > configuration, and/or me that makes the fonts totally unreadable. I > > keep meaning to follow up on that, but I'm stuck in a > > chicken-and-the-egg situation. I don't see the utility of gitk > > because I can't read the display that it produces. I don't look for > > the time to fix the display that it produces because, thus far, I > > don't see the utility of gitk. Sigh... > > That's a real pity, because it is very powerful. > > Try removing ~/.gitk, or look into it and try changing the font. (Also, as a quick fix, note that ctrl-- and ctrl-= will adjust the font size down or up (respectively).) --b. ``` ## Linus Torvalds, 2007-07-24 21:38 Subject: Re: workflow question Message-ID: URL: https://gitlist.dev/e/alpine.LFD.0.999.0707241433360.3607%40woody.linux-foundation.org In-Reply-To: <20070724210024.GC5040@fieldses.org> ``` On Tue, 24 Jul 2007, J. Bruce Fields wrote: > > (Also, as a quick fix, note that ctrl-- and ctrl-= will adjust the font > size down or up (respectively).) Side note: this can be *really* confusing on non-US keyboards. The "=" makes sense on a US keyboard, because it's really "ctrl-+" without the added need to press "shift". On many non-US keyboards, there is no such arrangement of +/= on the keyboard. So on a Finnish keyboard, for example, the sequence to make the fonts smaller is "ctrl--", but the sequence to make them larger is "contr-shift-0". Which makes *no* sense what-so-ever, but the "=" sign is "shift-0". Oh, well. On a Finnish keyboard, "ctrl-+" would make tons of sense. I always try it, and am frustrated when it doesn't work. Linus ```