6 ms·

I am not a git expert or anything, but I have helped resolve weird git issues for my teammates usually using a lot of Google and StackOverflow. I just know 5 b

I am not a git expert or anything, but I have helped resolve weird git issues for my teammates usually using a lot of Google and StackOverflow. I just know 5 basic commands; pull, push, commit, branch, and merge. Never ran into any issues. People who run into issues are usually editing git log or doing something fancy with “advanced” commands. I have a feeling that these people get into trouble with git cause they issue commands without really knowing what those commands do or even what they want to achieve.

flatline 9y ago
Start working in a repo with submodules and you suddenly have to understand a lot more and can get into trouble with no idea how you did it.
- relics443 9y ago
  I'm comfortable with most advanced git stuff. I don't touch submodules.
  - _pmf_ 9y ago
    > I don't touch submodules. What's the alternative? Managing all dependencies by an external dependency manager does not exactly reduce complexity (if you're not within a closed ecosystem like Java + Maven that has a mature, de-facto standard dependency manager; npm might count, too). It's absolutely not feasible for C++ projects; all projects that do this have horrible hacks upon hacks to fetch and mangle data and usually require gratuitous "make clean"s to untangle.
    - buserror 9y ago
      I use git sub-trees. Actually I love the thing. They give you a 'linear' history, and allow you to merge/pull/push into their original tree, keeping the history (if you require it).
      - _pmf_ 9y ago
        Never heard of them (well, probably in passing); will look into is. Thanks!
    - yawaramin 9y ago
      Why isn't it feasible for C++ projects?
- lilbobbytables 9y ago
  Oh you can fuck right off with submodules!
  - greasyjon1 9y ago
    ^^^ this comment is supposed to be humor, not douchebaggery, by the way. Easy on the downvotes.
- xxpor 9y ago
  I use submodules every day, never had a problem with them. What do people complain about when it comes to them? My mental model is basically that they're separate repos, and the main repo has a pointer to a commit in the submodule. Do your work that needs to be done for the submodule, push your changes, and then check out that new commit. Make a commit in the main repo to officially bump the submodule to that new commit. Done. The annoying part is when you do a pull on the main repo, you have to remember to run git submodule update --recursive.
  - flatline 9y ago
    Right, it’s not that hard, but there are some gotchas. The most common problem I see is the local submodule being out of sync with the remote superproject. Pushes across submodules are not atomic. Accidentally working from a detached head then trying to switch to a long out of date branch can be an issue, as can keeping multiple submodules synced to the head on the same branch. Recursive submodules are, as you mentioned, even more fun.
    - AstralStorm 9y ago
      The same problem appears in any non monolithic project. In any SCM I know of. Git subrepo or subtree are some of a solution but not quite complete and easy to use. In some other scms (P4 and SVN, partly hg) the answer is don't do that, which had a whole lot of its own problems.
  - chris_wot 9y ago
    Oh, so that's what you do!
    - xxpor 9y ago
      Heh, I probably made it sound more complicated than it really is. Just think of it as a pointer that needs to be manually updated.
  - friend-monoid 9y ago
    Because you have the .gitmodules file, the .git/config file, the index, and .git/modules directory, each of which can get out of sync with the others. If, for example, you add a submodule with the wrong url, then want to change the url, then you instinctively change .gitmodules. But that won't work, and it won't even nearly work. If you add a submodule, then remove it, but not from all of those places, and try to add the submodule again (say, to a different path), then you also get wierd errors. If you add a submodule and want to move it to another directory then just no. Oh and also one time a colleague ran into problems because he had added the repo to the index directly - with git add .. Oh and let's talk about tracking submodule branches and how you can mess that up by entering the submodule directories and running commands...
whym 9y ago
EDIT: I guess I misread it. On reflection what I wrote really doesn't make sense so let me retract.
- jhall1468 9y ago
  `cherry-pick` is just plucking a single commit and adding it the commit history of the current branch, and `rebase` is what civilized people use when they don't want merge commits plaguing their entire code base.
  - YZF 9y ago
    merge is what civilized people who care about getting history and context in their repository use ;) ... I worked a lot in git using both rebase and merge workflows and I'll be darned if I understand the fear of the merge commit ... If work happened in parallel, which it often does, we have a way of capturing that so we can see things in a logical order ...
    - jsjohnst 9y ago
      > merge is a what civilized people who care about getting history and context in their repository use > I'll be darned if I understand the fear of the merge commit I apologize in advance for not adding much substance in this reply, but I agree too much to just upvote alone.
    - sameerds 9y ago
      It's not really a fear of the merge commit. In a massively collaborative project, almost everything is happening in parallel, and most of that history is not important. The merge makes sense when there is an "official" branch in the project, with a separate effort spent on it. It's likely that people working on that branch rebase within the branch when collaborating, and then merge the branch as a whole when it is ready to join the mainstream.
    - salt-licker 9y ago
      Sometimes I want to take a subset of the commits out of a coworker's merge on staging to push to production, and then put all non-pushed commits on top of the production branch to form a new staging branch. I find having a linear history with no merges helpful for reasoning about conflict resolution during this process. What advantages do merged timelines give in this context?
