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
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
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.
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
For more options, visit https://groups.google.com/d/optout.