Thanks for your help. I've just created my empty new branch for delivery stuff... and effectively the branch is empty :-D Any idea on how I can add executable files in this empty branch from the master branch? Is that possible? (perhaps I'm using Git in a bad way) If I want to manage those file with Git, it's just for the purpose to merge them in another repository. I would have choose to have only one repository for all things... but basically, the two frameworks are not maid to be used together. So I thought that using two distinct repositories was better. Especially for Restfulx code generation which need a lot of unsalubrious hacks. I don't want to keep them in my final application... in any case, thank you very much for your quick answers. Bruno 2010/3/19, Avery Pennarun <apenwarr@xxxxxxxxx>: > On Fri, Mar 19, 2010 at 3:31 PM, bruno le hyaric > <bruno.lehyaric@xxxxxxxxx> wrote: >> 2010/3/18, Avery Pennarun <apenwarr@xxxxxxxxx>: >>> Do you actually have multiple projects that you're working on, or are >>> you the maintainer of an application that uses other people's >>> projects? >> >> I'm starting building a new web application based on 2 existing >> frameworks (Spree, RestfulX). > > This basic explanation leads me to believe you only really want one > repo (at least once you have it set up): the one for your app. Other > people already host repos for the other projects. > >> I want to use latest upstream of both frameworks. For the moment I >> don't have reason to make patches for these, but if I can do that, >> this is better. In the other case I can imagine developping patch in >> distinct repository in a independant way... > > You can embed the contents of the other repositories into yours in one > of three ways that I know of: > > - Just copy the files from those libraries into your project's repo. > This is cheap and easy, although it makes it a bit harder to push > patches upstream later, in case you care about that. > > - Use git-submodule to import those libraries into your project's > repo. This is reasonably easy, but makes it hard to patch those > libraries without creating additional repositories, which is > inconvenient. If you don't need to patch those libraries, it's the > cleanest way. > > - Use git-subtree to import those libraries into your project's repo. > This makes it relatively easy to push and pull changes from the > libraries from/to upstream, but can clutter up your 'git log' a bit. > > I expect that for your purposes, any of the three options would work fine. > >> I plan to distribute the basic work needed by my application. >> Basically, I'm building an automated process to get a e-commerce >> website with generated Flex (Flash) views. This process is mainly >> based on Git/Shell/Rake/Ruby commands. >> >> I won't distribute the source code of my own e-commerce website. >> >> But my problem wasn't about redistribution... RestfulX is a tool for >> code generation. It needs some input and generate Flex code as output. >> Then I compile Flex code to get a Flash executable (.swf / .swc). I >> want to manage everything with versionning, but regarding the merge, I >> just want to merge the executable in the destination repository, not >> all the stuff used for code generation. > > It's very rare with git to commit your output files into a repository. > You can do it, but it's rare. Most people just put the numbered > binaries up in a directory on a website somewhere. Version > controlling binaries any other way doesn't really add anything, since > 'git diff' and friends aren't much help, and the output files are (by > definition) possible to reconstruct from the source code, so if you > lose them, it's not a big deal. > > If you really want to do it, then you will probably want to at least > put the output files on their own branch (as you suggest) or even into > their own repository (so that people cloning the source repo don't > have to download tons of binary revisions that they won't be using). > > Hope this helps. > > Have fun, > > Avery > -- 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