[git-users] Best way to identify a version of a repo
I need to checkout code from a repo and somehow identify it (timestamp, hash, …) such that at some later time I can extract the SAME versions of all the code. I’m provisioning cloud instances, so each time would be a fresh “get clone” into an empty folder. After I create the “master” (ie provision the FIRST instance) I need to record some way to identify it in case I have to recreate the master.I prefer NOT to alter the original repo (ie tag it), but prefer the ‘work’ of identifying the sources to be done on the client side. Would appreciate any guidance! Deanna -- 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] Best way to identify a version of a repo
On Fri, 14 Jun 2013 05:08:11 -0700 (PDT) Deanna Delapasse ddelapa...@gmail.com wrote: I need to checkout code from a repo and somehow identify it (timestamp, hash, …) such that at some later time I can extract the SAME versions of all the code. I’m provisioning cloud instances, so each time would be a fresh “get clone” into an empty folder. After I create the “master” (ie provision the FIRST instance) I need to record some way to identify it in case I have to recreate the master.I prefer NOT to alter the original repo (ie tag it), but prefer the ‘work’ of identifying the sources to be done on the client side. I'm not sure I exactly understand what do you want. If you do `git clone` on a client, then a mere call to git rev-parse HEAD would show you the SHA-1 name of the commit which is currently checked out to the work tree of that client's clone. Is this enough for your case? If you want to identify a commit in a Git repository having just a tree of (unmodified) sources checked out some time earlier, this task is more complicated: you could commit this whole tree and get the SHA-1 hash name of the root tree object. Getting the name of a commit object which references the same tree object in a master repository is, unfortunately, an O(N) task: you'll have to traverse all the commits and check the SHA-1 names of the root tree objects they reference. -- 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] Best way to identify a version of a repo
From: Deanna Delapasse To: git-users@googlegroups.com Sent: Friday, June 14, 2013 1:08 PM Subject: [git-users] Best way to identify a version of a repo I need to checkout code from a repo and somehow identify it (timestamp, hash, …) such that at some later time I can extract the SAME versions of all the code. I’m provisioning cloud instances, so each time would be a fresh “get clone” into an empty folder. After I create the “master” (ie provision the FIRST instance) I need to record some way to identify it in case I have to recreate the master.I prefer NOT to alter the original repo (ie tag it), but prefer the ‘work’ of identifying the sources to be done on the client side. Would appreciate any guidance! Deanna Isn't the URL and sha1 sufficient? The URL gets you to the repo, and the sha1 gets the commit. You add the output of `git describe` to give a bit of context. 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.
Re: [git-users] Best way to identify a version of a repo
Maybe - I wasn't sure if the commit hash would give me JUST the recently committed files or the entire codebase. I'll try it. On Fri, Jun 14, 2013 at 7:55 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Fri, 14 Jun 2013 05:08:11 -0700 (PDT) Deanna Delapasse ddelapa...@gmail.com wrote: I need to checkout code from a repo and somehow identify it (timestamp, hash, …) such that at some later time I can extract the SAME versions of all the code. I’m provisioning cloud instances, so each time would be a fresh “get clone” into an empty folder. After I create the “master” (ie provision the FIRST instance) I need to record some way to identify it in case I have to recreate the master.I prefer NOT to alter the original repo (ie tag it), but prefer the ‘work’ of identifying the sources to be done on the client side. I'm not sure I exactly understand what do you want. If you do `git clone` on a client, then a mere call to git rev-parse HEAD would show you the SHA-1 name of the commit which is currently checked out to the work tree of that client's clone. Is this enough for your case? If you want to identify a commit in a Git repository having just a tree of (unmodified) sources checked out some time earlier, this task is more complicated: you could commit this whole tree and get the SHA-1 hash name of the root tree object. Getting the name of a commit object which references the same tree object in a master repository is, unfortunately, an O(N) task: you'll have to traverse all the commits and check the SHA-1 names of the root tree objects they reference. -- 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] Best way to identify a version of a repo
On Fri, 14 Jun 2013 08:23:46 -0500 Deanna Delapasse ddelapa...@gmail.com wrote: Maybe - I wasn't sure if the commit hash would give me JUST the recently committed files or the entire codebase. I'll try it. Neither. Each commit references one complete snapshot of the repository, and also it references one or more parent commits. So, knowing the SHA-1 name of a commit gives you: 1) A way to recreate the precise state of the repository as it was when that commit was recorded [*]. 2) An ability to go back through the commit's ancestry line. 3) Certain other bits of meta information about the commit author, the committer, the date the commit was recorded etc. Each commit in the repository has its own distinct SHA-1 name and captures its own distinct state of the repository. [*] That's not exactly true: commits are cut from the so-called staging area, not from the work tree. And certain information attached to files by the file system underlying the work tree (such as NTFS file streams and Unix permission bits and owner/group information) will be lost. -- 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 integration with Siebel 8.1 Tools
Hi Scott, Greetings We have a requirement of integrating CVS with Siebel 8.1, Can you please share the details of the same, it would be very helpful. Thanks in Advance Kind Regards, Suraj On Friday, 10 May 2013 14:39:53 UTC+5:30, Scott Wilson wrote: Hi Ajay, We've integrated Siebel using CVS and it works OK. Although Siebel provides a file for integrating with VSS, Siebel Tools provides a hook so you can call any script executable you like. It gets called whenever you check in/out a project and gives you a sif file of the project you're dealing with. This script can do whatever you want it to do, so as long as you know what you want to do with GIT, you should be OK The only drawbacks are that it's a bit fiddly to get working the way you want it, and that Tools will call your process for every project. So, if you're checking in multiple projects, the process gets called multiple times, rather than once If you'd like more detail of what we do, let me know Hope that helps Scott On Friday, 3 May 2013 17:24:10 UTC+1, Ajay Solleti wrote: Hi, We are trying to understand if we can use GIT to integrate with Siebel 8.1 Tools. Siebel by default provides Client-Server repository control. However, we need an alternative version control system in place to mange all our releases across projects. Any advice or help will be really helpful. Ajay -- 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] Best way to identify a version of a repo
Thanks Konstantin, I started with this approach yesterday. I tried this: git clone https://acct:p...@gethub.com/git ... i edited a file just to see what would happen git checkout hashcodeOfPriorCommit But git did NOT overwrite the file that I manually changed. Why was that? FYI, this won't happen in 'real life but I was trying to convince myself that the checkout would work. On Fri, Jun 14, 2013 at 9:34 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Fri, 14 Jun 2013 08:23:46 -0500 Deanna Delapasse ddelapa...@gmail.com wrote: Maybe - I wasn't sure if the commit hash would give me JUST the recently committed files or the entire codebase. I'll try it. Neither. Each commit references one complete snapshot of the repository, and also it references one or more parent commits. So, knowing the SHA-1 name of a commit gives you: 1) A way to recreate the precise state of the repository as it was when that commit was recorded [*]. 2) An ability to go back through the commit's ancestry line. 3) Certain other bits of meta information about the commit author, the committer, the date the commit was recorded etc. Each commit in the repository has its own distinct SHA-1 name and captures its own distinct state of the repository. [*] That's not exactly true: commits are cut from the so-called staging area, not from the work tree. And certain information attached to files by the file system underlying the work tree (such as NTFS file streams and Unix permission bits and owner/group information) will be lost. -- 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] Best way to identify a version of a repo
On Fri, 14 Jun 2013 10:26:52 -0500 Deanna Delapasse ddelapa...@gmail.com wrote: I started with this approach yesterday. I tried this: git clone https://acct:p...@gethub.com/git ... i edited a file just to see what would happen git checkout hashcodeOfPriorCommit But git did NOT overwrite the file that I manually changed. Why was that? FYI, this won't happen in 'real life but I was trying to convince myself that the checkout would work. One thing I forgot to mention, is that it's pretty easy to reset the work tree after a checkout to discard all local changes by either doing git reset --hard or git checkout -- . (the dot is significant -- it means the current directory). -- 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] Difficulty adding a symbolic link
From: PJ Weisberg pjweisb...@gmail.com I would bet that /dev/dvd is on a different filesystem than the repository, and /etc/hosts is not. Not that that explains/solves your problem; I'm just speculating on what the difference might be. Git has no problem with symlinks in a more traditionally laid-out repository, so I doubt it's that. Interesting point: I created /etc/hosts.link as a link to /etc/hosts, and Git handled it properly. 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] Best way to identify a version of a repo
The other option is to use an orphan branch http://stackoverflow.com/a/4288660/717355 This keeps the parts independent while in the same repo, but using the tree sha1 you should be able to confirm where it came from. I believe you can use gitolite for access control to branches in the repo, but I've not used it. [The tree sha1 is the sha1 has of the committed work tree, independent of any of the history, commit message or date information, so if you have the same (identical) directory content and file names at two different points in history they still have the same tree sha1] Philip - Original Message - From: Deanna Delapasse To: Philip Oakley Sent: Friday, June 14, 2013 2:23 PM Subject: Re: [git-users] Best way to identify a version of a repo Maybe - I'm very new to this. I'll try it. On Fri, Jun 14, 2013 at 8:05 AM, Philip Oakley philipoak...@iee.org wrote: From: Deanna Delapasse To: git-users@googlegroups.com Sent: Friday, June 14, 2013 1:08 PM Subject: [git-users] Best way to identify a version of a repo I need to checkout code from a repo and somehow identify it (timestamp, hash, …) such that at some later time I can extract the SAME versions of all the code. I’m provisioning cloud instances, so each time would be a fresh “get clone” into an empty folder. After I create the “master” (ie provision the FIRST instance) I need to record some way to identify it in case I have to recreate the master.I prefer NOT to alter the original repo (ie tag it), but prefer the ‘work’ of identifying the sources to be done on the client side. Would appreciate any guidance! Deanna Isn't the URL and sha1 sufficient? The URL gets you to the repo, and the sha1 gets the commit. You add the output of `git describe` to give a bit of context. Philip No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3345 / Virus Database: 3199/6409 - Release Date: 06/13/13 -- 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] Best way to identify a version of a repo
This code is ONLY used one time, extracted, built and then deleted. Thanks for the help! I will do more reading over the weekend. On Fri, Jun 14, 2013 at 11:05 AM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Fri, 14 Jun 2013 10:26:52 -0500 Deanna Delapasse ddelapa...@gmail.com wrote: I started with this approach yesterday. I tried this: git clone https://acct:p...@gethub.com/git ... i edited a file just to see what would happen git checkout hashcodeOfPriorCommit But git did NOT overwrite the file that I manually changed. Why was that? FYI, this won't happen in 'real life but I was trying to convince myself that the checkout would work. One thing I forgot to mention, is that it's pretty easy to reset the work tree after a checkout to discard all local changes by either doing git reset --hard or git checkout -- . (the dot is significant -- it means the current directory). -- 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] glassware
are there any developers interested in working with glassware? -- 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.
