

Y U NO commit?? - esneider
https://github.com/esneider/YUNOcommit.vim

======
remon
Committing code should not be a glorified Ctrl/Cmd+S. With few exceptions each
commit should be an isolated unit of work. Also, this floating to the top of
HN is a bit of a mystery to me.

~~~
akavel
You can really have two "species" of commits:

One of them is the "published, shared" kind; for this one, I can agree with
you, that they should be self-contained and complete, especially when there
many devs on the project, and/or you'd like to be able to use bisect.

The second kind, and for me actually a _very_ important one, is more of a
"local backup, dirty hacking" one. Those shouldn't probably be published
(unless a private/one-guy repo), but allow for easy hacking, developing,
testing, experimenting. The "commit often, whatever you have, however broken
or non-ideal" approach provides safe lightweight backup, and allows for easy
switching between various paths/approaches. Now, after you design stabilizes,
dust settles down, and you are completing the work, you can (and probably
should) eventually either just squash everything into one final feature commit
(the end result will be indistinguishable to what you'd deliver if not
committing in the meantime), or remodel the intermediary commits to whatever
ideal shape you like them to have retroactively (with "git rebase -i",
including patch editing etc.) Knowing the benefits of this approach, I don't
understand why anyone would want to reject it.

edit: Also, with many small, dirty commits, it's sometimes possible to fairly
quickly do stuff like carving out some subfeature into a separate branch (with
judicious use of rebases, cherrypicking and some occasional small edits). Or,
remove/revert commits marked earlier as DEBUG. Seems useful to me, as a means
to somewhat speed up such operations and decrease the possibility of manual
error at the same time.

~~~
mcherm
Interestingly, I have two different version control systems for doing these
two different species of commit. The published kind, I do in my regular team
version control system, complete with commit comments that explain the meaning
of the complete thought that is being committed. The other kind (bookmarking
my state before messing around with things I may want to cleanly revert) I do
using the version control that is built into IntelliJ IDEA. It is completely
orthogonal to the one used by my team.

Other IDEs should offer this feature... it turns out to be quite useful in
practice.

~~~
Retric
I really like this approach, you can take it one step further. Set up an
automatic independent (aka private) commit after every successful compile.

~~~
mcherm
IntelliJ, when you combine the internal version control and the undo log,
manages it so that effectively there is a commit after each piece of typing --
without any need to save or even compile. That turns out to be a nice way of
working.

------
fredley
It took me a while, but I think this is a tool to automatically remind you to
commit your work after making [20] writes. It is a plugin for vim.

~~~
cshimmin
I thought it was clear enough from just the first sentence after the image:
"Set the number of writes without committing before the message is shown".

Anyways, this is a cute idea but as someone who compulsive hits save after
practically every edit (i.e. after most transitions from insert to normal
mode), this wouldn't be very helpful.

------
asgard1024
I think HN would do well with having a single sentence abstract on article
submissions, because I have no idea what is this about.

~~~
spacemanmatt
I suspect this gets bumped up more for meme-compliance than novelty. I rather
like the SublimeText plugin, gitgutters[1].

But it in any case, I'm a fan of VCS integration in my editor.

1\.
[https://github.com/jisaacks/GitGutter](https://github.com/jisaacks/GitGutter)

~~~
ayrx
GitGutter is available for vim as well.

------
ryanpardieck
This thread has included some interesting discussion of how everyone handles
the different tasks of a) committing individual units of work, b) saving
works-in-progress, c) syncing files, d) backing up files, and e) persistent
undo editor features.

I thought I'd toss out what my setup is right now on my personal machine, for
a bit of reflection/discussion...

\- I compulsively save to disk after nearly every edit, so I'm a big fan of
editors that provide some kind of persistent undo functionality. Right now I'm
using live-archive inside the Atom editor, and it is wonderful. I hit cmd-
shift-y and it pops the current buffer open in a live-archive interface that
includes VCR-like with rewind/fast-forward buttons, etc. It leaves me feeling
quite free to mess with code a little more dangerously that I would otherwise.
Whereas before I might briefly comment out a line while I try something out,
now I'll just delete it and hack away. Anything that was there is just a cmd-
shift-y away.

