Re: New branch for No Gnus

[Steinar Bang <sb@dod.no>]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> Just to be totally sure I'm not screwing anything up:  Should I do a
> "git pull" in my local No Gnus tree before saying "git revert -m 2
> HEAD", and then pushing out, or should I just do the revert without
> pulling from git.gnus.org first?

I assume that this is the fix to the messup that was mentioned earlier
in the thread?

I've never used git-revert myself, but I would have done it this way:
 git checkout no-gnus
 git revert -m 2 HEAD
 git push -f origin HEAD

I could try to explain the logic behind this...?  Or I could just mention
chapter 3 of "Pro Git" again...:-)

Briefly:
  - if you do "git branch" you will see all local branches in your git
    repository.
  - If you do "git branch -a" you will see more branches, some with
    "remotes/origin/" in front of them.
  - All local branches exist only in your local .git directory (they do
    not exist upstream (though for tracking branches (mentioned later)
    that is a question of semantics...))
  - You can only check out and work on a local branch
  - Some local branches have a special relationship with a remote
    branch.  These local branches are called "tracking branches".  In
    your case, no-gnus and master are tracking branches
  - When you work on "no-gnus", you can't update
    "remotes/origin/no-gnus" to have the same commits, in other way than
    pushing the commits on "no-gnus" to origin.  So what I did over, was
    to: 
     - check out the local tracking branch no-gnus
     - revert the last two commits on that branch
     - push the current state of the branch to no-gnus on the remote
       called "origin", updating the "remotes/origin/no-gnus" branch in
       your local .git directory in the process
     - the "-f" ("force") flag to push is necessary to make it drop
       commits already on the branch in the origin remote