On Tuesday, May 31, 2011 at 04:01 CEST,
garyc618 <gary.carter@xxxxxxxxx> wrote:
> Magnus Bäck-2 wrote:
[...]
> > To deal with upstreams like this I recommend you place the upstream
> > branch(es) in a separate namespace prefixed by <upstreamname>/, e.g.
> > github/master if your upstream is the master branch from the
> > official Github repo of the project. Example:
> >
> > git fetch ssh://git@xxxxxxxx/git/project.git
> > git push ssh://git@server/git/project.git FETCH_HEAD:github/master
> >
> > If you mirror the upstream branches like this on your server merges
> > from upstream becomes trivial[*],
> >
> > git merge origin/github/master
> > git push ssh://git@server/git/project.git HEAD:master
> >
> > and can be done on any workstation plus it's easy for your users to
> > e.g. see what they've been up to compared to the upstream:
> >
> > git log origin/github/master..origin/master
> > [...]
> >
>
> Could you explain more about how this works - where do I find the
> character string to use instead of "github". It can't be arbitrary,
> I got an error message.
Can you be more specific about the error message? The string *is*
arbitrary. The only thing I can think of is that you need to specify
refs/heads/github/master rather than just github/master in the push
operation.
> When I did the fetch it said
> *branch HEAD -> FETCH_HEAD
> could you explain what this means in more detail?
Someone might need to correct my here, but I guess it means that the
local symbolic ref FETCH_HEAD has been updated with the contents of
the server-side symbolic ref HEAD. The important part to remember
here is that FETCH_HEAD is a useful shorthand that represent what you
got in the last fetch operation.
Come to think of it, the first example commands that you're commenting
might not necessarily do what you want. It's probably a good idea to
specify the ref explicitly instead of FETCH_HEAD, e.g. origin/master,
or just fetch the branch you want. I don't know what FETCH_HEAD contains
when multiple refs are fetched.
> We enthusiasts-who-don't-have-time-to-become-git-masters really need
> some well explained examples if we're going to be able to convince
> management that git is not some super complicated tool that takes
> weeks to learn.
If you're the one who's going to be managing your source code
repositories, any tool for this task will take weeks if not months to
master sufficiently well. Learning how to use a source control system
like Git isn't just about learning the tool itself -- that part is
usually easy. Regardless of the choice of tool, you'll have to learn its
ins and outs and how to apply it to your probably already established
processes, and/or how you should change your processes to adapt to the
tool (you probably need a little bit of both).
Any manager claiming that doing this properly is trivial with any tool
shouldn't be making decisions about this. Really.
> The particular use case described in this thread is the last sticking
> point I have to make work before I can show git doing everything we
> need it to do to my management.
Luckily integrating upstream development with your own is easy with Git
and probably all other distributed version control systems. I think it's
one of their major strengths.
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html