[git-users] invalid key error
Hi, After upgrade from 1.7.2.5-3.1 to 1.7.10.4-1+wheezy1 following error appear: [code] git push central versions/4.3.2 Counting objects: 45, done. Delta compression using up to 8 threads. Compressing objects: 100% (28/28), done. Writing objects: 100% (28/28), 13.01 KiB, done. Total 28 (delta 22), reused 0 (delta 0) remote: Update script started: Tue Jun 9 13:25:34 BST 2015 remote: Arguments: refs/heads/versions/4.3.2 2e5233728aecc6ac337f4d3a9f32281e7c786e27 ae25cc33f6cf745cfa1061cbdfaf445344a60d13 remote: Warning: using temporary hooks remote: error: invalid key: hooks.denypush.branch.versions/4.3.2 remote: error: invalid key: hooks.allowmerge.versions/4.3.2 remote: Packages changed by this update: remote: think_3 remote: hls_plugin_1 remote: hal_av_1 remote: rtsp_plugin_1 remote: Notifying the following package owners of this update: [/code] I am trying to find out what does it mean but with no result. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Beginner Git Book Half-Off (Ad, Promotion)
Hello, I've been writing a book about Git aimed at beginners. It's called Learn Git in a Month of Lunches, and it is from Manning Publications. Today, June 10, 2015, the book is half-off with the coupon code 'dotd061015au'. For those interested, please visit: http://www.manning.com/umali Thank you! -- Rick Umali -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Can not undo multiple git rebase using git reflog git reset --hard
2015-06-09 15:55 GMT-04:00 Konrád Lőrinczi klorin...@gmail.com:
I did a few git rebase interactive between branches, but when I use git
reflog git reset --hard HEAD@{N} I can not get the same branch
hierarchy as it was before.
git reflog
git reset --hard HEAD@{14}
Hi,
You seem to be confused as to what git reset --hard does -- it doesn't
reset your whole repository, it moves a single branch head to a different
commit.
You will have to consult the reflog of each branch (git reflog local_dev),
and reset that branch to the correct point (git checkout local_dev; git
reset --hard local_dev@{N}).
Good luck
--
Rémi Rampin
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[git-users] Setting up Git for existing project
I was hoping someone might be able to help me figure out how to setup a Git repository for our existing web application. There are several reasons for migrating to Git (from Visual SourceSafe), but the two biggest reasons are: 1). making the code more multi-developer friendly and 2). we are migrating to the AWS cloud and it will make it easier to use Git to assist in code deployment. That being said, I'm not sure the best practice for getting our existing code into Git. We currently have a Test server and Production server, so we have two copies of the code and the developers access the code directly on the Test server and make changes there. Because of this, we have code files on the Test server that I want in the repository, but in most cases I do not want these files to ever make it to the Production server. So on to my actual question, how can add ALL the code on the Test server to the repository, but only have a subset of that code identified to deploy to the Live server? I've thought about making the Test code the master branch and creating a production branch where the Production code subset would live, but when i think through the process of merging master changes into the production branch it would see that, without a ton of effort, the test-only files would come along for the merge, which is not desired. Any suggestions or comments you may have to help me figure this out are extremely welcomed. Thank you. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Setting up Git for existing project
On Wed, 10 Jun 2015 09:29:04 -0700 (PDT) David VanKirk krik...@gmail.com wrote: [...] That being said, I'm not sure the best practice for getting our existing code into Git. We currently have a Test server and Production server, so we have two copies of the code and the developers access the code directly on the Test server and make changes there. Because of this, we have code files on the Test server that I want in the repository, but in most cases I do not want these files to ever make it to the Production server. So on to my actual question, how can add ALL the code on the Test server to the repository, but only have a subset of that code identified to deploy to the Live server? I've thought about making the Test code the master branch and creating a production branch where the Production code subset would live, but when i think through the process of merging master changes into the production branch it would see that, without a ton of effort, the test-only files would come along for the merge, which is not desired. What do you mean by «test-only files»? Here's why I'm asking: A complicated project usually undergoes certain code churn which produces a number of commits, each or which is imperfect in the sense the state of the project at it can't yet be sensibly used in production. At some point, the code base stabilizes and the process resolves in a commit which can be deemed as fit for production usage. (More complicated project might involve several stages for this, like forking a stabilization branch at some point and only allowing bugfixes on it, and hence the production version is cut from that branch.) The key point here is that imperfect history leads to a perfect commit. And so here's my question: do you refer to the contents of the commits from such development history as test files? Or do you wanted to tell that developers create on the test server some files which exist on the filesystem only during development and must not exist on the filesystem on the production server? That's a crucial difference, and hence I'd like to see some clarification before we move forward. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Problem with the detached head:
I have the head detached for my remote origin/develop branch. I was not sure of my previous actions that resulted this but I remember getting a message saying the origin/develop diverged from develop (don't know if it is relevant). Anyways, I tried creating a temp branch and forcing the head of origin/develop to that temp but I am unable to solve this issue. Could you help me with this. Thanks, Bhargavi. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Problem with the detached head:
On Wed, 10 Jun 2015 08:28:19 -0700 (PDT) Bhargavi V umail.bharg...@gmail.com wrote: I have the head detached for my remote origin/develop branch. Terminology warning: the HEAD being in a detached state precisely means that it's no longer associated with any branch -- that's why it's detached after all. So you can't really say that you have the HEAD detached _for_ some branch: your origin/develop branch still has its own tip intact -- available through using that name origin/develop. I was not sure of my previous actions that resulted this but I remember getting a message saying the origin/develop diverged from develop (don't know if it is relevant). Supposedly this only means that you have a local branch named develop, and it's set to track the remote branch origin/develop. Tracking is used to assist the user in a common case: when a local branch is logically bound with a remote branch. When a local branch is set to track a remote branch, certain Git commands start hinting you about the relation of commits in these branches. You can start with [1] to learn more about this concept. And no, this is not relevant to the problem at hand. Anyways, I tried creating a temp branch and forcing the head of origin/develop to that temp but I am unable to solve this issue. Do you really want to mess with origin/develop? The origin/develop is a so-called remote branch. The core idea behind remote branches is that they are sort of bookmarks to the state of a particular remote repository. Say, you run `git fetch origin`, and when it completes your remote branches having the origin/ prefix are updated to mirror what tips their matching branches on the remote origin contained when fetching run. These branches are hence only for reference: they are there to not require you reach for a remote repository each time you want to work with a remote branch -- inspect its history, merge with your local branch etc. That's why you never work directly on remote branches, and never manipulate them directly. I think that your origin/devel is just OK, and the real question is what do you want to do with the work you did while having been in the detached HEAD state. Am I right on this? If yes, then first make sure you saved your work: tag your HEAD commit or make a branch out of it: git tag temp or git branch temp It seems that you've already managed to do that though... The next thing is to decide what to do with those commits. To me, it appears they were intended to be done on develop instead, right? If yes, cherry-picking seems like the best bet. Inspect what was done on the temp branch using `git log temp` and identify commits you want on your develop. Then check the develop branch out and use a series of calls to git cherry-pick commit passing it commits you want to get applied -- starting from the oldest. (This can be automated but let's not touch this for now.) 1. https://git-scm.com/book/it/v2/Git-Branching-Remote-Branches -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Setting up Git for existing project
Let me try to clarify, as I agree, the reasoning is important to making the right decision. For one, let me say that the application is an ASP.NET Web Site (as opposed to a Web Application), so it's not like a traditional compiled project where I can put code in the project that is not accessible in the release version. For example, in a traditional project I can create a class, but as long as I don't call or reference that class in production, user-accessible code that class will never be run in a production environment. In a Web site if I have the markup and code files on the server then it will be compiled during the site's run-time compilation and could potentially be discovered and accessed by users. So NOT having these files on the production server is the most secure option. Having said that, the types of files can be grouped into a few categories: admin tools and prototypes. So there is a subfolder on the site that is called admin_tools and it has several administrative tools that we ONLY want on the internal development server. These files tend to data management tools that we allow internal, non-developers access to update data associated with the site. These tools we DEFINITELY don't want discovered on production, as it would allow users to update data without restraint. There is also a folder called prototypes where we may prototype a feature (again, on the internal development server for employees only) that we want to proof-of-concept. It has merit on the internal development server and the prototype may evolve over time by various developers (hence the desire for being in the repository) but since they are not fully fleshed features, discovery by a user could again be disastrous to the site. Does this help to answer your question? I should also clarify how our development process is planning on changing with Git being involved. Currently our development process looks something like this: 1. Developers access code directly on Test server to make changes 2. Testers look at site on Test server to validate changes 3. Developers push code to Production Server 4. Testers re-validate changes just after code publishing With Git involved the plan is to do the following: 1. Developers alter code and test on their machines and push stable changes to repo 2. Several times a day the code from the repo will be updated to Test server and Testers will validate code changes 3. Once the Test server code is stable and ready for production use, the code will be tagged and pushed to a Staging server 4. Once the code is re-validated on the Staging server, the code will be scheduled and updated to the Production server Again, hope this clarifies some of our processes and reasoning and allows you to help me more effectively. On Wednesday, June 10, 2015 at 9:42:26 AM UTC-7, Konstantin Khomoutov wrote: On Wed, 10 Jun 2015 09:29:04 -0700 (PDT) David VanKirk kri...@gmail.com javascript: wrote: [...] That being said, I'm not sure the best practice for getting our existing code into Git. We currently have a Test server and Production server, so we have two copies of the code and the developers access the code directly on the Test server and make changes there. Because of this, we have code files on the Test server that I want in the repository, but in most cases I do not want these files to ever make it to the Production server. So on to my actual question, how can add ALL the code on the Test server to the repository, but only have a subset of that code identified to deploy to the Live server? I've thought about making the Test code the master branch and creating a production branch where the Production code subset would live, but when i think through the process of merging master changes into the production branch it would see that, without a ton of effort, the test-only files would come along for the merge, which is not desired. What do you mean by «test-only files»? Here's why I'm asking: A complicated project usually undergoes certain code churn which produces a number of commits, each or which is imperfect in the sense the state of the project at it can't yet be sensibly used in production. At some point, the code base stabilizes and the process resolves in a commit which can be deemed as fit for production usage. (More complicated project might involve several stages for this, like forking a stabilization branch at some point and only allowing bugfixes on it, and hence the production version is cut from that branch.) The key point here is that imperfect history leads to a perfect commit. And so here's my question: do you refer to the contents of the commits from such development history as test files? Or do you wanted to tell that developers create on the test server some files which exist on the filesystem only during development and must not exist on the filesystem on
