You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by "Justin Mclean (JIRA)" <ji...@apache.org> on 2013/03/21 01:17:15 UTC
[jira] [Created] (FLEX-33440) Make AIR optional
Justin Mclean created FLEX-33440:
------------------------------------
Summary: Make AIR optional
Key: FLEX-33440
URL: https://issues.apache.org/jira/browse/FLEX-33440
Project: Apache Flex
Issue Type: Bug
Components: Installer
Reporter: Justin Mclean
Priority: Minor
The installer downloads AIR. AIR is not required for browser applications so it should be an optional download.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [jira] [Created] (FLEX-33440) Make AIR optional
Posted by Kessler CTR Mark J <ma...@usmc.mil>.
My apps are all web based (US Govt IE8 user base). The client PCs have the latest versions of the flash player, but the last approved version of AIR was v1.5 (which isn't installed anyways). So that rounds out AIR here and HTML5 for the time being.
-Mark
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Thursday, March 21, 2013 1:02 AM
To: dev@flex.apache.org
Subject: Re: [jira] [Created] (FLEX-33440) Make AIR optional
Oddly enough there's people out there that still only make web based application.
Re: [jira] [Created] (FLEX-33440) Make AIR optional
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Where folks overlay the wrong version of the AIR
> sdk manually and it breaks everything.
If they use the installer or the scripts in the ide directory there should be no issues. If they do it manually there always a chance it will break.
> Moreover, having the AIR SDK allows folks to quickly create mobile and
> desktop versions.
Oddly enough there's people out there that still only make web based application.
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
> And I may be being stupid here but the log looks fine to me. Everything is
> in the correct order as far as I can see. What exactly is the issue with
> the log? Other than perhaps the useless merge develop into develop
> comment?.
As soon as you push after someone else, you work has to appear on top of
what the others did, making a log graph flat, the only exceptions are if you
worked on a branch and merged it, in order to preserve the work clear in the
history, your merge has to appear and a parallel line shown on the graph,
the only other exception should be (not recommanded though) if you work
directly on the develop branch, have commits (generaly more) and you want
them to appear as a merged branch, in this case, you use "git pull --no-ff"
(Which create a merge commit even when the merge resolves as a
fast-forward), in every other cases, the graph should be flat.
Thanks,
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Thursday, March 21, 2013 7:31 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
> I would like to bring to your attention that after 3 'git push', the log
> history looks already exotic, nobody did branches but it looks like there
> are [1].
And I may be being stupid here but the log looks fine to me. Everything is
in the correct order as far as I can see. What exactly is the issue with the
log? Other than perhaps the useless merge develop into develop comment?.
* 7e6fe20 Added support for Flash Player 11.7
* 8392018 Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
|\
| * f292ce0 added 38 Mustella tests for CallOutButton and removed a not
existing skin CallOutArrowSkin in defaults.css
| * bbb75ce FLEX-33350 adding CallOut components to experimental project -
component patch by Marcus Fritze .
| * 3016ec4 moved new components Accordion, DataAccordion, InlineScroller
.. new layouts AccordionLayout, CarouselLayout, Co
| |\
| | * 0d3bf3b moved new components Accordion, DataAccordion, InlineScroller
.. new layouts AccordionLayout, CarouselLayout, Co
* | | 3461a16 Added support for Flash Player 11.7 and AIR 3.7. Updated FP
11.6 playerglobal.swc MD5
|/ /
* | 4f6c47d Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
|\ \
| |/
| * b5fce93 FLEX-33435 added more details
| * 9c7c97e Updated for the Svn to Git migration
* | 85af480 Added el_GR locale for postcodes
* | 63580a8 Adding more datagrid double click modes
|/
* c5869e4 Added nl_NL locale for postcode validator
* cbfeae5 Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
|\
| * 5e15ba8 OS X specific entry for flex-tlf link
* | f825b4a Added fi_FI locale for postcode validator
|/
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I would like to bring to your attention that after 3 'git push', the log history looks already exotic, nobody did branches but it looks like there are [1].
And I may be being stupid here but the log looks fine to me. Everything is in the correct order as far as I can see. What exactly is the issue with the log? Other than perhaps the useless merge develop into develop comment?.
* 7e6fe20 Added support for Flash Player 11.7
* 8392018 Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
|\
| * f292ce0 added 38 Mustella tests for CallOutButton and removed a not existing skin CallOutArrowSkin in defaults.css
| * bbb75ce FLEX-33350 adding CallOut components to experimental project - component patch by Marcus Fritze .
| * 3016ec4 moved new components Accordion, DataAccordion, InlineScroller .. new layouts AccordionLayout, CarouselLayout, Co
| |\
| | * 0d3bf3b moved new components Accordion, DataAccordion, InlineScroller .. new layouts AccordionLayout, CarouselLayout, Co
* | | 3461a16 Added support for Flash Player 11.7 and AIR 3.7. Updated FP 11.6 playerglobal.swc MD5
|/ /
* | 4f6c47d Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
|\ \
| |/
| * b5fce93 FLEX-33435 added more details
| * 9c7c97e Updated for the Svn to Git migration
* | 85af480 Added el_GR locale for postcodes
* | 63580a8 Adding more datagrid double click modes
|/
* c5869e4 Added nl_NL locale for postcode validator
* cbfeae5 Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk into develop
|\
| * 5e15ba8 OS X specific entry for flex-tlf link
* | f825b4a Added fi_FI locale for postcode validator
|/
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
IMO none of this is clearly documented and there's been conflicting info sent to the list about rebase, noff etc etc. I've asked several times but no one step forward to sort out.
All of the basic Git usages docs don't use rebase and the official git doc warn against using it.
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Ok, from what Erik said on a previous post and because he is on OSX, it
appears there's one more extension to add to the .gitignore.
I you do a release, I guess other files will be candidate to an addition
into this file too, I guess you can manage that, simply add those
files/folders to the "Apache Flex Project" section of the .gitignore file,
if you use sourceTree, look at the untracked files, if you use the command
line, use git status to see them.
Once done, you'll be able to do a "git pull --rebase".
Note: if you didn't add/modify files, you can safely do a normal "git pull",
no risks here.
Thanks,
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Thursday, March 21, 2013 8:20 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
> Well, I completed my .gitignore right after a sdk build + other locales, I
> put the generated files/folders to be exclude from git operations in the
> .gitignore to avoid this kind situation, do you mean it still happens ?
Yep it still happens. Unless there something more I need to do with
.gitignore? It's checked in right?
Git pull --rebase gives:
Cannot pull with rebase: You have unstaged changes.
Please commit or stash them.
Did you do a release build or run any mustella tests?
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Well, I completed my .gitignore right after a sdk build + other locales, I put the generated files/folders to be exclude from git operations in the .gitignore to avoid this kind situation, do you mean it still happens ?
Yep it still happens. Unless there something more I need to do with .gitignore? It's checked in right?
Git pull --rebase gives:
Cannot pull with rebase: You have unstaged changes.
Please commit or stash them.
Did you do a release build or run any mustella tests?
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Well, I completed my .gitignore right after a sdk build + other locales, I
put the generated files/folders to be exclude from git operations in the
.gitignore to avoid this kind situation, do you mean it still happens ?
Thanks,
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Thursday, March 21, 2013 8:06 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
Part of the issue here is that you almost always going to have unstaged
changes in the SDK eg rat report, mustella test results, player swc or AIR
SDK files etc etc. In that case a git pull -rebase will always fail with
"Cannot pull with rebase: You have unstaged changes." .And you don't want to
commit these things into the SDK and I think in this case git stash will
remove the changes you actually want to commit?
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Part of the issue here is that you almost always going to have unstaged changes in the SDK eg rat report, mustella test results, player swc or AIR SDK files etc etc. In that case a git pull -rebase will always fail with "Cannot pull with rebase: You have unstaged changes." .And you don't want to commit these things into the SDK and I think in this case git stash will remove the changes you actually want to commit?
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Justin,
Really, I tried to be as clear as possible, unfortunately, we can't do graph
(except maybe in ASCII) on the list, but as an example of the commands I
used to demonstrate thoses cases, please look at the "[3/3] git commit:
Merge branch 'develop' of https://git-wip-us.apache.org/repos/asf/flex-sdk
into develop" thread.
Thanks,
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Thursday, March 21, 2013 7:42 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
> You should always do a "git pull --rebase" before pushing except, AFAIK
> when you have a "merged local banch not yet push", from the tests I did on
> my git lab relative to the info Desa gave, I can't see an other situation
> where a "git pull --rebase" rewrite/flattened your merged commit (and
> should not), in this particular case, you do a "git pull -ff-only" instead
> (Which refuse to merge and exit with a non-zero status unless the current
> HEAD is already up-to-date or the merge can be resolved as a
> fast-forward), in this case, use "git rebase -p origin/develop" to
> preserve your "merged branch commit" to be rewrite/flattened, then you can
> push.
Sorry that's just too confusing to follow. Can you put that into words that
a non git user would understand?
Justin
Re: [OT] Log history
Posted by Dasa Paddock <dp...@esri.com>.
git commit <file> works fine too if you want to skip the stage.
See:
http://markmail.org/thread/xd6vpbz5g7a4aely
--Dasa
On Mar 21, 2013, at 1:47 PM, Alex Harui <ah...@adobe.com>
wrote:
>
>
>
> On 3/21/13 1:36 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>
>> ah, maybe you meant instead of the dot..., in this case I would have done a
>> git add README
>>
> No, it just hasn't been my experience so far that I need to run add on files
> already tracked. I'm about to push something and want to make sure I'm not
> going to screw something up.
>
> In the flex-tlf repo I modified the build.xml and just ran "git commit
> build.xml " and now "git diff remotes/origin/master" shows the right set of
> changes.
>
> --
> Alex Harui
> Flex SDK Team
> Adobe Systems, Inc.
> http://blogs.adobe.com/aharui
>
>
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
True, I use to verify first doing git status.
-Fred
-----Message d'origine-----
From: Alex Harui
Sent: Thursday, March 21, 2013 10:13 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
On 3/21/13 2:05 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Difficult to say, it makes my commits more atomic and then clearer and
> when
> I've got time I review my commits too, when I'm in a hurry, I don't do
> anything of this though :)
>
One more question: If I don't have my .gitignore set right, then "git add
." could stage a bunch of undesired files, couldn't it?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
On 3/21/13 2:05 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Difficult to say, it makes my commits more atomic and then clearer and when
> I've got time I review my commits too, when I'm in a hurry, I don't do
> anything of this though :)
>
One more question: If I don't have my .gitignore set right, then "git add
." could stage a bunch of undesired files, couldn't it?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Difficult to say, it makes my commits more atomic and then clearer and when
I've got time I review my commits too, when I'm in a hurry, I don't do
anything of this though :)
-Fred
-----Message d'origine-----
From: Alex Harui
Sent: Thursday, March 21, 2013 10:01 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
OK, then I'm pushing what I have. Run for cover!
Seriously though, it seems like I would always work this way. How often do
you run into scenarios where you are glad you staged before committing?
-Alex
On 3/21/13 1:54 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Yes, true, that's an other option I forgot because I don't use to use it
> because the git way is to work with your working area and then the stage
> area where you can prepare what you want in the commit, even at the "line
> of
> a file" level, it's the first way to clean up your work, you can then
> commit.
> There's an other way later to clean up the commits before pushing.
>
> -Fred
>
> -----Message d'origine-----
> From: Alex Harui
> Sent: Thursday, March 21, 2013 9:47 PM
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
>
>
>
> On 3/21/13 1:36 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>
>> ah, maybe you meant instead of the dot..., in this case I would have done
>> a
>> git add README
>>
> No, it just hasn't been my experience so far that I need to run add on
> files
> already tracked. I'm about to push something and want to make sure I'm
> not
> going to screw something up.
>
> In the flex-tlf repo I modified the build.xml and just ran "git commit
> build.xml " and now "git diff remotes/origin/master" shows the right set
> of
> changes.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
OK, then I'm pushing what I have. Run for cover!
Seriously though, it seems like I would always work this way. How often do
you run into scenarios where you are glad you staged before committing?
-Alex
On 3/21/13 1:54 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Yes, true, that's an other option I forgot because I don't use to use it
> because the git way is to work with your working area and then the stage
> area where you can prepare what you want in the commit, even at the "line of
> a file" level, it's the first way to clean up your work, you can then
> commit.
> There's an other way later to clean up the commits before pushing.
>
> -Fred
>
> -----Message d'origine-----
> From: Alex Harui
> Sent: Thursday, March 21, 2013 9:47 PM
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
>
>
>
> On 3/21/13 1:36 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
>
>> ah, maybe you meant instead of the dot..., in this case I would have done
>> a
>> git add README
>>
> No, it just hasn't been my experience so far that I need to run add on files
> already tracked. I'm about to push something and want to make sure I'm not
> going to screw something up.
>
> In the flex-tlf repo I modified the build.xml and just ran "git commit
> build.xml " and now "git diff remotes/origin/master" shows the right set of
> changes.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Yes, true, that's an other option I forgot because I don't use to use it
because the git way is to work with your working area and then the stage
area where you can prepare what you want in the commit, even at the "line of
a file" level, it's the first way to clean up your work, you can then
commit.
There's an other way later to clean up the commits before pushing.
-Fred
-----Message d'origine-----
From: Alex Harui
Sent: Thursday, March 21, 2013 9:47 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
On 3/21/13 1:36 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> ah, maybe you meant instead of the dot..., in this case I would have done
> a
> git add README
>
No, it just hasn't been my experience so far that I need to run add on files
already tracked. I'm about to push something and want to make sure I'm not
going to screw something up.
In the flex-tlf repo I modified the build.xml and just ran "git commit
build.xml " and now "git diff remotes/origin/master" shows the right set of
changes.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
On 3/21/13 1:36 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> ah, maybe you meant instead of the dot..., in this case I would have done a
> git add README
>
No, it just hasn't been my experience so far that I need to run add on files
already tracked. I'm about to push something and want to make sure I'm not
going to screw something up.
In the flex-tlf repo I modified the build.xml and just ran "git commit
build.xml " and now "git diff remotes/origin/master" shows the right set of
changes.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
ah, maybe you meant instead of the dot..., in this case I would have done a
git add README
-Fred
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Thursday, March 21, 2013 9:33 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Nothing, if I modify a file and just do a commit, the commit does see
anything, the only way is to do a commit -a (Tell the command to
automatically stage files that have been modified and deleted, but new files
you have not told git about are not affected) [1]
-Fred
[1] https://www.kernel.org/pub/software/scm/git/docs/git-commit.html
-----Message d'origine-----
From: Alex Harui
Sent: Thursday, March 21, 2013 9:28 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
On 3/21/13 1:23 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> 1) Why did you have to do "add ." after updating the readme?
>
> Because once committed, the stage area doesn't contains this file anymore,
> I
> have to tell it to add my added/modified/removed files, git add . (from a
> directory, the dot means: add whatever you're going to find in this
> directory/sub-directory and have been added, removed or modified).
I didn't understand. What would have happened if you didn't do "git add ."?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Nothing, if I modify a file and just do a commit, the commit does see
anything, the only way is to do a commit -a (Tell the command to
automatically stage files that have been modified and deleted, but new files
you have not told git about are not affected) [1]
-Fred
[1] https://www.kernel.org/pub/software/scm/git/docs/git-commit.html
-----Message d'origine-----
From: Alex Harui
Sent: Thursday, March 21, 2013 9:28 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
On 3/21/13 1:23 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> 1) Why did you have to do "add ." after updating the readme?
>
> Because once committed, the stage area doesn't contains this file anymore,
> I
> have to tell it to add my added/modified/removed files, git add . (from a
> directory, the dot means: add whatever you're going to find in this
> directory/sub-directory and have been added, removed or modified).
I didn't understand. What would have happened if you didn't do "git add ."?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
On 3/21/13 1:23 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> 1) Why did you have to do "add ." after updating the readme?
>
> Because once committed, the stage area doesn't contains this file anymore, I
> have to tell it to add my added/modified/removed files, git add . (from a
> directory, the dot means: add whatever you're going to find in this
> directory/sub-directory and have been added, removed or modified).
I didn't understand. What would have happened if you didn't do "git add ."?
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
1) Why did you have to do "add ." after updating the readme?
Because once committed, the stage area doesn't contains this file anymore, I
have to tell it to add my added/modified/removed files, git add . (from a
directory, the dot means: add whatever you're going to find in this
directory/sub-directory and have been added, removed or modified).
2) Why did you have to add "origin develop" to "pull --rebase"?
Because I'm on a branch which is local only, git has no remote branch
corresponding to this one, so, I update from the origin/develop
-Fred
-----Message d'origine-----
From: Alex Harui
Sent: Thursday, March 21, 2013 9:06 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Fred,
I think I almost understood this. A couple of questions:
1) Why did you have to do "add ." after updating the readme?
2) Why did you have to add "origin develop" to "pull --rebase"?
-Alex
On 3/21/13 6:55 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Justin, coming back to your first commit, I want to show you the different
> possibilities you had, I used my git lab to do that, it's like you have a
> computer and me too.
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git branch
> * develop
> master
>
> ---------------------------------
> You add locales
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
> test_Rebased_Hotfix_Without_Conflic
> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>md locales
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>cd locales
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>copy /y nul >
> pt_PT.properties
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>echo "some portugues"
> >
> pt_PT.properties
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git add .
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git commit -m "Added
> pt_PT"
> [test_Rebased_Hotfix_Without_Conflic b05fdd8] Added pt_PT
> 1 file changed, 1 insertion(+)
> create mode 100644 locales/pt_PT.properties
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git hist
> * b05fdd8 2013-03-21 | Added pt_PT (HEAD,
> test_Rebased_Hotfix_Without_Conflic) [Justin]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
>
> ---------------------------------
> In between, Fred updated the README
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git branch
> * develop
> master
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>echo "Updated README" >> README
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>type README
> This file is supposed to be updated once this repository has been
> copied."Updated README"
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git add .
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git commit -m "Updated the
> README"
> [develop f43029d] Updated the README
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
> * f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric
> THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/develop, origin/HEAD, master) [Frédéric THOMAS]
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
> Current branch develop is up to date.
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git push
> Counting objects: 5, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 303 bytes, done.
> Total 3 (delta 1), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
> 1032fa2..f43029d develop -> develop
>
> ---------------------------------
> You get the newest changes
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin
> develop
> From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
> * branch develop -> FETCH_HEAD
> First, rewinding head to replay your work on top of it...
> Applying: Added pt_PT
>
> ---------------------------------
> Look, that's the state you're going to have on the remote if you do:
> git merge test_Rebased_Hotfix_Without_Conflic
> git push
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
> * 54072f3 2013-03-21 | Added pt_PT (HEAD,
> test_Rebased_Hotfix_Without_Conflic) [Justin]
> * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
> THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master, develop) [Frédéric THOMAS]
>
> ---------------------------------
> But here, if you decide to let the others know the all work you did on
> this
> branch, we do a merge without fast forward.
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
> test_Rebased_Hotfix_Without_Conflic
> Merge made by the 'recursive' strategy.
> README | 2 +-
> locales/pt_PT.properties | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
> create mode 100644 locales/pt_PT.properties
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
> * 5cd6098 2013-03-21 | Merge branch
> 'test_Rebased_Hotfix_Without_Conflic'
> into develop (HEAD, develop) [Justin]
> |\
> | * 54072f3 2013-03-21 | Added pt_PT (test_Rebased_Hotfix_Without_Conflic)
> [Justin]
> | * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
> THOMAS]
> |/
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
> ---------------------------------
> But actually, because it was a simple commit, you revert your merge to
> have
> a flat history and push it
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
> HEAD is now at 54072f3 Added pt_PT
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
> * 54072f3 2013-03-21 | Added pt_PT (HEAD,
> test_Rebased_Hotfix_Without_Conflic, develop) [Justin]
> * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
> THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git push
> Counting objects: 5, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (4/4), 351 bytes, done.
> Total 4 (delta 0), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
> f43029d..54072f3 develop -> develop
>
> ---------------------------------
> On my machine, I update and I see a clean ordered history
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
> remote: Counting objects: 5, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 4 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (4/4), done.
> From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
> f43029d..54072f3 develop -> origin/develop
> First, rewinding head to replay your work on top of it...
> Fast-forwarded develop to 54072f3f207612429d525c6854632b265996bf9e.
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
> * 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop)
> [Justin]
> * f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
Fred,
I think I almost understood this. A couple of questions:
1) Why did you have to do "add ." after updating the readme?
2) Why did you have to add "origin develop" to "pull --rebase"?
-Alex
On 3/21/13 6:55 AM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Justin, coming back to your first commit, I want to show you the different
> possibilities you had, I used my git lab to do that, it's like you have a
> computer and me too.
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git branch
> * develop
> master
>
> ---------------------------------
> You add locales
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
> test_Rebased_Hotfix_Without_Conflic
> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>md locales
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>cd locales
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>copy /y nul >
> pt_PT.properties
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>echo "some portugues" >
> pt_PT.properties
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git add .
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git commit -m "Added
> pt_PT"
> [test_Rebased_Hotfix_Without_Conflic b05fdd8] Added pt_PT
> 1 file changed, 1 insertion(+)
> create mode 100644 locales/pt_PT.properties
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git hist
> * b05fdd8 2013-03-21 | Added pt_PT (HEAD,
> test_Rebased_Hotfix_Without_Conflic) [Justin]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
>
> ---------------------------------
> In between, Fred updated the README
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git branch
> * develop
> master
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>echo "Updated README" >> README
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>type README
> This file is supposed to be updated once this repository has been
> copied."Updated README"
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git add .
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git commit -m "Updated the README"
> [develop f43029d] Updated the README
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
> * f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/develop, origin/HEAD, master) [Frédéric THOMAS]
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
> Current branch develop is up to date.
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git push
> Counting objects: 5, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 303 bytes, done.
> Total 3 (delta 1), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
> 1032fa2..f43029d develop -> develop
>
> ---------------------------------
> You get the newest changes
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop
> From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
> * branch develop -> FETCH_HEAD
> First, rewinding head to replay your work on top of it...
> Applying: Added pt_PT
>
> ---------------------------------
> Look, that's the state you're going to have on the remote if you do:
> git merge test_Rebased_Hotfix_Without_Conflic
> git push
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
> * 54072f3 2013-03-21 | Added pt_PT (HEAD,
> test_Rebased_Hotfix_Without_Conflic) [Justin]
> * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master, develop) [Frédéric THOMAS]
>
> ---------------------------------
> But here, if you decide to let the others know the all work you did on this
> branch, we do a merge without fast forward.
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
> test_Rebased_Hotfix_Without_Conflic
> Merge made by the 'recursive' strategy.
> README | 2 +-
> locales/pt_PT.properties | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-)
> create mode 100644 locales/pt_PT.properties
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
> * 5cd6098 2013-03-21 | Merge branch 'test_Rebased_Hotfix_Without_Conflic'
> into develop (HEAD, develop) [Justin]
> |\
> | * 54072f3 2013-03-21 | Added pt_PT (test_Rebased_Hotfix_Without_Conflic)
> [Justin]
> | * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
> THOMAS]
> |/
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
> ---------------------------------
> But actually, because it was a simple commit, you revert your merge to have
> a flat history and push it
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
> HEAD is now at 54072f3 Added pt_PT
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
> * 54072f3 2013-03-21 | Added pt_PT (HEAD,
> test_Rebased_Hotfix_Without_Conflic, develop) [Justin]
> * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git push
> Counting objects: 5, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (4/4), 351 bytes, done.
> Total 4 (delta 0), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
> f43029d..54072f3 develop -> develop
>
> ---------------------------------
> On my machine, I update and I see a clean ordered history
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
> remote: Counting objects: 5, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 4 (delta 0), reused 0 (delta 0)
> Unpacking objects: 100% (4/4), done.
> From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
> f43029d..54072f3 develop -> origin/develop
> First, rewinding head to replay your work on top of it...
> Fast-forwarded develop to 54072f3f207612429d525c6854632b265996bf9e.
>
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
> * 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop) [Justin]
> * f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
"and not add more complexity" is what the last sentence should say.
Justin
RE: [OT] Log history
Posted by Gordon Smith <go...@adobe.com>.
I'm with Justin. I'm extremely skeptical that we should encourage rebasing. Is there any evidence that other Apache Git projects use it to avoid merge commits?
- Gordon
-----Original Message-----
From: Justin Mclean [mailto:justin@classsoftware.com]
Sent: Thursday, March 21, 2013 6:56 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
Thanks for going though that.
> ---------------------------------
> You add locales
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b test_Rebased_Hotfix_Without_Conflic
> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
etc etc
Actually it wasn't quite like that in that as files and directories already existed. It does seem a bit excessive to make a branch just to change a single file and it also assumes I have no other changes and a perfectly clean tree (not the case). As the branch is local and not shared with anyone else do you really need a branch for a simple change to a singe file?
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop
This is the bit I'm confused about why would I use --rebase when all documentation I've read say it dangerous to use and it hard to undo (unlike merge) and it difficult to see what it's going to do (no --dry-run) - I know both of this situations have work arounds (mostly) but they are complex. It seems to me that knowing what about to happen and being able to back out of it if things go wrong is far more important than having a totally "clean" history. It's not like the history produced was incorrect or even confusing.
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff test_Rebased_Hotfix_Without_Conflic
Why is --no-ff required? What would happen if this option wasn't used in this case? And if I didn't make the branch in the first place there would be no need for this merge or the hard reset below right?
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
How do I know I need to do this? Would I need to do this every time?
I really don't want to have to work though obscure git options and issue a dozen git commands just to check in a single fix to a single file. If we have to do that then I think we are using the tools incorrectly or it's the wrong tool for the job. IMO we need to make it as easy or easier than SVN to use and add yet more complexity.
Thanks,
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Guys,
I gonna start a new page, probably on sunday for the git workflow has I
think it should happen for Apache Flex and following then nvie model, I want
to include examples for committers from my git lab, maybe as well, if you
guys are interested, how to create your own git lab.
-Fred
-----Message d'origine-----
From: Erik de Bruin
Sent: Friday, March 22, 2013 11:16 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
I've written the proposed workflow (with commands) to the wiki (with
Fred). Maybe we can base the discussion on that, not on general
theory. In other words, please have a look at the wiki and give
feedback (I'm creating a new thread for that) so we can perfect the
specifics for this project.
Thanks,
EdB
On Fri, Mar 22, 2013 at 11:11 AM, Frédéric THOMAS
<we...@hotmail.com> wrote:
>> Sure for a feature (and especially when multiple people need to work on
>> it) I see the benefit but for a single change to a single file?
>
>
> As I said in the long post, no problem in this case, just, don't forget to
> pull --rebase before pushing.
>
>
>> nothing destructive using pull --rebase as soon as you understand when,
>> where and why to use it.
>
> So why do the Git official docs state this?
> "This is a potentially dangerous mode of operation. It rewrites history,
> which does not bode well when you published that history already. Do not
> use
> this option unless you have read git-rebase(1) carefully."
>
> The published history is never touched until you really want to do it on
> purposed, you can't do it following the workflow I described.
>
>
>> All of the basic tutorials I've seen don't use "git pull --rebase".
>
>
> I can show you a lot recommanding to use it until your know how it works.
> Actually, there's one only situation where you can re-write your own
> merge,
> not the one of the others and I explained how to avoid it.
>
>
>
>> Know something once and for ever: rebasing preserve a good history and is
>> not destructive
>
> What I don't understand is why it's so important to have a "clean" history
> at the expense of making it easy to use.
>
> Once more, there's no risks as soon as you understand how to work with,
> it's
> easy, push your merge as soon you did it.
> Having a readable history allows everybody to understand what happened,
> see
> our history graph, can you tell me what happened, maybe you yes, because
> you
> did the pushes (but not even sure you'll be able to say it in one month)
> but
> someone else ?
>
> Thanks,
> -Fred
>
>
>
> -----Message d'origine----- From: Justin Mclean
> Sent: Friday, March 22, 2013 10:58 AM
>
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> HI,
>
>> The point, in the example I provided was to illustrate how you should
>> work
>> from a branch
>
> Sure for a feature (and especially when multiple people need to work on
> it)
> I see the benefit but for a single change to a single file?
>
>> nothing destructive using pull --rebase as soon as you understand when,
>> where and why to use it.
>
> So why do the Git official docs state this?
> "This is a potentially dangerous mode of operation. It rewrites history,
> which does not bode well when you published that history already. Do not
> use
> this option unless you have read git-rebase(1) carefully."
>
> All of the basic tutorials I've seen don't use "git pull --rebase".
>
>> Know something once and for ever: rebasing preserve a good history and is
>> not destructive
>
> What I don't understand is why it's so important to have a "clean" history
> at the expense of making it easy to use.
>
> Thanks,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
And the one I wrote at the end of the long post as well is a good
illustration of branching/rebasing/resolving conflicts
-Fred
-----Message d'origine-----
From: Erik de Bruin
Sent: Friday, March 22, 2013 11:16 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
I've written the proposed workflow (with commands) to the wiki (with
Fred). Maybe we can base the discussion on that, not on general
theory. In other words, please have a look at the wiki and give
feedback (I'm creating a new thread for that) so we can perfect the
specifics for this project.
Thanks,
EdB
On Fri, Mar 22, 2013 at 11:11 AM, Frédéric THOMAS
<we...@hotmail.com> wrote:
>> Sure for a feature (and especially when multiple people need to work on
>> it) I see the benefit but for a single change to a single file?
>
>
> As I said in the long post, no problem in this case, just, don't forget to
> pull --rebase before pushing.
>
>
>> nothing destructive using pull --rebase as soon as you understand when,
>> where and why to use it.
>
> So why do the Git official docs state this?
> "This is a potentially dangerous mode of operation. It rewrites history,
> which does not bode well when you published that history already. Do not
> use
> this option unless you have read git-rebase(1) carefully."
>
> The published history is never touched until you really want to do it on
> purposed, you can't do it following the workflow I described.
>
>
>> All of the basic tutorials I've seen don't use "git pull --rebase".
>
>
> I can show you a lot recommanding to use it until your know how it works.
> Actually, there's one only situation where you can re-write your own
> merge,
> not the one of the others and I explained how to avoid it.
>
>
>
>> Know something once and for ever: rebasing preserve a good history and is
>> not destructive
>
> What I don't understand is why it's so important to have a "clean" history
> at the expense of making it easy to use.
>
> Once more, there's no risks as soon as you understand how to work with,
> it's
> easy, push your merge as soon you did it.
> Having a readable history allows everybody to understand what happened,
> see
> our history graph, can you tell me what happened, maybe you yes, because
> you
> did the pushes (but not even sure you'll be able to say it in one month)
> but
> someone else ?
>
> Thanks,
> -Fred
>
>
>
> -----Message d'origine----- From: Justin Mclean
> Sent: Friday, March 22, 2013 10:58 AM
>
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> HI,
>
>> The point, in the example I provided was to illustrate how you should
>> work
>> from a branch
>
> Sure for a feature (and especially when multiple people need to work on
> it)
> I see the benefit but for a single change to a single file?
>
>> nothing destructive using pull --rebase as soon as you understand when,
>> where and why to use it.
>
> So why do the Git official docs state this?
> "This is a potentially dangerous mode of operation. It rewrites history,
> which does not bode well when you published that history already. Do not
> use
> this option unless you have read git-rebase(1) carefully."
>
> All of the basic tutorials I've seen don't use "git pull --rebase".
>
>> Know something once and for ever: rebasing preserve a good history and is
>> not destructive
>
> What I don't understand is why it's so important to have a "clean" history
> at the expense of making it easy to use.
>
> Thanks,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I've written the proposed workflow (with commands) to the wiki (with
Fred). Maybe we can base the discussion on that, not on general
theory. In other words, please have a look at the wiki and give
feedback (I'm creating a new thread for that) so we can perfect the
specifics for this project.
Thanks,
EdB
On Fri, Mar 22, 2013 at 11:11 AM, Frédéric THOMAS
<we...@hotmail.com> wrote:
>> Sure for a feature (and especially when multiple people need to work on
>> it) I see the benefit but for a single change to a single file?
>
>
> As I said in the long post, no problem in this case, just, don't forget to
> pull --rebase before pushing.
>
>
>> nothing destructive using pull --rebase as soon as you understand when,
>> where and why to use it.
>
> So why do the Git official docs state this?
> "This is a potentially dangerous mode of operation. It rewrites history,
> which does not bode well when you published that history already. Do not use
> this option unless you have read git-rebase(1) carefully."
>
> The published history is never touched until you really want to do it on
> purposed, you can't do it following the workflow I described.
>
>
>> All of the basic tutorials I've seen don't use "git pull --rebase".
>
>
> I can show you a lot recommanding to use it until your know how it works.
> Actually, there's one only situation where you can re-write your own merge,
> not the one of the others and I explained how to avoid it.
>
>
>
>> Know something once and for ever: rebasing preserve a good history and is
>> not destructive
>
> What I don't understand is why it's so important to have a "clean" history
> at the expense of making it easy to use.
>
> Once more, there's no risks as soon as you understand how to work with, it's
> easy, push your merge as soon you did it.
> Having a readable history allows everybody to understand what happened, see
> our history graph, can you tell me what happened, maybe you yes, because you
> did the pushes (but not even sure you'll be able to say it in one month) but
> someone else ?
>
> Thanks,
> -Fred
>
>
>
> -----Message d'origine----- From: Justin Mclean
> Sent: Friday, March 22, 2013 10:58 AM
>
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> HI,
>
>> The point, in the example I provided was to illustrate how you should work
>> from a branch
>
> Sure for a feature (and especially when multiple people need to work on it)
> I see the benefit but for a single change to a single file?
>
>> nothing destructive using pull --rebase as soon as you understand when,
>> where and why to use it.
>
> So why do the Git official docs state this?
> "This is a potentially dangerous mode of operation. It rewrites history,
> which does not bode well when you published that history already. Do not use
> this option unless you have read git-rebase(1) carefully."
>
> All of the basic tutorials I've seen don't use "git pull --rebase".
>
>> Know something once and for ever: rebasing preserve a good history and is
>> not destructive
>
> What I don't understand is why it's so important to have a "clean" history
> at the expense of making it easy to use.
>
> Thanks,
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
> Sure for a feature (and especially when multiple people need to work on
> it) I see the benefit but for a single change to a single file?
As I said in the long post, no problem in this case, just, don't forget to
pull --rebase before pushing.
> nothing destructive using pull --rebase as soon as you understand when,
> where and why to use it.
So why do the Git official docs state this?
"This is a potentially dangerous mode of operation. It rewrites history,
which does not bode well when you published that history already. Do not use
this option unless you have read git-rebase(1) carefully."
The published history is never touched until you really want to do it on
purposed, you can't do it following the workflow I described.
> All of the basic tutorials I've seen don't use "git pull --rebase".
I can show you a lot recommanding to use it until your know how it works.
Actually, there's one only situation where you can re-write your own merge,
not the one of the others and I explained how to avoid it.
> Know something once and for ever: rebasing preserve a good history and is
> not destructive
What I don't understand is why it's so important to have a "clean" history
at the expense of making it easy to use.
Once more, there's no risks as soon as you understand how to work with, it's
easy, push your merge as soon you did it.
Having a readable history allows everybody to understand what happened, see
our history graph, can you tell me what happened, maybe you yes, because you
did the pushes (but not even sure you'll be able to say it in one month) but
someone else ?
Thanks,
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Friday, March 22, 2013 10:58 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
HI,
> The point, in the example I provided was to illustrate how you should work
> from a branch
Sure for a feature (and especially when multiple people need to work on it)
I see the benefit but for a single change to a single file?
> nothing destructive using pull --rebase as soon as you understand when,
> where and why to use it.
So why do the Git official docs state this?
"This is a potentially dangerous mode of operation. It rewrites history,
which does not bode well when you published that history already. Do not use
this option unless you have read git-rebase(1) carefully."
All of the basic tutorials I've seen don't use "git pull --rebase".
> Know something once and for ever: rebasing preserve a good history and is
> not destructive
What I don't understand is why it's so important to have a "clean" history
at the expense of making it easy to use.
Thanks,
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
HI,
> The point, in the example I provided was to illustrate how you should work from a branch
Sure for a feature (and especially when multiple people need to work on it) I see the benefit but for a single change to a single file?
> nothing destructive using pull --rebase as soon as you understand when, where and why to use it.
So why do the Git official docs state this?
"This is a potentially dangerous mode of operation. It rewrites history, which does not bode well when you published that history already. Do not use this option unless you have read git-rebase(1) carefully."
All of the basic tutorials I've seen don't use "git pull --rebase".
> Know something once and for ever: rebasing preserve a good history and is not destructive
What I don't understand is why it's so important to have a "clean" history at the expense of making it easy to use.
Thanks,
Justin
Re: [OT] Log history
Posted by Michael Schmalle <ap...@teotigraphix.com>.
I will just say something.
Quoting Om <bi...@gmail.com>:
> Folks,
>
> I understand the frustration that folks are not contributing as much as
> expected, but lets not make that a big deal. People have other
> commitments, side projects and and jobs to take care of. It might just be
> unfortunate timing that they got busy with other things when the move to
> Git started. Remember, this is was not a planned move - it just happened
> out of the blue.
>
> I am glad that a few of us at least were able to take time out and work on
> this git migration. I am fully aware that there are going to be times that
> we will be busy with our lives when a bunch of other folks take up slack.
> And I wouldnt like it when they diss me (or others) when they are doing
> it.
Please don't insinuate that I have no clue where the line of respect is.
> And I request that we take these kind of discussions on private@flex.a.o to
> make sure that we don't say anything negative about individuals.
I don't think what we were talking about has anything to do with a
need for private conversation.
> I am worried that we are permanently driving folks away with this kind of
> talk. Public shaming does no good to anyone.
Again, I really don't know where you are coming from, publicly shaming
is a bit extreme here.
> Thanks,
> Om
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [OT] Log history
Posted by Om <bi...@gmail.com>.
Folks,
I understand the frustration that folks are not contributing as much as
expected, but lets not make that a big deal. People have other
commitments, side projects and and jobs to take care of. It might just be
unfortunate timing that they got busy with other things when the move to
Git started. Remember, this is was not a planned move - it just happened
out of the blue.
I am glad that a few of us at least were able to take time out and work on
this git migration. I am fully aware that there are going to be times that
we will be busy with our lives when a bunch of other folks take up slack.
And I wouldnt like it when they diss me (or others) when they are doing
it.
And I request that we take these kind of discussions on private@flex.a.o to
make sure that we don't say anything negative about individuals.
I am worried that we are permanently driving folks away with this kind of
talk. Public shaming does no good to anyone.
Thanks,
Om
Re: [OT] Log history
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Erik,
Hopefully those that read what I said, know what I am talking about.
It sounded like there would be "shepherding" during this period and
all I was saying was Om, etc basically did all this off the cuff.
Kudos to them, they know we all appreciate it.
Mike
Quoting Erik de Bruin <er...@ixsoftware.nl>:
> Well, while I generally agree with your sentiment, we wouldn't do
> justice to Om. He's gone above and beyond with Infra and I think his
> calm and political sense have made this possible. Also, I think Fred,
> Dasa and Jose did their fair share making sense of the inner workings
> of git in relation to this project.
>
> That's not to say that I'm very disappointed with some of the very
> vocal voters (PMC and contributors) who have been entirely absent
> during the implementation:
>
> http://markmail.org/message/ajlskznzec4wqda2
>
> Merit works both ways, IMHO.
>
> EdB
>
>
>
> On Fri, Mar 22, 2013 at 4:55 PM, Michael Schmalle
> <ap...@teotigraphix.com> wrote:
>> Well...
>>
>> Being down right blunt, this model was voted on by PMC members that don't
>> even contribute to the project anymore (if ever).
>>
>> All the people that voted for GIT int he first place have hardly show there
>> face once, now that it has happened.
>>
>> I think this calls for an ability to revise what was voted on since us
>> commiters (PMC members) that are actually doing work with this stuff right
>> now have problems with it.
>>
>> Gordon, I agree, for Falcon repo development that model is huge over kill.
>>
>> The vote happened when I was away for 8 months.
>>
>> Mike
>>
>>
>>
>> Quoting Gordon Smith <go...@adobe.com>:
>>
>>> 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
>>>
>>> Sent from my iPad
>>>
>>> On Mar 22, 2013, at 3:37 AM, "Justin Mclean" <ju...@classsoftware.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> Also anyone want to explain why this doesn't mention pull -rebase
>>>> anywhere?
>>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>>
>>>> Also on the bug fix issue to branch or not branch (from the author of
>>>> gitflow):
>>>> "A rule of thumb would be that if you need more than one commit for a
>>>> change, you should do it on a feature branch, otherwise commit it directly
>>>> on develop."
>>>>
>>>> https://github.com/nvie/gitflow/issues/24
>>>>
>>>> Thanks
>>>> Justin
>>>>
>>>
>>
>> --
>> Michael Schmalle - Teoti Graphix, LLC
>> http://www.teotigraphix.com
>> http://blog.teotigraphix.com
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [OT] Log history
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Well, while I generally agree with your sentiment, we wouldn't do
justice to Om. He's gone above and beyond with Infra and I think his
calm and political sense have made this possible. Also, I think Fred,
Dasa and Jose did their fair share making sense of the inner workings
of git in relation to this project.
That's not to say that I'm very disappointed with some of the very
vocal voters (PMC and contributors) who have been entirely absent
during the implementation:
http://markmail.org/message/ajlskznzec4wqda2
Merit works both ways, IMHO.
EdB
On Fri, Mar 22, 2013 at 4:55 PM, Michael Schmalle
<ap...@teotigraphix.com> wrote:
> Well...
>
> Being down right blunt, this model was voted on by PMC members that don't
> even contribute to the project anymore (if ever).
>
> All the people that voted for GIT int he first place have hardly show there
> face once, now that it has happened.
>
> I think this calls for an ability to revise what was voted on since us
> commiters (PMC members) that are actually doing work with this stuff right
> now have problems with it.
>
> Gordon, I agree, for Falcon repo development that model is huge over kill.
>
> The vote happened when I was away for 8 months.
>
> Mike
>
>
>
> Quoting Gordon Smith <go...@adobe.com>:
>
>> 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
>>
>> Sent from my iPad
>>
>> On Mar 22, 2013, at 3:37 AM, "Justin Mclean" <ju...@classsoftware.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Also anyone want to explain why this doesn't mention pull -rebase
>>> anywhere?
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>
>>> Also on the bug fix issue to branch or not branch (from the author of
>>> gitflow):
>>> "A rule of thumb would be that if you need more than one commit for a
>>> change, you should do it on a feature branch, otherwise commit it directly
>>> on develop."
>>>
>>> https://github.com/nvie/gitflow/issues/24
>>>
>>> Thanks
>>> Justin
>>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Gordon Smith <go...@adobe.com>.
Amen. There are so few people working in Falcon that I haven't had a merge conflict since I started.
Sent from my iPad
On Mar 22, 2013, at 8:56 AM, "Michael Schmalle" <ap...@teotigraphix.com> wrote:
> Well...
>
> Being down right blunt, this model was voted on by PMC members that
> don't even contribute to the project anymore (if ever).
>
> All the people that voted for GIT int he first place have hardly show
> there face once, now that it has happened.
>
> I think this calls for an ability to revise what was voted on since us
> commiters (PMC members) that are actually doing work with this stuff
> right now have problems with it.
>
> Gordon, I agree, for Falcon repo development that model is huge over kill.
>
> The vote happened when I was away for 8 months.
>
> Mike
>
>
> Quoting Gordon Smith <go...@adobe.com>:
>
>> 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
>>
>> Sent from my iPad
>>
>> On Mar 22, 2013, at 3:37 AM, "Justin Mclean"
>> <ju...@classsoftware.com> wrote:
>>
>>> Hi,
>>>
>>> Also anyone want to explain why this doesn't mention pull -rebase anywhere?
>>> http://nvie.com/posts/a-successful-git-branching-model/
>>>
>>> Also on the bug fix issue to branch or not branch (from the author
>>> of gitflow):
>>> "A rule of thumb would be that if you need more than one commit for
>>> a change, you should do it on a feature branch, otherwise commit it
>>> directly on develop."
>>>
>>> https://github.com/nvie/gitflow/issues/24
>>>
>>> Thanks
>>> Justin
>>>
>>
>
> --
> Michael Schmalle - Teoti Graphix, LLC
> http://www.teotigraphix.com
> http://blog.teotigraphix.com
>
Re: [OT] Log history
Posted by Michael Schmalle <ap...@teotigraphix.com>.
Well...
Being down right blunt, this model was voted on by PMC members that
don't even contribute to the project anymore (if ever).
All the people that voted for GIT int he first place have hardly show
there face once, now that it has happened.
I think this calls for an ability to revise what was voted on since us
commiters (PMC members) that are actually doing work with this stuff
right now have problems with it.
Gordon, I agree, for Falcon repo development that model is huge over kill.
The vote happened when I was away for 8 months.
Mike
Quoting Gordon Smith <go...@adobe.com>:
> 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
>
> Sent from my iPad
>
> On Mar 22, 2013, at 3:37 AM, "Justin Mclean"
> <ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>> Also anyone want to explain why this doesn't mention pull -rebase anywhere?
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Also on the bug fix issue to branch or not branch (from the author
>> of gitflow):
>> "A rule of thumb would be that if you need more than one commit for
>> a change, you should do it on a feature branch, otherwise commit it
>> directly on develop."
>>
>> https://github.com/nvie/gitflow/issues/24
>>
>> Thanks
>> Justin
>>
>
--
Michael Schmalle - Teoti Graphix, LLC
http://www.teotigraphix.com
http://blog.teotigraphix.com
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
That sounds like all the good way to work with branches to me.
-Fred
-----Message d'origine-----
From: Michael A. Labriola
Sent: Saturday, March 23, 2013 10:05 AM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
RE: [OT] Log history
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>It kind of bugs me that there are multiple ways to do things in Git (stash or don't stash, add or direct commit) and it represents a vastly different way of thinking than SVN, VSS or Perforce, but so far, I'm liking it.
Yes although in this case it's because there are multiple tools. They aren't all intended to do the same thing, however, in a pinch, you can pound in a small nail using a screw driver. That's sort of the situation here.
Mike
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
On 3/23/13 10:07 AM, "Michael A. Labriola" <la...@digitalprimates.net>
wrote:
>> 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?
>
> Another quick aside, I understand the value of keeping this all in email and
> searchable too, but if we wanted to, I wouldn't mind setting up a connect
> session or similar at some point where we could go through examples against
> the actual SDK in real time, show common tasks, what the git status looked
> like and discuss procedure. We could always record it for other to watch too.
> Its just a thought, but I am certainly open to answering each one here.
For me, I don't need a video (even though you are always entertaining). I'm
actually at the point where I think I have a enough knowledge to be
successful and am mostly refining my understanding.
It kind of bugs me that there are multiple ways to do things in Git (stash
or don't stash, add or direct commit) and it represents a vastly different
way of thinking than SVN, VSS or Perforce, but so far, I'm liking it.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
RE: [OT] Log history
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>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?
Another quick aside, I understand the value of keeping this all in email and searchable too, but if we wanted to, I wouldn't mind setting up a connect session or similar at some point where we could go through examples against the actual SDK in real time, show common tasks, what the git status looked like and discuss procedure. We could always record it for other to watch too. Its just a thought, but I am certainly open to answering each one here.
Mike
RE: [OT] Log history
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
>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?
Alex,
I will do my best to keep monitoring and answering question from my experience as they come up.
First, as far as changing a README, nope. I would likely just pull, change it (maybe quickly re-pull my from the repo to make sure no one else screwed with it while I was working) and push the change back up. I am not a purist on any of these things, my like of git is just because it saves me time.
Maybe I can go back through my narration and add commands, but let me answer quickly with the time I have now and I can document as soon as possible. I am doing this from memory so stick with me and I will try to make typos
--
So, for now, let's hit your questions. I prefer not to use stash. Stash is a temporary local storage and its sort of an escape hatch in my opinion. I usually only use it when I get into the weeds. For example, I realized I was making changes in the wrong branch. In that case, I would stash the changes, because I don't want to commit them. Switch branches, then apply the stash. That is really the only time I use it.
In every other case, I would commit my changes to my local branch. That is always the case for me if the work I just did was useful. Once everything in your local workspace is committed, you are free to switch branches.
Let's take a couple of scenarios.
Let's say I branched from develop and made SomePieceRefactor. I work in it for a bit, and then you tell me there is something you want me to take a look at. I now have a choice, I can add those changes to the work I have been doing already or not.
So, if I want to check your changes with mine, I would immediately branch:
git checkout -b RefactorPlusAlex
So, now I have a branch called RefactorPlusAlex. Why make a branch now? Because if your stuff doesn't work (or I don't want to keep using it), I want to resume my progress right away from my branch and not have to pick out your files one by one, etc..
Now, to be able to pull your changes directly, I need to know where your Repo is. This is a one time thing, but I need to setup a remote for you... it would look something like this:
git remote add alex urlToYourRepo
After this command, I can refer to your setup as alex in my commands going forward.
I can choose to download all of your code or just the branch I am interested in from your repo:
git fetch alex[/branchname]
This pulls down the code from your branch.
Now I say git merge alex/branchname
Which merges your code into my branch. I can now build/test/do whatever. When I am done, I can revert any changes (if I made them) and then just say:
git checkout SomePieceRefactor
which resets everything to exactly as it was before I brought down your changes. Had I instead wanted to integrate them but NOT with my changes:
I would first commit my changes, then:
git checkout develop
//switch me to develop
git checkout -b DevPlusAlex
//create a new branch from develop to try your changes
And now do the same as above... so, I just had to choose where I wanted to start the branch from, before I then integrated your changes. I know there are more questions, and I will try to be extra attentive anytime I am not on a plane for the next few days. Ask question on this and I should be able to respond again in an hour or so.
Mike
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
ohoh, just found that if you want the thing much more clearer than I can
explain them, it's even illustrated:
http://www.gitguys.com/topics/whats-the-deal-with-the-git-index/
-Fred
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Saturday, March 23, 2013 4:53 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
no, stash doesn't do an add, it saves the stage area and with the -u flag,
the working area too.
-Fred
-----Message d'origine-----
From: Alex Harui
Sent: Saturday, March 23, 2013 4:40 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
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" <we...@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" <we...@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
>> <we...@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" <la...@digitalprimates.net>
>>> wrote:
>>>
>>>
>>>> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
no, stash doesn't do an add, it saves the stage area and with the -u flag,
the working area too.
-Fred
-----Message d'origine-----
From: Alex Harui
Sent: Saturday, March 23, 2013 4:40 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
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" <we...@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" <we...@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
>> <we...@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" <la...@digitalprimates.net>
>>> wrote:
>>>
>>>
>>>> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
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" <we...@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" <we...@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
>> <we...@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" <la...@digitalprimates.net>
>>> wrote:
>>>
>>>
>>>> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
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" <we...@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
> <we...@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" <la...@digitalprimates.net>
>> wrote:
>>
>>
>>> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
Is it different if you have stuff already staged and/or committed?
On 3/23/13 7:52 AM, "Frédéric THOMAS" <we...@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
> <we...@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" <la...@digitalprimates.net>
>> wrote:
>>
>>
>>> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
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
<we...@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" <la...@digitalprimates.net>
> wrote:
>
>
>> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
>
>
Re: [OT] Log history
Posted by Mark Kessler <ke...@gmail.com>.
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
<we...@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" <la...@digitalprimates.net>
> wrote:
>
>
>> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
>
>
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
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" <la...@digitalprimates.net>
wrote:
>
> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
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" <la...@digitalprimates.net>
wrote:
>
> On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
RE: [OT] Log history
Posted by "Michael A. Labriola" <la...@digitalprimates.net>.
On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
Re: [OT] Log history
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Gordon,
The way I see it, if you work on your local develop branch, it's just
like it's a feature branch in Gitflow :-)
On you end, you're the boss of your workflow. As long as we agree on
the workflow on the remote site (push to develop, cherry-pick to
create release on the master branch), I think we're all good.
EdB
On Fri, Mar 22, 2013 at 4:48 PM, Gordon Smith <go...@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
>
> Sent from my iPad
>
> On Mar 22, 2013, at 3:37 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>> Also anyone want to explain why this doesn't mention pull -rebase anywhere?
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Also on the bug fix issue to branch or not branch (from the author of gitflow):
>> "A rule of thumb would be that if you need more than one commit for a change, you should do it on a feature branch, otherwise commit it directly on develop."
>>
>> https://github.com/nvie/gitflow/issues/24
>>
>> Thanks
>> Justin
>>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
AFAICT, the git branching model does not dictate that you must use a branch
for all changes to develop, it just talks about a strategy for how to use
feature branches if you choose to use them.
I'm a git newbie, but really, I am looking forward to having the option to
create a cheap and quick branch to do multi-commit changes to the code.
Quite often I get disrupted from some work I'm doing and when I come back I
find myself looking at the diffs against the SVN repo and trying to remember
why I did something. With a local branch, I can "commit" with a record of
what I did and have local history of what I did to refer to when I come
back. Sounds like a good thing to me, But there is no requirement to make
a branch unless you need that sort of thing.
Regarding the rebase option. I spent last evening reading all of the
articles Justin and other pointed us to. It seems pretty straight forward
to me: You should use rebase when refreshing your local branch against the
remote branch it came from before pushing. You should not rebase when
merging between two remote branches (and therefore, I am not setting the
config to default to rebase because I will be merging remote branches when
doing releases). And for other configurations, it is best to understand
what it really does, and if you decide to use it and it fails, abort it and
use merge.
On 3/22/13 8:48 AM, "Gordon Smith" <go...@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
>
> Sent from my iPad
>
> On Mar 22, 2013, at 3:37 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>
>> Hi,
>>
>> Also anyone want to explain why this doesn't mention pull -rebase anywhere?
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Also on the bug fix issue to branch or not branch (from the author of
>> gitflow):
>> "A rule of thumb would be that if you need more than one commit for a change,
>> you should do it on a feature branch, otherwise commit it directly on
>> develop."
>>
>> https://github.com/nvie/gitflow/issues/24
>>
>> Thanks
>> Justin
>>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Gordon Smith <go...@adobe.com>.
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
Sent from my iPad
On Mar 22, 2013, at 3:37 AM, "Justin Mclean" <ju...@classsoftware.com> wrote:
> Hi,
>
> Also anyone want to explain why this doesn't mention pull -rebase anywhere?
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Also on the bug fix issue to branch or not branch (from the author of gitflow):
> "A rule of thumb would be that if you need more than one commit for a change, you should do it on a feature branch, otherwise commit it directly on develop."
>
> https://github.com/nvie/gitflow/issues/24
>
> Thanks
> Justin
>
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
> Also anyone want to explain why this doesn't mention pull -rebase
> anywhere?
http://nvie.com/posts/a-successful-git-branching-model/
Simply because they don't talk about "when I'm working on" but "Creating a
feature branch" and "Incorporating a finished feature on develop", so, they
talk about the begining and the end only.
> "A rule of thumb would be that if you need more than one commit for a
> change, you should do it on a feature branch, otherwise commit it directly
> on develop."
Agree with that until it doesn't require tests
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Friday, March 22, 2013 11:36 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
Also anyone want to explain why this doesn't mention pull -rebase anywhere?
http://nvie.com/posts/a-successful-git-branching-model/
Also on the bug fix issue to branch or not branch (from the author of
gitflow):
"A rule of thumb would be that if you need more than one commit for a
change, you should do it on a feature branch, otherwise commit it directly
on develop."
https://github.com/nvie/gitflow/issues/24
Thanks
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Justin,
Just found [1], this guy explains it better than me, except my workaround is
better than the one is got, see my example on the wiki.
-Fred
[1] http://notes.envato.com/developers/rebasing-merge-commits-in-git/
-----Message d'origine-----
From: Justin Mclean
Sent: Friday, March 22, 2013 11:36 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
Also anyone want to explain why this doesn't mention pull -rebase anywhere?
http://nvie.com/posts/a-successful-git-branching-model/
Also on the bug fix issue to branch or not branch (from the author of
gitflow):
"A rule of thumb would be that if you need more than one commit for a
change, you should do it on a feature branch, otherwise commit it directly
on develop."
https://github.com/nvie/gitflow/issues/24
Thanks
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Also anyone want to explain why this doesn't mention pull -rebase anywhere?
http://nvie.com/posts/a-successful-git-branching-model/
Also on the bug fix issue to branch or not branch (from the author of gitflow):
"A rule of thumb would be that if you need more than one commit for a change, you should do it on a feature branch, otherwise commit it directly on develop."
https://github.com/nvie/gitflow/issues/24
Thanks
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Bugfixes are treated as features, hotfixes doesn't apply to us as we don't
release onDemand (for a client for example that would like to have an
immediate fix), at least, I see it like that.
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Friday, March 22, 2013 11:10 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
> As the Gitflow model this project agreed to follow says to always (and
> only) work on feature branches
For features yes but not for bug fixes as far as I'm aware. Notice the
yellow dots on the develop branch with no arrows from other branches.
Bugfixes are not the same as hotfixes as hotfixes are applied to the release
branch not the develop branch.
http://nvie.com/posts/a-successful-git-branching-model/
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Well, if I modify the README, I don't want to create branch for, I do it
directly on the develop branch, even though I guess it would be a good
train/habit for the branching model, it is good as well to not be heavy in
the workflow when it's safe to do it.
-Fred
-----Message d'origine-----
From: Erik de Bruin
Sent: Friday, March 22, 2013 11:29 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
What harm (other than a little more work) would it do to NOT have that
exception in that documentation? We're trying to keep the instructions
simple and generic...
EdB
On Fri, Mar 22, 2013 at 11:26 AM, Frédéric THOMAS
<we...@hotmail.com> wrote:
> I totaly agreed with that, the only exception is a single line of
> code/text
> which doesn't need tests.
>
> -Fred
>
> -----Message d'origine----- From: Erik de Bruin
> Sent: Friday, March 22, 2013 11:23 AM
>
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> I don't agree. I think all work should be done on a 'feature' branch -
> there is no inherent difference between changing code to create a new
> feature and changing code to fix a bug. Also, more then one person
> might want cooperate on fixing a bug, in which case a 'feature' branch
> is also called for. In order to keep things simple, I suggest we
> always work on 'feature' branches, so we can avoid introducing more
> rules that determine when to use one and when not to. KISS :-)
>
> Also: the Gitflow article mentions the 'develop' branch is actually
> the 'integration' branch, which I also read as: don't work on it
> directly.
>
> EdB
>
>
> On Fri, Mar 22, 2013 at 11:10 AM, Justin Mclean
> <ju...@classsoftware.com> wrote:
>>
>> Hi,
>>
>>> As the Gitflow model this project agreed to follow says to always (and
>>> only) work on feature branches
>>
>> For features yes but not for bug fixes as far as I'm aware. Notice the
>> yellow dots on the develop branch with no arrows from other branches.
>> Bugfixes are not the same as hotfixes as hotfixes are applied to the
>> release
>> branch not the develop branch.
>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Justin
>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Erik de Bruin <er...@ixsoftware.nl>.
What harm (other than a little more work) would it do to NOT have that
exception in that documentation? We're trying to keep the instructions
simple and generic...
EdB
On Fri, Mar 22, 2013 at 11:26 AM, Frédéric THOMAS
<we...@hotmail.com> wrote:
> I totaly agreed with that, the only exception is a single line of code/text
> which doesn't need tests.
>
> -Fred
>
> -----Message d'origine----- From: Erik de Bruin
> Sent: Friday, March 22, 2013 11:23 AM
>
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> I don't agree. I think all work should be done on a 'feature' branch -
> there is no inherent difference between changing code to create a new
> feature and changing code to fix a bug. Also, more then one person
> might want cooperate on fixing a bug, in which case a 'feature' branch
> is also called for. In order to keep things simple, I suggest we
> always work on 'feature' branches, so we can avoid introducing more
> rules that determine when to use one and when not to. KISS :-)
>
> Also: the Gitflow article mentions the 'develop' branch is actually
> the 'integration' branch, which I also read as: don't work on it
> directly.
>
> EdB
>
>
> On Fri, Mar 22, 2013 at 11:10 AM, Justin Mclean
> <ju...@classsoftware.com> wrote:
>>
>> Hi,
>>
>>> As the Gitflow model this project agreed to follow says to always (and
>>> only) work on feature branches
>>
>> For features yes but not for bug fixes as far as I'm aware. Notice the
>> yellow dots on the develop branch with no arrows from other branches.
>> Bugfixes are not the same as hotfixes as hotfixes are applied to the release
>> branch not the develop branch.
>>
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> Justin
>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
I totaly agreed with that, the only exception is a single line of code/text
which doesn't need tests.
-Fred
-----Message d'origine-----
From: Erik de Bruin
Sent: Friday, March 22, 2013 11:23 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
I don't agree. I think all work should be done on a 'feature' branch -
there is no inherent difference between changing code to create a new
feature and changing code to fix a bug. Also, more then one person
might want cooperate on fixing a bug, in which case a 'feature' branch
is also called for. In order to keep things simple, I suggest we
always work on 'feature' branches, so we can avoid introducing more
rules that determine when to use one and when not to. KISS :-)
Also: the Gitflow article mentions the 'develop' branch is actually
the 'integration' branch, which I also read as: don't work on it
directly.
EdB
On Fri, Mar 22, 2013 at 11:10 AM, Justin Mclean
<ju...@classsoftware.com> wrote:
> Hi,
>
>> As the Gitflow model this project agreed to follow says to always (and
>> only) work on feature branches
> For features yes but not for bug fixes as far as I'm aware. Notice the
> yellow dots on the develop branch with no arrows from other branches.
> Bugfixes are not the same as hotfixes as hotfixes are applied to the
> release branch not the develop branch.
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Erik de Bruin <er...@ixsoftware.nl>.
I don't agree. I think all work should be done on a 'feature' branch -
there is no inherent difference between changing code to create a new
feature and changing code to fix a bug. Also, more then one person
might want cooperate on fixing a bug, in which case a 'feature' branch
is also called for. In order to keep things simple, I suggest we
always work on 'feature' branches, so we can avoid introducing more
rules that determine when to use one and when not to. KISS :-)
Also: the Gitflow article mentions the 'develop' branch is actually
the 'integration' branch, which I also read as: don't work on it
directly.
EdB
On Fri, Mar 22, 2013 at 11:10 AM, Justin Mclean
<ju...@classsoftware.com> wrote:
> Hi,
>
>> As the Gitflow model this project agreed to follow says to always (and
>> only) work on feature branches
> For features yes but not for bug fixes as far as I'm aware. Notice the yellow dots on the develop branch with no arrows from other branches. Bugfixes are not the same as hotfixes as hotfixes are applied to the release branch not the develop branch.
>
> http://nvie.com/posts/a-successful-git-branching-model/
>
> Justin
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> As the Gitflow model this project agreed to follow says to always (and
> only) work on feature branches
For features yes but not for bug fixes as far as I'm aware. Notice the yellow dots on the develop branch with no arrows from other branches. Bugfixes are not the same as hotfixes as hotfixes are applied to the release branch not the develop branch.
http://nvie.com/posts/a-successful-git-branching-model/
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
> if you work locally in (feature) branches, use plain 'git pull'
I guess they say that to preserve you from destroying your own merge in case
you didn't push it yet, it's enought to push it to not be in trouble.
-Fred
-----Message d'origine-----
From: Erik de Bruin
Sent: Friday, March 22, 2013 11:07 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Wait... did I get it the wrong way around?
I made a note when reading through the list earlier, but I can't find
the source anymore:
"if you always work on the local develop branch (instead of a (local)
feature branch), use 'git pull \--rebase' (automate via: 'git config
\--global branch.autosetuprebase always'); if you work locally in
(feature) branches, use plain 'git pull'"
This would mean that when following Gitflow (always work on feature
branches), we'd never use --rebase...
Thoroughly confused,
EdB
On Fri, Mar 22, 2013 at 10:58 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Fred,
>
> As the Gitflow model this project agreed to follow says to always (and
> only) work on feature branches, we will never work directly on the
> (local) develop branch... Does this mean that the only case where
> 'rebase' might cause an irreversible problem doesn't exist for us? I
> think it does, but stating this explicitly here and on the wiki will
> take away much of the trouble people seem to be having with the
> suggested workflow.
>
> EdB
>
>
>
> On Fri, Mar 22, 2013 at 10:48 AM, Frédéric THOMAS
> <we...@hotmail.com> wrote:
>>> Rebasing is the operation to get the others work rewriting YOUR commits
>>> on
>>> top of them, it means you will never rewrite their history.
>>
>>
>> That deserves a better explanation, actually, visually, it doesn't look
>> like
>> to be rewritten but it is, and in the natural historical order.
>> Note, everything already pushed will be the exact same as it is on the
>> remote repo and your work will be re-writen on top, so the only risks is
>> if
>> YOU have an unpushed merge, in this case YOUR merge will be flaten but if
>> you follow the guideline I explained in the previous post, it will never
>> happen.
>>
>> Thanks,
>> -Fred
>>
>> -----Message d'origine----- From: Frédéric THOMAS
>> Sent: Friday, March 22, 2013 10:12 AM
>>
>> To: dev@flex.apache.org
>> Subject: Re: [OT] Log history
>>
>> Hi,
>>
>> I'm happy you gone into this and less because I thought you already
>> understood why and when it is better and cleaner while it is safe to use
>> rebasing instead of merging but no problem, I'm going to try to explain
>> it
>> again later.
>>
>>
>>
>> 1- Branching:
>>
>> The point, in the example I provided was to illustrate how you should
>> work
>> from a branch as branching and merging are cheap and are considered as a
>> standard developement workflow on Git, even if you work only on local
>> branches, the reason behind that is that you might discover another bug,
>> nothing relative to the one you're working on (but that impact the same
>> file(s)) and this new bug has a higher priority and then has to be fixed
>> now, making you stoping the dev of your current bug.
>> It's then better to fix it on another branch, doing do, it will be
>> availlable for the others as well as for you if you rebase your branch on
>> it
>> (again, I will tell you later why it is safe to do so at this point).
>> If you have been working on the develop branch directly or on the branch
>> dedicated to the bug you was working on before, it would have not been
>> clear
>> later in the paralelle history line of your bugfix why there's something
>> not
>> relative to it, I made an example of this you can look at [1], as you
>> will
>> see, there's nothing destructive using pull --rebase as soon as you
>> understand when, where and why to use it.
>>
>> I hope with the last paragraph, I made clearer why working on a
>> feature/bugfix branch is better than on the develop branch.
>> Indeed, if you work with someone else, it makes the thing more obvious.
>>
>> Note: If you apply a quick patch or the dev is only one line of code to
>> change and there are no tests to do, etc..., in this case, it's ok to do
>> it
>> directly on the develop branch, taking the precaution of rebasing before
>> committing however.
>>
>>
>>
>>
>> 2- Rebasing, merging, what, when, where and why :
>>
>> Know something once and for ever: rebasing preserve a good history and is
>> not destructive until you didn't merge the branch you are working on and
>> didn't pushed it yet.
>> (and for the latter, you can always avoid it as soon as you follow the
>> good
>> practices, see the conclusion).
>>
>> Note, I explain with my words and my poor English :P
>>
>> Let's start:
>>
>> A- Rebasing:
>>
>> a- What is rebasing:
>>
>> Rebasing is the operation to get the others work rewriting YOUR commits
>> on
>> top of them, it means you will never rewrite their history.
>>
>> b- When rebasing:
>>
>> Each time you know or you thing the branch you're based on changed or
>> even
>> only when there is a significant amount of time you didn't do it.
>>
>> c- Where and from where to rebase:
>>
>> From a branch: it means everywhere.
>> The From Where is depending if you are working on a local branch or a
>> tracked branch.
>>
>> From a local branch, you will like to rebase onto the branch your branch
>> is
>> based from.
>> From a tracked branch, same as before plus the same remote branch to
>> track
>> what your mates did.
>>
>> d- Finaly, WHY it works and it is not descrutive unless you don't follow
>> the
>> good practice i'm explaining in this doc :
>>
>> Because until you didn't merge and not pushed, there are no cases where
>> rebase will not preserve yours and the others history, it will put your
>> work
>> on top of the others, if you/they did a merge and pushed it, this merge
>> still will be preserved.
>>
>>
>>
>> B- Merging:
>>
>> a- What is merging:
>>
>> Merging is the operation to of joining 2 or more developement lines,
>> basicly, this operation will write your commits ahead of the current
>> HEAD,
>> you can use the --no-ff flag to indicate you want an extra commit, the
>> merge
>> commit, which will make your work easily reversed and will identify
>> clearly
>> this work on the remote branch it will be pushed.
>>
>> b- When merging:
>>
>> Just before pushing, like that, you are preversed from the mad reads I
>> see
>> on internet talking about the rebase risks.
>>
>> c- Where merging:
>>
>> From the branch you want your feature/bugfix branch be merge.
>>
>> d- Why merging :
>>
>> I mean, the anwser is in the What.
>>
>>
>> C- Conclusion:
>>
>> Reabase all the time, until you don't have a pending merge that is not
>> pushed.
>> But if you follow my guideline relative to the When merging, you should
>> not
>> encounter this situation.
>>
>> I hope those explanations anwser all of your questions, except maybe this
>> one:
>>
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
>>
>>
>> How do I know I need to do this? Would I need to do this every time?
>> I really don't want to have to work though obscure git options and issue
>> a
>> dozen git commands just to check in a single fix to a single file. If we
>> have to do that then I think we are using the tools incorrectly or it's
>> the
>> wrong tool for the job. IMO we need to make it as easy or easier than SVN
>> to
>> use and add yet more complexity.
>>
>> In the context of the demo I did, it was to revert the timeline just
>> before
>> the merge operation which did a no fast forward merge with the --no-ff
>> flag,
>> causing the creation of a merge commit, I wanted to show you how to
>> remove
>> it in case you decided you wanted a flat history at the end.
>>
>> Thanks,
>> -Fred
>>
>> [1]
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git checkout -b bug2fix1
>> Switched to a new branch 'bug2fix1'
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ ls bug2fixDir/
>> bug2FixFile1 bug2FixFile2
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the 1rst line
>> this is the 2nd line
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ echo Bug2fix1 should fix the line1 writing first instead of 1rst > null
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the first line
>> this is the 2nd line
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git commit -m "bug2fix1: Fixed bub2fixFile1" bug2fixDir/bug2FixFile1
>> [bug2fix1 51af745] bug2fix1: Fixed bub2fixFile1
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ echo As you can see, there is the second line to fix as well but not
>> plan
>> for this bug, so I open an other jira and f
>> ix it > nul
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git checkout develop
>> Switched to branch 'develop'
>> Your branch is ahead of 'origin/develop' by 2 commits.
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git checkout -b bug2fix2
>> Switched to a new branch 'bug2fix2'
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the 1rst line
>> this is the 2nd line
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ echo Fix the line 2 > nul
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the 1rst line
>> this is the second line
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ git commit -m "bug2fix2: Fixed bug2fixFile1" bug2fixDir/bug2FixFile1
>> [bug2fix2 46f7fe0] bug2fix2: Fixed bug2fixFile1
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ git checkout develop
>> Switched to branch 'develop'
>> Your branch is ahead of 'origin/develop' by 2 commits.
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git merge --no-ff bug2fix2
>> Merge made by the 'recursive' strategy.
>> bug2fixDir/bug2FixFile1 | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git branch -d bug2fix2
>> Deleted branch bug2fix2 (was 46f7fe0).
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git push
>> Counting objects: 14, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (10/10), done.
>> Writing objects: 100% (13/13), 1.16 KiB, done.
>> Total 13 (delta 3), reused 0 (delta 0)
>> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
>> 3cbafc4..3830e37 develop -> develop
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git checkout bug2fix1
>> Switched to branch 'bug2fix1'
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git pull --rebase origin develop
>> From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
>> * branch develop -> FETCH_HEAD
>> First, rewinding head to replay your work on top of it...
>> Applying: bug2fix1: Fixed bub2fixFile1
>> Using index info to reconstruct a base tree...
>> M bug2fixDir/bug2FixFile1
>> Falling back to patching base and 3-way merge...
>> Auto-merging bug2fixDir/bug2FixFile1
>> CONFLICT (content): Merge conflict in bug2fixDir/bug2FixFile1
>> Failed to merge in the changes.
>> Patch failed at 0001 bug2fix1: Fixed bub2fixFile1
>> The copy of the patch that failed is found in:
>> u:/gitLab/work/asf/flex/testWorkFlow/justin/.git/rebase-apply/patch
>>
>> When you have resolved this problem, run "git rebase --continue".
>> If you prefer to skip this patch, run "git rebase --skip" instead.
>> To check out the original branch and stop rebasing, run "git
>> rebase --abort".
>>
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
>> ((3830e37...)|REBASE)
>> $ git mergetool bug2fixDir/bug2FixFile1
>> Merging:
>> bug2fixDir/bug2FixFile1
>>
>> Normal merge conflict for 'bug2fixDir/bug2FixFile1':
>> {local}: modified file
>> {remote}: modified file
>> Hit return to start merge resolution tool (p4merge):
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
>> ((3830e37...)|REBASE)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the first line
>> this is the second line
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
>> ((3830e37...)|REBASE)
>> $ echo it was a normal confict, I resolved it now, I am going to fix the
>> last file > nul
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
>> ((3830e37...)|REBASE)
>> $ git rebase --continue
>> Applying: bug2fix1: Fixed bub2fixFile1
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ echo Fixed this file > bug2fixDir/bug2FixFile2
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ cat bug2fixDir/bug2FixFile2
>> Fixed this file
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git status
>> # On branch bug2fix1
>> # Changes not staged for commit:
>> # (use "git add <file>..." to update what will be committed)
>> # (use "git checkout -- <file>..." to discard changes in working
>> directory)
>> #
>> # modified: bug2fixDir/bug2FixFile2
>> #
>> # Untracked files:
>> # (use "git add <file>..." to include in what will be committed)
>> #
>> # bug2fixDir/bug2FixFile1.orig
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ rm bug2fixDir/bug2FixFile1.orig
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git status
>> # On branch bug2fix1
>> # Changes not staged for commit:
>> # (use "git add <file>..." to update what will be committed)
>> # (use "git checkout -- <file>..." to discard changes in working
>> directory)
>> #
>> # modified: bug2fixDir/bug2FixFile2
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git commit -m "bug2fix1: Fixed bug2fixFile2" bug2fixDir/bug2FixFile2
>> 1 file changed, 1 insertion(+)
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git checkout develop
>> Switched to branch 'develop'
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git merge --no-ff bug2fix1
>> Merge made by the 'recursive' strategy.
>> bug2fixDir/bug2FixFile1 | 4 ++--
>> bug2fixDir/bug2FixFile2 | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> AsusFred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
>> (develop)
>> $ git branch -d bug2fix1
>> Deleted branch bug2fix1 (was 96c462c).
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git push
>> Counting objects: 13, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (7/7), done.
>> Writing objects: 100% (9/9), 857 bytes, done.
>> Total 9 (delta 3), reused 0 (delta 0)
>> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
>> 3830e37..aa030f4 develop -> develop
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git hist
>> * aa030f4 2013-03-22 | Merge branch 'bug2fix1' into develop (HEAD,
>> origin/develop, develop) [Justin Mclean]
>> |\
>> | * 96c462c 2013-03-22 | bug2fix1: Fixed bug2fixFile2 (bug2fix1) [Justin
>> Mclean]
>> | * b931b4e 2013-03-22 | bug2fix1: Fixed bub2fixFile1 [Justin Mclean]
>> |/
>> * 3830e37 2013-03-22 | Merge branch 'bug2fix2' into develop [Justin
>> Mclean]
>> |\
>> | * 46f7fe0 2013-03-22 | bug2fix2: Fixed bug2fixFile1 [Justin Mclean]
>> |/
>> * fcb51d5 2013-03-22 | Renamed the file [Justin Mclean]
>> * 868fa15 2013-03-22 | prepared the bug2fix demo1 [Justin Mclean]
>> * 3cbafc4 2013-03-21 | Added fr_FR [Justin]
>> * c3058e9 2013-03-21 | Updated the README again [Frédéric THOMAS]
>> * 54072f3 2013-03-21 | Added pt_PT [Justin Mclean]
>> * f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
>> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
>> origin/HEAD, master) [Frédéric THOMAS]
>>
>> -- NOTHING DESTRUCTIVE, both of the bug histories have been preserved and
>> are clearly visible, for this demo, I didn't flaten the bug2fix2 to the
>> develop branch even though it has one commit, I would have done it in the
>> real live.
>>
>> -----Message d'origine----- From: Justin Mclean
>> Sent: Friday, March 22, 2013 2:56 AM
>> To: dev@flex.apache.org
>> Subject: Re: [OT] Log history
>>
>> Hi,
>>
>> Thanks for going though that.
>>
>>> ---------------------------------
>>> You add locales
>>> ---------------------------------
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
>>> test_Rebased_Hotfix_Without_Conflic
>>> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
>>
>>
>> etc etc
>>
>> Actually it wasn't quite like that in that as files and directories
>> already
>> existed. It does seem a bit excessive to make a branch just to change a
>> single file and it also assumes I have no other changes and a perfectly
>> clean tree (not the case). As the branch is local and not shared with
>> anyone
>> else do you really need a branch for a simple change to a singe file?
>>
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin
>>> develop
>>
>>
>> This is the bit I'm confused about why would I use --rebase when all
>> documentation I've read say it dangerous to use and it hard to undo
>> (unlike
>> merge) and it difficult to see what it's going to do (no --dry-run) - I
>> know
>> both of this situations have work arounds (mostly) but they are complex.
>> It
>> seems to me that knowing what about to happen and being able to back out
>> of
>> it if things go wrong is far more important than having a totally "clean"
>> history. It's not like the history produced was incorrect or even
>> confusing.
>>
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
>>> test_Rebased_Hotfix_Without_Conflic
>>
>>
>> Why is --no-ff required? What would happen if this option wasn't used in
>> this case? And if I didn't make the branch in the first place there would
>> be
>> no need for this merge or the hard reset below right?
>>
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
>>
>>
>> How do I know I need to do this? Would I need to do this every time?
>>
>> I really don't want to have to work though obscure git options and issue
>> a
>> dozen git commands just to check in a single fix to a single file. If we
>> have to do that then I think we are using the tools incorrectly or it's
>> the
>> wrong tool for the job. IMO we need to make it as easy or easier than SVN
>> to
>> use and add yet more complexity.
>>
>> Thanks,
>> Justin
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Wait... did I get it the wrong way around?
I made a note when reading through the list earlier, but I can't find
the source anymore:
"if you always work on the local develop branch (instead of a (local)
feature branch), use 'git pull \--rebase' (automate via: 'git config
\--global branch.autosetuprebase always'); if you work locally in
(feature) branches, use plain 'git pull'"
This would mean that when following Gitflow (always work on feature
branches), we'd never use --rebase...
Thoroughly confused,
EdB
On Fri, Mar 22, 2013 at 10:58 AM, Erik de Bruin <er...@ixsoftware.nl> wrote:
> Fred,
>
> As the Gitflow model this project agreed to follow says to always (and
> only) work on feature branches, we will never work directly on the
> (local) develop branch... Does this mean that the only case where
> 'rebase' might cause an irreversible problem doesn't exist for us? I
> think it does, but stating this explicitly here and on the wiki will
> take away much of the trouble people seem to be having with the
> suggested workflow.
>
> EdB
>
>
>
> On Fri, Mar 22, 2013 at 10:48 AM, Frédéric THOMAS
> <we...@hotmail.com> wrote:
>>> Rebasing is the operation to get the others work rewriting YOUR commits on
>>> top of them, it means you will never rewrite their history.
>>
>>
>> That deserves a better explanation, actually, visually, it doesn't look like
>> to be rewritten but it is, and in the natural historical order.
>> Note, everything already pushed will be the exact same as it is on the
>> remote repo and your work will be re-writen on top, so the only risks is if
>> YOU have an unpushed merge, in this case YOUR merge will be flaten but if
>> you follow the guideline I explained in the previous post, it will never
>> happen.
>>
>> Thanks,
>> -Fred
>>
>> -----Message d'origine----- From: Frédéric THOMAS
>> Sent: Friday, March 22, 2013 10:12 AM
>>
>> To: dev@flex.apache.org
>> Subject: Re: [OT] Log history
>>
>> Hi,
>>
>> I'm happy you gone into this and less because I thought you already
>> understood why and when it is better and cleaner while it is safe to use
>> rebasing instead of merging but no problem, I'm going to try to explain it
>> again later.
>>
>>
>>
>> 1- Branching:
>>
>> The point, in the example I provided was to illustrate how you should work
>> from a branch as branching and merging are cheap and are considered as a
>> standard developement workflow on Git, even if you work only on local
>> branches, the reason behind that is that you might discover another bug,
>> nothing relative to the one you're working on (but that impact the same
>> file(s)) and this new bug has a higher priority and then has to be fixed
>> now, making you stoping the dev of your current bug.
>> It's then better to fix it on another branch, doing do, it will be
>> availlable for the others as well as for you if you rebase your branch on it
>> (again, I will tell you later why it is safe to do so at this point).
>> If you have been working on the develop branch directly or on the branch
>> dedicated to the bug you was working on before, it would have not been clear
>> later in the paralelle history line of your bugfix why there's something not
>> relative to it, I made an example of this you can look at [1], as you will
>> see, there's nothing destructive using pull --rebase as soon as you
>> understand when, where and why to use it.
>>
>> I hope with the last paragraph, I made clearer why working on a
>> feature/bugfix branch is better than on the develop branch.
>> Indeed, if you work with someone else, it makes the thing more obvious.
>>
>> Note: If you apply a quick patch or the dev is only one line of code to
>> change and there are no tests to do, etc..., in this case, it's ok to do it
>> directly on the develop branch, taking the precaution of rebasing before
>> committing however.
>>
>>
>>
>>
>> 2- Rebasing, merging, what, when, where and why :
>>
>> Know something once and for ever: rebasing preserve a good history and is
>> not destructive until you didn't merge the branch you are working on and
>> didn't pushed it yet.
>> (and for the latter, you can always avoid it as soon as you follow the good
>> practices, see the conclusion).
>>
>> Note, I explain with my words and my poor English :P
>>
>> Let's start:
>>
>> A- Rebasing:
>>
>> a- What is rebasing:
>>
>> Rebasing is the operation to get the others work rewriting YOUR commits on
>> top of them, it means you will never rewrite their history.
>>
>> b- When rebasing:
>>
>> Each time you know or you thing the branch you're based on changed or even
>> only when there is a significant amount of time you didn't do it.
>>
>> c- Where and from where to rebase:
>>
>> From a branch: it means everywhere.
>> The From Where is depending if you are working on a local branch or a
>> tracked branch.
>>
>> From a local branch, you will like to rebase onto the branch your branch is
>> based from.
>> From a tracked branch, same as before plus the same remote branch to track
>> what your mates did.
>>
>> d- Finaly, WHY it works and it is not descrutive unless you don't follow the
>> good practice i'm explaining in this doc :
>>
>> Because until you didn't merge and not pushed, there are no cases where
>> rebase will not preserve yours and the others history, it will put your work
>> on top of the others, if you/they did a merge and pushed it, this merge
>> still will be preserved.
>>
>>
>>
>> B- Merging:
>>
>> a- What is merging:
>>
>> Merging is the operation to of joining 2 or more developement lines,
>> basicly, this operation will write your commits ahead of the current HEAD,
>> you can use the --no-ff flag to indicate you want an extra commit, the merge
>> commit, which will make your work easily reversed and will identify clearly
>> this work on the remote branch it will be pushed.
>>
>> b- When merging:
>>
>> Just before pushing, like that, you are preversed from the mad reads I see
>> on internet talking about the rebase risks.
>>
>> c- Where merging:
>>
>> From the branch you want your feature/bugfix branch be merge.
>>
>> d- Why merging :
>>
>> I mean, the anwser is in the What.
>>
>>
>> C- Conclusion:
>>
>> Reabase all the time, until you don't have a pending merge that is not
>> pushed.
>> But if you follow my guideline relative to the When merging, you should not
>> encounter this situation.
>>
>> I hope those explanations anwser all of your questions, except maybe this
>> one:
>>
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
>>
>>
>> How do I know I need to do this? Would I need to do this every time?
>> I really don't want to have to work though obscure git options and issue a
>> dozen git commands just to check in a single fix to a single file. If we
>> have to do that then I think we are using the tools incorrectly or it's the
>> wrong tool for the job. IMO we need to make it as easy or easier than SVN to
>> use and add yet more complexity.
>>
>> In the context of the demo I did, it was to revert the timeline just before
>> the merge operation which did a no fast forward merge with the --no-ff flag,
>> causing the creation of a merge commit, I wanted to show you how to remove
>> it in case you decided you wanted a flat history at the end.
>>
>> Thanks,
>> -Fred
>>
>> [1]
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git checkout -b bug2fix1
>> Switched to a new branch 'bug2fix1'
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ ls bug2fixDir/
>> bug2FixFile1 bug2FixFile2
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the 1rst line
>> this is the 2nd line
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ echo Bug2fix1 should fix the line1 writing first instead of 1rst > null
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the first line
>> this is the 2nd line
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git commit -m "bug2fix1: Fixed bub2fixFile1" bug2fixDir/bug2FixFile1
>> [bug2fix1 51af745] bug2fix1: Fixed bub2fixFile1
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ echo As you can see, there is the second line to fix as well but not plan
>> for this bug, so I open an other jira and f
>> ix it > nul
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git checkout develop
>> Switched to branch 'develop'
>> Your branch is ahead of 'origin/develop' by 2 commits.
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git checkout -b bug2fix2
>> Switched to a new branch 'bug2fix2'
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the 1rst line
>> this is the 2nd line
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ echo Fix the line 2 > nul
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the 1rst line
>> this is the second line
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ git commit -m "bug2fix2: Fixed bug2fixFile1" bug2fixDir/bug2FixFile1
>> [bug2fix2 46f7fe0] bug2fix2: Fixed bug2fixFile1
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
>> $ git checkout develop
>> Switched to branch 'develop'
>> Your branch is ahead of 'origin/develop' by 2 commits.
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git merge --no-ff bug2fix2
>> Merge made by the 'recursive' strategy.
>> bug2fixDir/bug2FixFile1 | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git branch -d bug2fix2
>> Deleted branch bug2fix2 (was 46f7fe0).
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git push
>> Counting objects: 14, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (10/10), done.
>> Writing objects: 100% (13/13), 1.16 KiB, done.
>> Total 13 (delta 3), reused 0 (delta 0)
>> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
>> 3cbafc4..3830e37 develop -> develop
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git checkout bug2fix1
>> Switched to branch 'bug2fix1'
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git pull --rebase origin develop
>> From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
>> * branch develop -> FETCH_HEAD
>> First, rewinding head to replay your work on top of it...
>> Applying: bug2fix1: Fixed bub2fixFile1
>> Using index info to reconstruct a base tree...
>> M bug2fixDir/bug2FixFile1
>> Falling back to patching base and 3-way merge...
>> Auto-merging bug2fixDir/bug2FixFile1
>> CONFLICT (content): Merge conflict in bug2fixDir/bug2FixFile1
>> Failed to merge in the changes.
>> Patch failed at 0001 bug2fix1: Fixed bub2fixFile1
>> The copy of the patch that failed is found in:
>> u:/gitLab/work/asf/flex/testWorkFlow/justin/.git/rebase-apply/patch
>>
>> When you have resolved this problem, run "git rebase --continue".
>> If you prefer to skip this patch, run "git rebase --skip" instead.
>> To check out the original branch and stop rebasing, run "git
>> rebase --abort".
>>
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
>> ((3830e37...)|REBASE)
>> $ git mergetool bug2fixDir/bug2FixFile1
>> Merging:
>> bug2fixDir/bug2FixFile1
>>
>> Normal merge conflict for 'bug2fixDir/bug2FixFile1':
>> {local}: modified file
>> {remote}: modified file
>> Hit return to start merge resolution tool (p4merge):
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
>> ((3830e37...)|REBASE)
>> $ cat bug2fixDir/bug2FixFile1
>> This is the first line
>> this is the second line
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
>> ((3830e37...)|REBASE)
>> $ echo it was a normal confict, I resolved it now, I am going to fix the
>> last file > nul
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
>> ((3830e37...)|REBASE)
>> $ git rebase --continue
>> Applying: bug2fix1: Fixed bub2fixFile1
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ echo Fixed this file > bug2fixDir/bug2FixFile2
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ cat bug2fixDir/bug2FixFile2
>> Fixed this file
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git status
>> # On branch bug2fix1
>> # Changes not staged for commit:
>> # (use "git add <file>..." to update what will be committed)
>> # (use "git checkout -- <file>..." to discard changes in working
>> directory)
>> #
>> # modified: bug2fixDir/bug2FixFile2
>> #
>> # Untracked files:
>> # (use "git add <file>..." to include in what will be committed)
>> #
>> # bug2fixDir/bug2FixFile1.orig
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ rm bug2fixDir/bug2FixFile1.orig
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git status
>> # On branch bug2fix1
>> # Changes not staged for commit:
>> # (use "git add <file>..." to update what will be committed)
>> # (use "git checkout -- <file>..." to discard changes in working
>> directory)
>> #
>> # modified: bug2fixDir/bug2FixFile2
>> #
>> no changes added to commit (use "git add" and/or "git commit -a")
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git commit -m "bug2fix1: Fixed bug2fixFile2" bug2fixDir/bug2FixFile2
>> 1 file changed, 1 insertion(+)
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
>> $ git checkout develop
>> Switched to branch 'develop'
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git merge --no-ff bug2fix1
>> Merge made by the 'recursive' strategy.
>> bug2fixDir/bug2FixFile1 | 4 ++--
>> bug2fixDir/bug2FixFile2 | 1 +
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> AsusFred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git branch -d bug2fix1
>> Deleted branch bug2fix1 (was 96c462c).
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git push
>> Counting objects: 13, done.
>> Delta compression using up to 8 threads.
>> Compressing objects: 100% (7/7), done.
>> Writing objects: 100% (9/9), 857 bytes, done.
>> Total 9 (delta 3), reused 0 (delta 0)
>> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
>> 3830e37..aa030f4 develop -> develop
>>
>> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
>> $ git hist
>> * aa030f4 2013-03-22 | Merge branch 'bug2fix1' into develop (HEAD,
>> origin/develop, develop) [Justin Mclean]
>> |\
>> | * 96c462c 2013-03-22 | bug2fix1: Fixed bug2fixFile2 (bug2fix1) [Justin
>> Mclean]
>> | * b931b4e 2013-03-22 | bug2fix1: Fixed bub2fixFile1 [Justin Mclean]
>> |/
>> * 3830e37 2013-03-22 | Merge branch 'bug2fix2' into develop [Justin
>> Mclean]
>> |\
>> | * 46f7fe0 2013-03-22 | bug2fix2: Fixed bug2fixFile1 [Justin Mclean]
>> |/
>> * fcb51d5 2013-03-22 | Renamed the file [Justin Mclean]
>> * 868fa15 2013-03-22 | prepared the bug2fix demo1 [Justin Mclean]
>> * 3cbafc4 2013-03-21 | Added fr_FR [Justin]
>> * c3058e9 2013-03-21 | Updated the README again [Frédéric THOMAS]
>> * 54072f3 2013-03-21 | Added pt_PT [Justin Mclean]
>> * f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
>> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
>> origin/HEAD, master) [Frédéric THOMAS]
>>
>> -- NOTHING DESTRUCTIVE, both of the bug histories have been preserved and
>> are clearly visible, for this demo, I didn't flaten the bug2fix2 to the
>> develop branch even though it has one commit, I would have done it in the
>> real live.
>>
>> -----Message d'origine----- From: Justin Mclean
>> Sent: Friday, March 22, 2013 2:56 AM
>> To: dev@flex.apache.org
>> Subject: Re: [OT] Log history
>>
>> Hi,
>>
>> Thanks for going though that.
>>
>>> ---------------------------------
>>> You add locales
>>> ---------------------------------
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
>>> test_Rebased_Hotfix_Without_Conflic
>>> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
>>
>>
>> etc etc
>>
>> Actually it wasn't quite like that in that as files and directories already
>> existed. It does seem a bit excessive to make a branch just to change a
>> single file and it also assumes I have no other changes and a perfectly
>> clean tree (not the case). As the branch is local and not shared with anyone
>> else do you really need a branch for a simple change to a singe file?
>>
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin
>>> develop
>>
>>
>> This is the bit I'm confused about why would I use --rebase when all
>> documentation I've read say it dangerous to use and it hard to undo (unlike
>> merge) and it difficult to see what it's going to do (no --dry-run) - I know
>> both of this situations have work arounds (mostly) but they are complex. It
>> seems to me that knowing what about to happen and being able to back out of
>> it if things go wrong is far more important than having a totally "clean"
>> history. It's not like the history produced was incorrect or even confusing.
>>
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
>>> test_Rebased_Hotfix_Without_Conflic
>>
>>
>> Why is --no-ff required? What would happen if this option wasn't used in
>> this case? And if I didn't make the branch in the first place there would be
>> no need for this merge or the hard reset below right?
>>
>>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
>>
>>
>> How do I know I need to do this? Would I need to do this every time?
>>
>> I really don't want to have to work though obscure git options and issue a
>> dozen git commands just to check in a single fix to a single file. If we
>> have to do that then I think we are using the tools incorrectly or it's the
>> wrong tool for the job. IMO we need to make it as easy or easier than SVN to
>> use and add yet more complexity.
>>
>> Thanks,
>> Justin
>>
>
>
>
> --
> Ix Multimedia Software
>
> Jan Luykenstraat 27
> 3521 VB Utrecht
>
> T. 06-51952295
> I. www.ixsoftware.nl
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Erik de Bruin <er...@ixsoftware.nl>.
Fred,
As the Gitflow model this project agreed to follow says to always (and
only) work on feature branches, we will never work directly on the
(local) develop branch... Does this mean that the only case where
'rebase' might cause an irreversible problem doesn't exist for us? I
think it does, but stating this explicitly here and on the wiki will
take away much of the trouble people seem to be having with the
suggested workflow.
EdB
On Fri, Mar 22, 2013 at 10:48 AM, Frédéric THOMAS
<we...@hotmail.com> wrote:
>> Rebasing is the operation to get the others work rewriting YOUR commits on
>> top of them, it means you will never rewrite their history.
>
>
> That deserves a better explanation, actually, visually, it doesn't look like
> to be rewritten but it is, and in the natural historical order.
> Note, everything already pushed will be the exact same as it is on the
> remote repo and your work will be re-writen on top, so the only risks is if
> YOU have an unpushed merge, in this case YOUR merge will be flaten but if
> you follow the guideline I explained in the previous post, it will never
> happen.
>
> Thanks,
> -Fred
>
> -----Message d'origine----- From: Frédéric THOMAS
> Sent: Friday, March 22, 2013 10:12 AM
>
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> Hi,
>
> I'm happy you gone into this and less because I thought you already
> understood why and when it is better and cleaner while it is safe to use
> rebasing instead of merging but no problem, I'm going to try to explain it
> again later.
>
>
>
> 1- Branching:
>
> The point, in the example I provided was to illustrate how you should work
> from a branch as branching and merging are cheap and are considered as a
> standard developement workflow on Git, even if you work only on local
> branches, the reason behind that is that you might discover another bug,
> nothing relative to the one you're working on (but that impact the same
> file(s)) and this new bug has a higher priority and then has to be fixed
> now, making you stoping the dev of your current bug.
> It's then better to fix it on another branch, doing do, it will be
> availlable for the others as well as for you if you rebase your branch on it
> (again, I will tell you later why it is safe to do so at this point).
> If you have been working on the develop branch directly or on the branch
> dedicated to the bug you was working on before, it would have not been clear
> later in the paralelle history line of your bugfix why there's something not
> relative to it, I made an example of this you can look at [1], as you will
> see, there's nothing destructive using pull --rebase as soon as you
> understand when, where and why to use it.
>
> I hope with the last paragraph, I made clearer why working on a
> feature/bugfix branch is better than on the develop branch.
> Indeed, if you work with someone else, it makes the thing more obvious.
>
> Note: If you apply a quick patch or the dev is only one line of code to
> change and there are no tests to do, etc..., in this case, it's ok to do it
> directly on the develop branch, taking the precaution of rebasing before
> committing however.
>
>
>
>
> 2- Rebasing, merging, what, when, where and why :
>
> Know something once and for ever: rebasing preserve a good history and is
> not destructive until you didn't merge the branch you are working on and
> didn't pushed it yet.
> (and for the latter, you can always avoid it as soon as you follow the good
> practices, see the conclusion).
>
> Note, I explain with my words and my poor English :P
>
> Let's start:
>
> A- Rebasing:
>
> a- What is rebasing:
>
> Rebasing is the operation to get the others work rewriting YOUR commits on
> top of them, it means you will never rewrite their history.
>
> b- When rebasing:
>
> Each time you know or you thing the branch you're based on changed or even
> only when there is a significant amount of time you didn't do it.
>
> c- Where and from where to rebase:
>
> From a branch: it means everywhere.
> The From Where is depending if you are working on a local branch or a
> tracked branch.
>
> From a local branch, you will like to rebase onto the branch your branch is
> based from.
> From a tracked branch, same as before plus the same remote branch to track
> what your mates did.
>
> d- Finaly, WHY it works and it is not descrutive unless you don't follow the
> good practice i'm explaining in this doc :
>
> Because until you didn't merge and not pushed, there are no cases where
> rebase will not preserve yours and the others history, it will put your work
> on top of the others, if you/they did a merge and pushed it, this merge
> still will be preserved.
>
>
>
> B- Merging:
>
> a- What is merging:
>
> Merging is the operation to of joining 2 or more developement lines,
> basicly, this operation will write your commits ahead of the current HEAD,
> you can use the --no-ff flag to indicate you want an extra commit, the merge
> commit, which will make your work easily reversed and will identify clearly
> this work on the remote branch it will be pushed.
>
> b- When merging:
>
> Just before pushing, like that, you are preversed from the mad reads I see
> on internet talking about the rebase risks.
>
> c- Where merging:
>
> From the branch you want your feature/bugfix branch be merge.
>
> d- Why merging :
>
> I mean, the anwser is in the What.
>
>
> C- Conclusion:
>
> Reabase all the time, until you don't have a pending merge that is not
> pushed.
> But if you follow my guideline relative to the When merging, you should not
> encounter this situation.
>
> I hope those explanations anwser all of your questions, except maybe this
> one:
>
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
>
>
> How do I know I need to do this? Would I need to do this every time?
> I really don't want to have to work though obscure git options and issue a
> dozen git commands just to check in a single fix to a single file. If we
> have to do that then I think we are using the tools incorrectly or it's the
> wrong tool for the job. IMO we need to make it as easy or easier than SVN to
> use and add yet more complexity.
>
> In the context of the demo I did, it was to revert the timeline just before
> the merge operation which did a no fast forward merge with the --no-ff flag,
> causing the creation of a merge commit, I wanted to show you how to remove
> it in case you decided you wanted a flat history at the end.
>
> Thanks,
> -Fred
>
> [1]
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git checkout -b bug2fix1
> Switched to a new branch 'bug2fix1'
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ ls bug2fixDir/
> bug2FixFile1 bug2FixFile2
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ cat bug2fixDir/bug2FixFile1
> This is the 1rst line
> this is the 2nd line
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ echo Bug2fix1 should fix the line1 writing first instead of 1rst > null
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ cat bug2fixDir/bug2FixFile1
> This is the first line
> this is the 2nd line
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git commit -m "bug2fix1: Fixed bub2fixFile1" bug2fixDir/bug2FixFile1
> [bug2fix1 51af745] bug2fix1: Fixed bub2fixFile1
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ echo As you can see, there is the second line to fix as well but not plan
> for this bug, so I open an other jira and f
> ix it > nul
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git checkout develop
> Switched to branch 'develop'
> Your branch is ahead of 'origin/develop' by 2 commits.
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git checkout -b bug2fix2
> Switched to a new branch 'bug2fix2'
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ cat bug2fixDir/bug2FixFile1
> This is the 1rst line
> this is the 2nd line
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ echo Fix the line 2 > nul
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ cat bug2fixDir/bug2FixFile1
> This is the 1rst line
> this is the second line
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ git commit -m "bug2fix2: Fixed bug2fixFile1" bug2fixDir/bug2FixFile1
> [bug2fix2 46f7fe0] bug2fix2: Fixed bug2fixFile1
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
> $ git checkout develop
> Switched to branch 'develop'
> Your branch is ahead of 'origin/develop' by 2 commits.
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git merge --no-ff bug2fix2
> Merge made by the 'recursive' strategy.
> bug2fixDir/bug2FixFile1 | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git branch -d bug2fix2
> Deleted branch bug2fix2 (was 46f7fe0).
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git push
> Counting objects: 14, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (10/10), done.
> Writing objects: 100% (13/13), 1.16 KiB, done.
> Total 13 (delta 3), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
> 3cbafc4..3830e37 develop -> develop
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git checkout bug2fix1
> Switched to branch 'bug2fix1'
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git pull --rebase origin develop
> From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
> * branch develop -> FETCH_HEAD
> First, rewinding head to replay your work on top of it...
> Applying: bug2fix1: Fixed bub2fixFile1
> Using index info to reconstruct a base tree...
> M bug2fixDir/bug2FixFile1
> Falling back to patching base and 3-way merge...
> Auto-merging bug2fixDir/bug2FixFile1
> CONFLICT (content): Merge conflict in bug2fixDir/bug2FixFile1
> Failed to merge in the changes.
> Patch failed at 0001 bug2fix1: Fixed bub2fixFile1
> The copy of the patch that failed is found in:
> u:/gitLab/work/asf/flex/testWorkFlow/justin/.git/rebase-apply/patch
>
> When you have resolved this problem, run "git rebase --continue".
> If you prefer to skip this patch, run "git rebase --skip" instead.
> To check out the original branch and stop rebasing, run "git
> rebase --abort".
>
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
> ((3830e37...)|REBASE)
> $ git mergetool bug2fixDir/bug2FixFile1
> Merging:
> bug2fixDir/bug2FixFile1
>
> Normal merge conflict for 'bug2fixDir/bug2FixFile1':
> {local}: modified file
> {remote}: modified file
> Hit return to start merge resolution tool (p4merge):
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
> ((3830e37...)|REBASE)
> $ cat bug2fixDir/bug2FixFile1
> This is the first line
> this is the second line
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
> ((3830e37...)|REBASE)
> $ echo it was a normal confict, I resolved it now, I am going to fix the
> last file > nul
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
> ((3830e37...)|REBASE)
> $ git rebase --continue
> Applying: bug2fix1: Fixed bub2fixFile1
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ echo Fixed this file > bug2fixDir/bug2FixFile2
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ cat bug2fixDir/bug2FixFile2
> Fixed this file
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git status
> # On branch bug2fix1
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working
> directory)
> #
> # modified: bug2fixDir/bug2FixFile2
> #
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # bug2fixDir/bug2FixFile1.orig
> no changes added to commit (use "git add" and/or "git commit -a")
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ rm bug2fixDir/bug2FixFile1.orig
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git status
> # On branch bug2fix1
> # Changes not staged for commit:
> # (use "git add <file>..." to update what will be committed)
> # (use "git checkout -- <file>..." to discard changes in working
> directory)
> #
> # modified: bug2fixDir/bug2FixFile2
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git commit -m "bug2fix1: Fixed bug2fixFile2" bug2fixDir/bug2FixFile2
> 1 file changed, 1 insertion(+)
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
> $ git checkout develop
> Switched to branch 'develop'
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git merge --no-ff bug2fix1
> Merge made by the 'recursive' strategy.
> bug2fixDir/bug2FixFile1 | 4 ++--
> bug2fixDir/bug2FixFile2 | 1 +
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> AsusFred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git branch -d bug2fix1
> Deleted branch bug2fix1 (was 96c462c).
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git push
> Counting objects: 13, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (7/7), done.
> Writing objects: 100% (9/9), 857 bytes, done.
> Total 9 (delta 3), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
> 3830e37..aa030f4 develop -> develop
>
> Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
> $ git hist
> * aa030f4 2013-03-22 | Merge branch 'bug2fix1' into develop (HEAD,
> origin/develop, develop) [Justin Mclean]
> |\
> | * 96c462c 2013-03-22 | bug2fix1: Fixed bug2fixFile2 (bug2fix1) [Justin
> Mclean]
> | * b931b4e 2013-03-22 | bug2fix1: Fixed bub2fixFile1 [Justin Mclean]
> |/
> * 3830e37 2013-03-22 | Merge branch 'bug2fix2' into develop [Justin
> Mclean]
> |\
> | * 46f7fe0 2013-03-22 | bug2fix2: Fixed bug2fixFile1 [Justin Mclean]
> |/
> * fcb51d5 2013-03-22 | Renamed the file [Justin Mclean]
> * 868fa15 2013-03-22 | prepared the bug2fix demo1 [Justin Mclean]
> * 3cbafc4 2013-03-21 | Added fr_FR [Justin]
> * c3058e9 2013-03-21 | Updated the README again [Frédéric THOMAS]
> * 54072f3 2013-03-21 | Added pt_PT [Justin Mclean]
> * f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
> -- NOTHING DESTRUCTIVE, both of the bug histories have been preserved and
> are clearly visible, for this demo, I didn't flaten the bug2fix2 to the
> develop branch even though it has one commit, I would have done it in the
> real live.
>
> -----Message d'origine----- From: Justin Mclean
> Sent: Friday, March 22, 2013 2:56 AM
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> Hi,
>
> Thanks for going though that.
>
>> ---------------------------------
>> You add locales
>> ---------------------------------
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
>> test_Rebased_Hotfix_Without_Conflic
>> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
>
>
> etc etc
>
> Actually it wasn't quite like that in that as files and directories already
> existed. It does seem a bit excessive to make a branch just to change a
> single file and it also assumes I have no other changes and a perfectly
> clean tree (not the case). As the branch is local and not shared with anyone
> else do you really need a branch for a simple change to a singe file?
>
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin
>> develop
>
>
> This is the bit I'm confused about why would I use --rebase when all
> documentation I've read say it dangerous to use and it hard to undo (unlike
> merge) and it difficult to see what it's going to do (no --dry-run) - I know
> both of this situations have work arounds (mostly) but they are complex. It
> seems to me that knowing what about to happen and being able to back out of
> it if things go wrong is far more important than having a totally "clean"
> history. It's not like the history produced was incorrect or even confusing.
>
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
>> test_Rebased_Hotfix_Without_Conflic
>
>
> Why is --no-ff required? What would happen if this option wasn't used in
> this case? And if I didn't make the branch in the first place there would be
> no need for this merge or the hard reset below right?
>
>> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
>
>
> How do I know I need to do this? Would I need to do this every time?
>
> I really don't want to have to work though obscure git options and issue a
> dozen git commands just to check in a single fix to a single file. If we
> have to do that then I think we are using the tools incorrectly or it's the
> wrong tool for the job. IMO we need to make it as easy or easier than SVN to
> use and add yet more complexity.
>
> Thanks,
> Justin
>
--
Ix Multimedia Software
Jan Luykenstraat 27
3521 VB Utrecht
T. 06-51952295
I. www.ixsoftware.nl
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
> Rebasing is the operation to get the others work rewriting YOUR commits on
> top of them, it means you will never rewrite their history.
That deserves a better explanation, actually, visually, it doesn't look like
to be rewritten but it is, and in the natural historical order.
Note, everything already pushed will be the exact same as it is on the
remote repo and your work will be re-writen on top, so the only risks is if
YOU have an unpushed merge, in this case YOUR merge will be flaten but if
you follow the guideline I explained in the previous post, it will never
happen.
Thanks,
-Fred
-----Message d'origine-----
From: Frédéric THOMAS
Sent: Friday, March 22, 2013 10:12 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
I'm happy you gone into this and less because I thought you already
understood why and when it is better and cleaner while it is safe to use
rebasing instead of merging but no problem, I'm going to try to explain it
again later.
1- Branching:
The point, in the example I provided was to illustrate how you should work
from a branch as branching and merging are cheap and are considered as a
standard developement workflow on Git, even if you work only on local
branches, the reason behind that is that you might discover another bug,
nothing relative to the one you're working on (but that impact the same
file(s)) and this new bug has a higher priority and then has to be fixed
now, making you stoping the dev of your current bug.
It's then better to fix it on another branch, doing do, it will be
availlable for the others as well as for you if you rebase your branch on it
(again, I will tell you later why it is safe to do so at this point).
If you have been working on the develop branch directly or on the branch
dedicated to the bug you was working on before, it would have not been clear
later in the paralelle history line of your bugfix why there's something not
relative to it, I made an example of this you can look at [1], as you will
see, there's nothing destructive using pull --rebase as soon as you
understand when, where and why to use it.
I hope with the last paragraph, I made clearer why working on a
feature/bugfix branch is better than on the develop branch.
Indeed, if you work with someone else, it makes the thing more obvious.
Note: If you apply a quick patch or the dev is only one line of code to
change and there are no tests to do, etc..., in this case, it's ok to do it
directly on the develop branch, taking the precaution of rebasing before
committing however.
2- Rebasing, merging, what, when, where and why :
Know something once and for ever: rebasing preserve a good history and is
not destructive until you didn't merge the branch you are working on and
didn't pushed it yet.
(and for the latter, you can always avoid it as soon as you follow the good
practices, see the conclusion).
Note, I explain with my words and my poor English :P
Let's start:
A- Rebasing:
a- What is rebasing:
Rebasing is the operation to get the others work rewriting YOUR commits on
top of them, it means you will never rewrite their history.
b- When rebasing:
Each time you know or you thing the branch you're based on changed or even
only when there is a significant amount of time you didn't do it.
c- Where and from where to rebase:
>From a branch: it means everywhere.
The From Where is depending if you are working on a local branch or a
tracked branch.
>From a local branch, you will like to rebase onto the branch your branch is
based from.
>From a tracked branch, same as before plus the same remote branch to track
what your mates did.
d- Finaly, WHY it works and it is not descrutive unless you don't follow the
good practice i'm explaining in this doc :
Because until you didn't merge and not pushed, there are no cases where
rebase will not preserve yours and the others history, it will put your work
on top of the others, if you/they did a merge and pushed it, this merge
still will be preserved.
B- Merging:
a- What is merging:
Merging is the operation to of joining 2 or more developement lines,
basicly, this operation will write your commits ahead of the current HEAD,
you can use the --no-ff flag to indicate you want an extra commit, the merge
commit, which will make your work easily reversed and will identify clearly
this work on the remote branch it will be pushed.
b- When merging:
Just before pushing, like that, you are preversed from the mad reads I see
on internet talking about the rebase risks.
c- Where merging:
>From the branch you want your feature/bugfix branch be merge.
d- Why merging :
I mean, the anwser is in the What.
C- Conclusion:
Reabase all the time, until you don't have a pending merge that is not
pushed.
But if you follow my guideline relative to the When merging, you should not
encounter this situation.
I hope those explanations anwser all of your questions, except maybe this
one:
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
How do I know I need to do this? Would I need to do this every time?
I really don't want to have to work though obscure git options and issue a
dozen git commands just to check in a single fix to a single file. If we
have to do that then I think we are using the tools incorrectly or it's the
wrong tool for the job. IMO we need to make it as easy or easier than SVN to
use and add yet more complexity.
In the context of the demo I did, it was to revert the timeline just before
the merge operation which did a no fast forward merge with the --no-ff flag,
causing the creation of a merge commit, I wanted to show you how to remove
it in case you decided you wanted a flat history at the end.
Thanks,
-Fred
[1]
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git checkout -b bug2fix1
Switched to a new branch 'bug2fix1'
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ ls bug2fixDir/
bug2FixFile1 bug2FixFile2
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ cat bug2fixDir/bug2FixFile1
This is the 1rst line
this is the 2nd line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ echo Bug2fix1 should fix the line1 writing first instead of 1rst > null
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ cat bug2fixDir/bug2FixFile1
This is the first line
this is the 2nd line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git commit -m "bug2fix1: Fixed bub2fixFile1" bug2fixDir/bug2FixFile1
[bug2fix1 51af745] bug2fix1: Fixed bub2fixFile1
1 file changed, 1 insertion(+), 1 deletion(-)
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ echo As you can see, there is the second line to fix as well but not plan
for this bug, so I open an other jira and f
ix it > nul
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git checkout develop
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 2 commits.
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git checkout -b bug2fix2
Switched to a new branch 'bug2fix2'
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ cat bug2fixDir/bug2FixFile1
This is the 1rst line
this is the 2nd line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ echo Fix the line 2 > nul
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ cat bug2fixDir/bug2FixFile1
This is the 1rst line
this is the second line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ git commit -m "bug2fix2: Fixed bug2fixFile1" bug2fixDir/bug2FixFile1
[bug2fix2 46f7fe0] bug2fix2: Fixed bug2fixFile1
1 file changed, 1 insertion(+), 1 deletion(-)
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ git checkout develop
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 2 commits.
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git merge --no-ff bug2fix2
Merge made by the 'recursive' strategy.
bug2fixDir/bug2FixFile1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git branch -d bug2fix2
Deleted branch bug2fix2 (was 46f7fe0).
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git push
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (13/13), 1.16 KiB, done.
Total 13 (delta 3), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
3cbafc4..3830e37 develop -> develop
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git checkout bug2fix1
Switched to branch 'bug2fix1'
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git pull --rebase origin develop
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: bug2fix1: Fixed bub2fixFile1
Using index info to reconstruct a base tree...
M bug2fixDir/bug2FixFile1
Falling back to patching base and 3-way merge...
Auto-merging bug2fixDir/bug2FixFile1
CONFLICT (content): Merge conflict in bug2fixDir/bug2FixFile1
Failed to merge in the changes.
Patch failed at 0001 bug2fix1: Fixed bub2fixFile1
The copy of the patch that failed is found in:
u:/gitLab/work/asf/flex/testWorkFlow/justin/.git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git
rebase --abort".
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
((3830e37...)|REBASE)
$ git mergetool bug2fixDir/bug2FixFile1
Merging:
bug2fixDir/bug2FixFile1
Normal merge conflict for 'bug2fixDir/bug2FixFile1':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (p4merge):
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
((3830e37...)|REBASE)
$ cat bug2fixDir/bug2FixFile1
This is the first line
this is the second line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
((3830e37...)|REBASE)
$ echo it was a normal confict, I resolved it now, I am going to fix the
last file > nul
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
((3830e37...)|REBASE)
$ git rebase --continue
Applying: bug2fix1: Fixed bub2fixFile1
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ echo Fixed this file > bug2fixDir/bug2FixFile2
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ cat bug2fixDir/bug2FixFile2
Fixed this file
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git status
# On branch bug2fix1
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: bug2fixDir/bug2FixFile2
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# bug2fixDir/bug2FixFile1.orig
no changes added to commit (use "git add" and/or "git commit -a")
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ rm bug2fixDir/bug2FixFile1.orig
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git status
# On branch bug2fix1
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: bug2fixDir/bug2FixFile2
#
no changes added to commit (use "git add" and/or "git commit -a")
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git commit -m "bug2fix1: Fixed bug2fixFile2" bug2fixDir/bug2FixFile2
1 file changed, 1 insertion(+)
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git checkout develop
Switched to branch 'develop'
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git merge --no-ff bug2fix1
Merge made by the 'recursive' strategy.
bug2fixDir/bug2FixFile1 | 4 ++--
bug2fixDir/bug2FixFile2 | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
AsusFred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git branch -d bug2fix1
Deleted branch bug2fix1 (was 96c462c).
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git push
Counting objects: 13, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (9/9), 857 bytes, done.
Total 9 (delta 3), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
3830e37..aa030f4 develop -> develop
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git hist
* aa030f4 2013-03-22 | Merge branch 'bug2fix1' into develop (HEAD,
origin/develop, develop) [Justin Mclean]
|\
| * 96c462c 2013-03-22 | bug2fix1: Fixed bug2fixFile2 (bug2fix1) [Justin
Mclean]
| * b931b4e 2013-03-22 | bug2fix1: Fixed bub2fixFile1 [Justin Mclean]
|/
* 3830e37 2013-03-22 | Merge branch 'bug2fix2' into develop [Justin
Mclean]
|\
| * 46f7fe0 2013-03-22 | bug2fix2: Fixed bug2fixFile1 [Justin Mclean]
|/
* fcb51d5 2013-03-22 | Renamed the file [Justin Mclean]
* 868fa15 2013-03-22 | prepared the bug2fix demo1 [Justin Mclean]
* 3cbafc4 2013-03-21 | Added fr_FR [Justin]
* c3058e9 2013-03-21 | Updated the README again [Frédéric THOMAS]
* 54072f3 2013-03-21 | Added pt_PT [Justin Mclean]
* f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
-- NOTHING DESTRUCTIVE, both of the bug histories have been preserved and
are clearly visible, for this demo, I didn't flaten the bug2fix2 to the
develop branch even though it has one commit, I would have done it in the
real live.
-----Message d'origine-----
From: Justin Mclean
Sent: Friday, March 22, 2013 2:56 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
Thanks for going though that.
> ---------------------------------
> You add locales
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
> test_Rebased_Hotfix_Without_Conflic
> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
etc etc
Actually it wasn't quite like that in that as files and directories already
existed. It does seem a bit excessive to make a branch just to change a
single file and it also assumes I have no other changes and a perfectly
clean tree (not the case). As the branch is local and not shared with anyone
else do you really need a branch for a simple change to a singe file?
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin
> develop
This is the bit I'm confused about why would I use --rebase when all
documentation I've read say it dangerous to use and it hard to undo (unlike
merge) and it difficult to see what it's going to do (no --dry-run) - I know
both of this situations have work arounds (mostly) but they are complex. It
seems to me that knowing what about to happen and being able to back out of
it if things go wrong is far more important than having a totally "clean"
history. It's not like the history produced was incorrect or even confusing.
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
> test_Rebased_Hotfix_Without_Conflic
Why is --no-ff required? What would happen if this option wasn't used in
this case? And if I didn't make the branch in the first place there would be
no need for this merge or the hard reset below right?
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
How do I know I need to do this? Would I need to do this every time?
I really don't want to have to work though obscure git options and issue a
dozen git commands just to check in a single fix to a single file. If we
have to do that then I think we are using the tools incorrectly or it's the
wrong tool for the job. IMO we need to make it as easy or easier than SVN to
use and add yet more complexity.
Thanks,
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi,
I'm happy you gone into this and less because I thought you already
understood why and when it is better and cleaner while it is safe to use
rebasing instead of merging but no problem, I'm going to try to explain it
again later.
1- Branching:
The point, in the example I provided was to illustrate how you should work
from a branch as branching and merging are cheap and are considered as a
standard developement workflow on Git, even if you work only on local
branches, the reason behind that is that you might discover another bug,
nothing relative to the one you're working on (but that impact the same
file(s)) and this new bug has a higher priority and then has to be fixed
now, making you stoping the dev of your current bug.
It's then better to fix it on another branch, doing do, it will be
availlable for the others as well as for you if you rebase your branch on it
(again, I will tell you later why it is safe to do so at this point).
If you have been working on the develop branch directly or on the branch
dedicated to the bug you was working on before, it would have not been clear
later in the paralelle history line of your bugfix why there's something not
relative to it, I made an example of this you can look at [1], as you will
see, there's nothing destructive using pull --rebase as soon as you
understand when, where and why to use it.
I hope with the last paragraph, I made clearer why working on a
feature/bugfix branch is better than on the develop branch.
Indeed, if you work with someone else, it makes the thing more obvious.
Note: If you apply a quick patch or the dev is only one line of code to
change and there are no tests to do, etc..., in this case, it's ok to do it
directly on the develop branch, taking the precaution of rebasing before
committing however.
2- Rebasing, merging, what, when, where and why :
Know something once and for ever: rebasing preserve a good history and is
not destructive until you didn't merge the branch you are working on and
didn't pushed it yet.
(and for the latter, you can always avoid it as soon as you follow the good
practices, see the conclusion).
Note, I explain with my words and my poor English :P
Let's start:
A- Rebasing:
a- What is rebasing:
Rebasing is the operation to get the others work rewriting YOUR commits on
top of them, it means you will never rewrite their history.
b- When rebasing:
Each time you know or you thing the branch you're based on changed or even
only when there is a significant amount of time you didn't do it.
c- Where and from where to rebase:
>From a branch: it means everywhere.
The From Where is depending if you are working on a local branch or a
tracked branch.
>From a local branch, you will like to rebase onto the branch your branch is
based from.
>From a tracked branch, same as before plus the same remote branch to track
what your mates did.
d- Finaly, WHY it works and it is not descrutive unless you don't follow the
good practice i'm explaining in this doc :
Because until you didn't merge and not pushed, there are no cases where
rebase will not preserve yours and the others history, it will put your work
on top of the others, if you/they did a merge and pushed it, this merge
still will be preserved.
B- Merging:
a- What is merging:
Merging is the operation to of joining 2 or more developement lines,
basicly, this operation will write your commits ahead of the current HEAD,
you can use the --no-ff flag to indicate you want an extra commit, the merge
commit, which will make your work easily reversed and will identify clearly
this work on the remote branch it will be pushed.
b- When merging:
Just before pushing, like that, you are preversed from the mad reads I see
on internet talking about the rebase risks.
c- Where merging:
>From the branch you want your feature/bugfix branch be merge.
d- Why merging :
I mean, the anwser is in the What.
C- Conclusion:
Reabase all the time, until you don't have a pending merge that is not
pushed.
But if you follow my guideline relative to the When merging, you should not
encounter this situation.
I hope those explanations anwser all of your questions, except maybe this
one:
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
How do I know I need to do this? Would I need to do this every time?
I really don't want to have to work though obscure git options and issue a
dozen git commands just to check in a single fix to a single file. If we
have to do that then I think we are using the tools incorrectly or it's the
wrong tool for the job. IMO we need to make it as easy or easier than SVN to
use and add yet more complexity.
In the context of the demo I did, it was to revert the timeline just before
the merge operation which did a no fast forward merge with the --no-ff flag,
causing the creation of a merge commit, I wanted to show you how to remove
it in case you decided you wanted a flat history at the end.
Thanks,
-Fred
[1]
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git checkout -b bug2fix1
Switched to a new branch 'bug2fix1'
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ ls bug2fixDir/
bug2FixFile1 bug2FixFile2
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ cat bug2fixDir/bug2FixFile1
This is the 1rst line
this is the 2nd line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ echo Bug2fix1 should fix the line1 writing first instead of 1rst > null
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ cat bug2fixDir/bug2FixFile1
This is the first line
this is the 2nd line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git commit -m "bug2fix1: Fixed bub2fixFile1" bug2fixDir/bug2FixFile1
[bug2fix1 51af745] bug2fix1: Fixed bub2fixFile1
1 file changed, 1 insertion(+), 1 deletion(-)
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ echo As you can see, there is the second line to fix as well but not plan
for this bug, so I open an other jira and f
ix it > nul
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git checkout develop
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 2 commits.
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git checkout -b bug2fix2
Switched to a new branch 'bug2fix2'
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ cat bug2fixDir/bug2FixFile1
This is the 1rst line
this is the 2nd line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ echo Fix the line 2 > nul
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ cat bug2fixDir/bug2FixFile1
This is the 1rst line
this is the second line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ git commit -m "bug2fix2: Fixed bug2fixFile1" bug2fixDir/bug2FixFile1
[bug2fix2 46f7fe0] bug2fix2: Fixed bug2fixFile1
1 file changed, 1 insertion(+), 1 deletion(-)
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix2)
$ git checkout develop
Switched to branch 'develop'
Your branch is ahead of 'origin/develop' by 2 commits.
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git merge --no-ff bug2fix2
Merge made by the 'recursive' strategy.
bug2fixDir/bug2FixFile1 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git branch -d bug2fix2
Deleted branch bug2fix2 (was 46f7fe0).
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git push
Counting objects: 14, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (13/13), 1.16 KiB, done.
Total 13 (delta 3), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
3cbafc4..3830e37 develop -> develop
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git checkout bug2fix1
Switched to branch 'bug2fix1'
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git pull --rebase origin develop
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: bug2fix1: Fixed bub2fixFile1
Using index info to reconstruct a base tree...
M bug2fixDir/bug2FixFile1
Falling back to patching base and 3-way merge...
Auto-merging bug2fixDir/bug2FixFile1
CONFLICT (content): Merge conflict in bug2fixDir/bug2FixFile1
Failed to merge in the changes.
Patch failed at 0001 bug2fix1: Fixed bub2fixFile1
The copy of the patch that failed is found in:
u:/gitLab/work/asf/flex/testWorkFlow/justin/.git/rebase-apply/patch
When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git
rebase --abort".
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
((3830e37...)|REBASE)
$ git mergetool bug2fixDir/bug2FixFile1
Merging:
bug2fixDir/bug2FixFile1
Normal merge conflict for 'bug2fixDir/bug2FixFile1':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (p4merge):
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
((3830e37...)|REBASE)
$ cat bug2fixDir/bug2FixFile1
This is the first line
this is the second line
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
((3830e37...)|REBASE)
$ echo it was a normal confict, I resolved it now, I am going to fix the
last file > nul
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin
((3830e37...)|REBASE)
$ git rebase --continue
Applying: bug2fix1: Fixed bub2fixFile1
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ echo Fixed this file > bug2fixDir/bug2FixFile2
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ cat bug2fixDir/bug2FixFile2
Fixed this file
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git status
# On branch bug2fix1
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: bug2fixDir/bug2FixFile2
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# bug2fixDir/bug2FixFile1.orig
no changes added to commit (use "git add" and/or "git commit -a")
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ rm bug2fixDir/bug2FixFile1.orig
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git status
# On branch bug2fix1
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
directory)
#
# modified: bug2fixDir/bug2FixFile2
#
no changes added to commit (use "git add" and/or "git commit -a")
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git commit -m "bug2fix1: Fixed bug2fixFile2" bug2fixDir/bug2FixFile2
1 file changed, 1 insertion(+)
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (bug2fix1)
$ git checkout develop
Switched to branch 'develop'
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git merge --no-ff bug2fix1
Merge made by the 'recursive' strategy.
bug2fixDir/bug2FixFile1 | 4 ++--
bug2fixDir/bug2FixFile2 | 1 +
2 files changed, 3 insertions(+), 2 deletions(-)
AsusFred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git branch -d bug2fix1
Deleted branch bug2fix1 (was 96c462c).
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git push
Counting objects: 13, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (9/9), 857 bytes, done.
Total 9 (delta 3), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
3830e37..aa030f4 develop -> develop
Fred@ASUSFRED-PC /u/gitLab/work/asf/flex/testWorkFlow/justin (develop)
$ git hist
* aa030f4 2013-03-22 | Merge branch 'bug2fix1' into develop (HEAD,
origin/develop, develop) [Justin Mclean]
|\
| * 96c462c 2013-03-22 | bug2fix1: Fixed bug2fixFile2 (bug2fix1) [Justin
Mclean]
| * b931b4e 2013-03-22 | bug2fix1: Fixed bub2fixFile1 [Justin Mclean]
|/
* 3830e37 2013-03-22 | Merge branch 'bug2fix2' into develop [Justin
Mclean]
|\
| * 46f7fe0 2013-03-22 | bug2fix2: Fixed bug2fixFile1 [Justin Mclean]
|/
* fcb51d5 2013-03-22 | Renamed the file [Justin Mclean]
* 868fa15 2013-03-22 | prepared the bug2fix demo1 [Justin Mclean]
* 3cbafc4 2013-03-21 | Added fr_FR [Justin]
* c3058e9 2013-03-21 | Updated the README again [Frédéric THOMAS]
* 54072f3 2013-03-21 | Added pt_PT [Justin Mclean]
* f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
-- NOTHING DESTRUCTIVE, both of the bug histories have been preserved and
are clearly visible, for this demo, I didn't flaten the bug2fix2 to the
develop branch even though it has one commit, I would have done it in the
real live.
-----Message d'origine-----
From: Justin Mclean
Sent: Friday, March 22, 2013 2:56 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
Thanks for going though that.
> ---------------------------------
> You add locales
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
> test_Rebased_Hotfix_Without_Conflic
> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
etc etc
Actually it wasn't quite like that in that as files and directories already
existed. It does seem a bit excessive to make a branch just to change a
single file and it also assumes I have no other changes and a perfectly
clean tree (not the case). As the branch is local and not shared with anyone
else do you really need a branch for a simple change to a singe file?
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin
> develop
This is the bit I'm confused about why would I use --rebase when all
documentation I've read say it dangerous to use and it hard to undo (unlike
merge) and it difficult to see what it's going to do (no --dry-run) - I know
both of this situations have work arounds (mostly) but they are complex. It
seems to me that knowing what about to happen and being able to back out of
it if things go wrong is far more important than having a totally "clean"
history. It's not like the history produced was incorrect or even confusing.
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
> test_Rebased_Hotfix_Without_Conflic
Why is --no-ff required? What would happen if this option wasn't used in
this case? And if I didn't make the branch in the first place there would be
no need for this merge or the hard reset below right?
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
How do I know I need to do this? Would I need to do this every time?
I really don't want to have to work though obscure git options and issue a
dozen git commands just to check in a single fix to a single file. If we
have to do that then I think we are using the tools incorrectly or it's the
wrong tool for the job. IMO we need to make it as easy or easier than SVN to
use and add yet more complexity.
Thanks,
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
Thanks for going though that.
> ---------------------------------
> You add locales
> ---------------------------------
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b test_Rebased_Hotfix_Without_Conflic
> Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
etc etc
Actually it wasn't quite like that in that as files and directories already existed. It does seem a bit excessive to make a branch just to change a single file and it also assumes I have no other changes and a perfectly clean tree (not the case). As the branch is local and not shared with anyone else do you really need a branch for a simple change to a singe file?
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop
This is the bit I'm confused about why would I use --rebase when all documentation I've read say it dangerous to use and it hard to undo (unlike merge) and it difficult to see what it's going to do (no --dry-run) - I know both of this situations have work arounds (mostly) but they are complex. It seems to me that knowing what about to happen and being able to back out of it if things go wrong is far more important than having a totally "clean" history. It's not like the history produced was incorrect or even confusing.
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff test_Rebased_Hotfix_Without_Conflic
Why is --no-ff required? What would happen if this option wasn't used in this case? And if I didn't make the branch in the first place there would be no need for this merge or the hard reset below right?
> U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
How do I know I need to do this? Would I need to do this every time?
I really don't want to have to work though obscure git options and issue a dozen git commands just to check in a single fix to a single file. If we have to do that then I think we are using the tools incorrectly or it's the wrong tool for the job. IMO we need to make it as easy or easier than SVN to use and add yet more complexity.
Thanks,
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
until it exists, yep.
-Fred
-----Message d'origine-----
From: Gordon Smith
Sent: Thursday, March 21, 2013 10:31 PM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
When a remote repo is cloned to make a local repo, doing 'git pull' in a
particular branch of the local repo pulls from the corresponding branch in
the remote depo?
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 2:21 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
It is not linked to the justin repo but as we have a remote one, I created
the same kind of repo that I called flex-sdk.git, it's what is called a bare
repo, you can do it creating first a draft repo with at least one file on
each branch you want inside and then use git clone --bare myDraftRepo
flex-sdk.git, you can then remove your draft repo and clone as much as repo
you want, they will have their origin pointing to the remote one.
-Fred
-----Message d'origine-----
From: Gordon Smith
Sent: Thursday, March 21, 2013 10:06 PM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
OK, my next conceptual problem is at
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current
> branch develop is up to date.
I assume this is pulling from justin's develop branch into fred's develop
branch. But how did this relationship get established? Was the fred repo
cloned from the Justin repo? Is there some other way to establish where a
'pull' pulls from?
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 2:02 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Sorry, true, I tried to not using my aliases to demonstrate but I forgot
about that one, copy [1] in your .gitconfig
-Fred
[1]
[alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --pretty=format:\"%h %ad | %s%d
[%an]\" --graph --date=short --decorate
type = cat-file -t
dump = cat-file -p
-----Message d'origine-----
From: Gordon Smith
Sent: Thursday, March 21, 2013 9:58 PM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
I followed this only up to the point you did 'git hist'. My git (1.7.12.4)
has no such command.
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 6:55 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Justin, coming back to your first commit, I want to show you the different
possibilities you had, I used my git lab to do that, it's like you have a
computer and me too.
U:\gitLab\work\asf\flex\testWorkFlow\justin>git branch
* develop
master
---------------------------------
You add locales
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
test_Rebased_Hotfix_Without_Conflic
Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
U:\gitLab\work\asf\flex\testWorkFlow\justin>md locales
U:\gitLab\work\asf\flex\testWorkFlow\justin>cd locales
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>copy /y nul >
pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>echo "some portugues" >
pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git add .
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git commit -m "Added
pt_PT"
[test_Rebased_Hotfix_Without_Conflic b05fdd8] Added pt_PT
1 file changed, 1 insertion(+)
create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git hist
* b05fdd8 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
In between, Fred updated the README
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git branch
* develop
master
U:\gitLab\work\asf\flex\testWorkFlow\fred>echo "Updated README" >> README
U:\gitLab\work\asf\flex\testWorkFlow\fred>type README This file is supposed
to be updated once this repository has been copied."Updated README"
U:\gitLab\work\asf\flex\testWorkFlow\fred>git add .
U:\gitLab\work\asf\flex\testWorkFlow\fred>git commit -m "Updated the README"
[develop f43029d] Updated the README
1 file changed, 1 insertion(+), 1 deletion(-)
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/develop, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current branch
develop is up to date.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git push Counting objects: 5,
done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 303 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
1032fa2..f43029d develop -> develop
---------------------------------
You get the newest changes
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Added pt_PT
---------------------------------
Look, that's the state you're going to have on the remote if you do:
git merge test_Rebased_Hotfix_Without_Conflic
git push
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
But here, if you decide to let the others know the all work you did on this
branch, we do a merge without fast forward.
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
test_Rebased_Hotfix_Without_Conflic
Merge made by the 'recursive' strategy.
README | 2 +-
locales/pt_PT.properties | 1 +
2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644
locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 5cd6098 2013-03-21 | Merge branch 'test_Rebased_Hotfix_Without_Conflic'
into develop (HEAD, develop) [Justin]
|\
| * 54072f3 2013-03-21 | Added pt_PT
|(test_Rebased_Hotfix_Without_Conflic)
[Justin]
| * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
THOMAS]
|/
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
---------------------------------
But actually, because it was a simple commit, you revert your merge to have
a flat history and push it
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3 HEAD is
now at 54072f3 Added pt_PT
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic, develop) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\justin>git push Counting objects: 5,
done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 351 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
f43029d..54072f3 develop -> develop
---------------------------------
On my machine, I update and I see a clean ordered history
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (4/4),
done.
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
f43029d..54072f3 develop -> origin/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded develop to 54072f3f207612429d525c6854632b265996bf9e.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop) [Justin]
* f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
RE: [OT] Log history
Posted by Gordon Smith <go...@adobe.com>.
When a remote repo is cloned to make a local repo, doing 'git pull' in a particular branch of the local repo pulls from the corresponding branch in the remote depo?
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 2:21 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
It is not linked to the justin repo but as we have a remote one, I created the same kind of repo that I called flex-sdk.git, it's what is called a bare repo, you can do it creating first a draft repo with at least one file on each branch you want inside and then use git clone --bare myDraftRepo flex-sdk.git, you can then remove your draft repo and clone as much as repo you want, they will have their origin pointing to the remote one.
-Fred
-----Message d'origine-----
From: Gordon Smith
Sent: Thursday, March 21, 2013 10:06 PM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
OK, my next conceptual problem is at
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current
> branch develop is up to date.
I assume this is pulling from justin's develop branch into fred's develop branch. But how did this relationship get established? Was the fred repo cloned from the Justin repo? Is there some other way to establish where a 'pull' pulls from?
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 2:02 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Sorry, true, I tried to not using my aliases to demonstrate but I forgot about that one, copy [1] in your .gitconfig
-Fred
[1]
[alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short --decorate
type = cat-file -t
dump = cat-file -p
-----Message d'origine-----
From: Gordon Smith
Sent: Thursday, March 21, 2013 9:58 PM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
I followed this only up to the point you did 'git hist'. My git (1.7.12.4) has no such command.
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 6:55 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Justin, coming back to your first commit, I want to show you the different possibilities you had, I used my git lab to do that, it's like you have a computer and me too.
U:\gitLab\work\asf\flex\testWorkFlow\justin>git branch
* develop
master
---------------------------------
You add locales
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b test_Rebased_Hotfix_Without_Conflic
Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
U:\gitLab\work\asf\flex\testWorkFlow\justin>md locales
U:\gitLab\work\asf\flex\testWorkFlow\justin>cd locales
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>copy /y nul > pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>echo "some portugues" > pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git add .
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git commit -m "Added pt_PT"
[test_Rebased_Hotfix_Without_Conflic b05fdd8] Added pt_PT
1 file changed, 1 insertion(+)
create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git hist
* b05fdd8 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
In between, Fred updated the README
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git branch
* develop
master
U:\gitLab\work\asf\flex\testWorkFlow\fred>echo "Updated README" >> README
U:\gitLab\work\asf\flex\testWorkFlow\fred>type README This file is supposed to be updated once this repository has been copied."Updated README"
U:\gitLab\work\asf\flex\testWorkFlow\fred>git add .
U:\gitLab\work\asf\flex\testWorkFlow\fred>git commit -m "Updated the README"
[develop f43029d] Updated the README
1 file changed, 1 insertion(+), 1 deletion(-)
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/develop, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current branch develop is up to date.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git push Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 303 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
1032fa2..f43029d develop -> develop
---------------------------------
You get the newest changes
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Added pt_PT
---------------------------------
Look, that's the state you're going to have on the remote if you do:
git merge test_Rebased_Hotfix_Without_Conflic
git push
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
But here, if you decide to let the others know the all work you did on this branch, we do a merge without fast forward.
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff test_Rebased_Hotfix_Without_Conflic
Merge made by the 'recursive' strategy.
README | 2 +-
locales/pt_PT.properties | 1 +
2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 5cd6098 2013-03-21 | Merge branch 'test_Rebased_Hotfix_Without_Conflic'
into develop (HEAD, develop) [Justin]
|\
| * 54072f3 2013-03-21 | Added pt_PT
|(test_Rebased_Hotfix_Without_Conflic)
[Justin]
| * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
THOMAS]
|/
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master) [Frédéric THOMAS]
---------------------------------
But actually, because it was a simple commit, you revert your merge to have a flat history and push it
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3 HEAD is now at 54072f3 Added pt_PT
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, test_Rebased_Hotfix_Without_Conflic, develop) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\justin>git push Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 351 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
f43029d..54072f3 develop -> develop
---------------------------------
On my machine, I update and I see a clean ordered history
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (4/4), done.
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
f43029d..54072f3 develop -> origin/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded develop to 54072f3f207612429d525c6854632b265996bf9e.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop) [Justin]
* f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master) [Frédéric THOMAS]
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
It is not linked to the justin repo but as we have a remote one, I created
the same kind of repo that I called flex-sdk.git, it's what is called a bare
repo, you can do it creating first a draft repo with at least one file on
each branch you want inside and then use git clone --bare myDraftRepo
flex-sdk.git, you can then remove your draft repo and clone as much as repo
you want, they will have their origin pointing to the remote one.
-Fred
-----Message d'origine-----
From: Gordon Smith
Sent: Thursday, March 21, 2013 10:06 PM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
OK, my next conceptual problem is at
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current branch
> develop is up to date.
I assume this is pulling from justin's develop branch into fred's develop
branch. But how did this relationship get established? Was the fred repo
cloned from the Justin repo? Is there some other way to establish where a
'pull' pulls from?
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 2:02 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Sorry, true, I tried to not using my aliases to demonstrate but I forgot
about that one, copy [1] in your .gitconfig
-Fred
[1]
[alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --pretty=format:\"%h %ad | %s%d
[%an]\" --graph --date=short --decorate
type = cat-file -t
dump = cat-file -p
-----Message d'origine-----
From: Gordon Smith
Sent: Thursday, March 21, 2013 9:58 PM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
I followed this only up to the point you did 'git hist'. My git (1.7.12.4)
has no such command.
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 6:55 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Justin, coming back to your first commit, I want to show you the different
possibilities you had, I used my git lab to do that, it's like you have a
computer and me too.
U:\gitLab\work\asf\flex\testWorkFlow\justin>git branch
* develop
master
---------------------------------
You add locales
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
test_Rebased_Hotfix_Without_Conflic
Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
U:\gitLab\work\asf\flex\testWorkFlow\justin>md locales
U:\gitLab\work\asf\flex\testWorkFlow\justin>cd locales
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>copy /y nul >
pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>echo "some portugues" >
pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git add .
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git commit -m "Added
pt_PT"
[test_Rebased_Hotfix_Without_Conflic b05fdd8] Added pt_PT
1 file changed, 1 insertion(+)
create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git hist
* b05fdd8 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
In between, Fred updated the README
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git branch
* develop
master
U:\gitLab\work\asf\flex\testWorkFlow\fred>echo "Updated README" >> README
U:\gitLab\work\asf\flex\testWorkFlow\fred>type README This file is supposed
to be updated once this repository has been copied."Updated README"
U:\gitLab\work\asf\flex\testWorkFlow\fred>git add .
U:\gitLab\work\asf\flex\testWorkFlow\fred>git commit -m "Updated the README"
[develop f43029d] Updated the README
1 file changed, 1 insertion(+), 1 deletion(-)
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/develop, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current branch
develop is up to date.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git push Counting objects: 5,
done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 303 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
1032fa2..f43029d develop -> develop
---------------------------------
You get the newest changes
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Added pt_PT
---------------------------------
Look, that's the state you're going to have on the remote if you do:
git merge test_Rebased_Hotfix_Without_Conflic
git push
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
But here, if you decide to let the others know the all work you did on this
branch, we do a merge without fast forward.
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
test_Rebased_Hotfix_Without_Conflic
Merge made by the 'recursive' strategy.
README | 2 +-
locales/pt_PT.properties | 1 +
2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644
locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 5cd6098 2013-03-21 | Merge branch 'test_Rebased_Hotfix_Without_Conflic'
into develop (HEAD, develop) [Justin]
|\
| * 54072f3 2013-03-21 | Added pt_PT
|(test_Rebased_Hotfix_Without_Conflic)
[Justin]
| * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
THOMAS]
|/
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
---------------------------------
But actually, because it was a simple commit, you revert your merge to have
a flat history and push it
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3 HEAD is
now at 54072f3 Added pt_PT
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic, develop) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\justin>git push Counting objects: 5,
done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 351 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
f43029d..54072f3 develop -> develop
---------------------------------
On my machine, I update and I see a clean ordered history
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (4/4),
done.
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
f43029d..54072f3 develop -> origin/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded develop to 54072f3f207612429d525c6854632b265996bf9e.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop) [Justin]
* f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
RE: [OT] Log history
Posted by Gordon Smith <go...@adobe.com>.
OK, my next conceptual problem is at
> U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current branch develop is up to date.
I assume this is pulling from justin's develop branch into fred's develop branch. But how did this relationship get established? Was the fred repo cloned from the Justin repo? Is there some other way to establish where a 'pull' pulls from?
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 2:02 PM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Sorry, true, I tried to not using my aliases to demonstrate but I forgot about that one, copy [1] in your .gitconfig
-Fred
[1]
[alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short --decorate
type = cat-file -t
dump = cat-file -p
-----Message d'origine-----
From: Gordon Smith
Sent: Thursday, March 21, 2013 9:58 PM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
I followed this only up to the point you did 'git hist'. My git (1.7.12.4) has no such command.
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 6:55 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Justin, coming back to your first commit, I want to show you the different possibilities you had, I used my git lab to do that, it's like you have a computer and me too.
U:\gitLab\work\asf\flex\testWorkFlow\justin>git branch
* develop
master
---------------------------------
You add locales
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b test_Rebased_Hotfix_Without_Conflic
Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
U:\gitLab\work\asf\flex\testWorkFlow\justin>md locales
U:\gitLab\work\asf\flex\testWorkFlow\justin>cd locales
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>copy /y nul > pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>echo "some portugues" > pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git add .
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git commit -m "Added pt_PT"
[test_Rebased_Hotfix_Without_Conflic b05fdd8] Added pt_PT
1 file changed, 1 insertion(+)
create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git hist
* b05fdd8 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
In between, Fred updated the README
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git branch
* develop
master
U:\gitLab\work\asf\flex\testWorkFlow\fred>echo "Updated README" >> README
U:\gitLab\work\asf\flex\testWorkFlow\fred>type README This file is supposed to be updated once this repository has been copied."Updated README"
U:\gitLab\work\asf\flex\testWorkFlow\fred>git add .
U:\gitLab\work\asf\flex\testWorkFlow\fred>git commit -m "Updated the README"
[develop f43029d] Updated the README
1 file changed, 1 insertion(+), 1 deletion(-)
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/develop, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current branch develop is up to date.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git push Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 303 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
1032fa2..f43029d develop -> develop
---------------------------------
You get the newest changes
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Added pt_PT
---------------------------------
Look, that's the state you're going to have on the remote if you do:
git merge test_Rebased_Hotfix_Without_Conflic
git push
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
But here, if you decide to let the others know the all work you did on this branch, we do a merge without fast forward.
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff test_Rebased_Hotfix_Without_Conflic
Merge made by the 'recursive' strategy.
README | 2 +-
locales/pt_PT.properties | 1 +
2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 5cd6098 2013-03-21 | Merge branch 'test_Rebased_Hotfix_Without_Conflic'
into develop (HEAD, develop) [Justin]
|\
| * 54072f3 2013-03-21 | Added pt_PT
|(test_Rebased_Hotfix_Without_Conflic)
[Justin]
| * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
THOMAS]
|/
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master) [Frédéric THOMAS]
---------------------------------
But actually, because it was a simple commit, you revert your merge to have a flat history and push it
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3 HEAD is now at 54072f3 Added pt_PT
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, test_Rebased_Hotfix_Without_Conflic, develop) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\justin>git push Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 351 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
f43029d..54072f3 develop -> develop
---------------------------------
On my machine, I update and I see a clean ordered history
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (4/4), done.
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
f43029d..54072f3 develop -> origin/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded develop to 54072f3f207612429d525c6854632b265996bf9e.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop) [Justin]
* f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master) [Frédéric THOMAS]
Re: [OT] Log history
Posted by Om <bi...@gmail.com>.
On Thu, Mar 21, 2013 at 2:02 PM, Frédéric THOMAS <we...@hotmail.com>wrote:
> Sorry, true, I tried to not using my aliases to demonstrate but I forgot
> about that one, copy [1] in your .gitconfig
>
> -Fred
>
> [1]
>
> [alias]
> co = checkout
> ci = commit
> st = status
> br = branch
> hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
> --decorate
> type = cat-file -t
> dump = cat-file -p
>
>
This should go in the WIKI as an optional set up note.
Thanks,
Om
> -----Message d'origine----- From: Gordon Smith
> Sent: Thursday, March 21, 2013 9:58 PM
> To: dev@flex.apache.org
> Subject: RE: [OT] Log history
>
>
> I followed this only up to the point you did 'git hist'. My git (1.7.12.4)
> has no such command.
>
> - Gordon
>
> -----Original Message-----
> From: Frédéric THOMAS [mailto:webdoublefx@hotmail.**com<we...@hotmail.com>
> ]
> Sent: Thursday, March 21, 2013 6:55 AM
> To: dev@flex.apache.org
> Subject: Re: [OT] Log history
>
> Justin, coming back to your first commit, I want to show you the different
> possibilities you had, I used my git lab to do that, it's like you have a
> computer and me too.
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>git branch
> * develop
> master
>
> ------------------------------**---
> You add locales
> ------------------------------**---
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>git checkout -b
> test_Rebased_Hotfix_Without_**Conflic
> Switched to a new branch 'test_Rebased_Hotfix_Without_**Conflic'
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>md locales
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>cd locales
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin\locales>**copy /y nul >
> pt_PT.properties
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin\locales>**echo "some
> portugues" > pt_PT.properties
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin\locales>**git add .
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin\locales>**git commit -m
> "Added pt_PT"
> [test_Rebased_Hotfix_Without_**Conflic b05fdd8] Added pt_PT
> 1 file changed, 1 insertion(+)
> create mode 100644 locales/pt_PT.properties
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin\locales>**git hist
> * b05fdd8 2013-03-21 | Added pt_PT (HEAD,
> test_Rebased_Hotfix_Without_**Conflic) [Justin]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
>
> ------------------------------**---
> In between, Fred updated the README
> ------------------------------**---
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>git branch
> * develop
> master
>
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>echo "Updated README" >>
> README
>
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>type README This file is
> supposed to be updated once this repository has been copied."Updated README"
>
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>git add .
>
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>git commit -m "Updated the
> README"
> [develop f43029d] Updated the README
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>git hist
> * f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/develop, origin/HEAD, master) [Frédéric THOMAS]
>
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>git pull --rebase Current
> branch develop is up to date.
>
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>git push Counting objects: 5,
> done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 303 bytes, done.
> Total 3 (delta 1), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/**testWorkFlow/..\flex-sdk.git
> 1032fa2..f43029d develop -> develop
>
> ------------------------------**---
> You get the newest changes
> ------------------------------**---
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>git pull --rebase origin
> develop From U:/gitLab/work/asf/flex/**testWorkFlow/..\flex-sdk
> * branch develop -> FETCH_HEAD
> First, rewinding head to replay your work on top of it...
> Applying: Added pt_PT
>
> ------------------------------**---
> Look, that's the state you're going to have on the remote if you do:
> git merge test_Rebased_Hotfix_Without_**Conflic
> git push
> ------------------------------**---
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>git hist
> * 54072f3 2013-03-21 | Added pt_PT (HEAD,
> test_Rebased_Hotfix_Without_**Conflic) [Justin]
> * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
> THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master, develop) [Frédéric THOMAS]
>
> ------------------------------**---
> But here, if you decide to let the others know the all work you did on
> this branch, we do a merge without fast forward.
> ------------------------------**---
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>git merge --no-ff
> test_Rebased_Hotfix_Without_**Conflic
> Merge made by the 'recursive' strategy.
> README | 2 +-
> locales/pt_PT.properties | 1 +
> 2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644
> locales/pt_PT.properties
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>git hist
> * 5cd6098 2013-03-21 | Merge branch 'test_Rebased_Hotfix_Without_**
> Conflic'
> into develop (HEAD, develop) [Justin]
> |\
> | * 54072f3 2013-03-21 | Added pt_PT
> |(test_Rebased_Hotfix_Without_**Conflic)
> [Justin]
> | * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
> THOMAS]
> |/
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
> ------------------------------**---
> But actually, because it was a simple commit, you revert your merge to
> have a flat history and push it
> ------------------------------**---
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>git reset --hard 54072f3
> HEAD is now at 54072f3 Added pt_PT
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>git hist
> * 54072f3 2013-03-21 | Added pt_PT (HEAD, test_Rebased_Hotfix_Without_**Conflic,
> develop) [Justin]
> * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
> THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
> U:\gitLab\work\asf\flex\**testWorkFlow\justin>git push Counting objects:
> 5, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (4/4), 351 bytes, done.
> Total 4 (delta 0), reused 0 (delta 0)
> To U:/gitLab/work/asf/flex/**testWorkFlow/..\flex-sdk.git
> f43029d..54072f3 develop -> develop
>
> ------------------------------**---
> On my machine, I update and I see a clean ordered history
> ------------------------------**---
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>git pull --rebase
> remote: Counting objects: 5, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100%
> (4/4), done.
> From U:/gitLab/work/asf/flex/**testWorkFlow/..\flex-sdk
> f43029d..54072f3 develop -> origin/develop
> First, rewinding head to replay your work on top of it...
> Fast-forwarded develop to 54072f3f207612429d525c6854632b**265996bf9e.
>
> U:\gitLab\work\asf\flex\**testWorkFlow\fred>git hist
> * 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop) [Justin]
> * f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
> * 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
> origin/HEAD, master) [Frédéric THOMAS]
>
>
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Sorry, true, I tried to not using my aliases to demonstrate but I forgot
about that one, copy [1] in your .gitconfig
-Fred
[1]
[alias]
co = checkout
ci = commit
st = status
br = branch
hist = log --pretty=format:\"%h %ad | %s%d
[%an]\" --graph --date=short --decorate
type = cat-file -t
dump = cat-file -p
-----Message d'origine-----
From: Gordon Smith
Sent: Thursday, March 21, 2013 9:58 PM
To: dev@flex.apache.org
Subject: RE: [OT] Log history
I followed this only up to the point you did 'git hist'. My git (1.7.12.4)
has no such command.
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 6:55 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Justin, coming back to your first commit, I want to show you the different
possibilities you had, I used my git lab to do that, it's like you have a
computer and me too.
U:\gitLab\work\asf\flex\testWorkFlow\justin>git branch
* develop
master
---------------------------------
You add locales
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
test_Rebased_Hotfix_Without_Conflic
Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
U:\gitLab\work\asf\flex\testWorkFlow\justin>md locales
U:\gitLab\work\asf\flex\testWorkFlow\justin>cd locales
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>copy /y nul >
pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>echo "some portugues" >
pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git add .
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git commit -m "Added
pt_PT"
[test_Rebased_Hotfix_Without_Conflic b05fdd8] Added pt_PT
1 file changed, 1 insertion(+)
create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git hist
* b05fdd8 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
In between, Fred updated the README
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git branch
* develop
master
U:\gitLab\work\asf\flex\testWorkFlow\fred>echo "Updated README" >> README
U:\gitLab\work\asf\flex\testWorkFlow\fred>type README This file is supposed
to be updated once this repository has been copied."Updated README"
U:\gitLab\work\asf\flex\testWorkFlow\fred>git add .
U:\gitLab\work\asf\flex\testWorkFlow\fred>git commit -m "Updated the README"
[develop f43029d] Updated the README
1 file changed, 1 insertion(+), 1 deletion(-)
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/develop, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current branch
develop is up to date.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git push Counting objects: 5,
done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 303 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
1032fa2..f43029d develop -> develop
---------------------------------
You get the newest changes
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Added pt_PT
---------------------------------
Look, that's the state you're going to have on the remote if you do:
git merge test_Rebased_Hotfix_Without_Conflic
git push
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
But here, if you decide to let the others know the all work you did on this
branch, we do a merge without fast forward.
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
test_Rebased_Hotfix_Without_Conflic
Merge made by the 'recursive' strategy.
README | 2 +-
locales/pt_PT.properties | 1 +
2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644
locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 5cd6098 2013-03-21 | Merge branch 'test_Rebased_Hotfix_Without_Conflic'
into develop (HEAD, develop) [Justin]
|\
| * 54072f3 2013-03-21 | Added pt_PT
|(test_Rebased_Hotfix_Without_Conflic)
[Justin]
| * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
THOMAS]
|/
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
---------------------------------
But actually, because it was a simple commit, you revert your merge to have
a flat history and push it
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3 HEAD is
now at 54072f3 Added pt_PT
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic, develop) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\justin>git push Counting objects: 5,
done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 351 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
f43029d..54072f3 develop -> develop
---------------------------------
On my machine, I update and I see a clean ordered history
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (4/4),
done.
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
f43029d..54072f3 develop -> origin/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded develop to 54072f3f207612429d525c6854632b265996bf9e.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop) [Justin]
* f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
RE: [OT] Log history
Posted by Gordon Smith <go...@adobe.com>.
I followed this only up to the point you did 'git hist'. My git (1.7.12.4) has no such command.
- Gordon
-----Original Message-----
From: Frédéric THOMAS [mailto:webdoublefx@hotmail.com]
Sent: Thursday, March 21, 2013 6:55 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Justin, coming back to your first commit, I want to show you the different possibilities you had, I used my git lab to do that, it's like you have a computer and me too.
U:\gitLab\work\asf\flex\testWorkFlow\justin>git branch
* develop
master
---------------------------------
You add locales
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b test_Rebased_Hotfix_Without_Conflic
Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
U:\gitLab\work\asf\flex\testWorkFlow\justin>md locales
U:\gitLab\work\asf\flex\testWorkFlow\justin>cd locales
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>copy /y nul > pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>echo "some portugues" > pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git add .
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git commit -m "Added pt_PT"
[test_Rebased_Hotfix_Without_Conflic b05fdd8] Added pt_PT
1 file changed, 1 insertion(+)
create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git hist
* b05fdd8 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
In between, Fred updated the README
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git branch
* develop
master
U:\gitLab\work\asf\flex\testWorkFlow\fred>echo "Updated README" >> README
U:\gitLab\work\asf\flex\testWorkFlow\fred>type README This file is supposed to be updated once this repository has been copied."Updated README"
U:\gitLab\work\asf\flex\testWorkFlow\fred>git add .
U:\gitLab\work\asf\flex\testWorkFlow\fred>git commit -m "Updated the README"
[develop f43029d] Updated the README
1 file changed, 1 insertion(+), 1 deletion(-)
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/develop, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase Current branch develop is up to date.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git push Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 303 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
1032fa2..f43029d develop -> develop
---------------------------------
You get the newest changes
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Added pt_PT
---------------------------------
Look, that's the state you're going to have on the remote if you do:
git merge test_Rebased_Hotfix_Without_Conflic
git push
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
But here, if you decide to let the others know the all work you did on this branch, we do a merge without fast forward.
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff test_Rebased_Hotfix_Without_Conflic
Merge made by the 'recursive' strategy.
README | 2 +-
locales/pt_PT.properties | 1 +
2 files changed, 2 insertions(+), 1 deletion(-) create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 5cd6098 2013-03-21 | Merge branch 'test_Rebased_Hotfix_Without_Conflic'
into develop (HEAD, develop) [Justin]
|\
| * 54072f3 2013-03-21 | Added pt_PT
|(test_Rebased_Hotfix_Without_Conflic)
[Justin]
| * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
THOMAS]
|/
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master) [Frédéric THOMAS]
---------------------------------
But actually, because it was a simple commit, you revert your merge to have a flat history and push it
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3 HEAD is now at 54072f3 Added pt_PT
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, test_Rebased_Hotfix_Without_Conflic, develop) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\justin>git push Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 351 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
f43029d..54072f3 develop -> develop
---------------------------------
On my machine, I update and I see a clean ordered history
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (4/4), done.
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
f43029d..54072f3 develop -> origin/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded develop to 54072f3f207612429d525c6854632b265996bf9e.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop) [Justin]
* f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master, origin/HEAD, master) [Frédéric THOMAS]
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Justin, coming back to your first commit, I want to show you the different
possibilities you had, I used my git lab to do that, it's like you have a
computer and me too.
U:\gitLab\work\asf\flex\testWorkFlow\justin>git branch
* develop
master
---------------------------------
You add locales
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git checkout -b
test_Rebased_Hotfix_Without_Conflic
Switched to a new branch 'test_Rebased_Hotfix_Without_Conflic'
U:\gitLab\work\asf\flex\testWorkFlow\justin>md locales
U:\gitLab\work\asf\flex\testWorkFlow\justin>cd locales
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>copy /y nul >
pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>echo "some portugues" >
pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git add .
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git commit -m "Added
pt_PT"
[test_Rebased_Hotfix_Without_Conflic b05fdd8] Added pt_PT
1 file changed, 1 insertion(+)
create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin\locales>git hist
* b05fdd8 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/develop, origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
In between, Fred updated the README
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git branch
* develop
master
U:\gitLab\work\asf\flex\testWorkFlow\fred>echo "Updated README" >> README
U:\gitLab\work\asf\flex\testWorkFlow\fred>type README
This file is supposed to be updated once this repository has been
copied."Updated README"
U:\gitLab\work\asf\flex\testWorkFlow\fred>git add .
U:\gitLab\work\asf\flex\testWorkFlow\fred>git commit -m "Updated the README"
[develop f43029d] Updated the README
1 file changed, 1 insertion(+), 1 deletion(-)
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* f43029d 2013-03-21 | Updated the README (HEAD, develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/develop, origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
Current branch develop is up to date.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 303 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
1032fa2..f43029d develop -> develop
---------------------------------
You get the newest changes
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git pull --rebase origin develop
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Added pt_PT
---------------------------------
Look, that's the state you're going to have on the remote if you do:
git merge test_Rebased_Hotfix_Without_Conflic
git push
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master, develop) [Frédéric THOMAS]
---------------------------------
But here, if you decide to let the others know the all work you did on this
branch, we do a merge without fast forward.
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git merge --no-ff
test_Rebased_Hotfix_Without_Conflic
Merge made by the 'recursive' strategy.
README | 2 +-
locales/pt_PT.properties | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
create mode 100644 locales/pt_PT.properties
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 5cd6098 2013-03-21 | Merge branch 'test_Rebased_Hotfix_Without_Conflic'
into develop (HEAD, develop) [Justin]
|\
| * 54072f3 2013-03-21 | Added pt_PT (test_Rebased_Hotfix_Without_Conflic)
[Justin]
| * f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric
THOMAS]
|/
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
---------------------------------
But actually, because it was a simple commit, you revert your merge to have
a flat history and push it
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\justin>git reset --hard 54072f3
HEAD is now at 54072f3 Added pt_PT
U:\gitLab\work\asf\flex\testWorkFlow\justin>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD,
test_Rebased_Hotfix_Without_Conflic, develop) [Justin]
* f43029d 2013-03-21 | Updated the README (origin/develop) [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
U:\gitLab\work\asf\flex\testWorkFlow\justin>git push
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 351 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)
To U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk.git
f43029d..54072f3 develop -> develop
---------------------------------
On my machine, I update and I see a clean ordered history
---------------------------------
U:\gitLab\work\asf\flex\testWorkFlow\fred>git pull --rebase
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (4/4), done.
>From U:/gitLab/work/asf/flex/testWorkFlow/..\flex-sdk
f43029d..54072f3 develop -> origin/develop
First, rewinding head to replay your work on top of it...
Fast-forwarded develop to 54072f3f207612429d525c6854632b265996bf9e.
U:\gitLab\work\asf\flex\testWorkFlow\fred>git hist
* 54072f3 2013-03-21 | Added pt_PT (HEAD, origin/develop, develop) [Justin]
* f43029d 2013-03-21 | Updated the README [Frédéric THOMAS]
* 1032fa2 2013-03-21 | Added README (origin/release, origin/master,
origin/HEAD, master) [Frédéric THOMAS]
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
You can add [1] to your .gitconfig to have per branch refrog in all of your
repos, but personaly, I don't had to use it, the git reflog gives all git
operations done, included in branches.
Note: with the workflow I gave on the wiki, such situation shouldn't happen,
especialy because, we don't do complicated things.
Thanks,
-Fred
[1]->
[user]
logallrefupdates=true
-----Message d'origine-----
From: Justin Mclean
Sent: Thursday, March 21, 2013 11:02 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
> I had a quick look at the 1rst one, this anwser is the good one to me.
Yep but it doesn't work in all cases.
> If you've enabled per branch reflogs
How do you do this?
> you should be able to simply do git reflog branchname@{1} as a rebase
> detaches the branch head before reattaching to the final head.
I like the term "simply" - seems anything but.
> You can do this by adding:
>
> [user]
> logallrefupdates=true
To where? Does this need to be documented in the wiki?
> Did I miss somethig ?
Probably not - but I certainly don't know the intimate details of git at
this level.
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I had a quick look at the 1rst one, this anwser is the good one to me.
Yep but it doesn't work in all cases.
> If you've enabled per branch reflogs
How do you do this?
> you should be able to simply do git reflog branchname@{1} as a rebase detaches the branch head before reattaching to the final head.
I like the term "simply" - seems anything but.
> You can do this by adding:
>
> [user]
> logallrefupdates=true
To where? Does this need to be documented in the wiki?
> Did I miss somethig ?
Probably not - but I certainly don't know the intimate details of git at this level.
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
I had a quick look at the 1rst one, this anwser is the good one to me:
The easiest way would be to find the head commit of the branch as it was
immediately before the rebase started in the reflog...
git reflog
and to reset the current branch to it (with the usual caveats about being
absolutely sure before reseting with the --hard option).
# Suppose the old commit was HEAD@{5} in the ref log
git reset --hard HEAD@{5}
You can check the history of the candidate old head by just doing a git log
HEAD@{5} .
If you've enabled per branch reflogs you should be able to simply do git
reflog branchname@{1} as a rebase detaches the branch head before
reattaching to the final head. I would double check this, though as I
haven't verified this recently. You can do this by adding:
[user]
logallrefupdates=true
Did I miss somethig ?
Thanks,
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Thursday, March 21, 2013 10:49 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
> True, the git rebase hasn't got a dry run but you can undo it if it didn't
> please you:
>
> git reflog
Seems it doesn't always work - which makes me a little nervous:
http://stackoverflow.com/questions/134882/undoing-a-git-rebase
Sometime you need to do this (a bit scary):
http://www.bluemangolearning.com/blog/2009/03/recovering-from-a-disastrous-git-rebase-mistake/
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> True, the git rebase hasn't got a dry run but you can undo it if it didn't please you:
>
> git reflog
Seems it doesn't always work - which makes me a little nervous:
http://stackoverflow.com/questions/134882/undoing-a-git-rebase
Sometime you need to do this (a bit scary):
http://www.bluemangolearning.com/blog/2009/03/recovering-from-a-disastrous-git-rebase-mistake/
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
True, the git rebase hasn't got a dry run but you can undo it if it didn't
please you:
git reflog
be9dd19 HEAD@{0}: commit: added test2.txt
b182b7f HEAD@{1}: rebase finished: returning to refs/heads/master
b182b7f HEAD@{2}: pull --rebase: CREATED myFile1.txt
db46d91 HEAD@{3}: checkout: moving from master to
db46d91ad5fcce68696de5d6eb66cf8ffff2f935^0
2c5f71c HEAD@{4}: commit: CREATED myFile1.txt
9d119a0 HEAD@{5}: rebase finished: returning to refs/heads/master
9d119a0 HEAD@{6}: pull --rebase: Added myFile.txt
af5e47b HEAD@{7}: checkout: moving from master to
af5e47bfd2ec488d5f6ca70b54a58ee2505d1cc0^0
4865f0a HEAD@{8}: commit: Added myFile.txt
git reset --hard HEAD@{3} // to return before your rebase / pull --rebase
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Thursday, March 21, 2013 9:23 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
> Ok, I should have say "in this case, use 'git rebase -p origin/develop' to
> preserve your 'merged branch commit' from being rewriten/flattened, then
> you can push.", I guess that's more english.
How do I know what this is going to do? git pull has a "--dry-run" option
but it seems get rebase doesn't have a "--dry-run" option.
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Ok, I should have say "in this case, use 'git rebase -p origin/develop' to preserve your 'merged branch commit' from being rewriten/flattened, then you can push.", I guess that's more english.
How do I know what this is going to do? git pull has a "--dry-run" option but it seems get rebase doesn't have a "--dry-run" option.
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Ok, I should have say "in this case, use 'git rebase -p origin/develop' to
preserve your 'merged branch commit' from being rewriten/flattened, then you
can push.", I guess that's more english.
As I don't know how I can explain that clearlier, just tell me what you want
me to give some more details.
Thanks,
-Fred
-----Message d'origine-----
From: Justin Mclean
Sent: Thursday, March 21, 2013 7:42 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
Hi,
> You should always do a "git pull --rebase" before pushing except, AFAIK
> when you have a "merged local banch not yet push", from the tests I did on
> my git lab relative to the info Desa gave, I can't see an other situation
> where a "git pull --rebase" rewrite/flattened your merged commit (and
> should not), in this particular case, you do a "git pull -ff-only" instead
> (Which refuse to merge and exit with a non-zero status unless the current
> HEAD is already up-to-date or the merge can be resolved as a
> fast-forward), in this case, use "git rebase -p origin/develop" to
> preserve your "merged branch commit" to be rewrite/flattened, then you can
> push.
Sorry that's just too confusing to follow. Can you put that into words that
a non git user would understand?
Justin
Re: [OT] Log history
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> You should always do a "git pull --rebase" before pushing except, AFAIK when you have a "merged local banch not yet push", from the tests I did on my git lab relative to the info Desa gave, I can't see an other situation where a "git pull --rebase" rewrite/flattened your merged commit (and should not), in this particular case, you do a "git pull -ff-only" instead (Which refuse to merge and exit with a non-zero status unless the current HEAD is already up-to-date or the merge can be resolved as a fast-forward), in this case, use "git rebase -p origin/develop" to preserve your "merged branch commit" to be rewrite/flattened, then you can push.
Sorry that's just too confusing to follow. Can you put that into words that a non git user would understand?
Justin
Re: [OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
You should always do a "git pull --rebase" before pushing except, AFAIK when
you have a "merged local banch not yet push", from the tests I did on my git
lab relative to the info Desa gave, I can't see an other situation where a
"git pull --rebase" rewrite/flattened your merged commit (and should not),
in this particular case, you do a "git pull -ff-only" instead (Which refuse
to merge and exit with a non-zero status unless the current HEAD is already
up-to-date or the merge can be resolved as a fast-forward), in this case,
use "git rebase -p origin/develop" to preserve your "merged branch commit"
to be rewrite/flattened, then you can push.
Thanks,
-Fred
-----Message d'origine-----
From: Alex Harui
Sent: Thursday, March 21, 2013 7:19 AM
To: dev@flex.apache.org
Subject: Re: [OT] Log history
OK, so we should always do a pull --rebase before pushing?
Is there any time we should not do that?
On 3/20/13 10:55 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Hi guys,
>
> I would like to bring to your attention that after 3 'git push', the log
> history looks already exotic, nobody did branches but it looks like there
> are [1].
>
> Given nobody worked on a branch and did a merge --no-ff, we should have a
> flat graph: eveything pushed on top of what the others did.
> It is not the case because the 2 last persons who pushed didn't do a
> pull --rebase first, if you don't want to use pull --rebase because of
> have
> a "local merged branch not yet pushed" and don't want it to be re-writen
> by
> the rebase operation, you can "git pull --ff-only", it will gives you an
> error if they are commits ahead of your local head and then do a "git
> rebase -p origin/develop" to preserve your merged branch commit to be
> re-writen.
>
> Thanks,
> -Fred
>
> [1]
> * 7e6fe20 2013-03-21 | Added support for Flash Player 11.7 (HEAD,
> origin/develop, develop) [Justin Mclean]
> * 8392018 2013-03-21 | Merge branch 'develop' of
> https://git-wip-us.apache.org/repos/asf/flex-sdk into develop [Justin
> Mclean]
> |\
> | * f292ce0 2013-03-20 | added 38 Mustella tests for CallOutButton and
> removed a not existing skin CallOutArrowSkin in defaults.css [cyrill
>
> | * bbb75ce 2013-03-20 | FLEX-33350 adding CallOut components to
> experimental project - component patch by Marcus Fritze .
> [cyrill.za
>
> | * 3016ec4 2013-03-20 | moved new components Accordion, DataAccordion,
> InlineScroller .. new layouts AccordionLayout, CarouselLayout, Cov
>
> | |\
> | | * 0d3bf3b 2013-03-19 | moved new components Accordion, DataAccordion,
> InlineScroller .. new layouts AccordionLayout, CarouselLayout, Cov
>
> * | | 3461a16 2013-03-21 | Added support for Flash Player 11.7 and AIR
> 3.7.
> Updated FP 11.6 playerglobal.swc MD5 [Justin Mclean]
> |/ /
> * | 4f6c47d 2013-03-19 | Merge branch 'develop' of
> https://git-wip-us.apache.org/repos/asf/flex-sdk into develop [Justin
> Mclean]
> |\ \
> | |/
> | * b5fce93 2013-03-19 | FLEX-33435 added more details [Frédéric THOMAS]
> | * 9c7c97e 2013-03-19 | Updated for the Svn to Git migration [Frédéric
> THOMAS]
> * | 85af480 2013-03-19 | Added el_GR locale for postcodes [Justin Mclean]
> * | 63580a8 2013-03-19 | Adding more datagrid double click modes [Justin
> Mclean]
> |/
> * c5869e4 2013-03-19 | Added nl_NL locale for postcode validator [Justin
> Mclean]
> * cbfeae5 2013-03-19 | Merge branch 'develop' of
> https://git-wip-us.apache.org/repos/asf/flex-sdk into develop [Justin
> Mclean]
> |\
> | * 5e15ba8 2013-03-18 | OS X specific entry for flex-tlf link [Erik de
> Bruin]
> * | f825b4a 2013-03-19 | Added fi_FI locale for postcode validator [Justin
> Mclean]
> |/
> * 35c5fbd 2013-03-18 | Added ru_RU locale for postcode validator [Justin
> Mclean]
> * fc57407 2013-03-18 | Added pt_PT postcode validator strings [Justin
> Mclean]
> * 8645f87 2013-03-18 | Added pt_BR postcode validator strings [Justin
> Mclean]
> * 2d41d85 2013-03-18 | Added ja_JP postcode validator strings [Justin
> Mclean]
> * 8b9c4a6 2013-03-18 | Added de_DE postcode validator strings [Justin
> Mclean]
> * 077c87e 2013-03-17 | The files/directories to exclude while checkin
> [Frédéric THOMAS]
> * a099d6a 2013-03-11 | added instruction on how to buil framework RSLs if
> they don't exits [Justin Mclean]
> * 3d2092d 2013-03-11 | Fix RTE in ComboBox as described in FLEX-33414.
> Mustella ComboBox tests pass. [Justin Mclean]
> * a364811 2013-03-11 | removed shell as needed on windows [Justin Mclean]
> * 390831f 2013-03-10 | Fix RTE described in FLEX-33385. titeText is
> optional
> part. [Justin Mclean]
> * bcdf552 2013-03-10 | Less strict typing to stop RTE as described
> FLEX-33405 [Justin Mclean]
> * c226e84 2013-03-09 | Added my public key [Frédéric Thomas]
> * eef6a6c 2013-03-07 | Removed duplicate experimental targets and fixed
> textLayut_rb output swc. Is this file used any more? [Justin Mclean]
>
> * aaf34fd 2013-03-07 | Tiny bit of cleanup I noticed while reading the
> code.
> [Carol Frampton]
> * 6791729 2013-03-06 | Revert last change which shouldn't have been
> submitted. [Carol Frampton]
> * 7c3caab 2013-03-06 | Fix up a few errors in the method headers. [Carol
> Frampton]
> * c4432ef 2013-03-06 | Refix FLEX-33417 correctly. [Carol Frampton]
> * 255743f 2013-03-05 | FLEX-33417. core.swc doesn't link correctly if
> playerglobal.swc is included in compile-config.xml rather than direct
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [OT] Log history
Posted by Alex Harui <ah...@adobe.com>.
OK, so we should always do a pull --rebase before pushing?
Is there any time we should not do that?
On 3/20/13 10:55 PM, "Frédéric THOMAS" <we...@hotmail.com> wrote:
> Hi guys,
>
> I would like to bring to your attention that after 3 'git push', the log
> history looks already exotic, nobody did branches but it looks like there
> are [1].
>
> Given nobody worked on a branch and did a merge --no-ff, we should have a
> flat graph: eveything pushed on top of what the others did.
> It is not the case because the 2 last persons who pushed didn't do a
> pull --rebase first, if you don't want to use pull --rebase because of have
> a "local merged branch not yet pushed" and don't want it to be re-writen by
> the rebase operation, you can "git pull --ff-only", it will gives you an
> error if they are commits ahead of your local head and then do a "git
> rebase -p origin/develop" to preserve your merged branch commit to be
> re-writen.
>
> Thanks,
> -Fred
>
> [1]
> * 7e6fe20 2013-03-21 | Added support for Flash Player 11.7 (HEAD,
> origin/develop, develop) [Justin Mclean]
> * 8392018 2013-03-21 | Merge branch 'develop' of
> https://git-wip-us.apache.org/repos/asf/flex-sdk into develop [Justin
> Mclean]
> |\
> | * f292ce0 2013-03-20 | added 38 Mustella tests for CallOutButton and
> removed a not existing skin CallOutArrowSkin in defaults.css [cyrill
>
> | * bbb75ce 2013-03-20 | FLEX-33350 adding CallOut components to
> experimental project - component patch by Marcus Fritze . [cyrill.za
>
> | * 3016ec4 2013-03-20 | moved new components Accordion, DataAccordion,
> InlineScroller .. new layouts AccordionLayout, CarouselLayout, Cov
>
> | |\
> | | * 0d3bf3b 2013-03-19 | moved new components Accordion, DataAccordion,
> InlineScroller .. new layouts AccordionLayout, CarouselLayout, Cov
>
> * | | 3461a16 2013-03-21 | Added support for Flash Player 11.7 and AIR 3.7.
> Updated FP 11.6 playerglobal.swc MD5 [Justin Mclean]
> |/ /
> * | 4f6c47d 2013-03-19 | Merge branch 'develop' of
> https://git-wip-us.apache.org/repos/asf/flex-sdk into develop [Justin
> Mclean]
> |\ \
> | |/
> | * b5fce93 2013-03-19 | FLEX-33435 added more details [Frédéric THOMAS]
> | * 9c7c97e 2013-03-19 | Updated for the Svn to Git migration [Frédéric
> THOMAS]
> * | 85af480 2013-03-19 | Added el_GR locale for postcodes [Justin Mclean]
> * | 63580a8 2013-03-19 | Adding more datagrid double click modes [Justin
> Mclean]
> |/
> * c5869e4 2013-03-19 | Added nl_NL locale for postcode validator [Justin
> Mclean]
> * cbfeae5 2013-03-19 | Merge branch 'develop' of
> https://git-wip-us.apache.org/repos/asf/flex-sdk into develop [Justin
> Mclean]
> |\
> | * 5e15ba8 2013-03-18 | OS X specific entry for flex-tlf link [Erik de
> Bruin]
> * | f825b4a 2013-03-19 | Added fi_FI locale for postcode validator [Justin
> Mclean]
> |/
> * 35c5fbd 2013-03-18 | Added ru_RU locale for postcode validator [Justin
> Mclean]
> * fc57407 2013-03-18 | Added pt_PT postcode validator strings [Justin
> Mclean]
> * 8645f87 2013-03-18 | Added pt_BR postcode validator strings [Justin
> Mclean]
> * 2d41d85 2013-03-18 | Added ja_JP postcode validator strings [Justin
> Mclean]
> * 8b9c4a6 2013-03-18 | Added de_DE postcode validator strings [Justin
> Mclean]
> * 077c87e 2013-03-17 | The files/directories to exclude while checkin
> [Frédéric THOMAS]
> * a099d6a 2013-03-11 | added instruction on how to buil framework RSLs if
> they don't exits [Justin Mclean]
> * 3d2092d 2013-03-11 | Fix RTE in ComboBox as described in FLEX-33414.
> Mustella ComboBox tests pass. [Justin Mclean]
> * a364811 2013-03-11 | removed shell as needed on windows [Justin Mclean]
> * 390831f 2013-03-10 | Fix RTE described in FLEX-33385. titeText is optional
> part. [Justin Mclean]
> * bcdf552 2013-03-10 | Less strict typing to stop RTE as described
> FLEX-33405 [Justin Mclean]
> * c226e84 2013-03-09 | Added my public key [Frédéric Thomas]
> * eef6a6c 2013-03-07 | Removed duplicate experimental targets and fixed
> textLayut_rb output swc. Is this file used any more? [Justin Mclean]
>
> * aaf34fd 2013-03-07 | Tiny bit of cleanup I noticed while reading the code.
> [Carol Frampton]
> * 6791729 2013-03-06 | Revert last change which shouldn't have been
> submitted. [Carol Frampton]
> * 7c3caab 2013-03-06 | Fix up a few errors in the method headers. [Carol
> Frampton]
> * c4432ef 2013-03-06 | Refix FLEX-33417 correctly. [Carol Frampton]
> * 255743f 2013-03-05 | FLEX-33417. core.swc doesn't link correctly if
> playerglobal.swc is included in compile-config.xml rather than direct
>
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
[OT] Log history
Posted by Frédéric THOMAS <we...@hotmail.com>.
Hi guys,
I would like to bring to your attention that after 3 'git push', the log
history looks already exotic, nobody did branches but it looks like there
are [1].
Given nobody worked on a branch and did a merge --no-ff, we should have a
flat graph: eveything pushed on top of what the others did.
It is not the case because the 2 last persons who pushed didn't do a
pull --rebase first, if you don't want to use pull --rebase because of have
a "local merged branch not yet pushed" and don't want it to be re-writen by
the rebase operation, you can "git pull --ff-only", it will gives you an
error if they are commits ahead of your local head and then do a "git
rebase -p origin/develop" to preserve your merged branch commit to be
re-writen.
Thanks,
-Fred
[1]
* 7e6fe20 2013-03-21 | Added support for Flash Player 11.7 (HEAD,
origin/develop, develop) [Justin Mclean]
* 8392018 2013-03-21 | Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop [Justin
Mclean]
|\
| * f292ce0 2013-03-20 | added 38 Mustella tests for CallOutButton and
removed a not existing skin CallOutArrowSkin in defaults.css [cyrill
| * bbb75ce 2013-03-20 | FLEX-33350 adding CallOut components to
experimental project - component patch by Marcus Fritze . [cyrill.za
| * 3016ec4 2013-03-20 | moved new components Accordion, DataAccordion,
InlineScroller .. new layouts AccordionLayout, CarouselLayout, Cov
| |\
| | * 0d3bf3b 2013-03-19 | moved new components Accordion, DataAccordion,
InlineScroller .. new layouts AccordionLayout, CarouselLayout, Cov
* | | 3461a16 2013-03-21 | Added support for Flash Player 11.7 and AIR 3.7.
Updated FP 11.6 playerglobal.swc MD5 [Justin Mclean]
|/ /
* | 4f6c47d 2013-03-19 | Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop [Justin
Mclean]
|\ \
| |/
| * b5fce93 2013-03-19 | FLEX-33435 added more details [Frédéric THOMAS]
| * 9c7c97e 2013-03-19 | Updated for the Svn to Git migration [Frédéric
THOMAS]
* | 85af480 2013-03-19 | Added el_GR locale for postcodes [Justin Mclean]
* | 63580a8 2013-03-19 | Adding more datagrid double click modes [Justin
Mclean]
|/
* c5869e4 2013-03-19 | Added nl_NL locale for postcode validator [Justin
Mclean]
* cbfeae5 2013-03-19 | Merge branch 'develop' of
https://git-wip-us.apache.org/repos/asf/flex-sdk into develop [Justin
Mclean]
|\
| * 5e15ba8 2013-03-18 | OS X specific entry for flex-tlf link [Erik de
Bruin]
* | f825b4a 2013-03-19 | Added fi_FI locale for postcode validator [Justin
Mclean]
|/
* 35c5fbd 2013-03-18 | Added ru_RU locale for postcode validator [Justin
Mclean]
* fc57407 2013-03-18 | Added pt_PT postcode validator strings [Justin
Mclean]
* 8645f87 2013-03-18 | Added pt_BR postcode validator strings [Justin
Mclean]
* 2d41d85 2013-03-18 | Added ja_JP postcode validator strings [Justin
Mclean]
* 8b9c4a6 2013-03-18 | Added de_DE postcode validator strings [Justin
Mclean]
* 077c87e 2013-03-17 | The files/directories to exclude while checkin
[Frédéric THOMAS]
* a099d6a 2013-03-11 | added instruction on how to buil framework RSLs if
they don't exits [Justin Mclean]
* 3d2092d 2013-03-11 | Fix RTE in ComboBox as described in FLEX-33414.
Mustella ComboBox tests pass. [Justin Mclean]
* a364811 2013-03-11 | removed shell as needed on windows [Justin Mclean]
* 390831f 2013-03-10 | Fix RTE described in FLEX-33385. titeText is optional
part. [Justin Mclean]
* bcdf552 2013-03-10 | Less strict typing to stop RTE as described
FLEX-33405 [Justin Mclean]
* c226e84 2013-03-09 | Added my public key [Frédéric Thomas]
* eef6a6c 2013-03-07 | Removed duplicate experimental targets and fixed
textLayut_rb output swc. Is this file used any more? [Justin Mclean]
* aaf34fd 2013-03-07 | Tiny bit of cleanup I noticed while reading the code.
[Carol Frampton]
* 6791729 2013-03-06 | Revert last change which shouldn't have been
submitted. [Carol Frampton]
* 7c3caab 2013-03-06 | Fix up a few errors in the method headers. [Carol
Frampton]
* c4432ef 2013-03-06 | Refix FLEX-33417 correctly. [Carol Frampton]
* 255743f 2013-03-05 | FLEX-33417. core.swc doesn't link correctly if
playerglobal.swc is included in compile-config.xml rather than direct
Re: [jira] [Created] (FLEX-33440) Make AIR optional
Posted by Alex Harui <ah...@adobe.com>.
On 3/20/13 10:37 PM, "Justin Mclean" <ju...@classsoftware.com> wrote:
>> Those scripts Justin wrote don't really have a windows equivalent.
> They would be fairly simple to port to bat scripts. Anyone on windows want to
> give it a go?
I thought the problem with .bat (and the reason we wrote this installer) is
because we couldn't get a download command in the bat without some vbscript
library or something.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Created] (FLEX-33440) Make AIR optional
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> Bonus points if the installer can be re-run later to add in any version of
> AIR SDK so folks don't get it wrong.
Currently it needs an empty directory, would be nice if it could run in update mode for example if you decided you needed one of the optional bits.
> Those scripts Justin wrote don't really have a windows equivalent.
They would be fairly simple to port to bat scripts. Anyone on windows want to give it a go?
Justin
Re: [jira] [Created] (FLEX-33440) Make AIR optional
Posted by Alex Harui <ah...@adobe.com>.
Bonus points if the installer can be re-run later to add in any version of
AIR SDK so folks don't get it wrong. Those scripts Justin wrote don't
really have a windows equivalent.
On 3/20/13 9:57 PM, "Om" <bi...@gmail.com> wrote:
> On Wed, Mar 20, 2013 at 9:44 PM, Justin Mclean
> <ju...@classsoftware.com>wrote:
>
>> Hi,
>>
>>> I am not sure if this is a good idea. If we dont do it by default during
>>> the install, there is a good chance that folks will download the wrong
>>> version of the AIR SDK which would break a lot of functionality.
>>
>> Just make the licence checkbox optional is all I think is required and
>> perhaps a "Are you sure you don't want to install AIR is required for
>> desktop and mobile applications"?
>>
>>
> It is easy enough to implement, but I think it will cause more support
> issues like we had today. Where folks overlay the wrong version of the AIR
> sdk manually and it breaks everything. I dont know if it is worth it.
>
> Moreover, having the AIR SDK allows folks to quickly create mobile and
> desktop versions. Having to download AIR sdk at a later point would create
> an unnecessary barrier.
>
>
>
>> I've had several people compile to me that the installer download AIR when
>> they don't need it and it's not a small download.
>>
>> Justin
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
Re: [jira] [Created] (FLEX-33440) Make AIR optional
Posted by Om <bi...@gmail.com>.
On Wed, Mar 20, 2013 at 9:44 PM, Justin Mclean <ju...@classsoftware.com>wrote:
> Hi,
>
> > I am not sure if this is a good idea. If we dont do it by default during
> > the install, there is a good chance that folks will download the wrong
> > version of the AIR SDK which would break a lot of functionality.
>
> Just make the licence checkbox optional is all I think is required and
> perhaps a "Are you sure you don't want to install AIR is required for
> desktop and mobile applications"?
>
>
It is easy enough to implement, but I think it will cause more support
issues like we had today. Where folks overlay the wrong version of the AIR
sdk manually and it breaks everything. I dont know if it is worth it.
Moreover, having the AIR SDK allows folks to quickly create mobile and
desktop versions. Having to download AIR sdk at a later point would create
an unnecessary barrier.
> I've had several people compile to me that the installer download AIR when
> they don't need it and it's not a small download.
>
> Justin
Re: [jira] [Created] (FLEX-33440) Make AIR optional
Posted by Justin Mclean <ju...@classsoftware.com>.
Hi,
> I am not sure if this is a good idea. If we dont do it by default during
> the install, there is a good chance that folks will download the wrong
> version of the AIR SDK which would break a lot of functionality.
Just make the licence checkbox optional is all I think is required and perhaps a "Are you sure you don't want to install AIR is required for desktop and mobile applications"?
I've had several people compile to me that the installer download AIR when they don't need it and it's not a small download.
Justin
Re: [jira] [Created] (FLEX-33440) Make AIR optional
Posted by Om <bi...@gmail.com>.
I am not sure if this is a good idea. If we dont do it by default during
the install, there is a good chance that folks will download the wrong
version of the AIR SDK which would break a lot of functionality.
What is the concern if AIR is also downloaded?
Thanks,
Om
On Wed, Mar 20, 2013 at 5:17 PM, Justin Mclean (JIRA) <ji...@apache.org>wrote:
> Justin Mclean created FLEX-33440:
> ------------------------------------
>
> Summary: Make AIR optional
> Key: FLEX-33440
> URL: https://issues.apache.org/jira/browse/FLEX-33440
> Project: Apache Flex
> Issue Type: Bug
> Components: Installer
> Reporter: Justin Mclean
> Priority: Minor
>
>
> The installer downloads AIR. AIR is not required for browser applications
> so it should be an optional download.
>
> --
> This message is automatically generated by JIRA.
> If you think it was sent incorrectly, please contact your JIRA
> administrators
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>