A Git catastrophe cleaned up
blog.plover.com
blog.plover.com
>I think I've written before that this profusion of solutions is the sign of a well-designed system. The tools and concepts are powerful, and can be combined in many ways to solve many problems that the designers didn't foresee.
I disagree. I consider this to be a failure of Git. The set of different options (normal merge, rebase, filter-branch, etc) is complex and not cleanly orthogonal which makes for a very messy "mental model". Even experienced experts would have difficulty finding the clear, simple way to solve this problem and those less experienced would have little chance of proceeding cleanly.
I really wish some tool other than Git had "won" the version-control race; I honestly believe Git to be the worst of the contenders in the most recent generation of version control systems (albeit better than the previous generation in important ways).
Git fails often for the "basic" use cases. I won't lie. The number of options is intimidating for a beginner and one can easily get themselves into trouble. This is why there are Git guides and tutorials and UIs and they are all ultimately unsatisfying when you're a beginner.
However the use case discussed in this article is NOT a beginner use case. It is an advanced case and the fact that Git is an advanced tool that supports it (both natively with git-filter-branch, as the author found out, and ad-hoc-ly as was their original plan is a testament to the power of the system.
Tell me how you would better achieve the requirements that were the premise for this article in a different VCS?
I would argue the author probably could have even used SVN (not that I would recommend that at all) given he did some pretty manual scripting stuff (looping through commit ids etc).
Of course it his hard for me to tell with out seeing his exact repository (files).
"a hundred other programmers had copies of them." isn't a problem/cannot happen with svn because svn uses a single master repository. Fix it, and everybody can fetch it.
That leaves the "going back in time" step. That isn't easy with svn. If you have a backup of your repository, you can create patches for the commits made after it, restore from backup, and replay those you want to keep.
If you don't have a backup, the svn administrator can use svnadmin to dump and restore revisions and remove them (http://superuser.com/a/315138). I think that will be a lengthy operation if your repository has lots of history. It also requires free space to create a copy of your reporpsitory. Disclaimer: I have never used this tool.
Maybe I'm just too young to have a good perspective on this (due to only becoming a developer after git was fairly well established), but I thought that version control itself is supposed to be your backup
(Decentralized version control is only slightly different; if you lose the 'main' repository and don't have an exact clone (aka a backup), you may be able to glue together something from other repositories that is close to or equal to what you had, but there is no way to know for sure)
its rare, but sometimes a repository can get damaged beyond repair. keeping it inside of a cloud storage directory like google drive, dropbox or similar makes it prone for fatal errors.
in such a scenario a backup of the full repository is required. in gits case, remote sources can fill the 'backup' role pretty easily, as everything gets pushed to a remote server. this is obviously not enough safety if you're a bigger enterprise, they'll need additional safety guards/backups, but its sufficient for most people.
It is, if you're going to simplify it so far as to avoid the problemspace by nomenclature. It's just transforming nonlinear events into a linear sequence! I guess multithreading is also a fundamentally simple concept, in that vein.
I know abstraction is out of fashion these days, but it may have helped a little in organizing things. Abstraction, when used properly, can almost always make complicated things more simple.
Basically, if a regular person had created Git, and not a demigod, would it even have become what it is?
as a user, I'll take premature optimizations over slow as balls any day.
But, wtf do I know, I'm just some regular person.
> without losing the commit history and messages
Otherwise a "partial checkin" (which was exactly what "co-worker X" did) would have worked fine.
For instance, in this case, as mentioned below, the author of the article should have just reverted the commit where he checked out the files, then done a normal merge. If you're thinking of everything at the commit level, it's pretty much the obvious thing to do. The first obvious thought is to just backtrack (as mentioned in the article), then once you realize that's off the table (since the code is out in the wild) the very next obvious idea is to revert. Revert is what you do when you can't just undo. It's not even as if his commit involved any merges, so the revert is super easy.
I guess I just don't agree that experts would have a hard time finding the simple solution - it was the first thought that popped into my head, and I read the article mostly looking for the explanation for why he didn't just do it.
While git does provide near complete control, you almost never need to use more than the basics, and it doesn't have to be confusing.
EDIT: Just to make very clear why I think the solution is obvious, the first thought that I think will occur to almost anyone is, "if I can just bring the master branch back to its prior state, then I can merge like usual". The beauty of git is if you can form a coherent idea like "bring the master branch back to its prior state" then you can probably do it, and it probably isn't hard. The mistake the author made was to have that thought, and then instead go off down a rabbit hole, and throw out the original simple idea.
Woah that's a real messy one. I hope everyone walks away with a feeling that merging 400 commits in what sounds like a CD env is asking for trouble...
I'm probably not going to earn extra ninja points here, but in that situation I'd have turned off the deploy jenkins job, force pushed master back to sanity, squashed these commits into a sensible amount in a new branch, rebased it from master and gotten someone (several someones) to go over the pull rq which should be able to merge without conflict. (Fix conflicts in branch!)
Maybe you'll have to get your devs to make a new branch locally and cherry pick their stuff back in, but urgh; I think the solution in the article would have taken me ages to RTFM enough to work it out...
The lesson here is merge less, more often, or pay more attention when doing evil things like this should you get into that kind of situ...
I do agree though that my first step would have been merge from master to the topic, or rebase the topic onto master.
Presumably if you're merging a bunch of other changes in anyway, you're going to need to do a bunch of testing in any case, that's just an inevitable result of splitting the deployment into two phases.
In most real situations you'll probably find that only a small number of commits actually need to be reverted and reapplied, especially if your team is good about having reasonably self-contained commits.
If you're concerned about filling the git logs up with noise, you can always do use rebase to combine any revert/re-revert commits into single log entries.
All of those commands you just listed are clearly defined and serve different purposes. In other cases, most commands or command flags simply help the user do something in an automated fashion that you could do by typing each specific command out (i.e., git pull --rebase). Git's core tooling is mainly centered around graph manipulation, everything else has been added due to convenience. And quite frankly I've never really understood the criticism people levy at git for being "complicated."
It's stupidly simple at the end of the day, especially compared to the hodgepodge of features that other VC's provide, all of which don't really work together and are designed to cover some gap in what should be handled in the core design of the VC (I'm looking at you, Mercurial branches and bookmarks). All tools require you to be familiar with them. There's no getting around that.
> Even experienced experts would have difficulty finding the clear, simple way to solve this problem
I'm not sure how you can possibly say that, the answer is pretty obvious to a lot of us reading this article. This just feels like baseless whining.
There is a litany of literature out there that could have easily pointed the author to a well defined, accepted, and documented solution.
That reminds me a joke. On a particularly convoluted math lecture the professor writes on the whiteboard and explains at the same time: "from here we can state that, obviously..." He suddenly stops, slowly turns the head down, keeps mumbling "so we can obviously...". He slowly walks in the room, trying to catch the thought, then leaves the room... Some minutes pass. Then he comes back, with head up, widely open eyes and confidently continues - "Yes, this is completely obvious - so from here we can easily get the following conclusion."
Git has a lot of nice explanations. However it's either a particularly edgy case, or all those great explanations somehow fail to easily conduct those core "stupidly simple" ideas forward to actual Git beginners. At least to some of those beginners - not an insignificant number.
But, for many others, Git is a confusing mess. And, i should think, nearly everyone has heard someone(s) call Git confusing. I don't think it is up for debate that Git is known for being confusing.
Who cares if it "is" confusing or not - that's relative. Most things aren't confusing if you've learned the subject matter.. right? It is known for being confusing though, and that is clearly to people who don't know Git. Ffs, there wouldn't be debates about Git's UX every month on HN if it was so utterly non-confusing, haha.
Some things are very simple and easy to learn, use, and adopt. Git is not one of them, clearly and objectively.
Git has a fundamentally sound architecture, and with a correct mental model of what's going on you'll be able to deal with pretty much any situation. Nevertheless, you won't get beyond the simple use cases if your conceptual picture is incorrect, but that'll be the case for any VCS. I don't believe that git is necessarily superior to mercurial or take-your-pick, but let's not disregard that we're dealing with something difficult.
git checkout lets you check out files from a particular point in time. If you don't specify a path, it will check out every file. If you don't specify a point in time, it defaults to HEAD (like every git command). I fail to see what is confusing about that. You're not "reverting" changes to a file, you're just checking out a version of the file from the history.
`git checkout -b` is shorthand, and is shorthand that I personally don't use.
No, it's not!
I've been teaching SVN to Electronics Engineers, Designers and other folks who have never used version control before. It's always been very straightforward. They'd be able to use it effectively after a quick tutorial and demo, with a few notes of advice.
I've been teaching Git recently... until I gave up. It's a giant WTF clusterfuck. Git is the ultimate failure in simplicity and user experience.
Just use SVN (it works on git repo).
Yes it is. SVN is so "simple" because it doesn't have many of the features needed by large teams working on code. It's simply not fit for purpose.
> Just use SVN (it works on git repo).
Unless you need branches (and merge them), code that doesn't get silently corrupted, a proper history of all changes, the ability to work offline without connecting to a server. Y'know, the problems that git was built to solve.
I use svn to merge branches every day. I do agree that git is probably more useful for more complicated setups, but svn is very capable of branching and merging.
Has it gotten any better with conflicts? From what I heard a few years ago, it's still absolutely shocking (if two people touch the same file you can forget about merging your branch).
If you have more than 1 person doing simultaneous changes to a repository which might overlap, SVN becomes a pain to use because its merge handling is basically "Oh, there's a conflict. Here is the whole mess, good luck!" and you lose access to all the tools SVN provides for normal use.
Git (and hg) treat merges as an everyday thing, and a merge conflict does not leave you unable to do basic things such as commit or stage changes with the index, which is a huge help when resolving large conflicts.
One thing I always worried about when experimenting with commands in SVN was that I'd permanently screw up the server. With git, I was comfortable in the knowledge that as long as I didn't push, at worst I would screw up my local repository. Even better, I could just make a copy of that local repository before trying something I wasn't sure about. I haven't had to do that in a very long time, but it was nice while I was learning.
git is not the first version control I tried, but it's definitely the first that really made sense to me. Sure, there's a bunch of badly named commands to memorize, but the underlying concepts they represent are simple.
I have successfully taught it to people like CEO's and CTO's with very little difficulty.
The problem with Git is that it has 3 areas of state (working-index-repo) instead of 2 (working-repo).
That makes things HORRIBLY complicated for the 99% of useful use cases.
The underlying code of the application I'm writing would be much "simpler" if I didn't have to add all kinds of features to make it easier for the user.
Also, Git is not so much a VCS application as a framework for version control.
I had a lecturer who did this! With the only difference being he didn't leave the room, he would just stand there speechless with a poker face and then - 0.5-1 minute later - he'd say "well, this is obvious".
SUDDENLY, during the exams he expected us to explain the obvious.
For example, what does the following command do?
git checkout a/b
* Get a clean copy of the file a/b from the current branch
* Checkout the branch b from remote a
* Checkout the local branch 'a/b'
By confusing where you can use particular types of arguments, I've found students will often end up in these situations (in particular lots seem to end up with local branches called 'remote/branchname', or files called 'remote/branchname'), which tends to lead to massive confusion.
Life would be much better if git was a more direct mapping to it's underlying model, and didn't try to be so clever about guessing what users wanted.
The git documentation clearly states what happens in your scenario:
> ARGUMENT DISAMBIGUATION
> When there is only one argument given and it is not -- (e.g. "git checkout abc"), and when the argument is both a valid <tree-ish> (e.g. a branch "abc" exists) and a valid <pathspec> (e.g. a file or a directory whose name is "abc" exists), Git would usually ask you to disambiguate. Because checking out a branch is so common an operation, however, "git checkout abc" takes "abc" as a <tree-ish> in such a situation. Use git checkout -- <pathspec> if you want to checkout these paths out of the index.
See here: https://git-scm.com/docs/git-checkout#_argument_disambiguati...
If you somehow manage to purposefully name things in a confusing manner, you can tell git exactly what you want it to grab at any point in time. I don't possibly see how this is a fault of the tooling.
Obviously one can read the documentation carefully and read what's going on, but in practice most users don't. Also, to be fair to users, they often don't know what they don't know -- they aren't aware they should be reading how checkout does argument disambiguation when they start getting weird error messages.
On the other hand, if git didn't allow '/' in branch names, except are a remote/branchname seperator, then we would know what '/' meant -- in practice this is what almost everyone does in practice anyway (there may be a deeper issue here I'm not aware of).
Similarly, if git didn't have commands which could take either a <tree-ish> or a <pathspec>, say have "checkout-file" (that's an awful name, but I'm sure we can find a better one), then there would be no need to have this special bit of documentation, and describe to people how to get around the issue.
My experience of teaching is that git guessing what people want makes learning git harder, as they have to learn what are the fundamentals, and what is git being "helpful".
I also don't use most of the git commands directly, I have a bazillion of aliases that are shorter and/or more intuitive.
To be honest, there were some changes for the better in the CLI. For instance 'git push' no longer defaults to the crazy 'matching' behavior, but 'simple' instead.
I guess the problem is perhaps that most of the time, people get used to the quirks and don't report them (maybe I'm mistaken).
In fact, if git bug tracker was hosted on GitHub, I'd probably be more active in reporting and discussing things. I'm not an old school mailing list kind of guy I guess, and maybe not only me (but I believe many git maintainers would say, it's a feature that barrier of entry is not low).
I think you have a slight misunderstanding on the differences between git and mercurial, as git absolutely allows you to do this. Mercurial tends to track this information in a way where it actually limits telling you what branches a commit is contained in. Git will tell you straight up which branches lead back to a commit (i.e., being contained in them). Mercurial tends to only give you immediate, direct ancestors, any kind of complicated history and Mercurial can't be bothered to actually to dive in and tell you what branches a commit is really apart of.
That seems to be strangely counter-intuitive for "long running branches."
Git doesn't need an equivalent of Mercurial branches and bookmarks, because git branches do everything both of those mercurial features do and more, in a far more lightweight and efficient manner contained in a clean, singular feature.
Not quite everything. Since Mercurial branch names are baked into the commit, if you wanted to know which branch a commit was originally part of, you can find out.
Git does not support this. If two branches have parent commits in common, it technically belongs to both branches.
There is a valid conversation to be had on if this feature is actually necessary or makes sense in the context of a DVCS, but git branches are not a full substitute for Mercurial branches.
It belongs to both branches as well in Mercurial, it just hides that information from you. An astoundingly bad idea, no? I'm not sure how mercurial hiding information from you is a "feature" in any sense of the word.
As such, I fully expect each tool to hide some amount of information so that I don't have to think about the details.
In other words, Mercurial has feature branches, while git has developer branches. This gives much more possible workflows in case of Mercurial.
>Mercurial tends to only give you immediate, direct ancestors, any kind of complicated history and Mercurial can't be bothered to actually to dive in and tell you what branches a commit is really apart of...
http://stackoverflow.com/questions/7166011/mercurial-find-al...
Is that what you are talking about?
Mercurial contains vastly more querying capabilities in the form of revsets. No such thing exists for Git.
If you go head to head with git vs mercurial, git will loose pathetically.
It doesn't pre-bake the information in the commit, because it's entirely useless information to bake into a commit; and even in the case of Mercurial can paint the wrong picture about the nature of a commit given branches that it's on.
>This gives much more possible workflows in case of Mercurial.
That is the exact opposite of what it gives you. I'm not even sure how you possibly arrived at that conclusion.
>Mercurial contains vastly more querying capabilities in the form of revsets.
Git doesn't need a query language, because you can literally do everything revsets will give you with git log and then maybe some very elementary bash script knowledge. You are literally arguing that Mercurial having its own arbitrary DSL is somehow better than git being able to seamlessly use popular tooling with conventional command line syntax; which seems to be at odds with the whole "mercurial is easier to use." I take extreme issue with your claim that Mercurial has "vastly" more querying capabilities and then you not even give one measly example.
I have found it very useful in untangling a complex history. You might not see the value in it becuase git does not care to maintain a truthful history, but promotes building a "clean" history. It makes sense to do that if you are maintaing somethign like linux kernal. But for smaller projects, maintaining a truthful history is much more valuable.
So I would say that it is extremely valuable information in the context of Mercurial.
And there are other version control systems that follow similar model. Take a look at the '3.3 Branches' heading in another fantastic version control system called 'Fossil' here [1].
>That is the exact opposite of what it gives you. I'm not even sure how you possibly arrived at that conclusion.
Well, Mercurial supports git's branching model and a lot of others. I am not sure how that is not clear.
>Git doesn't need a query language...
Of course. It is not meant to be used by mere mortals..
>because you can literally do everything revsets will give you with git log ...
Are you seriously saying that using command line flags is more powerful and easier than using a query language that lets you use arbitrarily expressions to query a data set?
> I take extreme issue with your claim that Mercurial has "vastly" more querying capabilities and then you not even give one measly example.
Checkout the link I mentioned in my earlier comment.
This is the manual page for revsets [2]. Please take a look.
[1] http://www.fossil-scm.org/fossil/doc/trunk:2012-01-01/www/fo...
Elaborate.
>Mercurial supports git's branching model and a lot of others.
Except, it doesn't completely.
>Are you seriously saying that using command line flags is more powerful and easier than using a query language that lets you use arbitrarily expressions to query a data set?
Yes, because command line flags are ubiquitous in nearly every single tool, versus an arbitrary DSL that has no convention behind it, or can be easily parsed by other tools in the same ecosystem.
> Please take a look.
You seem to be under the impression that I have not or do not use Mercurial. You would be mistaken. Both of those pages do not lend support to your claim that the ability to "query" (with or without a DSL) the history graph is somehow superior in Mercurial. They merely document the feature, but do not draw any meaningful comparisons highlighting what it can do that git log or even git rev-list (which git log uses) can't.
For example, to answer questions like "What feature was this commit part of, originally". "How and where did the merges happened?". To answer these questions months after the merges happened, even after you did't think that you would need to answer these questions, something like the workflows mercurial is essential.
>Except, it doesn't completely.
Elaborate?
>Yes, because command line flags are ubiquitous in nearly every single tool
Ok. But that does not mean that it is powerful enough and can be a replacement for or better than a proper query laguage..
> arbitrary DSL that has no convention behind it
What convention? I am not getting you.
>can be easily parsed by other tools in the same ecosystem.
Parse what exactly?
>Both of those pages do not lend support to your claim that the ability to "query" (with or without a DSL) the history graph is somehow superior in Mercurial. They merely document the feature, but do not draw any meaningful comparisons highlighting what it can do that git log or even git rev-list (which git log uses) can't.
Oh it does support it plenty. Take a look at the vocabulary supported by revsets in form of intuitive and easy to remember predicates. I don't think you are really impartial if you are not convinced by it.
Neither system will answer that. If you're relying on branches to tell you what feature sets changes belong to, you should be adding that to your commits.
>"How and where did the merges happened?"
Git will do this faster and in a more correct manner. In a complicated history graph, Mercurial will actually hide information from you if you try to query it and sometimes even mislead you. I'm starting to think you haven't used either system extensively.
>Parse what exactly?
Arguments and output.
>Oh it does support it plenty.
It does not. If you can't give an example, you can just admit that you don't know what you're talking about.
I am not sure what you are talking about. Every change set in Mercurial contain the branch in which it was made. Even after a merge, there is a clear distinction about the commits made in a certain branch.
I think you might be thinking of rebased change sets. In that case, you would be right.
>Git will do this faster and in a more correct manner..
Please show an example. I would also like to see an instance where Mercurial hiding information from you and giving misleading answers to your queries.
>Arguments and output.
But it is supposed to be used by people. So it should be first human friendly. And there is nothing stopping you from parsing output of mercurial commands. And what is the use case of parsing arguments? Why did you think so? Mercurial has even a template feature letting you format the output in any way you want. I am not sure, it seems to me that you are not making a whole lot of sense..
>If you can't give an example, you can just admit that you don't know what you're talking about.
There are some examples at the bottom of the revset page I linked. Knock yourself out. And do share some examples of your claims, because your last commits contained enough stuff to doubt your experience..(stuff about conventions and DSLs, what was that again?)
A branch with two heads. Two branches that have the same name. Which commit came from where? What happens if that branch was merged into the other? Or what happens if only one got merged into a "mainline" branch, while the other one was reverted else where. It's useless information at best, and misleading at worse.
>But it is supposed to be used by people. So it should be first human friendly.
You're going to claim a DSL that you have to research is somehow easier to use than simple command line arguments that have decades of convention behind them? Odd.
Git allows you to format output as well. Not sure why you felt the need to bring that up. Again, unless you've extensively used both systems I'm not sure why you feel the need to argue because it's making you look foolish.
>There are some examples at the bottom of the revset page I linked.
And absolutely none of them help your argument.
It seems useless to you because you see it from a git viewpoint. It is clear when you say that "Two branches that have the same name". It is not "two branches", but one branch with two heads. In Mercurial, a Branch is a set of commits. That view is incompatible with the thing that git call "branches".
If you think about it, Mercurial's implementation of a Branch is closer to the idea of a "Branch". As I told earlier, Mercurial branches are "Feature" branches". I am not sure if you have gone through the fossil doc page I linked earlier. When you see it like that, it makes complete sense that a Branch can have any number of heads. Say, the second head containing a different implementation of the same feature.
(God I miss Mercurial)
>Which commit came from where? What happens if that branch was merged into the other? Or what happens if only one got merged into a "mainline" branch, while the other one was reverted else where. It's useless information at best, and misleading at worse.
These questions are the result of trying to make sense of Mercurial branches in a GIt way..
>what happens if only one got merged into a "mainline" branch, while the other one was reverted else where.
Again, this question is a result of you seeing mercurial branches in a git way. Because git define a branch as the set of commits starting from a "head", the idea of merging only one of the heads does not make sense to you.
But you can do the same with git, right. You can move back couple of commits from a head and create a new head by starting committing from there. Only that in git, the previous head would be hidden. And you will have to go to the reflog to dig them up. But in Mercurial, things are much clearer and exposed (contrary to your accusation of it hiding and misleading).
So again, it feels misleading to you because it is different from git. It is very consistent in conforming to its on model.
>You're going to claim a DSL that you have to research is somehow easier to use than simple command line arguments that have decades of convention behind them? Odd.
I am not at all getting you here. "command line arguments that have decades of convention"? What exactly does that mean? And what is the thing about "a DSL that you have to research"?. You don't have to look up command line arguments of git? And you call git's command line arguments simple?
>Again, unless you've extensively used both systems I'm not sure why you feel the need to argue because it's making you look foolish.
I didn't claim that git does not allow you to format the output, but just that Mercurial allows you to do that so that your argument about easily parseable output is moot.
git branch --contains <commit>I personally don't understand the use case, and prefer git's way of handling things, but I don't rule out that other people find it useful.
It can also just simplify certain things. I can tell by checking if a commit is reachable from e.g. the v1.2 bugfix branch but not from master that the commit was post the 1.2.0 release to fix a bug.
With hg branches you can just see that the commit was made the the v1.2 bugfix branch. This is very minor, but my experience with hg is that there are dozens of these minor niceties that are why a lot of hg users are still around despite git having clearly won the popularity contest.
What am I not understanding here? You definitely can go N commits in the past on each branch, and even any commit. And if you rewrite history you can even use the reflog to really tell what the branch was like (as long as it hasn't been cleaned out).
┌─────┐◀──────── master
│Merge│◀──────── bugfix
└▲───▲┘
│ │
│ │
│ ┌─┐
│ │B│
│ └▲┘
┌─┐ │
│A│ │
└▲┘ │
└───┤
│
┌────────┐
│Ancestor│
└────────┘
git cat-file -p master
You can do some basic heuristics to figure it out, but I'm not sure what the point of knowing this is.
>What did the `bugfix` branch look like one commit ago?
`git checkout bugfix; git log bugfix^1`
> And if you rewrite history you can even use the reflog to really tell what the branch was like (as long as it hasn't been cleaned out).
The reflog is not moved across remotes, is it? If I make a fresh clone of a repository, that doesn't tell me what the branch was like a year ago.
>If I make a fresh clone of a repository, that doesn't tell me what the branch was like a year ago.
This isn't true with Mercurial either. A lot can happen in a year, and it might even make the information misleading (having similar named branches, history deletion, etc). It's useless at best and misleading at worst.
I find that having a branch name that was the sole branch name when the code was made gives context to the commit; why it was made and what its purpose was. Being reachable from a branch pointer doesn't give that same context. Yes, commit messages should handle this. But I find they don't.
> It's useless at best and misleading at worst.
This has not been my experience. I haven't found a great need for "what's the whole state a year ago"; more so "what was the context around this commit", which I think a mercurial-style branch name answers.
And to make sure no one responds with some silly "just because you don't have a use for it, doesn't mean don't have their uses for it": I get what you're trying to say. I'm really just not buying it as an actual use case. If your commit message isn't sufficient enough to explain the purpose of the commit (ticket numbers, explanation, etc), it doesn't get approved. If you're relying on a <20 character branch name to give you sufficient context about a commit a year later, I simply have no words.
>which I think a mercurial-style branch name answers.
I find that extremely suspect.
I'm glad this is the case where you work and develop. I have never worked at a company where this is the case. I'm also not perfect about commit messages in my personal code. The codebase I'm currently working on has recent commits with description "review", "add addressDto" and "post rebase fix".
> >which I think a mercurial-style branch name answers.
> I find that extremely suspect.
Ok. If I see "add addressDto" as a part of the branch "google-geocoding", that tells me the context. If I see it as part of "refactor-to-use-hibernate", that also tells me something useful.
I guess what I don't get, is that if you have people doing commit messages like that, how can you possibly expect them to appropriately name a branch which most likely stores far less characters.
Just recently I had to triage a recently discovered bug whose symptoms disappeared about 4 years ago to determine if the bug was fixed or just masked. This was code that I was completely unfamiliar with because the other engineers that might have looked at it were otherwise indisposed working on things that were known for sure to be issues.
The "what" told me the specific change that masked the bug and the "why" informed me of the feature that this supported. That allowed me to generate a new test-case that showed up in the current version. Without both pieces of information I would likely have had to spend a couple of hours inspecting code changes to do the same.
Believe it or not, there were times in the last 20 years when there was insufficient review of commit messages!
Please elaborate how this helps you in long-term branches, instead of just assuming long-term branches aren't something most people deal with on a daily basis.
>you might be happy to have a tool that helps untangle the web of merges somewhat.
This has no relation to long-term branches, this happens with any kind of normal history, and even shared history between repositories (which is a far messier thing to untangle). Yet this feature is unneeded, because the information can be correctly found within git in an accurate and not misleading fashion.
If you always merge "from the right direction", you can follow the first parent line in git and reconstruct which parent is in the master branch (or in the "heavier" branch in general) and which isn't.
In more complicated situations, Mercurial named branches (commit forever carries the branch name) can be helpful. But you can get pretty far with git, too.
A tangent perhaps, but would you mind expanding on this? I use `git pull --rebase` frequently, and I'm not sure how this fits into what you described. Is it the specific command, or the automated shortcut? And what's the counterpart?
Just trying to check my mental model.
IMO this is a stumbling block for a lot of people new to Git -- for example it covers up the fact that "remote" branches are a separate reference ("master" and "origin/master" are not the same branch!).
> Incorporates changes from a remote repository into the current branch. In its default mode, git pull is shorthand for git fetch followed by git merge FETCH_HEAD.
> More precisely, git pull runs git fetch with the given parameters and calls git merge to merge the retrieved branch heads into the current branch. With --rebase, it runs git rebase instead of git merge.
http://gitolite.com/git-pull--rebase
I searched for "how does git pull --rebase work"
The described failure mode also can occur in any existing version control system --- the user is essentially did
cp -f ../mybranch/somefile-new.c somefile.c; hg commit somefile.c
The history in mybranch touching somefile.c is now partly useless, since all the patches are already applied. Of course, the branch can still be merged, if the conflicts are resolved --- the conflict resolution is then pretty much doing the above command again.
That said, I'm far from an expert in git. What do you see as it's advantages? (outside of the larger mindshare, obviously :)
I wish some well thought-out front-end to Git became hugely popular and eventually standard. I mean, including the CLI. Git even has a "plumbing mode" to interact with other programs more easily.
But doing that is hard work.
[1]: https://magit.vc/
Emacs is a somehow heavyweight frontend for a VCS, though. OTOH it can be considered a GUI client (and comes with a nice built-in editor).
For one, TortoiseHg isn't windows only. It's a python+qt based application that works uniformly pretty much everywhere.
That fact that you made that assumption makes me thing you may not have explored many alternatives. I'd recommend trying out some other VCSes, just to get a broader picture of how they function. I think doing that helps to get a grip on what your specific needs actually are, as well as a better understanding of the tradeoffs for whatever tool you pick. None of them I've seen are 100% superior.
Secondly, I love tortoisehg specifically because of the command line. Doing a simple commit with mercurial just takes `hg ci`. Doing a commit using the gui just takes `thg ci`. The latter one pops up a gui for me to stage the commit, and then I'm back in the console again.
IMO it's the best of both worlds -- I don't have to get knocked out of the commandline until I need to, and I can trigger whatever gui action explicitly, as part of my existing workflow.
There are some things which I think are just fundamentally better with a gui -- whether it's a curses-style "TUI", or proper graphics. Under tortoisehg, if I'm cherry picking for a commit, I can double click to open up a file in meld to make last-minute edits, shelve bits away for later, all kinds of one-off actions which are much more complex from the command line. Not to mention performing complex searches on VCS history.
It's a lack of an equivalently powerful cli-controlled gui for git which has kept me using hg as my primary vcs.
>For one, TortoiseHg isn't windows only. It's a python+qt based application that works uniformly pretty much everywhere.
Yeah, admitted this mistake elsewhere.
>That fact that you made that assumption makes me thing you may not have explored many alternatives. I'd recommend trying out some other VCSes, just to get a broader picture of how they function. I think doing that helps to get a grip on what your specific needs actually are, as well as a better understanding of the tradeoffs for whatever tool you pick. None of them I've seen are 100% superior.
I have used, in this order, visual source safe, TFS, SVN, Hg, git.
>Secondly, I love tortoisehg specifically because of the command line. Doing a simple commit with mercurial just takes `hg ci`. Doing a commit using the gui just takes `thg ci`. The latter one pops up a gui for me to stage the commit, and then I'm back in the console again.
Doing a simple commit with git is just git commit. What am I missing here? You could alias it to git ci if you want.
>There are some things which I think are just fundamentally better with a gui -- whether it's a curses-style "TUI", or proper graphics. Under tortoisehg, if I'm cherry picking for a commit, I can double click to open up a file in meld to make last-minute edits, shelve bits away for later, all kinds of one-off actions which are much more complex from the command line. Not to mention performing complex searches on VCS history.
These aren't more complex on the command line, they're just done differently. They aren't as intuitive as a GUI, where the button is presented to you rather than having to read about a flag in the man pages. But VCS is a tool you use all day every day, it's worth it to learn about it in depth.
> ... These aren't more complex on the command line, they're just done differently.
The process I outlined was a series of steps which were all part of what I'd consider an average commit (not necessarily "simple"). Invoking `thg ci` I could cherry pick lines, edit files as I'm reviewing the diffs, shelve away others, all within seconds, without shifting context. There isn't a single "flag" to read about which makes typing all those commands out necessarily faster.
Simple commits, I will frequently just do `hg ci` and be done. But if I'm doing a bunch of manipulation, I have click the hunks I want, commit, merge and push, all in much fewer seconds than it would be possible to type the equivalent set of commands.
I consider the overall job "tell the computer what I want, as efficiently as possible". For some specific tasks, a mouse just is a better method than a keyboard. I think it's good for complex multi-purpose tools to offer multiple UIs, allowing the user to get work done using the most efficient method tailored to their specific task at hand.
That said, I think having them based on the CLI, and using it to trigger a gui, is a far superior meta flow than having a gui trigger a cli just never seems to work out.
This architecture is the reason why projects such as libgit had to reimplement a lot of core git algorithms. https://libgit2.github.com/
Mercurial, on the other hand is more amenable for extension due to being built our of a bunch of Python modules.
CLIs are great when the space of actions you could perform is large (to nigh uncountable), but the range of subjects is small (the file paths, etc are known). Since you know the subjects, a programming language like `sh` is the most concise way to express a complex action.
GUIs are better in the exact opposite case: when you have a constrained set of actions to perform, but a large number of subjects they may be performed on. In that case, the problem isn't expressing the action, it's picking which subjects to act on (pick these lines to commit, oh except let me edit that one, put that one aside, ok back to the commit i'm staging...).
Many complex tools like VCSes contain both kinds of situations. I think sometimes a CLI is more appropriate, and sometimes a GUI is, depending on the context. IMO a fully mature VCS should make it as easy to invoke a gui for complex tasks as it is to do them from the command line.
Those examples are not only possible, but easy to do in the CLI for an advanced user. I do that sort of thing every day.
I agree that some tasks are better suited to a GUI and some are better suited to a CLI, but your VCS is firmly in the latter camp imo.
From the command prompt, invoking thg and doing that took me about 18 seconds.
I'm reasonably good on the command line, but I certainly don't see how to beat that time using just the cli. I think saying it's "easy for an advanced user" is a little loaded, but I'm still interested to know how to do that task faster. And if such a cli process could only be done with git, I'd consider switching.
For the example I gave, unless the hunks were asymetrically distributed, `git add -p` would require pressing "n" 20 times to skip through the excluded hunks (among other things), even when the user could visually see all the hunks, and know which ones they wanted. Where as gui would only require the clicks to select the "y" hunks.
I realize this is arguing a difference in the efficiency, not capability, of the UIs; but that's basically my point. The use-cases where one or the other is optimal are too closely situated together in the problem space to say one is inherently the better choice, even for VCS tasks.
While command line interaction may allow the user to receive a whole screen's worth of information at once, it forces them to interact with it in a serial fashion, regardless of whether out-of-order interaction with on-screen elements would allow them to complete the task faster.
He quickly paginated through the file and just by clicking with his mouse was able to stage and unstage hunks. He had a neat side-by-side view with two panes of text showing the current text and staged commit, if I recall correctly. The IDE instantly showed if this would result in syntax errors, and could even automatically run the project build and tests.
`git add -i` and `git add -p` can do this, but it's much more clunky and serial and modal. For example, my colleague could easily scroll up and down the files, staging and unstaging hunks as needed. He could easily see which files in his file explorer needed this processing and switch between them. This information was all displayed on the screen at the same time, contextually, and the GUI enables navigation to any point in this workflow instantaneously with a click or scroll.
I don't tend to have to do this kind of operation very much, and I'm comfortable doing them from the CLI, so I haven't bothered to set up this GUI tool. But I've seen that GUI tools for tasks like this are faster. Anything involving editing the actual text of files or diffs of them will likely be faster in a GUI.
I would say, though, that the ideal GUI for a DVCS has probably not been invented yet.
Me too.
What I found was that people do not recognize what tool git really is. People do not read the manuals and count on their world knowledge acquired from years of svn or other centralized systems. It's not the best sign, that you have to really dig git to be able to use it properly. But once you understood the core ideas, you can basically derive a lot of the workflows yourself, in a very principled and clear manner. Also: once you get a bit more familiar with the data model, one almost cannot not appreciate its beauty, I believe.
Personally I'm not going to abandon Git and all the tooling and community it comes with just for a simpler mental model, given that I have a moderately good handle on the (mainline) features of git -- and therein lies the problem. (Although note, Gitless does work on top of Git, so you should be able to use it with Github by the looks of things [2]).
I've linked Adrian Colyer's summary of the paper to make it easier to digest:
[1]: https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c... [2]: http://gitless.com/#vs
Really what I think needs improvement is better diff/merging interfaces. There really isn't platform independent one that is opensource and free.
Right now I use p4merge because it works fairly well on macOS but I still think it sucks (it doesn't have keybindings and yeah I have tried vim and emacs diff ... they are ok but not as easy to visualize diffing).
As a kernel hacker myself, I think Git's interface is superb and intuitive.
But point taken.
The cleanup after the foot-shot was pretty gory, but I'm not sure with disciplined git-flow that its possible to replicate that foot-shot, and if you can't shoot yourself in the foot then the goriness of the cleanup is a non-issue.
A third level up is you've got two devs carefully not coordinating and working together on code that closely related to each other, aside from the git-splosion that is not generally a recipe for success. Like, refactor the obviously independent multiple concepts (obviously independent because non-cooperating devs are working separately in parallel on them) in those files into multiple files and then there aren't merges to fight.
The technical discussion of git innards and workflow just get in the way of the core philosophical discussion, and the innards would fall into place if the philosophical question were answered (as if philosophical questions are ever truly answered, LOL)
A classic example of the philosophical argument is Perl vs Python. There's infinite ways to express yourself vs there is only one way that works.
Now its very politically incorrect to say you like Perl in 2016 and I suspect Git is going to be in big trouble soon enough for the same philosophical reason.
I would be interested in hearing what is the philosophical equivalent of Python for source code revision control. I mean... people can't be seriously suggesting going back to RCS/CVS/SVN/Hg, can they? Or I guess they can? Maybe some closed source silo I'm unfamiliar with? Maybe no revision control at all and go back to tgz files with dates embedded in the filename?
A classic problem with limiting opportunity, limiting the range of thoughts and ideas, is finding a way to do it without impacting productivity or quality. In that way "use something simpler and enormously less capable" would be considered cheating the philosophical problem.
Nowadays many people hate Python as well and I'm speaking as an ex-Python developer that now hates Python.
And do you know what's ironic about Python? Because the language excluded certain features, it led to multiple non-orthogonal features that solve very specific use-cases and ways of doing things in its ecosystem, with hacks upon hacks meant to implement ideas from other ecosystems, most of them slightly broken.
The problem with language simplicity is that it is misunderstood. Simplicity in the language implementation is often correlated with complexity for the developer, being what happens when you limit what can be expressed.
So if the answer to the philosophical question is two opposing camps, and we have the source code revision control solution for one pole, then all we need to do is find the opposite pole and then ask the two never to merge (oh the extended pun..) groups, to realize the other side exists and please be civil with each other, etc. That could save a lot of wasted effort.
Clearly the equivalent of methodically twisting Python into Perl one little bit at a time isn't going to make anyone on any side happy, or vice versa.
Very roughly, by cliche:
Perl, Git: "The street finds its own uses."
Python: "How can you have any pudding if you don't eat your meat?"
(With apologies to those who don't read Gibson or haven't heard Pink Floyd.)
...What's wrong with Mercurial? Or is there another Hg source control?
Personally, I started using Mercurial when I can and Git when I have to; I can't imagine someone considering Mercurial as backward even if they prefer Git.
I've yet find a workflow I prefer git to hg for.
B) I find it crazy that people are so reductionist when it comes to source control. There are tons of systems out there beyond the rcs/cvs/svn tree that have explored the space immensely. If all you are comparing to is those then clearly you'd think git was the only choice.
Allow me to disagree... Does the CVS or SVN way of doing rebase and filter-branch work with your "mental model"? Well, there is your answer.
> I really wish some tool other than Git had "won" the version-control race; I honestly believe Git to be the worst of the contenders in the most recent generation of version control systems
Not to sound harsh, but why would I want to use an inferior tool just because you don't get git?
If you want to compare, compare to darcs, mercurial, bazaar, monotone, ... plenty of choice without going back to svn (let alone cvs).
The point I was half-jokingly making was that people don't understand what an extremely powerful tool they have been given and instead complain about shallow stuff that for them is simple to grasp
edit: the way mg, bzr and the rest do the advanced stuff [when available] is basically a carbon copy of git.
I'm a pretty big fan of git, but this is an unproductive stance. I don't know much about bzr, but my impression is that darcs pioneered the ideas that became git-rebase, and elsewhere in this thread people are having substantive discussions about hg (Mercurial; I assume that's what you meant by mg) bookmarks and branches vs git branches: https://news.ycombinator.com/item?id=13229582
Surely it's a failure of source code as streams of text.
If each function was versioned with dependencies then this problem would be eliminated.
Replaced by other problems.
# try the merge; you'll get conflicts on those files
git merge topic
# discard the versions from the topic branch;
# you know you already merged those changes in
# the funny "git checkout commit", so any differences
# are due to changes on master.
git checkout --ours new-file-{1,18}
# now you are free to fix up any real conflicts
# and resolve the merge
git commit
And I missed the hundreds of devs bit apparently. My bad.
....Hundreds of devs though? On the same repo? I started sweating thinking about that one ...
so git checkout --ours {name_of_file1,name_of_file2,and_so_on}
The {} is standard bash expansion, you can try it like mkdir hello{one,two,three}, so parent poster went with articles use of new-file as the name of the files that were affected.
My name is Angela and I do research for Atlassian. I’m kicking off a round of discussions with people who use Git tools. Ideally, I’d like to talk to people that sit on a team of 3 or more. If this is you, I would love to talk to you about your experience with <using> Git tools, or just some of the pain points that are keeping you up at night when doing your jobs.
We’ll just need 30 mins of your time, and as a token of my thanks to those that participate, I’d like to offer a US$50 Amazon gift voucher.
If you’re interested, just shoot me an email with your availability over the next few weeks and we can set up a time to chat for 30 minutes. Please also include your timezone so we can schedule a suitable time (as I’m located in San Francisco). Hope to talk to you soon!
Cheers, Angela Guo aguo@atlassian.com
For the most brute force example, you could copy the whole program and make a runtime switch for deciding which to run.
Wouldn't that make merges even worse, not better?
Unless you're working on a topic branch together with another dev, but I find that rarely happens in practice.
Once my refactoring was complete I squashed it into a single commit to prepare to merge (or rebase) into master. I don't really think it's useful to keep the history of how I implemented that refactoring. Squashing it into a single commit is far easier to revert then if I merged multiple commits into master.
Everybody merge OR every rebase. The organization gotta decide on the workflow.
I'm also not a big fan of the everyone has their own branch world view, I worked on a big project (a chip design project) where we essentially lost track of what we were building because of this. I'm much more keen on requiring people to stay close to main and eating their own dogfood
Can one not instead merge master into the feature branch?
The next day, when he was ready for the rest of the changes, merge those into the feature branch.
These devs were trying to be clever, and got bit by it :)
KISS
Then rebased featurebranch on that, and thats it. So sure the history would contain the mistake, so what.
>The easiest strategy in a case like this is usually to back in time: If the problem was caused by the unorthodox checkout-add-commit, then reset master to the point before that happened and try doing it a different way. That strategy wasn't available because X had already published the master with his back-end files, and a hundred other programmers had copies of them.
So resetting the commit isn't an option, but what about reverting it? It seems like the obvious alternative to me, I'm not sure why he didn't mention it.
Reverting them seems a bit more risky to be than just rebuilding it properly -- you'll need to write some scripts to make sure you got all the commits and then the whole dev team is going to end up pushing commits which unrevert your reverts just so you can then rebase the feature branch..
Sometimes push -f is the best option ;)
I'm not saying I would have done one or the other if I was the OP -- just that I'd have no issues doing it should the situation call for it and it saved time/money at the cost of pure feelings :}
It presupposes that the commits are clean and well-separated though.
Little difference, but if "as clean as possible" was the goal, I think that would be the cleanest.
[edit] added the little words that my keyboard seems to filter out.
Apart from anything else it allows a clean-slate "this is how it _should_ have been handled in the first place", rather than a separate git-fu move that was necessary or even relevant only because of the original indiscretion.
No, just `git revert` that terrible commit, then do a regular sensible merge/rebase. Solves all problems in, like, two commands.
And the problem wasn't in checkout-add-commit, that is a trivial issue, the WTF here is producing 406 new commits in a branch without ever thinking of merging master back into it or rebasing on master, to avoid having a giant merge later.
> "What should X have done in the first place to avoid the pickle?"
0. (Of course, not develop a 406 patch changeset and then have to pick it apart. Make smaller pushes, frequently.)
1. Create a topic branch right there at the tip where the 406 changes are locally committed.
2. Then use git's interactive rebase to rewrite this branch such that just the back-end commits are picked first, followed by the front end.
3. Make a back-end topic branch from the last back-end commit and test that. If it's cool, master can be rebased to that and pushed to origin/master upstream.
4. Test remaining front-end changes, rebase master to them, push.
Also:
3. a) If back-end changes need fixing, fix them on the back-end-topic branch. Then rebase the original topic to the back end topic to pick up these changes "under" it. (I.e. replay the front end over the new back end, and install as new front end).
Probably how I'd do it, but I know it's not a popular workflow. The only project that I've seen publicly talk about expecting a changeset to rewritten from "history of fiddling around" into "series of incremental improvements to a codebase" is the linux kernel.
It's more work for every developer, and digs into more advance git operations, but it really helps keep the tree clean. Most projects don't have a velocity that requires such well-groomed changes, but this is an example of how failing that can make the history ugly and changes more difficult to work with.
For those interested why/how you'd rewrite a patch series: https://www.kernel.org/doc/html/latest/development-process/5... The 406 changes probably compress to less than 20.
By the way, this also helps with the issue this developer faced because part of the problem seems to have been that the backend and frontend changes were mixed in the same commits (hence the ugly hack for committing). Doing this kind of history-cleaning as you go makes it much easier to manipulate the order of committing changes to master.
Typically I will do a rebase pass through the commit stack to do nothing but these splits in that pass. Then when things are separated out, do another interactive rebase to do the re-ordering and squashing.
"Use filter-branch!!! Use filter-branch!!! NOOOOOOOO NOT merge union with manual deletes!!!"
But... he went and did it anyways. Honestly, reading back through commit logs, you always find the part where the driver runs off the road, plows through a clearly marked gate, runs on a train track for a mile or two, then merges back onto the main street, carrying part of a mailbox and a deer carcass.
You can fault git if you want, but it seems like some of these cases just arrive naturally no matter what cvs is used. It would be great to have a "git education" repo that contains situations just like these to work through... sort of a "drivers ed" for managing a repo.
https://www.reddit.com/r/git/comments/5i3mpz/another_git_cat...
This means you can't really have a catastrophe.
Just git reflog your way out.
I notice they are from the same publisher.
My bad. I shouldn't have used the word cherrypick there.
Otherwise it's still in reflog. Anything you ever commited is just there.
On a completely unrelated topic, extundelete is a great piece of software.
The problem is when you realise someone badly rebased, or forced a push, a while ago and now you have to try to find where the stuff was lost.
Aside from that, it'd be fun to see how mecurial handles this, but I'm not sure from reading the original post if I could exactly reproduce it.
Mercurial would let you do the checkout (revert) trick that started it all. I can imagine it causing merge conflicts as described. Mercurial does let you specify how to resolve merge conflicts for the whole merge, or you can tell it not to resolve conflicts at all and then you can run hg resolve on a file-per-file (or glob of files) basis and tell it to pick default (equivalent of master) for the files you want. I didn't quite follow the git way of doing this he described with .gitattributes, but using hg resolve sounds easier (but neither are things a non-expert user of either tool would know).
In the end some other solutions were proposed. I would not recommend using checkout (revert in mercurial) either. I don't know of a filter-branch equivalent in mercurial, but that sounds like a cool way to deal with this. In mercurial I probably would have reached for graft (equivalent of git's cherry pick), which isn't very different from git.
Well. Okay. That's a technical solution and it'd work, it's probably no less time consuming than going and fixing the code in a new branch and merging cleanly (every time I end up needing to filter branch stuff I have to RTFM on it, and it takes ages) -- this problem is NOT a technical one though; it's a process one.
Why are you landing 400 commits in one go? Half of those were on files which then start causing merge conflicts for your team and wasted a huge amount of your time?
Use feature flags, fix your conflicts in branch, don't merge anything into master unless it's using the 'merge' button on github/gitlab/gogs/whatever. And really think/discuss/roundtable about how you're introducing features because it sounds like this is running away from you a bit here..
It doesn't need to be this complex, and these kinds of messes can't really be put on the tools -- although git certainly makes it easy to set a lot of things on fire..
No, the cause of the problem was a process one, but now it's become a technical problem.
That isn't really helpful when someone has already created a git nightmare like what's described here.
Unfucking the repo, while mildly technically interesting should really be the smaller of the two lessons learned from such a mess... No?
Unless OP is asking for better processes to avoid this in the future, I think it's not a good idea to offer preventative advice as a first response. YMMV, but this sort of comment is often unwelcome (especially if you phrase the questions in an interrogative way... example - "Why are you landing 400 commits in one go? Half of those were on files which then start causing merge conflicts for your team and wasted a huge amount of your time?" comes across like you kind of enjoyed typing it and doesn't really occur as a kind stranger leaning in to help)
If your post was directed more to the readers of the thread instead of at OP, I think it would've come across less admonishing. Of course, I'm not judging you for your comment to be clear, just providing feedback on why your comment might rub people the wrong way (apologies for length).
As for coming across like I enjoyed typing it, I'm pretty much at a loss on how to respond to that one besides: NEIN!
"Days since gitastrophe" is a common phrase. There is no Perforce equivalent. You can't blow your leg off. There aren't thousands of "Perforce made easy" blog posts because it's actually easy. There are no "fixing my p4 repo" tales because it never breaks.
Thanks Perforce.
I like Perforce. It may not be perfect. But it's idiot proof.
That's because it is almost impossible to do anything, good or bad with it. ;-)
"Days since gitastrophe" is a common phrase.
Never heard it before.
There is no Perforce equivalent. You can't blow your leg off.
The equivalent of a hand saw: you will have a harder time cutting off your leg with a hand saw than with a chain saw.
There aren't thousands of "Perforce made easy" blog posts because it's actually easy. There are no "fixing my p4 repo" tales because it never breaks.
Or because nobody uses it and those who do keeps the knowledge for themselves;-)
Seriously: I used perforce for 18 months and I tried to understand why people loved it but no luck. Git isn't exactly perfect but compared to "checking out" a file before even editing it or not being able to commit without access to the server (IIRC) git is perfect. Oh, and not being able to check out a file that someone else has checked out, so if a dev goes on holiday without "checking in" the files first then you have to hack a bit to get ready for work again.
The best argument however for git is that even the perforce guys have integrated with it.
Thanks Perforce.
Also branching which hides previous history before branch out for no reason. No real branch merge functionality. Automatic merge being inferior to what Git has.
And more...
Re. Perforce made easy, I'd suggest hitting up stack overflow or the p4 forums -- the community is much smaller than git's (i.e. practically the entire open source community vs. game developers), so there are fewer people available to write such blog posts (but enough to complain, evidently). I have a number of company internal-blog posts that explain Perforce to fellow newbs, but they can't be made public due to contracts and etc.
The wrapper command-line tool was about 10,000 lines of Perl, and called 'p5'. Good times.
I've worked like that for years on some pretty big projects, and it never caused complicated problems like in the OP. The only caveat is that you need a strong safety net against breaking the trunk (lots of tests, mandatory code review, etc.)
That really seems weird. I don't think it's git's fault. Also he could have done git merge master --accept-theirs if he really wanted some kind of history but I guess it would be worthless.
Thanks for the tip re: --keep-redundant-commits!
Which is why so many developers and companies prefer it:
In nearly every thread about Git I hear vague claims that other systems are much easier, but almost never any specific reason to think so.
And sorry for the brief comment but that would be very interesting.
It is only when one wants to do advance tricks that he/she needs to enter "Git-like" land.
-_-
That's why rebase is so cool. It lets you solve each conflict during the merge of each commit separately. Then you can do it interactively and squash it all into one commit.
Learn the tools, don't complain.
Which is what they're complaining about, compared to just merging and doing it once. Sometimes resolving smaller chunks at a time can be easier, but almost as often it involves a lot of extra effort creating intermediate states for little benefit, and often they don't even make sense.
I much prefer to keep an accurate history, rather than invent one that I think looks neater (the same goes for squashing commits). And honestly I think a lot of what people object to can be mitigated by learning how to use git log properly.
Nor would anyone want me to. The re-writing history part only really applies to your local repo. If you re-write history on the remote, you are going to piss some people off.
You don't have to share it, but why not?
It might be useful in some cases, and people don't have to look at it the rest of the time. They can just look at merge commits, which are almost always coherent changes. Instead of relying on people to invent continuity, which might not even make sense.
He said that one guy was only making changes to either the front end or back end code.
They should have been two separate repos. one for the front end code and one for the back end code.
If you need to share code between repos you need to create versioned packages - in the c# world - Nuget.
In the article, the author stated that "X decided to merge and deploy just the back-end changes". To me, that suggests that perhaps the backend is an independent component entirely decoupled from the front end.
At the very least I think you should avoid making changes to multiple independently deployable parts in the same commit.