5 ms·

I feel like git culture is one of the worst about these sorts of things. I've run into people that think you're a loser if you don't use it from the command lin

I feel like git culture is one of the worst about these sorts of things. I've run into people that think you're a loser if you don't use it from the command line, but my commits using a GUI client are much cleaner and I seem to have much less trouble than they do.

quickthrower2 3y ago
I use command line for pull/push/new branch, VSCode for commits and Tortoise for archeology and merges. I just use whatever seems easiest for the task.
poorlyknit 3y ago
What GUI are you using and how do I make my commits cleaner?
- globular-toast 3y ago
  I use magit. You want a UI that allows you to easily see the changes in your worktree and add those line by line to the index, if necessary. Of course, you also want it to be easy to add whole files or hunks too, as always going line by line would be insane. A good commit means a good version. That's what we're doing after all: version control. Every commit you produce should be a valid standalone version of the software. Commits can build on each other, e.g. you can add feature a then subsequently add feature b that depends on feature a, but a maintainer should always be able to only take feature a, there shouldn't be bits of feature b in there, and there shouldn't be fixes for feature a in feature b's commit. With practice you can learn to make rough commits first then clean them up into proper commits later. For example, there are "end of day" commits and there are fixup commits. Those are both valid uses of git, but you shouldn't be exposing those to your team. You need to rebase them before sending them. A good git user will sow the seeds for a smooth rebase early.
  - Vinnl 3y ago
    For those who do prefer the command line (you do you), what you want is git add --patch
    - globular-toast 3y ago
      That's not really a CLI, though, it's a really basic rudimentary text UI. Might as well spend the effort to learn it learning enough Emacs to use Magit. Can it even do line by line effectively? What about unstaging stuff you added accidentally? It's not a patch on Magit or even any semi-decent GUI.
      - Vinnl 3y ago
        Heh fair enough. For me, it comes with the advantages of the CLI that I care about (primarily: easily accessible with the keyboard, and launching without delay) without having to adopt a different editor. I don't need line-by-line usually (but it can technically do it if needed), but undoing accidental adds is indeed a bit of a pain.
  - offices 3y ago
    The emacs user has feelings about annoying elitist cultures.
    - globular-toast 3y ago
      Eh? Emacs is the complete opposite of an elitist culture. The entire point of Emacs and free software in general is to destroy the elite (developers) and put the users (me) in control.
