Tag Info

New answers tagged

1

Currently Debian provides the integration via git-remote-bzr package, which lists as it's homepage https://github.com/felipec/git-remote-bzr.


0

As MainMa already said, the maintenance page is a feature of the site. They are not two sites. The maintenance page is a special page of the site and should therefore go with it in the same tree. Branches are great for parallel history, but not suitable for about anything else. For different variants, the only practical way is having them together in the ...


2

Since the maintenance page is a feature of the web application, there is no reason to put it into a separate branch or repository. Instead, have a dedicated directory, or maybe even just a file at the root. This will make it possible to: Share all static files such as the images, CSS or JavaScript, Benefit from common code instead of duplicating it with ...


0

Actually, git is rather different from the concept you described. In a nutshell, this is how it works: It's repository stores compressed copies of entire files that have changed, as determined by the SHA-1 hash of the file, rather than some form of a diff patch. But if the hash for a file is already anywhere in the repository, even if found on some ...


1

Fossil and Veracity are two VCSs that are not just VCSs, they are full project management systems. In addition to VCS functionality, they also include bug tracking and documentation, among other things. Veracity specifically is based around the idea that there are two general "shapes" of data in project management: "file shape" (a tree of unstructured, ...


1

Image-based systems such as most Smalltalks, LISPs, but also the Intentional Domain Workbench and similar tools have VCSs that aren't based on text. In those systems, programs aren't text files, they are semantic graphs of rich objects. In image-based systems, "programming" actually means "mutating the live running program while it is executing". Their VCSs ...


3

I think you'll find all SCMs are roughly the same, though you could consider Visual Sourcesafe as an esoteric outlier :-) Nearly all work on diff deltas between commits, SVN for example has the same kind of diff+patch approach darcs does, only it doesn't try to pull in more revision history than you ask it to when merging (I'm not sure if Darcs trying to ...


0

One drawback of using submodules is that the tarballs or zip-archives on Github (and many other services) do not include the sources of submodules. That is, the archives are not self-contained. This is of an issue if the repository is small and does not really have a build script, like a static HTML site depending on a JavaScript library.


3

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 ...


6

If it is just a single JAR file, then I don't think version controlling it will be apocalyptic. If however, you start adding more and more external JAR files to your app, then you should consider using a repo manager like artifactory to deal with this whether you opt to use Gradle/Maven/ANT. If you have a build script, you can further simplify the task ...


-1

With most other version control systems, there’s 2 places to store data: your working copy (the folders/files that you’re currently using) and the datastore (where the version control decides how to pack and store your changes). In Git there’s a third option: the staging area (or index). It’s basically a loading dock where you get to determine what changes ...


0

Staging is a step before the commit process in git. That is, a commit in git is performed in two steps: staging and actual commit. As long as a changeset is in the staging area, git allows you to edit it as you like (replace staged files with other versions of staged files, remove changes from staging, etc.). Broken metaphor time: Consider a scenario ...


5

You can create separate Git repositories for each library, publish them, then use Git submodules to link them to the main repository. git submodule add submodule1_url directory1 git submodule add submodule2_url directory2 git commit -m "add submodules" Working with submodules is a little more complex. After cloning the repo, you need to clone the ...


0

I have two git branches with almost the same code, but some minor changes in order to support different platforms. Your are trying to use a version control system to solve a design problem. I don't know the details of your systems but this "minor changes per platform" can be easily designed with a little abstraction and polymorphism if you use a OO ...


1

If the changes are very minor, like just different command-line arguments, this should be done with configuration files. Otherwise, as @radium alluded to, you should make separate modules, include everything in source control, and have the build system determine which module is included. Using Git to maintain two different branches is brittle and ...


2

This is my opinion, based on my experience. Debugging is one process. Rebasing is a different process. If you try to combine the two of them you get a mess. At the point that you start your rebase, you should have working code. If you don't have working code, stop what you're doing and fix the code. If this is code that someone else has submitted to ...


0

I've been faced with a couple of hard speed bumps that I've been surprised by: 1) having to using git from the command line (I've always been lucky & lazy enough to run it through one GUI or another :P) 2) a shop where the development flow relies heavily on rebasing instead of merging. After stubbing my toes a bunch of times, I finally whipped up a ...


1

The people are afraid of things that they don't understand, this is why they think branch are evil. The problem its that decide about the version control politics of a company without understanding branching its... well, not very professional. You are using a very similar approach that the one that the tool git-flow (https://github.com/nvie/gitflow) ...


2

I work in an office thats taken over 2 years (and still counting) to move to a Git/Branch workflow model from an RCS based config management tool. i.e. Git with gerrit was installed 2 years ago, yet releases and half the team still use the old tool. The old tool was a state of the art configuration management tool in 1994, and has features that Git/Gerrit do ...


7

Branches can be hard to understand for people who are not used to them, and can be tricky to explain to managers if you need to avoid saying things like "different versions". To a manager who is using a mental model based on clean division of labour and a waterfall process, the idea that you would even want to permit more than one person to work on a file at ...


1

My previous company had a manual copy/paste code deployment process. Everyone loved it except the Release Engineers. It wasn't changed until an accident wiped out several days worth of work and restoring from backup wasn't an option. Using a version control tool with proper branches was an easy sell after that. If you can demonstrate to your management ...


2

To answer your question: This seems to be the most brain dead process using git. The whole point of using git is because of easy branching and merging. Manually copying / pasting changes is just asking for trouble, because some day someone will forget to copy something and you will have no track of who did that.


2

Anything you put into the Spring XML is static and compiled into the binary. If there is some information which can change, it is always a good idea to externalize it into a properties file. Spring can read the properties file and then use the values as inputs to its beans. You need to use a concept called the property placeholder to inject these ...


1

TBH if you have a centralised system when pushing to origin is necessary then you're really using git like it was SVN/TFS (ie a centralised system) in the first place. You would be better off going back to such a SCM. However, you could migrate to Fossil which is a centralised decentralised SCM and I think is the next-gen of SCM systems. You should also ...


3

Firstly, let me say that trying to coerce software developers into adopting any practice is likely to backfire. Software developers as a group are intelligent, educated people who like to be treated as professionals, and respond much better to management techniques that respect this, and treat them as valued collaborators. So the key is to convince your ...


0

Let's skip --onto for the moment. upstream and branch are pretty basic, and actually sort-of mimic checkout and branch - the second argument is optional: git branch <newbranch> git branch <newbranch> <base> git checkout -b <newbranch> git checkout -b <newbranch> <base> git rebase <upstream> git rebase ...



Top 50 recent answers are included