Search Results

Search found 1622 results on 65 pages for 'branch'.

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

  • 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

  • git local master branch stopped tracking remotes/origin/master, can't push

    - by Paul Smith
    Just when I thought I'd got the hang of the git checkout -b newbranch - commit/commit/commit - git checkout master - git merge newbranch - git rebase -i master - git push workflow in git, something blew up, and I can't see any reason for it. Here's the general workflow, which has worked for me in the past: # make sure I'm up to date on master: $ git checkout master $ git pull # k, no conflicts # start my new feature $ git checkout -b FEATURE9 # master @ 2f93e34 Switched to a new branch 'FEATURE9' ... work, commit, work, commit, work, commit... $ git commit -a $ git checkout master $ git merge FEATURE9 $ git rebase -i master # squash some of the FEATURE9 ugliness Ok so far; now what I expect to see -- and normally do see -- is this: $ git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # nothing to commit (working directory clean) But instead, I only see "nothing to commit (working directory clean)", no "Your branch is ahead of 'origin/master' by 1 commit.", and git pull shows this weirdness: $ git pull From . # unexpected * branch master -> FETCH_HEAD # unexpected Already up-to-date. # expected And git branch -a -v shows this: $ git branch -a -v FEATURE9 3eaf059 started feature 9 * master 3eaf059 started feature 9 remotes/origin/HEAD -> origin/master remotes/origin/master 2f93e34 some boring previous commit # should=3eaf059 git branch clearly shows that I'm currently on * master, and git log clearly shows that master (local) is at 3eaf059, while remotes/origin/HEAD - remotes/origin/master is stuck back at the fork. Ideally I'd like to know the semantics of how I might have gotten into this, but I would settle for a way to get my working copy tracking the remote master again & get the two back in sync without losing history. Thanks! (Note: I re-cloned the repo in a new directory and manually re-applied the changes, and everything worked fine, but I don't want that to be the standard workaround.) Addendum: The title says "can't push", but there's no error message. I just get the "already up to date" response even though git branch -a -v shows that local master is ahead of /remotes/origin/master. Here's the output from git pull and git remote -v, respectively: $ git pull From . * branch master -> FETCH_HEAD Already up-to-date. $ git remote -v origin [email protected]:proj.git (fetch) origin [email protected]:proj.git (push) Addendum 2: It looks as if my local master is configured to push to the remote, but not to pull from it. After doing for remote in 'git branch -r | grep -v master '; do git checkout --track $remote ; done, here's what I have. It seems I just need to get master pulling from remotes/origin/master again, no? $ git remote show origin * remote origin Fetch URL: [email protected]:proj.git Push URL: [email protected]:proj.git HEAD branch: master Remote branches: experiment_f tracked master tracked Local branches configured for 'git pull': experiment_f merges with remote experiment_f Local refs configured for 'git push': experiment_f pushes to experiment_f (up to date) master pushes to master (local out of date)

    Read the article

  • Rolling back or re-creating the master branch in git?

    - by Matthew Savage
    I have a git repo which has a few branches - there's the master branch, which is our stable working version, and then there is a development/staging branch which we're doing new work in. Unfortunately it would appear that without thinking I was a bit overzealous with rebasing and have pulled all of the staging code into Master over a period of time (about 80 commits... yes, I know, stupid, clumsy, poor code-man-ship etc....). Due to this it makes it very hard for me to do minor fixes on the current version of our app (a rails application) and push out the changes without also pushing out the 'staged' new features which we don't yet want to release. I am wondering if it is possible to do the following: Determine the last 'trunk' commit Take all commits from that point onward and move them into a separate branch, more or less rolling back the changes Start using the branches like they were made for. Unfortunately, though, I'm still continually learning about git, so I'm a bit confused about what to really do here. Thanks!

    Read the article

  • Listing and deleting Git commits that are under no branch (dangling?)

    - by Samer Abukhait
    I've got a git repository with plenty of commits that are under no particular branch, I can git show them but when I try to list branches that contain them, it reports back nothing: I thought this is the dangling commits/tree issue (as a result of -D branch), so I pruned the repo, but I still see the case after that: $ git fetch origin $ git fsck --unreachable $ git fsck No output, nothing dangling (right?) $ git show 793db7f272ba4bbdd1e32f14410a52a412667042 commit 793db7f272ba4bbdd1e32f14410a52a412667042 Author: .. But $ git branch --contains 793db7f272ba4bbdd1e32f14410a52a412667042 Gives no output What exactly is the state of that commit? How can I list all commits with similar state, How can I delete commits like those?

    Read the article

  • Git. Checkout feature branch between merge commits

    - by mageslayer
    Hi all It's kind weird, but I can't fulfill a pretty common operation with git. Basically what I want is to checkout a feature branch, not using it's head but using SHA id. This SHA points between merges from master branch. The problem is that all I get is just master branch without a commits from feature branch. Currently I'm trying to fix a regression introduced earlier in master branch. Just to be more descriptive, I crafted a small bash script to recreate a problem repository: #!/bin/bash rm -rf ./.git git init echo "test1" > test1.txt git add test1.txt git commit -m "test1" -a git checkout -b patches master echo "test2" > test2.txt git add test2.txt git commit -m "test2" -a git checkout master echo "test3" > test3.txt git add test3.txt git commit -m "test3" -a echo "test4" > test4.txt git add test4.txt git commit -m "test4" -a echo "test5" > test5.txt git add test5.txt git commit -m "test5" -a git checkout patches git merge master #Now how to get a branch having all commits from patches + test3.txt + test4.txt - test5.txt ??? Basically all I want is just to checkout branch "patches" with files 1-4, but not including test5.txt. Doing: git checkout [sha_where_test4.txt_entered] ... just gives a branch with test1,test3,test4, but excluding test2.txt Thanks.

    Read the article

  • Pull/Clone a svn repository into hg with new default branch name?

    - by TheLQ
    I'm forking a project's SVN repo and need to integrate into my Mercurial repo. To keep things simple I have a local hgsubversion repo and a local hg repo. However both the mercurial and hgsubversion repo uses default as their default branch name. My goal here is to put the original code and updates on one branch and my code on the default branch However I have yet to be able to do this. W:\programming\tcsite-svn-test>hg clone http://*HG_SITE*/hg . no changes found updating to branch default 0 files updated, 0 files merged, 0 files removed, 0 files unresolved W:\programming\tcsite-svn-test>hg branch blizzard marked working directory as branch blizzard W:\programming\tcsite-svn-test>hg commit W:\programming\tcsite-svn-test>hg log changeset: 0:be13a9580df0 branch: blizzard tag: tip user: Leon Blakey <[email protected]> date: Fri Jan 14 23:44:25 2011 -0500 summary: Created Blizzard Branch W:\programming\tcsite-svn-test>hg pull http://*SVN_SITE*/svn/ pulling from http://*SVN_SITE*/svn/ .... pulled 23 revisions (run 'hg update' to get a working copy) W:\programming\tcsite-svn-test>hg branch blizzard W:\programming\tcsite-svn-test>hg branches default 23:93642a8890ab <------ blizzard 0:be13a9580df0 Not surprisingly, hgsubversion puts pulled commits into the default branch when I really need them in the blizzard branch. From the docs, there is no way to rename the branch that a commit came from. Frustratingly I can't even come up with a way to do it on a repo with only the hgsubversion repo being pulled from, nothing else. All commits are tied to that one branch no matter what. Is there any suggestions on how to pull changes from an SVN repo and rename the branch to something else?

    Read the article

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