Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mercurial developer responds to "Switch to git?"

groups.google.com

Post reply on HN
Print view View original

131–140 of 201 posts

Re: Mercurial developer responds to "Switch to git?"

#131

Post by willvarfar »

TylerE wrote: post #97
rocky1138 wrote: post #82

Earlier quoted context omitted.

You can actually get back files that you rm. I've seen it done. Apparently it has something to do with unmounting the drive, restarting in single-user mode, then finding/knowing where it is on the drive before the OS overwrites it (hence the unmount).

Doesn't generally work with modern FS's that use more "clever" allocation schemes.

Yeah there's not a lot of tooling for it. I recall writing my own to analyse a disk image to find traces of an intrusion, so its possible if you put in the leg work even for modern complex FS that do stuff like store small files inline in inodes.

Re: Mercurial developer responds to "Switch to git?"

#132

Post by __david__ »

sampo wrote: post #44
jlgreco wrote: post #32

Earlier quoted context omitted.

To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Of course --hard is not on by default so... there is no issue here with git's default behaviour. > "Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex." Yup, exactly. The simplicity of git's model is hugely important. It allows me to…

> To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Every version control system has a way to overwrite a dirty (modified) work directory, so git is hardly any more dangerous than any other tool. It also won't help you get back uncommitted files that you destroy with `rm`. No other tool does, either.

> No other tool does, either.

Darcs does: if you "darcs revert" to erase your local unrecorded changes you can actually "darcs unrevert" and get them back later. I guess it's a little like "git stash" but not quite, as you can only have 1 saved state and many darcs operations will nuke the unrevert save (loudly and with prompts, so it won't catch you off guard).

Re: Mercurial developer responds to "Switch to git?"

#133

Post by dingaling »

elwin wrote: post #84
ggchappell wrote: post #33

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

DVCS is a relatively new technology. We're still figuring out the best ways of designing and using it. To continue your filesystem analogy, filesystems were invented sometime around 1960, but it was over 20 years before everyone settled on Unix-style filesystems, where files are just a sequence of bytes. Eventually, they realized implementing version control or record structures at the filesystem level was unnecessar…

> Eventually, they realized implementing version control or record structures at the filesystem level was unnecessary.

I wouldn't say 'unnecessary'; it's more the case that the quick and dirty Unix and DOS solutions 'won' by deign of being easy for implementers & users.

And ever since then we've been hacking-on the features that were lost because of this.

Two features we lost:

1. Generational data groups, as on MVS. The OS automatically keeping a history of changes to the 'file'

2. Addressing any file as an RDBMS table, as on OS/400. Amazingly flexible.

Re: Mercurial developer responds to "Switch to git?"

#134

Post by _pmf_ »

ams6110 wrote: post #55
ggchappell wrote: post #33

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

Articles like this make me wonder if I'm stupid. 95% of the time all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg. I just hardly ever find myself needing to understand anything more complicated than that. Why does it seem like everyone else has spent thousands of hours understanding esoteric git or hg incantations that I've never encountered the need for.

Having to maintain several legacy branches and several feature branches comes to mind. Is this possible to do with SVN? Absolutely. Is it a fucking waste of time and energy to do with SVN? Absolutely.

Re: Mercurial developer responds to "Switch to git?"

#135

Post by gbog »

ams6110 wrote: post #55
ggchappell wrote: post #33

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

Articles like this make me wonder if I'm stupid. 95% of the time all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg. I just hardly ever find myself needing to understand anything more complicated than that. Why does it seem like everyone else has spent thousands of hours understanding esoteric git or hg incantations that I've never encountered the need for.

Maybe you could let git influence and hopefully improve the way you work.

For instance, when refactoring something quite complex with good test coverage, you want each commit to be the smallest atomic commit that can pass all tests. But you also want to very quickly and "carelessly" add debug logs, assertions, changes in many files. For this kind of task I have found the following workflow to be very helpful and fast:

1. edit files relentlessly running a few tests cases

2. when you feel you "got" something run full test suite

3. if 2. pass, use `git add -p` to add the smallest changeset doing the thing.

4. Use `git stash --keep-index` to remove all other changes

5. Run full test suite

6. If 5. fails `git add -p` to continue editing your commit, or `git reset` if too far off

7. If 5. pass, `git commit` and `git reset --hard`.

Edit: When using `git add -p` you can even use 'e' command to manually edit your patch.

Re: Mercurial developer responds to "Switch to git?"

#136

Post by qznc »

dingaling wrote: post #133
elwin wrote: post #84

Earlier quoted context omitted.

DVCS is a relatively new technology. We're still figuring out the best ways of designing and using it. To continue your filesystem analogy, filesystems were invented sometime around 1960, but it was over 20 years before everyone settled on Unix-style filesystems, where files are just a sequence of bytes. Eventually, they realized implementing version control or record structures at the filesystem level was unnecessar…