live-archive is actually maybe the foremost reason I'm still using Atom. I'll
probably switch away from it eventually, but I'm grown to like the customized
little hole I've built for myself, inside that particular editor. I might try
out a JetBrains IDE next, sometime ...

\- I don't do a lot of work-in-progress saving. Maybe I should be better about
this? I'm not a fan of git histories that read like "went to lunch," "stuck,
think on this--" etc. Even when I'm the only one that's going to be seeing
them. I keep a gitignored text file where I tend to scribble down notes like
this, but maybe I should play around with WIP commits.

\- For syncing I have an hourly cron job that does a rsync -av --delete-after
for my important directories to several different locations. This is mostly
meant as a true sync and not backup, but I do find myself using it as a way to
lose no more than an hour's work at a time. I might change this to running
every 30 or 20 minutes since it doesn't seem to tax the machine too much.

\- For backup I have crashplan backing everything up to a local external drive
and then their cloud service too. I haven't put a terrible amount of thought
into this. It only runs when I sleep. I want to play around with using arq and
amazon glacier eventually.

For git I just do small unit-of-work commits for myself, and then cleaning up
when necessary.

------
relate
I just wanted to point out vim's persistent undo:
[http://stackoverflow.com/questions/5700389/using-vims-
persis...](http://stackoverflow.com/questions/5700389/using-vims-persistent-
undo)

Sometimes I forget to commit, and suddenly I'm in the middle of a second
feature, with the code in a non-working state. Then it's perfect to just undo
back a couple of hours, save, commit, and redo back to where I am.

However, It's rather risky though if you're not confident with the undo
system, so it's a good idea to save the file to a temporary location first.

~~~
godDLL
Or use `git stash`.

Or use `git add -p`.

------
chris_wot
I'm finding that I commit in units of work. Currently, I'm refactoring
LibreOffice's SalGraphics class to move the mirroring from this class into an
upper layer, but I'm finding it better to do it little by little.

Gerrit topic is here:

[https://gerrit.libreoffice.org/#/q/status:open+project:core+...](https://gerrit.libreoffice.org/#/q/status:open+project:core+branch:master+topic:salgraphicsmirror,n,z)

I'm finding it productive to commit when I have a compilable change. I find it
helps me keep track of what's going on.

------
k-mcgrady
Wouldn't this just encourage people who don't want to commit to stop saving
regularly and possibly lose work?

~~~
Tehnix
Then they probably shouldn't be running this plugin in the first place. It's
more for the people that can occasionally forget to commit, and their commits
end up being huge.

~~~
k-mcgrady
Ah ok. I looked at it more as something you force on your co-workers :)

------
jbert
Slightly related, I get a lot of value out of a bash prompt which tells me:

\- if my git repo is dirty (uncommitted changes)

\- which branch it is on

\- if (and how many) changes I have stashed

It's not originally my work but I find it massively useful, since it avoids
the "committed but not pushed" failure mode, the "on wrong branch" failure
more and the "stashed and forgotten about" failure mode.

I know that regularly running git status would work, but this is a useful
visual reminder for me.

~~~
chris_wot
Link to bashism that allows this?

