Search Results

Search found 120 results on 5 pages for 'rebase'.

Page 3/5 | < Previous Page | 1 2 3 4 5  | Next Page >

• A file was added to git on commit n. How do I add it instead to commit n-m?

  - by carleeto

  I have a branch. Half way through I noticed git was not tracking a file that it should have been and so I added it as part of a commit and continued with my work. Now, I'm doing a git bisect and all commits before the file was added do not build. So I'm thinking, I need to split the commit that added the file into two parts: the file add and the rest of the commit. I then need to re-order the commits so that the file add commit will be at the beginning of my branch. Is this the correct solution or is there a better way of doing it?

  Read the article

• Reorganising git commits into different branches

  - by user1425706

  I am trying to reorganise my git tree so that it is structured a bit better. Basically at the moment I have a single master branch with a couple of small feature branches that split from it. I want to go back and reorder it so that the only commits in the main branch are the ones corresponding to new version numbers and then have all the in between commits reside in a separate develop branch from which the feature branches split from too. Basically I'm looking for a tool that will let me completely manually reorganise the tree. I thought maybe that interactive rebasing was what I was looking for but trying to do so in sourcetree makes it seem like it is not the right tool. Can anyone give me some advice on how best to proceed. Below is a diagram of my current structure: featureA x-x-x / \ master A-x-x-x-x-B-x-x-x-C D Desired structure: feature x-x-x / | develop x-x-x-x-x-x-x - / | | | master A - B - C - D

  Read the article

• Shared Git repo syncing to svn causing git svn rebase to pollute repo with a log of no-op merge prob

  - by John K

  This wasn't so bad at the beginning, but now I have hundreds of no-op merge problems (solved by git rebase --skip). I have setup a shared git repo for my group because it is easier to deal with. But the company uses SVN so I have to keep SVN in sync with GIT. Worked like a dream at first, but after weeks of doing this GIT is giving me a lot of the following errors. Applying: * making all config actions work Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging app/controllers/vulnerabilities_controller.rb CONFLICT (content): Merge conflict in app/controllers/vulnerabilities_controller.rb Auto-merging public/javascripts/network_analysis_vulnerability_config.js CONFLICT (content): Merge conflict in public/javascripts/network_analysis_vulnerability_config.js Failed to merge in the changes. Patch failed at 0046 * making all config actions work My workflow: git co master git pull origin git svn rebase ... deal with no-op merge problems ... git svn dcommit git pull origin git push origin The problem is that what is in SVN is the correct so I use git rebase --skip, but I have to do that hundreds of times before I can dcommit. How do I clear these merge problems permanently?

  Read the article

• How can I merge 2 commits into 1

  - by michael

  Hi, I am trying to merge 2 commits into 1. So I follow this: http://www.gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html I did $ git rebase --interactive HEAD~2 It opens an editor I change 'pick' to 'squash' Save the editor But i get 'Cannot 'squash' without a previous commit' so what can I do to recover? When I do ' git rebase --interactive HEAD~2 Interactive rebase already started' When I do '$ git rebase --continue Cannot 'squash' without a previous commit' Thank you.

  Read the article

• How do I customize the format of git rebase --interactive commit messages?

  - by adamjford

  Hi everyone, I use git for my local work (and love it ever so much), and I follow a workflow similar to the one described in this article. So basically, when starting on a new feature, I create a branch for it, go through the usual hack then commit cycle, and when I think I'm done with it, I squash it into a single commit using git rebase --interactive master, and these squashed commit messages always end up looking like the example in the article, reproduced here: [#3275] User Can Add A Comment To a Post * Adding Comment model, migrations, spec * Adding Comment controller, helper, spec * Adding Comment relationship with Post * Comment belongs to a User * Comment form on Post show page Of course, that's after a bunch of removing # This is the xth commit message lines and copy/pasting * in front of each commit message. Now, what I was wondering, is there any way to customize how git rebase -i outputs the merged commit messages so I don't have to do all that hacking? (I use msysgit, if that matters.) Thanks!

  Read the article

