[rancid] Rancid and Git

[Brown, David M JR]

To whom it may concern,

Apparently this has been brought up a bunch of times.

Original Git Patch...
http://www.shrubbery.net/pipermail/rancid-discuss/2007-March/002152.html

Another mention of the git patch...
http://www.shrubbery.net/pipermail/rancid-discuss/2008-December/003529.html

More poking about git...
http://www.shrubbery.net/pipermail/rancid-discuss/2010-April/004865.html

And yet even more poking around git...
http://www.shrubbery.net/pipermail/rancid-discuss/2013-May/006830.html

The final mention of git support in rancid talks about a rancid fork (essentially) rancid-git whose sole purpose is to support git in rancid https://github.com/dotwaffle/rancid-git.

So, I'd really like to know the answer as to why Git isn't supported in Rancid yet? Most of the patches seem okay and discussion about them seems to have just stopped. The discussion has no mention of whether the patch was going to be supported or not.

So I'd really like an answer to why Git is not supported in Rancid.

Thanks,
- David Brown

[heasley]

Fri, Apr 25, 2014 at 08:32:47PM +0000, Brown, David M JR:
> To whom it may concern,
>
> Apparently this has been brought up a bunch of times.
>
> Original Git Patch...
> http://www.shrubbery.net/pipermail/rancid-discuss/2007-March/002152.html
>
> Another mention of the git patch...
> http://www.shrubbery.net/pipermail/rancid-discuss/2008-December/003529.html
>
> More poking about git...
> http://www.shrubbery.net/pipermail/rancid-discuss/2010-April/004865.html
>
> And yet even more poking around git...
> http://www.shrubbery.net/pipermail/rancid-discuss/2013-May/006830.html
>
> The final mention of git support in rancid talks about a rancid fork (essentially) rancid-git whose sole purpose is to support git in rancid https://github.com/dotwaffle/rancid-git.
>
> So, I'd really like to know the answer as to why Git isn't supported in Rancid yet? Most of the patches seem okay and discussion about them seems to have just stopped. The discussion has no mention of whether the patch was going to be supported or not.

to support it, i have to test it and havent had time. what does git provide
over svn? afaict, there is only one feature, which does not apply to rancid.

[Brown, David M JR]

> to support it, i have to test it and havent had time. what does git provide
> over svn? afaict, there is only one feature, which does not apply to rancid.

For us, the feature fits well into the rest of our git repository management we have internally. We have a centralized git server where all configuration for internal applications is stored and supporting a subversion server is replication of support overhead that shouldn't be needed.

Furthermore, git, like most distributed SCMs, supports pushing and pulling to multiple locations this means that multiple rancid deployments could be hooked into one central git repository. At least for us we have managed switches that are not accessible (due to security or support concerns) from broader networks. The ability to setup a tree of git repositories to aggregate our network configurations to a central place is a big feature for us.

Thanks,
- David Brown

[Tore Anderson]

* Brown, David M JR

> For us, the feature fits well into the rest of our git repository
> management we have internally. We have a centralized git server where
> all configuration for internal applications is stored and supporting
> a subversion server is replication of support overhead that shouldn't
> be needed.

+1

We've phased out all instances of RCS, CVS, and SVN in favour of Git
which we consider superior in pretty much any way. So we have a lot of
processes and systems that build on top of Git, like issue trackers and
web based repository browsers with nice coloured side-by-side diffs and
such. There's just no way we would want to keep the old stuff around
solely for RANCID.

> Furthermore, git, like most distributed SCMs, supports pushing and
> pulling to multiple locations this means that multiple rancid
> deployments could be hooked into one central git repository. At least
> for us we have managed switches that are not accessible (due to
> security or support concerns) from broader networks. The ability to
> setup a tree of git repositories to aggregate our network
> configurations to a central place is a big feature for us.

Again +1.

