[Beowulf] Thoughts on git?

[Faraz Hussain]

I am curious what people think of git. On one hand everyone seems to
be using it and proclaiming its virtues. On the other hand it seems
way overkill for how the majority of people code.

I maintain dozens of scripts to manage various HPC environments . None
are more than a few hundred lines long. To do backups of scripts, I
just copy them to some backup folder. Occasionally I might tar them up
and copy them to a different server. I have never had a need to go
back to an older version of my script.

So I tried to learn git but find it very confusing. It seems designed
for teams of developers working on some million+ line of code project.
For my rinky-dinky scripts it just adds a lot of confusion. It seems I
need to "commit" to using git everyday in order for it to be
effective. Otherwise, use it or lose it.

Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?

_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe)

[John Hearns via Beowulf]

Faraz, I use git every day.
We have Bitbucket here, and have linked the repositories to Jira for our
sprint planning and kanban.

Anyway - you say something very relevant "I have never had a need to go
back to an older version of my script."
It is not only about rollback to older versions. If you are workign in a
small team, I think you really have to have the production version of
scripts defined somewhere.
For instance I work with PBS Hooks, which are Python scripts. I need to
know which are the ones in use on our PBS server.
(Yes -you can do a fetch of the script from the PBS server. I know how to
do that).
But it is cleaner and easier to point towards the master of that repo and
say - these are the PBS hooks we are using right now.
I can then create a branch and go off to implemen tchanges on our test
cluster - knowing that the master branch remains untouched.
When we are happy I get a colleague to to a merge.

Regarding the command line of git, I do agree that it can be confusing.
I discovered the Atom editor, which has an in-build GUI for git.
https://webdesign.tutsplus.com/articles/quick-tip-how-to-use-atom-as-a-git-gui--cms-21073

Also now start to think about disaster recovery, and software defined
infrastructure.

Firstly, lets us be extreme. Your data centre burns down. Your management
are breathing down your neck. They want the service back up and running.
Funds magically appear, and a bunch of servers appears on the loading dock
of the new data centre.
Are you confident those scripts can be integrated onto the new setup?

Also the trend now is to software defined infrastructures. You stand up new
nodes and configure them using defined rules.
You may want to copy some of those scripts onto the nodes - lets' say they
are PBS hooks, or pre job healthchecks.
I admit we are nowhere near doing that effictively, but it is our goal.

I am curious what people think of git. On one hand everyone seems to be
using it and proclaiming its virtues. On the other hand it seems way
overkill for how the majority of people code.
I maintain dozens of scripts to manage various HPC environments . None are
more than a few hundred lines long. To do backups of scripts, I just copy
them to some backup folder. Occasionally I might tar them up and copy them
to a different server. I have never had a need to go back to an older
version of my script.
So I tried to learn git but find it very confusing. It seems designed for
teams of developers working on some million+ line of code project. For my
rinky-dinky scripts it just adds a lot of confusion. It seems I need to
"commit" to using git everyday in order for it to be effective. Otherwise,
use it or lose it.
Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[John Hearns via Beowulf]

Faraz - a shorter answer. If you already have a git repository, try using
Atom https://atom.io/

Post by John Hearns via Beowulf
Faraz, I use git every day.
We have Bitbucket here, and have linked the repositories to Jira for our
sprint planning and kanban.
Anyway - you say something very relevant "I have never had a need to go
back to an older version of my script."
It is not only about rollback to older versions. If you are workign in a
small team, I think you really have to have the production version of
scripts defined somewhere.
For instance I work with PBS Hooks, which are Python scripts. I need to
know which are the ones in use on our PBS server.
(Yes -you can do a fetch of the script from the PBS server. I know how to
do that).
But it is cleaner and easier to point towards the master of that repo and
say - these are the PBS hooks we are using right now.
I can then create a branch and go off to implemen tchanges on our test
cluster - knowing that the master branch remains untouched.
When we are happy I get a colleague to to a merge.
Regarding the command line of git, I do agree that it can be confusing.
I discovered the Atom editor, which has an in-build GUI for git.
https://webdesign.tutsplus.com/articles/quick-tip-how-to-
use-atom-as-a-git-gui--cms-21073
Also now start to think about disaster recovery, and software defined
infrastructure.
Firstly, lets us be extreme. Your data centre burns down. Your management
are breathing down your neck. They want the service back up and running.
Funds magically appear, and a bunch of servers appears on the loading dock
of the new data centre.
Are you confident those scripts can be integrated onto the new setup?
Also the trend now is to software defined infrastructures. You stand up
new nodes and configure them using defined rules.
You may want to copy some of those scripts onto the nodes - lets' say they
are PBS hooks, or pre job healthchecks.
I admit we are nowhere near doing that effictively, but it is our goal.

