Closed bigos closed 9 years ago
Hey! Excellent news.
I haven't been going in any direction for a while, it pretty much does what it needs to for me. I'm not opposed to always committing to a specific branch or something, but I don't quite see the use-case. This mode is meant mainly for projects of files that are nice to have history for, but don't really require much information on each step. Mainly my tasks
org file and companions and my org-based website are examples of what I use this for.
I'm having a little trouble thinking up exactly what you're trying to accomplish, from what I can understand it might be better to use a lot of backup files (Emacs can make quite a few), or decrease the time between your commits. But I don't know your situation so I can't really say anything about it.
I've looked over your changes a little and it seems that the bulk of the work is being done in an external script. I have no idea what this script does so I can't comment on the actual functioning much either. It seems to me though that it would be strange to have something just automatically checkout another branch and start trying to commit to it.
I would like to know a little more about your needs in this case and also about your implementation before I accept or dismiss this direction you propose.
Thank you for contacting me.
Perhaps it's my overeaction, but my project manager took me once to the conference room and told me off in presence of one of the directors for commiting my work too often. He was complaining about being distracted by it while pair programming. The problem with Emacs backup files is that I can't use git tools to search and selectively merge code. Having lots of backup commits seems to integrate better with my workflow than having lots of Emacs backup files.
My script works like this. When I save a file, the script takes last branch commit at the HEAD of the branch and puts its SHA in hv variable. Then it commits my changes to the branch and looks for a wip/branch. Then it switches to the wip/branch, creating it if neccesary and checkouts the branch and commits it. Then it switches back to the branch soft resetting it to commit in hv variable. So my work is commited in wip/branch but in the branch it appears to be waiting to be commited due to using soft reset. I know I could make the script a bit better and will do it one day.
Perhaps I get too many commits in a wip/branch but deleting it now and the is not a problem. In the past, I ended sevaral times in a situation where I was doing something very complex and wished I commited my work before. Not doing it was very difficult to backtrack from the dead end. Having a record of my mistakes that I could analyse is a good thing.
I think you should fork this project and continue on in your own direction. I think it's an interesting idea, but I also think it would be very confusing to have a simple customization fundamentally change the workings of a module such as this. Your use case is far from just simply committing progress, which is what git-auto-commit-mode
is really all about.
If there's anything I can help with, you know where to find me.
It can be found at: https://github.com/bigos/git-auto-commit-mode
I'm not sure if we are going in different directions. Do you think it would be better if I turned it into separate project and call it git-auto-wip-mode? Your project just autocommits into current branch, while I try to commit ot a separate wip branch.