On 2008-08-11 16:24:57 -0400, Trans wrote: > On Mon, Aug 11, 2008 at 4:39 PM, Karl Hasselström <kha@xxxxxxxxxxx> > wrote: > > > git supports multiple branches per repository/working copy, but > > doesn't force you to have more than one. And it's very easy to > > pull changes from one repo to another. > > In retrospect, It's more the tags I need rather then branches, but > just the same... So if I have a repository like: > > myapp/ > 1.0.0/ > 1.0.1/ > 1.1.0/ > current/ > > This would be okay? No other "giter" is going to look at this and > think "what the hell?" That would be OK. But "myapp" wouldn't be a repository -- it'd be a directory that contains four repositories. Each of those repositories would have a specific branch checked out, but they'd probably all contain the full set of tags and branches. > Hmm... actually I don't see how this can work. If .get is under > current/ than no one will be able to see the tags on my shared repo, > but if it is under myapp/ then I'd be branching and tagging my tags > --that's doesn't make any sense. I'm confused. All your repositories have a .git directory. That's what makes them git reppositories. I think what you need to do to get un-confused is to learn about how git stores history. Specifically, that 1. the history consists of a DAG of commits, and 2. that branches and tags are just named pointers to commits. http://eagain.net/articles/git-for-computer-scientists/ is a short and sweet introduction. -- Karl Hasselström, kha@xxxxxxxxxxx www.treskal.com/kalle -- 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
