You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@flex.apache.org by "Michael A. Labriola" <la...@digitalprimates.net> on 2013/04/06 03:21:06 UTC

RE: Git needs a KISSa

Gordon and Justin,

>I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 'git status', and see changes to 200 files from other people mingling with your changes to 2. The simple way to prevent this is to commit your changes before pulling in other people's changes (I think).

Unfortunately that won't prevent it. For now, it's more about just educating everyone about merges.

Read this (and the comments if you are brave). [1] What Fred was advocating was a rebase workflow. What Gordon is proposing is mostly a merge workflow. That latter can work, we use it often, but it puts the onus on the developer doing the merge. Incidentally, this is why is most larger open source projects... see linux (or even what we did on FlexUnit in git) have a very few number of people who knew git well that managed the actual develop and master branches.

The rest of the community happily worked from their own forks (which is basically just a server side copy of git all to your own) and just pulled in changes from develop, they didn't push to develop. That was the question I was originally asking Fred as to if there was a technical reason that we were setup this way. Incidentally, Fred did an excellent job on the wiki pages and making his case.

I understand why everyone can see git as a pain right now. I really do. Ultimately the active committers on this list need to decide the correct route for the project. From my experience, this is the best analogy I can give. Please indulge me one last time.

SVN was like a nail and everyone got good at using a hammer to put that nail into the wall. Git is a screw. When you start, it's natural to try to pound the screw into the wall the same way you did a nail. You can make it work, but it will seem cumbersome and inelegant compared to the ease of the nail. You won't see any advantages and it won't get any better, although you can make it work. If, however, you can begin to see that the screw works differently (and btw, that's the big thing git and SVN are honestly night and day in how they work and their workflow) and begin carrying the right tool, soon you can see that the screw has some advantages. It doesn't replace a nail but for certain applications it's much more useful. Look at the success of open source projects on github, linux and many others and I promise, we aren't all crazy. There are growing pains, but they are not insurmountable.

I personally wish we had more of a github fork model here where a couple of people have the keys to the castle. To be honest, that's what I was envisioning when I voted for git. It may not be possible at this point or ever, but the result is putting the onus on everyone learning more about git than they might otherwise need and having a miserable experience. So, read my link. Ask questions and I will answer here whenever possible.

Mike

[1] http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

Re: Git needs a KISSa

Posted by Justin Mclean <ju...@classsoftware.com>.

Hi,

> Incidentally, this is why is most larger open source projects... see linux (or even what we did on FlexUnit in git) have a very few number of people who knew git well that managed the actual develop and master branches.
Could that work for us? (With committers pushing to develop that is?) Could someone who a git expert "clean up" the log on develop from time to time as required? Would anyone want to do that?

> It doesn't replace a nail but for certain applications it's much more useful. Look at the success of open source projects on github, linux and many others and I promise, we aren't all crazy.
I don't think that the issue. Most of us know some git and get what the benefits are (local branches, offline commits etc etc). I used git successfully on other projects and on my own projects and it was not this complex and there were minimal issues.

> I personally wish we had more of a github fork model here where a couple of people have the keys to the castle.
Which is probably against the Apache Way.

> [1] http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
And this is the problem I run into  again and agin when reading about git. if you read the conclusion to me it's saying you need to be really really careful using rebase. It seems to me having a slightly  messy log is the lesser evil.

Thanks,
Justin

Re: Git needs a KISSa

Posted by Jose Barragan <jo...@codeoscopic.com>.

I'm totally agree with Mike, 

In fact, I use that simple criterion: 
make a new branch for any action and work, share, stash, commit any thing into it
if original branch is updated, we need merge the original advances using fast forward resolution (try to move the local pointer of our topic branch to original head), and if isn't possible, make a merge.
and continue working on it and sharing it with my coworkers.
When we decided delivery the content of our topic/utility branch into the original or whatever other, we must force a merge commit, to track all that work in the util branch.

Best,
--
Jose Barragan

On Apr 6, 2013, at 9:03 PM, Michael A. Labriola <la...@digitalprimates.net> wrote:

>> Your link says "Merge is perfectly fine for managing your code." The 
>> only drawback it mentions is a more cluttered log. It has far stronger 
>> warnings about misusing rebase.
>> 
>> How could anyone read this conclusion
>> 
>> 
>> 1.  Merge works great, but creates lots of empty merge commits when 
>> you are working on a team.
>> 2.  Rebase keeps things tidy, but is destructive and potentially 
>> dangerous if you don¹t know what you are doing.
>> 
>> and not conclude that merge is better for non-experts?
> 
> Gordon,
> 
> So, that is effectively what Fred and I were discussing before. I do personally think a merge workflow is easier for beginners. Fred was pointing out the history becoming difficult to follow and also that in the merge scenario the new developer is responsible for committing the combination of the files they worked on plus the merge back to the repo. If they didn't do this it would be as though they had intentionally excluded the code that was in place before. He is right about both of those things.
> 
> I was simply suggesting that, perhaps, to get everyone started we acknowledge both of those issues and deal with a period of messier logs until everyone is comfortable with the basics, then evolve an approach later that might be better for a more advanced set of users. The really big educational point is just to ensure you commit all of the changes after a merge.
> 
> Mike
>

