4 ms·

You're probably right. I, though, know just enough GIT to get by. In every case where things have gone seriously pear-shaped, it's just quicker -- like days qui

You're probably right. I, though, know just enough GIT to get by. In every case where things have gone seriously pear-shaped, it's just quicker -- like days quicker -- for me just to throw everything to the wind and clone the repo again. Reading up how to do the proper thing a recover will just take me order-of-magnitude longer, and frankly, I don't have the time. Just think how many person-hours were wasted by that team huddled around the monitor... GIT: The Swiss-Army Chainsaw of Version Management.

habitue 8y ago
Once you understand a few basic things like the underlying git model, and what the reflog is, you can basically get out of any situation. Totally worth the time to learn, it'll save you a ton of time
- bhj 8y ago
  The interface should be what saves a ton of time, and should not expose the underlying technical model (especially because that model may change at some point)
  - habitue 8y ago
    I don't think it's reasonable at this point that git's underlying model ever changes substantially. Essentially, it is the interface that's stable over time. It's also the easiest way to understand git. You could learn to read by memorizing the shapes of thousands of words without learning the alphabet or how it matches up to sounds. I'm sure people have done it. But the failure mode when encountering a new word is complete and utter bewilderment that this new shape is unfamiliar, rather than a graceful degradation you get if you understand the alphabet. The same is true of git.
    - zaphar 8y ago
      This is funny because the lack of consistency in Git's user interface forces you into memorizing the shapes of specific words (commands and arguments). To spell it's language. The UI does a remarkably good job of hiding the elegant underpinnings from you.
majewsky 8y ago
> it's just quicker -- like days quicker -- for me just to throw everything to the wind and clone the repo again In this case, I have a single suggestion for you: Give the following extra arguments to git clone. --reference /path/to/existing/clone/ --dissociate This will download objects from your existing clone rather than from the remote repository, thus saving you a great deal of bandwidth if your repo is appreciably large. Also, this operation is absolutely safe. It will only copy objects over into the new clone that are referenced in the remote repository.

habitue 8y ago

Once you understand a few basic things like the underlying git model, and what the reflog is, you can basically get out of any situation. Totally worth the time to learn, it'll save you a ton of time

bhj 8y ago
The interface should be what saves a ton of time, and should not expose the underlying technical model (especially because that model may change at some point)
- habitue 8y ago
  I don't think it's reasonable at this point that git's underlying model ever changes substantially. Essentially, it is the interface that's stable over time. It's also the easiest way to understand git. You could learn to read by memorizing the shapes of thousands of words without learning the alphabet or how it matches up to sounds. I'm sure people have done it. But the failure mode when encountering a new word is complete and utter bewilderment that this new shape is unfamiliar, rather than a graceful degradation you get if you understand the alphabet. The same is true of git.
  - zaphar 8y ago
    This is funny because the lack of consistency in Git's user interface forces you into memorizing the shapes of specific words (commands and arguments). To spell it's language. The UI does a remarkably good job of hiding the elegant underpinnings from you.

majewsky 8y ago

> it's just quicker -- like days quicker -- for me just to throw everything to the wind and clone the repo again In this case, I have a single suggestion for you: Give the following extra arguments to git clone. --reference /path/to/existing/clone/ --dissociate This will download objects from your existing clone rather than from the remote repository, thus saving you a great deal of bandwidth if your repo is appreciably large. Also, this operation is absolutely safe. It will only copy objects over into the new clone that are referenced in the remote repository.