I am curious what people think of git. On one hand everyone seems to be
using it and proclaiming its virtues. On the other hand it seems way
overkill for how the majority of people code.
I maintain dozens of scripts to manage various HPC environments . None
are more than a few hundred lines long. To do backups of scripts, I just
copy them to some backup folder. Occasionally I might tar them up and copy
them to a different server. I have never had a need to go back to an older
version of my script.
So I tried to learn git but find it very confusing. It seems designed for
teams of developers working on some million+ line of code project. For my
rinky-dinky scripts it just adds a lot of confusion. It seems I need to
"commit" to using git everyday in order for it to be effective. Otherwise,
use it or lose it.
Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[Alex Chekholko via Beowulf]

Here is a user-friendly guide that can provide you with some motivation to
use git:

http://www-cs-students.stanford.edu/~blynn/gitmagic/

Post by John Hearns via Beowulf
Faraz, I use git every day.
We have Bitbucket here, and have linked the repositories to Jira for our
sprint planning and kanban.
Anyway - you say something very relevant "I have never had a need to go
back to an older version of my script."
It is not only about rollback to older versions. If you are workign in a
small team, I think you really have to have the production version of
scripts defined somewhere.
For instance I work with PBS Hooks, which are Python scripts. I need to
know which are the ones in use on our PBS server.
(Yes -you can do a fetch of the script from the PBS server. I know how to
do that).
But it is cleaner and easier to point towards the master of that repo and
say - these are the PBS hooks we are using right now.
I can then create a branch and go off to implemen tchanges on our test
cluster - knowing that the master branch remains untouched.
When we are happy I get a colleague to to a merge.
Regarding the command line of git, I do agree that it can be confusing.
I discovered the Atom editor, which has an in-build GUI for git.
https://webdesign.tutsplus.com/articles/quick-tip-how-to-use-atom-as-a-git-gui--cms-21073
Also now start to think about disaster recovery, and software defined
infrastructure.
Firstly, lets us be extreme. Your data centre burns down. Your management
are breathing down your neck. They want the service back up and running.
Funds magically appear, and a bunch of servers appears on the loading dock
of the new data centre.
Are you confident those scripts can be integrated onto the new setup?
Also the trend now is to software defined infrastructures. You stand up
new nodes and configure them using defined rules.
You may want to copy some of those scripts onto the nodes - lets' say they
are PBS hooks, or pre job healthchecks.
I admit we are nowhere near doing that effictively, but it is our goal.

I am curious what people think of git. On one hand everyone seems to be
using it and proclaiming its virtues. On the other hand it seems way
overkill for how the majority of people code.
I maintain dozens of scripts to manage various HPC environments . None
are more than a few hundred lines long. To do backups of scripts, I just
copy them to some backup folder. Occasionally I might tar them up and copy
them to a different server. I have never had a need to go back to an older
version of my script.
So I tried to learn git but find it very confusing. It seems designed for
teams of developers working on some million+ line of code project. For my
rinky-dinky scripts it just adds a lot of confusion. It seems I need to
"commit" to using git everyday in order for it to be effective. Otherwise,
use it or lose it.
Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[Peter Clapham]