RE: Git needs a KISSa

Posted by "Michael A. Labriola" <la...@digitalprimates.net>.

> Your link says "Merge is perfectly fine for managing your code." The 
> only drawback it mentions is a more cluttered log. It has far stronger 
> warnings about misusing rebase.
> 
> How could anyone read this conclusion
> 
> 
>  1.  Merge works great, but creates lots of empty merge commits when 
> you are working on a team.
>  2.  Rebase keeps things tidy, but is destructive and potentially 
> dangerous if you don¹t know what you are doing.
> 
> and not conclude that merge is better for non-experts?

Gordon,

So, that is effectively what Fred and I were discussing before. I do personally think a merge workflow is easier for beginners. Fred was pointing out the history becoming difficult to follow and also that in the merge scenario the new developer is responsible for committing the combination of the files they worked on plus the merge back to the repo. If they didn't do this it would be as though they had intentionally excluded the code that was in place before. He is right about both of those things.

I was simply suggesting that, perhaps, to get everyone started we acknowledge both of those issues and deal with a period of messier logs until everyone is comfortable with the basics, then evolve an approach later that might be better for a more advanced set of users. The really big educational point is just to ensure you commit all of the changes after a merge.

Mike

Re: Git needs a KISSa

Posted by Justin Mclean <ju...@classsoftware.com>.

Hi,

> At least, nobody has gotten on my case for screwing up history. 

Run gitk to view. You might be surprised. It's reasonable but it's not 100% "clean" (for the SDK anyway).

Justin

Re: Git needs a KISSa

Posted by Alex Harui <ah...@adobe.com>.



On 4/5/13 7:22 PM, "Gordon Smith" <go...@adobe.com> wrote:

> 
> Your link says "Merge is perfectly fine for managing your code." The only
> drawback it mentions is a more cluttered log. It has far stronger warnings
> about misusing rebase.
> 
> How could anyone read this conclusion
> 
> 
>  1.  Merge works great, but creates lots of empty merge commits when you are
> working on a team.
>  2.  Rebase keeps things tidy, but is destructive and potentially dangerous if
> you don¹t know what you are doing.
> 
> and not conclude that merge is better for non-experts?
Because, IIUC, most of the work we do is better suited for rebase.  SVN
essentially did a rebase for you.  The difference is when you start pulling
stuff from other public branches, not from the local branch you made when
you started to make some changes.

I could be wrong, but I'm pretty sure that most of the complexity occurs
when you start sharing code with other committers before its gets "checked
in".  99% of the time we aren't going to do that and a simple SVN-like
approach seems to be working for me.  At least, nobody has gotten on my case
for screwing up history.  But please review my checkins on flex-asjs and
flex-falcon and correct me if I'm doing something wrong.  I am using
--rebase 100% of the time so far because I don't think the series of changes
are related enough to deserve a "branch" in the history.

> 
> - Gordon
> 
> Sent from my iPad
> 
> On Apr 5, 2013, at 7:12 PM, "Gordon Smith"
> <go...@adobe.com>> wrote:
> 
> Unfortunately that won't prevent it.
> 
> Please explain why not.
> 
> -  Gordon
> 
> Sent from my iPad
> 
> On Apr 5, 2013, at 6:21 PM, "Michael A. Labriola"
> <la...@digitalprimates.net>> wrote:
> 
> Gordon and Justin,
> 
> I agree that it would be bad to edit 2 files, do a 'git pull' followed by a
> 'git status', and see changes to 200 files from other people mingling with
> your changes to 2. The simple way to prevent this is to commit your changes
> before pulling in other people's changes (I think).
> 
> Unfortunately that won't prevent it. For now, it's more about just educating
> everyone about merges.
> 
> Read this (and the comments if you are brave). [1] What Fred was advocating
> was a rebase workflow. What Gordon is proposing is mostly a merge workflow.
> That latter can work, we use it often, but it puts the onus on the developer
> doing the merge. Incidentally, this is why is most larger open source
> projects... see linux (or even what we did on FlexUnit in git) have a very few
> number of people who knew git well that managed the actual develop and master
> branches.
> 
> The rest of the community happily worked from their own forks (which is
> basically just a server side copy of git all to your own) and just pulled in
> changes from develop, they didn't push to develop. That was the question I was
> originally asking Fred as to if there was a technical reason that we were
> setup this way. Incidentally, Fred did an excellent job on the wiki pages and
> making his case.
> 
> I understand why everyone can see git as a pain right now. I really do.
> Ultimately the active committers on this list need to decide the correct route
> for the project. From my experience, this is the best analogy I can give.
> Please indulge me one last time.
> 
> SVN was like a nail and everyone got good at using a hammer to put that nail
> into the wall. Git is a screw. When you start, it's natural to try to pound
> the screw into the wall the same way you did a nail. You can make it work, but
> it will seem cumbersome and inelegant compared to the ease of the nail. You
> won't see any advantages and it won't get any better, although you can make it
> work. If, however, you can begin to see that the screw works differently (and
> btw, that's the big thing git and SVN are honestly night and day in how they
> work and their workflow) and begin carrying the right tool, soon you can see
> that the screw has some advantages. It doesn't replace a nail but for certain
> applications it's much more useful. Look at the success of open source
> projects on github, linux and many others and I promise, we aren't all crazy.
> There are growing pains, but they are not insurmountable.
> 
> I personally wish we had more of a github fork model here where a couple of
> people have the keys to the castle. To be honest, that's what I was
> envisioning when I voted for git. It may not be possible at this point or
> ever, but the result is putting the onus on everyone learning more about git
> than they might otherwise need and having a miserable experience. So, read my
> link. Ask questions and I will answer here whenever possible.
> 
> Mike
> 
> [1] 
> http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-reba
> se-hell/
> 

