2009/2/6 Tim Jenness <[log in to unmask]>:
> On Fri, 6 Feb 2009, David Berry wrote:
>
>> Personally I'd feel more comfortable if, at least for the moment, I
>> had some fixed patterns for working with git. Two situations occur to
>> me:
>>
>> A) A minor tweak to the master branch
>> B) A major new development
>>
>>
>>
>> Thinking firstly about A), how would this be:
>>
>> I'll work in the working directory that was created when I cloned the
>> origin/master, on the assumption that the majority of the existing
>> built files in that working directory will be appropriate for me to
>> build and test the bug fix. So
>>
>> 1) git pull      # Ensure we're starting from a current master
>>
>> This reduces the chances of conflicts arising with other people's work
>> later on. After all, someone else may already have fixed the bug.
>>
>
> they have to remember to push it back :-)
>
>> 2) git branch bug-fix      #  Create a branch to work on
>>
>> I should be safe to re-use a single fixed branch name such as
>> "bug-fix" since I'll be deleting the branch at the end of each bug
>> fix.
>
> yep
>
>>
>> 3) git checkout bug-fix      # Check out the new branch
>>
>
> Yes. "git checkout -b bug-fix" may be able to combine 2 and 3 (it creates
> the branch)
>
>> 4) Edit the source files, build the changed system, and test until the
>> bug is fixed.
>>
>> 5) git commit -a      # Commit the changed files to the bug-fix branch
>
> Or commit little bits as appropriate. I'm thinking that git commit -a
> could be dangerous at times so make sure you use $EDITOR to type in your
> comment rather than -m so then at least you can see if it is going to
> commit something extra.

OK. I have EDITOR set so I get chance to review the commits before
accepting them.


>>
>> The commands in step 6) have to be done quickly to minimise the chance
>> of anyone else pushing new stuff to master in the middle of it all.
>>
>> 6) git checkout master      # Go back to the master branch
>>    git pull                           # Get any changes made whilst
>> I've been fixing the bug
>>    git checkout bug-fix      # Go back to the bug-fix branch
>>    git rebase master         # Modify the bug-fix changes so that
>> they can be applied to the current master HEAD
>>    git checkout master      # Go back to master
>
> you can insert a git pull at this point just to make sure that no new
> patches have arrived.

Except if new patches were pulled here, my bug-fix changes would no
longer be re-based at HEAD correctly.

>>    git merge bug-fix          # Append the bug-fix changes to the end
>> of the master branch
>>    git push                        # Send the modified master branch to JAC
>>
>> 7) git branch -d bug-fix     # Delete the bug-fix branch
>>
>> This leaves the built files in the working directory in sync with the
>> current master HEAD.
>>
>
> Yes.
>
>>
>> So question one, does this over-all scheme seem correct, and question
>> two, are the git commands I've used to implement this scheme correct?
>>
>
> Looks okay to me (but I've got it all wrong before :-)
>
>
>>
>>
>> Going on to B) - handling a major new development. The difference is
>> that I will need to keep swapping back and forth between the new
>> development work and day-to-day bug-fixes on master. So I should use a
>> separate working directory for the new development work so I do not
>> need to re-build everything from scratch each time I swap branch:
>>
>> 1) git pull    # Ensure master is up to date
>>
>> 2) git-new-workdir /path/to/my/repo /path/to/new/workdir  # Create a
>> new working directory containing a checkout of master
>>
>> 3) cd  /path/to/new/workdir
>>
>> 4) git branch ast-stcs    #  Create a new branch with a unique name
>> that identifies the development work being done
>>
>> 5) git checkout ast-stcs    # Checkout the new branch
>>
>> 6) Make edits, build, test
>>
>> 7 ) git commit -a
>>
>
> if you don't feel like you are commit worthy you can use git-stash at this
> point.

Since the ast-stcs and bug-fix stuff each have their own working
directory, a stash wouldn't be needed would it? That is, I'm about to
change directory, so my current edits wont get changed.

>> 8) Brad reports a new AST bug...
>>
>> 9) cd /path/to/main/workdir
>>
>> I'm assuming that the main workdir still contains a checkout of
>> master. Maybe I should refer to "master/workdir" rather than
>> "main/workdir" above...
>
> I have not tried this workdir switching scheme so am not sure how it knows
> that each tree is a different branch.

I've given it a go, and it does work. If you check out a different
branch in each working directory, then "cd" into each directory, "git
status" shows a different current branch in each directory.

>>
>> 10) Do the bug fix and push the changes to JAC as per scheme A) above.
>>
>> 11) cd  /path/to/new/workdir      # which still contains a checkout of ast-stcs
>>
>> 12) Loop back to step 6) until the development work is ready for use
>> by others. Then proceed with step 13)
>>
>> 13) cd /path/to/main/workdir
>>
>> 14) git pull
>>      git merge ast-stcs
>>      git push
>>
>> No rebase here in order to retain visibility of the ast-stcs branch.
>
> In my opinion I'd call
>
>   git rebase master
>
> from ast-stcs every day just to keep up to date (most of the patches will
> be irrelevant to ast-stcs development). Knowing that you branched from
> some commit 2 months ago and have now merged does not provide additional
> information. You also have to handle merges all in one go whereas a daily
> git-rebase forces you to resolve conflicts as soon as they would occur
> (which may or may not be a good thing if you have completely rewritten
> the ast source code (such as the threading work) since every time you
> tweak trunk you'll have to work out how that tweak applies to the branch -
> this is what git-rerere is for but I think it's too early for that). Any
> ast patches you've done in trunk will then automatically be integrated
> into your dev branch. Without a daily rebase you end up doing one major
> merge and conflict resolution all in one shot.
>
>>
>> Comments???
>>
>
> You may want to consider simply having two clones, one for your heavy
> development and one for minor bug fixes. May be less confusing.

The git-new-workdir approach seems to be working. I don't suppose I
should say this, but it gives the whole system a bit more of an SVN
feel to it...

I've produced two scripts, one for major works and one for small,
quick changes that implement the above ideas. So hopefully I will at
least be consistent in the stuff I'm pushing to JAC.

David