From: "Magnus Bäck" <magnus.back@sonyericsson.com>
To: garyc618 <gary.carter@eigen.com>
Cc: git@vger.kernel.org, Ilya Basin <basinilya@gmail.com>
Subject: Re: merging bare repository
Date: Mon, 6 Jun 2011 23:54:33 +0200 [thread overview]
Message-ID: <20110606215433.GC29348@jpl.local> (raw)
In-Reply-To: <1306807292356-6421097.post@n2.nabble.com>
On Tuesday, May 31, 2011 at 04:01 CEST,
garyc618 <gary.carter@eigen.com> 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@some.org/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
next prev parent reply other threads:[~2011-06-06 21:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-13 10:51 merging bare repository Ilya Basin
2011-05-13 13:53 ` Magnus Bäck
2011-05-13 20:56 ` Enrico Weigelt
2011-05-31 2:01 ` garyc618
2011-06-06 21:54 ` Magnus Bäck [this message]
2011-05-13 13:54 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110606215433.GC29348@jpl.local \
--to=magnus.back@sonyericsson.com \
--cc=basinilya@gmail.com \
--cc=gary.carter@eigen.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).