[git-users] Re: The remote end hang up unexpectedly
Indeed, the logs you posted don't tell me much. Indeed, it appears as if the ssh client closes the connection and sends an error code upstream, probably because the server doesn't ack the close (I'm speculating...). Maybe the following questions need also be answered before trying anything else: - Does this happen on other machines running the same software? - Would it be possible to set up a direct network link between client and server (i.e. no network switches, etc.) and retry? I'm maintaining my opinion that this is a network-related problem rather than a git-related one. One other thing to check, if you're using consumer-grade network switches between your client ad the server is that the MTUs for the eth interfaces on both client and server do not exceed 1500. Cheap network switches simply discard any packet larger than this. Yeah, toy with the MTU... -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/7NDflXWlo0MJ. 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: The remote end hang up unexpectedly
Yeah, I'd definitely do that, especially since it should be as easy as moving .vmx files between physical machines that are already connected. I'd not rely upon the wm-switches for anything more complex than ftp-ing between VMs... I fear they were not even tested for doing more than just that... I've had my own share of trouble with VMWare. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/lUGzs0M3L3IJ. 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: git build linker error
Referring specifically to your error, it's caused by the fact that the linker doesn't find libz.a in the proper place for libs, e.g. /usr/lib or /usr/local/lib And that's most likely because you don't have zlib installed in your system. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/_g0hqLRHXJoJ. 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 with combine repositories
I could actively tell git that two trees are the same. I'll keep my eyes open for an answer to this one on this list, as this interests me as much as it does you. This is key for your problem. But I can tell you this much: over here, where I'm working, we cloned entire reposes -- history and all -- so that we could easily pull from each other when needed, without worrying about differing histories. We're also using the patch-based approach, but the issue of failing to apply older patches to newer branches arises frequently. The way we're working around that, is to apply the older patch to a temporary branch starting from the commit the patch was created from, and then cherry-pick it onto the right branch. If there are no conflicts, git will do the right thing every time, and history is key. Suppose, I have a repository with history on master. Now I create a new branch new from nothing that includes all the same files as master, but no history. Just as if i created all the files now from scratch. I'm not sure you can do that at all in git, i.e. branch from no commit. That, indeed, would be like cloning with no history. I'll also keep my eyes peeled for this one... Thank you for your feedback as well. vineri, 25 mai 2012, 22:43:36 UTC+3, 7ff a scris: Stafen, thank you for your reply, Am Freitag, 25. Mai 2012 13:49:52 UTC+2 schrieb Stefan: [...]There simply is no way to cherry-pick commits (or rebase branches) from B into A, since git has no way to know that they are even the same source tree, let alone have any common history among them. I did know about the different sha when they don't have a common history. I was under the impression, that I could actively tell git that two trees are the same. But it seems I was remembering wrongly, git merge -s ours does the opposite of what I want: merge in all the history without changing files :-( To simplify the problem a bit (forget about the submodule and changes files and two repositories for a moment): Suppose, I have a repository with history on master. Now I create a new branch new from nothing that includes all the same files as master, but no history. Just as if i created all the files now from scratch. master and new have no common history, right. But could I not merge new into master? There should not be any conflicts since all files are the same. (?) Or if it is seen as a conflict that I want to recreate an already existing file (even with the very same content), I could resolve this easily, by just adding either version. What am I missing here? I might try this experiment later and see what's happening. I suspect that it will not work that way even though I don't really understand why ... So, the way I see it, in your case you have but one choice, and that is to move patches from B to A (and backwards, if A is indeed active itself!) and applying them in the same sequence. Git also tries to make this easier for you by providing things like format-patch, send-email, apply, etc. right, applying patch-files, or even copying files over and checking them in again, that was my Plan B already. cheers Matt -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/BZ7sipuaNkUJ. 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 with combine repositories
Maybe I can also help shed some light here. I'll start with the difference between patch and commit. Patch is -- simply put -- a diff between two versions of the same tree. You can only apply the patch to the same version of the tree from which it was generated. Period. In comes git to add a new dimension to patching: the history. A patch with a history is a commit. Every commit has a SHA1 that makes it unique. Two commits that have different SHA1s are viewed as different commits, even though running git format-patch on both could yield identical results! otherwise put, even though it's the same patch, if applied to different histories, you have different commits. And this is the case with your A and B reposes. Even though B starts fresh from a given commit in A, git has no way of knowing this without replicating the entire history (I'm not an expert here, so someone may cut in and contradict me; but this highlights the true git-related question behind your question: Is there a way to link two separate git histories without actually replicating them?). There simply is no way to cherry-pick commits (or rebase branches) from B into A, since git has no way to know that they are even the same source tree, let alone have any common history among them. So, the way I see it, in your case you have but one choice, and that is to move patches from B to A (and backwards, if A is indeed active itself!) and applying them in the same sequence. Git also tries to make this easier for you by providing things like format-patch, send-email, apply, etc. Anyone else please feel free to disagree. joi, 24 mai 2012, 18:40:52 UTC+3, 7ff a scris: Hello, I would appreciate some help or suggetions on this problem: condensed version: - A) a big repository with long history and a submodule B) a small repo made recently from an export of repo A, except some files/folders and including the files from the submodule of A how can I merge new commits (or cherrypick)? more detailed: --- repo A is a project with about 10 years of history (partially imported form svn) which I want to keep. This repo includes files for different customers/ applications. Recently, I agreed to work on this project with a team of one customer in a shared git repository. Obviously, they must not be able to see private files belonging to other customers. And there was no need for them to see my 10ys of history. So for a quick start, I just created a new repository with the files to be used. And to make things simpler (maybe more complicated now) I included the files from the submodule. Now I want to link the two repos so that I can merge new commits between the two repos. (git remote starts with a no common history warning ... so maybe some merge -s ours magic should be applied ... ? But the difference in submodules makes me doubt that this will be easy) To be sure not to import private object into B, merging one way B into A alone would be a helpful start. Ideally, I would to able to merge both ways. Is this possible at all? Or should I prepare to juggle with patch files? Thanks, Matt -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/QBXtZrkYVRMJ. 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: The remote end hang up unexpectedly
All looks OK below, but I do get that same message myself when there's a connection problem. Looks like you're using ssh, and it's there where I'd look first. Can you successfully transfer a large file over ssh to the server named 'git' using the 'git' account? Try this: $ scp large-file.dat git@git:/tmp Do you see any errors? miercuri, 23 mai 2012, 11:15:19 UTC+3, Thorsten Peters a scris: Our it check this but it all ok.. Fetch URL: git@git:/daten/git/dbc.git Push URL: git@git:/daten/git/dbc.git HEAD branch: master Remote branches: mastertracked v6.0.a1.0 tracked v6.0.drk.0tracked v6.0.impatto.0tracked v6.0.o2.0 tracked v6.0.quizwall.0 tracked v6.0.vodafone.0 tracked v6.0.vw.0.alpha tracked Local branches configured for 'git pull': master merges with remote master v5.3.vodafone.0.stable merges with remote v5.3.vodafone.0.stable v6.0.vodafone.0merges with remote v6.0.vodafone.0 Local refs configured for 'git push': master pushes to master (local out of date) v5.3.vodafone.0.stable pushes to v5.3.vodafone.0.stable (local out of dat Am Dienstag, 22. Mai 2012 13:44:38 UTC+2 schrieb Stefan: Looks to me like your git server is simply overloaded. Run a h/top/vmstat -n 1 on it in a different window and only retry the push when CPU usage on the server drops below 50%. If the push never succeeded I would've expected invalid ssh/git credentials... You might also want to check your network/firewall settings. If your network does some ugly form of traffic shaping, it could unexpectedly kill your TCP connection for git push. Otherwise, you may simply lack the bandwidth, which may as well be causing your TCP connections to timeout. Posting the output of the git remote show origin command on your system (not necessarily the full URL paths) could also help someone provide a better answer than this. These are just some possibilities, hope you find the true cause by starting with these... Ştefan Szabó marți, 22 mai 2012, 14:17:05 UTC+3, Thorsten Peters a scris: Any ideas? We try different things, but nothing works. Same push, x times hang up, than it works finde. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/llKe3MZABrAJ. 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] Command unknown: 'AUTH' at /usr/lib/git-core/git-send-email line 1140, STDIN line 1.
Has anyone seen this before? It only happens to me with git version 1.7.9.5 on a ubuntu x86_64 machine. Thanks -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/ZBQFWfM0UE8J. 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: git-send-email troubles
It's two of us... In git version 1.7.9.5 the error has moved to line 1140. I can't believe nothing happened on this thread since back in 2009! We're either both probably doing something very wrong, or noone is using git send-email on ubuntu... sâmbătă, 14 martie 2009, 22:59:01 UTC+2, Frew a scris: Hello all! I am trying to use get-send-email on ubuntu. When I attempt to send a message I get this errror: Command unknown: 'AUTH' at /usr/bin/git-send-email line 775, STDIN line 1. Here are my settings: [sendemail] smtpserver = smtp.gmail.com smtpserverport = 587 smtpencryption = tls smtpuser = fri...@gmail.com Any idea what I am doing wrong here? Thanks! -- fREW Schmidt http://blog.afoolishmanifesto.com -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/n8uADHp3jWQJ. 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.
