Search Results

Search found 2291 results on 92 pages for 'justin branch'.

Page 4/92 | < Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Git push current branch to a remote with Heroku

    - by cmaughan
    I'm trying to create a staging branch on Heroku, but there's something I don't quite get. Assuming I've already created a heroku app and setup the remote to point to staging-remote, If I do: git checkout -b staging staging-remote/master I get a local branch called 'staging' which tracks staging-remote/master - or that's what I thought.... But: git remote show staging-remote Gives me this: remote staging Fetch URL: [email protected]:myappname.git Push URL: [email protected]:myappname.git HEAD branch: master Remote branch: master tracked Local branch configured for 'git pull': staging-remote merges with remote master Local ref configured for 'git push': master pushes to master (up to date) As you can see, the pull looks reasonable, but the default push does not. It implies that if I do: git push staging-remote I'm going to push my local master branch up to the staging branch. But that's not what I want.... Basically, I want to merge updates into my staging branch, then easily push it to heroku without having to specify the branch like so: git push staging-remote mybranch:master The above isn't hard to do, but I want to avoid accidentally doing the previous push and pushing the wrong branch... This is doubly important for the production branch I'd like to create! I've tried messing with git config, but haven't figured out how to get this right yet...

    Read the article

  • Does deleting a branch in git remove it from the history?

    - by Ken Liu
    Coming from svn, just starting to become familiar with git. When a branch is deleted in git, is it removed from the history? In svn, you can easily recover a branch by reverting the delete operation (reverse merge). Like all deletes in svn, the branch is never really deleted, it's just removed from the current tree. If the branch is actually deleted from the history in git, what happens to the changes that were merged from that branch? Are they retained?

    Read the article

  • How do I determine what branch/tag I have checked out in git?

    - by Avry
    I clone my source using git clone https://gerrit.wikimedia.org/r/p/mediawiki/core.git w/. Then I specify a specific branch/tag by doing git checkout <tag name> or git checkout origin/REL<release number>. Sometimes I forget what branch or tag I'm on. In SVN I would do a svn info to figure out what branch/tag I'm using (I realize that git has distinct definitions for branch and tag but for my purposes they are the same). How do I determine what branch/tag I am on?

    Read the article

  • Committing to a different branch with commit -r

    - by Amarghosh
    Does CVS allow committing a file to a different branch than the one it was checked out from? The man page and some sites suggest that we can do a cvs ci -r branch-1 file.c but it gives the following error: cvs commit: Up-to-date check failed for `file.c' cvs [commit aborted]: correct above errors first! I did a cvs diff -r branch-1 file.c to make sure that contents of file.c in my BASE and branch-1 are indeed the same. I know that we can manually check out using cvs co -r branch-1, merge the main branch to it (and fix any merge issues) and then do a check in. The problem is that there are a number of branches and I would like to automate things using a script. This thread seems to suggest that -r has been removed. Can someone confirm that? If ci -r is not supported, I am thinking of doing something like: Make sure the branch versions and base version are the same with a cvs diff Check in to the current branch Keep a copy of the file in a temp file For each branch: Check out from branch with -r replace the file with the temp file Check in (it'll go the branch as -r is sticky) Delete the temp file The replacing part sounds like cheating to me - can you think of any potential issues that might occur? Anything I should be careful about? Is there any other way to automate this process?

    Read the article

  • Branch prediction , correlation bit

    - by Maciej Adrzej
    Problem ; Consider following simplified code fragment; if (d==0) d=1; if (d==1) ... Construct the action table for the 1-bit predictor with 1-bit correlation assuming predictor initialized to NOT TAKEN and the correlation bit is initialized to TAKEN. The value of d alternates 1,2,1,2 Note count the instances of misprediction. I tried to solve question my answer is ; |d=?|B1 |B1 |New B1 |B2 |B2 | New B2 | | |Prediction|Action|Prediction|Prediction|Action|Prediction| |1 | NT/NT | T | T/NT | NT/NT | NT | NT/NT | |2 | T/NT | T | T/NT | NT/NT | T | NT/T | |1 | T/NT | T | T/NT | NT/T | NT | NT/NT | |2 | T/NT | T | T/NT | NT/NT | T | NT/T | I doubt whether it is true or not ? Any idea ?

    Read the article

  • Git: Help an SVN novice translate trunk/branch concepts to Git

    - by Jasconius
    So I am not much of a source control expert, I've used SVN for projects in the past. I have to use Git for a particular project (client supplied Git repo). My workflow is as such that I will be working on the files from two different computers, and often I need to check in changes that are unstable when I move from place to place so I can continue my work. What then occurs is when, say, the client goes to get the latest version, they will also download the unstable code. In SVN, you can address this by creating a trunk and use working branches, or use the trunk as the working version and create stable branches. What is the equivalent concept in Git, and is there a simple way to do this via Github?

    Read the article

  • Gerrit, git and reviewing whole branch

    - by liori
    I'm now learning Gerrit (which is the first code review tool I use). Gerrit requires a reviewed change to consist of a single commit. My feature branch has about 10 commits. The gerrit-prefered way is to squash those 10 commits into a single one. However this way if the commit will be merged into the target branch, the internal history of that feature branch will be lost. For example, I won't be able to use git-bisect to bisect into those commits. Am I right? I am a little bit worried about this state of things. What is the rationale for this choice? Is there any way of doing this in Gerrit without losing history?

    Read the article

  • Launchpad dailybuild source in subdirectory of branch

    - by Jared
    I have a repo branch that i have mirrored in Launchpad that I am trying to setup a daily build. The problem is that the source directory of the package is a subdirectory in the branch. When building locally it's no problem because I can just change to that directory. However with launchpad's bzr-builder it does everything from the top directory in the branch. My current build recipe is: # bzr-builder format 0.3 deb-version {debupstream}-{revno}-{revno:packaging} lp:kegbot nest-part packaging lp:~szechyjs/kegbot/kegbot_debian debian debian Ideally I would use lp:kegbot/pykeg but this is not possible in bzr. Is there a easy way I can build the package in the kegbot/pykeg directory, by setting it up in my recipe or some kind of source directory variable in the rules file?

    Read the article

  • git changing head not reflected on co-dev's branch

    - by stevekrzysiak
    Basically, we undid history. I know this is bad, and I am already committed to avoiding this at all costs in the future, but what is done is done. Anyway, I issued a git push origin <1_week_old_sha:master to undo some bad commits. I then deleted a buggered branch called release(which had also received some bad commits) from remote and then branched a new release off master. I pushed this to remote. So basically, remote master & release are clones and just how I want them. The issue is if I clone the repo anew(or work in my current repo) everything looks great....but when my co-devs delete their release branch and create a new one based off the new remote release I created, they still see all the old junk I tried to remove. I feel this has to do with some local .git files mistaking the new branch release for the old release. Any thoughts? Thanks.

    Read the article

  • Safely delete a TFS branch project

    - by Codesleuth
    I'm currently reorganising our TFS source control for a very large set of solutions, and I've done this successfully so far. I have a problem at the moment where I need to delete a legacy "Release Branch" TFS project that was branched for the old structure, and is no-longer required since I now host a release branch within the new structure. This is an example of how the source control now looks after moving everything: $/Source Project /Trunk /[Projects] /Release /[Projects] $/Release Branch Project /[Projects] /[Other legacy stuff] So far I've found information that says: tf delete /lock:checkout /recursive TestMain to delete a branch. TfsDeleteProject to delete a project tf delete seems to be only relevant when I need to delete a branch that is within the same project as the trunk, and TfsDeleteProject doesn't seem like it will delete the branch association from the source project (I hope I'm wrong, see below). Can someone tell me if the above will work, and in what order I should perform them in, to successfully delete the TFS $/Release Branch Project while also deleting the branch association (from right-click $/Source Project - Properties - Branches)?

    Read the article

  • Pulling changes from master to my work branch?

    - by Utkarsh Sinha
    There's two of us working on something. We're using this branch structure master dev-A dev-B We both work on separate branches (dev-A,B) and whenever we're done - we promote our changes to master. But the drawback of this is we can't get changes the other developer makes. Everything exists in the master tree - but we can't get the latest updates the other developer made. Is there a way to resolve this or should we change our branch structure (per feature?)?

    Read the article

  • How do I prevent a branch from being pushed to another branch in BZR?

    - by cabbey
    We use a dev-test-prod branching scheme with bzr 2. I'd like to setup a bzr hook on the prod branch that will reject a push from the test branch. Looking at the bzr docs, this looks doable, but I'm kinda surprised that my searches don't turn up any one having done it, at least not via any of the keywords I've thought to search by. I'm hoping someone has already gotten this working and can share their path to success. My current thought is to use the pre_change_branch_tip hook to check for the presence of a file on the test branch. If it's present, fail the commit. You may ask, why test for a file, why not just test the branch name? Because I actually need to handle the case where our developers have branched their devel branch, pulled in the shared test branch and are now (erroneously) pushing that test branch to production instead of pushing their feature branch to production. And it seems a billion times easier to look for a file in the new branch than to try to interrogate the sending branch's lineage. So has someone done this? seen it done? or do I get to venture out into the uncharted wasteland that is hook development with bzr? :)

    Read the article

  • Why does git branch -t fail with "Not tracking: ambiguous information"?

    - by che
    When I try to create a new branch tracking a remote branch, I get this: che@nok ~/prj/git-ipc $ git branch -t test main/some_remote_branch error: Not tracking: ambiguous information for ref refs/remotes/main/some_remote_branch The source seems to somehow search for branches to track and throws me out because it finds less more than one, but I don't exactly get what it's looking for since I already told it what to track on the command line. Can anybody tell me what's going on and how to fix it?

    Read the article

  • When is the reintegrate option really necessary?

    - by Tor Hovland
    If you always sync a feature branch before you merge it back, why do you really have to use the --reintegrate option? The Subversion book says: When merging your branch back to the trunk, however, the underlying mathematics is quite different. Your feature branch is now a mishmosh of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!) So the --reintegrate option only merges the changes that are unique to the feature branch. But if you always sync before merge (which is a recommended practice, in order to deal with any conflicts on the feature branch), then the only changes between the branches are the changes that are unique to the feature branch, right? And if Subversion tries to merge code that is already on the target branch, it will just do nothing, right? In this blog post, Mark Phippard writes: http://blogs.open.collab.net/svn/2008/07/subversion-merg.html If we include those synched revisions, then we merge back changes that already exist in trunk. This yields unnecessary and confusing conflicts. Can somebody give me an example of when dropping reintegrate gives me unnecessary conflicts?

    Read the article

  • Is a "model" branch a common practice?

    - by dukeofgaming
    I just thought it could be a good thing to have a dedicated version control branch for all database schema changes and I wanted to know if anyone else is doing the same and what have the results been. Say that you are working with: Schema model/documentation (some file where you model the database visually to generate the schema source, say MySQL Workbench, with a .mwb file, which is binary) Schema source (a .sql file) Schema-based code generation The normal way we were working was with feature branches, so we would do changes to the model files (the database specific ones), and then have to regenerate points 2 and 3, dealing with the possible conflicts (or even code rewriting). Now say that your workflow goes the same way as the previous item numbering. With a model branch you wouldn't have to reconcile the schema model with binaries in other feature branches, or have to regenerate schema source and regenerate code (which might have human code on top of it). It makes so much sense to me it feels weird not having seen this earlier as a common practice. Edit: I'm counting on branch merges to be the assertions for the model matching the code. I use a DVCS, so I don't fear long-lived branches or scary-looking merges. I'm also doing feature branching.

    Read the article

  • dvcs - is "clone to branch" a common workflow?

    - by Tesserex
    I was recently discussing dvcs with a coworker, because our office is beginning to consider switching from TFS (we're a MS shop). In the process, I got very confused because he said that although he uses Mercurial, he hadn't heard of a "branch" or "checkout" command, and these terms were unfamiliar to him. After wondering how it was possible that he didn't know about them and explaining how dvcs branches work "in place" on your local files, he was quite confused. He explained that, similar to how TFS works, when he wants to create a "branch" he does it by cloning, so he has an entire copy of his repo. This seemed really strange to me, but the benefit, which I have to concede, is that you can look at or work on two branches simultaneously because the files are separate. In searching this site to see if this has been asked before I saw a comment that many online resources promote this "clone to branch" methodology, to the poster's dismay. Is this actually common in the dvcs community? And what are some of the pros and cons of going this way? I would never do it since I have no need to see multiple branches at once, switching is fast, and I don't need all the clones filling up my disk.

    Read the article

  • SVN Question regarding branching and third party vendor branching

    - by fritzone
    Hi, We are developing an application which consists of: a source code base given to us by a partner infrequently. This is a somewhat working code, "final" version of something. They have their own release cycle and version tracking. on the code base above we make our changes. These can be either bugfixes or development of new features. Till now, we managed to create some code mayhem, as a result we would like to put all this in a SVN repository. I would like to ask you what you think is the best practice for this to happen with the less pain. The followings are our things that we consider important: We would like to track our bugfixes/changes since we cannot send back bugfixes to our software vendor, but we can report a bug (and they might or might not fix it). All we develop on their code remains "in-house" they are not interested in our changes. As long as we don't get a new codebase from the vendor, we consider their latest version to be the stable one we are working on. This might be branched down further, but the result is always a stable trunk, the build is done based on this "stable" trunk. When the vendor releases a new version we would like to merge our "stable" trunk (which contains a lot of changes) with their changes, thus creating a new "stable" trunk. For each version we deploy (to clients) we should be able later to fix bugs only on that version, for clients who have installed our system using that specific version There are more developers working on the codebase... (as usual :) Thanks a lot for the tips.

    Read the article

  • Push Trunk or Push Branch to Production

    - by coffeeaddict
    I'd like to get an idea of some processes on build process with Tortoise SVN. Primarily I'm wondering do you push: The Mainline Trunk A branch after QA has grabbed it into a working copy locally and tested the branch and then some build pushes that branch The problem I have is I work at a craphole (hey, it is what it is and I'm venting on stackoverflow, you better believe it..good way to relieve stress due to complete utter chaos) and we have no formal process for pushing anything. In fact even worse my boss directly codes against production. When I have changes, he pushes the mainline trunk. The problem becomes when I make database changes on our Dev database for lets say Branch A. Well...that breaks Branch B and C. I have like 4 projects going on at once! Why? Well, I will not get into that (chaos). So consequently I rename a table field, or add a field or whatever in SQL Server and walla, now my other branches have stale code pointing to previous field names. So what happens? I have to merge certain changes to this branch, to that branch, etc. It feels like a war zone. Finally, what happens is I try to only merge the minimum. Lets say I made DB changes for Branch A's code but now I had to jump back on Branch B's project. Well I need to merge "some" of A's changes over for those database changes so that B's code is not going to bomb out and is able to work with the new table changes. Finally boss pushes the mainline trunk to production. Now I get an email "you forgot to remove the hyperlink for this". That hyperlink was actually a feature I added in Branch A. But what he's talking about here is he just pushed the mainline trunk to production which now has my merged changes from Branch B and any database scripts for Branch A because remember I had some DB changes and if he pushes code, it's got to reflect those changes thus some partial database changes must also be pushed even if it's not related to this project. Well...I missed the hyperlink, so kill me. Maybe that's why we need a build process boss? (sorry, it's been a nightmare working here which is why this thread is getting so detailed). Anyway, obviously this is a nightmare. And he dictates almost everything. The only reason we have source control is because I've worked on hard core teams and that's the first thing you setup. Well there was none here. Problem is I can't dictate the structure..he does but he's never really used source control!! My God. So we have no QA. This is an e-commerce website. That's another huge issue. So consequently I'm expected to be perfect. That means mainline trunk needs to be perfect for whatever we're pushing, whatever branch feature. Is this luda? wtf do I do? I could go off on him after tying so many times tactfully to explain that we need a freakin build process (not just copy local mainline trunk to production!) but I've tried to push before and got yelled at. So I gave up on that. So it will help me tremendously to know how others are pushing their source from Tortoise to production. I was not the person pushing when I was on previous teams so really I'm not too versed in build processes. We are a fairly good size e-commerce site and get a couple millions hits a month.

    Read the article

  • branch prediction

    - by Alexander
    Consider the following sequence of actual outcomes for a single static branch. T means the branch is taken. N means the branch is not taken. For this question, assume that this is the only branch in the program. T T T N T N T T T N T N T T T N T N Assume a two-level branch predictor that uses one bit of branch history—i.e., a one-bit BHR. Since there is only one branch in the program, it does not matter how the BHR is concatenated with the branch PC to index the BHT. Assume that the BHT uses one-bit counters and that, again, all entries are initialized to N. Which of the branches in this sequence would be mis-predicted? Use the table below. Now I am not asking answers to this question, rather than guides and pointers on this. What does a two level branch predictor means and how does it works? What does the BHR and BHT stands for?

    Read the article

  • I accidentally created a git local branch called --track, how can I delete it?

    - by Rich
    I mistyped a git command which resulted in the creation of a local branch called, '--track'. I've tried the following: git branch -m --track delme (this renames the current branch to delme, not the branch called --track) git checkout --track > fatal: --track needs a branch name git branch -d --track (does nothing, reports nothing) git branch -D --track (also does nothing) git branch -d "--track" (also does nothing How can I delete this branch?

    Read the article

  • heroku using git branch is confusing!

    - by Stacia
    Ok, so I have a big github project that i'm not supposed to merge my little Stacia branch into. However, it seems like Heroku only takes pushing MASTER seriously. It looks like I pushed my branch, but for example if I only have my branch, it even acts like there's no code on the server. I can't even get my gems installed since the .gems file is on my branch. Basically I don't even want Heroku to know there's a master. I just want to use my test Stacia branch. But it keeps ignoring my local branch. Is there a way to do this? And again, I don't want to overwrite anything on the main Github repository (eeek!) but it would be ok probably if I had both master and my branch on heroku and merged them there. I am a total git novice (on windows no less) so please bear with me.

    Read the article

  • Git: Make one branch exactly like another

    - by G. Martin
    I am relatively new to Git, and I'm still not very comfortable with it. Right now, I'm looking for the command/options/magic that can make the current branch look like another branch; that is, to merge them, but when a conflict arises, to always choose the difference in the branch that is being merged into the current one. My situation is thus; I have an stable(ish) application on the "master" branch. I also have another branch, called "feature". I basically want to make changes/additions/deletions to feature until I like the new feature I'm working on. Once I feel it is ready, I want to make the master branch look identical to the feature branch. I know this probably isn't a best practice, but as I said, I'm new to Git. I plan on learning how to do more complicated things in the future, but for now, this is all I need. Thanks, SO!

    Read the article

< Previous Page | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >