Hi Russ P,

On Sunday, December 10, 2017 at 5:32:32 AM UTC+1, Russ P wrote:
> Thanks for the help, guys. I will have to think about it a bit. I must 
> admit that I am concerned about "effing things up" if I try to use new git 
> commands for this problem.

I understand. Being so powerful, Git can seem really daunting in the 
beginning, kind of providing so many ways to shoot your legs off. But it in 
reality, it`s nowhere like that, of course, as that would be against the 
point of a Version Control System in the first place, especially one of the 
best there are :)

Tell me, do you use Git through command line, or you have some GUI?

And if you decide you would like to give it a try, let us know. If you`re 
still unsure, for the worst case, you can backup your whole project folder 
(with .git subfolder), so at least you have a peace of mind for yourself.

> One thing I have learned from this problem is that I should have committed 
> more often. Since I was doing a fairly extensive redesign, I was thinking 
> that I should hold off on committing until I had verified that everything 
> was working. Now I realize that was a huge mistake.

Lesson learned :) One of the very reasons Git exists is so you exactly _do 
not_ do that, but "commit early, commit often" (preferably each commit 
state should build successfully, but even that is not a must, if you know 
what you`re doing).

What people usually do in such situation is make a new branch where they 
want to start doing something, and off they go - hack, commit, rinse, 
repeat. Once you`re satisfied, you can merge to your main branch (usually 
"master" or "develop"), and you can even "rewrite" your commits before 
that. Or, you can drop the whole branch with all its commits as it never 

So there is really no reason not to commit in Git - but there usually is a 
reason not to work/commit on your main branch, thus branching/merging 
should be learned early with Git, as it`s really powerful - and yet really 
easy, especially if you`re working on your own.

It occurred to me that perhaps there should be some way of having "minor" 
> commits done automatically. I'm sure someone must have thought of this 
> before. Why not have a scheme to do an auto-commit (with no comment) every 
> time you compile successfully? If I had that, I could find the bug fairly 
> easily.

I don`t know *the* answer. But I could speculate about at least one of them 
- because it`s easy to do yourself (for your specific needs), and hard to 
do in general (for everyone`s needs)...? :) Read below.

How would it be implemented? I suppose it would be done by the build 
> system. I am using Scala and sbt. Could sbt be made to automatically do a 
> commit every time it builds successfully? I don't see why not. Heck, maybe 
> it has that feature already and I just don't know it! And perhaps git could 
> allow for "minor" commits without a comment. At least that would allow 
> someone like me to locate a bug easier. What do you think?

There, you answered it all yourself :)

One should check his build system, first to see if such feature is not 
already available (which could be quite possible), but if not, then 
investigate on something like "post build" events available.

Once you know how you can trigger some action on successful build (from 
within your build system), you can put there something like this to make an 
"auto save" commit (just note you should probably be doing this on a 
separate branch):

    git commit --all --no-edit --allow-empty-message

That`s it :) Here, "--all" option says you want to commit all the changes 
on all the files Git is currently tracking, "--no-edit" that you don`t want 
to edit the message text, and "--allow-empty-message" allows making a 
commit without a message - which is not considered a good practice, but 
yes, it can be done.

Just note that if you create new files (or rename existing ones), Git will 
not automatically commit these changes with the command above - I would 
leave it up to you to discover more here.

Regards, Buga

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to