• Git rebase and semi-tracked per-developer config files.

  - by dougkiwi

  This is my first SO question and I'm new-ish to Git as well. Background: I am supposed to be the version control guru for Git in my group of about 8 developers. As I don't have a lot of Git experience, this is exciting. I decided we need a shared repository that would be the authoritative master for the production code and the main meeting-point for the development code. As we work for a corporation, we really do need to show an authoritive source for the production code at least. I have instructed the developers to pull-rebase when pulling from the shared repository, then push the commits that they want to share. We have been running into problems with a particular type of file. One of these files, which I currently assume is typical of the problem, is called web.config. We want a version-controlled master web.config for devs to clone, but each dev may make minor edits to this file that they wish to locally save but not share. The problem is this: how do I tell git not to consider local changes or commits to this file to be relevent for rebasing and pushing? Gitignore does not seem to solve the problem, but maybe that's because I put web.config into .gitignore too late? In some simple situations we have stacked local changes, rebased, pushed, and popped the stack, but that doesn't seem to work all of the time. I haven't picked up the pattern quite yet. The published documentation on pull --rebase tends to deal with simplier situations. Or do I have the wrong idea entirely? Are we misusing Git? Dougkiwi

  Read the article

• Fatal error on "mode 120000" file during git -> svn migration

  - by Oliver

  Following instructions from the following website: http://code.google.com/p/support/wiki/ImportingFromGit I'm trying to migrate a git repository to svn, but during the "git rebase master tmp" step it fails with the following error after apply the first few patches: $ git rebase master tmp First, rewinding head to replay your work on top of it... Applying: Imported Applying: Cleaned up the readme file Applying: fix problem with versions fatal: unable to write file foobar mode 120000 Patch failed at 0003 fix problem with versions When you have resolved this problem run "git rebase --continue". If you would prefer to skip this patch, instead run "git rebase --skip". To restore the original branch and stop rebasing run "git rebase --abort". I understand that 120000 may refer to a symlink, but Subversion has supported symlinks for a long time now. Subversion installed is 1.6.5, Git is 1.6.3.3. Running on Ubuntu Linux. The system is not running out of disk space and this operation is taking place within my home directory so permissions should not be an issue.

  Read the article

• Git branching / rebasing good practices

  - by Pawel Krupinski

  I have a following scenario: 3 branches: - Master - MyBranch branched off Master for the purpose of developing a new feature of the system - MyBranchLocal branched off MyBranch as my local copy of the branch MyBranch is being rebased against and pushed to by other developers (who are working on the same feature as I am). As the owner of the MyBranch branch I want to keep it in sync with Master by rebasing. I also need to merge the changes I make to MyBranchLocal with MyBranch. What is a good way to do that? Couple of possible scenarios I tried so far: I. 1. Commit change to MyBranchLocal 2. Rebase MyBranch against Master 3. Rebase MyBranchLocal against MyBranch 4. Merge MyBranch with MyBranchLocal II. 1. Commit change to MyBranchLocal 2. Merge MyBranch with MyBranchLocal 3. Rebase MyBranch against Master 4. Rebase MyBranchLocal against MyBranch III. 1. Commit change to MyBranchLocal 2. Rebase MyBranch against Master 3. Merge MyBranch with MyBranchLocal 4. Rebase MyBranchLocal against MyBranch I already know that scenario III seems to be messing the commit history up a lot, potentially duplicating commits. What is your experience? What scenarios do you recommend?

  Read the article

• git: remove 2nd commit

  - by cwolves

  I'm trying to remove the 2nd commit to a repo. At this point I could just blow away the .git dir and re-do it, but I'm curious how to do this... I've deleted commits before, but apparently never the 2nd one :) > git log commit c39019e4b08497406c53ceb532f99801793205ca Author: Me Date: Thu Mar 22 14:02:41 2012 -0700 Initializing registry directories commit 535dce28f1c68e8af9d22bc653aca426fb7825d8 Author: Me Date: Tue Jan 31 21:04:13 2012 -0800 First Commit > git rebase -i HEAD~2 fatal: Needed a single revision invalid upstream HEAD~2 > git rebase -i HEAD~1 at which point I get in my editor: pick c39019e Initializing registry directories # Rebase 535dce2..c39019e onto 535dce2 # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like "squash", but discard this commit's log message # x, exec = run command (the rest of the line) using shell # # If you remove a line here THAT COMMIT WILL BE LOST. # However, if you remove everything, the rebase will be aborted. # Now my problem is that I can't just blow away this 2nd commit since "if you remove everything, the rebase will be aborted"

  Read the article

