git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: "Patrick Neuner - Futureweb.at" <neuner@futureweb.at>
Cc: Andreas Ericsson <ae@op5.se>, git@vger.kernel.org
Subject: Re: Parallell Development / Switching to GIT
Date: Sun, 28 Jun 2009 14:47:14 -0400	[thread overview]
Message-ID: <20090628184714.GA8634@sigio.peff.net> (raw)
In-Reply-To: <B81058949321C8439B9D742F5F8D8FCA01A75C1D@hpserver.intranet.local>

On Sun, Jun 28, 2009 at 07:51:26PM +0200, Patrick Neuner - Futureweb.at wrote:

> 1) What if I only want to merge a specific file/directly, but not the
> whole branch, is there a way?
> [...]
> The reason is, that external developers will only commit to
> development branch.  They are working on new features, and sometimes
> some small bugfixes, or design templates.  Those need to be merged
> separately, and we try to not have more branches. As developers can
> access our testserver and then see what they have done and test
> functionality.

For the situation you describe, it is not about merging a specific
_file_, but rather you want to pick specific _commits_ from the
development branch that have the bugfixes (or whatever) that you need,
and merge the changes introduced by those commits (but not the rest of
the history).

And that is easy to do; it is called cherry-picking, and you can use
"git cherry-pick" to pick specific commits from development to master.

> 2) We are using gitosis to give external developers access to the
> branches and have some kind of access restriction.  But we are only
> able to limit push rights, not pull rights. In most cases, that's not
> a problem, if they see master And development, but sometimes (like for
> external designers), we might want them to only be able to checkout
> some directories.

There are two ways you can split access, and one will work but the other
will not.

In git, you generally cannot split your data by _tree_. That is, you
cannot say "here is all of the history for the master branch, but you
are only allowed to look at some subset of the files." Because at a
fundamental level, git is about tracking changes to the _whole_ set of
files over time, and it makes the assumption that if you have commit X,
which points to tree Y, which points to files A, B, and C, that you will
have the data for X, Y, A, B, and C in your repository.

However, if you have your data split by _history_, that might work. That
is, if you have a "master" branch and a "development" branch, you can in
theory say "you may look at the history of master, but not of
development". The usual way to do that is to actually keep "master" and
"development" in two different repositories, and only grant read
permission in the filesystem for the "master" one (which obviously
implies doing your reading over something authenticated, like ssh).

Hope that helps,
-Peff

  reply	other threads:[~2009-06-28 18:46 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-25  9:52 Parallell Development / Switching to GIT Patrick Neuner
2009-06-25 10:11 ` Andreas Ericsson
2009-06-28 17:51   ` AW: " Patrick Neuner - Futureweb.at
2009-06-28 18:47     ` Jeff King [this message]
2009-06-28 20:08       ` Patrick Neuner - Futureweb.at
2009-06-28 22:33         ` David Aguilar
2009-06-29  8:35         ` AW: " Andreas Ericsson
2009-06-29 16:37           ` Peter Harris
2009-07-02  0:47           ` AW: " Patrick Neuner - Futureweb.at
2009-07-02  6:20             ` Johannes Sixt
2009-07-02 11:44               ` AW: " Patrick Neuner - Futureweb.at
2009-07-02 11:55                 ` Johannes Sixt
2009-06-30  5:32         ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090628184714.GA8634@sigio.peff.net \
    --to=peff@peff.net \
    --cc=ae@op5.se \
    --cc=git@vger.kernel.org \
    --cc=neuner@futureweb.at \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).