Re: What's cooking in git.git (topics)

From: Yaroslav Halchenko <debian@onerussian.com>
Date: Dec 13, 2010, 22:36 UTC
Message-ID: <20101213223621.GD13447@onerussian.com>
In-Reply-To: <7vlj3txqsz.fsf@alter.siamese.dyndns.org>

On Mon, 13 Dec 2010, Junio C Hamano wrote:

> > hm -- read-tree sounded like yet another unknown to me feature of GIT I
> > was trying desperately to discover ;)  unfortunately it doesn't produce a merge
> > for me

> Didn't I already say it makes sense only with --no-commit?  IOW to shape
> the tree.

rright -- in my case --no-commit so I could remove the content before committing.

Show 6 quoted lines

> And in your use case I do not think you would even want to have a merge.
> Even if you run "git rm" to remove non-free stuff from the merge result,
> if you merged the history of 0.2 that contains non-free stuff you are not
> allowed to distribute (forbidden either by upstream or self-imposed dfsg,
> the reason does not matter), people who gets the merge commit can follow
> its second parent to grab the non-free stuff, no?

I see your point better now -- so it is yet another dimension of "the feature".

as for non-free -- I probably should have been more precise -- non-DFSG (debian free software guidelines)-free ;) i.e.:

*  free compiled,rendered materials, often binary blobs, without
   sources (e.g. .dll's, pdfs etc)

*  material under free but not DFSG-free licenses, etc

* if upstream repository already provides that 'non-free' material it
  would not be much of my misdemeanor to keep them as well buried in the
  repository history.  What I care is to have a cleaned branch from
  which I could git archive, and also which I could inspect in regards to
  changes between releases without visually filtering all changes in
  non-sources (e.g. those binary blobs) or irrelevant content.

  if ever legal situation causes upstream to rewrite history to remove
  them -- I will have to do that as well anyways :-/

Having an actual merge would be useful for making the explicit "bridge" from upstream branch, thus '--no-commit -s theirs' with consecutive cleaning before commit looks the way to go IMHO. But I see now that I could possibly use read-tree at times if a real necessity comes to prune non-distributable content, and then obviously I do not want to drag upstream's illegal stuff along.

-- 
Yaroslav O. Halchenko
Postdoctoral Fellow,   Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik