[asdf-devel] announce: ASDF 1.359

[Robert Goldman]

Stelian Ionescu wrote:
> On Wed, 2009-08-19 at 10:25 -0500, Robert Goldman wrote:
>> Gary King wrote:
>> ...
>>>   * moved defgenerics to their own section because I like it that way.
>> ...
>> I think that this is a fine thing to do, but it makes for a miserable
>> merge.  The next time you are going to do this, would you mind pushing a
>> version with all the normal patches, then push a second version with the
>> code blocks moved?
>>
>> Alternatively, would someone please provide simple recipes for dealing
>> with git?  It's really far more complex than CVS, and I don't see
>> obvious patterns of interaction to do simple things like restore
>> synchronization with the central repo.
> 
> git fetch origin
>  downloads latest commits
> git reset --hard origin/master 
>  nukes all local changes, synchronizing with the remote repo

Would it be possible for us to add a short git briefing to the ASDF web
page materials?

At the bottom of the message is what I have from the org-mode folks (now
very old), which I've found helpful.

Note that they suggest, for simplicity, putting all your local changes
for a particular topic on a branch, and keeping your local master as a
clean reflection of the remote origin.  Each time you want to make a
single change, you just make a new branch.  Is this a reasonable

One of the things these instructions aren't great about is filling in
how to pull changes from remote into your local development branch
(through the master).  They also don't touch on resolving conflicts.  I
have read about this on the web, and find the advice there conflicting
and confusing.

Also, is git diff the best way to generate patches?  I know that there
are ways to generate patch emails from git, but don't know how to make
them work if (like me) you don't run sendmail, procmail, etc. on your
local machine.

Thanks,

R


-------------------------------------------------------------

1. get the latest changes

    git pull

2. create a branch for you to do your changes

    git checkout -b my-doc-fixed

3. Edit the file you want to change

    $ emacs ....
    $ emacs ....

4. Commit the changes when you feel like it

    git add doc/org.texi
    git commit

5. Create a patch

    git diff master > send-to-carsten.patch

6. Go back t the master branch for normal use of Org-mode.
    Do this only after committing all changes.

    git checkout master

This all works fine when you don't pull new changes while
working on your patch.  If Org changes while you do your work,
you can do this:

- commit your changes as described above.
- switch back to master

   git checkout master

- get new changes

   git pull

- return to your branch

   git checkout my-doc-fixes

- make sure your changes are made relative to the current, new master:

   git rebase master

- continue working on your patches.

The only problem here is that git rebase can fail if there is overlap,
so my recommendation for he beginner is to just use the workflow
shown above.