No more excuses! (aka the ValidateThis Guide to Git)

[Bob Silverberg]

Well, you let me know what it would take to get more contributions and I've done my darnedest to make that happen. You told me that Git it getting in your way, so I devoted some time to researching ,experimenting with, and documenting a Git workflow that I'm hoping will be useful to anyone wanting to contribute to the framework. I have no reason to expect that it's perfect, but the best way to find the chinks in its armour is by using it and seeing where it fails, so let's get busy.

You can find my draft document here: http://www.silverwareconsulting.com/page.cfm/A-Git-Workflow-for-Collaboration-on-Open-Source-Pr

I plan to publish this to my blog, once it's been certified through some use, which is why it is in the format in which it appears, complete with unnecessary introduction (from your point of view). I am hoping that anyone interested in contributing to the framework will be able to use this set of instructions to implement a workflow that will work both for them and for the team.

I would be more than happy to schedule a Connect session to walk through the document and the workflow, and demonstrate how I would use it in the course of making changes to the framework. If anyone is interested in that please let me know, and also let me know which days and times would work for you for such a session.

Also please feel free to ask questions or make comments in response to this thread.

My hope, as I've noted in the post, is that this workflow can serve to help not only the ValidateThis project, but also other open source projects, both CF based and not, so your contributions in attempting to work with this workflow will not only benefit this framework, but could benefit countless others as well.

I look forward to seeing how this all works out.

Cheers,

Bob

--
Bob Silverberg
www.silverwareconsulting.com

Hands-on ColdFusion ORM Training
www.ColdFusionOrmTraining.com

[Mark Mandel]

Bob,

Nice work on the document.

Actually showed me some of the really nice features of GitHub! Almost makes me wish CS2 was on there.

To be honest, I've never looked into / had to do a 'git pull --rebase', but maybe that's just me?

Mark

--
You received this message because you are subscribed to the Google Groups "ValidateThis-dev" group.
To post to this group, send email to validate...@googlegroups.com.
To unsubscribe from this group, send email to validatethis-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/validatethis-dev?hl=en.

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

cf.Objective(ANZ) - Nov 18, 19 - Melbourne Australia
http://www.cfobjective.com.au

[Bob Silverberg]

I didn't even know it existed (git pull --rebase) until I started researching this. And regarding GitHub, is there a reason you can't move CS2 there? It's still pre-alpha, so it seems to me it's an ideal time to move it.  I must admit, however, that the issue tracking system at GitHub is the pits, so maybe that's reason enough not to move it. Although it seems like a great place to be to encourage contributions.

Cheers,

Bob

[Mark Mandel]

Yeah, the reason for staying at sourceforge is the infrastructure.

I get Trac on sourceforge, essentially, and a variety of other options as well, including MediWiki and the like.

SF Beta should be coming soon too, with a lot of improvements, and I'm expecting there to be GitHub like tools as well.

Mark

[Jamie Krug]

Okay, this is fantastic, Bob! I've been gradually wrapping my brain around the more advanced complexities in Git, and have also reviewed Vincent Driessen's fantastic "A successful Git branching model" post (http://nvie.com/git-model) a couple times. Your in-depth, real world coverage of this flow has really solidified a lot of things for me. I have a couple quick questions/comments...

I understand git rebase, and it's slick, but the "git pull --rebase" option was new to me. It makes perfect sense, however, I wonder if a merge to keep a primary forked branch current with the main remote would be fine, since it should automatically just do a fast-forward merge, no? I understand that updating a branch that has modifications can make good use of a rebase, and may even have conflicts to resolve, but just keeping something like master or develop branches current should simply be fast-forward merges, no? Or, does a fast-forward merge even still introduce an unnecessary commit, I wonder?

I was slightly confused by the "Rule #X..." headings in the document, at first. I think my problem is they look a bit like a heading, so I was thinking in that manner, but those statements are often just to emphasize what has just been outlined in the document. The flow of the document's content makes perfect sense, but I think the heading style confused me--maybe just bold text at the same font size as normal content? Maybe I'm being way too particular? :P

I'm just curious as to why you've used "main" as the example alias for the project's remote repo, when "upstream" seems to be a fairy well-established standard (though it's just an agreed upon naming convention, no more). Not that "main" is a poor choice--it makes perfect sense--but "upstream" also makes a lot of sense to me, and it seems a common choice and would be consistent with GitHub's help pages as well.