globular-toast 3y ago
I'm the "git guy" in every job I've had. I never use the CLI! I use magit which is probably the very best git UI there is. A GUI is simply the best thing when you are in the process of building state. CLI is great for functional type stuff (ie. I type a command providing both input and output but is completely stateless). Building commits is one such example of working with state. Most CLI users I know just add everything every time.
themadturk 3y ago
I’m a non-coder and use git for versioning text files for my fiction writing. I don’t have any sort of deep understanding of git, but I’m pretty comfortable at the command line for commits, pushes, pulls, etc. I must admit I’ve started liking the GitHub gui app lately, though.
bshacklett 3y ago
I'm certainly skeptical of folks that use Git GUIs. It has been my experience that the folks that I've worked with who only use Git from the GUI only know the absolute minimal subset of the tool to allow them to get code/changes into the CI system. As soon as something happens outside of that comfort zone, things go haywire. Adding insult to injury, many of the Git GUIs that I've seen people work with don't use "standard" terminology, or they combine/conflate multiple actions (I'm looking at you, VS Code). This makes it difficult to help when things go awry, or when someone's having difficulty understanding how to work in the team's established workflow. Ultimately, I don't care what tools people use if they produce quality work and can integrate with the team without creating additional friction. There's nothing that says that a good GUI can't exist, or even be more productive than the CLI in some cases. I have had enough experience of GUIs causing problems, however, to make me nervous when I hear one is being used by a team member. It's often followed by something like: "I ran into a problem with Git, so I just deleted the repository and cloned it again." Perhaps it's time for me to start looking at the available GUIs again, so that I can make a recommendation for a solid one when someone doesn't want to use the command line. In the end, though, one still needs to understand Git's behavior, to some degree, to be productive and avoid creating situations which take the team's focus away from our goals. I don't know that any GUI is going to help junior developers with that.

quickthrower2 3y ago

I use command line for pull/push/new branch, VSCode for commits and Tortoise for archeology and merges. I just use whatever seems easiest for the task.

poorlyknit 3y ago

What GUI are you using and how do I make my commits cleaner?

globular-toast 3y ago
I use magit. You want a UI that allows you to easily see the changes in your worktree and add those line by line to the index, if necessary. Of course, you also want it to be easy to add whole files or hunks too, as always going line by line would be insane. A good commit means a good version. That's what we're doing after all: version control. Every commit you produce should be a valid standalone version of the software. Commits can build on each other, e.g. you can add feature a then subsequently add feature b that depends on feature a, but a maintainer should always be able to only take feature a, there shouldn't be bits of feature b in there, and there shouldn't be fixes for feature a in feature b's commit. With practice you can learn to make rough commits first then clean them up into proper commits later. For example, there are "end of day" commits and there are fixup commits. Those are both valid uses of git, but you shouldn't be exposing those to your team. You need to rebase them before sending them. A good git user will sow the seeds for a smooth rebase early.
- Vinnl 3y ago
  For those who do prefer the command line (you do you), what you want is git add --patch
  - globular-toast 3y ago
    That's not really a CLI, though, it's a really basic rudimentary text UI. Might as well spend the effort to learn it learning enough Emacs to use Magit. Can it even do line by line effectively? What about unstaging stuff you added accidentally? It's not a patch on Magit or even any semi-decent GUI.
    - Vinnl 3y ago
      Heh fair enough. For me, it comes with the advantages of the CLI that I care about (primarily: easily accessible with the keyboard, and launching without delay) without having to adopt a different editor. I don't need line-by-line usually (but it can technically do it if needed), but undoing accidental adds is indeed a bit of a pain.
- offices 3y ago
  The emacs user has feelings about annoying elitist cultures.
  - globular-toast 3y ago
    Eh? Emacs is the complete opposite of an elitist culture. The entire point of Emacs and free software in general is to destroy the elite (developers) and put the users (me) in control.

globular-toast 3y ago

I'm the "git guy" in every job I've had. I never use the CLI! I use magit which is probably the very best git UI there is. A GUI is simply the best thing when you are in the process of building state. CLI is great for functional type stuff (ie. I type a command providing both input and output but is completely stateless). Building commits is one such example of working with state. Most CLI users I know just add everything every time.

themadturk 3y ago

I’m a non-coder and use git for versioning text files for my fiction writing. I don’t have any sort of deep understanding of git, but I’m pretty comfortable at the command line for commits, pushes, pulls, etc. I must admit I’ve started liking the GitHub gui app lately, though.

bshacklett 3y ago

I'm certainly skeptical of folks that use Git GUIs. It has been my experience that the folks that I've worked with who only use Git from the GUI only know the absolute minimal subset of the tool to allow them to get code/changes into the CI system. As soon as something happens outside of that comfort zone, things go haywire. Adding insult to injury, many of the Git GUIs that I've seen people work with don't use "standard" terminology, or they combine/conflate multiple actions (I'm looking at you, VS Code). This makes it difficult to help when things go awry, or when someone's having difficulty understanding how to work in the team's established workflow. Ultimately, I don't care what tools people use if they produce quality work and can integrate with the team without creating additional friction. There's nothing that says that a good GUI can't exist, or even be more productive than the CLI in some cases. I have had enough experience of GUIs causing problems, however, to make me nervous when I hear one is being used by a team member. It's often followed by something like: "I ran into a problem with Git, so I just deleted the repository and cloned it again." Perhaps it's time for me to start looking at the available GUIs again, so that I can make a recommendation for a solid one when someone doesn't want to use the command line. In the end, though, one still needs to understand Git's behavior, to some degree, to be productive and avoid creating situations which take the team's focus away from our goals. I don't know that any GUI is going to help junior developers with that.