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.
[git-users] Re: Merging workflow
Ah, so fetch is an operation on the entire repository and merge is an operation on a specific branch? So you're say that 'pull'ing each branch is not necessary because the 'fetch' in 'pull's fetch+merge is redundant. Is that correct? I also don't understand why this is a deficient approach? If each branch is for a bug fix, then wouldn't it make sense to want to be able to work with a branch that has ALL of the bugs fixed? Thanks for your help so far! David On Aug 13, 11:31 am, Konstantin Khomoutov khomou...@gmail.com wrote: On Aug 13, 5:12 am, David Doria daviddo...@gmail.com wrote: [...] Then when I update something in Project1, I just do a |[dor...@localhost AllProjects]$ git pull origin Project1 and AllProjects is now up to date. It's not clear why you need to pull each branch. Note that pull does fetch + merge, so each pull makes Git access the remote and ask for changes. Hence doing multiple pulls in a row would only be sensible if each of your ProjectN branches is hosted in its own remote repository. From your last example, it's appears to not be the case, so you should probably do one fetch followed by multiple merges: $ git fetch origin $ git checkout All $ git merge origin/Project1 $ git merge origin/Project2 ... Is there any standard way to make a script to pull from a whole bunch of projects? Or should I just make a bash script with git pull origin Project1 git pull origin Project2 etc ? To me, it appears that if you want such automation, something is wrong. Having N parallel branches to develop N features and/or fix bugs is perfectly OK, but having a need to periodically merge them _all at once_ appears to be a deficient approach. Usually you should be careful when doing each merge except for no-brainer fast-forwarding cases, and in your setup fast-forwards should be rare. At least, if you will decide to write a shell script doing multiple merges in a row, start it with set -e to make it crash as soon as the current merge command fails due to conflicts. -- 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] Re: Developing Wordpress plugins
On Aug 11, 5:30 am, Daniel Trezub daniel...@gmail.com wrote: I've just started using git last week, and I am still learning a lot. This means I am still messing with my trees a lot, too :) I am trying to mantain a Wordpress website. So I want to use git to keep my wordpress installation up-to-date, as described in this post (http://cad.cx/blog/2010/06/21/svn-is-so-wordpress-2-0-using-git-to-ma...). I am using git in a private and offline repo. At the same time, I am developing mainly two plugins for this site. They are kept in the sub-dirs /plugins/feed and /plugins/site-list. What I did until now is: cd /wordpress git init git add . git commit -m 'wordpress 2.9.2' No problem here, until now. My question is regarding the plugins in development: what is the best way to track them inside this dir using git? I was thinking about making two dev branches, one for the feed plugin and another for the site-list plugin, so I can develop them separatedly. The problem is: I have no idea how I can keep my main wordpress installation up-to-date with the changes in both plugins, once they are tested and commited. I would create two branches: upstream and master. upstream would receive wordpress updates (hence the naming) and only them; master would be based on upstream, would host the plugins and would receive merges from upstream each time it's updated. Something like this: 1) Initial setup: $ git init $ git checkout -b upstream ... roll the wordpress files in $ git add .; git commit -m wordpress X.Y.Z $ git checkout master $ git merge -m Merge wordpress X.Y.Z upstream 2) Hack on plugins (being on master): $ git add ...; git commit; ... 3) When a new wordpress release appears: $ git checkout upstream ... roll the new wordpress files, check if some of them are new and need to be added, some of them disappeared and have to be removed using git- rm etc, so $ git add ...; git rm ...; git commit -m wordpress X.Y.Z+1 $ git checkout master $ git merge -m Merge wordpress X.Y.Z+1 upstream Then go to step (2). If you do not touch wordpress' files while hacking plugins (and you shouldn't) merges are guaranteed to be clean. Such approach is used when maintaining Debian packages in Git using git-buildpackage: you keep the debianisation stuff on master and each upstream release of the software being packaged goes to upstream branch first and is then merged into master. -- 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?
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. DSB -- 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.
[git-users] Re: How to move the master?
On Aug 13, 10:44 pm, David Bruce davidstuartbr...@gmail.com wrote: 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 you will rename branches, as Rick proposed, there's no need to tag the original master's tip. The whole idea of such tagging is just to have a convenient temporary throw-away name. -- 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] Re: Merging workflow
On Aug 13, 7:37 pm, David Doria daviddo...@gmail.com wrote: Ah, so fetch is an operation on the entire repository and merge is an operation on a specific branch? So you're say that 'pull'ing each branch is not necessary because the 'fetch' in 'pull's fetch+merge is redundant. Is that correct? It's a bit more involved: git-fetch can be used to fetch specific objects from a remote repository, but in the most common case it's used without any refspecs on the command line, and in this case Git's behaviour is governed by a special configuration parameter. This parameter is named fetch, and it is autocreated for each remote when you do $ git remote add ... or $ git clone That parameter is set for you to something like +refs/heads/*:refs/ remotes/origin/* (origin is the name of the remote here) which means fetch all remote branches and forcibly update the same-named local branches pertaining to that remote. This default setup makes git fetch remotename bring everything applicable from the specified remote. Of course, you're free to tweak this option to suit your needs but in the general case it just does the right thing. I also don't understand why this is a deficient approach? If each branch is for a bug fix, then wouldn't it make sense to want to be able to work with a branch that has ALL of the bugs fixed? I meant something different. Or course, it's perfectly sensible to merge back to a common branch any bugfixes pertaining to it, but I can't get such accumulate and apply all at once approach. It seems like a quite contrived approach, whch is invented just because it could be invented, and not from a real need. -- 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.