Finally, if I'm seeing this correctly, I think the screen shots near the end, for your example pull request might be slightly confusing to folks. Assuming the ValidateThis/ValidateThis repo will be the true primary repo for the project, then wouldn't it make sense to show an example pull request into ValidateThis:develop from bobsilverberg:develop, rather than the reverse (which is what you have pictured)?

Thanks again for putting the time into this fantastic resource!

Cheers,
Jamie

[Bob Silverberg]

Hi Jamie,

Thanks for the feedback...

On Wed, Sep 8, 2010 at 11:13 PM, Jamie Krug <jami...@gmail.com> wrote:

Okay, this is fantastic, Bob! I've been gradually wrapping my brain around the more advanced complexities in Git, and have also reviewed Vincent Driessen's fantastic "A successful Git branching model" post (http://nvie.com/git-model) a couple times. Your in-depth, real world coverage of this flow has really solidified a lot of things for me. I have a couple quick questions/comments...

I understand git rebase, and it's slick, but the "git pull --rebase" option was new to me. It makes perfect sense, however, I wonder if a merge to keep a primary forked branch current with the main remote would be fine, since it should automatically just do a fast-forward merge, no? I understand that updating a branch that has modifications can make good use of a rebase, and may even have conflicts to resolve, but just keeping something like master or develop branches current should simply be fast-forward merges, no? Or, does a fast-forward merge even still introduce an unnecessary commit, I wonder?

The tests I did showed merge commits when pulling from another remote, but I was doing testing of a collaborative workflow, so I may not have tried that simple case of pulling when there are no changes at all in the local repo.  I just tested and you are correct - if there have been no changes in a branch and you do a pull to bring in changes from upstream then it doesn't add a merge commit.

So I suppose if the workflow is that you make all of your changes in a branch, and only merge them back into develop when you are ready to push them to your own remote, then there is no need for a git pull --rebase.  Things start to get complicated though - even more complicated than I anticipated with my document, when you need to make changes after that. 

Adam and I have been working on a bunch of changes that he made, and we were both pulling from each other, so I'm not sure how often it's going to be a case of "make changes in a branch, merge into develop, push, and that's it".  We ended up using additional branches to collaborate it, and it worked pretty well, but would have gotten quite complicated if there was a third developer in the mix.

I'm thinking, though, that perhaps the safest thing to do it forget about git pull --rebase, even though it is cool, and just accept the fact that there may be unnecessary merge commits from time to time.  I'm not too bothered by the commit history containing those.  Does that sound like the best route to you?

I was slightly confused by the "Rule #X..." headings in the document, at first. I think my problem is they look a bit like a heading, so I was thinking in that manner, but those statements are often just to emphasize what has just been outlined in the document. The flow of the document's content makes perfect sense, but I think the heading style confused me--maybe just bold text at the same font size as normal content? Maybe I'm being way too particular? :P

You're not the only one to comment on that. I got some great feedback from Mike Henke which caused me to make the location of the "rules" more consistent. They now each appear immediately after the code example that they refer to.  But I can see how it might still be confusing.  I'm not sure how to make it better, though. Your comment about "maybe just bold text at the same font size as normal content" - that's what they are now. Maybe they don't appear that way, but they're just normal text wrapped in a <strong>. Do you have any other suggestions that make make it more readable/understandable?

A number of people have suggested breaking it up into smaller pieces. I know it's very long, as tends to be my want, but I also thought that if it was meant to be a "guide" then it should all be on one page to save people from having to click around.

I think I may release it to my blog in a few pieces, but have a link back to the whole document as well (as someone suggested - I can't remember who - maybe John?)

I'm just curious as to why you've used "main" as the example alias for the project's remote repo, when "upstream" seems to be a fairy well-established standard (though it's just an agreed upon naming convention, no more). Not that "main" is a poor choice--it makes perfect sense--but "upstream" also makes a lot of sense to me, and it seems a common choice and would be consistent with GitHub's help pages as well.

Yeah, "main" was my own invention and you're right, I should probably change it to upstream to be more consistent with the nomenclature.

 

Finally, if I'm seeing this correctly, I think the screen shots near the end, for your example pull request might be slightly confusing to folks. Assuming the ValidateThis/ValidateThis repo will be the true primary repo for the project, then wouldn't it make sense to show an example pull request into ValidateThis:develop from bobsilverberg:develop, rather than the reverse (which is what you have pictured)?

You are correct about that too. When I was experimenting I had the roles reversed, but now I think that  ValidateThis/ValidateThis should be the main/upstream repo so I should redo those screen caps.

Thanks again for putting the time into this fantastic resource!

Thank you for your fantastic feedback. Let me know if you have any comments on the above or any further suggestions.

And to anyone else who's read this far, I'd really appreciate your feedback as well. ;-)

