[git-users] Re: Problem with moving everything into a subdirectory; merge conflicts
Hi Philip, Am 2013-01-06 18:21, schrieb Philip Oakley: Your issue [my mistake] is that the (gits's) merge process is a three way merge, so you have the two commits F and N to merge, but git will also locate the merge-base at M (which has the old directory structure), and compares the diffs between them [M-F] and [M-N] (AFAIKI), so you will get these hundreds (thousands) of renames on that basis, and a great difficulty in (git) trying to decide what to do. Thank you very much for that explanation, it helps me a lot with understanding this! So I'm thinking that it would be useful to have a merge commit, if possible, immediately before the two flag day change commits, and then adjust the level of rename detection (--rename-threshold) on the subsequent merge. (can't remember the default threshold) I had this (a helper merge commit), indeed not strictly immediately before the flag day change commit, but close enough so that I should have recognized if the affected files from the few intermediate commits (between the last merge commit and D) were involved in or responsible for the conflicts. However, it rather looked as if a main source of trouble were a large number of index.html sentinel files: As they all have the exact same contents, it seemed that the rename detection started to associate files at completely different, unrelated paths with each other. Also you could simply try an Ours/Theirs strategy (as appropriate) which would stop git trying to do more than it needs to, given that you will already have carefully made the two tree 'compatible' ;-) which will establish a new merge base for future merges. Ah!! :-) I really should have thought of trying this myself. Using git merge -s ours master worked quickly and without any problems, and created the new merge commit G just as expected. However, I'm unsure if this is the proper solution: Of course, logically I expected that commits F and G have the same tree (as G's only purpose is to serve as a new merge basis), even if G was created with the default merge strategy. The ours strategy does exactly that (refer to same tree in G) quasi on the direct route, per definition. But I wonder if this argument is enough? That is, do I understand correctly that if I had used the default merge strategy, and somehow solved all the conflicts (so that none of the files had been changed from F), the result would have technically been exactly the same? Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de --
[git-users] Asyncronous post-receive
Hi Is it possible to have asynchronous post-receive. I want to run a mirror script which will send a push request to the mirror server. Currently when i do a push to the remote server I have to wait for it push to the mirror server also. Is there a way for post-receive script asynchronously from my push to the remote server --
Re: [git-users] Asyncronous post-receive
On Mon, Jan 07, 2013 at 02:42:46AM -0800, kumar wrote: Is it possible to have asynchronous post-receive. I want to run a mirror script which will send a push request to the mirror server. Currently when i do a push to the remote server I have to wait for it push to the mirror server also. Is there a way for post-receive script asynchronously from my push to the remote server Implementing this has nothing to do with Git -- it's a matter of shell scripting (or of whatever means your post-receive hook is implemented with). For shell scripting, just terminate the command which is to run the code doing your push request with `' rather than plain newline or `;'. The code might be just a single command pipeline, a script executed in a subshell or it might be contained in a separate script file. To demonstrate: 1) Running just one command without waiting it to complete: git push -q $remote $refspec 2) Calling a subshell: ( logger -p daemon.info -t git-server 'About to mirror...' git push -q $mirror $refspec logger -p daemon.info -t git-server Completed; RC=$? ) 3) Calling an external script: `dirname $0`/push-to-mirror Note though that a scheme like this one might be prone to abusing: if the mirror server is slow (say, it's being accessed over a WAN link) anyone with commit access might arrange for performing a long series of pushes of tiny commits leading to creation of several mirror push request processes running concurrently on your server. Since you seem not to care about whether pushing to the mirror server really succeeded or not, probably it's better to arrange for the post-receive hook to just `touch` a flag file in a well-known place and then set up a cron job that will check for the existence of this file, and if it exists, it would push whatever changes available to the remote server and then delete the file. Another way is to `touch` such a flag file before performing a mirror push and remove it afterwards; before attempting a mirror push, the existence of this flag file should be checked, and if the file exists, the push should not be attempted. This would ensure only a single mirror push attempt is active at any given time. --
Re: [git-users] File diff shows up as single line
Fixed the problem with CFBuilder using the File-Convert Line Delimiters to (Windows format). Thanks, Aaron On Wednesday, December 26, 2012 3:06:16 PM UTC-9, Dale Worley wrote: From: Aaron Woehler aaron@alaska.gov javascript: I have two files in my repository that started showing up as single lines. How do I fix this? The files show up fine in Eclipse and other editors. Here is what git-gui shows me. @@ -1 +1 @@ -cffunction name=table_data_inputcfargument name=label required=yescfargument name=bindto required=yes . \ No newline at end of file +cffunction name=table_data_inputcfargument name=label required=yescfargument name=bindto required=yes . \ No newline at end of file *Environment:* Windows 7 Git-gui 0.17.gitgui git 1.8.0.msysgit.0 As the other responder said, it's likely a problem with the line-ending characters. Probably the files have (or are fed to diff with) only 0x0A for line-ending, but diff is expecting 0x0D 0x0A for line-ending. Thus, diff sees no newlines. It may be complicated to determine exactly where the problem is. Find whatever references you can to how Git handles line-endings in text files in different environments. Dale --
Re: [git-users] Re: Problem with moving everything into a subdirectory; merge conflicts
From: Carsten Fuchs carsten.fu...@cafu.de Sent: Monday, January 07, 2013 9:21 AM Hi Philip, Am 2013-01-06 18:21, schrieb Philip Oakley: Your issue [my mistake] is that the (gits's) merge process is a three way merge, so you have the two commits F and N to merge, but git will also locate the merge-base at M (which has the old directory structure), and compares the diffs between them [M-F] and [M-N] (AFAIKI), so you will get these hundreds (thousands) of renames on that basis, and a great difficulty in (git) trying to decide what to do. Thank you very much for that explanation, it helps me a lot with understanding this! So I'm thinking that it would be useful to have a merge commit, if possible, immediately before the two flag day change commits, and then adjust the level of rename detection (--rename-threshold) on the subsequent merge. (can't remember the default threshold) I had this (a helper merge commit), indeed not strictly immediately before the flag day change commit, but close enough so that I should have recognized if the affected files from the few intermediate commits (between the last merge commit and D) were involved in or responsible for the conflicts. However, it rather looked as if a main source of trouble were a large number of index.html sentinel files: As they all have the exact same contents, it seemed that the rename detection started to associate files at completely different, unrelated paths with each other. They do sound like they would give some hassle to rename detection! Also you could simply try an Ours/Theirs strategy (as appropriate) which would stop git trying to do more than it needs to, given that you will already have carefully made the two tree 'compatible' ;-) which will establish a new merge base for future merges. Ah!! :-) I really should have thought of trying this myself. Using git merge -s ours master worked quickly and without any problems, and created the new merge commit G just as expected. However, I'm unsure if this is the proper solution: Of course, logically I expected that commits F and G have the same tree (as G's only purpose is to serve as a new merge basis), even if G was created with the default merge strategy. The ours strategy does exactly that (refer to same tree in G) quasi on the direct route, per definition. But I wonder if this argument is enough? There are two separate issues, one is to create a merge-base (any base) with the new layout (i.e. structure effects), and the second is to ensure you have the right (good-enough) basis (i.e. content) in your merge. Between the two you will then have easy rename detection and easy content merging. Normally structure variations are small, so the normal rename detection heuristic is OK, but in your case that promise wasn't kept. That is, do I understand correctly that if I had used the default merge strategy, and somehow solved all the conflicts (so that none of the files had been changed from F), the result would have technically been exactly the same? Obviously/hopefully your solution to any conflicts would have ended up being an ours choice anyway... Given that you already had a recent merge before the restructuring I would expect that it would be exactl;y the same! Best regards, Carsten --
[git-users] Issue in checking out repo in GIT in eclipse
Hello Guys, ** I have a git repo in my Ubuntu server set up. I want to checkout that repo on my windows machine into eclipse. I have installed EGIT plugin my eclipse. I tried checking importing the files from using the plugin by choosing the URI option in eclipse and got an Unknown Host Exception. These are the setting i gave: 1) URI : user@hostname:/path/to/repo 2) Host : hostname 3) Repository Path : /path/to/repo 4) Protocol :SSH 5) Port : 22 6) user : username 7) pwd : password Is there any place that in need to enter the ip address. The server is on my lan and I can access and work on my repo using putty. What info is missing here. --
[git-users] git push
Hi every one, am kindly requesting for your assistance, i successfully push to a remote branch on my account for the first time( first push where i use git push origin name of the branch) but when am pushing the second or any other time except the first i normally get an error $ git push Enter passphrase for key '/c/Users/kaweesi joseph/.ssh/id_rsa': error: src refspec refs/heads/TRUNK-3814:g...@github.com does not match any. error: failed to push some refs to 'g...@github.com:k-joseph/openmrs-core.git' i have also tried using git push --all and i get $ git push --all Enter passphrase for key '/c/Users/kaweesi joseph/.ssh/id_rsa': Counting objects: 249, done. Delta compression using up to 4 threads. Compressing objects: 100% (79/79), done. Writing objects: 100% (139/139), 24.36 KiB, done. Total 139 (delta 72), reused 99 (delta 45) To g...@github.com:k-joseph/openmrs-core.git 9b76cd3..9e4ba80 TRUNK-3814 - TRUNK-3814 * [new branch] TRUNK-2449 - TRUNK-2449 * [new branch] testing - testing ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'g...@github.com:k-joseph/openmrs-core.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. Check out this branch and merge the remote changes hint: (e.g. 'git pull') before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. So i have always been deleting the remote branch in order to succeed in pushing my changes to a remote branch, i fill this is not the best way to do this Please help me with a git command that i can use to push to a remote branch the second, third or even more time without first deleting the remote branch, thanks all --
