Re: bug: autostash is lost after aborted rebase
The bug still persists when you abort the rebase by using :cq in Vim (exit with an error code). See also http://stackoverflow.com/q/37252108/244297 -- View this message in context: http://git.661346.n2.nabble.com/bug-autostash-is-lost-after-aborted-rebase-tp7611141p7656556.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
deadlock git upload-pack command when GIT_TRACE is enabled
Hello, I stuck around the deadlock inside git when running git upload-pack . command. A debugging shown that the bottom process (it starts several processes to implement the task) hangs writing to stderr. I managed to reproduce the issue with a tiny bash script. The repository and the script is found here https://github.com/jonnyzzz/git-upload-pack-deadlock I saw the issue reproducing both under Windows and Linux/Mac. Windows thread dumps are available here https://github.com/jonnyzzz/git-upload-pack-deadlock/tree/master/debug According to those thread dumps I see the following problem around upload-pack.c line 129. There the pack_objects command is executed. First the wants block is pushed to the command, next the stdout processing is started. This means, that pack_objects process output is not processed until all output is put there. In the case I have, the pack_objects process writes TRACE logging into stderr and eventually (on hug repo) the OS buffer runs-out deadlocking the execution. Best regards, Eugene Petrenko -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: About checkout with untracked files on remote.
I have specific case which you can use to improve git. My example: I have 2 branches - master, implement_button. Branch implement_button add some button with few style.css and fonts files. Both branches have same git ignore file where all fonts and css folders with files ignored. The point: Now my active branch is implement_button. 1 Try to checkout to remote master branch and get error: error: The following untracked working tree files would be overwritten by checkout: css/style.css css/fonts/RobotoSlab-Bold-webfont.eot Please move or remove them before you can switch branches. Aborted. So we have case where master haven’t new ignored files. We can’t use git clean -df bc it not clean untracked files. Bc implement_button branch it is not untracked. I can’t use git clean -dfx» bc i need some another ignored files. I can’t use force checkout bc i need this files be deleted. Also i can’t get this error without run checkout, so or i will be checkout or error. Dry-run not work for this command. http://stackoverflow.com/questions/28714372/how-to-catch-git-error-on-checkout-without-checkout/28714462#28714462 So i need help understand how i can do this? Parse rendered error to get the list of files to drop and drop them? Hope i can do this in another way =) P.S. Thank you very much for try help me =)-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Wed, Oct 30, 2013 at 11:54 PM, Junio C Hamano gits...@pobox.com wrote: Eugene Sajine eugu...@gmail.com writes: That was my initial intention, because I would like to be able to pass parameters like to git log or git blame correctly without the explicit use of $1. Could you please advise about how to make it work with the !sh -c ? Because the same exact (sed 's/@\\S*//') syntax didn't work with sh -c. You can make it work if you think step-by-step. First, this is what you want to run: sh -c 'git log --format=... $@ | sed s/@\S*//' - so that git euguess master..next would turn into sh -c 'git log --format=... $@ | sed s/@\S*//' - master..next Now, you want to wrap it into an alias, i.e. [alias] euguess = !sh -c ... That ... part is read by our configuration reader, so you need to quote the double quotes and backslashes with backslash, which would give you something like: [alias] euguess = !sh -c 'git log --format=\%h %ae %s\ --date=short \$@\ | sed \s/@\\S*//\' - Junio, Thanks for taking the time - I appreciate that a lot. It does work properly now except there is some difference between the required pathnames: when i'm in a subfolder in git repo i can say git log filename But it seems that if the alias is used i need to specify full path from the root of the repo no matter where i am. git log a/b/c/filename the difference is obviously in the working directory when i add an alias: pd = !sh -c 'pwd' i get this: $ git pd /home/users/euguess/repo $ pwd /home/users/euguess/repo/a/b/c Is there any way to help that situation? Thanks, Eugene Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Thu, Oct 31, 2013 at 2:15 PM, David Aguilar dav...@gmail.com wrote:
On Thu, Oct 31, 2013 at 11:07:19AM -0700, Junio C Hamano wrote:
David Aguilar dav...@gmail.com writes:
A-ha.. I think adding the chdir to alias is possible using a function.
You do not have to use a function to do so, no?
Right, of course.
So something like:
[alias]
example = !cd ${GIT_PREFIX:-.} git log \$@\
should do the trick.
--
David
Awesome! It does work!
One note: i tried the ${GIT_PREFIX:-.} and ${GIT_PREFIX} and it seems
to give the same results. What is the expected difference here?
Thank you!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Thu, Oct 31, 2013 at 3:41 PM, Junio C Hamano gits...@pobox.com wrote:
Eugene Sajine eugu...@gmail.com writes:
One note: i tried the ${GIT_PREFIX:-.} and ${GIT_PREFIX} and it seems
to give the same results. What is the expected difference here?
GIT_PREFIX may be an empty string when you run from the top-level,
in which case you would end up with cd ... and end up working
in your $HOME.
got it! thank you!
Eugene
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Help creating git alias
Hi, I need some advice about creating the git command alias: I have this as the command: git log --pretty=format:%h %ad %ae %s --date=short | sed 's/@\S*//g' The purpose is to cut off the email domain and keep only username. I'm trying to create this as the alias: lg = !sh -c 'git log --pretty=format:%h %ad %ae %s --date=short | sed 's/@\S*//g'' - but it complains about the \S and i'm failing to come up with the escape sequence to make it work right. I know i can work around that by creating shell alias, but it is not what i would like to have. Any ideas? Thanks! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Wed, Oct 30, 2013 at 3:47 PM, Andrew Ardill andrew.ard...@gmail.com wrote: Have you tried backslash escaping the backslash? double escaping? I don't know how many are required, but I would try first \S, then \\S, then S, etc Regards, Andrew Ardill When i do that it stops understanding \S* as regexp so it removes only @, while i need to remove from @ to the next whitespace Thanks, Eugene On 30 October 2013 12:34, Eugene Sajine eugu...@gmail.com wrote: Hi, I need some advice about creating the git command alias: I have this as the command: git log --pretty=format:%h %ad %ae %s --date=short | sed 's/@\S*//g' The purpose is to cut off the email domain and keep only username. I'm trying to create this as the alias: lg = !sh -c 'git log --pretty=format:%h %ad %ae %s --date=short | sed 's/@\S*//g'' - but it complains about the \S and i'm failing to come up with the escape sequence to make it work right. I know i can work around that by creating shell alias, but it is not what i would like to have. Any ideas? Thanks! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Wed, Oct 30, 2013 at 3:57 PM, Ralf Thielow ralf.thie...@gmail.com wrote: lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g' should work. It did! thanks! I didn't know that !sh -c is not needed On Wed, Oct 30, 2013 at 8:34 PM, Eugene Sajine eugu...@gmail.com wrote: Hi, I need some advice about creating the git command alias: I have this as the command: git log --pretty=format:%h %ad %ae %s --date=short | sed 's/@\S*//g' The purpose is to cut off the email domain and keep only username. I'm trying to create this as the alias: lg = !sh -c 'git log --pretty=format:%h %ad %ae %s --date=short | sed 's/@\S*//g'' - but it complains about the \S and i'm failing to come up with the escape sequence to make it work right. I know i can work around that by creating shell alias, but it is not what i would like to have. Any ideas? Thanks! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Wed, Oct 30, 2013 at 5:02 PM, Junio C Hamano gits...@pobox.com wrote: Eugene Sajine eugu...@gmail.com writes: On Wed, Oct 30, 2013 at 3:57 PM, Ralf Thielow ralf.thie...@gmail.com wrote: lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g' should work. It did! thanks! I didn't know that !sh -c is not needed sh -c is often used when you pass arguments to your scriptlets, e.g. to allow git lg master..next you would want sh -c 'git log ... $@ | sed ...' - so that git lg master..next turns into sh -c 'git log ... $@ | sed ...' - master..next which makes $1=master..next and fed to git log. Junio, That was my initial intention, because I would like to be able to pass parameters like to git log or git blame correctly without the explicit use of $1. Could you please advise about how to make it work with the !sh -c ? Because the same exact (sed 's/@\\S*//') syntax didn't work with sh -c. Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Fwd: git-daemon access-hook race condition
For now I'm trying to do the following: access-hook.bash has: delayed-notify.bash $@ delayed-notify.bash has: sleep 10 ... curl ... I'm expecting access-hook to spawn new process and return without waiting for it to finish to let the service to do its job. But when i do push - it sleeps for 10 seconds anyway. Am i missing something obvious here? Any help is much appreciated! Thanks, Eugene I found a following solution to make it happen while waiting for somebody to be generous enough to take on the --post-service-hook (unfortunately i'm not a C guy): It is using 'at' command. The access-hook script has: echo delayed-notify.bash $@ | at now while delayed-notify.bash has: sleep 10 curl ... This is not perfect and in certain situations can still fail because the delay is not long enough but this will at least resolve 90% of issues. I hope that might be helpful for someone. Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: git-daemon access-hook race condition
Hi, We are serving repos in closed netwrok via git protocol. We are using git-daemon access hook (thank you very much for such a great feature) in order to create push notifications for Jenkins. I.e. upon the push the access-hook is called and then the curl command is created and executed. As we have several instances of Jenkins, that we need to notify (three), the execution of the access-hook can take some time. Sometimes we have a situation when the whole chain works fine but Jenkins git plugin doesn't recognize the changes. I think it happens because we hit a kind of race condition: 1. Incoming push triggers access-hook 2. notify jenkins 1 3. notify jenkins 2 4. jenkins 1 polls repo but sees no changes 5. notify Jenkins 3 6. the push data transfer finishes - consequent pushes will find changes w/o any problem The question is: Is there a way to avoid that? Is it possible to have access-hook to be executed after receive? Is it possible to introduce a parameter that would specify if it needs to be executed before receive or after? Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: Fwd: git-daemon access-hook race condition
On Thu, Sep 12, 2013 at 3:15 PM, Junio C Hamano gits...@pobox.com wrote: Eugene Sajine eugu...@gmail.com writes: Is it possible to have access-hook to be executed after receive? The whole point of access-hook is to allow it to decide whether the access is allowed or not, so that is a non-starter. A notification _after_ successful push update is usually done via the post-receive hook in the receiving repository, I think. Junio, Thanks for the reply! This is interesting: i always thought about the access-hook as something to be executed when the repo is accessed, not just verification if access is allowed - your definition is much more limiting. we have about 1400 bare repos - so i would like to avoid the configuration of each one of them. I could probably find a way to automate it, but already having access-hook in current implementation makes me reluctant to go this way, because it is so much easier to use centralized manager. So are you really sure that it is a non-starter to have --before-service/--after-service options for access-hook? Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Fwd: git-daemon access-hook race condition
Junio, Thanks for the clarification! Your solution does look better. For now though i think i will have to delay the notification somehow and let the service finish first then notify the server. Thanks again! Eugene On Thu, Sep 12, 2013 at 5:08 PM, Junio C Hamano gits...@pobox.com wrote: Eugene Sajine eugu...@gmail.com writes: So are you really sure that it is a non-starter to have --before-service/--after-service options for access-hook? Given the definition of --access-hook in git help daemon: --access-hook=path:: Every time a client connects, first run an external command specified by the path ... The external command can decide to decline the service by exiting with a non-zero status (or to allow it by exiting with a zero status) There is *NO* way in anywhere --after-service makes any sense (and by definition --before-service is redundant). What you _could_ propose is to define a *new* hook that is run when the spawned service has returned, with the same information that is fed to the access hook (possibly with its exit status). I do not offhand know if we retain the original service information that long after the main daemon process has spawned the service process, though. With the current system, the only thing it needs to know is the PID of the service processes that are to be culled by calls to waitpid(). So you may have to extend existing bookkeeping data structures a bit to keep those pieces of information around if you wanted to add such a new hook. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Fwd: git-daemon access-hook race condition
On Thu, Sep 12, 2013 at 5:16 PM, Eugene Sajine eugu...@gmail.com wrote: Junio, Thanks for the clarification! Your solution does look better. For now though i think i will have to delay the notification somehow and let the service finish first then notify the server. Thanks again! Eugene On Thu, Sep 12, 2013 at 5:08 PM, Junio C Hamano gits...@pobox.com wrote: Eugene Sajine eugu...@gmail.com writes: So are you really sure that it is a non-starter to have --before-service/--after-service options for access-hook? Given the definition of --access-hook in git help daemon: --access-hook=path:: Every time a client connects, first run an external command specified by the path ... The external command can decide to decline the service by exiting with a non-zero status (or to allow it by exiting with a zero status) There is *NO* way in anywhere --after-service makes any sense (and by definition --before-service is redundant). What you _could_ propose is to define a *new* hook that is run when the spawned service has returned, with the same information that is fed to the access hook (possibly with its exit status). I do not offhand know if we retain the original service information that long after the main daemon process has spawned the service process, though. With the current system, the only thing it needs to know is the PID of the service processes that are to be culled by calls to waitpid(). So you may have to extend existing bookkeeping data structures a bit to keep those pieces of information around if you wanted to add such a new hook. For now I'm trying to do the following: access-hook.bash has: delayed-notify.bash $@ delayed-notify.bash has: sleep 10 ... curl ... I'm expecting access-hook to spawn new process and return without waiting for it to finish to let the service to do its job. But when i do push - it sleeps for 10 seconds anyway. Am i missing something obvious here? Any help is much appreciated! Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: Fwd: git-daemon access-hook race condition
On Thu, Sep 12, 2013 at 6:20 PM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Eugene Sajine eugu...@gmail.com writes: So are you really sure that it is a non-starter to have --before-service/--after-service options for access-hook? Given the definition of --access-hook in git help daemon: --access-hook=path:: Every time a client connects, first run an external command specified by the path ... The external command can decide to decline the service by exiting with a non-zero status (or to allow it by exiting with a zero status) There is *NO* way in anywhere --after-service makes any sense (and by definition --before-service is redundant). What you _could_ propose is to define a *new* hook that is run when the spawned service has returned, with the same information that is fed to the access hook (possibly with its exit status). Scratch that exit status part, as I do not think it is useful. To a receive-pack and a send-pack that is talking to it, if a push results in a failure, it is a failure. Likewise for upload-pack and fetch-pack for a transfer in the reverse direction. And the way that failure is communicated from the receive-pack to the end-user via the send-pack is for the receive-pack to send a protocol message that tells the send-pack about the failure, and the send-pack showing the error message and signalling the failure with its exit status. Likewise for upload-pack and fetch-pack (hence fetch, which is conceptually a thin wrapper around it). Between the deamon and the receive-pack (or the fetch-pack) process, however, such a failed push (or fetch) is still a success. I correctly diagnosed and successfully sent a rejection notice to the other end is signalled by receive-pack to the daemon by exiting with success (i.e. 0) exit status. So even if we feed the exit status of the service process to the hook script specified by the --post-service-hook, it does not tell the script if the service succeeded in that sense. I see what you're saying. In my particular use case I can work around that service status because even if it failed it will just trigger Jenkins to poll and in case of failure to transfer data there will be no new changes for Jenkins to work with. If we would want the --post-service-hook to know that data transfer succeeded or failed, then may be there should be some difference between service status and service process status? In this case the existing logic works with service process status while the --post-service-hook is fed with the service status (or name it data transfer status) Do i make any sense? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git daemon --access-hook problem
- Your log file might not be located where you expect, you should use absolute path to dump text You were right! The problem was with the script itself - the log file not being specified with absolute path! Stupid me! ... - The documentation says you can print one line before a failure, also try this to show the cwd Would you be able to advise how this should be done? I don't get the error message (i mean the output of pwd) if i do this: echo `pwd` exit 1 What should it be? Thanks! Eugene Hope that helps, Antoine, -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git daemon --access-hook problem
Anybody? Any ideas? Thanks in advance! Eugene On Fri, May 31, 2013 at 4:22 PM, Eugene Sajine eugu...@gmail.com wrote: Hi, I'm trying to test this new feature and having problems getting any results in the following scenario: i have a repo in local folder /home/users/myuser/repos/projectA/.git i start the daemon with the following: git daemon --export-all --base-path=/home/users/myuser/repos --enable=receive-pack --access-hook=/home/users/myuser/test_hook.bash test_hook.bash has the following: #!/bin/bash echo $@ test_hook_out.txt echo $REMOTE_ADDR test_hook_out.txt the hook is set to be executable - otherwise it complains when i do anything via git protocol, which proves that it seems to or check the hook: then i did: cd ~/tmp/ git clone git://myhost/projectA projectA cd projectA and trying to perform some operations like fetch or push. It is cloned and fetches and pushes successfully. The problem is that the file test_hook_out.txt doesn't have anything in it after the execution, So the hook doesn't seem to work. What might be the issue here? Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git daemon --access-hook problem
Hi, I'm trying to test this new feature and having problems getting any results in the following scenario: i have a repo in local folder /home/users/myuser/repos/projectA/.git i start the daemon with the following: git daemon --export-all --base-path=/home/users/myuser/repos --enable=receive-pack --access-hook=/home/users/myuser/test_hook.bash test_hook.bash has the following: #!/bin/bash echo $@ test_hook_out.txt echo $REMOTE_ADDR test_hook_out.txt the hook is set to be executable - otherwise it complains when i do anything via git protocol, which proves that it seems to or check the hook: then i did: cd ~/tmp/ git clone git://myhost/projectA projectA cd projectA and trying to perform some operations like fetch or push. It is cloned and fetches and pushes successfully. The problem is that the file test_hook_out.txt doesn't have anything in it after the execution, So the hook doesn't seem to work. What might be the issue here? Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: git cvsimport implications
Hi My primary goal was to understand better what are the real problems that we might have with the way we use git cvsimport, so I was not asking about the guarantee of the cvsimport to import things correctly, but if there is a guarantee the import will result in completely broken history. IF there is a situation when cvsimport can do things right and when it definitely going to fail? Anyway, thanks a lot for the info. I do know that cvs2git is an option. If the cvsimport is that broken - is there any plan to fix it? Thanks, Eugene On Wed, May 15, 2013 at 2:24 AM, Michael Haggerty mhag...@alum.mit.edu wrote: On 05/15/2013 12:19 AM, Junio C Hamano wrote: Eugene Sajine eugu...@gmail.com writes: What if there are a lot of branches in the CVS repo? Is it guaranteed to be broken after import? Even though CVS repository can record branches in individual ,v files, reconstructing per branch history and where the branch happened in each changeset cannot be determined with any certainty. The best you can get is a heuristic result. I do not think anybody can give such a guarantee. The best you can do is to convert it and validate if the result matches what you think has happened in the CVS history. Junio, you are correct that there is no 100% reliable way of inferring the changesets that were made in CVS. CVS doesn't record which file revisions were committed at the same time, unambiguous branch points, etc. The best a tool can do is use heuristics. But it *is* possible for a conversion tool to make some more elementary guarantees regarding aspects of the history that are recorded unambiguously in CVS, for example: * That if you check the tip of same branch out of CVS and out of Git, you get the same contents. * That CVS file revisions are committed to Git in the correct order relative to each other; e.g., that the changes made in CVS revision 1.4.2.2 in a particular file precede those made in revision 1.4.2.3 of the same file. git-cvsimport fails to ensure even this minimal level of correctness. Such errors are demonstrated in its own test suite. cvs2git, on the other hand, gets the basics 100% correct (if you find a discrepancy, please file a bug!), in addition to having great heuristics for inferring the details of the history. There is no reason ever to use git-cvsimport for one-time conversions from CVS to Git. The only reason ever to use it is if you absolutely require an incremental bridge between CVS and Git, and even then please use it with great caution. Michael the cvs2svn/cvs2git maintainer -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: git cvsimport implications
Hi, We are using git cvsimport heavily but mostly the projects are not using branches that much. We are also migrating our repos only once, so there is no commits to CVS repo and no incremental imports allowed after the migration. we have migrated more than a thousand projects already. we use the simplest way (from the CVS checkout folder) $ git cvsimport -C /path/to/new/git/repo Just recently it was brought to my attention that we can have problems with that tool. So my question is if anybody could advise which scenarios are safe to use this tool for, and what is not recommended? What if there are a lot of branches in the CVS repo? Is it guaranteed to be broken after import? Do i understand correctly that it might put some files into a branch, that were not originally in this branch in CVS? In which cases it might happen (i'm sorry i didn't quite get the issues in the man pages for cvsimport)? Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bad URL passed to RA layer ('https')
Here I. Come me.detected at gmail.com writes: --8--- $ git svn clone https://host/svn/myrepo Initialized empty Git repository in /tmp/myrepo/.git/ Bad URL passed to RA layer: Unrecognized URL scheme for 'https://host/svn/myrepo' at /usr/libexec/git-core/git-svn line 1770 --8--- Hi, I have faced with the same problem. Did you find out who to resolve it? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Android Replies to Git List getting rejected
On Tue, Aug 7, 2012 at 4:55 PM, Theodore Ts'o ty...@mit.edu wrote: On Tue, Aug 07, 2012 at 01:33:23PM -0600, John 'Warthog9' Hawley wrote: It's pretty simple: you sent HTML mail to vger.kernel.org, and it explicitly rejects all HTML e-mail. GMail, particularly from Android, apparently doesn't have a way to bypass sending HTML mail (it's been a much maligned bug). Yeah, sigh. Drew, I suggest that you star the following bug: http://code.google.com/p/android/issues/detail?id=8712 ... and perhaps leave a comment in the bug report that you can't interact with the git mailing list because of this limitation. I'm sure you know (since you indicated that you sent your e-mail via the web interface of Gmail), that this is at least something you can control in the desktop/web version of Gmail (just enable Plain text mode) --- but it would certainly be nice if users had the choice of whether they wanted to participate on vger mailing lists using the Android application, versus the Web interface, or using Mutt or Pine on a Linux box. Regards, - Ted -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html There were several discussions about that on the list and unfortunately list moderators didn't pay enough attention to it. Android Gmail sends totally valid multipart message that has HTML and plain-text part. List being unable to process those correctly and cut off HTML part is a limitation. I personally feel that i could and would be more active on the list if not for this limitation. rant Don't want to accept HTML messages - fine. But don't tell me which program to use for my email, especially when I'm sending totally valid message, so take my plain text message part and use it. /rant Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: need help with syncing two bare repos
On Fri, Aug 3, 2012 at 4:00 PM, Junio C Hamano gits...@pobox.com wrote: Eugene Sajine eugu...@gmail.com writes: I think the best variant would be to do something like: $ git pull --rebase /refs/heads/*:/refs/heads/* $ git push origin /refs/heads/*:/refs/heads/* You perhaps meant worst not best here. From the point of view of people who have pushed into the origin repository we see above, their history is rewritten; you are screwing half the population by doing this. Not allowing B to accept pushes while it is not positively sure that A has gone down would of course be the best solution (in your scenario, B started serving when it merely found out that *it* cannot contact A), but barring that, the recovery for two histories at A and B, once they diverged, should be to merge corresponding branches. Junio, Thanks for chipping in! Please correct me if I'm wrong, but wouldn't merge result in the same history changes for people pushing to the origin (bareA)? Still all their consequent changes will not be fast-forwardable because of merge commit. Or am i missing something? It might be that the command i specified is incorrect. I meant that I would execute pull --rebase (or proper analogue for bare repo) for each branch on B side and then push those refs to A. This way it would pretend that B is another dev repo. May be you can advise on correct commands to do that properly? I'll think about not allowing pushes to B while not sure it is really time, so it is not reacting on irrelevant connectivity issues or bareA downtime due to the maintenance. Thanks, Eugene -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