Thank you,

The multi-language component of the link is very useful. One to pass on locally.
Pete

From: Beowulf <beowulf-***@beowulf.org> on behalf of Alex Chekholko via Beowulf <***@beowulf.org>
Reply-To: Alex Chekholko <***@calicolabs.com>
Date: Tuesday, December 19, 2017 at 4:45 PM
To: John Hearns <***@googlemail.com>
Cc: Beowulf Mailing List <***@beowulf.org>
Subject: Re: [Beowulf] Thoughts on git?

Here is a user-friendly guide that can provide you with some motivation to use git:


http://www-cs-students.stanford.edu/~blynn/gitmagic/


On Tue, Dec 19, 2017 at 8:41 AM John Hearns via Beowulf <***@beowulf.org<mailto:***@beowulf.org>> wrote:
Faraz, I use git every day.
We have Bitbucket here, and have linked the repositories to Jira for our sprint planning and kanban.

Anyway - you say something very relevant "I have never had a need to go back to an older version of my script."
It is not only about rollback to older versions. If you are workign in a small team, I think you really have to have the production version of scripts defined somewhere.
For instance I work with PBS Hooks, which are Python scripts. I need to know which are the ones in use on our PBS server.
(Yes -you can do a fetch of the script from the PBS server. I know how to do that).
But it is cleaner and easier to point towards the master of that repo and say - these are the PBS hooks we are using right now.
I can then create a branch and go off to implemen tchanges on our test cluster - knowing that the master branch remains untouched.
When we are happy I get a colleague to to a merge.

Regarding the command line of git, I do agree that it can be confusing.
I discovered the Atom editor, which has an in-build GUI for git.
https://webdesign.tutsplus.com/articles/quick-tip-how-to-use-atom-as-a-git-gui--cms-21073

Also now start to think about disaster recovery, and software defined infrastructure.

Firstly, lets us be extreme. Your data centre burns down. Your management are breathing down your neck. They want the service back up and running.
Funds magically appear, and a bunch of servers appears on the loading dock of the new data centre.
Are you confident those scripts can be integrated onto the new setup?

Also the trend now is to software defined infrastructures. You stand up new nodes and configure them using defined rules.
You may want to copy some of those scripts onto the nodes - lets' say they are PBS hooks, or pre job healthchecks.
I admit we are nowhere near doing that effictively, but it is our goal.


































On 19 December 2017 at 17:11, Faraz Hussain <***@feacluster.com<mailto:***@feacluster.com>> wrote:
I am curious what people think of git. On one hand everyone seems to be using it and proclaiming its virtues. On the other hand it seems way overkill for how the majority of people code.

I maintain dozens of scripts to manage various HPC environments . None are more than a few hundred lines long. To do backups of scripts, I just copy them to some backup folder. Occasionally I might tar them up and copy them to a different server. I have never had a need to go back to an older version of my script.

So I tried to learn git but find it very confusing. It seems designed for teams of developers working on some million+ line of code project. For my rinky-dinky scripts it just adds a lot of confusion. It seems I need to "commit" to using git everyday in order for it to be effective. Otherwise, use it or lose it.

Should I force myself to use git everyday? Or maybe find some incrementally better way to manage backups of my scripts?

_______________________________________________
Beowulf mailing list, ***@beowulf.org<mailto:***@beowulf.org> sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

_______________________________________________
Beowulf mailing list, ***@beowulf.org<mailto:***@beowulf.org> sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
--
Sent from a "phone".

[Brian Oborn]

I argue that using a source control system of any kind is useful for
answering the questions like "This was working 6 months ago. What have I
changed since then?" or "This line of code to work around feature X is odd.
When did I change it and what was my motivation at the time?"

Git has the advantage that it doesn't require a server to track the commits
for a single person so you could just use it on a local filesystem with
normal file-level backups. That would reduce the complexity quite a bit.

Brian Oborn

