flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric THOMAS <webdoubl...@hotmail.com>
Subject Re: [OT] Log history
Date Sat, 23 Mar 2013 15:26:47 GMT
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.


-----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" <webdoublefx@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
> <webdoublefx@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" <labriola@digitalprimates.net>
>> wrote:
>>> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <gosmith@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.

View raw message