-- 
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui

Re: Git needs a KISSa

Posted by Gordon Smith <go...@adobe.com>.

Your link says "Merge is perfectly fine for managing your code." The only drawback it mentions is a more cluttered log. It has far stronger warnings about misusing rebase.

How could anyone read this conclusion

1. Merge works great, but creates lots of empty merge commits when you are working on a team.
2. Rebase keeps things tidy, but is destructive and potentially dangerous if you don’t know what you are doing.

and not conclude that merge is better for non-experts?

- Gordon

Sent from my iPad

On Apr 5, 2013, at 7:12 PM, "Gordon Smith" <go...@adobe.com>> wrote:

Unfortunately that won't prevent it.

Please explain why not.

- Gordon

Sent from my iPad

On Apr 5, 2013, at 6:21 PM, "Michael A. Labriola" <la...@digitalprimates.net>> wrote:

Gordon and Justin,

I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 'git status', and see changes to 200 files from other people mingling with your changes to 2. The simple way to prevent this is to commit your changes before pulling in other people's changes (I think).

Unfortunately that won't prevent it. For now, it's more about just educating everyone about merges.

Mike

[1] http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/

Re: Git needs a KISSa

Posted by Gordon Smith <go...@adobe.com>.

> Unfortunately that won't prevent it. 

Please explain why not.

-  Gordon

Sent from my iPad

On Apr 5, 2013, at 6:21 PM, "Michael A. Labriola" <la...@digitalprimates.net> wrote:

> Gordon and Justin,
> 
>> I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 'git status', and see changes to 200 files from other people mingling with your changes to 2. The simple way to prevent this is to commit your changes before pulling in other people's changes (I think).
> 
> Unfortunately that won't prevent it. For now, it's more about just educating everyone about merges.
> 
> Read this (and the comments if you are brave). [1] What Fred was advocating was a rebase workflow. What Gordon is proposing is mostly a merge workflow. That latter can work, we use it often, but it puts the onus on the developer doing the merge. Incidentally, this is why is most larger open source projects... see linux (or even what we did on FlexUnit in git) have a very few number of people who knew git well that managed the actual develop and master branches.
> 
> The rest of the community happily worked from their own forks (which is basically just a server side copy of git all to your own) and just pulled in changes from develop, they didn't push to develop. That was the question I was originally asking Fred as to if there was a technical reason that we were setup this way. Incidentally, Fred did an excellent job on the wiki pages and making his case. 
> 
> I understand why everyone can see git as a pain right now. I really do. Ultimately the active committers on this list need to decide the correct route for the project. From my experience, this is the best analogy I can give. Please indulge me one last time.
> 
> SVN was like a nail and everyone got good at using a hammer to put that nail into the wall. Git is a screw. When you start, it's natural to try to pound the screw into the wall the same way you did a nail. You can make it work, but it will seem cumbersome and inelegant compared to the ease of the nail. You won't see any advantages and it won't get any better, although you can make it work. If, however, you can begin to see that the screw works differently (and btw, that's the big thing git and SVN are honestly night and day in how they work and their workflow) and begin carrying the right tool, soon you can see that the screw has some advantages. It doesn't replace a nail but for certain applications it's much more useful. Look at the success of open source projects on github, linux and many others and I promise, we aren't all crazy. There are growing pains, but they are not insurmountable. 
> 
> I personally wish we had more of a github fork model here where a couple of people have the keys to the castle. To be honest, that's what I was envisioning when I voted for git. It may not be possible at this point or ever, but the result is putting the onus on everyone learning more about git than they might otherwise need and having a miserable experience. So, read my link. Ask questions and I will answer here whenever possible.
> 
> Mike
> 
> [1] http://www.jarrodspillers.com/2009/08/19/git-merge-vs-git-rebase-avoiding-rebase-hell/
>