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
