getting started with git

getting started with git

[Ivan Senji]

Hello everyone!

I started using git recently to manage my personal projects and I really
like it. I develop on several different locations and have a little problem
that i couldn't find a way to solve.

On each location that i develop some project and configuration files are
different. But i would like them to be in the repository as a starting point
when checking out a project (example: opening a project on a dfferent OS in
eclipse... eclipse will find an error in the path to jdk and ask me to fix
that error by selecting a different jdk).

How to achieve that these files are in the repository but that any further
changes to them are not commited (or are commited localy but not pushed to a
remote repository)?

Is that even possible?

Thanks!
-- 
View this message in context: http://www.nabble.com/getting-started-with-git-tp20497802p20497802.html
Sent from the git mailing list archive at Nabble.com.

Re: getting started with git

[Tor Arvid Lund]

On Fri, Nov 14, 2008 at 11:16 AM, Ivan Senji <ivan.senji@gmail.com> wrote:
> On each location that i develop some project and configuration files are
> different. But i would like them to be in the repository as a starting point
> when checking out a project (example: opening a project on a dfferent OS in
> eclipse... eclipse will find an error in the path to jdk and ask me to fix
> that error by selecting a different jdk).
>
> How to achieve that these files are in the repository but that any further
> changes to them are not commited (or are commited localy but not pushed to a
> remote repository)?

Hi,

Well, if it were me, I think I would commit that eclipse config file
under a different name... Say, ".classpath.defaults" instead of
".classpath". Then your README file could tell your users to start by
copying the .classpath.defaults to .classpath, and update its contents
as necessary. Put .classpath in your .gitignore file, so it won't be
committed to the repository.

-Tor Arvid-

Re: getting started with git

[Lars Hoss]

>
> Well, if it were me, I think I would commit that eclipse config file
> under a different name... Say, ".classpath.defaults" instead of
> ".classpath". Then your README file could tell your users to start by
> copying the .classpath.defaults to .classpath, and update its contents
> as necessary. Put .classpath in your .gitignore file, so it won't be
> committed to the repository.

Template files (x.default) is a good idea. But regarding your example
with .classpath: it's safe to add it to git since it's developer
independent and project oriented. Therefore it's useful for every
developer in the project who uses eclipse :-)

Yours,
Lars

Getting started with git

[Jonathan Nieder]

Hi!

Kalle Launiala wrote:

> [Subject: Industrywide breakthrough innovation - Git as a key role of distribution]
[30 lines of filler]
> == End of Disclaimer.

Please don't do that.  Most of your audience isn't going to get
past that.

> However in this post I am simply asking help to understand Git
> properly

Are you a programmer?  I'd recommend starting with

 http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html

and moving on to

 http://www.kernel.org/pub/software/scm/git/docs/gittutorial-2.html

and

 http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#hacking-git

Hope that helps,
Jonathan

Re: Getting started with git

[Kalle Launiala]

Hello!

Thanks for the links of overall programmer requirements, been reading
such so far as well. The hacking guide was fresh compared to what I
discovered.

Now the reason of specific detail understanding of the Git was to use
it on wide-range software-code-block distribution. I would like to
know if the following scenario either will "blow up" something or has
some other anti-Git patterns hidden inside.

1. Git repositories vs. "traditional" branch/merge

Within the current spec, we have identified "branching/merging" that
is VCS supported conflict management only feasible option. With Git
this seems to turn to forked/linked independent repositories; this
seems the best option. Every independent software-block would have an
independent root-repository of its own.

Any reason why Git would be using branching at all in distributing
between-project data, even when in traditional VCS they would be
within same repository?

2. Scalability, when having tiny repositories that are chained to the
end-developer

Basically none of the "bottom" is going to push back any changes, so
they're effectively just readers, and also from the nearest
repository; the repository syncing (while likely can be automated out)
will go with normal pulls. I'm not worrying about "seconds to pull",
but moreover is there something architectural structure, that will
cause single-bottleneck.

Is there any scalability issue, if there are say 10 levels from root
repository to the end-user-bottom (in between various feature-adding
or modifying tailoring), and total number of children of the bottom
level grows to hundreds of thousands?


3. Distribution of catalogues, registering "Abstractions"

Registering of new "Abstractions" from any provider (be it major
organization or single consultant) would be dealt with specific
"distribution" repository chain. Pushing the "Registration Request"
within the catalogue would be fullfilled by validating the data in the
claimed repository. The format of the data is strongly schema based
XML all the way. The openly used "root" catalogue would be synced
globally (daily or so, not immediatelly); the dedicated "private" or
other independent catalogue providers would be in charge of their
policies.

Are there any experience on this kind of use for Git?


4. Handling "private" catalogues; repository access filtered with
client-access-control

Private catalogues would be handled in a way, that their
existence/registration would be standard-pushed up to the chain.
However all the information of their data and their content would be
contained only within the repository. Hence, only the clients that
have the access to connect to the repository could fetch the actual
catalogue of information. They would cache their catalogues with same
manner as would the root catalogue.

Even if the clients would get improper private entires in their
connection lists, they would only get any real information out, if
their credentials authorized on the target repository.

Any blockers that come in mind with this?


Kalle