On Wed, Feb 16, 2011 at 09:38:43AM -0200, Daniel Trezub wrote:
> > In any case, I have two points to tell:
> > 1) When fetching from a remote repo, to make a remote branch named
> > "online" end up as remote/origin/master you would have to pass
> > git-fetch a specially formed refspec; I assume you did not do this,
> > so probably the problem is elsewhere.
> Not exactly. The "online" branch is local. The remote repo is a newly
> created one, and thus does not have any branches in it. But I´ve read
> somewhere that a git fetch would just get the content of the remote repo to
> the current branch.
That is very wrong. Possibly you confused git-fetch with git-pull,
which, in one of its modes of operation, does git-fetch of a specific
remote branch and then merges what it fetched into the currently checked
out local branch.
> So, if I do
> git checkout online
> git fetch
> I expected to get all my remote content into my current branch "online", and
> not in a new branch "remote/origin/master". But it is ok, not a big deal, as
> it is easily managed (as I can create a new local branch from
To modify your example to achieve what you described you'd do this
$ git checkout online
$ git pull origin online
That one would download the "online" branch from the "origin" remote and
merge it to your local "online" branch.
To quickly get the idea behind git-pull, skip to the "EXAMPLES" section
of the git-pull manpage, and after you understand that section, rewind
back and read in completely -- that way there are much higher chances to
grok it, in my opinion.
> Then, I´d like to be able to merge or rebase my local master branch (that
> holds my release version) with this local online branch (that would hold my
> actual copy of the live site), and then git pull everything to the live
> site. That would be beautiful.
> BUT when I try
> git checkout master
> git rebase origin/master
> git checkout origin/master
> git rebase master
> (anyways, whitch is the right way to do it? I couldn´t find a clear
> explanation and the rebase sintax is a bit confusing)
Never ever check out remote branches unless you're clearly intending to
do this (but I have not yet any idea about where this could be useful).
Hence, your first example seems to be more sensible.
Rebasing appears to be complex, but in fact it is not so, once you start
thinking in terms of patches:
$ git rebase TARGET
essentially does this:
1) finds a common ancestor between the HEAD and TARGET;
2) resets the HEAD to point exactly to TARGET after saving all the
commits HEAD has compared to TARGET;
3) applies patchsets represented by those commits one by one in a
chronological order on top of HEAD, advancing it after each
successful application which results in a commit.
I fail to see why you did not find a clear explanation of this because
much the same text is written in the first 20 or so lines of git-rebase
manpage, I just rephrased this differently hoping it will help.
> I get a merge conflict for every single file in the repository (even the
> ones that are listed in the .gitignore file). This is weird because I know
> that only 10 or 12 files where really modified in my local branch. Besides
> that, the merge shows me all files as conflicts but both versions are
> exactly the same in local and in remote.
> I know the files are exactly the same because the master branch is my local
> testing environment and right now it is just like my live site (i.e. no
> development has been made locally or remotely). Weird.
I cannot say anything on this, as this heavily depends on what data you
have in your repositories.
Probably you're just doing something wrong.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to firstname.lastname@example.org.
To unsubscribe from this group, send email to
For more options, visit this group at