Anybody Good At Git?

[DAZ]

Hi,

I've also posted this on the Git for Human Beings group, but thought
I'd try here as some people might have come across what I mean....

I was wondering if somebody could point me in the right direction
here:

I am working on a Sinatra base web framework and am using git for
source control and also putting it up on github.

The framework also contains a CSS framework. I would actually like the
CSS framework to be in a separate github repository so they can be
developed separately, but I'd also like it if I could work on the CSS
within the Sinatra framework and for those changes to take effect in
it's own repository.

I am also using a one page CSS project that I have hosted on github

I hope what I am saying makes sense. I have been reading the git docs
and can't figure out if I should clone the CSS repository into the
Sinatra repository or if I need to use submodules.

Any advice on the best way to do this would be much appreciated,
thanks

DAZ

[Nicholas Young]

So, I'm not completely clear as to what you want, but I would look
into multiple remotes or submodules in git, and see if either of those
suit your needs.

It's at least a start.

Nicholas

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "sinatrarb" group.
> To post to this group, send email to sina...@googlegroups.com.
> To unsubscribe from this group, send email to sinatrarb+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sinatrarb?hl=en.
>

[Nickolas Means]

The simplest approach (for development at least) would be to keep the CSS framework in a separate directory and just symlink it into the Sinatra project.  Obviously, that would get a bit complicated for deployment, but it's an easy way to go while things are still early and in flux.

If you plan to keep working this way long-term, submodules are probably what you're looking for. Here's a good place to start: http://book.git-scm.com/5_submodules.html

HTH!

-Nick

-----

Nickolas Means

nme...@gmail.com

m | 806.789.6947

[DAZ]

Thanks for the replies guys,

It's definitely not multiple remotes Nicholas. Submodules seem to
explain what I mean. That link looks very useful Nickolas - cheers!
And the symlink idea sounds good, although I want to get the full
framework on github quite soon, so will have to get submodules sorted
soon...

DAZ
ps - Do all git experts have the same name but with different
spelling?!

On Aug 5, 3:19 pm, Nickolas Means <nme...@gmail.com> wrote:
> The simplest approach (for development at least) would be to keep the CSS
> framework in a separate directory and just symlink it into the Sinatra
> project.  Obviously, that would get a bit complicated for deployment, but
> it's an easy way to go while things are still early and in flux.
>
> If you plan to keep working this way long-term, submodules are probably what
> you're looking for. Here's a good place to start:http://book.git-scm.com/5_submodules.html
>
> <http://book.git-scm.com/5_submodules.html>HTH!
>
> -Nick
>
> -----
> Nickolas Means
> nme...@gmail.com
> m | 806.789.6947
>
> On Thu, Aug 5, 2010 at 9:05 AM, Nicholas Young

> <nicho...@nicholaswyoung.com>wrote:

>
>
>
> > So, I'm not completely clear as to what you want, but I would look
> > into multiple remotes or submodules in git, and see if either of those
> > suit your needs.
>
> > It's at least a start.
>
> > Nicholas
>
> > Sent from my iPhone
>

> > sinatrarb+...@googlegroups.com<sinatrarb%2Bunsubscribe@googlegroups .com>
> > .

> > > For more options, visit this group at
> >http://groups.google.com/group/sinatrarb?hl=en.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "sinatrarb" group.
> > To post to this group, send email to sina...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > sinatrarb+...@googlegroups.com<sinatrarb%2Bunsubscribe@googlegroups .com>
> > .

[Nicholas Young]

Cool. ;-) I figured two different approaches wouldn't hurt. Let you figure out which one suited your need, since I wasn't quite sure what you were doing. 

Nicholas

To unsubscribe from this group, send email to sinatrarb+...@googlegroups.com.

[DAZ]

Thanks Nicholas,

I am going to set up a really simple dummy project and play around
with submodules, so hopefully then I will understand them!

DAZ

[trans]

Create two repos in two separate directories. If you organize them
right you can just symlink the css framework project into the web
framework project where you want it, and depolyment won't be an issue
b/c a package task/tool will copy the actual files into the package,
not the symlink.

Submodules are close to what you want but they are fixed to particular
checkouts so I am not sure you can actually work on the project via
them --I've been curious about that too. Of course you can also clone
a git repo into another a subdirectory of another repo clone as long
as it is ignored in .gitignore, git won't care.

[Markus Prinz]

On 06.08.2010, at 02:29, trans wrote:
>
> Submodules are close to what you want but they are fixed to particular
> checkouts so I am not sure you can actually work on the project via
> them --I've been curious about that too.

You can, since they're normal git repos. It's just a bit cumbersome, since you'll usually want your submodule checked out at a specific version, while maybe working on multiple branches in the repository. I always have a separate clone for doing actual development work on repos that are submodules.

That said, symlinking is probably the easiest solution for what the OP wants in his case.

[Stephen Eley]

On Fri, Aug 6, 2010 at 3:43 AM, Markus Prinz
<markus...@nuclearsquid.com> wrote:
>
> You can, since they're normal git repos. It's just a bit cumbersome, since you'll usually want your submodule checked out at a specific version, while maybe working on multiple branches in the repository. I always have a separate clone for doing actual development work on repos that are submodules.

I'm going to be the smellfungus here: in my experience, Git submodules
are more trouble than they're worth. Adding one's easy enough; but
then everyone working in your project has to remember to initialize it
('git submodule init') as a separate step, and also know when to
update it ('git submodule update'). Beyond that, they just seem
annoyingly fragile. It's very easy to push a parent update but forget
to push submodule changes, or lose track of what branch you're in (or
even *if* you're in a branch), or get things out of sync in many other
hard-to-debug ways.

And then if you change your mind and want to *remove* the submodule?
Ha. There's no command for that. You can Google for the right
incantations and hidden text files to hack, but I personally don't
like the feeling that I'm performing brain surgery on my repository
for simple dependency maintenance.

There are a couple of other strategies that people have promoted. One
is a much simpler "fake submodules" approach, where you simply copy a
repository in and _don't_ declare a submodule for it:

http://debuggable.com/posts/git-fake-submodules:4b563ee4-f3cc-4061-967e-0e48cbdd56cb

Another is to use subtree merging instead of submodules. Scott Chacon
describes the approach here:

http://progit.org/book/ch6-7.html

...and some noble human has crystallized it into a very clean and
simple Git command:

http://github.com/apenwarr/git-subtree/blob/master/git-subtree.txt

Good luck.

--
Have Fun,
   Steve Eley (sfe...@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org