• Rebasing a branch which is public

  - by Dror

  I'm failing to understand how to use git-rebase, and I consider the following example. Let's start a repository in ~/tmp/repo: $ git init Then add a file foo $ echo "hello world" > foo which is then added and committed: $ git add foo $ git commit -m "Added foo" Next, I started a remote repository. In ~/tmp/bare.git I ran $ git init --bare In order to link repo to bare.git I ran $ git remote add origin ../bare.git/ $ git push --set-upstream origin master Next, lets branch, add a file and set an upstream for the new branch b1: $ git checkout -b b1 $ echo "bar" > foo2 $ git add foo2 $ git commit -m "add foo2 in b1" $ git push --set-upstream origin b1 Now it is time to switch back to master and change something there: $ echo "change foo" > foo $ git commit -a -m "changed foo in master" $ git push At this point in master the file foo contain changed foo, while in b1 it is still hello world. Finally, I want to sync b1 with the progress made in master. $ git checkout b1 $ git fetch origin $ git rebase origin/master At this point git st returns: # On branch b1 # Your branch and 'origin/b1' have diverged, # and have 2 and 1 different commit each, respectively. # (use "git pull" to merge the remote branch into yours) # nothing to commit, working directory clean At this point the content of foo in the branch b1 is change foo as well. So what does this warning mean? I expected I should do a git push, git suggests to do git pull... According to this answer, this is more or less it, and in his comment @FrerichRaabe explicitly say that I don't need to do a pull. What's going on here? What is the danger, how should one proceed? How should the history be kept consistent? What is the interplay between the case described above and the following citation: Do not rebase commits that you have pushed to a public repository. taken from pro git book. I guess it is somehow related, and if not I would love to know why. What's the relation between the above scenario and the procedure I described in this post.

  Read the article

• Why is the meaning of “ours” and “theirs” reversed with git-svn

  - by Marc Liyanage

  I use git-svn and I noticed that when I have to fix a merge conflict after performing a git svn rebase, the meaning of the --ours and --theirs options to e.g. git checkout is reversed. That is, if there's a conflict and I want to keep the version that came from the SVN server and throw away the changes I made locally, I have to use ours, when I would expect it to be theirs. Why is that? Example: mkdir test cd test svnadmin create svnrepo svn co file://$PWD/svnrepo svnwc cd svnwc echo foo > test.txt svn add test.txt svn ci -m 'svn commit 1' cd .. git svn clone file://$PWD/svnrepo gitwc cd svnwc echo bar > test.txt svn ci -m 'svn commit 2' cd .. cd gitwc echo baz > test.txt git commit -a -m 'git commit 1' git svn rebase git checkout --ours test.txt cat test.txt # shows "bar" but I expect "baz" git checkout --theirs test.txt cat test.txt # shows "baz" but I expect "bar"

  Read the article

• Recover history from foolish git-svn merge

  - by Gregg Lind

  the players: master: the svn branch (actual, not local trackign) mybranch: a local branch My mistake: [master] git svn rebase [master] git merge mybranch [master] git svn dcommit I did this twice. Is there a way I can remedy all this? I was thinking something like: git checkout --hard [commit before the merging] git dcommit # that to the svn? git rebase mybranch git dcommit But this doesn't seem to work. (I know I should a. working from a local tracking branch and b. have rebased rather than merged) I'm in the frantic / willing to send beer to respondents stage :)

  Read the article