nurettin 9y ago
I never had any problems the past 6 years I've been using Git professionally. But then someone asked me what to do when Git prevents you from changing branches and not knowing they did not stage, I told them to stash or commit. They stashed and the changes were gone. My point is, while your basic commands do the work, your habits and knowledge keep you from losing code like this without you knowing.
- bonzini 9y ago
  Why were the changes gone? Why couldn't they "git stash pop"?
  - nurettin 9y ago
    Unstaged or untracked changes were gone. They couldn't get those back after pop. I can't remember which.
    - amalag 9y ago
      Untracked files are not stashed, that is true.
      - bonzini 9y ago
        They're also not deleted by "git stash" though.
- mrweasel 9y ago
  I do like Git, most of the time, but really, not a single problem, in six years? When using Git daily we never really did anything complicated, just a few feature branches per developer, commit, push, pull-request, merge. Basic stuff. We had Git crap out all the time. Never something that couldn't be fixed, but sometimes the fix was: copy your changes somewhere else, nuke your local repo, clone, copy changes in and then commit an continue as normal.
  - 9y ago
Ace17 9y ago
So you're not using checkout, reset, and diff?
- e12e 9y ago
  Or fetch?
  - OJFord 9y ago
    I think a lot of people ignore fetch and only ever pull.
    - TomK32 9y ago
      But you'd have to stash before pull. At least with my config where a pull will rebase automatically.
      - OJFord 9y ago
        I use `git config pull.rebase true` too, but that doesn't mean you _have_ to stash first, just as rebase manually wouldn't - depends if there's a conflict. Same is true of merge-based pull.
      - e12e 9y ago
        Except for saving some typing, is there any benefit to stash over local branches? In other words, shouldn't git just fix ux for branches and rip out stash?
        OJFord 8y ago
        So "some typing" would be: # git stash: prev_ref="$(git rev-parse --abbrev-ref HEAD)" git checkout -b wip-stash git add . git commit -m 'wip stuff' git checkout "$prev_ref" # git stash pop: git checkout wip-stash -- . git checkout -D wip-stash It's quite a considerable saving. I suppose by "fix UX" you mean make it so the saving would be less anyway, but I think really they're just conceptually different: - branch: pointer to a line of history, i.e. a commit and inherently its ancestors - stash: a single commit-like dump of patches If stashing disappeared from git tomorrow, I think I'd use orphan commits rather than branches to replace it.
johnx123-up 9y ago
Just curious... are you working in a team using git workflow?
- amerkhalid 9y ago
  Yes, my direct team is small of 4 devs but the main repo we work on is used by 100+ devs. We use git workflow (new branch for each feature) for the main repo and github style workflow (clone and then submit PR) for some other repos.

flatline 9y ago

Start working in a repo with submodules and you suddenly have to understand a lot more and can get into trouble with no idea how you did it.

