Hot answers tagged

64

People want to avoid merge commits because it makes the log prettier. Seriously. It looks like the centralized logs they grew up with, and locally they can do all their development in a single branch. There are no benefits aside from those aesthetics, and several drawbacks in addition to those you mentioned, like making it conflict-prone to pull directly ...


46

In two words: git bisect A linear history allows you to pinpoint the actual source of a bug. An example. This is our initial code: def bar(arg=None): pass def foo(): bar() Branch 1 does some refactoring such that arg is no longer valid: def bar(): pass def foo(): bar() Branch 2 has a new feature that needs to use arg: def bar(arg=...


44

if you know what you're doing, you shouldn't (and shouldn't ever have to) re-merge a branch in the first place. (Of course it's difficult to do when you're doing something fundamentally wrong and silly!) And therein lies the source of your confusion and the whole problem in general. You say that merging branches is "fundamentally wrong and silly". Well, ...


42

I use [Abc]: Message. With Add, Mod(ify), Ref(actoring), Fix, Rem(ove) and Rea(dability) then it's easy to extract logfile. Example : Add: New function to rule the world. Mod: Add women factor in Domination.ruleTheWorld(). Ref: Extract empathy stuff to an abstract class. Fix: RUL-42 or #42 Starvation need to be initialised before Energy to avoid ...


31

I would take a look at Fossil. It is the system the developers of sqlite use, internally, apparently. It also uses sqlite, which is a good solid technology... that is nice and portable - as well as simple and reliable. It has a good, if austere user-interface (which i think behooves the nature of a productivity-oriented goal such as you describe). ((Be ...


31

"Have you ever found the 'undo' button useful? Oh, so you agree we should use a version control then?" When I started using version control the main feature I was interested in was the ability to 'undo' my mistakes and go back to a previous version. Everyone can appreciate an undo button. Granted version control can do a lot more.


26

We've been using Mercurial for about a year. While the headache you mention exists, by far, the biggest challenge to full adoption for us was getting into the DVCS mindset of local repositories (= commit often.) The old mindset of "Commit once you have polished code" can be hard to let go. You said: In the DVCS model, each developer checks in their ...


26

Disclaimer: I work for Atlassian DVCS does not discourage Continuous Integration as long as the developer pushes remotely on a regular basis to their own branch and the CI server is setup so that it builds the known active branches. Traditionally there are two problems with DVCS and CI: Uncertainty of integration state - unless the developer has been ...


22

The History is sacred, the Present is not. You can split your DVCS "tree" in two parts: The past/history which contains an accurate view of how you have reached the current state of the code. This part of the history grow over time The present which part you are currently working on to make you code evolve. This tip most part of the history have about ...


22

Personally, for your scenario, I wouldn't bother even creating a branch, unless I was working on multiple changes, each of which would need to be accepted by the core developers. Just clone their repository and work in it, then make a pull request. If I were to use a branch then I'd rather use named branches. They were designed for this exact purpose, ...


21

Please see my Stack Overflow answer for a very concrete situation where Mercurial (and Git) merges without problems and where Subversion presents you with a bogus conflict. The situation is a simple refactoring done on a branch where you rename some files. With regard to tdammers answer, then there is a number of misunderstandings there: Subversion, ...


21

It's because svn lacked the proper data structures to accurately determine the latest common ancestor of the two branches. That's not a big deal for a branch that is only merged once, but can cause a lot of erroneous merge conflicts in situations where several branches are merged multiple times. I don't follow svn very closely, but my understanding is ...


19

There is nothing too difficult about SVN merging... anymore... if you follow the right philosophy What I see in most other answers seems to come from people who haven't used SVN in a while. As someone accurately mentions: "it wasn't fixed early enough to dispel the myth". From my current experience of using SVN 1.6 to 1.8 on a legacy project I inherited ...


19

You should commit often. But @durron597! I'm a beginner programmer! I don't trust my commits! This is why you are committing on a separate branch! You can even have many branches that you're committing to for your own use, for different fits and starts and experiments and whatnot. Don't worry about big fancy commit messages. The only commit messages that ...


18

From my own experience, the following statements are all true: Git is very efficient in storing text files, and only storing these files that were changed. so when doing a comparison of SVN and Git to compare the repository sizes, they may be similar, or there may be even a small advantage for Git. This is completely wrong if you compare the size of ...


16

Gitorious is open source and you can install it on your own server using scripts provided by the Gitorious community edition (see http://www.getgitorious.com/installer). Gitorious now has support for wikis and issue tracking. There is also a Docker image available for quickly getting it running. Another option would be Gitlab which is basically a GitHub ...


16

In short, because merging is often another place for something to go wrong, and it only needs to go wrong once to make people very afraid of dealing with it again (once bitten twice shy, if you will). So, let's say we're working on an new Account Management Screen, and it turns out there is a bug discovered in the New Account workflow. OK, we take two ...


15

I don't claim to be an expert on the subject of hype cycles, but I'll offer a few observations: The hype cycle seems to be more a product of expectations and media coverage than a characteristic of technology itself. My dictionary says that hype is "extravagant or intensive publicity or promotion." It defines publicity as "the notice or attention given to ...


14

My small team switched to a DVCS a year or two ago, and the rest of my company followed suit a couple of months ago. In my experience: People using a centralized VCS still tend to hold off on commits when they are doing a large project. This isn't a problem unique to DVCSes. They'll have change sets that wait several days before doing a commit. The big ...


14

The idea is actually very nice. Contrary to common workflows, you keep the review directly in code, so technically, you don't need anything but text editor to use this workflow. The support in the IDE is nice too, especially the ability to display the list of reviews in the bottom. There are still a few drawbacks: It works fine for very small teams, but ...


12

No they shouldn't be expected to know about it. Some companies (stupidly, in my opinion) don't use version control. They won't necessarily have been exposed to it. If you're hiring an intelligent, logical developer then they should be able to pick up the concept with very little effort. If you do choose to hire them and are worried they will break ...


12

I work as a Mercurial consultant and I've found that it's not too hard to explain DVCS to new users, provided that you don't confuse them. So what I do is: Emphasize the core principles. The history model in Mercurial is actually very clean and simple. In particular, I find that branches are modeled better in Mercurial than in, say, Subversion. Talk with ...


12

I do Mercurial consulting and my experience is that big companies spend a lot of time up-front to investigate the pros and cons of DVCS. So when they finally take the jump, they've already been using DVCS for one or two pilot projects and so they're pretty certain that it will work for the rest of the group. However, I do know of one example where Mercurial ...


12

Yes, you must delete all compiled code. Source control is for, well, the source code, not the compiled files. The worst scenario is when developers commit the compiled binaries. Your case is not the same, since you're not committing large binaries which are diff-unfriendly, but still, keep your source control free of everything you don't need to run the ...


12

I deal with both of your proposed solutions daily. There are two key concepts to handling them well. Use topic branches. I believe production history should be pristine. As a result I spend a great deal of time making my production branch's history logical, replicable, and debuggable. When using multiple machines, however, you occasionally need to commit ...


12

First of all, the use of feature branches (to isolate the work done on a feature) and CI (to find integration problems as soon as they are committed) are slightly at odds. In my opinion, running CI on feature branches is a waste of time. As feature branches come and go frequently, the CI tooling would have to be reconfigured over and over again. And that ...


11

There is one simple rule, which is a convention followed by many (if not all) SCMs and by most tools that work with SCMs : The first line of a commit message is a short summary, while the rest of the message contains the details. So, most tools display the first line only, and display the whole message on demand. A typical misuse of a commit message is ...


Only top voted, non community-wiki answers of a minimum length are eligible