• git merging changes to local branch

  - by ScottS

  Is it possible to merge changes from a central repo to a local branch without having to commit/stash the edits on the local branch and checkout master? If I am working on local branch "work" and there are some uncommited changes, I use the following steps to get updates from the central repo into my working branch. git stash git checkout master git pull git checkout work git rebase master git stash pop Usually there are no uncommitted changes in "work" and then I omit the stash steps. What I would really like is something like the following: git pull master (updates master while work branch is checked out and has changes) git rebase master (rebases the updates into work branch uncommited changes are still safe) Is there something easier than what I currently do?

  Read the article

• Rebasing a core repo in git.

  - by b. e. hollenbeck

  I have a customized fork of CodeIgniter that I use as a standard baseline for several projects. Recently, I've made significant improvements in this repo that I want to use to update the client projects that use it. What I can't seem to figure out is how to pull in the changes to a client project. So I have: Baseline: A--B--C--D--E Client cloned @ C C'--D'--E' And I want to update the client repo to E from the Baseline project. I've tried rebase, and it has erased the files not present in the baseline project (views and such), and creates a bunch of conflicts that really don't need to be conflicts with things like the default HTML5 boilerplate that I use. Is there an option for rebase that I should be using? Is there a different way to approach it? Do I need a bunch of .gitignores for the content directories?

  Read the article

• Multiple svn projects into one git repository?

  - by trondgzi

  Hi, I have started to use git-svn for some of my work to be able to do local commits. This works great for projects that use standard svn layout. Recently I started working on a Java project that is split into multiple connected modules (20-25), and each module have its own root folder in the same svn repo with its own trunk/branches/tags. svnrepo/ module-1 trunk branches tags module-N trunk branches tags I have cloned each and every module with git svn clone -s /path/to/svnrepo/module[1-N]. The "problem" is that when I want to do git svn rebase on all modules i have to do it N times. I have tried to do git svn clone /path/to/svnrepo/ do avoid doing the rebase operation N times, but that leaves me with a directory layout that is the same as in the svn repo. Is there a way that I can track all the trunks of all modules in one git repo? So that I get a directory layout like this within my git repository: module-1 module-2 module-N

  Read the article

• Git commit messages with nvie branching model

  - by eykanal

  This Git branching model recommends branching for all development efforts and merging when complete: Branch Develop Merge when complete I'm wondering how this works in practice, given that performing a merge off this model will simply add a commit to the develop with whatever commit message happened to be the last one in line. Do people using this model do an interactive rebase on the feature branch before committing? If not, how do you ensure that the commits make sense on the main branch?

  Read the article

• Question about 'git branching'

  - by michael

  Hi, I read this about git branch: http://book.git-scm.com/3_basic_branching_and_merging.html so I follow it and create 1 branch : experimental And I 1. switch to experimental branch (git checkout experimental) 2. make a bunch of changes 3. commit it (git commit -a) 4. switch to master branch (git checkout master) 5. make some changes and commit there 6. switch back to experimental (git checkout experimental) 7. merge master change to experimental (git merge master) 8. there are some conflicts but after I resolve them, I did 'git add myfile' And now i am stuck, I can't move back to master when I do $ git checkout master error: Entry 'res/layout/my_item.xml' would be overwritten by merge. Cannot merge. and I did: $ git rebase --abort No rebase in progress? and I did : $ git add res/layout/socialhub_list_item.xml $ git checkout master error: Entry 'res/layout/my_item.xml' would be overwritten by merge. Cannot merge. What can I do so that I can go back to my master branch? Thank you.

  Read the article

