Re: [git-users] Merge+rebase diverged branches
Hi Gergely, On 08/03/14 17:46, Gergely Polonkai wrote: Thank you for your advice, Philip! Table, in this case, is a new major feature in the app, and parts of that feature are already pushed to get feedback, that's why I have pushed commits. We are following (more or less) the GitHub flow, so master always works. Meanwhile these intermediate branches are free to use (although it's strongly advised for its origin side to be mergeable any time). Also, merging with master on the feature branch is somewhat optional until the pull request, but we do it after all bugfix pulls, and most feature pulls. As we do heavy testing, most final pull requests don't affect master too hard (except some accidents, of course). What I finally did, a bit reversing you advise, is this: On branch table $ git branch tmp $ git reset --hard origin/table $ git merge master Fix conflicts, run tests $ git checkout tmp $ git rebase origin/table Fix more commits, run tests, all fine $ git checkout table $ git reset --hard tmp All this, of course on a copy of my repo, all hail git for making it possible :-) Everything seems fine so far, although now that I write this, it would have been a bit shorter with your version, but I can't see how it is less error prone. I would simply do the merge and rebase without any temporary branches: $ git checkout master $ git merge T2 Fix conflicts $ git checkout table $ git rebase # (Assuming master is set to upstream) Fix conflicts This is the usual work flow when working with a main type of branch. BR Gunnar On 3 Aug 2014 17:00, Philip Oakley philipoak...@iee.org mailto:philipoak...@iee.org wrote: *From:* Gergely Polonkai mailto:gerg...@polonkai.eu *To:* git-users@googlegroups.com mailto:git-users@googlegroups.com *Sent:* Sunday, August 03, 2014 2:09 PM *Subject:* [git-users] Merge+rebase diverged branches Hello, I have two branches, master and table, both went through some changes and have their respective tracking brances: M1! - M2! - M3! \ \-T1! - T2! - T3 - T4 commits marked with ! are pushed upstream. I'd like to merge master into table, and rebase my local commits (T3 and T4) on top of the result. How can I do that? I was thinking about saving T4 as a tmp branch, resetting table to origin/table, but here I lost my track, as I don't know how to apply those local commits on my new merge commit. Thanks in advance! I'd start a new new branch at T2! (git checkout -b), then do the merge with master (M3!), and then do a rebase of Table (T3-T4) onto the new tip. However I'm not quite sure how that would fit with your upstream workflow - it depends on how they want to see the intermediate merges (i.e. should master appear to be a first or second parent in the merge record?) Similarly you can rename the various branches to make them all look good (i.e. get the right 'names'. ). The main difference between my approach and yours is that I add extra branches at the mid points while you were reseting to those points (which would be error prone for me ;-) Don't forget to use Gitk (visualisation) and Git Gui (sneak ammending, etc) and any other useful tool to do things by the back door! Philip -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com mailto:git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] effect of git checkout master on master branch
On 02/28/14 09:41, Daniel Hunsaker wrote: All that will happen is that any changes you've made to files git is tracking in the current commit will be reverted. New files will be left intact, as will ignored ones, but deleted files will be restored. Basically, checkout does its best to get you to the exact state described in the commit you specify, which in this case is the commit at the tip of master. If you haven't made any changes since the last checkout, it will do nothing at all. Please correct me if I am wrong, but as far as I can tell using experimentation, checking out master while on master has no effect at all, regardless of whether files are changed, deleted, in the index or not. BR Gunnar On Fri, Feb 28, 2014 at 1:27 AM, dexter ietf dexter.i...@gmail.com mailto:dexter.i...@gmail.com wrote: i'm already on master branch, what's the effect of running the 'git checkout master' while on master branch ? thanks -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] How to setup http protocol for GIT
On 02/25/14 14:16, Konstantin Khomoutov wrote: On Mon, 24 Feb 2014 12:52:05 -0800 (PST) Jirong Hu jirong...@gmail.com wrote: http://git-scm.com/book/en/Git-on-the-Server-Public-Access I was following the above link to setup http access for GIT. But after this issue:https://groups.google.com/forum/#!topic/git-users/nL0qZXiBHqw, I think my http settings are not right. This is what I do: 1. Change the DocumentRoot= /opt/git, since /opt/git/simple.git is the repository I want to access. 2. Created a git.conf in /etc/httpd/conf.d, has the LDAP access information. It works fine. 3. chmod a+x simple.git/hooks/post-update 1. 'x' alone is not enough to execute a program--'r' is needed as well. Though that is true in this context, the statement is a bit misleading since it is not true for programs in general, only for scripts. Binary programs do not need read permissions, only execute permissions: ~$ cp /bin/ls . ~$ chmod a-r ls ~$ ./ls -l ls --wx--x--x 1 gunnar gunnar 106120 Feb 25 15:11 ls BR Gunnar -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Preserving changes locally, and never commit them to anywhere
Hi Oleg, There are probably other better solutions, but one way would be to add a .gitignore file listing the particular file you do not want tracked, and add the .gitignore itself file too. http://git-scm.com/docs/gitignore BR Gunnar On 02/19/14 11:35, Oleg Kosmakov wrote: Hi everyone. My Git experience is somehow basic, so I don't even know which function name I am looking for. My question is as follows: I am working on one public project on GitHub. That project is being developed in Visual Studio *2012*. I am using Visual Studio *2013*. These 2 IDEs are mostly compatible, except the latter adds couple of lines to solution file, thus making it VS2013 file, still preserving compatibility with older versions. My usual working flow is to open the solution (and it will update the solution file), write some code, save changes to my files. Close the IDE. Revert changes to solution file. And commit, at last. Basically, I'd like to remove 2 unneeded steps from my working flow: updating solution file, reverting it back. Is there a way to tell GIT that after upgrading the solution file I don't want it to concider this change as one that needs to be added to the commit? Something like: GIT knows that there are couple of lines in one file that are only used by me and don't need to be commited. Hence IDE won't upgrade this file anymore, and I don't have to revert it each time I commit. Any ideas? Thanks in advance -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Preserving changes locally, and never commit them to anywhere
On 02/19/14 12:31, Gunnar Strand wrote: Hi Oleg, There are probably other better solutions, but one way would be to add a .gitignore file listing the particular file you do not want tracked, and add the .gitignore itself file too. http://git-scm.com/docs/gitignore BR Gunnar On 02/19/14 11:35, Oleg Kosmakov wrote: Hi everyone. My Git experience is somehow basic, so I don't even know which function name I am looking for. My question is as follows: I am working on one public project on GitHub. That project is being developed in Visual Studio *2012*. I am using Visual Studio *2013*. These 2 IDEs are mostly compatible, except the latter adds couple of lines to solution file, thus making it VS2013 file, still preserving compatibility with older versions. My usual working flow is to open the solution (and it will update the solution file), write some code, save changes to my files. Close the IDE. Revert changes to solution file. And commit, at last. Basically, I'd like to remove 2 unneeded steps from my working flow: updating solution file, reverting it back. Is there a way to tell GIT that after upgrading the solution file I don't want it to concider this change as one that needs to be added to the commit? Something like: GIT knows that there are couple of lines in one file that are only used by me and don't need to be commited. Hence IDE won't upgrade this file anymore, and I don't have to revert it each time I commit. Any ideas? Thanks in advance Apologize for the previous top-posting. Well, after a quick search I have to update my answer. You are probably better off adding the file to a global gitignore file so you do not have to add the local gitignore file each time the repo is cleaned or cloned. The following link shows how to set up a personal gitignore file: http://stackoverflow.com/questions/7335420/global-git-ignore BR Gunnar -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Preserving changes locally, and never commit them to anywhere
On 02/19/14 12:56, Thomas Ferris Nicolaisen wrote: On Wednesday, February 19, 2014 12:31:26 PM UTC+1, Gunnar Strand wrote: Hi Oleg, There are probably other better solutions, but one way would be to add a .gitignore file listing the particular file you do not want tracked, and add the .gitignore itself file too. http://git-scm.com/docs/gitignore http://git-scm.com/docs/gitignore Since the file is already tracked in this case, doing a normal ignore will not help. Right, I stand corrected. It even appears to be gitignore 101. After some researching using the normal tools, your suggestion of using assumed-unchanged seems appropriate. I find this an interesting problem, but I have been unable to find any trivial solution. As an alternative, I added the following to a pre-commit hook: git checkout ignoreme git reset HEAD ignoreme This would also solve the problem, but is less elegant than --assume-unchanged. However, a pull after a commit would result in the ignored file to be updated with the upstream changes. But the above test also revealed what I believe is a bug in git. After the pre-commit is executed with git reset, the ignoreme file is still listed as being committed: # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: ignoreme # And adding a commit message results in an empty commit: ign2$ git --no-pager diff HEAD^ HEAD ign2$ I think git should reevaluate the state after the pre-commit hook has been executed, and not create an empty commit unless --allow-empty is given to commit. I've submitted this on the bug list. BR Gunnar -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] Submodules and clobbering history
On 01/29/14 00:16, Eric Reischer wrote: I have a fairly esoteric situation, but I suspect I'm probably not the only one who is attempting to do something along these lines. I have a software product that consists of a number of Git repositories, each with its own group of engineers working on it (think of MATLAB (R) with its plethora of toolboxes). When we deliver software to customers, we ideally would have a superproject that references each repo such that we can just have bare repositories that are delivered (i.e. zip up the superproject after removing all source code), and then on-site the customer runs a program that performs a reset --hard to get all the source code back. Easy enough. (Before everyone asks, it's because the source code occupies several hundred megabytes, so having everything compressed in the repo is convenient for keeping the media count low.) The rub comes in that we do not want our customers to see all of our development history (and our sometimes not-so-professional commit remarks). I've read about a shallow clone (i.e. --depth 1), but it is my understanding these types of repos cannot be used with git-bundle. It does seem to follow everything else though, in that updates that occur upstream (i.e. bugfixes to a major revision) will be successfully applied with a pull or fetch. The other issue is the --depth flag doesn't seem to be supported with the submodule command. Anyone have any thoughts on how to accomplish all this? We did something similar using ClearCase a long time ago. I would separate the development repos from the customer repos. The customer repos would contain snapshots from the development repos, with one patch per release. You would basically be squashing the history to one commit per release for the customers. I would write a release script along these lines: # Assuming dev repos have the same tag for each release from_tag=$1 to_tag=$2 for r in dev repos; do cd $r git diff -p $from_tag $to_tag /tmp/$r-$to_tag.patch cd $r_customer # Go to corresponding customer repo patch -p0 /tmp/$r-$to_tag.patch git add . git commit -m Release notes ... git tag ... done cd $customer_super_repo git add . git commit -m Release notes ... git tag ... # Continue with packing super-repo to customer... BR Gunnar -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] how to Git help me get my changes around the globe compared to SVN?
Hi Oliver, You can set different repos for push and pull for US developers, so that US pull from the read-only US mirror, but pushes to the UK repo. There will be a short delay before the changes are visible in the US mirror if you use the pull strategy as described by Konstantin. git remote set-url --push origin ssh://uk-server/ourproduct.git In .git/config: [remote origin] url = ssh://us-server/ourproduct.git fetch = +refs/heads/*:refs/remotes/origin/* pushurl = ssh://uk-server/ourproduct.git The US mirror should be setup to pull periodically/continuously. This alternative would be similar to the SVN setup you use. We have the above setup when working with Gerrit, except that even the UK office would use a read-only mirror. The mirrors help reduce load on the central server, and clone/fetch times. Pushes are not allowed to the mirrors. BR Gunnar On 12/19/13 14:55, Oliver Harvey wrote: Konstantin - thanks for your reply - fantastic details response! :-) I'll go through in more detail, but wanted to get you a fast basic response first. your last sentance says it all really - ie a single repository with VPN access. However - our main problem is that a large number of changes in the UK will take a long time to get when the US office come on-line (we have lots of HTML etc). With SVN we can configure it to synch a copy to a read-only repo in the US. This can also be configured such that any commits are done to this read-only repo, but are * automatically routed to the main repo in the UK* ...this makes for an easy and fast (for check-out anyway) solution for the US team. Git does not seem to help here... Oli. On Thursday, December 19, 2013 1:35:26 PM UTC, Konstantin Khomoutov wrote: On Thu, 19 Dec 2013 04:42:13 -0800 (PST) Oliver Harvey o...@tigertechsoftware.com javascript: wrote: ...our main requirement is for changes made in the UK available to be available the US for fast/easy check-out (check-in not so important). SVN can crack this either via WanDisco (commercial), or via some master-slave auto-sync thing- -Does Git help us with this at all? - perhaps it makes it *more difficult* by requiring a two-step push?? Hmm, I don't quite get the problem. As you mention pushes, supposedly you imply you have a central repository to which your devs (or whoever else) push changes from their private repos, right? If yes, then what's the problem of making this central rendez-vous repository available to both UK and US offices? Say, by means of a VPN tunnel, a private Git hosting etc. If this is impossible/undesirable for some reason, you can either set up automated *mirroring* by hand or use a ready-made solution (such as that provided by gitolite). The way to implement mirroring depends on whether you want passive (or pull) style, when the US office periodically checks to see if there's anything new in the UK central repo) or active (or push) style, when a post-update hook set in the US shared repository queues a task to push the changes from that repository to the one in the US office. Pull-style mirroring is easy: 1) Create an initial bare mirror clone: us_server$ cd /srv/git us_server$ git clone --bare --mirror ssh://git@uk-server/uk.git 2) Set up a cron job that just `cd`-s to /srv/git/uk.git and runs `git fetch` there. The refspec (the what to fetch specification) set up by the initial clone operation should make `git fetch` grab everything the remote has and update the local stuff with that. Push-style mirroring is harder because you has to compensate for possible case of rapid pushing where someone updates the repo so fast several copies of the post-update script propagating the changes are spawned because they are slow to complete. So some sort of locking or queuing should supposedly be implemented. As to how to do such mirror-push, you just do something like uk_server$ git push ssh://git@us-server '+refs/*:refs/*' where the refspec +refs/*:refs/* tells Git to send all the refs (branches and tags) existing locally to the refs with the matching names on the remote side, creating them if necessary, and also force-updating them if needed (+). Of course, the remote repo must be bare and must accept forced updates (this is the default). Surely, you might opt to do more fine-grained synchronizing by pushing or fetching only a set of selected branches. This will just make your refspecs more involved, and will possibly require you to also use the --tags command-line option. Read the git-fetch and git-push manual pages carefully. To recap, in my opinion, the best option is to just provide direct network access to the single shared repository (or a set of them if
Re: [git-users] how to delete a commit?
Hi, On 12/19/13 09:10, Jagadeesh N. Malakannavar wrote: Hi, May I know how to delete one intermidate commit? For ex: git one line log c4ab7b9 commit 6 a2396a2 commit 5 85020f2 commit 4 8779285 commit 3 4c0b83b commit 2 4498573 commit 1 I want to delete 8779285 commit 3 how to do that? Others have already suggested rebasing, but if you just want to revert the changes made in that commit you can use git revert commit: git checkout c4ab7b9 git revert 8779285 A new commit (7) will be created after commit 6. I have not actually used it personally yet, but I assume this is what Gerrit uses to revert changes. BR Gunnar -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
