2

I have a bash script that I've written during the course of the last week. Today, I've decided to finally give git a try before making any further changes, created a git repository, etc. The script has two versions: script.sh and script1.sh. My question is whether there is a way to tell git that the latter is an updated version of the former? I've read the beginner chapters of the "git book" about 3 or 4 times now and I'm a little shaky on terminology, still. I don't think that merge is what I'm looking for. I've committed both of the files, but from what I understand that just means that they are two separate files of a project to be tracked. From now on I'll just be editing one file with its changes tracked, but is there a way to neatly preserve my work in the version control system from the "pre-git" days? Or am I imagining a function that isn't there?

3
  • 1
    A side note: it is very un-Unix to give executable files extensions. If you call your script from another script, and then re-write it in another language, would you change the extension. If so then you have to change all scripts that call the script. (you should instead use #! ) Commented Jan 6, 2017 at 17:41
  • @richard That's an interesting point to keep in mind! Funnily enough, I do it so that automatic syntax highlighting in VIM would be...Well, automatic haha! I guess I should have my priorities sorted.
    – Max
    Commented Jan 6, 2017 at 20:19
  • I thing there may be a way to configure vim to look at the #! Commented Jan 7, 2017 at 11:13

2 Answers 2

3

Yes, you overwrite script.sh with script1.sh, after an initial commit. Starting from scratch:

git init
git add script.sh
git commit -m "First version of script.sh"
mv script1.sh script.sh
git add script.sh
git commit -m "Second version of script.sh"

You'll then be able to see both versions of script.sh in git log, check out the previous version etc.

3
  • Ha! That's killer! Thank you! So, just to clarify, there isn't a "built-in way", for lack of a better phrase, to do it in git? It simply keeps track of single files? Sorry for being clingy-just trying to wrap my head around the concepts once and for all.
    – Max
    Commented Jan 6, 2017 at 15:12
  • 1
    Yes, it tracks changes to files (single or multiple). It completely replaces the kind of manual version control you're doing with copies of files. Commented Jan 6, 2017 at 15:34
  • 1
    Yes git does not track renames, some revision control systems do. However this is not a rename. you have script-revision0, script-revision1 etc. Then you put it in to git, and you have script at revision 0 and script at revision 1 etc. Commented Jan 6, 2017 at 17:39
1

To understand Git you need to think in snapshots which are the commits. After having changed the file across several commits you could track the changes via git diff script.sh

2
  • 1
    Yeah, absolutely! I got that part right, I just thought that maybe there is a function that lets me track one file as a version of another as opposed to tracking(taking snapshots of) changes in a single file, if that makes sense. Looks like I was wrong. My goal was to get the diffs between those two files.
    – Max
    Commented Jan 6, 2017 at 15:33
  • 1
    To get the diff between the two files, as separate files, you'd just use diff script.sh script1.sh. The whole point of git is to avoid having to copy files around to be able to compare changes; whenever you have a change that makes sense to keep as an identifiable change, you commit it, and then you can view the history of files as a succession of changes (and see what changed at each step). Commented Jan 6, 2017 at 15:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .