Tag Info

Hot answers tagged

23

You assume the fix does not introduce any new issues and fixes the old ones complete. But lots of fixes are worth a review on their own - and that is probably much easier when the incremental changes can be reviewed separately.


6

The MIT license doesn't specify attribution beyond maintaining the copyright notice. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. Somewhere within the source for the project you are considering forking, there should be a LICENSE file or equivalent. If there isn't, then ...


5

When releasing a new version of a program is it better to include the full changelog since the beginning of the project or just the part since the last release? Neither. Only provide the relevant, bigger changes that an end user is going to care about. No one cares about the fact that you refactored class Foo so that it can be re-used a bit more ...


5

The good schedule is to merge only stable code (or "likely to be stable" code). If you merge half-way just to begin tests, and you know that some of the features you're currently coding are not finished, you surely will get some testing feedback about these features. The question you have to ask is "Am I confident with the completeness of what I already ...


5

You're right that once a local repository is pushed to a remote location, both locations contain the successive revisions. Moreover, if somebody mistakenly erases some of the files and pushes this change to the remote repository, you can still recover those files with ease from the history. What is the risk for both copies to be lost? It depends on the ...


4

If, as you write, you directly edit files on the server over SFTP, your only option (as far as I can see) is to install git on the server, login via SSH and do all git operations locally. You'd have to create a repository on the server, add all your files and then commit regularly. In that case your working directory would be the directory where all the JS ...


4

There are neither any advantages nor disadvantages to this approach. The reason I say this is simple: to Git, it makes no difference if you develop from master or release from master. You don't even need to release branches; you could tag an arbitrary commit and release that, instead. The real trouble here is one of process and procedure. The more ...


4

Assuming that this snippet of code x=0 x+=1 if foo x+=1 if bar return x has been changed in one branch into this x=0 x+=1 if foo && xyzzy x+=1 if bar return x and in another branch into this x=0 x+=1 if foo x+=1 if bar && xyzzy return x then I would not want git to merge it into this x=0 x+=1 if foo && xyzzy x+=1 if bar ...


4

The basic idea behind merging is that you have to consider resolving conflicts. You cannot just automatically merge and hope the system figured out what you meant - that is mostly does this is convenient but do not get confused and think that all merges work perfectly all the time. After merging, you will want to review the results and only if it passes the ...


3

Facebook is actually in the process of implementing server side rebasing (there's a summary here or you can skip to to about 10:55 in the video). In their case they have such a volume of pushes that developers are in competition to push, and they can get stuck trying to pull then push before someone else pushes and forces them to pull again. By ...


3

I can see your dilemma. I had it too, until I unlearned what I always assumed about master. I was taught you want to keep master deployable and not use it as development and from previous places where I've worked master is always meant to be deployable for production. From Git's documentation / book - Git branching The “master” branch in Git is ...


3

If you move the file in Windows Explorer, you still have to git add the new file location and git rm (or git add --all) the old file location. Once those two things are done, git will work out on its own that the new file is mostly identical to the old file, and will automatically display it as a move in commands like git status. The benefit of git mv is ...


3

The new Branch wont interfere on the master branch You should leave it there and keep writing and commit on the master branch


2

I prefer checks over conventions in this case. Every team contains member who are better at getting new features started and other people who are better at stabilizing things for a release. If you lack the latter, then code reviews will help (often, the more disciplined people will want code reviews anyway). That's why we configure our Git repo (we're ...


2

There's a few approaches you might consider: You could download a vanilla copy of the library from the same version as used in your project. Then use a diff utility to find what has been changed between your version and the vanilla version. This approach could work well if you know the version and there aren't too many changes. You could use git log to ...


2

Git has features like blame and bisect that should make this job relatively easy. Chances are, it was just a mistake, but it could have been an unintended side effect of fixing another problem, or even an intentional trade off. If you don't know what that other problem is, there's a good chance you will cause it again. There are few things more annoying ...


2

I am not familiar with plugin development at all. However, where your code is in the source control and how you present it to either browser can be separated by adding a build step. With that model: you have a single branch of development (you could have multiple, but you don't need to) your source is wherever you like it to be two distinct build steps ...


1

Whether its window or unix, git mv basically combines three actions: a file system move a git delete of the original file a git add of the new file. So, without git rm, one might do (this is Unix/OSX but the steps are similar in windows unless using cygwin terminal emulator and then u probably can): $ mv newfile movedfile $ git status On branch master ...


1

You might be trying to use git to handle a situation it was not intended to[citation needed], maybe a build script might be the answer. If Chrome is flexible with the folder structure, you could just follow the folder structure required by Firefox. Have one branch for Chrome and another for Firefox to handle the distinct files, then later do a merged by a ...


1

SVN/GIT or any control version should work. Except for very specific application, web application a rarely live ( in the sense Physically loaded in memory) and i assume your application doesnt rewrite itself ( else you have the risk of rewriting the push you just made). Then if you push your file the next call on the webserver/php will load the new code ...



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