Another thing we find useful is that once you set up the RANCID
server(s) to automatically push changes to a central Git repository,
then you can easily allow other systems which have some use for parsing
the network configs to use Git to easily fetch updated copies from that
central location. Those system do not need to have access to or even
know about the individual servers running RANCID.

Speaking of Git, I would also suggest to move the development of RANCID
itself into a publicly available Git repository like GitHub. I find it
much easier to contribute my own changes back upstream this way, find
the exact code that introduced bugs (git-bisect is just pure awesome),
and so on. Contributing a patch to RANCID proper, on the other hand,
seems to be to fire off a patch to this mailing list with no way to
verify that it still works or even applies cleanly to the current
development head. I'd guess this is partially the reason why the
rancid-git fork has become more than "vanilla RANCID + Git integration"
but actually have other changes too, like new device scripts and such.

John, if you've not familiarised yourself with Git yet I would strongly
recommend that you invest some time in doing so, you won't regret it...
It's not without reason that a huge number of open-source projects have
converted to Git.

Tore

[heasley]

trying to integrate, test and sanitize the git patch; does anyone know the
significance of the flock in control_rancid around commits:

+ git )
+ (
+ flock -x 200
+ git add $router
+ git commit -m "$message"
+ ) 200>$BASEDIR/.lockfile

git must do its own locking, and rancid does its own per-group. so,
paranoia or some special git thing?

[Brown, David M JR]

Heasley,

My guess is that they wanted to make the git add/commit in one transaction
in case someone else might be manipulating the repo. Subversion does
something similar in that svn add just adds that file and then the commit
pushes it to the repository. So the flock doesn¹t seem relevant to me
unless you do a similar lock around svn add/commit.

Thanks,
- David Brown

On 5/16/14, 6:37 PM, "heasley" <***@shrubbery.net> wrote:

>trying to integrate, test and sanitize the git patch; does anyone know the
>significance of the flock in control_rancid around commits:
>
>+ git )
>+ (
>+ flock -x 200
>+ git add $router
>+ git commit -m "$message"
>+ ) 200>$BASEDIR/.lockfile
>
>git must do its own locking, and rancid does its own per-group. so,
>paranoia or some special git thing?

[james machado]

there was a message about git and locks back in 2007
http://www.shrubbery.net/pipermail/rancid-discuss/2007-March/002154.html
that talked about this or something related to this.

best i can remember from past research on using git and rancid.

james

On Fri, May 16, 2014 at 6:37 PM, heasley <***@shrubbery.net> wrote:
> trying to integrate, test and sanitize the git patch; does anyone know the
> significance of the flock in control_rancid around commits:
>
> + git )
> + (
> + flock -x 200
> + git add $router
> + git commit -m "$message"
> + ) 200>$BASEDIR/.lockfile
>
> git must do its own locking, and rancid does its own per-group. so,
> paranoia or some special git thing?
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-***@shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[heasley]

Mon, May 19, 2014 at 11:16:37AM -0700, james machado:
> there was a message about git and locks back in 2007
> http://www.shrubbery.net/pipermail/rancid-discuss/2007-March/002154.html
> that talked about this or something related to this.
>
> best i can remember from past research on using git and rancid.

Thanks for that.

----
> $BASEDIR is the dir into which all groups go. If you put a generic
> lockfile here you will make it so multiple groups can't be polled at one
> time. Typically a temp dir is used where the file includes the group name
> so there is no stepping on of toes, and stale lockfiles aren't left in
> unexpected places.

The locks shouldn't slow down polling, the lock is only held when making
commits to the Git repository which shouldn't happen during polling
(unless I'm misunderstanding something about the code). I needed the
locks because I need to run a series of git commands atomically or
changes from other groups might become part of the wrong commit.
----

That seems out of scope to me. Perhaps i do not yet understand the process
in git. how would the commits in one group become part of another group's
commit? the commit occurs in the group's directory.


> james
>
> On Fri, May 16, 2014 at 6:37 PM, heasley <***@shrubbery.net> wrote:
> > trying to integrate, test and sanitize the git patch; does anyone know the
> > significance of the flock in control_rancid around commits:
> >
> > + git )
> > + (
> > + flock -x 200
> > + git add $router
> > + git commit -m "$message"
> > + ) 200>$BASEDIR/.lockfile
> >
> > git must do its own locking, and rancid does its own per-group. so,
> > paranoia or some special git thing?
> > _______________________________________________
> > Rancid-discuss mailing list
> > Rancid-***@shrubbery.net
> > http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Jeffrey Ollie]