• Best way to fork SVN project with Git

  - by Jeremy Thomerson

  I have forked an SVN project using Git because I needed to add features that they didn't want. But at the same time, I wanted to be able to continue pulling in features or fixes that they added to the upstream version down into my fork (where they don't conflict). So, I have my Git project with the following branches: master - the branch I actually build and deploy from feature_* - feature branches where I work or have worked on new things, which I then merge to master when complete vendor-svn - my local-only git-svn branch that allows me to "git svn rebase" from their svn repo vendor - my local branch that i merge vendor-svn into. then i push this (vendor) branch to the public git repo (github) So, my flow is something like this: git checkout vendor-svn git svn rebase git checkout vendor git merge vendor-svn git push origin vendor Now, the question comes here: I need to review each commit that they made (preferably individually since at this point I'm about twenty commits behind them) before merging them into master. I know that I could run git checkout master; git merge vendor, but this would pull in all changes and commit them, without me being able to see if they conflict with what I need. So, what's the best way to do this? Git seems like a great tool for handling forks of projects since you can pull and push from multiple repos - I'm just not experienced with it enough to know the best way of doing this. Here's the original SVN project I'm talking about: https://appkonference.svn.sourceforge.net/svnroot/appkonference My fork is at github.com/jthomerson/AsteriskAudioKonf (sorry - I couldn't make it a link since I'm a new user here)

  Read the article

• Using git pull to track a remote branch without merging

  - by J Barlow

  I am using git to track content which is changed by some people and shared "read-only" with others. The "readers" may from time to time need to make a change, but mostly they will not. I want to allow for the git "writers" to rebase pushed branches** if need be, and ensure that the "readers" never accidentally get a merge. That's normally easy enough. git pull origin +master There's one case that seems to cause problems. If a reader makes a local change, the command above will merge. I want pull to be fully automatic if the reader has not made local changes, while if they have made local changes, it should stop and ask for input. I want to track any upstream changes while being careful about merging downstream changes. In a way, I don't really want to pull. I want to track the master branch exactly. ** (I know this is not a best practice, but it seems necessary in our case: we have one main branch that contains most of the work and some topic branches for specific customers with minor changes that need to be isolated. It seems easiest to frequently rebase to keep the topics up to date.)

  Read the article

• git merge with renamed files

  - by Kevin

  I have a large website that I am moving into a new framework and in the process adding git. The current site doesn't have any version control on it. I started by copying the site into a new git repository. I made a new branch and made all of the changes that were needed to make it work with the new framework. One of those steps was changing the file extension of all of the pages. Now in the time that I have been working on the new site changes have been made to files on the old site. So I switched to master and copied all of those changes in. The problem is when I merge the branch with the new framework back onto master there is a conflict on every file that was changed on the master branch. I wouldn't be to worried about it but there are a couple of hundred files with changes. I have tried git rebase and git rebase --merge with no luck. How can I merge these 2 branches without dealing with every file?

  Read the article

• Using git filter-branch to remove commits by their commit message

  - by machineghost

  In our repository we have a convention where every commit message starts with a certain pattern: Redmine #555: SOME_MESSAGE We also do a bit of rebasing to bring in the potential release branch's changes to a specific issue's branch. In other words, I might have branch "foo-555", but before I merge it in to branch "pre-release" I need to get any commits that pre-release has that foo-555 doesn't (so that foo-555 can fast-forward merge in to pre-release). However, because pre-release sometimes changes, we sometimes wind up with situations where you bring in a commit from pre-release, but then that commit later gets removed from pre-release. It's easy to identify commits that came from pre-release, because the number from their commit message won't match the branch number; for instance, if I see "Redmine #123: ..." in my foo-555 branch, I know that its not a commit from my branch. So now the question: I'd like to remove all of the commits that "don't belong" to a branch; in other words, any commit that: Is in my foo-555 branch, but not in the pre-release branch (pre-release..foo-555) Has a commit message that doesn't start with "Redmine #555" but of course "555" will vary from branch to branch. Is there any way to use filter-branch (or any other tool) to accomplish this? Currently the only way I can see to do it is to do go an interactive rebase ("git rebase -i") and manually remove all the "bad" commits.

  Read the article

• Publish Git repository to SVN

  - by Ken Williams

  I and my small team work in Git, and the larger group uses Subversion. I'd like to schedule a cron job to publish our repositories current HEADs every hour into a certain directory in the SVN repo. I thought I had this figured out, but the recipe I wrote down previously doesn't seem to be working now: git clone ssh://me@gitserver/git-repo/Projects/ProjX px2 cd px2 svn mkdir --parents http://me@svnserver/svn/repo/play/me/fromgit/ProjX git svn init -s http://me@svnserver/svn/repo/play/me/fromgit/ProjX git svn fetch git rebase trunk master git svn dcommit Here's what happens when I attempt: % git clone ssh://me@gitserver/git-repo/Projects/ProjX px2 Cloning into 'ProjX'... ... % cd px2 % svn mkdir --parents http://me@svnserver/svn/repo/play/me/fromgit/ProjX Committed revision 123. % git svn init -s http://me@svnserver/svn/repo/play/me/fromgit/ProjX Using higher level of URL: http://me@svnserver/svn/repo/play/me/fromgit/ProjX => http://me@svnserver/svn/repo % git svn fetch W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: File not found: revision 100, path '/play/me/fromgit/ProjX' W: Do not be alarmed at the above message git-svn is just searching aggressively for old history. This may take a while on large repositories % git rebase trunk master fatal: Needed a single revision invalid upstream trunk I could have sworn this worked previously, anyone have any suggestions? Thanks.

  Read the article

• How can I rewrite the history of a published git branch in multiple steps?

  - by Frerich Raabe

  I've got a git repository with two branches, master and amazing_new_feature. The latter branch contains the work on, well, an amazing new feature. A colleague and me are both working on the same repository, and the two of us commit to both branches. Now the work on the amazing new feature finished, and a bit more than 100 commits were accumulated in the amazing_new_feature branch. I'd like to clean those commits up a bit (using git rebase -i) before merging the work into master. The issue we're facing is that it's quite a pain to rewrite/reorder all 100 commits in one go. Instead, what I'd like to do is: Rewrite/merge/reorder the first few commits in the amazing_new_feature branch and put the result into a dedicated branch which contains the 'cleaned up' history (say, a amazing_new_feature_ready_for_merge branch). Rebase the remaining amazing_new_feature branch on the amazing_new_feature_ready_for_merge branch. Repeat at 1. My idea is that at some point, all the work from amazing_new_feature should be in amazing_new_feature_ready_for_merge and then I can merge the latter into master. Is this a sensible approach, or are there better/easier/more fool-proff solutions to this problem? I'm especially scared about the second step of the above algorithm since it means rebasing a published branch. IIRC it's a dangerous thing to do.

  Read the article

• Is this a situation where I should "hg push -f"?

  - by user144182

  I have two machines, A and B that both access an external hg repository. I did some development on A, wasn't ready to push changesets to the external, and needed to switch machines, so I pushed the changesets to B using hg serve. Changesets continued on B, were committed and then pushed to external repo. I then pulled on A and updated to default/tip. This left the local changesets that had previously been pushed to B as a branch, but because of how I pushed things around, the changes in the local changesets are already in default/tip. I've now continued to make changes and commit locally on A, but when I try to push hg asks me to merge or do push -f instead. I know push -f is almost never recommended. This situation is close to one where I should use rebase, however the changesets that would be "rebased" I don't really need locally or in the external repository since they are already effectively in default/tip via the push to B. Now, I know I could merge with the latest local changeset and just discard the changes, but then I would still have to commit the merge which gets me back into rebase territory. Is this a case where I could do hg push -f? Also, why would pushing from A create remote heads if I've updated to default/tip before I continued to commit changesets?

  Read the article

• How should I incorporate a hotfix back into a feature branch using gitflow?

  - by Mark Trapp

  I've started using gitflow for a project, and I have an outstanding feature branch as well as a newly created hotfix. Per the gitflow workflow, the hotfix gets applied to both the master and develop branches, but nothing is said or done about extant feature branches. Nevertheless, I'd like to incorporate the hotfix changes back into my feature branch, which as near as I can tell leaves three options: Don't incorporate the changes. If the changes were needed for the feature branch, it should've been part of the feature branch. Merge develop back into the feature branch. This seems to follow the gitflow workflow the best, but would cause out-of-order commits. Rebase the feature branch onto develop. This would preserve commit order but rebasing seems to be completely absent from the general gitflow workflow. What's the best practice here?

  Read the article

< Previous Page | 1 2 3 4 5  | Next Page >