81–90 of 111 posts
Earlier quoted context omitted.
Rebase is not dangerous. It can't be, since it only works on the local repo. It's non-fast-forward pushes that are dangerous. And they're dangerous whether anyone uses rebase or not.
Loss of un-pushed work can be an issue, which I think is the thing that makes people wary.
I have nothing to directly comment on the tutorial. Just a tangential mention regarding the tedious argument parsing boilerplate in Python, I have found Python Fire to be much more convenient: https://github.com/google/python-fire It would have shaved off another 15-20 lines from the 503 line example ;-)
docopt deserves a link in this thread: https://github.com/docopt/docopt It’s a magical idea if you haven’t seen it. You just write the help text and it automatically creates the argument parsing code.
I have an admission to make: I don't understand git. By this I mean I have a few simple commands I use (status/add/commit/push/pull) and if I try to do anything more complicated it always ends up with lots of complex error messages that I don't understand and me nuking the repository and starting again. So I think: there must be a better way. I have often thought about implementing a VCS. The idea behind one doesn't…
(dear everyone here and elsewhere recommending git incantations "but of course you have to know what you're doing": if you regularly have to take a backup of your working area before interacting with the vcs, because the interaction may do things you did not intend from which the simplest way back is to reset hard and start over, I humbly suggest that the vcs has failed in its primary purpose)
On the note of Git being difficult, I'm really curious to see if Pijul[1] ends up being easier to understand than Git. [1]: https://pijul.org
In particular, Pijul supports (and depends on) working with repository states that are, in Git terms, not fully resolved. In addition, those states are potentially very difficult to even represent as flat files (see e.g. [2]). Git is simpler in that it mandates that each commit represents a fully valid filesystem state.
That said, I still think Pijul might have a place, if it turns out that it supports superior workflows that aren't possible in Git. But the "VCS elitism" would probably become worse than it is today.
[1]: https://jneem.github.io/merging/ [2]: https://jneem.github.io/cycles/
Earlier quoted context omitted.
Loss of un-pushed work can be an issue, which I think is the thing that makes people wary.
Almost always, you can recover a bad rebase via git reflog.
Earlier quoted context omitted.
There are 2 things I dispute here: 1. I didn't say this affects branch diffing, but rather trawling through history on a single branch. 2. "self-appointed super-users [...] [who break everything]" is a strawman and borderline ad-hominem. If you follow the guidelines I put forth, there won't be any issues collaborating with others. Also, as a general note, it's actually very difficult to completely destroy information…
> I didn't say this affects branch diffing, but rather trawling through history on a single branch. Exactly. What's the point of all the "oops, a typo" or "applying code review remarks, part III" commits. Just rewrite. This is the workflow you get eg. with Gerrit.
https://github.com/andrewshadura/git-crecord/
Those familiar with Mercurial will surely notice it is, in fact, a port of a Mercurial’s interactive commit functionality, previously a separate extension called crecord.
If you find these kinds of "build your own X" articles interesting, there's a repo on Github that aggregates them, sorted in various categories: https://github.com/danistefanovic/build-your-own-x
I have an admission to make: I don't understand git. By this I mean I have a few simple commands I use (status/add/commit/push/pull) and if I try to do anything more complicated it always ends up with lots of complex error messages that I don't understand and me nuking the repository and starting again. So I think: there must be a better way. I have often thought about implementing a VCS. The idea behind one doesn't…
Yeah, I too don't really understand git. It seems that it was developed without any concern for affording a good mental model of its operation to its users, and thus it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down. I know I could build a mental model of it if I put enough time into it, but who wants to do that when there's actually useful things to do? So…
That's not git, that's the command line - the interface with no inline visualization, no discoverability and no affordances.
git is not its command line interface. I use the git CLI like I use curl: a powerful tool for occasional surgical or automated operations directly on underlying protocol. Most of the time I prefer something that better fits my workflow: for git, it's Git Extensions; for HTTP, it's Chrome.
Earlier quoted context omitted.
Yeah, I too don't really understand git. It seems that it was developed without any concern for affording a good mental model of its operation to its users, and thus it is just a complex black box you chant arcane rituals at and hope it doesn't decide to burn your world down. I know I could build a mental model of it if I put enough time into it, but who wants to do that when there's actually useful things to do? So…
Are there other VCSs that you find it easier to understand and build a mental model of?