Cheers,

Bob

[Jamie Krug]

On Thu, Sep 9, 2010 at 12:39 PM, Bob Silverberg <bob.sil...@gmail.com> wrote:

The tests I did showed merge commits when pulling from another remote, but I was doing testing of a collaborative workflow, so I may not have tried that simple case of pulling when there are no changes at all in the local repo.  I just tested and you are correct - if there have been no changes in a branch and you do a pull to bring in changes from upstream then it doesn't add a merge commit.

Cool. This is what I'd expect, as Git is pretty smart!

 

So I suppose if the workflow is that you make all of your changes in a branch, and only merge them back into develop when you are ready to push them to your own remote, then there is no need for a git pull --rebase.  Things start to get complicated though - even more complicated than I anticipated with my document, when you need to make changes after that. 

Right, but then again, I don't there's any harm in using git pull --rebase there.

 

Adam and I have been working on a bunch of changes that he made, and we were both pulling from each other, so I'm not sure how often it's going to be a case of "make changes in a branch, merge into develop, push, and that's it".  We ended up using additional branches to collaborate it, and it worked pretty well, but would have gotten quite complicated if there was a third developer in the mix.

I'm thinking, though, that perhaps the safest thing to do it forget about git pull --rebase, even though it is cool, and just accept the fact that there may be unnecessary merge commits from time to time.  I'm not too bothered by the commit history containing those.  Does that sound like the best route to you?

Unless I'm missing something, I don't think there's a danger here (as long as everyone is aware of "The Perils of Rebasing," which is covered at http://progit.org/book/ch3-6.html with one simple rule:

"Do not rebase commits that you have pushed to a public repository."

When developers are "pulling from each other," you should still be pulling into a remote, which can then be used to rebase or merge your own local branch. But, as the above rule states, if you've pushed commits to a public repo, just be sure not to rebase those commits. In such case, you'll want to be sure to merge (or fetch/merge). Right? I think I'm getting it, and I'm liking the power of Git and this workflow a lot.

 

You're not the only one to comment on that. I got some great feedback from Mike Henke which caused me to make the location of the "rules" more consistent. They now each appear immediately after the code example that they refer to.  But I can see how it might still be confusing.  I'm not sure how to make it better, though. Your comment about "maybe just bold text at the same font size as normal content" - that's what they are now. Maybe they don't appear that way, but they're just normal text wrapped in a <strong>. Do you have any other suggestions that make make it more readable/understandable?

Okay, I guess the <strong> made it look like a heading to me. In that case, it might just make more sense if the rules were indeed headings and preceded the code example they refer to.

 

A number of people have suggested breaking it up into smaller pieces. I know it's very long, as tends to be my want, but I also thought that if it was meant to be a "guide" then it should all be on one page to save people from having to click around. 