I am curious what people think of git. On one hand everyone seems to be
using it and proclaiming its virtues. On the other hand it seems way
overkill for how the majority of people code.
I maintain dozens of scripts to manage various HPC environments . None are
more than a few hundred lines long. To do backups of scripts, I just copy
them to some backup folder. Occasionally I might tar them up and copy them
to a different server. I have never had a need to go back to an older
version of my script.
So I tried to learn git but find it very confusing. It seems designed for
teams of developers working on some million+ line of code project. For my
rinky-dinky scripts it just adds a lot of confusion. It seems I need to
"commit" to using git everyday in order for it to be effective. Otherwise,
use it or lose it.
Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[Adam DeConinck]

I am also a fan of putting everything in source control. This is useful for
small scripts, but even more so (IMO) for configuration files. Being able
to track changes closely is a lifesaver when something about a system stops
working, and you have no idea what has changed. Source control has saved me
from the “this change is harmless!” problem many times.

As for git itself... I’m kind of meh. I do use it. The distributed model
is great, and you have the advantage of the popular tool having a lot of
debugging resources. But the CLI can be confusing, especially if you don’t
use it often, and I think the official documentation is not great. So I
think choosing some other system (Mercurial, Bazaar, Subversion) is
perfectly defensible if it works better for you. At the
small-scripts-and-config level, I think the biggest win is in using source
control at all.

Post by Brian Oborn
I argue that using a source control system of any kind is useful for
answering the questions like "This was working 6 months ago. What have I
changed since then?" or "This line of code to work around feature X is odd.
When did I change it and what was my motivation at the time?"
Git has the advantage that it doesn't require a server to track the
commits for a single person so you could just use it on a local filesystem
with normal file-level backups. That would reduce the complexity quite a
bit.
Brian Oborn

I am curious what people think of git. On one hand everyone seems to be
using it and proclaiming its virtues. On the other hand it seems way
overkill for how the majority of people code.
I maintain dozens of scripts to manage various HPC environments . None
are more than a few hundred lines long. To do backups of scripts, I just
copy them to some backup folder. Occasionally I might tar them up and copy
them to a different server. I have never had a need to go back to an older
version of my script.
So I tried to learn git but find it very confusing. It seems designed for
teams of developers working on some million+ line of code project. For my
rinky-dinky scripts it just adds a lot of confusion. It seems I need to
"commit" to using git everyday in order for it to be effective. Otherwise,
use it or lose it.
Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[Chris Samuel]

Post by Adam DeConinck
I am also a fan of putting everything in source control. This is useful for
small scripts, but even more so (IMO) for configuration files. Being able
to track changes closely is a lifesaver when something about a system stops
working, and you have no idea what has changed. Source control has saved me
from the “this change is harmless!” problem many times.

+1 for this - and also the related "etckeeper" which is packaged in Debian/
Ubuntu and RHEL/CentOS. It hooks in to apt/yum and basically automates
version control for your /etc directory.

It defaults to using git (though others are possible, Ubuntu used to default
to bzr for some bizare reason - sorry) and by default will do daily commits of
/etc as well as before and after package manager changes (so you can see what
files in /etc were changed by a particular package install/upgrade/removal).

You can also drive it yourself, if you modify something in /etc then you can
just (as root, obviously) do:

/etc # etckeeper commit "Changed foo to bar in all config files"

Which then lets you revert it should you decide that perhaps some foo's were
actually needed. Of course you can still use the underlying VCS commands too,
it's just providing a handy wrapper.

All the best,
Chris

[Nathan Moore]

Not sure how well known the Software Carpentry folks are to this list.
Their tutorial on git is mature and clear.

http://swcarpentry.github.io/git-novice/

Post by Chris Samuel

Post by Adam DeConinck
I am also a fan of putting everything in source control. This is useful

for

Post by Adam DeConinck
small scripts, but even more so (IMO) for configuration files. Being able
to track changes closely is a lifesaver when something about a system

stops

Post by Adam DeConinck
working, and you have no idea what has changed. Source control has saved