> Eventually, they realized implementing version control or record structures at the filesystem level was unnecessary. I wouldn't say 'unnecessary'; it's more the case that the quick and dirty Unix and DOS solutions 'won' by deign of being easy for implementers & users. And ever since then we've been hacking-on the features that were lost because of this. Two features we lost: 1. Generational data groups, as on MVS.…

1. is addressed by svn,git,etc and 2. is addressed by SQLite,BerkeleyDB,etc. The advantage of the user-space solution is that they are portable across OS boundaries, version management is independent of OS, and more diversity. How is it an advantage to put this stuff into the OS?

("in the OS" probably always means "in the kernel" in this context, not "in system user-space libraries")

Re: Mercurial developer responds to "Switch to git?"

#137

Post by qznc »

ggchappell wrote: post #33

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

Software development with more than one person is inherently a distributed system. People work on outdated versions and in parallel and conflicts arise. Development requires branching and merging.

It is probably impossible to package this complexity into an easy UI. I like git, because it has a simple core model, but the UI could certainly be easier. Mercurials model is not so simple (e.g. multiple types of branches and commits), but the UI is easier. Subversions UI is even easier, but the model is so simple that some things are impossible (the distributed stuff).

(can we assume on HN that people have understood "simple != easy"?)

Re: Mercurial developer responds to "Switch to git?"

#138

Post by sampo »

natrius wrote: post #96
kasey_junk wrote: post #63

Earlier quoted context omitted.

Just curious, what about Git's branches and history management is better than Mercurials with the appropriate plugins turned on? I've been able to successfully replicate all the Git use cases I can think of in Mercurial even if I think they are bad practices. Conversely, nothing I do makes git's cli anywhere near as good as hg. For me, that is the single biggest glaring problem with Git. I spend a very small minority…

To use bookmarks, I have to convince the whole team to use bookmarks. Why not convince them to switch to git instead? I use Mercurial plugins to give me commands that make my life better, like `pull --rebase`, `shelve` and `strip`, but getting coworkers on the bandwagon requires explaining which extensions to install instead of pointing to the man page for the appropriate command. My git workflow is probably replicab…

> which extensions to install

I don't think you need to install those extensions, you just enable them by putting a line in .hgrc

Re: Mercurial developer responds to "Switch to git?"

#139

Post by qznc »

ggchappell wrote: post #52
gkoberger wrote: post #40

Earlier quoted context omitted.

Taking your logic a bit further: the final product is what we (should be) interested in. Python or C++ or LaTeX or whatever are just to help us make it. Everything else, whether it be Python or git or C++ or Mecurial or vim or Windows or an ergonomical mouse, is just there to help us make the final product in an easy and quality manner. I don't see a problem with worrying about git any more than I see one with worryi…

That's an interesting point. Here are my off-the-top-of-my-head thoughts: I guess the real goal is proper separation of responsibilities. When I cook a meal, I use devices that run on electricity. I want to be able to power them up by plugging them in without thinking much about it. The people who work at my power company need to think about the intricacies of generating and transmitting electricity, but I don't want…

In larger teams you can assign merging and conflict resolution to specialists. For example, Linus Torvalds does pretty much exactly this special role (merging stuff from separate departments) all day long and git is excellent at this.

The interesting question is, how much can you automate? Git is the "very little" department, because Linus prefers a deterministic and simple process to an easy, but less reliable one.

Re: Mercurial developer responds to "Switch to git?"

#140

Post by qznc »

kasey_junk wrote: post #63
natrius wrote: post #58

Earlier quoted context omitted.

Code is read more than it is written. Version control systems provide tools to make it simpler to read code and understand why it was written. Version control systems also define how you branch and merge, which are are hugely important concerns if you're working on a team, and still pretty important if you're working alone. Git handles branches and history management better than Mercurial does for my needs, and it ma…

Just curious, what about Git's branches and history management is better than Mercurials with the appropriate plugins turned on? I've been able to successfully replicate all the Git use cases I can think of in Mercurial even if I think they are bad practices. Conversely, nothing I do makes git's cli anywhere near as good as hg. For me, that is the single biggest glaring problem with Git. I spend a very small minority…

The reverse question is, what about Mercurials UI is better than gits with the appropriate aliases and wrapper scripts?

In both cases the answer is pretty much nothing.

Git is not optimized for the minority case, it is optimized for simple implementation. It basically leaks implementation details left and right. I believe git users come to like this, because the core model is so simple (for a computer scientist). Git internally is just snapshots of the code connected with prev-version edges forming a directed acyclic graph and then some named pointers into this DAG.

Post reply on HN