relics443 9y ago
I'm comfortable with most advanced git stuff. I don't touch submodules.
- _pmf_ 9y ago
  > I don't touch submodules. What's the alternative? Managing all dependencies by an external dependency manager does not exactly reduce complexity (if you're not within a closed ecosystem like Java + Maven that has a mature, de-facto standard dependency manager; npm might count, too). It's absolutely not feasible for C++ projects; all projects that do this have horrible hacks upon hacks to fetch and mangle data and usually require gratuitous "make clean"s to untangle.
  - buserror 9y ago
    I use git sub-trees. Actually I love the thing. They give you a 'linear' history, and allow you to merge/pull/push into their original tree, keeping the history (if you require it).
    - _pmf_ 9y ago
      Never heard of them (well, probably in passing); will look into is. Thanks!
  - yawaramin 9y ago
    Why isn't it feasible for C++ projects?
lilbobbytables 9y ago
Oh you can fuck right off with submodules!
- greasyjon1 9y ago
  ^^^ this comment is supposed to be humor, not douchebaggery, by the way. Easy on the downvotes.
xxpor 9y ago
I use submodules every day, never had a problem with them. What do people complain about when it comes to them? My mental model is basically that they're separate repos, and the main repo has a pointer to a commit in the submodule. Do your work that needs to be done for the submodule, push your changes, and then check out that new commit. Make a commit in the main repo to officially bump the submodule to that new commit. Done. The annoying part is when you do a pull on the main repo, you have to remember to run git submodule update --recursive.
- flatline 9y ago
  Right, it’s not that hard, but there are some gotchas. The most common problem I see is the local submodule being out of sync with the remote superproject. Pushes across submodules are not atomic. Accidentally working from a detached head then trying to switch to a long out of date branch can be an issue, as can keeping multiple submodules synced to the head on the same branch. Recursive submodules are, as you mentioned, even more fun.
  - AstralStorm 9y ago
    The same problem appears in any non monolithic project. In any SCM I know of. Git subrepo or subtree are some of a solution but not quite complete and easy to use. In some other scms (P4 and SVN, partly hg) the answer is don't do that, which had a whole lot of its own problems.
- chris_wot 9y ago
  Oh, so that's what you do!
  - xxpor 9y ago
    Heh, I probably made it sound more complicated than it really is. Just think of it as a pointer that needs to be manually updated.
- friend-monoid 9y ago
  Because you have the .gitmodules file, the .git/config file, the index, and .git/modules directory, each of which can get out of sync with the others. If, for example, you add a submodule with the wrong url, then want to change the url, then you instinctively change .gitmodules. But that won't work, and it won't even nearly work. If you add a submodule, then remove it, but not from all of those places, and try to add the submodule again (say, to a different path), then you also get wierd errors. If you add a submodule and want to move it to another directory then just no. Oh and also one time a colleague ran into problems because he had added the repo to the index directly - with git add .. Oh and let's talk about tracking submodule branches and how you can mess that up by entering the submodule directories and running commands...

whym 9y ago

EDIT: I guess I misread it. On reflection what I wrote really doesn't make sense so let me retract.

jhall1468 9y ago
`cherry-pick` is just plucking a single commit and adding it the commit history of the current branch, and `rebase` is what civilized people use when they don't want merge commits plaguing their entire code base.
- YZF 9y ago
  merge is what civilized people who care about getting history and context in their repository use ;) ... I worked a lot in git using both rebase and merge workflows and I'll be darned if I understand the fear of the merge commit ... If work happened in parallel, which it often does, we have a way of capturing that so we can see things in a logical order ...
  - jsjohnst 9y ago
    > merge is a what civilized people who care about getting history and context in their repository use > I'll be darned if I understand the fear of the merge commit I apologize in advance for not adding much substance in this reply, but I agree too much to just upvote alone.
  - sameerds 9y ago
    It's not really a fear of the merge commit. In a massively collaborative project, almost everything is happening in parallel, and most of that history is not important. The merge makes sense when there is an "official" branch in the project, with a separate effort spent on it. It's likely that people working on that branch rebase within the branch when collaborating, and then merge the branch as a whole when it is ready to join the mainstream.
  - salt-licker 9y ago
    Sometimes I want to take a subset of the commits out of a coworker's merge on staging to push to production, and then put all non-pushed commits on top of the production branch to form a new staging branch. I find having a linear history with no merges helpful for reasoning about conflict resolution during this process. What advantages do merged timelines give in this context?

nurettin 9y ago

I never had any problems the past 6 years I've been using Git professionally. But then someone asked me what to do when Git prevents you from changing branches and not knowing they did not stage, I told them to stash or commit. They stashed and the changes were gone. My point is, while your basic commands do the work, your habits and knowledge keep you from losing code like this without you knowing.

bonzini 9y ago
Why were the changes gone? Why couldn't they "git stash pop"?
- nurettin 9y ago
  Unstaged or untracked changes were gone. They couldn't get those back after pop. I can't remember which.
  - amalag 9y ago
    Untracked files are not stashed, that is true.
    - bonzini 9y ago
      They're also not deleted by "git stash" though.
mrweasel 9y ago
I do like Git, most of the time, but really, not a single problem, in six years? When using Git daily we never really did anything complicated, just a few feature branches per developer, commit, push, pull-request, merge. Basic stuff. We had Git crap out all the time. Never something that couldn't be fixed, but sometimes the fix was: copy your changes somewhere else, nuke your local repo, clone, copy changes in and then commit an continue as normal.
- 9y ago

Ace17 9y ago

So you're not using checkout, reset, and diff?

e12e 9y ago
Or fetch?
- OJFord 9y ago
  I think a lot of people ignore fetch and only ever pull.
  - TomK32 9y ago
    But you'd have to stash before pull. At least with my config where a pull will rebase automatically.
    - OJFord 9y ago
      I use `git config pull.rebase true` too, but that doesn't mean you _have_ to stash first, just as rebase manually wouldn't - depends if there's a conflict. Same is true of merge-based pull.
    - e12e 9y ago
      Except for saving some typing, is there any benefit to stash over local branches? In other words, shouldn't git just fix ux for branches and rip out stash?
      - OJFord 8y ago
        So "some typing" would be: # git stash: prev_ref="$(git rev-parse --abbrev-ref HEAD)" git checkout -b wip-stash git add . git commit -m 'wip stuff' git checkout "$prev_ref" # git stash pop: git checkout wip-stash -- . git checkout -D wip-stash It's quite a considerable saving. I suppose by "fix UX" you mean make it so the saving would be less anyway, but I think really they're just conceptually different: - branch: pointer to a line of history, i.e. a commit and inherently its ancestors - stash: a single commit-like dump of patches If stashing disappeared from git tomorrow, I think I'd use orphan commits rather than branches to replace it.

johnx123-up 9y ago

Just curious... are you working in a team using git workflow?

amerkhalid 9y ago
Yes, my direct team is small of 4 devs but the main repo we work on is used by 100+ devs. We use git workflow (new branch for each feature) for the main repo and github style workflow (clone and then submit PR) for some other repos.