me

Post by Adam DeConinck
from the “this change is harmless!” problem many times.

+1 for this - and also the related "etckeeper" which is packaged in Debian/
Ubuntu and RHEL/CentOS. It hooks in to apt/yum and basically automates
version control for your /etc directory.
It defaults to using git (though others are possible, Ubuntu used to default
to bzr for some bizare reason - sorry) and by default will do daily commits of
/etc as well as before and after package manager changes (so you can see what
files in /etc were changed by a particular package
install/upgrade/removal).
You can also drive it yourself, if you modify something in /etc then you can
/etc # etckeeper commit "Changed foo to bar in all config files"
Which then lets you revert it should you decide that perhaps some foo's were
actually needed. Of course you can still use the underlying VCS commands too,
it's just providing a handy wrapper.
All the best,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[John Hearns via Beowulf]

Nathan, Sir - you are a prize Git.
Abusive retorts aside, there is another very good use for Git.

As a fan of the Julia language, I report that Julia packages are held as
repositories on Github.
If you want to work with an unregistered package (which is usually a
development project)
you bring the package onto your system using a 'git clone'.

I'm not really sure how you would then cope with a secure site with no
Internet access.
Last time I had to install RPM updates on a Government secure site we
cloned the repository to a hard drive
and brought it onto site. It is easy enough to make a local clone of a Git
repo on a hard drive.
I guess I should ask on the Julia list how to use that as a repo for
packages.

Post by Nathan Moore
Not sure how well known the Software Carpentry folks are to this list.
Their tutorial on git is mature and clear.
http://swcarpentry.github.io/git-novice/

Post by Adam DeConinck

Post by Adam DeConinck
I am also a fan of putting everything in source control. This is useful

for

Post by Adam DeConinck
small scripts, but even more so (IMO) for configuration files. Being

able

Post by Adam DeConinck
to track changes closely is a lifesaver when something about a system

stops

Post by Adam DeConinck
working, and you have no idea what has changed. Source control has

saved me

Post by Adam DeConinck
from the “this change is harmless!” problem many times.

+1 for this - and also the related "etckeeper" which is packaged in Debian/
Ubuntu and RHEL/CentOS. It hooks in to apt/yum and basically automates
version control for your /etc directory.
It defaults to using git (though others are possible, Ubuntu used to default
to bzr for some bizare reason - sorry) and by default will do daily commits of
/etc as well as before and after package manager changes (so you can see what
files in /etc were changed by a particular package
install/upgrade/removal).
You can also drive it yourself, if you modify something in /etc then you can
/etc # etckeeper commit "Changed foo to bar in all config files"
Which then lets you revert it should you decide that perhaps some foo's were
actually needed. Of course you can still use the underlying VCS commands too,
it's just providing a handy wrapper.
All the best,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

--
- - - - - - - - - - - - - - - - - - - - -
Nathan Moore
Mississippi River and 44th Parallel
- - - - - - - - - - - - - - - - - - - - -
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

[Peter Clapham]

+1

Also add in the potential for CI and CD as part of the hooks within git and you have a powerful method to ensure changes to your code are unlikely to impact your environment.

By integrating with gitlab (etc) a GUI can also help your servicedesk accept proposals and have the updates then deploy as a part of an automated workload.

Rollback, backup, remove cursing of former self (or at least reduce its potential), making others live simper and reducing potential risks are all good things that can come of using a solid versioning tool.

Pete

From: Beowulf <beowulf-***@beowulf.org> on behalf of John Hearns via Beowulf <***@beowulf.org>
Reply-To: John Hearns <***@googlemail.com>
Date: Tuesday, December 19, 2017 at 4:41 PM
To: Beowulf Mailing List <***@beowulf.org>
Subject: Re: [Beowulf] Thoughts on git?

Faraz, I use git every day.
We have Bitbucket here, and have linked the repositories to Jira for our sprint planning and kanban.

