Re: News...

[Thomas Schwinge]

Hello!

On Wed, Jul 08, 2009 at 12:38:28PM +0200, Arne Babenhauserheide wrote:
> Am Dienstag, 7. Juli 2009 19:10:15 schrieb Thomas Schwinge:
> > The instructions from
> > <http://lists.gnu.org/archive/html/bug-hurd/2008-11/msg00129.html>
> > basically still apply, replacing homepage with master-news_next, of
> > course.  If there are concrete questions about how to handle these two
> > branches (master and master-news_next), then please ask -- before pushing
> > experiments to flubber.
> 
> Just to make sure I understand it correctly: That means I use the following 
> commands: 

First, there are two options: you can have separate repositories
(*clones*, or *checkouts*; what you get from ``git clone'') for the
master and master-news_next (not master-next_news, by the way) branches,
or you can deal with both in the same repository.  Having separate
repositories you don't have to remember which branch you're on, and don't
have to switch between branches before beginning to edit files, and it
doesn't matter -- as no switching between branches is needed -- if you
have uncomitted changes to some files.  On the other hand, you may want
to keep it all in one repository, to save disk space, and for shuffling
different branches' commits being (a bit) easier.

> ## get the latest version of next_news
> 
>       git fetch && git checkout -b master-next_news origin/master-next_news

Use the ``git checkout -b master-news_next ...'' command to *create* a
local news branch.  That only has to be done once (unless you remove that
branch later on -- ``git branch -d ...'').  Once you have such a branch
(check with ``git branch'', or ``git branch -a'' to also see the remote
branches) you'd just do ``git checkout [branch]'' to change your
repository to the [branch].

Always do check which branch you're on (asterisk in the first column of
``git branch'''s output), and only then begin to do your changes and
commit them.  (Of course it is possible to move commits between branches,
but you can also simply avoid having to do that.  Talk to me in case it
should be needed and you can't figure out for yourself how to do it.)

> ## check the outgoing changes
> 
>       git log --reverse -p -C -M master-next_news..origin/master-next_news

``-M'' is redundant, I think.  One might want to use ``--cc'' to see if a
merge introduces additional changes (to resolve conflicts and the like),
but that shouldn't be relevant for your use case.  And I got it the wrong
way round in my older email: it should be ``origin/[branch]..[branch]''
to see the changes needed for getting from origin/[branch]'s state to
(local) [branch]'s state -- those we're going to push.

> ## push the changes
> 
>       git push master-next_news

You also have to specify to which repository to push (typically named
origin), in front of the branch head to push.  Then, this command will
transfer the reachable commits to the remote repository and update its
(the remote's) notion of master-news_next to the ID of your last commit
on that branch.

> ## if push fails, fetch and rebase
> 
>       git fetch && git rebase origin/master-next_news

Correct.  Note that this might cause some conflicts to arise -- if the
remote repository contains commits that conflict with any that you've
been recording in your local repository.  For this reason, you might want
to already do this *rebase* before beginning you local edits, simply to
shorten the time frame in which such conflicts can arise.
(Theoretically, in the very rare case of very much concurrent editing
going on, you'd have to repeat this again (and again...) before
succeeding to push your changes.)  Additional explanation: if your branch
is in a state where it doesn't contain any commits that are not yet as
well in the remote repository (or the other way round: it only contains
commits that are as well in the remote repository) -- that is, after a
successful *push* to the remote repository -- this *rebase* will in fact
be a *fast-forward*: it will simply add the commits
[branch]..origin/[branch] (which are those that are in the origin
repository's branch, but not in the local one's) on top of your current
branch, which is the work that others have pushed to the remote
repository in the mean time.


Further questions?


Regards,
 Thomas

signature.asc
Description: Digital signature