Search Results

Search found 34 results on 2 pages for 'rebasing'.

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

Page 1/2 | 1 2  | Next Page >

  • Cherrypicking versus Rebasing

    - by Lakshman Prasad
    The following is a scenario I commonly face: You have a set of commits on master or design, that I want to put on top of production branch. I tend to create a new branch with the base as production cherry-pick these commits on it and merge it to production Then when I merge master to production, I face merge conflicts because even tho the changes are same, but are registered as a different commit because of cherry-pick. I have found some workarounds to deal with this, all of which are laborious and can be termed "hacks". Altho' I haven't done too much rebasing, I believe that too creates a new commit hash. Should I be using rebasing where I am cherrypicking. What other advantages does that have over this.

    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

  • 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: how to not delete files when rebasing commits with file deletion

    - by Benjol
    I have a branch that I would like to rebase onto the lastest commit on my master. The problem is that one of the intervening commits on master was to delete and ignore a particular set of files (see this question). If I just do a straight rebase, those files will get deleted again. Is there anyway of doing this, inside git, rather than copying all the files out by hand, then copying them back in again afterwards? Or should I do something like create a new branch off master, then merge in just the commits from the old branch? Attempts ascii art: master branch | w work in progress on branch C | committed further changes on master | | B / committed delete/ignore files on master | 2 committed changes on branch | / A / committed changes on master which I now need to get branch working | 1 committed changes on branch 0___/ created branch (Doing the art, I realise that I could just rebase branch from A, then merge when I've finished, but I'd still like to know if there's a way to do this 'properly') UPDATE Warning to anyone trying this. The solution proposed here is fine, but when you checkout master again, the B commit will be re-applied, and you lose all your files again :(

    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

  • .NET assembly cache / ngen / jit image warm-up and cool-down behavior

    - by Mike Jiang
    Hi, I have an Input Method (IME) program built with C#.NET 2.0 DLL through C++/CLI. Since an IME is always attaching to another application, the C#.NET DLL seems not able to avoid image address rebasing. Although I have applied ngen to create a native image of that C#.NET 2.0 DLL and installed it into Global Assembly Cache, it didn't improved much, approximately 12 sec. down to 9 sec. on a slow PIII level PC. Therefore I uses a small application, which loads all the components referenced by the C#.NET DLL at the boot up time, to "warm up" the native image of that DLL. It works fine to speed up the loading time to 0.5 sec. However, it only worked for a while. About 30 min. later, it seems to "cool down" again. Is there any way to control the behavior of GAC or native image to be always "hot"? Is this exactly a image address rebasing problem? Thank you for your precious time. Sincerely, Mike

    Read the article

  • Do I need to perform a commit after a rebase?

    - by Benjol
    I've just rebased a feature branch onto another feature branch (in preparation for rebasing everything to the head of my master), and it involved quite a few tricky merge resolutions. Is the rebase automatically saved as a commit somewhere? Just where do those modifications live? I can't see anything in gitk, or git log --oneline. (Same question for when I merge back my branch after rebasing.)

    Read the article

  • Is version history really sacred or is it better to rebase?

    - by dukeofgaming
    I've always agreed with Mercurial's mantra, however, now that Mercurial comes bundled with the rebase extension and it is a popular practice in git, I'm wondering if it could really be regarded as a "bad practice", or at least bad enough to avoid using. In any case, I'm aware of rebasing being dangerous after pushing. OTOH, I see the point of trying to package 5 commits in a single one to make it look niftier (specially at in a production branch), however, personally I think would be better to be able to see partial commits to a feature where some experimentation is done, even if it is not as nifty, but seeing something like "Tried to do it way X but it is not as optimal as Y after all, doing it Z taking Y as base" would IMHO have good value to those studying the codebase and follow the developers train of thought. My very opinionated (as in dumb, visceral, biased) point of view is that programmers like rebase to hide mistakes... and I don't think this is good for the project at all. So my question is: have you really found valuable to have such "organic commits" (i.e. untampered history) in practice?, or conversely, do you prefer to run into nifty well-packed commits and disregard the programmers' experimentation process?; whichever one you chose, why does that work for you? (having other team members to keep history, or alternatively, rebasing it).

    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

  • When should I use git pull --rebase?

    - by Jason Baker
    I know of some people who use git pull --rebase by default and others who insist never to use it. I believe I understand the difference between merging and rebasing, but I'm trying to put this in the context of git pull. Is it just about not wanting to see lots of merge commit messages? Or are there other issues?

    Read the article

  • msysgit git-am can't apply it's own git format-patch sequence

    - by Andrian Nord
    I'm using msysgit git on windows to operate on central svn repository. I'm using git as I want to have it's awesome little local branches for everything and rebasing on each other. I also need to update from central repo often, so using separate svn/git is not an option. Problem is - git svn --help (man page) says that it is not a good idea to use git merge into master branch (which is set to track from svn's trunk) from local branches, as this will ruin the party and git svn dcommit would not work anymore. I know that it's not exactly true and you may use git merge if you are merging from branch which was properly rebased on master prior merge, but I'm trying to make it safer and actually use git format-patch and git am. We are using code review, so I'm making patches anyway. I also knew about git cherry-pick, but I want to just git am /reviewed/patches/dir/* without actually recalling what commits was corresponding to this patches (without reading patches, that is). So, what's wrong with git svn and git am? It's simple - git am for a few very hard points is doing CRLF into LF conversion for patches supplied (git-mailsplit is doing this, to be precise), if not rebasing. git format-patch is also producing proper (LF-ended) patches. As my repo is mostly CRLF (and it should remain so), patches are, obviously, failing due to wrong EOL. Converting diffs to CRLF and somehow hacking git am to prevent it from conversion is not working, too. It will fail if any file was removed or deleted - git apply will complain about expected /dev/null (but he got /dev/null^M). And if I'm applying it with git am --ignore-space-change --ignore-whitespace that it will commit LF endings straight to the index, which is also weird. I don't know if it will preserve over commiting into svn (via git svn dcommit) and checking it out and I don't want to try out. Of course, it's still possible to try hacking around patches to convert only actual diffs, but this is too much hacks for simple task. So, I wonder, is there really no established way to produce patches and apply them to the same repo on the same system? It just feels weird that msysgit can't apply it's own patches.

    Read the article

  • git rebase, keeping track of 'local' and 'remote'

    - by Benjol
    When doing a git rebase, I often have difficulty working out what is happening with the 'local' and 'remote' when resolving conflicts. I sometimes have the impression that they swap sides from one commit to the next. This is probably (definitely) because I still haven't properly understood. When rebasing, who is 'local' and who is 'remote'? (I use P4Merge for resolving conflicts)

    Read the article

  • What git branching models actually work - the final question

    - by UncleCJ
    In our company we have successfully deployed git and we are currently using a simple trunk/release/hotfixes branching model. However, this has it's problems, I have some key issues of confusion in the community which would be awesome to have answered here. Maybe my hopes for an Alexander stroke are too great, quite possibly I'll decompose this question into more manageable issues, but here's my first shot. Workflows / branching models - below are the three main descriptions of this I have seen, but they are partially contradicting each other or don't go far enough to sort out the subsequent issues we've run into (as described below). Thus our team so far defaults to not so great solutions. Are you doing something better? gitworkflows(7) Manual Page (nvie) A successful Git branching model (reinh) A Git Workflow for Agile Teams Merging vs rebasing (tangled vs sequential history) - the bids on this are as confusing as it gets. Should one pull --rebase or wait with merging back to the mainline until your task is finished? Personally I lean towards merging since this preserves a visual illustration of on which base a task was started and finished, and I even prefer merge --no-ff for this purpose. It has other drawbacks however. Also many haven't realized the useful property of merging - that it isn't commutative (merging a topic branch into master does not mean merging master into the topic branch). I am looking for a natural workflow - sometimes mistakes happen because our procedures don't capture a specific situation with simple rules. For example a fix needed for earlier releases should of course be based sufficiently downstream to be possible to merge upstream into all branches necessary (is the usage of these terms clear enough?). However it happens that a fix makes it into the master before the developer realizes it should have been placed further downstream, and if that is already pushed (even worse, merged or something based on it) then the option remaining is cherry-picking, with it's associated perils... What simple rules like such do you use? Also in this is included the awkwardness of one topic branch necessarily excluding other topic branches (assuming they are branched from a common baseline). Developers don't want to finish a feature to start another one feeling like the code they just wrote is not there anymore How to avoid creating merge conflicts (due to cherry-pick)? What seems like a sure way to create a merge conflict is to cherry-pick between branches, they can never be merged again? Would applying the same commit in revert (how to do this?) in either branch possibly solve this situation? This is one reason I do not dare to push for a largely merge-based workflow. How to decompose into topical branches? - We realize that it would be awesome to assemble a finished integration from topic branches, but often work by our developers is not clearly defined (sometimes as simple as "poking around") and if some code has already gone into a "misc" topic, it can not be taken out of there again, according to the question above? How do you work with defining/approving/graduating/releasing your topic branches? Proper procedures like code review and graduating would of course be lovely, but we simply cannot keep things untangled enough to manage this - any suggestions? integration branches, illustration please? Vote and comment as much as you'd like, I'll try to keep the issue page clear and informative enough. Thanks! Below is a list of related topics on stackoverflow I have checked out: What are some good strategies to allow deployed applications to be hotfixable? Workflow description for git usage for in-house development Git workflow for corporate Linux kernel development How do you maintain development code and production code? (thanks for this PDF!) git releases management Git Cherry-pick vs Merge Workflow How to cherry-pick multiple commits How do you merge selective files with git-merge? How to cherry pick a range of commits and merge into another branch ReinH Git Workflow git workflow for making modifications you’ll never push back to origin Cherry-pick a merge Proper Git workflow for combined OS and Private code? Maintaining Project with Git Why cant Git merge file changes with a modified parent/master. Git branching / rebasing good practices When will "git pull --rebase" get me in to trouble?

    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

  • Running rebaseall on Cygwin

    - by Erik Vold
    I tried building node.js on cygwin and that caused errors, so someone in #node.js on freenode told me to run rebaseall on cygwin to clean it up. So I tried that and I got the following message: $ rebaseall rebaseall: only ash or dash processes are allowed during rebasing Exit all Cygwin processes and stop all Cygwin services. Execute ash (or dash) from Start/Run... or a cmd or command window. Execute '/bin/rebaseall' from ash (or dash). So I closed cygwin, went to Start/Run and tried ash and dash but got the following alert: Windows cannot find 'ash'. Make sure you typed the name correctly, and then try again. To search for a file, click the Start button, and then click Search. So what am I supposed to do??

    Read the article

  • Understanding and memorizing git rebase parameters

    - by Robert Dailey
    So far the most confusing portion of git is rebasing onto another branch. Specifically, it's the command line arguments that are confusing. Each time I want to rebase a small piece of one branch onto the tip of another, I have to review the git rebase documentation and it takes me about 5-10 minutes to understand what each of the 3 main arguments should be. git rebase <upstream> <branch> --onto <newbase> What is a good rule of thumb to help me memorize what each of these 3 parameters should be set to, given any kind of rebase onto another branch? Bear in mind I have gone over the git-rebase documentation again, and again, and again, and again (and again), but it's always difficult to understand (like a boring scientific white-paper or something). So at this point I feel I need to involve other people to help me grasp it. My goal is that I should never have to review the documentation for these basic parameters. I haven't been able to memorize them so far, and I've done a ton of rebases already. So it's a bit unusual that I've been able to memorize every other command and its parameters so far, but not rebase with --onto.

    Read the article

  • Routinely sync a branch to master using git rebase

    - by m1755
    I have a Git repository with a branch that hardly ever changes (nobody else is contributing to it). It is basically the master branch with some code and files stripped out. Having this branch around makes it easy for me to package up a leaner version of my project without having to strip out the code and files manually every time. I have been using git rebase to keep this branch up to date with the master but I always get this warning when I try to push the branch after rebasing: To prevent you from losing history, non-fast-forward updates were rejected Merge the remote changes before pushing again. See the 'Note about fast-forwards' section of 'git push --help' for details. I then use git push --force and it works but I feel like this is probably bad practice. I want to keep this branch "in sync" with the master quickly and easily. Is there a better way of handling this task?

    Read the article

  • How to force rebase when same changes applied to both branches manually?

    - by Dmitry
    My repository looks like: X - Y- A - B - C - D - E branch:master \ \ \ \ merge master -> release \ \ M --- BCDE --- N branch:release Here "M - BCDE - N" are manually (unfortunately!) applied changes approximately same as separate commits "A - B - C - D - E" (but seems GIT does not know that these changes are the same). I'd like to rebase and get the following structure: X - Y- A - B - C - D - E branch:master \ * branch:release I.e. I want to make branch:release to be exactly the same as branch:master and fork it from the master's HEAD. But when I run "git rebase master" sitting at the branch release, GIT reports about lots of conflicts and refuces rebasing. How could I solve this? Other explaination of this: I'd like to "re-create" branch:release from scratch from master's HEAD. And there are a lot of other people who had already made "git pull" for the branch:release, so I cannot use git reset + git push -f.

    Read the article

  • Redoing Commit History in GIT Without Rebase

    - by yar
    Since asking my last question which turned out to be about rebasing with GIT, I have decided that I don't want to rebase at all. Instead I want to: Branch Work work work, checking in and pushing at all times Throw out all of those commits and pretend they never happened (so one clean commit at the end of work) I do this currently by copying the files to a new directory and then copying them back in to a new branch (branched at the same point as my working branch), and then merging that into master or wherever. Is this just plain bad and why? More important: Is there a better/GIT way to do this? git rebase -i forces me to merge (and pick, and squash).

    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

  • What are the advantages of a rebase over a merge in git?

    - by eSKay
    In this article, the author explains rebasing with this diagram: Rebase: If you have not yet published your branch, or have clearly communicated that others should not base their work on it, you have an alternative. You can rebase your branch, where instead of merging, your commit is replaced by another commit with a different parent, and your branch is moved there. while a normal merge would have looked like this: So, if you rebase, you are just losing a history state (which would be garbage collected sometime in the future). So, why would someone want to do a rebase at all? What am I missing here?

    Read the article

  • DVCS - What's the downside of rewriting unpublished history?

    - by user1447278
    I was wondering what in particular is the downside of "losing history" in a development process. One famous example is of course git rebase -i / git merge --squash, but also what is described here: http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar under "I want to clean up my commit history prior to submitting my changes to the mainline." I can see that exporting patches and applying them to another branch would lose the "history" of the branch, but why would that branch and its commit history be useful after it has been merged? Can someone elaborate on why such techniques are considered "dirty"? Why does it matter in which order changes were originally committed in the first place as long as they can be applied to the main branch?

    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

facebook twitter digg google delicious technorati stumbleupon myspace wordpress linkedin gmail igoogle windows live tumblr viadeo yahoo buzz yahoo mail yahoo bookmarks favorites email print

1 2  | Next Page >