Anyway - you say something very relevant "I have never had a need to go back to an older version of my script."
It is not only about rollback to older versions. If you are workign in a small team, I think you really have to have the production version of scripts defined somewhere.
For instance I work with PBS Hooks, which are Python scripts. I need to know which are the ones in use on our PBS server.
(Yes -you can do a fetch of the script from the PBS server. I know how to do that).
But it is cleaner and easier to point towards the master of that repo and say - these are the PBS hooks we are using right now.
I can then create a branch and go off to implemen tchanges on our test cluster - knowing that the master branch remains untouched.
When we are happy I get a colleague to to a merge.

Regarding the command line of git, I do agree that it can be confusing.
I discovered the Atom editor, which has an in-build GUI for git.
https://webdesign.tutsplus.com/articles/quick-tip-how-to-use-atom-as-a-git-gui--cms-21073

Also now start to think about disaster recovery, and software defined infrastructure.

Firstly, lets us be extreme. Your data centre burns down. Your management are breathing down your neck. They want the service back up and running.
Funds magically appear, and a bunch of servers appears on the loading dock of the new data centre.
Are you confident those scripts can be integrated onto the new setup?

Also the trend now is to software defined infrastructures. You stand up new nodes and configure them using defined rules.
You may want to copy some of those scripts onto the nodes - lets' say they are PBS hooks, or pre job healthchecks.
I admit we are nowhere near doing that effictively, but it is our goal.


































On 19 December 2017 at 17:11, Faraz Hussain <***@feacluster.com<mailto:***@feacluster.com>> wrote:
I am curious what people think of git. On one hand everyone seems to be using it and proclaiming its virtues. On the other hand it seems way overkill for how the majority of people code.

I maintain dozens of scripts to manage various HPC environments . None are more than a few hundred lines long. To do backups of scripts, I just copy them to some backup folder. Occasionally I might tar them up and copy them to a different server. I have never had a need to go back to an older version of my script.

So I tried to learn git but find it very confusing. It seems designed for teams of developers working on some million+ line of code project. For my rinky-dinky scripts it just adds a lot of confusion. It seems I need to "commit" to using git everyday in order for it to be effective. Otherwise, use it or lose it.

Should I force myself to use git everyday? Or maybe find some incrementally better way to manage backups of my scripts?

_______________________________________________
Beowulf mailing list, ***@beowulf.org<mailto:***@beowulf.org> sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

[Tim Cutts]

I agree it is quite intimidating, but the basic version control features are pretty basic; if you don’t want to branch/merge, you don’t have to. Neither do you have to do all the git pull/push to another git instance somewhere else.

You can do basic version control on an entire directory with just two commands:

git init

to start controlling the directory and its contents and

git commit –a

each time you want to save the current state into the repository. At this point you’ve got the same functionality as old-school rcs, plus the ability to deal with removing, adding and renaming files.

Others have already been eloquent about good reasons to use git in a more sophisticated way, so I won’t repeat what they’ve said.

git is something you’re going to be forced to use though, anyway, in other contexts. If you want to participate in pretty much any open source project now, you do kind of need to know some basic git stuff. I am by no means a git expert (I don’t know what re-base actually means, for example)

One thing I started doing recently was deploying a containerised application, the source of which lives on github. I need to make some changes to the docker configuration to make it work in our network environment, so I have some local customisations in a branch. Pulling down new versions from upstream is now pretty simple (and I’ve had to do that every couple of weeks recently). Manually re-making my changes would be a PITA, but I don’t have to do that because git merge does it for me. I’m probably doing it wrong, but updating the system for me becomes a matter of:

git checkout master
git pull
git checkout sanger_prod
git merge master
# check it all worked
git commit –m “Merged upstream for <reason>”
docker-compose up -d --build

Not too painful.

Tim

On 19/12/2017, 16:11, "Beowulf on behalf of Faraz Hussain" <beowulf-***@beowulf.org on behalf of ***@feacluster.com> wrote:

