6 ms·

There's nothing wrong with committing often, but pushing too often should not be encouraged. If you commit a lot, you should probably rebase before pushing.

Touche 12y ago
> There's nothing wrong with committing often, but pushing too often should not be encouraged. Pushing often is just as import. Computers do fail.
- Dewie 12y ago
  If the concern is the computer failing, you should do backups. And it's probably simpler to use automated backups than using git push as a backup mechanism.
  - maguirre 12y ago
    Automated backups are useful. However how often can you backup? If you are hacking/experimenting backing up after every change seems too resource intensive
    - Dewie 12y ago
      I back up every 10 minutes. So I lose 10 minutes if I screw something up, which is acceptable to me. I guess I could back up every 5 minutes, and I don't think that would be a problem.
  - Touche 12y ago
    Adding another thing I have to keep track of and maintain is not simpler than 1 command that is pure muscle reflex.
    - Dewie 12y ago
      Once you have automated backup set up, how much work is it to maintain? If you keep your code in a few areas/directories (like for example /home/workspace), it seems like a set-it-and-forget-it thing. PS: how is a command that demands that you write a commit message really just 'muscle memory'?
      - Anderkent 12y ago
        git alias cw commit -a -m 'WIP' ;P (and before the outrage beings, I always push these to my private fork of the main repo, so it's basically just a way of syncing code between machines. Other ways of achieving this with git seem to be always painful; you can push to another machine but only if you rename branches, which is tedious)
        Dewie 12y ago
        Well now we are up to three, arguably distinct needs: - version control - backup - syncing Syncing can, like backup, be had with software and services that are dedicated to that end. I just use Dropbox, though I'm not that worried about privacy. I guess something could be built "from scratch" with rsync, if the ready-made alternatives arent satisfactory?
        Touche 12y ago
        All to avoid typing git push? Why?
        Dewie 12y ago
        No. You are assuming that my backup and syncing needs overlap with my git usage, so that all I need to backup or sync is to use git push in my already-existing git directories. I backup and/or sync things that I don't have under version control (git). I only sync my grocery list, for example, since I don't need a history of the 'evolution' of my grocery list. Actually, I may have it under a backup scheme, but that is only because of other files and directories in that directory that I need to backup, and I've at this point set (and partly forgot) that backup plan. My /home/Dropbox contains a lot of files that I regularly need, and it seems a bit excessive to put all of that into one, monolithic git repo.
- lazerwalker 12y ago
  My code folder is synced with Dropbox. Probably bandwidth-heavy, sure, but if I have Internet access than that generally means I'll lose at most 5-10 minutes of work in the case of disaster.
ulisesrmzroche 12y ago
There's really nothing wrong with pushing your changes, and even force-pushing, so long as its not in your master branch.
- Myrmornis 12y ago
  Yeah. One slightly annoying thing is that git doesn't provide a way to disable force pushes to particular branches (how would such a thing even be implemented? I guess the remote would have to remember the old and new branch pointers and determine whether the change is fast forward for each individual branch) So if you want your team to be able to do what you say then someone could force push to master by mistake.
philjackson 12y ago
What if, in a team-based situation, someone is off and half way through a feature. Based on your point above there's now two problems: * Getting the stuff off the developer's machine because they didn't push their code. * Even if the code is retrieved, now the commit log is a mess of commits that were based on nothing but arbitrary time lapses. It would be preferable they're a 'story' of the current development process for the feature and atomic in their own right.

Touche 12y ago

> There's nothing wrong with committing often, but pushing too often should not be encouraged. Pushing often is just as import. Computers do fail.

Dewie 12y ago
If the concern is the computer failing, you should do backups. And it's probably simpler to use automated backups than using git push as a backup mechanism.
- maguirre 12y ago
  Automated backups are useful. However how often can you backup? If you are hacking/experimenting backing up after every change seems too resource intensive
  - Dewie 12y ago
    I back up every 10 minutes. So I lose 10 minutes if I screw something up, which is acceptable to me. I guess I could back up every 5 minutes, and I don't think that would be a problem.
- Touche 12y ago
  Adding another thing I have to keep track of and maintain is not simpler than 1 command that is pure muscle reflex.
  - Dewie 12y ago
    Once you have automated backup set up, how much work is it to maintain? If you keep your code in a few areas/directories (like for example /home/workspace), it seems like a set-it-and-forget-it thing. PS: how is a command that demands that you write a commit message really just 'muscle memory'?
    - Anderkent 12y ago
      git alias cw commit -a -m 'WIP' ;P (and before the outrage beings, I always push these to my private fork of the main repo, so it's basically just a way of syncing code between machines. Other ways of achieving this with git seem to be always painful; you can push to another machine but only if you rename branches, which is tedious)
      - Dewie 12y ago
        Well now we are up to three, arguably distinct needs: - version control - backup - syncing Syncing can, like backup, be had with software and services that are dedicated to that end. I just use Dropbox, though I'm not that worried about privacy. I guess something could be built "from scratch" with rsync, if the ready-made alternatives arent satisfactory?
        Touche 12y ago
        All to avoid typing git push? Why?
        Dewie 12y ago
        No. You are assuming that my backup and syncing needs overlap with my git usage, so that all I need to backup or sync is to use git push in my already-existing git directories. I backup and/or sync things that I don't have under version control (git). I only sync my grocery list, for example, since I don't need a history of the 'evolution' of my grocery list. Actually, I may have it under a backup scheme, but that is only because of other files and directories in that directory that I need to backup, and I've at this point set (and partly forgot) that backup plan. My /home/Dropbox contains a lot of files that I regularly need, and it seems a bit excessive to put all of that into one, monolithic git repo.
lazerwalker 12y ago
My code folder is synced with Dropbox. Probably bandwidth-heavy, sure, but if I have Internet access than that generally means I'll lose at most 5-10 minutes of work in the case of disaster.

ulisesrmzroche 12y ago

There's really nothing wrong with pushing your changes, and even force-pushing, so long as its not in your master branch.

Myrmornis 12y ago
Yeah. One slightly annoying thing is that git doesn't provide a way to disable force pushes to particular branches (how would such a thing even be implemented? I guess the remote would have to remember the old and new branch pointers and determine whether the change is fast forward for each individual branch) So if you want your team to be able to do what you say then someone could force push to master by mistake.

philjackson 12y ago

What if, in a team-based situation, someone is off and half way through a feature. Based on your point above there's now two problems: * Getting the stuff off the developer's machine because they didn't push their code. * Even if the code is retrieved, now the commit log is a mess of commits that were based on nothing but arbitrary time lapses. It would be preferable they're a 'story' of the current development process for the feature and atomic in their own right.