3 ms·

The biggest quality of life improvement for me with git is a bash function I wrote that does add all, commit and push in one. Turns out I don’t care about all t

The biggest quality of life improvement for me with git is a bash function I wrote that does add all, commit and push in one. Turns out I don’t care about all the granular control it provides 99% of the time, it’s cumbersome: $ save This is a commit message no quotes

globular-toast 3y ago
So basically `scp -r` (recursive remote copy). It's what I call "dumb version control" and I've observed many people not going beyond this with git: https://blog.gpkb.org/posts/git-is-a-version-control-system/ https://blog.gpkb.org/posts/git-is-a-version-control-system/
- Thorrez 3y ago
  It's better than scp because it stores the commit message and the history, and old versions are immutable.
  - globular-toast 3y ago
    Well, I'm not sure what kind of commit messages would be possible other than "update" and "new version" etc. if you're committing everything each time.
    - Thorrez 3y ago
      Wouldn't it be possible to fix a bug then commit that fix?
rwmj 3y ago
This is fine for using git as a kind of offsite backup, but I hope you later rebase everything into meaningful commits with proper messages if you're going to share your work with anyone else.
- loloquwowndueo 3y ago
  Dunno, I’ve spent countless hours carefully grooming my git commit histories so they make sense and convey a coherent story, just to have them destroyed by some squash zealot at merge time . “Squash before merge” workflows seem to be more common these days and I have to think it’s mostly a push by people who do not know how to do interactive rebases and history rewrites.
  - Aissen 3y ago
    You did the right thing, and I'm sorry this happened to you. May you only have to contribute to non-squashing projects in the future.
  - tempest_ 3y ago
    I find it has more to do with people (myself included) who interact with git at a PR/MR level. If your PRs are small and you interact with git a lot using some web portal it sort of pushes you this way.
  - skydhash 3y ago
    Squash before merge is fine if you have a project tracker, where you can use the issue as a discussion hub to describe your thoughts. Then you put the issue number in the squashed commit message. The PR can serve as implementation specific documentation and discussion.
    - loloquwowndueo 3y ago
      I disagree: discussion in a ticket or issue tends to be as disorganized as the random series of commits that are frowned upon in “nice commit history” workflows. It’s just sweeping the mess to another place where it can’t easily be found. But it’s okay, I gave up trying to convince people. So I’ll just disagree and commit (pun intended).
- PurpleRamen 3y ago
  What's the worth of a commit-message? The code, it's documentation and the associated issue-number is enough information. Or are people just not using their other tools for communicating those things?
okl 3y ago
You could solve that with a git alias as well which might be a bit more orderly as it would be defined in the git config. You can prepend the command defined for a git alias with an exclamation mark to run anything (not limited to git subcommands). Last example on this page: https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases
lallysingh 3y ago
git commit -am 'commit message'
- Zambyte 3y ago
  && git push
nextlevelwizard 3y ago
Are you trying to tell me you actually don't review your staged changes and/or commits before you push them? Also how do you resolve conflicts? Or is this just your solo project with zero users so you dont have to worry about other people's commits or your own commit's quality?
- PurpleRamen 3y ago
  > Are you trying to tell me you actually don't review your staged changes and/or commits before you push them? The final review happens in the merge request-view on the forge. There is little reason for local reviewing. Especially when multiple people work on a branch. > Also how do you resolve conflicts? Editor.
  - nextlevelwizard 3y ago
    So you just push shit in and make a review request and only then check if you actually had the correct things in commit(s) and have a descriptive commit message? Yikes
    - PurpleRamen 3y ago
      I get the impression that many people here seems to be very challenged to know what they actually do. Do you just randomly work on things, barf out different issues into the same branch at the same time?
      - user3939382 3y ago
        Agree. We for example do one branch per bug or new feature. You open a draft PR on GH, review it, then when you think it’s ready open a review and someone else can take a look at the whole branch. The commits serve an auxiliary role in that workflow. I think some people assume everyone uses their exact workflow.

globular-toast 3y ago

So basically `scp -r` (recursive remote copy). It's what I call "dumb version control" and I've observed many people not going beyond this with git: https://blog.gpkb.org/posts/git-is-a-version-control-system/ https://blog.gpkb.org/posts/git-is-a-version-control-system/

Thorrez 3y ago
It's better than scp because it stores the commit message and the history, and old versions are immutable.
- globular-toast 3y ago
  Well, I'm not sure what kind of commit messages would be possible other than "update" and "new version" etc. if you're committing everything each time.
  - Thorrez 3y ago
    Wouldn't it be possible to fix a bug then commit that fix?

rwmj 3y ago

This is fine for using git as a kind of offsite backup, but I hope you later rebase everything into meaningful commits with proper messages if you're going to share your work with anyone else.

loloquwowndueo 3y ago
Dunno, I’ve spent countless hours carefully grooming my git commit histories so they make sense and convey a coherent story, just to have them destroyed by some squash zealot at merge time . “Squash before merge” workflows seem to be more common these days and I have to think it’s mostly a push by people who do not know how to do interactive rebases and history rewrites.
- Aissen 3y ago
  You did the right thing, and I'm sorry this happened to you. May you only have to contribute to non-squashing projects in the future.
- tempest_ 3y ago
  I find it has more to do with people (myself included) who interact with git at a PR/MR level. If your PRs are small and you interact with git a lot using some web portal it sort of pushes you this way.
- skydhash 3y ago
  Squash before merge is fine if you have a project tracker, where you can use the issue as a discussion hub to describe your thoughts. Then you put the issue number in the squashed commit message. The PR can serve as implementation specific documentation and discussion.
  - loloquwowndueo 3y ago
    I disagree: discussion in a ticket or issue tends to be as disorganized as the random series of commits that are frowned upon in “nice commit history” workflows. It’s just sweeping the mess to another place where it can’t easily be found. But it’s okay, I gave up trying to convince people. So I’ll just disagree and commit (pun intended).
PurpleRamen 3y ago
What's the worth of a commit-message? The code, it's documentation and the associated issue-number is enough information. Or are people just not using their other tools for communicating those things?

okl 3y ago

You could solve that with a git alias as well which might be a bit more orderly as it would be defined in the git config. You can prepend the command defined for a git alias with an exclamation mark to run anything (not limited to git subcommands). Last example on this page: https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases https://git-scm.com/book/en/v2/Git-Basics-Git-Aliases

lallysingh 3y ago

git commit -am 'commit message'

Zambyte 3y ago
&& git push

nextlevelwizard 3y ago

Are you trying to tell me you actually don't review your staged changes and/or commits before you push them? Also how do you resolve conflicts? Or is this just your solo project with zero users so you dont have to worry about other people's commits or your own commit's quality?

PurpleRamen 3y ago
> Are you trying to tell me you actually don't review your staged changes and/or commits before you push them? The final review happens in the merge request-view on the forge. There is little reason for local reviewing. Especially when multiple people work on a branch. > Also how do you resolve conflicts? Editor.
- nextlevelwizard 3y ago
  So you just push shit in and make a review request and only then check if you actually had the correct things in commit(s) and have a descriptive commit message? Yikes
  - PurpleRamen 3y ago
    I get the impression that many people here seems to be very challenged to know what they actually do. Do you just randomly work on things, barf out different issues into the same branch at the same time?
    - user3939382 3y ago
      Agree. We for example do one branch per bug or new feature. You open a draft PR on GH, review it, then when you think it’s ready open a review and someone else can take a look at the whole branch. The commits serve an auxiliary role in that workflow. I think some people assume everyone uses their exact workflow.