Re: [git-users] Is it possible cp some file from one branch to another without switch branch
git checkout B -- somefile On Mon, Dec 17, 2012 at 7:58 AM, lei yang yanglei.f...@gmail.com wrote: Hi expert, now I'm in the branch A, I want to copy some file from branch B to A any help? Lei -- -- Rick DeNatale Google+: +Rick DeNatale https://plus.google.com/10254117893106790 Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale --
Re: [git-users] Process of branching
On Mon, Sep 10, 2012 at 7:25 AM, P Rouleau proulea...@gmail.com wrote: Your steps seem to imply he must use the same new_branch_name in 1) and in 5). We can simplify this by avoiding renaming the master branch. I believe it is already tracking the github's origin. So the steps can be rewritten like this: 1) git branch feature_branch_name 2) git stash 3) git fetch 4) git reset --hard origin/master 5) git push origin feature_branch_name 6) git co feature_branch_name 7) git stash pop First we create a feature_branch_name on the tip of the local master, since it is ahead of the origin's one. Then we stash the local changes and we reset the master branch to the same commit than the origin (3 4). The fetch is required when many developers push to the same remote. (Always use reset with care, since we can loose work. In doubt, create a temporarily branch as a safety net.) Then we create the feature branch on the remote (5). It does not need to be the current branch. Then we switch to the feature branch (6) and we recover the stashed modifications to continue the work on the feature branch. We can skip 5 if we do not want to publish it now and want to add more commits before. After that, we simply push to origin to update it with the new commits, ie: git push. If we commited on many tracked branches but want to push only one, we have to specify the branch name, ie: git push origin branch_name. The problem is he said that he already made 12 commits to master in his local repo. So that stash will only save any uncommitted changes since the last commit. I believe that my suggestion will leave him in the same state as if he had started the branch at the 'right' time in the past. -- Rick DeNatale Google+: +Rick DeNatale https://plus.google.com/10254117893106790 Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Process of branching
OP = Original Poster On Mon, Sep 10, 2012 at 11:59 AM, Łukasz Siwiński lsiwin...@gmail.comwrote: Ok, maybe I've misunderstood his problem. But now I'm sure I really know what does your answer script do , thanks a lot :-) PS: what does mean OP in this context? Pozdrawiam, -- Łukasz Siwiński http://siwinski.info Wysłano z telefonu. 10-09-2012 17:22, Rick DeNatale rick.denat...@gmail.com napisał(a): On Mon, Sep 10, 2012 at 8:55 AM, Łukasz Siwiński lsiwin...@gmail.comwrote: Hmm... Local Repo 12 commits ahead of origin/master means, that You haven't pushed your last 12 commits to remote (@github) origin/master branch if you do: git push # what is the same as git push origin master then You'll see your changes on github. First of all, it's not me it's the OP. and unless I misunderstood him, that's what he DOESN'T want to do. Here's my understanding of his dilemma: First some time ago he fetched master from remote then he made some changes, commited locally, and repeated 11 more times. Now he realizes that before making those changes he should have created a new branch. 10-09-2012 14:14, Rick DeNatale rick.denat...@gmail.com napisał(a): On Mon, Sep 10, 2012 at 7:25 AM, P Rouleau proulea...@gmail.comwrote: Your steps seem to imply he must use the same new_branch_name in 1) and in 5). We can simplify this by avoiding renaming the master branch. I believe it is already tracking the github's origin. So the steps can be rewritten like this: 1) git branch feature_branch_name 2) git stash 3) git fetch 4) git reset --hard origin/master 5) git push origin feature_branch_name 6) git co feature_branch_name 7) git stash pop First we create a feature_branch_name on the tip of the local master, since it is ahead of the origin's one. Then we stash the local changes and we reset the master branch to the same commit than the origin (3 4). The fetch is required when many developers push to the same remote. (Always use reset with care, since we can loose work. In doubt, create a temporarily branch as a safety net.) Then we create the feature branch on the remote (5). It does not need to be the current branch. Then we switch to the feature branch (6) and we recover the stashed modifications to continue the work on the feature branch. We can skip 5 if we do not want to publish it now and want to add more commits before. After that, we simply push to origin to update it with the new commits, ie: git push. If we commited on many tracked branches but want to push only one, we have to specify the branch name, ie: git push origin branch_name. The problem is he said that he already made 12 commits to master in his local repo. So that stash will only save any uncommitted changes since the last commit. I believe that my suggestion will leave him in the same state as if he had started the branch at the 'right' time in the past. -- Rick DeNatale Google+: +Rick DeNatale https://plus.google.com/10254117893106790 Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- Rick DeNatale Google+: +Rick DeNatale https://plus.google.com/10254117893106790 Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- Rick DeNatale
Re: [git-users] Process of branching
On Sun, Sep 9, 2012 at 12:53 PM, Patrick pn1.d...@gmail.com wrote: Local Repo 12 commits ahead of origin/master How do I take those 12 commits and pull them off on a branch? I haven't tried this completely but since you haven't pushed the branch,I think something like 1) git branch -m master new_branch_name 2) git fetch origin 3) git branch --track master origin/master 4) git checkout master 5) git branch -f new_branch_name master 6) git config branch.new_branch_namel.merge refs/heads/new_branch_name 7) git checkout new_branch_name 8) git push origin new_branch_name:refs/heads/new_branch_name First we give the local master branch the new name (1). Then we make sure we have the latest changes from master (2). Then we create a new local master branch which tracks the remote master (3). We then checkout the master branch(4) to allow us to set the starting point of the new branch(5) Next we tell the new branch to merge changes to the right branch on origin (6) Note this remote branch won't exist yet. Finally we checkout the new local branch(7) and push it to the remote repo. -- Rick DeNatale Google+: +Rick DeNatale https://plus.google.com/10254117893106790 Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] git checkout file silently fails
On Tue, Sep 4, 2012 at 3:44 PM, Philip Oakley philipoak...@iee.org wrote: If both cases of checking out a path you are expected to provide a tree-ish, not a branch. The git glossary says that a tree-ish is a commit, tree, or tag - nothing about a branch. A branch name is perfectly suitable to use as a treeish. A branch is really just in effect a variable pointer to a commit. http://www.scribd.com/doc/65739673/12/The-Treeish#outer_page_41 et. seq. (see page 42) -- Rick DeNatale Google+: +Rick DeNatale https://plus.google.com/10254117893106790 Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: getting the tag corresponding to a git commit
On Sun, Jan 29, 2012 at 2:57 PM, Thomas Ferris Nicolaisen tfn...@gmail.comwrote: Hi Kevin, git tag --contains [commit-id] This doesn't do the job exactly though, it will list any tags whose corresponding commit is either the named commit, or one of its parents. So if we have a history (linear here to simplify, with parents to the left and children to the right a(v0.1) b c d(v1.1) e Then git tag --contains x will return v0.1 AND v1.1 if x is d or e and v0.1 if x is any of a, b, or c. Note that not ever commit has a tag. -- Rick DeNatale Google+: +Rick DeNatale https://plus.google.com/10254117893106790 Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Git source code for productivity measurement, using semi-auto half-hourly commits.
http://en.wikipedia.org/wiki/Galley_slave On Thu, Sep 8, 2011 at 7:42 AM, Clive Crous clive.cr...@gmail.com wrote: Hi Everyone, I work for a company as a developer and got an email from management this morning and would just like to cloud-source some opinions. Trying to keep this question as unbiased as I can, but I'd really like some feedback, thanks: The company I work for sent out an email this morning instructing us to, from now on, commit all source code changes for whatever we're currently working on and push (to central company git repository), regardless of the progress, status or state every half-an-hour so that they see the changes being made and can monitor productivity. Thoughts on this? Thank you, Clive -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Security experts from Cyberoam, Novell, Wipro, IBM all at one place @Security Conf (April 9th, Mumbai)
On Wed, Mar 30, 2011 at 12:19 AM, Kavya Shree kavya.jingade.shre...@gmail.com wrote: SiliconIndia is 12-year old media firm. We publish two technology business magazines—one in the U.S and the other in India. Over the last one decade, SiliconIndia.com has emerged as the most trusted source for news and information for professionals. Which was no doubt achieved by spamming new-groups with irrelevant posts. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: Output from push
On Fri, Dec 10, 2010 at 3:46 AM, Konstantin Khomoutov khomou...@gmail.com wrote: On Nov 24, 2:20 pm, Roddie Grant gitl...@myword.co.uk wrote: [...] To make things simpler to grok, you can think of all those three types of objects as being plain text files. Playing with `git ls-tree` and `git cat-file` can give a very clear idea about how objects reference one another. Thanks Konstantin, that's very helpful. I'm still trying to conceptualise how Git works, and your reply has filled in a few gaps. I recently came across this paper [1] which you may find useful as it tries to explain Git on the object level, showing the precise steps Git performs to create a new commit. I've spotted one minor deficiency in the article so far (there's no such thing as the HEAD of the current branch as Git maintains just one HEAD ref) Not exactly. .git/HEAD contains an indirect reference to a git ref so, if I'm working on the branch foo $cat .git/HEAD ref: refs/heads/master $ls .git/refs/heads foo master so there's a heads ref for each branch known to my 'client' machine $cat .git/refs/master 0407dee585688b08aecdd27ff33bcea81d8422a5 $cat .git/refs/foo 249599f642b50ffc2dd0fcd1f4716b8fc89e5633 These are the sha hashes of the last commit on each of the branches. When you do a commit, git uses the ref pointed to by the refs file pointed to by HEAD as the base for the commit, i.e. what to use to diff against to determine what has changed. At the end of the commit the ref is updated with the new SHA. In the case of a detached head, for example if you checkout using a SHA rather than a branch or tag then the contents of .git/HEAD will simply be that SHA. In this case git doesn't know what branch you are on, in fact that commit may appear on more than one branch or no branch at all. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: Output from push
On Fri, Dec 10, 2010 at 11:14 AM, Konstantin Khomoutov khomou...@gmail.com wrote: The idea is that the HEAD is a distinguished reference, which is used to point to the commit object on which the work tree is based, and it has no inherent relation to the notion of the current branch. Actually .git/HEAD is exactly where git stores the notion of the curent branch if it contains something like ref: refs/heads/master Then the current branch is master If it just contains a sha then HEAD is detached and there IS no current branch. Which was my point. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] getting a list of branches
On Tue, Aug 24, 2010 at 2:24 PM, Ted cecinemapasdera...@gmail.com wrote: Is there some way to specifically get a list of branches, without the annotation that `git branch` normally adds? I'd like to write a script that loops over branches, but it shouldn't be dependent on the presentation format. ls -1 .git/refs/heads Note that it's dash one, not dash ell -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: How to move the master?
On Thu, Aug 12, 2010 at 1:09 PM, jd chima...@gmail.com wrote: On Aug 12, 3:18 am, Konstantin Khomoutov khomou...@gmail.com wrote: That's because you created a situation known as detached HEAD. How can I fix this? I want master to point to the same place as HEAD. Record the name of the commit HEAD points at, checkout master and hard reset it to that commit. The simplest way to do that is via a branch or tag: $ git tag foo $ git checkout master $ git reset --hard foo $ git tag -d foo Thank you for the help, that seems to have fixed the problem. One question: why is the git checkout master needed? (What would have happened if I had done the hard reset when the detached head was checked out?) Note that there is a HEAD for each branch, it points to the commit at the tip of that branch. The command git reset changes which commit HEAD points to for the current branch. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: How to move the master?
On Fri, Aug 13, 2010 at 2:44 PM, David Bruce davidstuartbr...@gmail.com wrote: Hi, Along these lines, we are in a somewhat similar situation. Basically, we have had a major feature branch for a GSoC project, and this branch has now substantially diverged from master. However, the divergence is almost completely due to equivalent work that was done first in master, and then re-done by hand in the feature branch because it was too hard to merge (we are git noobs). So, we want to make master point to the new branch, and rename master to something like old_master for safekeeping. So it looks like we should first create a branch (or tag) to save the tip of master, and then hard reset master to the tip of the feature branch. If it's just a local repository (probably not) you can just rename the branches, I'll use the branch name dev_branch to stand in for your feature branch: git branch -m master old_master git branch -m dev_branch master If the branches are remote you should be able to rename and end up with tracking branches with something like this: First rename the current master branch git push origin master:refs/heads/old_master Create the branch old_master in the origin repository by copying the current master branch. git fetch origin Fetch updates from the remote repository git branch --track old_master origin/old_master create a tracking branch git checkout old_master git push origin :refs/heads/master Delete the remote master branch, remember that a branch is just a pointer to a commit, and deleting it doesn't delete the commit or any other commits git branch -d master Delete the local master branch Now rename the dev_branch to be the new master branch: git checkout dev_branch git push origin master:refs/heads/dev_branch git fetch origin git branch -track master origin/master git checkout master git push origin :refs/heads/dev_branch git branch -d dev_branch The last two steps (which delete the remote and local dev_branch are optional) There may be more efficient ways to do this. I use the grb ruby gem to handle tasks like this and this is how it approaches renaming a remote branch. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: help - pushes not reflected on remote origin
On Fri, May 7, 2010 at 11:31 AM, Matt Palermo mpale...@vt.edu wrote: Okay, maybe someone can give me advice for the best way to accomplish this... I have a team of developers (myself included) for a PHP website. I also have a design team. On the main webserver I want to setup the live site where all tested code will go. Then for each developer on the team, I want to have another site on the server where that developer can work and we can all see his development in progress. The design team will also have their own site on the server. So it would be something like this: - Server http://site.com/live (live site with only tested/approved code) http://site.com/dev1 (test site for developer 1, which is a clone of the live site) http://site.com/dev2 (test site for developer 2, which is a clone of the live site) http://site.com/design (test site for design team, which is a clone of the live site) So the way I've tried to implement it is this... Setup a main bare repo. Then have clones of the main repo for live, dev1, dev2, design all in their respective webroot folders. Then let's say dev1 makes a change that is tested and ready to go live... I will go to the server into the dev1 repo and push it to the main repo. Then I will go to the live repo and pull the changes to it. All devs will be able to clone their server dev repo to their local machine and work from there. However, I want their server dev repo to be as current as possible so that I can go to the server site for them and see the latest changes. So if developer 1 makes changes on his local clone, then he will commit the changes and push them to the server dev repo so that the entire team can view the changes on the server site. The problem I'm running into is that when the dev pushes commits to the server, the server dev repo working files/folders don't reflect the changes that were pushed to it. Therefore I can visit the dev1 site after a commit was pushed to it and it will look/work the same as before the push. I need to always keep the dev sites current with the latest changes. Should I be doing something different in my workflow? Does anyone have any advice on setting up a system to work this way? Thanks, Matt Why are you pushing from the server(s). I'd set up a main git repository somewhere, probably on github. Have the developers clone this and push changes, use branches to control production vs. staging. Then to deploy to a server have it checkout a specific branch and pull. I don't know about php apps, but this is the way things are normally done with Rails. Most Rails developers use a tool named capistrano to deploy, which has recipes for fetching code from git, rolling back changes... There's probably something similar for php apps. As a matter of fact it appears that some folks are using capistrano for php deployment http://www.google.com/search?q=capistrano+deploy+php Having a separate staging server for each developer seems to be overkill to me, most of the projects I've worked on have the developers run code on their own development machines, and one staging server where code not ready for production can be deployed for manual acceptance testing, or review or ... But I guess there's no reason why you couldn't do that. HTH -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Fixing up a branch on a stale branch point
On Thu, Apr 15, 2010 at 6:45 PM, Charles Manning mannin...@actrix.gen.nz wrote: On Friday 16 April 2010 01:15:42 Rick DeNatale wrote: On Thu, Apr 15, 2010 at 12:59 AM, Charles Manning mannin...@actrix.gen.nz wrote: Hi All I have an issue that I think I can resolve in a messy way, but I suspect there has to be a cleaner way to do this too. On one computer I have master, plus a branch with some work on it. Let's call that branch B. On a different computer I made a change and pushed that to the shared repository. Now I want to go back to the first computer, pull the changes so that master reflects the current shared repository. That would put master ahead of the branch point, but I want to have those changes viewed in branch B too. Ideally there would be some way to rip a branch off and re-graft it on to a different branch point. It seems I could do something like -- Starting on branch B -- git commit -m B work in progress git checkout master git pull git branch B-continued git checkout B-continued git merge B git branch -d B -- Continue working on B-continued-- If I understand what you are asking I think it's just - Starting on Branch B git commit -m'B work in progress' git checkout master git pull git checkout B git merge master -- continue working on B I did some reading last night. It looks like the following would do what I want: -starting on B - git commit -m B work in progress git checkout master git pull git checkout B git rebase master B Be careful, you don't want to rebase a branch which you have already pushed, or it will wreak havoc for other users. If you HAVE pushed branch be then you should merge master into it to pick up changes from master instead of rebasing it. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Github: http://github.com/rubyredrick Twitter: @RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] How do you exclude files from being merged by git pull, push etc?
Is this what you are looking for? http://www.gitready.com/beginner/2009/01/19/ignoring-files.html On Wed, Mar 31, 2010 at 10:07 AM, vfclists vfcli...@googlemail.com wrote: I have come to one of my main reasons for using git. I am creating an app which is being customzied for users. The idea is that the main non UI code is constant, the same across all customized versions, but with the customized versions, the UI will will different, some options will be disabled etc, and some of the functions in the non UI libraries will never be called at all, although they will be there for consistency's sake. So after creating branch, how do I configure it to exclude some files from being merged or updated from the mainline version. In other words it will be akin to having the working directory made up files from 2 or more branches in the remote repositories, and pushes and pulls will know which files goes where or comes from. I am sure git probably allows this in its feature set, but I am yet to know the right configuration. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: How do you exclude files from being merged by git pull, push etc?
On Wed, Mar 31, 2010 at 12:11 PM, vfclists vfcli...@googlemail.com wrote: On Mar 31, 4:20 pm, Rick DeNatale rick.denat...@gmail.com wrote: Is this what you are looking for? http://www.gitready.com/beginner/2009/01/19/ignoring-files.html Using .gitignore is something I have considered, but it looks like it is going to get more interesting than that. I will probably have to use separate directories, and use some kind of condititional excludes or includes if .gitignore supports something like that. Does checking out a branch erase all the directories and files in the working directory and replace them with only the contents of the branch? Only files which are tracked will be affected by a checkout. Files don't get tracked until you git add them. .gitignore is a way to keep new files from being tracked. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: git const branch
On Fri, Nov 27, 2009 at 1:00 PM, Konstantin Khomoutov khomou...@gmail.com wrote: On Nov 26, 11:23 am, itroot ivan.tolstoshe...@gmail.com wrote: Some branches in git are tracking another branches (for example, usually master tracks origin/master). Let's assume, that in my work- flow i don't want accidentally commit in master, but i want master to track origin/master. I release that i can do this with hooks, but this solution seems to me complicated. Can i make some git branches const? I think you can not, but until you have pushed the branch with wrongly applied commits you can easily revert these wrong changes using `git reset -- hard ...`, so the absence of immutable branches is not a big loss. On the other hand, Git already includes certain things which are there mostly for convenience, so why not. In either case, you should suggest your idea on the official Git mailing list, not here. I think that by definition a branch is a movable pointer to a commit, so a const branch is a bit of an oxymoron. The concept for a fixed pointer to a commit is called a tag. If I want to mark a point I might want to get back to, such as the commit corresponding to a current release, the I tag it and push the tag. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: git const branch
On Fri, Nov 27, 2009 at 1:58 PM, Konstantin Khomoutov khomou...@gmail.com wrote: On Nov 27, 9:51 pm, Rick DeNatale rick.denat...@gmail.com wrote: Some branches in git are tracking another branches (for example, usually master tracks origin/master). Let's assume, that in my work- flow i don't want accidentally commit in master, but i want master to track origin/master. I release that i can do this with hooks, but this solution seems to me complicated. Can i make some git branches const? [...] I think that by definition a branch is a movable pointer to a commit, so a const branch is a bit of an oxymoron. The concept for a fixed pointer to a commit is called a tag. If I want to mark a point I might want to get back to, such as the commit corresponding to a current release, the I tag it and push the tag. Good point, but there's one exception: you can't fast forward a tag, while this is often the sole reason for the existance of the master branch as a mirror of origin/master. But then again, to fast forward a branch it must not be immutable ;-) You can't fast forward, or merge to, a tag because it is a constant pointer to a given commit. Which is what the OP seemed to be asking for. Q.E.D. -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] How to copy a complete remote repository to another one
Heres my situation. I'm working on a project for a client, company C and gradually taking over from another company, company B which was doing this project. It's a peaceful transition. Until now the main repo has been on github in a private repo under company B's account, let's call this repo B We want to set up a complete copy of this repo, complete with all branches, tags, etc. to another private github repo which is owned by company C, I'll call this repo C Company B first thought that all that we needed to do was to create the new repo on Github, as a fork of the original one. Unfortunately this didn't pickup all of the branches etc. So we deleted repo C, and created a new empty one, and then tried to use git push --mirror repo_c from a machine with a local repo which had been attached to repo B But looking at the repo either through git or the github web interface I only see a few branches, apparently those which were known locally. So is there an easy way to copy the complete contents of one remote git repo to another, with all branches, tags, and commit history. Alternatively is there an easy way to fetch/pull all branches and tags from one remote before git push --mirror to another? -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/git-users?hl=en -~--~~~~--~~--~--~---
[git-users] Re: help for losed files after git commit.
On Thu, Sep 10, 2009 at 12:22 AM, QTchyi@gmail.com wrote: git checkout branch_1 git checkout head; git add file_1; git commit -a -mprepare to add init(); So you commited it to branch_1 git checkout master. And now you've checked out the master branch. It seems my commit of add file_1 is disappeared. Can I find it? It should be on the branch git checkout branch_1 and the file should be in your working set. Now if you want to merge the changes back to master: git checkout master git merge branch_1 -- Rick DeNatale Blog: http://talklikeaduck.denhaven2.com/ Twitter: http://twitter.com/RickDeNatale WWR: http://www.workingwithrails.com/person/9021-rick-denatale LinkedIn: http://www.linkedin.com/in/rickdenatale --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/git-users?hl=en -~--~~~~--~~--~--~---
