BBEdit and git and terminal

[@lbutlr]

I know that I can setup BBEdit to talk to a git repository. Or at least I know that in theory.

What I would like to do is setup a git repository for all of the “Unix” files that I edit. things like /etc/hosts /etc/postfix/* /Users/*/.bashrc /usr/local/bin/* and others so that when I edit my bashrc or a shell script or postfix configurations I have a way to roll back to previous versions.

OK.

BUT. I don’t always edit these files with BBEdit. Sometimes it’s because I’m already in the shell and “this will only take a second” and others it is because I am logged in via ssh.

So, is there a way to setup git so that it basically automatically watches an arbitrary list of files and directories and just does its magic in the background that would work regardless of if I use BBEdit, vim, text wrangler, TextEdit, or whatever?

A bit off-topic, perhaps, but I figure if anyone knows it will be you lot.

Of course, in 10.13 this will all happen automagically through the power of APFS, but until then…

--
'Somewhere, A Crime Is Happening,' said Dorfl. --Feet of Clay

[Greg Raven]

Time Machine.

[james.o...@gmail.com]

I think that you should be able to create a BBEdit project, add the files to that (whilst leaving them in their current locations) and add that project to GitHub as a repository.

Currently I add project files to gitignore so I’m not sure that it would work as you intend.

Alternatively, you could create hard links to the files in a folder and sync that folder to GitHub.

[@lbutlr]

On Jun 19, 2016, at 5:32 AM, Greg Raven <greg...@gmail.com> wrote:
> Time Machine.

I don’t think that works. First of all, I don’t think that files like ~/.bashrc are in Time Machine at all. If they are, they would be very annoying to find. That said, interacting with Time Machine at the shell level is terrible.


--
and I lift my glass to the Awful Truth / which you can't reveal to the
Ears of Youth / except to say it isn't worth a dime

[@lbutlr]

On Jun 19, 2016, at 10:10 AM, james.o...@gmail.com wrote:
> I think that you should be able to create a BBEdit project, add the files to that (whilst leaving them in their current locations) and add that projectt to GitHub as a repository.

Oh, yes, that makes sense in the cases that I am using BBEdit to edit the files, but it doesn’t account for the times I am sshed in to the machine. I guess I was thinking of something a bit lower-level that would simply do the versioning and such behind the scenes regardless of the tool used to edit the files.

--
Humans are always slightly lost. It's a basic characteristic. It
explains a lot about them.

[Steve deRosier]

On Thu, Jun 23, 2016 at 7:03 PM, @lbutlr <kre...@kreme.com> wrote:
>
> Oh, yes, that makes sense in the cases that I am using BBEdit to edit the files, but it doesn’t account for the times I am sshed in to the machine. I guess I was thinking of something a bit lower-level that would simply do the versioning and such behind the scenes regardless of the tool used to edit the files.
>

Git is a source code revision control system. Just like CVS,
Subversion, Mercurial, Perforce, and so on, it won't do things
"automatically" behind the scenes. You most absolutely can use it to
version /etc and other directories, but you're still going to have to
stage your changes and make each commit. It would be editor-agnostic
as you're desiring, but it won't be transparent/hands off.

And it wouldn't be terribly valuable to version an area hands-off like
that - you'd not have any metadata giving you context to your changes.
The commit message you create for each commit give you context so you
can understand why you made a particular change.

If all you want is an automated backup, Timemachine, a cron-job'd
rsync or other backup solution could be made to do that. And you could
set them up to keep periodic snapshots (ie "versions").

Git is an excellent system for managing a directory of textual config
files like /etc. But you need to understand what the tool does and how
it works before embarking on such a use.

- Steve

[Jeff Bingham]

Lewis,

What you want to do is possible but is not relative to BBEdit.

Git can only track files at the root of the repo so since you are wanting to track files all over the drive, that makes it more difficult.  Please DO NOT create a git repo at /

I have a similar setup what you are trying to do.  Here is what I've done.

In /usr/local/etc/, create a new git repo. (I called mine dotfiles since I was originally tracking only my .files but it has since expanded to other system files too)

Now you can move the files to track into /usr/local/etc/dotfiles/ and create hard or soft links back to their original location.

Now anytime you make a change to the files, jump into the /usr/local/etc/dotfiles/ directory and commit the changes.

An automated option could be to create a script (called by cron.daily) that runs 'git status --porcelain' in the dotfiles repo and if any results are found, it commits all changes.

It would need to generate a commit message so as Steve mentioned, one of the best features of versioning is that the commit messages explain what was changed.  In this case, the messages wouldn't matter but at least you would have a history of your changes.

[steveax]

Linking the dotfiles from the repository to their usual location is a good idea, but given the permission changes in OSX El Capitan, I would not not recommend putting the repository in /usr/local. Something like ~/dev/dotfiles will avoid any permissions issues.

Cheers,

-S

[Rich Siegel]

/usr/local/ should be OK; it's not subject to System Integrity
Protection. That said, keeping stuff in your own home directory
is generally easier to manage anyway. :-)

R.
--
Rich Siegel Bare Bones Software, Inc.
<sie...@barebones.com> <http://www.barebones.com/>

Someday I'll look back on all this and laugh... until they
sedate me.

[@lbutlr]

On 24 Jun 2016, at 12:27, Jeff Bingham <je...@bingham.co> wrote:
> Now anytime you make a change to the files, jump into the /usr/local/etc/dotfiles/ directory and commit the changes.
> An automated option could be to create a script (called by cron.daily) that runs 'git status --porcelain' in the dotfiles repo and if any results are found, it commits all changes.
> It would need to generate a commit message so as Steve mentioned, one of the best features of versioning is that the commit messages explain what was changed. In this case, the messages wouldn't matter but at least you would have a history of your changes.

That sounds workable. Maybe even a limited diff output send as the commit message.

Something like “line 47 changed from <old line47>” or “7 lines changed”

I’ll have to ponder on that.