OK, so stash does an add and saves what is in the staging area?
On 3/23/13 8:26 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: > What is committed are in the git storage/history, not the things in the > stage area, that's an intermediary zone between your working area and git > storage to prepare your commit. > > -Fred > > -----Message d'origine----- > From: Alex Harui > Sent: Saturday, March 23, 2013 4:12 PM > To: dev@flex.apache.org > Subject: Re: [OT] Log history > > Is it different if you have stuff already staged and/or committed? > > > On 3/23/13 7:52 AM, "Frédéric THOMAS" <webdoubl...@hotmail.com> wrote: > >> Hi, >> >> I'm not sure I understand what you ask but your untracked files are here >> for >> every branches, so it's better to stashed them, your stage area will be >> stashed as well. >> btw, to include untracked files it's "git stash -u", sorry :P >> >> -Fred >> >> -----Message d'origine----- >> From: Mark Kessler >> Sent: Saturday, March 23, 2013 3:32 PM >> To: dev@flex.apache.org >> Subject: Re: [OT] Log history >> >> Well if he was modifying files in a feature branch then switched to an >> entirely different branch to do that testing... would he even have to >> worry >> about stashing or such? >> >> >> >> On Sat, Mar 23, 2013 at 10:17 AM, Frédéric THOMAS >> <webdoubl...@hotmail.com>wrote: >> >>> I would do that: >>> >>> git stash (to save your untracked files of the branch your working on) >>> git checkout develop >>> git log (here get the hash of your HEAD) >>> git reset --hard <HASH/TAG> (to the point you want to go back in the >>> history, can be nothing if your current version is stable) >>> git checkout <REMOTE_BRANCH_TO_TEST> >>> >>> Test the branch, once finished: >>> >>> git reset --hard <HEAD> (the hash you previously saved). >>> git checkout <BRANCH> (the branch you're working on) >>> git stash apply (to get back your untracked files) >>> >>> -Fred >>> >>> -----Message d'origine----- From: Alex Harui >>> Sent: Saturday, March 23, 2013 2:58 PM >>> To: dev@flex.apache.org >>> Subject: Re: [OT] Log history >>> >>> OK, nice story. But for me, I have no idea how you "pull in his changes >>> and >>> review". Or "go back and test against unmodified code". And are you >>> stashing or committing your changes first? What git commands and flags >>> do >>> you use? >>> >>> And the main debate is: if you have a simple change to the README, are >>> you >>> creating a branch for that? >>> >>> >>> On 3/23/13 2:05 AM, "Michael A. Labriola" <labri...@digitalprimates.net> >>> wrote: >>> >>> >>>> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <gosm...@adobe.com> wrote: >>>> >>>>> I plan to do my Falcon development work on the 'develop' branch. The >>>>> full >>>>> nvie model is complete overkill for what I am doing and I don't need >>>>> umpteen >>>>> feature branches. Has everyone forgotten about KISS? >>>>> >>>>> - Gordon >>>>> >>>>> >>>> I understand where all the confusion comes from and taken as a whole, it >>>> does >>>> seem like overkill. I think it's less so in practice but by way of >>>> example, >>>> here is a minimal version of what I do on a daily basis for my own >>>> projects. >>>> Maybe some of this helps, maybe not. I am not trying to assert my >>>> workflow for >>>> any of you. You are doing work on this and I am not. Just thought it >>>> might >>>> help presented this way and help you see where I see the value. >>>> >>>> Let's say I am going to work on refactoring SomePiece. >>>> I make a quick branch called SomePieceRefactor. >>>> >>>> First, what does this mean. In git this really just means that I am >>>> going >>>> to >>>> record a pointer to where the code was when I started so that I can >>>> easily go >>>> back. It's just a pointer to what code looked like at a point in time, >>>> not a >>>> copy. >>>> >>>> Second, why bother? A couple of reasons. I might work on SomePiece but >>>> before >>>> I have the chance to finish I need to go patch a bug elsewhere, I can >>>> easily >>>> keep my changes and go back to what the repo looked like before. >>>> >>>> Or perhaps someone else on my team commits a potential fix for something >>>> and >>>> wants my opinion. It may not work (or simply might not be fair) to >>>> integrate >>>> that with my half-baked code. So, instead, I can jump back to the last >>>> point >>>> where the repo was stable. Make a quick branch called TestJimsChanges, >>>> pull in >>>> his changes and review. If they look good, I can then leave them be, or >>>> (if I >>>> really need them) switch back to my SomePieceRefactor and integrate his >>>> code. >>>> The point of the branches are really just pointers or bookmarks that I >>>> can use >>>> the manage my own workflow. They really aren't (at this point) for >>>> anyone >>>> else. >>>> >>>> When I am satisfied with SomePieceRefactor, I tend to leave that branch >>>> hanging around. Why? Well, for me, it's useful because later when >>>> someone >>>> discovers a bug, I can very quickly go back and test against my >>>> unmodified >>>> code. Was the bug there from the beginning or was it caused by something >>>> after >>>> this point or something someone else did? I quickly reduce the amount of >>>> debugging I do by having these points in history to look at. >>>> >>>> When all is said and done, I push my changes to develop. So, personally, >>>> I am >>>> not making a million branches out in the project, the branches are for >>>> me, >>>> they are for my workflow and they are tools I use. So what does this >>>> extra >>>> branch/workflow cost me. Well, in my experience so far it's actually >>>> saved me >>>> time, not cost me any. Making a branch is a quarter of a second of my >>>> time and >>>> the fact that I can task switch so quickly, review others code, test >>>> combinations (their code with the original branch, their code with my >>>> latest) >>>> before I need make any final commitments to pushing these live is hugely >>>> helpful to me. >>>> >>>> So, everyone's mileage may vary and again you need to do what you feel >>>> is >>>> best, but I wanted to provide a concrete though on the whole branching >>>> thing >>>> and perhaps peel back some of the complexity of the situation. >>>> >>>> Hope that helps a little, >>>> Mike >>>> >>>> >>>> >>>> >>> -- >>> Alex Harui >>> Flex SDK Team >>> Adobe Systems, Inc. >>> http://blogs.adobe.com/aharui >>> >>> >> -- Alex Harui Flex SDK Team Adobe Systems, Inc. http://blogs.adobe.com/aharui