I think I may release it to my blog in a few pieces, but have a link back to the whole document as well (as someone suggested - I can't remember who - maybe John?)

It's a bit dense, but I like it as one. If there are sections that are worth elaborating on a bit, maybe blog posts would work well there. It'd be nice if this was a living document too, as you may want to tweak along the way. Maybe a candidate for a GitHub wiki page, with revision history all built in, and open for collaboration should you deem fit?

 

Cheers,

Jamie

[Jamie Krug]

One other thought... If you and Adam are working in feature branches, there's really no concern for messy log history, right? So maybe merge away, and then when one of you is ready to prep that feature branch for the develop line, you can rebase and/or squash and then bring it into develop. Make sense? If there are also changes happening in develop that you want to rebase along the way, then you of course need to be careful about any commits you've pushed to a public repo for that branch.

[Jamie Krug]

Bob, another thought on the lengthy document concern: wiki-like table of contents at the top, to bookmark any logical sections?

[Jamie Krug]

Okay, I'm digging a little deeper and learning a bit more... As it's been stated by others, a potential challenge of using Git is simply the fact that it's so powerful and flexible! There are multiple ways to accomplish the same thing, and there are various workflows that can be created to suit a project's or team's need.

In any case, after reading your post again, Bob, along with the reference links you provided, I think I might be more comfortable with simplifying Rule #2 and #3 (under "Keep your repo up to date with the main repo"). By the way, my idea here, which may be flawed, is derived from the http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html post.

So, after creating a feature branch and working on it, e.g.,

git checkout -b newFeature

# ...commit early, commit often...

Your document currently suggests something like the following, which keeps your develop branch up to date with upstream, as well as your feature branch (note: starting within "newFeature" feature branch):

git checkout develop

git pull --rebase upstream develop

git checkout newFeature

git rebase develop

My question is, can we simplify this to the following (note: starting within "newFeature" feature branch, again)?

git fetch upstream develop

git rebase upstream/develop

This definitely has the same net effect on the "newFeature" branch, right? I do realize that my own "develop" branch would not be current with upstream at this time, however if my feature branch is continuously rebasing on upstream/develop, then I should be fine when I finally do this:

git checkout develop

git merge newFeature

My thinking is that Git is smart enough to recognize those commits that came from upstream/develop, and this will just be a fast-forward merge. I could then push to my fork and send a pull request. Since I should never do anything to my "develop" directly anyway, other than a clean fast-forward merge from a recently rebased feature branch, I see no risk and this feels a bit more direct to me.

Are my assumptions correct? Am I missing something else? Opinions?

Thanks!

Jamie

[Bob Silverberg]

Did you experiment with this option? I did and found issues, but I
might have had too many variables in play. It was the first thing I
tried, as it made the most sense to me too, but I ended up getting
strange conflicts that I didn't understand when I did this.

I'll try a few more experiments to see if I can simulate a workflow
with this that doesn't cause problems.

By the way, thanks so much for all of your valuable feedback Jamie.
Sorry I've been a bit busy to reply to each one.

Cheers,
Bob

[Jamie Krug]

On Fri, Sep 10, 2010 at 3:36 PM, Bob Silverberg <bob.sil...@gmail.com> wrote:

Did you experiment with this option? I did and found issues, but I
might have had too many variables in play.  It was the first thing I
tried, as it made the most sense to me too, but I ended up getting
strange conflicts that I didn't understand when I did this.

I have not experimented, but I will. I have an article deadline fast approaching, so I may go quiet for a few days, but I'll come back to this.

 

By the way, thanks so much for all of your valuable feedback Jamie.
Sorry I've been a bit busy to reply to each one.

You bet, and no problem!

Best,
Jamie

[adam drew]

so after a week of making furious changes to the framework, while bringing myself up to speed on github, mxunit, bob's new project workflow, and keeping two remote development machines in sync... all at the same time.. .. I should probably just admit that I have broken every one of Bob's rules at some point this week..

The main problems that still stand out for me right now include (but are not limited to):

 1. working off of my develop branch directly...
     a. there is no real excuse here, but I would like to explain why I did this the way I did,:
          I split my development time between two machines daily... It was hard to make all the changes i wanted and need to make, while follow the workflow, and keeping the dev machines in sync..

2. I  did not use git --rebase once :-/
   a. i did do a lot of work on feature-branches, but I did alot of  "$git merge --no-ff bob/adam_develop" && "$git merge --no-ff feature-[name]"  on develop.

 

   b. i pushed and merged my remote branches often (at some points, I may have even pushed incomplete or not working code to my remote so could pull it and pick up exactly where I left off on my *2nd machine)

   c. I got a gut feeling that I shouldn't squish all of my commits, this way any other contributor can see exactly what I've done and where I'm at, and also so that I could retrace all my steps in some complex branching situations where I at one time had 3 different branches I was doing work in that utimately needed to come down to develop.

   d. I'm also not sure how we will be able to really collaborate if we keep squashing exactly what we are doing during our individual development.. I can the need to do this when pushing to the Framework master or release branchs..

   e. then again there, are two sides to every coin and maybe I will make a stupid comment or coding mistake that I don't want the rest of the team to see...

I guess what I'm trying to say here is that we really need to be careful when setting up the rules/guidelines for  our collective git workflows... It will come with trial and error that we figure out exactly what will be the ideal workflow for the team  

Also, thanks for all the insight that you've provided here Jaime. and thanks to Bob for all the patience he had with me this week.

Happy Weekend,
Adam.

[adam drew]

one additional Rule # that I have learned to accept this week, and also hope to see Bob reiterate in his workflow document, is that you should never, ever, push any changes to a remote/upstream branch without having first run alll of the included framework tests or added the new tests required to check for your code... you only save everyone else the extra work of chasing things down by doing so.

Regards,
Adam

[Bob Silverberg]

Adam, and others,

This was a good chance to test out aspects of the workflow, but it was
also not done in a manner in which I would hope things would happen in
the future. I do agree that there are probably flaws in my proposed
workflow, and we're going to have to find and fix those as we go
along.

I will address your individual points below, but start by discussing
why I think this experience was different that what I had envisioned.
The workflow I described is aimed at adding small features and bug
fixes. You identify one thing you want to do, you implement it, and
you send your pull request. What Adam and I did, on the other hand
was work through some submitted changes that impacted many different
areas, and were also both incomplete and buggy. This is not meant as
any sort of criticism of you or your code, Adam. I just want to point
out that it's not the way I imagined folks using the workflow.

So given that a single pull request affected dozens of files in
numerous ways, and a lot of back and forth was required to identify
bugs and missing functionality, I don't think it was a good test of
the proposed workflow. Again, I do agree that the proposed workflow
isn't perfect, but I also think that we might want to try it out again
on a much smaller scale, such as a bug fix or adding an individual
feature.

Now let me respond to your note...

On Fri, Sep 10, 2010 at 7:40 PM, adam drew <epn...@gmail.com> wrote:
> so after a week of making furious changes to the framework, while bringing
> myself up to speed on github, mxunit, bob's new project workflow, and
> keeping two remote development machines in sync... all at the same time.. ..
> I should probably just admit that I have broken every one of Bob's rules at
> some point this week..
>
> The main problems that still stand out for me right now include (but are not
> limited to):
>
>  1. working off of my develop branch directly...
>      a. there is no real excuse here, but I would like to explain why I did
> this the way I did,:
>           I split my development time between two machines daily... It was
> hard to make all the changes i wanted and need to make, while follow the
> workflow, and keeping the dev machines in sync..
>

I too ended up working off of a sort-of development branch. I created
a branch called adam_develop which coincided with Adam's develop
branch, and I made all of my changes there. I didn't create feature
branches off of that. I think part of the reason was that I just
didn't see the proposed workflow as applicable to this situation. I
just wanted to try to get something working and stable asap.

As for the two machines issue, you could still use feature branches
and just push and pull those to and from the two machines, couldn't
you?

> 2. I  did not use git --rebase once :-/
>    a. i did do a lot of work on feature-branches, but I did alot of  "$git
> merge --no-ff bob/adam_develop" && "$git merge --no-ff feature-[name]"  on
> develop.
>

I did use git rebase from time to time, but I also used merge. I was
concerned because of all the pushing and pulling that was going on
that rebase might be dangerous. Again, I wasn't concerned too much
with following the rules on this one.

>
>    b. i pushed and merged my remote branches often (at some points, I may
> have even pushed incomplete or not working code to my remote so could pull
> it and pick up exactly where I left off on my *2nd machine)
>

This was necessary as we were both working on the exact same code.
That's not really what the workflow is aimed at. I think that if two
developers need to work on the exact same feature then some changes
are required - probably creating a new, shared branch that gets pushed
to remotes. Possibly even a single shared branch that lives on the
main repo.

>    c. I got a gut feeling that I shouldn't squish all of my commits, this
> way any other contributor can see exactly what I've done and where I'm at,
> and also so that I could retrace all my steps in some complex branching
> situations where I at one time had 3 different branches I was doing work in
> that utimately needed to come down to develop.
>

The idea of git rebase -i to squash commits is really about committing
often, like every 30 minutes or so (or even more), and then squashing
commits that are really one unit of work. I do not want people to
squash commits that will hide history. I think each piece of work
should have its own commit, but let's say you are doing some work and
it takes you a couple of hours to complete one feature. Let's also say
you commit every 30 minutes, just because it's a good idea. You then
have 3-4 commits which are all about the same piece of work - it just
happened to take you a couple of hours to complete it. Perhaps some of
those commits represent incomplete work - maybe some tests are
failing. Those are the commits that I think it is worthwhile to
squash.

Does that make sense and does that address your concern about
squashing commits? Maybe the way I describe it in the document makes
it sound different than I just described above.

>    d. I'm also not sure how we will be able to really collaborate if we keep
> squashing exactly what we are doing during our individual development.. I
> can the need to do this when pushing to the Framework master or release
> branchs..
>

See above. And also I think this relates to the need to have different
workflows for individual development versus collaborating on a
feature. If you compare this to the way you'd do it with SVN, ask
yourself: how often would you commit to SVN? Would you do it
frequently to protect yourself, or would you wait until an entire
feature was complete before committing? If the latter then I suggest
that you can commit more often using Git, but still end up with larger
commits in the repo as you would have had with SVN.

One other note on this, based on my own experience of this week: For
the most part I did not look at your commits, I only looked at the
changes to the files when I had a pull request. The GitHub pull
request system is amazing for this - it shows you every file that
changed and all of the changes. I found this invaluable as I don't
have a decent tool to do this locally yet. So going back to your
comment that it will be hard to collaborate if a developer squashed
their commits - that would not have affected me at all. I do agree (as
I've stated above) that I don't think that commits that relate to
different changes should be squashed together, but I also wanted to
point out that even if you had squashed all of the commits that went
into a single pull request together it wouldn't really have affected
me personally.

>    e. then again there, are two sides to every coin and maybe I will make a
> stupid comment or coding mistake that I don't want the rest of the team to
> see...
>

Yes, another advantage to committing often and rebasing.

> I guess what I'm trying to say here is that we really need to be careful
> when setting up the rules/guidelines for  our collective git workflows... It
> will come with trial and error that we figure out exactly what will be the
> ideal workflow for the team
>

I agree 100%. I am totally open (contrary to how it may sound from my
response) to making changes to the workflow and/or the "rules" as we
discover what works and what does not work.

> Also, thanks for all the insight that you've provided here Jaime. and thanks
> to Bob for all the patience he had with me this week.
>

I second the thanks to Jamie, and Adam it was my pleasure. For those
of you you have no idea what Adam and I were up to (which I'm assuming
is all of you), Adam did a ton of work not only on new features he
added but on cleaning up a lot of stuff, and coming up with an
improved way of testing SRVs.

> Happy Weekend,
> Adam.
>

Ditto,
Bob

[Bob Silverberg]

Very good point, Adam, and you have done a ton of work to make running
those tests much easier than it was, and are also living proof that
one can learn to write unit tests for the framework. ;-)

Having said that, I don't want to create barriers to contributions, so
if some people don't feel up to writing tests for their contributions
I think we can live with that. I just means that someone else is going
to have to write them. It would certainly be better if people wrote
tests, preferably first, but I don't plan to make that a requirement
(not yet, anyway).

Running the tests prior to sending a pull request is a very good idea,
though, and I think that should be mandatory. With the work that Adam
did it should be very easy for anyone to run the suite of unit tests,
and I hope to make some changes to the tests to make it even easier.

How do people feel about that becoming a requirement? Is that too
harsh? Will it deter any of you from contributing (just the running
of the tests, not having to write tests for new stuff)?

Cheers,
Bob

[Marc Esher]

I'd even go further as to say "the first thing you do when you want to
become a contributor is run the tests. when they go green, that's your
greenlight to start writing code".

People can waste a lot of time -- theirs and yours -- if they jump in
, start coding, then say "oh, huh, I better run tests", and then they
get all manner of red and start banging down your door.

Ergo: baseline green should be a requirement. It's your cover charge,
so to speak.

[Bob Silverberg]

Very good point, Marc. That will become the "Marc Esher Rule". "Run
the tests or be kicked to the curb".

[Marc Esher]

I can see a pulp fiction moment:

Bob: "How many tests passed?"

New Contributor: "All of them"

Bob: "How many?

NC: "All. yeah. All, Right?"

Bob: "Give me a number!"

NC: "what?"

Bob: "Say what one more time"

.....

On Fri, Sep 10, 2010 at 9:59 PM, Bob Silverberg

[Bob Silverberg]

OK, I did a couple of simple tests and found that:

git fetch upstream develop

git rebase upstream/develop

did not work for me. It actually produced errors, so I'm not sure what the issue is.

I'm pretty sure, however, that:

git pull --rebase upstream develop 

will do the exact same thing (i.e., a fetch plus a rebase), and in my tests that seemed to be OK.  I call these simple tests as it was just pulling in changes from upstream that did not affect the same files as changes that existed in my feature branch.  I'll try another test that's a bit more complicated later today.

So for now it looks like forgetting about the develop branch until it's time to merge back in is a good idea.

Thanks for the suggestion,

Bob

[Bob Silverberg]

I just did a more complex test and it seemed to work too.  I think I know why I encountered problems with this technique before, but I'm not going to bore you with the details.  I'm going to make some updates to the document to reflect everyone's feedback.

Cheers,

Bob

[Bob Silverberg]

One thing I realized while editing the document is that, with this approach, you can no longer use:

git rebase -i develop 

to squash all of the commits in your feature branch.  In fact that would be disastrous.

This is probably indicative of a problem with that rule, which Adam took issue with, and I concurred that you really only need to squash commits when they are meaningless.

So I think I'll update the document to make the squashing optional and to explain that it should be done more often as well, not just at the end before merging. Folks will also have to use the HEAD~n notation, rather than the simple branch notation to make it work along with the rebasing directly from upstream develop.

Cheers,

Bob

[Mark Mandel]

As an interesting aside -

Bob, does it really matter what external developers are doing on their own work? (assuming you are not working with them collaboratively)

Reason being, if you get a pull request from someone, they tell you their repo, and their branch, you create your own local branch from the current develop, and do a pull into that branch.
 
From there you can rebase -i until your heart is content, and squash anything you think is superfluous to the git commit history.

Once you are happy, you can merge back into your develop branch, and push back up to remote.

Would that not work out?

I mean, you may end up with a few extra merge's in your commit history, but *shrugs* is that such a big deal?

Mark

--
You received this message because you are subscribed to the Google Groups "ValidateThis-dev" group.
To post to this group, send email to validate...@googlegroups.com.
To unsubscribe from this group, send email to validatethis-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/validatethis-dev?hl=en.

--
E: mark....@gmail.com
T: http://www.twitter.com/neurotic
W: www.compoundtheory.com

cf.Objective(ANZ) - Nov 18, 19 - Melbourne Australia
http://www.cfobjective.com.au

[Bob Silverberg]

Yes, that would work, but I'd rather not have to do that for a couple of reasons:

1. It's more work for me to have to choose which commits to squash and which to keep.

2. I am not in as good a position as the original developer to choose which commits should be kept and which should be squashed.

So it definitely would work, and could be used as a "last line of defence" against multitudinous meaningless commits, but my preference would be for folks to do this themselves.

Also, this document is meant as a guide to the various steps involved in using Git to collaborate, so I thought it worthwhile to inform new developers of this option.

I am in the process of editing the document right now, and I have changed the wording of the section on interactive rebase, and have indicated that it's an *optional* rule.  I'm hoping to publish a new version today and look forward to everyone's feedback on whether it is an improvement over the old version.

Cheers,

Bob