5 ms·

Back in 2013, I was working for one of Redfin's competitors, near Redmond. We were moving the developers off VisualSourceSafe, and the DevOps expert (hired at t

Back in 2013, I was working for one of Redfin's competitors, near Redmond. We were moving the developers off VisualSourceSafe, and the DevOps expert (hired at the same time as me) was a Git pro, so we tried Git. Git lasted almost a week. The last straw was when a junior developer accidentally deleted the main line repo. We switched to TFS and never had problems like that again.

int_19h 9y ago
Why did your junior developer have sufficient permissions to delete branches in your main repo?
- stephengillie 9y ago
  Presumably because permissions were not set correctly. The poor fellow was tasked with compiling 20-year old code with a completely circular-linked library. He spent months hacking it into shape, and made great progress. But this problem continues to occur. Last year, working on an Ops team, team members started noticing their scripts were no longer present on production servers. It turns out a team member was modifying code and checking it in. The problem is that Git clobbers unchanged files, so he was unknowingly reverting changes. After years of seeing numerous professional developers and engineers continuously have team-impacting, show-stopping issues using a tool, I must assume the tool is defective in some way.
  - int_19h 9y ago
    > Presumably because permissions were not set correctly. Which, of course, is also potentially a problem with TFS, and a developer can similarly wipe out the repo if permissions allow them to. I'll grant you that it's easier to go so with Git by doing something like push -f, so it's more important to have permissions right in that case. > The problem is that Git clobbers unchanged files Except it doesn't? I'm not sure what was broken in your case, but that's definitely not normal or expected Git behavior, and I can't think of any time I've seen anything like that. About the only case I can think of where Git insists on "modifying" random files is when line endings are mismatched, and the repo is not configured properly. But even then it's not lossy.
    - stephengillie 9y ago
      > Except it doesn't? I'm not sure what was broken in your case, but that's definitely not normal or expected Git behavior, and I can't think of any time I've seen anything like that. About the only case I can think of where Git insists on "modifying" random files is when line endings are mismatched, and the repo is not configured properly. But even then it's not lossy. Git does this by design. There seems to be no concept of line-item uploads - either you have to push the whole fork or none of it. There seems to be no concept of "I haven't modified this file", and an assumption that a user will frequently be fetching and aware of the entire code base. Some tools help with this awareness, by auto-fetching frequently, so you know when others have uploaded code and you need to merge the master back into your branch. (Err diff the mainline against your development copy, so you can integrate the upstream changes into yours.) Mandatory workflows like this should be automated as part of the tool, but here they are very clearly left manual.
      - int_19h 9y ago
        If the developer is working in their own branch, as is the normal scenario with Git, then they can push that branch to their heart's content - nothing is magically changing there. They will, of course, need to merge it with the primary branch eventually - but that's the thing, you merge branches (or rebase them), you don't just replace one with the other... and it's not like the latter is easy to do accidentally. And when you merge, of course, it will only merge the diffs, so the concept of "I haven't modified this file" is inherent. If your fork has only modified the files that no-one else touched, then it doesn't really matter how old it is - it'll still be able to merge; you don't need to be frequently syncing with the main branch. If the developer is working directly in the main branch, then what you describe can happen - although even then, if someone else makes changes there, there would be a divergence, and push would simply fail, instead of overwriting those changes (unless you explicitly force it by using -f... but the whole point of having that switch is to be a safeguard against destructive operations). So I'm still confused about the exact scenario here.

int_19h 9y ago

Why did your junior developer have sufficient permissions to delete branches in your main repo?

stephengillie 9y ago
Presumably because permissions were not set correctly. The poor fellow was tasked with compiling 20-year old code with a completely circular-linked library. He spent months hacking it into shape, and made great progress. But this problem continues to occur. Last year, working on an Ops team, team members started noticing their scripts were no longer present on production servers. It turns out a team member was modifying code and checking it in. The problem is that Git clobbers unchanged files, so he was unknowingly reverting changes. After years of seeing numerous professional developers and engineers continuously have team-impacting, show-stopping issues using a tool, I must assume the tool is defective in some way.
- int_19h 9y ago
  > Presumably because permissions were not set correctly. Which, of course, is also potentially a problem with TFS, and a developer can similarly wipe out the repo if permissions allow them to. I'll grant you that it's easier to go so with Git by doing something like push -f, so it's more important to have permissions right in that case. > The problem is that Git clobbers unchanged files Except it doesn't? I'm not sure what was broken in your case, but that's definitely not normal or expected Git behavior, and I can't think of any time I've seen anything like that. About the only case I can think of where Git insists on "modifying" random files is when line endings are mismatched, and the repo is not configured properly. But even then it's not lossy.
  - stephengillie 9y ago
    > Except it doesn't? I'm not sure what was broken in your case, but that's definitely not normal or expected Git behavior, and I can't think of any time I've seen anything like that. About the only case I can think of where Git insists on "modifying" random files is when line endings are mismatched, and the repo is not configured properly. But even then it's not lossy. Git does this by design. There seems to be no concept of line-item uploads - either you have to push the whole fork or none of it. There seems to be no concept of "I haven't modified this file", and an assumption that a user will frequently be fetching and aware of the entire code base. Some tools help with this awareness, by auto-fetching frequently, so you know when others have uploaded code and you need to merge the master back into your branch. (Err diff the mainline against your development copy, so you can integrate the upstream changes into yours.) Mandatory workflows like this should be automated as part of the tool, but here they are very clearly left manual.
    - int_19h 9y ago
      If the developer is working in their own branch, as is the normal scenario with Git, then they can push that branch to their heart's content - nothing is magically changing there. They will, of course, need to merge it with the primary branch eventually - but that's the thing, you merge branches (or rebase them), you don't just replace one with the other... and it's not like the latter is easy to do accidentally. And when you merge, of course, it will only merge the diffs, so the concept of "I haven't modified this file" is inherent. If your fork has only modified the files that no-one else touched, then it doesn't really matter how old it is - it'll still be able to merge; you don't need to be frequently syncing with the main branch. If the developer is working directly in the main branch, then what you describe can happen - although even then, if someone else makes changes there, there would be a divergence, and push would simply fail, instead of overwriting those changes (unless you explicitly force it by using -f... but the whole point of having that switch is to be a safeguard against destructive operations). So I'm still confused about the exact scenario here.