4 ms·

Push and Pull almost always from the cli. But one of the things I find tools like Sourcetree useful for is selecting which changes (hunks, files or selected lin

Push and Pull almost always from the cli. But one of the things I find tools like Sourcetree useful for is selecting which changes (hunks, files or selected lines) to stage for commit, which is in my opinion much easier than with the CLI only.

DJHenk 6y ago
> selecting which changes (hunks, files or selected lines) to stage for commit I never understood why people feel the need do this. If you are working on a bug or feature, why put unrelated changes in that branch? It only creates confusion and probably messes up your tests too. And for what? It seems like a chaotic way of working to me.
- nemetroid 6y ago
  Who said they were unrelated? Sometimes a single commit is the best presentation of a bug fix/feature implementation, sometimes it makes more sense to split the work into multiple commits.
  - DJHenk 6y ago
    I can understand that. But in my mind, if things are separate enough that I want multiple commits, then I would work on them separately. If a feature needs A, but A needs B, then I would work on B, commit that and only then work on A. Sometimes working on A will cause me to change the committed B part a little, but that's fine. At the moment in time that I committed B it was a perfectly reasonable solution that I can revert back to. You know what, typing it out I can totally see why people do it the other way. A matter of personal preference probably.
    - Cogito 6y ago
      For me, I often don't know exactly how I am going to do something until I have done it. Once it's done I will split the changes into commits that make logical sense, for someone wondering how the new code changes the behaviour of the existing code.
- helloguillecl 6y ago
  For example I might be working on a specific feature and discover that my dev environment is missing something (For example replacing node by nodemon). I will make the change on the build script but I will not commit before testing the process for a couple of days, and certainly not before finishing the feature/bug I'm working on.
nonninz 6y ago
Try git add -uip

DJHenk 6y ago

> selecting which changes (hunks, files or selected lines) to stage for commit I never understood why people feel the need do this. If you are working on a bug or feature, why put unrelated changes in that branch? It only creates confusion and probably messes up your tests too. And for what? It seems like a chaotic way of working to me.

nemetroid 6y ago
Who said they were unrelated? Sometimes a single commit is the best presentation of a bug fix/feature implementation, sometimes it makes more sense to split the work into multiple commits.
- DJHenk 6y ago
  I can understand that. But in my mind, if things are separate enough that I want multiple commits, then I would work on them separately. If a feature needs A, but A needs B, then I would work on B, commit that and only then work on A. Sometimes working on A will cause me to change the committed B part a little, but that's fine. At the moment in time that I committed B it was a perfectly reasonable solution that I can revert back to. You know what, typing it out I can totally see why people do it the other way. A matter of personal preference probably.
  - Cogito 6y ago
    For me, I often don't know exactly how I am going to do something until I have done it. Once it's done I will split the changes into commits that make logical sense, for someone wondering how the new code changes the behaviour of the existing code.
helloguillecl 6y ago
For example I might be working on a specific feature and discover that my dev environment is missing something (For example replacing node by nodemon). I will make the change on the build script but I will not commit before testing the process for a couple of days, and certainly not before finishing the feature/bug I'm working on.

nonninz 6y ago

Try git add -uip