On Wed, May 21, 2014 at 1:55 PM, heasley <***@shrubbery.net> wrote:
> Mon, May 19, 2014 at 11:16:37AM -0700, james machado:
>> there was a message about git and locks back in 2007
>> http://www.shrubbery.net/pipermail/rancid-discuss/2007-March/002154.html
>> that talked about this or something related to this.
>>
>> best i can remember from past research on using git and rancid.
>
> Thanks for that.
>
> ----
>> $BASEDIR is the dir into which all groups go. If you put a generic
>> lockfile here you will make it so multiple groups can't be polled at one
>> time. Typically a temp dir is used where the file includes the group name
>> so there is no stepping on of toes, and stale lockfiles aren't left in
>> unexpected places.
>
> The locks shouldn't slow down polling, the lock is only held when making
> commits to the Git repository which shouldn't happen during polling
> (unless I'm misunderstanding something about the code). I needed the
> locks because I need to run a series of git commands atomically or
> changes from other groups might become part of the wrong commit.
> ----
>
> That seems out of scope to me. Perhaps i do not yet understand the process
> in git. how would the commits in one group become part of another group's
> commit? the commit occurs in the group's directory.

Git is different from CVS or SVN. In CVS and SVN directories are
significant in that they are essentially separate repositories. In
Git there is only one repository and a "git add" done in one directory
will be included in a "git commit" done in a different directory.

--
Jeff Ollie

[Max Clark]

Is there movement on an official RANCID release with GIT support?


On Wed, May 21, 2014 at 12:58 PM, Jeffrey Ollie <***@ocjtech.us> wrote:

> On Wed, May 21, 2014 at 1:55 PM, heasley <***@shrubbery.net> wrote:
> > Mon, May 19, 2014 at 11:16:37AM -0700, james machado:
> >> there was a message about git and locks back in 2007
> >>
> http://www.shrubbery.net/pipermail/rancid-discuss/2007-March/002154.html
> >> that talked about this or something related to this.
> >>
> >> best i can remember from past research on using git and rancid.
> >
> > Thanks for that.
> >
> > ----
> >> $BASEDIR is the dir into which all groups go. If you put a generic
> >> lockfile here you will make it so multiple groups can't be polled at one
> >> time. Typically a temp dir is used where the file includes the group
> name
> >> so there is no stepping on of toes, and stale lockfiles aren't left in
> >> unexpected places.
> >
> > The locks shouldn't slow down polling, the lock is only held when making
> > commits to the Git repository which shouldn't happen during polling
> > (unless I'm misunderstanding something about the code). I needed the
> > locks because I need to run a series of git commands atomically or
> > changes from other groups might become part of the wrong commit.
> > ----
> >
> > That seems out of scope to me. Perhaps i do not yet understand the
> process
> > in git. how would the commits in one group become part of another
> group's
> > commit? the commit occurs in the group's directory.
>
> Git is different from CVS or SVN. In CVS and SVN directories are
> significant in that they are essentially separate repositories. In
> Git there is only one repository and a "git add" done in one directory
> will be included in a "git commit" done in a different directory.
>
> --
> Jeff Ollie
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-***@shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss
>

[Heasley]

Am Jun 25, 2014 um 17:16 schrieb Max Clark <***@gmail.com>:
>
> Is there movement on an official RANCID release with GIT support?
>
I've started testing the provided patch and felt it needs a bit of work, but i've been OOT, back tm.

>> On Wed, May 21, 2014 at 12:58 PM, Jeffrey Ollie <***@ocjtech.us> wrote:
>> On Wed, May 21, 2014 at 1:55 PM, heasley <***@shrubbery.net> wrote:
>> > Mon, May 19, 2014 at 11:16:37AM -0700, james machado:
>> >> there was a message about git and locks back in 2007
>> >> http://www.shrubbery.net/pipermail/rancid-discuss/2007-March/002154.html
>> >> that talked about this or something related to this.
>> >>
>> >> best i can remember from past research on using git and rancid.
>> >
>> > Thanks for that.
>> >
>> > ----
>> >> $BASEDIR is the dir into which all groups go. If you put a generic
>> >> lockfile here you will make it so multiple groups can't be polled at one
>> >> time. Typically a temp dir is used where the file includes the group name
>> >> so there is no stepping on of toes, and stale lockfiles aren't left in
>> >> unexpected places.
>> >
>> > The locks shouldn't slow down polling, the lock is only held when making
>> > commits to the Git repository which shouldn't happen during polling
>> > (unless I'm misunderstanding something about the code). I needed the
>> > locks because I need to run a series of git commands atomically or
>> > changes from other groups might become part of the wrong commit.
>> > ----
>> >
>> > That seems out of scope to me. Perhaps i do not yet understand the process
>> > in git. how would the commits in one group become part of another group's
>> > commit? the commit occurs in the group's directory.
>>
>> Git is different from CVS or SVN. In CVS and SVN directories are
>> significant in that they are essentially separate repositories. In
>> Git there is only one repository and a "git add" done in one directory
>> will be included in a "git commit" done in a different directory.
>>
>> --
>> Jeff Ollie
>> _______________________________________________
>> Rancid-discuss mailing list
>> Rancid-***@shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/rancid-discuss
>
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-***@shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Max Clark]

Thanks!


On Thu, Jun 26, 2014 at 12:49 AM, Heasley <***@shrubbery.net> wrote:

> Am Jun 25, 2014 um 17:16 schrieb Max Clark <***@gmail.com>:
>
> Is there movement on an official RANCID release with GIT support?
>
> I've started testing the provided patch and felt it needs a bit of work,
> but i've been OOT, back tm.
>
> On Wed, May 21, 2014 at 12:58 PM, Jeffrey Ollie <***@ocjtech.us> wrote:
>
>> On Wed, May 21, 2014 at 1:55 PM, heasley <***@shrubbery.net> wrote:
>> > Mon, May 19, 2014 at 11:16:37AM -0700, james machado:
>> >> there was a message about git and locks back in 2007
>> >>
>> http://www.shrubbery.net/pipermail/rancid-discuss/2007-March/002154.html
>> >> that talked about this or something related to this.
>> >>
>> >> best i can remember from past research on using git and rancid.
>> >
>> > Thanks for that.
>> >
>> > ----
>> >> $BASEDIR is the dir into which all groups go. If you put a
>> generic
>> >> lockfile here you will make it so multiple groups can't be polled at
>> one
>> >> time. Typically a temp dir is used where the file includes the group
>> name
>> >> so there is no stepping on of toes, and stale lockfiles aren't left in
>> >> unexpected places.
>> >
>> > The locks shouldn't slow down polling, the lock is only held when making
>> > commits to the Git repository which shouldn't happen during polling
>> > (unless I'm misunderstanding something about the code). I needed the
>> > locks because I need to run a series of git commands atomically or
>> > changes from other groups might become part of the wrong commit.
>> > ----
>> >
>> > That seems out of scope to me. Perhaps i do not yet understand the
>> process
>> > in git. how would the commits in one group become part of another
>> group's
>> > commit? the commit occurs in the group's directory.
>>
>> Git is different from CVS or SVN. In CVS and SVN directories are
>> significant in that they are essentially separate repositories. In
>> Git there is only one repository and a "git add" done in one directory
>> will be included in a "git commit" done in a different directory.
>>
>> --
>> Jeff Ollie
>> _______________________________________________
>> Rancid-discuss mailing list
>> Rancid-***@shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/rancid-discuss
>>
>
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-***@shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss
>
>

[Jeffrey Ollie]

On Fri, May 16, 2014 at 8:37 PM, heasley <***@shrubbery.net> wrote:
> trying to integrate, test and sanitize the git patch; does anyone know the
> significance of the flock in control_rancid around commits:
>
> + git )
> + (
> + flock -x 200
> + git add $router
> + git commit -m "$message"
> + ) 200>$BASEDIR/.lockfile
>
> git must do its own locking, and rancid does its own per-group. so,
> paranoia or some special git thing?

Paranoia mostly.

--
Jeff Ollie

[Crowe, David]

On Apr 29, 2014, at 7:39 AM, heasley <***@shrubbery.net> wrote:

> Fri, Apr 25, 2014 at 08:32:47PM +0000, Brown, David M JR:
>> To whom it may concern,
>>
>> Apparently this has been brought up a bunch of times.
>>
>> Original Git Patch...
>> http://www.shrubbery.net/pipermail/rancid-discuss/2007-March/002152.html
>>
>> Another mention of the git patch...
>> http://www.shrubbery.net/pipermail/rancid-discuss/2008-December/003529.html
>>
>> More poking about git...
>> http://www.shrubbery.net/pipermail/rancid-discuss/2010-April/004865.html
>>
>> And yet even more poking around git...
>> http://www.shrubbery.net/pipermail/rancid-discuss/2013-May/006830.html
>>
>> The final mention of git support in rancid talks about a rancid fork (essentially) rancid-git whose sole purpose is to support git in rancid https://github.com/dotwaffle/rancid-git.
>>
>> So, I'd really like to know the answer as to why Git isn't supported in Rancid yet? Most of the patches seem okay and discussion about them seems to have just stopped. The discussion has no mention of whether the patch was going to be supported or not.
>
> to support it, i have to test it and havent had time. what does git provide
> over svn? afaict, there is only one feature, which does not apply to rancid.


what one feature do you mean? git is an easy integration into rancid and gives us useful options when we're trying to manage the repository backend as the OP noted in his later response. we've been carrying around a git patchset for rancid for years that has been relatively easy to port to each version. however, i would greatly appreciate integration upstream. it works very well and is feature comparable to the svn implementation.

enjoy,

David

[Brown, David M JR]

>----
>> $BASEDIR is the dir into which all groups go. If you put a generic
>> lockfile here you will make it so multiple groups can't be polled at one
>> time. Typically a temp dir is used where the file includes the group
>>name
>> so there is no stepping on of toes, and stale lockfiles aren't left in
>> unexpected places.
>
>The locks shouldn't slow down polling, the lock is only held when making
>commits to the Git repository which shouldn't happen during polling
>(unless I'm misunderstanding something about the code). I needed the
>locks because I need to run a series of git commands atomically or
>changes from other groups might become part of the wrong commit.
>----
>
>That seems out of scope to me. Perhaps i do not yet understand the
>process
>in git. how would the commits in one group become part of another group's
>commit? the commit occurs in the group's directory.

One of the big differences between svn commit and git commit is the
current working directory doesn¹t matter for git and it does for svn. My
guess is that they did this then to ensure that commits to on group don¹t
have race conditions with another group being modified.

A fix to this would be to do a 'git commit -m ³$message² *' this should
only commit things in the current working directory and not differences in
the entire tree.

Hopefully this helps.

Thanks,
- David Brown

[heasley]

Wed, May 21, 2014 at 08:07:26PM +0000, Brown, David M JR:
>
> >----
> >> $BASEDIR is the dir into which all groups go. If you put a generic
> >> lockfile here you will make it so multiple groups can't be polled at one
> >> time. Typically a temp dir is used where the file includes the group
> >>name
> >> so there is no stepping on of toes, and stale lockfiles aren't left in
> >> unexpected places.
> >
> >The locks shouldn't slow down polling, the lock is only held when making
> >commits to the Git repository which shouldn't happen during polling
> >(unless I'm misunderstanding something about the code). I needed the
> >locks because I need to run a series of git commands atomically or
> >changes from other groups might become part of the wrong commit.
> >----
> >
> >That seems out of scope to me. Perhaps i do not yet understand the
> >process
> >in git. how would the commits in one group become part of another group's
> >commit? the commit occurs in the group's directory.
>
> One of the big differences between svn commit and git commit is the
> current working directory doesn¹t matter for git and it does for svn. My
> guess is that they did this then to ensure that commits to on group don¹t
> have race conditions with another group being modified.
>
> A fix to this would be to do a 'git commit -m ³$message² *' this should
> only commit things in the current working directory and not differences in
> the entire tree.
>
> Hopefully this helps.
>
> Thanks,
> - David Brown

I've been playing with git a bit to determine how to arrange the repository
and understand the commands. I find the automatic search for changed files
unwelcome.

The original git patch arranges the repository at $BASEDIR (eg: /var/rancid),
which creates a single repository with all groups.

I experimented with creating a "remote" repository in $BASEDIR, then pushing
individual groups to it, but they clash, which I suspect has to do with
either the repository name (git push -u origin master).

Assuming that is not the problem with that arrangement, another possibility
is just making each group its own self-contained repository. However, I
dislike this as well, as its easier to help users recover from RCS problems
when they can just rm-rf the group and check-out a fresh copy.

Also, I'd like to maintain the existing arrangement with CVS and SVN, where
each rancid group is it's own path that admins can remove their working copy
without remove-ing from the repository (yes, I understand that the history
remains).

Any guidance or comment welcome.

[Hughes, Doug]

I think 1 repo seems the sanest thing to do, but I might be missing some esoteric use cases where multiple would be valuable.

[Crowe, David]

i would agree with a single repo being the best approach.

regarding the automatic search for changed files (i'll include untracked files in here), the additions to .gitignore helps with this tremendously.

thanks,

David

On Jul 18, 2014, at 1:35 PM, Hughes, Doug <***@DEShawResearch.com> wrote:

> I think 1 repo seems the sanest thing to do, but I might be missing some esoteric use cases where multiple would be valuable.
>
>
> _______________________________________________
> Rancid-discuss mailing list
> Rancid-***@shrubbery.net
> http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[John Heasley]

Am Jul 18, 2014 um 2:05 PM schrieb "Crowe, David" <***@bendbroadband.net>:
>
> i would agree with a single repo being the best approach.
>
> regarding the automatic search for changed files (i'll include untracked files in here), the additions to .gitignore helps with this tremendously.
>

I do not like its global behavior, but...

Can you tell me what is wrong with the second approach i described?

> thanks,
>
> David
>
>> On Jul 18, 2014, at 1:35 PM, Hughes, Doug <***@DEShawResearch.com> wrote:
>>
>> I think 1 repo seems the sanest thing to do, but I might be missing some esoteric use cases where multiple would be valuable.
>>
>>
>> _______________________________________________
>> Rancid-discuss mailing list
>> Rancid-***@shrubbery.net
>> http://www.shrubbery.net/mailman/listinfo/rancid-discuss

[Crowe, David]

On Jul 18, 2014, at 2:18 PM, John Heasley <***@shrubbery.net> wrote:

> Am Jul 18, 2014 um 2:05 PM schrieb "Crowe, David" <***@bendbroadband.net>:
>>
>> i would agree with a single repo being the best approach.
>>
>> regarding the automatic search for changed files (i'll include untracked files in here), the additions to .gitignore helps with this tremendously.
>>
>
> I do not like its global behavior, but...
>

that is a bit of a pain but once you add the extraneous files and patterns to .gitignore file i've not had to touch it in a long time. having a separate repo for each group could make that a bit cleaner.


> Can you tell me what is wrong with the second approach i described?
>

if i understand what you tried, the "remote" can't be within/under the same directory tree as $BASEDIR if that is the root of an existing git repo.

if you stay with the single repo strategy, doing "git reset --hard $BASEDIR/group" is the best way to get back to the last known good repo copy for any group.

David

[Heasley John]

Fri, Jul 18, 2014 at 02:57:07PM -0700, Crowe, David:
> On Jul 18, 2014, at 2:18 PM, John Heasley <***@shrubbery.net> wrote:
>
> > Am Jul 18, 2014 um 2:05 PM schrieb "Crowe, David" <***@bendbroadband.net>:
> >>
> >> i would agree with a single repo being the best approach.
> >>
> >> regarding the automatic search for changed files (i'll include untracked files in here), the additions to .gitignore helps with this tremendously.
> >>
> >
> > I do not like its global behavior, but...
> >
>
> that is a bit of a pain but once you add the extraneous files and patterns to .gitignore file i've not had to touch it in a long time. having a separate repo for each group could make that a bit cleaner.
>
>
> > Can you tell me what is wrong with the second approach i described?
> >
>
> if i understand what you tried, the "remote" can't be within/under the same directory tree as $BASEDIR if that is the root of an existing git repo.

how do services like github arrange their store? is it a path per-project?

another nice result of having this mehtod, is that the code remains generic
for local (this host) or remote repositories.

> if you stay with the single repo strategy, doing "git reset --hard $BASEDIR/group" is the best way to get back to the last known good repo copy for any group.

thanks; i suspected that would be the result.

[Crowe, David]

On Jul 19, 2014, at 1:16 PM, Heasley John <***@shrubbery.net> wrote:

> Fri, Jul 18, 2014 at 02:57:07PM -0700, Crowe, David:
>> On Jul 18, 2014, at 2:18 PM, John Heasley <***@shrubbery.net> wrote:
>>
>>> Am Jul 18, 2014 um 2:05 PM schrieb "Crowe, David" <***@bendbroadband.net>:
>>>>
>>>> i would agree with a single repo being the best approach.
>>>>
>>>> regarding the automatic search for changed files (i'll include untracked files in here), the additions to .gitignore helps with this tremendously.
>>>>
>>>
>>> I do not like its global behavior, but...
>>>
>>
>> that is a bit of a pain but once you add the extraneous files and patterns to .gitignore file i've not had to touch it in a long time. having a separate repo for each group could make that a bit cleaner.
>>
>>
>>> Can you tell me what is wrong with the second approach i described?
>>>
>>
>> if i understand what you tried, the "remote" can't be within/under the same directory tree as $BASEDIR if that is the root of an existing git repo.
>
> how do services like github arrange their store? is it a path per-project?
>

correct.

> another nice result of having this mehtod, is that the code remains generic
> for local (this host) or remote repositories.
>

agreed.


>> if you stay with the single repo strategy, doing "git reset --hard $BASEDIR/group" is the best way to get back to the last known good repo copy for any group.
>
> thanks; i suspected that would be the result.

[Jeffrey Ollie]

On Fri, Jul 18, 2014 at 3:33 PM, heasley <***@shrubbery.net> wrote:
>
> I've been playing with git a bit to determine how to arrange the repository
> and understand the commands. I find the automatic search for changed files
> unwelcome.

Git should only be automatically searching for changed files if you
are using "git commit -a". My patch didn't do that, it added changed
files to the pending commit individually.

> The original git patch arranges the repository at $BASEDIR (eg: /var/rancid),
> which creates a single repository with all groups.
>
> I experimented with creating a "remote" repository in $BASEDIR, then pushing
> individual groups to it, but they clash, which I suspect has to do with
> either the repository name (git push -u origin master).

That won't quite work the way that you expect... merging multiple
unrelated repositories into one will make for a very confused
repository.

--
Jeff Ollie