On Sun, Mar 21, 2010 at 6:59 PM, Scott Haneda <talklists@xxxxxxxxxx> wrote: > I have seen there are a lot of patches, diffs, and what appear to be > development related posts on this list. Am I in the correct place? > If not, can someone point me in the right direction? There's only one official git mailing list, so that's what you get. I think the rule of thumb for mailing lists is: if you can't answer your questions in ten seconds using a Google search, then you're pretty safe asking on a mailing list. It looks like you're safe. By the way, this mailing list accepts posts from non-subscribers, and it's the policy on the list to always cc: everyone who has replied to a message in that thread so far, including the original poster. The idea is that you can ask a question about git without *having* to subscribe to read all the other stuff. But of course, reading some of the other stuff will make you a more competent git user pretty fast, so it might be worth it anyway. > ** - My question if appropriate - ** > My needs are simple. I do some scripting, some coding, web > development etc. I try my best to take what I have done and > release it back out to the public. This has become something > that takes too much effort. Yup, sounds like you need version control. > At that point, I have to make a decision. Pack it all up, tar it, and put > it online, perhaps on my website, or perhaps announce it on twitter, or > a relevant mailing list. Of I make a change, even a one character change, > I have to update the distribution that is on my website. There could be > links to it I forgot about that would contain an older broken version. It may > also be a simple 30 line bash script, it may not even get a version number, it is a quick hack. I think you're right to consider Github for this choice. It's about 100x more sane than sourceforge, and you can go from start to release+tarball in one step: it gives viewers the ability to create tarballs from any version automatically. If you use 'git tag' (to tag specific versions as "done") then it'll be even easier for people to find later. > I am thinking github is going to be where I put all this stuff, but I am > completely lost on where to even begin with all this. I watched a few > of the videos on the kernel.org website, and will continue with the > git tutorials and documentation. You should probably look at getting a good book on version control. You can find *these* using Google, including free online ones, now that you know this is what you should do :) > The second reason I came to this list is that I am a Mac user, > and some of the tools I have created are resource fork dependent. > If they are ftp'd they will be broken. Rsync is the only tool I know > of that can accurately transfer the files without destroying them. > However, this requires a custom patched version of rsync, and > must be equal on both ends. I am not sure git hub is going to > have that patch applied. I may be getting into git hub specifics > here, and going outside of the lists scope being focussed on git, > if I am, plesae let me know and I can find a git hub resource. github just does what git does, only with a friendly web interface. git doesn't support fancy xattrs or resource forks, at least without using add-on tools. This is because source code almost never *needs* these resource forks: only finished products do, and those are usually built *from* the source code. As part of the build process, you add the resource forks and xattrs onto the completed files. Also, your repository wouldn't work on non-Mac computers if git stored that kind of stuff internally. Your best bet is to have a simple Makefile or build script that does everything that's necessary. There are a couple of tools out there that claim to support attrs and xattrs (for example, metastore), but at least in metastore's case I don't see any evidence that it supports resource forks. 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