~~~
zorbo
[http://lmgtfy.com/?q=git+bash+integration](http://lmgtfy.com/?q=git+bash+integration)

~~~
chris_wot
[http://lmgtfy.com/?q=noone+likes+a+smartarse](http://lmgtfy.com/?q=noone+likes+a+smartarse)

------
atmosx
I guess professional programmers has this sort of thing already sorted out,
but it happens all to often to reach the point where my _new feature_ is
working as it should (appears to be stable), and I keep working on yet another
addition on the same branch. When I commit, I feel like I should have
committed at least 2 or 3 times by now.

Happens too often so I setup up this plugin from 20 to 10 and see how it goes!
But thanks, the idea is really handy.

~~~
zorbo
I have the same "problem". I guess I'm just too focuses on fixing stuff to
stop and commit. Thankfully we're alive in a time where we don't have to adapt
to our tools anymore, but our tools are adapting to us.

    
    
      git add <file> -p
    

This lets you pick chunks of code from <file> that you'd like to stage for
commit. When I feel I'm done coding for a session, I just run a `git diff` in
one window, and in the other one pick chunks that contain changes that belong
in one commit.

~~~
atmosx
Oh good to know! I didn't knew that was possible :-) thanks for the hint. I
use a cli tool called 'tig' to view difference between commits and not
committed changes.

~~~
dbdr
tig is (among other things) a more user-friendly tool that can replace git add
-p.

------
fmoralesc
I tend to write to disk after every edit (a bad habit, I know, but it's pretty
ingrained in my muscle memory), so as-is, this would spam me quite a bit.

A better criterion for determining when to display the message would be to
count the non-empty lines of the diff, and only show it if it passes a
threshold.

Or: only if the added/removed lines ratio is > 1, or something like that.

~~~
gmantastic
I save after every logical edit too - I think it's a good habit. You never get
caught out by network/file-system failures, and can confidently reload from
disk to a recent good state if you mess up or change your mind mid-edit.

I think commiting should be done for a more meaningful unit of work than a
single edit, something logically 'complete' akin to a transaction.

~~~
fmoralesc
I tried to integrate git into this with per-file repos once, but I never
really used it much: [https://github.com/fmoralesc/vim-
autogit](https://github.com/fmoralesc/vim-autogit) This commits on writes.

> I think commiting should be done for a more meaningful unit of work than a
> single edit, something logically 'complete' akin to a transaction.

What do you think would be a good set of criteria for what should count as a
meaningful unit of work?

~~~
gmantastic
Is the motivation for commit-on-write to get a kind of persistent history for
undo/redo? That is an interesting idea.

~~~
fmoralesc
Yes. The commits are recorded in an independent repo, so you can have both a
per-file history of changes and a global history.

------
yitchelle
I would typically commit at the end of the day, even if it is into my private
repository. So days, I think it as backup, but on other days, I use it to
socialise the code.

I find that this forces me to take stock of the current state of
implementation and put my mind in the right mind frame for the next stage.

When pushing it into the main repository, it will be a unit of work.

------
flowerpot
I like the general idea, I sometimes also tend to code too much until
committing, however, for me it is more a combination of running tests, amount
of code and of course completeness. Plus, I often start hammering ":w" when I
am stuck. (which would be miss-interpreted by this tool)

------
johncoltrane
Commit time is a good time to step back a little and think about what I wrote
and why. Organizing hunks of changes into a meaningful package. I usually
commit when I'm done with a feature (once or twice a day) or right after
fixing a bug (a good dozen times a day).

------
mmahemoff
Nice idea but I don't think I'd want to use it for risk of too many false
positives. e.g. if I lift a 20+ line function to move it somewhere else in the
file, I would guess it will warn I should commit now.

~~~
quarterto
It prompts every 20 _writes_ (i.e. saves), not lines modified.

------
robmccoll
Seems like a pretty useful idea. It would be great to also set thresholds on
number of files changed and total number of lines (ignoring whitespace)
changed.

------
clubhi
I have all my code in a dropbox synced in a dropbox folder. Works pretty well
in combination with something like Git.

------
loganfsmyth
I save pretty compulsively, so this would annoy the crap out of me...

------
davedx
I much prefer our ascii art doge when all tests pass. :)

------
brexis
Y U NO write this for other editors?

~~~
silverbax88
I would guess (and probably get downvoted for this) that it's because GIT is
so widely used, is not well structured and overall group source control is not
well understood by developers.

If you are exposed to several source control systems, you would avoid GIT, at
least until you know what you are doing. But so many people use it and don't
understand what they are doing, there are massive numbers of conversations
just like this article - often between people who have never used anything
other than GIT.

~~~
zenciadam
It's still better than when everyone just used CVS because that's what
everyone was used to.

