Re: [git-users] Re: Multiple clones of the same remote repo
On Mon, Sep 02, 2013 at 09:59:43PM -0700, Juha Aaltonen wrote: To put it more clearly: There are a couple of guys working with a code and there's a common repo on a server. I cloned the remote repo with both Giteye and SourceTree (two different clones). I edited the code cloned with SourceTree, committed the changes and pushed the changes back to the remote repo. Then some other people have made some changes in some parts of the program and I made changes in another part of the program in the Giteye-clone. Before committing I wanted to update the Giteye-clone, but pull shows that everything has changed and everything is in conflict whereas fetch shows that nothing has changed. I managed to do the changes using the SourceTree-repo - first pulling then manually merging from the Giteye-tree and then committing/pushing using the SourceTree. I would strongly suggest you drop into a shell and test what git on the command line says. Many of the GUIs for git are great, but they sometimes make it /very/ difficult to understand what the exact state of a clone is. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin, Historical Review of Pennsylvania, 1759 pgpuQmwGffhuT.pgp Description: PGP signature
[git-users] Re: Migrate multi-repository setup form SVN to GIT
If you want to keep your process relatively similar then I think it might look something like... development (repo) - master (= trunk) - branches from master. - tags on master. de (repo) - master (= trunk) - branches from master (if necessary, probably a good practice to create a branch when merging from development repo) - tags on master. etc. The *de* repo would have *development* repo as a remote. So the equivalent to the process you outlined would be... In *de*: 1. git remote add development ssh://user@host:port/path/development.git 2. git fetch development tag (you can use tab-complete to give you list of tags) 3. git checkout -b dev-tag-merge FETCH_HEAD 4. sort out the issues, *git commit* to finish off the changes. 5. git checkout master 6. git merge dev-tag-merge 7. fix any conflicts 8. git branch -d dev-tag-merge (delete the branch used to merge from * development* as you don't need it any more). 9. git tag -a de_tag Or something along those lines I think, doing this off the top of my head :) Others might be able to something better. HTH Alex On Tuesday, 3 September 2013 06:40:55 UTC+1, Sascha Egerer wrote: Hi, we are currenlty planning to migrate a big project from SVN to GIT. The project in rolled out to multiple countries (currently about 15) and each country is based on the master but has slight modifications. It's not possible to localize everthing. So our current SVN setup looks like this: SVN - master - trunk - branches - feature-111-foo-bar - bugfix-222-foo-bar - hotfix-333-foo-bar - tags - 1.0.0 - 1.1.0 - 1.1.1 - 1.2.0 - 1.2.1 - de - trunk - branches - trags - 1.0.0 - 1.1.0 - 1.1.1 - 1.2.1 - us - trunk - branches - trags - 1.0.0 - 1.2.1 The workflow is the following: Development is completely done in the master repository. If a country says hey version 1.1.0 look good for us. we want to roll this out in our country we are merging the tag into the country repository. After the merge some required changes are also commited to the trunk. After we have finished the country adjusted a tag will be created for the country. So there is no real development in the country based repositories. And we do just merged the requested tags into the countries. The question is now what is the best way to do this in git. 1. Create a branch for each country in the origin repository - then merge master tags into the country branch and create a country tag 2. Create a own git repository for each country that is added as remote - pull origin tags and merge them into the country repo. then merge the tag and create a tag in the country repo What would you suggest? Do you have similar setups? -- 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] Migrate multi-repository setup form SVN to GIT
Your email client seems to be set to sending HTML-only, which means my email client wasn't able to display the illustration of the SVN repo properly. I've hopefully guessed correctly in my attempt to adjust it below ;) On Mon, Sep 02, 2013 at 10:40:55PM -0700, Sascha Egerer wrote: Hi, we are currenlty planning to migrate a big project from SVN to GIT. The project in rolled out to multiple countries (currently about 15) and each country is based on the master but has slight modifications. It's not possible to localize everthing. So our current SVN setup looks like this: SVN - master - trunk - branches - feature-111-foo-bar - bugfix-222-foo-bar - hotfix-333-foo-bar - tags - 1.0.0 - 1.1.0 - 1.1.1 - 1.2.0 - 1.2.1 - de - trunk - branches - trags - 1.0.0 - 1.1.0 - 1.1.1 - 1.2.1 - us - trunk - branches - trags - 1.0.0 - 1.2.1 The workflow is the following: - Development is completely done in the master repository. - If a country says hey version 1.1.0 look good for us. we want to roll this out in our country we are merging the tag into the country repository. After the merge some required changes are also commited to the trunk. After we have finished the country adjusted a tag will be created for the country. So there is no real development in the country based repositories. And we do just merged the requested tags into the countries. The question is now what is the best way to do this in git. 1. Create a branch for each country in the origin repository - then merge master tags into the country branch and create a country tag 2. Create a own git repository for each country that is added as remote - pull origin tags and merge them into the country repo. then merge the tag and create a tag in the country repo What would you suggest? Do you have similar setups? To me it sounds like you are using version control (SVN) for two things: 1. Development (in master/trunk) 2. Release management and distribution (by `svn copy` from master/tags/foo to country/tags/foo, followed by an `svn switch` by the country operations). If I've understood this properly then it's easier to find a way to use git. I've personally not seen a similar setup, but I have experienced situations where a VCS was used for more than version control of artefacts (e.g. for release management, deployment, etc). It's not necessarily a bad option, but it's useful to always keep in mind what exactly you are using a tool for. Based on your description above I think you can get away with only a single central git repo that the country-based operations can clone. The country-repos would then base their 'master' on a tag, make a few country-specific changes and commit them. When they want to move to a new release (another tag), they simply move 'master' to the new tag and transplant their local changes (using either `git rebase` or `git cherrypick` as needed). /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus The British have the perfect temperament to be hackers--technically skilled, slightly disrespectful of authority, and just a touch of criminal behavior. -- Mary Ann Davidson, Oracle's Security Chief pgpS3R2J7bQ1f.pgp Description: PGP signature
Re: [git-users] Two way mirroring because over network zones
Thanks for the input guys. We could do an automatic sync with manual notifications on merge conflicts (would probably be rare), but I think we will smplify our setup like Konstantin suggests. For reference: * We have many readers of the repo in zone two, so we set up a clone --mirror as a read only repo in zone two which mirrors zone one * We make ssh available to the few clients in zone two that needs write to the repo in zone one (transparent forwarding http://sshmenu.sourceforge.net/articles/transparent-mulithop.html through a jump host, or exceptions in the firewall) Anders, On Thursday, 29 August 2013 00:01:21 UTC+2, Philip Oakley wrote: - Original Message - From: Philip Oakley philip...@iee.org javascript: To: git-...@googlegroups.com javascript: Cc: Anders Sveen anders@gmail.com javascript:; Konstantin Khomoutov flat...@users.sourceforge.net javascript: Sent: Wednesday, August 28, 2013 10:38 PM Subject: Re: [git-users] Two way mirroring because over network zones That said, is the two sides won't talk you will get conflicts, so do expect the tool to do everything ;-) Oops, Should read: That said, if the two sides won't talk you will get conflicts, so don't expect the tool to do everything ;-) Do have a look at how git itself is developed with a layered approach to the synchronization problem; 'master' is never rewound, 'next' is occasionally rewound at choreographed points, 'pu' (potential updates) is often rewound, so folks have a good handle on levels of stability and where their patches have progressed to. 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. For more options, visit https://groups.google.com/groups/opt_out.
[git-users] Files unexpectedly ignored in git repo!
*I manually loaded a few files in my repository and some files are now ignored without being specified as ignored in gitignore.* *here is a brief discussion on stack overflow on this issue. We suspect this is a bug.* * * http://chat.stackoverflow.com/rooms/36566/discussion-between-xdrone-and-jszakmeister * * -- 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.
[git-users] Suspected Bug Files unexpectedly ignored in git repo
I manually replaced come files in a dev repo and not i have a few files ignored without add these files to gitignore. We suspect this is a bug, here is a discussion that prompted this post. http://chat.stackoverflow.com/rooms/36566/discussion-between-xdrone-and-jszakmeister -- 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] avoid git deleting tags file
Hi Dexter, you are using option x in git clean command. In the manual, the option x tells: -x Don’t use the standard ignore rules read from .gitignore (per directory) and $GIT_DIR/info/exclude, but do still use the ignore rules given with -e options. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git reset) to create a pristine working directory to test a clean build. So, if you don't want to delete files in .gitignore, just don't use the option x, only the options f and d: git clean -fd William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Tue, Sep 3, 2013 at 10:33 AM, dexter ietf dexter.i...@gmail.com wrote: hi, when i run git clean -xfd, git deletes my tags file. i have the tag file listed in gitignore, but how do i tell git not to remove the tags file. -dexter -- 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] starting out with git -- a problem with branching....
thank you all very much for your responses this is the first time I'm back on Usenet in a long time... it had become practically unusable b/c of the spam, but I see that google got its act together here, and has somehow managed to deal with the spam...;-) this is good to know... yes, I see that I have to commit changes before switching branches in order for the changes to NOT show up in branch master to me personally this doesn't matter, I work in my localhost, and just want the changes to be visible that I want to push at that moment... so I guess all I have to do is stage commit, then switch to the branch for the changes I want to push at that moment, and push... does this make sense? it's the first time I'm using git for my personal stuff... but I imagine in other situations, to have to commit every time before switching branches is weird... what if you haven't finished work on a branch and need to switch branches to take care of another problem, but don't want to commit what you just did because, well, you're not ready to commit? ;-) I mean scenario described here, http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging on very first section, near the top of this page... (they never said you'd have to commit every time you switch branches.;-) thank you very much -- 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] starting out with git -- a problem with branching....
If you don't want to do a commit, then do a stash. It puts the current working directory off to the side. Like a temporary branch. When you want to come back, then you do a git stash pop. I think I understand how you're working. You likely only do a commit when you think something is finished. I, on the other hand, think of commit as take a checkpoint. And I use the commit comment to tell me where I am and what I'm thinking about. I have a bare repository to which I do a git push when I think that something is finished. Well, to the extent that anything that _I_ do is ever finished grin/. On Tue, Sep 3, 2013 at 10:05 AM, maya melnick maya778...@yahoo.com wrote: thank you all very much for your responses this is the first time I'm back on Usenet in a long time... it had become practically unusable b/c of the spam, but I see that google got its act together here, and has somehow managed to deal with the spam...;-) this is good to know... yes, I see that I have to commit changes before switching branches in order for the changes to NOT show up in branch master to me personally this doesn't matter, I work in my localhost, and just want the changes to be visible that I want to push at that moment... so I guess all I have to do is stage commit, then switch to the branch for the changes I want to push at that moment, and push... does this make sense? it's the first time I'm using git for my personal stuff... but I imagine in other situations, to have to commit every time before switching branches is weird... what if you haven't finished work on a branch and need to switch branches to take care of another problem, but don't want to commit what you just did because, well, you're not ready to commit? ;-) I mean scenario described here, http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging on very first section, near the top of this page... (they never said you'd have to commit every time you switch branches.;-) thank you very much -- 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. -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- 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.
[git-users] git log format without times and/or zone
Hello! I get with git log --format=%h %ci %s eef5296 2013-08-15 16:37:35 +0200 msg3 1e68ecb 2013-08-14 11:08:22 +0200 msg2 4959e91 2013-07-29 12:03:09 +0200 msg1 How can I achieve this output please? eef5296 2013-08-15 16:37 msg3 1e68ecb 2013-08-14 11:08 msg2 4959e91 2013-07-29 12:03 msg1 Or even this? eef5296 2013-08-15 msg3 1e68ecb 2013-08-14 msg2 4959e91 2013-07-29 msg1 Thanks HG PS: git version 1.7.1 https://www.kernel.org/pub/software/scm/git/docs/git-log.html -- 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] starting out with git -- a problem with branching....
On Tue, 2013-09-03 at 08:05 -0700, maya melnick wrote: but I imagine in other situations, to have to commit every time before switching branches is weird... what if you haven't finished work on a branch and need to switch branches to take care of another problem, but don't want to commit what you just did because, well, you're not ready to commit? ;-) That's what the git stash command is for. Check it 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] starting out with git -- a problem with branching....
From: maya melnick maya778...@yahoo.com (I haven't commited, it's just a test branch, I don't want to commit;-) make sense? The way to think about it is that you've just changed a file in the working directory, it isn't *in* the branch or the repository. So when you tell Git to shuffle the working directory to show the top of master, Git sees that there's this entirely un-archived change in the working directory, and it leaves it unchanged. You can stash the change, but I think that what you really want is to commit it into test. The change may not be complete, but it safely saves the change into test. You can add further changes to the top commit of test using git commit --amend, or you can combine several commits using git rebase --interactive. Dale -- 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] starting out with git -- a problem with branching....
On Tue, 3 Sep 2013 10:20:06 -0500 John McKown john.archie.mck...@gmail.com wrote: If you don't want to do a commit, then do a stash. It puts the current working directory off to the side. Like a temporary branch. This comparison is quite to the point -- the `git stash` command even allows to create a new branch from any stash entry. When you want to come back, then you do a git stash pop. I think I understand how you're working. You likely only do a commit when you think something is finished. I, on the other hand, think of commit as take a checkpoint. Again, a very good suggestion. To those introduced to video games, I like to explain commits as saving the game just before opening a door to a yet not visited room with your gun ready ;-) [...] -- 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] starting out with git -- a problem with branching....
On Tue, 3 Sep 2013 08:05:23 -0700 (PDT) maya melnick maya778...@yahoo.com wrote: [...] but I imagine in other situations, to have to commit every time before switching branches is weird... what if you haven't finished work on a branch and need to switch branches to take care of another problem, but don't want to commit what you just did because, well, you're not ready to commit? ;-) You do not *have to* commit -- if you dislike the idea of work-in-progress commits, then just use stash -- it was invented precisely for dealing with such scenarious when you want to disrupt your hacking session to switch to another branch temporarily to do, say, a quick fix. But it helps to actually ponder the possibility of throw-away commits even if you do not intend to use them. This is because in Git philosophy your *local* (unpushed) history is not sacred (this is in stark contrast with certain other DVCS systems, for instance, Fossil [1] in which each commit is cast in stone), and you're free to manipulate it however you're pleased to do so until it's pushed somewhere else. This allows you to spit a series of miniscule dirty commits and then lump them together to form a larger beautiful commit or several of them and bless the result as something you intend to share or publish. If you lament the fact the work tree is not tied to a branch then there's nothing which could be do to it -- this is the design choice, and Git developers are highly unlikely to ever change that. It also helps pondering that there are technical difficulties implementing such affinity: what to do with untracked files? Obviously, when you hack a feature, you're likely to create new files -- should Git auto save them when you switch branches? Yes? But what if while hacking that feature you performed a test run of your program and it spewed a few hundred gigabytes of tracing data to your work tree? Saving just everything hence has unexpected (and possibly crazy) hidden costs, and not saving everything has the great WTF potential. So in fact what Git does is a) simple and predictable, and b) has low WTF potential once you know the rules (and you do now). 1. http://www.fossil-scm.org -- 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] starting out with git -- a problem with branching....
On 4 September 2013 01:20, John McKown john.archie.mck...@gmail.com wrote: If you don't want to do a commit, then do a stash. It puts the current working directory off to the side. Like a temporary branch. When you want to come back, then you do a git stash pop. I think I understand how you're working. You likely only do a commit when you think something is finished. I, on the other hand, think of commit as take a checkpoint. And I use the commit comment to tell me where I am and what I'm thinking about. I have a bare repository to which I do a git push when I think that something is finished. Well, to the extent that anything that _I_ do is ever finished grin/. The following additional comments are directed to maya melnick, based on John's above: I agree. At this state I'd encourage you more toward getting more comfortable with commits rather than stashing, although both are fine. Like John wrote, I think of commits as snapshots. The less sure I am of how todays code is going to develop, the more interim commits I make, in case I go in a direction that doesn't work out, or might not. I make lots of commits and little branches. Then when the final design becomes clearer, I remove the unwanted stuff, usually by rebasing or amending commits. I find the graphical tools gitk and git-gui help with this. This is different to thinking of commits as finished milestones, although you can of course have other commits and/or branches that have that role. It takes a while to become that comfortable with git, but when you do, it is great. It is very important (and took me too long) to realise that branches are just pointers, and so this: when you want to do anything in git that you are unsure about (like rebasing or tidying up a branch), just create another temporary branch that points to the exactly same place and modify it. So if you mess it up, the original branch will still be there unchanged, as a fallback. Repeat until happy with results. -- 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] starting out with git -- a problem with branching....
For milestones, I either create a new branch at that commit point (rarely) or tag the commit with a nice name. On Tue, Sep 3, 2013 at 10:40 AM, David bouncingc...@gmail.com wrote: On 4 September 2013 01:20, John McKown john.archie.mck...@gmail.com wrote: If you don't want to do a commit, then do a stash. It puts the current working directory off to the side. Like a temporary branch. When you want to come back, then you do a git stash pop. I think I understand how you're working. You likely only do a commit when you think something is finished. I, on the other hand, think of commit as take a checkpoint. And I use the commit comment to tell me where I am and what I'm thinking about. I have a bare repository to which I do a git push when I think that something is finished. Well, to the extent that anything that _I_ do is ever finished grin/. The following additional comments are directed to maya melnick, based on John's above: I agree. At this state I'd encourage you more toward getting more comfortable with commits rather than stashing, although both are fine. Like John wrote, I think of commits as snapshots. The less sure I am of how todays code is going to develop, the more interim commits I make, in case I go in a direction that doesn't work out, or might not. I make lots of commits and little branches. Then when the final design becomes clearer, I remove the unwanted stuff, usually by rebasing or amending commits. I find the graphical tools gitk and git-gui help with this. This is different to thinking of commits as finished milestones, although you can of course have other commits and/or branches that have that role. It takes a while to become that comfortable with git, but when you do, it is great. It is very important (and took me too long) to realise that branches are just pointers, and so this: when you want to do anything in git that you are unsure about (like rebasing or tidying up a branch), just create another temporary branch that points to the exactly same place and modify it. So if you mess it up, the original branch will still be there unchanged, as a fallback. Repeat until happy with results. -- 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. -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- 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] git log format without times and/or zone
I get eef5296 Thu Aug 15 16:37:35 2013 +0200 msg3 1e68ecb Wed Aug 14 11:08:22 2013 +0200 msg2 4959e91 Mon Jul 29 12:03:09 2013 +0200 msg1 with my locale LANG=en_GB.UTF-8 LC_ALL=en_GB.UTF-8 Dne úterý, 3. září 2013 17:30:09 UTC+2 John McKown napsal(a): See if: git log --format=%h %cd %s gives you what you want. It looks like you last example, with only the date. On Tue, Sep 3, 2013 at 10:20 AM, Hans Ginzel ha...@matfyz.czjavascript: wrote: Hello! I get with git log --format=%h %ci %s eef5296 2013-08-15 16:37:35 +0200 msg3 1e68ecb 2013-08-14 11:08:22 +0200 msg2 4959e91 2013-07-29 12:03:09 +0200 msg1 How can I achieve this output please? eef5296 2013-08-15 16:37 msg3 1e68ecb 2013-08-14 11:08 msg2 4959e91 2013-07-29 12:03 msg1 Or even this? eef5296 2013-08-15 msg3 1e68ecb 2013-08-14 msg2 4959e91 2013-07-29 msg1 Thanks HG PS: git version 1.7.1 https://www.kernel.org/pub/software/scm/git/docs/git-log.html -- 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+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- As of next week, passwords will be entered in Morse code. Maranatha! John McKown -- 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.
[git-users] Re: git hangs up unexpectedly (but git push works, kinda) dropbear+git
I know this is from several years ago, but did you ever come up with a solution to this? I'm currently running into the same problem, using dropbearkey and git through Terminal IDE on an ASUS android tablet. The push works, but I get The remote end hung up unexpectedly and the post-receive hook doesn't run. On Thursday, July 16, 2009 9:32:02 PM UTC-4, J wrote: I'm encountering some strange behavior so I'm hoping someone can help shed some light on this. When I do a git push, it ends with a fatal: The remote end hung up unexpectedly but checking the git logs and the remote repo seems to indicate the push went through fine. Rerunning the git push returns Everything is up to date. So a little background, I have dropbear and git installed on a Palm Pre and am trying to commit changes to a repo on gitorious. Since dropbear is kind of screwy, I had to create a shell script (called sssh) that does the equivalent of ssh ~/.ssh/id_rsa $* as dropbear will not automatically scan for the public key. Additionally, I have defined GIT_SSH to be /opt/bin/sssh. So at this point, everything seems to work (i.e. the push happens) but I am not sure why the fatal message keeps popping up. Any ideas/ suggestions? -- 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.
[git-users] Need sine help on Git hooks
Hello, I'm kinds of new on Git and now we are trying to get the hooks enabled into one of our server repository, what we want this hooks doing is to prevent when local users that push the changes from their local repo to server repo, we need to first check the commit comments to see if it include some specific words, (i.e. 999). so what I tried is created an update hooks with compare the git log, but looks like this won't works correctly since this is only check the previous pushed comments. so I believe I will need to use pre-receive hook, but here is my quesiton? What is the basic flow for pre-receive hook for me to compare the local push commets with server existing comments? Thanks Ling -- 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] avoid git deleting tags file
On Tuesday, September 3, 2013 8:07:06 PM UTC+5:30, William Seiti Mizuta wrote: Hi Dexter, you are using option x in git clean command. In the manual, the option x tells: -x Don’t use the standard ignore rules read from .gitignore (per directory) and $GIT_DIR/info/exclude, but do still use the ignore rules given with -e options. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git reset) to create a pristine working directory to test a clean build. So, if you don't want to delete files in .gitignore, just don't use the option x, only the options f and d: git clean -fd William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Tue, Sep 3, 2013 at 10:33 AM, dexter ietf dexte...@gmail.comjavascript: wrote: hi, when i run git clean -xfd, git deletes my tags file. i have the tag file listed in gitignore, but how do i tell git not to remove the tags file. -dexter -- 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+...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. as simple as that, thanks for the help. i should have rtfm, but it scares that s***t out of me once i open the manual. -- 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.
[git-users] Re: Multiple clones of the same remote repo
Truckload of thanks for the explanation. It must have taken a lot of iron wire to bend it for me. :-) -- 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.