I am curious what people think of git. On one hand everyone seems to
be using it and proclaiming its virtues. On the other hand it seems
way overkill for how the majority of people code.

I maintain dozens of scripts to manage various HPC environments . None
are more than a few hundred lines long. To do backups of scripts, I
just copy them to some backup folder. Occasionally I might tar them up
and copy them to a different server. I have never had a need to go
back to an older version of my script.

So I tried to learn git but find it very confusing. It seems designed
for teams of developers working on some million+ line of code project.
For my rinky-dinky scripts it just adds a lot of confusion. It seems I
need to "commit" to using git everyday in order for it to be
effective. Otherwise, use it or lose it.

Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?

_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf

[Skylar Thompson]

90% of the battle is using a VCS to begin with. Whether that's SVN, git,
Mercurial, etc. is somewhat irrelevant - just pick something with the
features (and ease of use is a feature!) that you and your team need and
stick with it.

In my professional life, I've found SVN to suit my needs and be easy
enough for other folks I work with (even ones without software
development expertise) to use.

Skylar

I am curious what people think of git. On one hand everyone seems to be
using it and proclaiming its virtues. On the other hand it seems way
overkill for how the majority of people code.
I maintain dozens of scripts to manage various HPC environments . None
are more than a few hundred lines long. To do backups of scripts, I just
copy them to some backup folder. Occasionally I might tar them up and
copy them to a different server. I have never had a need to go back to
an older version of my script.
So I tried to learn git but find it very confusing. It seems designed
for teams of developers working on some million+ line of code project.
For my rinky-dinky scripts it just adds a lot of confusion. It seems I
need to "commit" to using git everyday in order for it to be effective.
Otherwise, use it or lose it.
Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?
_______________________________________________
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf

_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailm

[Lux, Jim (337K)]

The problem with git is that it wasn’t “architected”, it just sort of grew to meet a variety of needs. So the commands don’t necessarily make sense, and there are multiple ways to achieve a particular desired end result, particularly in a simple environment. (

And, of course, like any other source code control system, the commands and terminology are different for git than every other SCCS.

Most projects wind up issuing a set of “here’s how WE are doing these 5 things in git” with cookbook sets of commands for the things that everybody does on a day to day basis.





On 12/19/17, 8:11 AM, "Beowulf on behalf of Faraz Hussain" <beowulf-***@beowulf.org on behalf of ***@feacluster.com> wrote:

I am curious what people think of git. On one hand everyone seems to
be using it and proclaiming its virtues. On the other hand it seems
way overkill for how the majority of people code.

I maintain dozens of scripts to manage various HPC environments . None
are more than a few hundred lines long. To do backups of scripts, I
just copy them to some backup folder. Occasionally I might tar them up
and copy them to a different server. I have never had a need to go
back to an older version of my script.

So I tried to learn git but find it very confusing. It seems designed
for teams of developers working on some million+ line of code project.
For my rinky-dinky scripts it just adds a lot of confusion. It seems I
need to "commit" to using git everyday in order for it to be
effective. Otherwise, use it or lose it.

Should I force myself to use git everyday? Or maybe find some
incrementally better way to manage backups of my scripts?

_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf


_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscrib

[Faraz Hussain]

Thanks for all the replies. I am following the tutorial from the
Stanford page. I still think a simple bash script that uses rsyc could
handle what I need. But since everyone is using git, I should learn
that.

It seems only "git clone" always works as I expect. The other commands
always give errors, i.e add, push, pull, commit.. Since I am only the
"developer" of my script, it will take more time to ingrain this
source control mentality :-)

http://www-cs-students.stanford.edu/~blynn/gitmagic/ might
have a way for you to come up to speed on git.
I use git for all things that I need to keep track of - documents,
code, websites
and especially my /etc folders (via etckeeper).
Do check out the link above. I am sure you'll find it useful.
Harish

_______________________________________________
Beowulf mailing list, ***@beowulf.org sponsored by Penguin Computing
To change your subscription (digest mode or unsubscribe) vi