git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* "linking" to files from another repo
@ 2018-06-12  8:18 Crni Gorac
  2018-06-12  9:35 ` Jeff King
  0 siblings, 1 reply; 2+ messages in thread
From: Crni Gorac @ 2018-06-12  8:18 UTC (permalink / raw)
  To: git

I'm working on a large closed-source project.  For one of clients, I
had to create a library that consists of some directories from
original project, and even within these directories, not all files are
used for the library.  On top of that, I've added some files specific
for this library, in separate directories and in the library repo
top-level directory.  Most of files from original project are
unchanged, and for some, I had to make some small changes (mostly to
exclude dependencies on other stuff from the original project).  We're
now switching to Git from another VCS, and I'm wondering is there any
way to automatically "link" those pieces from the main project repo
into my library repo?  So far, I would run update in the main project
repo, check is any of files that I'm using in library changed, and if
so, then I would either copy the new version of given file into the
library (if given file unchanged for the library), or merge updates
manually (if given file is one of these files that are slightly
changed for the library), and then commit all these changes in the
library repo.  None of changes in the library will ever go back into
the main project, i.e. the flow of updates is uni-directional here.
So, any support in Git to automate the procedure of updating the
library with the changes made for corresponding files in the main
project?

Thanks.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: "linking" to files from another repo
  2018-06-12  8:18 "linking" to files from another repo Crni Gorac
@ 2018-06-12  9:35 ` Jeff King
  0 siblings, 0 replies; 2+ messages in thread
From: Jeff King @ 2018-06-12  9:35 UTC (permalink / raw)
  To: Crni Gorac; +Cc: git

On Tue, Jun 12, 2018 at 10:18:31AM +0200, Crni Gorac wrote:

> I'm working on a large closed-source project.  For one of clients, I
> had to create a library that consists of some directories from
> original project, and even within these directories, not all files are
> used for the library.  On top of that, I've added some files specific
> for this library, in separate directories and in the library repo
> top-level directory.  Most of files from original project are
> unchanged, and for some, I had to make some small changes (mostly to
> exclude dependencies on other stuff from the original project).  We're
> now switching to Git from another VCS, and I'm wondering is there any
> way to automatically "link" those pieces from the main project repo
> into my library repo?  So far, I would run update in the main project
> repo, check is any of files that I'm using in library changed, and if
> so, then I would either copy the new version of given file into the
> library (if given file unchanged for the library), or merge updates
> manually (if given file is one of these files that are slightly
> changed for the library), and then commit all these changes in the
> library repo.  None of changes in the library will ever go back into
> the main project, i.e. the flow of updates is uni-directional here.
> So, any support in Git to automate the procedure of updating the
> library with the changes made for corresponding files in the main
> project?

If I understand your case correctly, this is usually solved with a
"vendor" branch type of workflow. E.g.:

  # Import the first version of the library verbatim onto the branch
  # "upstream".
  git init
  git checkout -b upstream
  tar xf the-lib-1.0.tar
  git add .
  git commit -m 'import version 1.0'

  # Now make your changes on master.
  git checkout -b master upstream
  hack hack hack
  git commit -m 'fixed some bits'

  # Time passes. You want to import 1.1. Do this on the upstream branch,
  # where we know that we can overwrite the state completely (since we
  # are replacing upstream's 1.0 with their 1.1).
  git checkout upstream
  rm -rf *
  tar xf the-lib-1.1.tar
  git add -A
  git commit -m 'import version 1.1'

  # And now you can merge 1.1 into your master branch. The git history
  # you've created reflects two lines of development: upstream's and
  # your custom changes. So merging will never "undo" the changes you've
  # made (but you'll probably see conflicts if you deleted a file and
  # upstream changed it, for example).
  git checkout master
  git merge upstream

Note that your "master" branch doesn't have to be _just_ the changes to
upstream. It can actually be your whole project, complete with changes
to the upstream library.

-Peff

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-06-12  8:18 "linking" to files from another repo Crni Gorac
2018-06-12  9:35 ` Jeff King

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox