41–50 of 118 posts
Earlier quoted context omitted.
I agree. The "alternative universes" that Git creates after rebases are hard to deal with once branches are published anywhere .
Which is why every single tutorial of rebase you can find will explain that you should never rebase branches that have already been published.
We were discussing the advantages of Mercurial having publishable rebases.
Earlier quoted context omitted.
Is history modifying rebase going away? If I accidently commit "the keys to the kingdom" how do I get them out of the history?
> Is history modifying rebase going away? In hg "rebase" just means "change the base" not "rewrite commits". So I assume you mean "rewrite" in general. With evolve, the obsolete commits stay around foreverish, but they slowly fade from history as new people clone or pull, since obsolete commits don't get pulled or pushed by default. > If I accidently commit "the keys to the kingdom" how do I get them out of the histo…
rebase doesn't mean "rewrite commits", it means "create new commits based on these ones, based of a new base". Your original commits are still there, and are pushed to the remote, but are GCed after a certain period (default 30 days?) if they are not referenced from anywhere. Since unreferenced commits are pushed to the remote, you can easily restore those commits within the GC period.
While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just c…
There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model. What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply obje…
Want to revert your changes? That's unpacking from the repo to the working dir. Want to switch to a different branch? That's also unpacking files from the repo to the working dir. The only difference is that in one case the current working branch stays the same and in one case it changes (or you could look at it as in one case you set it to the current value and in the other you set it to something different).
This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model.
Also, want to create a branch? "git branch new-branch". Delete it "git branch -d new-branch". The "checkout -b" is an optimization, just like "rm -r x" is an optimization of "find x | xargs rm" (why do two commands when you can do one?).
The only thing I don't like about git UI is that it can't decide what to call the "index". It's called "index", "staging area", and "cache" in various places (including command line flags), which is confusing.
I am so excited for Changset Evolution. The only thing I miss having from git in mercurial, is the ability to safely rewrite commit history.
I'm excited because it is SO MUCH more powerful than git's commit history rewriting, because "I re-wrote history" becomes part of your (distributed) repository's history.
For the case when you want to push out to the world… Well, that's mostly for catastrophic things—oh, no I accidentally checked in the private key! In that case I also don't want the history of that kept around.
So I don't know. I like the idea, but I'm not sure when it's applicable.
Earlier quoted context omitted.
There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model. What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply obje…
I feel that people that rail on "git checkout" don't actually understand what it does. It does two things: 1) unpacks files from the repository into the working directory, and 2) updates the current working branch. Want to revert your changes? That's unpacking from the repo to the working dir. Want to switch to a different branch? That's also unpacking files from the repo to the working dir. The only difference is th…
Making people understand the internal data structures in order to understand a UI is... not good.
Earlier quoted context omitted.
> Is history modifying rebase going away? In hg "rebase" just means "change the base" not "rewrite commits". So I assume you mean "rewrite" in general. With evolve, the obsolete commits stay around foreverish, but they slowly fade from history as new people clone or pull, since obsolete commits don't get pulled or pushed by default. > If I accidently commit "the keys to the kingdom" how do I get them out of the histo…
> In hg "rebase" just means "change the base" not "rewrite commits". So I assume you mean "rewrite" in general. rebase doesn't mean "rewrite commits", it means "create new commits based on these ones, based of a new base". Your original commits are still there, and are pushed to the remote, but are GCed after a certain period (default 30 days?) if they are not referenced from anywhere. Since unreferenced commits are…
My point is that git says "rebase" even when the underlying base of the commits affected is not changing. This is an artifact of the UI, since the command to rewrite in git is typically git rebase -i.
Earlier quoted context omitted.
I'm excited because it is SO MUCH more powerful than git's commit history rewriting, because "I re-wrote history" becomes part of your (distributed) repository's history.
I was impressed and excited when I read about that feature, but as I chewed on it for a while I realized I don't think I would ever use it. Most of my history rewriting is done locally before I've ever pushed—in that case I don't want those kept track of because they are throwaway (the same reason I don't check in a file after every single character change). For the case when you want to push out to the world… Well,…
That's just a habit you acquired because right now rewriting public history is a "problem". It shouldn't be a problem. In fact, it's something people do, e.g. how about being able to edit a pull request as it's being discussed and it being ok if that pull request gets merged as it's being discussed?
Earlier quoted context omitted.
I gave a talk about it at our local Python user group. AMA: https://www.youtube.com/watch?v=4OlDm3akbqg
Is history modifying rebase going away? If I accidently commit "the keys to the kingdom" how do I get them out of the history?
Changeset evolution puts mercurial slightly ahead of git here Now if only Atlassian's bitbucket was as popular as github!
Earlier quoted context omitted.
I feel that people that rail on "git checkout" don't actually understand what it does. It does two things: 1) unpacks files from the repository into the working directory, and 2) updates the current working branch. Want to revert your changes? That's unpacking from the repo to the working dir. Want to switch to a different branch? That's also unpacking files from the repo to the working dir. The only difference is th…
> This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model. Making people understand the internal data structures in order to understand a UI is... not good.