{"thread":{"id":"29778","subject":"git (commit|tag) atomicity","startedAt":"2012-02-28T15:40:09Z","lastAt":"2012-02-28T20:43:21Z","messageCount":6,"participants":["Jon Jagger","Holger Hellmuth","Jakub Narebski","Zach Brown"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"185629","messageId":"CADWOt=j8gJvr88eNAfoYq_qGQvG6M_k-9MCuof_DRrH0sHRVCA@mail.gmail.com","threadId":"29778","inReplyTo":null,"subject":"git (commit|tag) atomicity","fromName":"Jon Jagger","fromEmail":"jon@jaggersoft.com","sentAt":"2012-02-28T15:40:09Z","receivedAt":"2012-02-28T15:40:09Z","isPatch":false,"sender":{"key":"jon@jaggersoft.com","avatar":"https://gravatar.com/avatar/5e11dcd7b4c298022da2e37455fbe0249dee8bb79cf4342f6a4dd10040153ff8?d=mp&s=160"},"body":"Hi,\nI don't know a lot about git - I use it as a tool behind\nhttp://cyber-dojo.com\nwhich is an online coding dojo server.\nI have a quick question...\nIf I do a\n git commit ....\nin one thread and a\n git tag | sort -g\nin another thread is the output of the git tag guaranteed to be atomic?\nThat is, the output will be from before the git commit or after it but\nnot a mixture?\nLogically, I assume so but cannot find anything definitive on google\nor in my git books or from the lips of my friends.\nThanks for any help\nJon Jagger\n"},{"id":"185632","messageId":"4F4D04F4.80905@ira.uka.de","threadId":"29778","inReplyTo":"CADWOt=j8gJvr88eNAfoYq_qGQvG6M_k-9MCuof_DRrH0sHRVCA@mail.gmail.com","subject":"Re: git (commit|tag) atomicity","fromName":"Holger Hellmuth","fromEmail":"hellmuth@ira.uka.de","sentAt":"2012-02-28T16:46:44Z","receivedAt":"2012-02-28T16:46:44Z","isPatch":false,"sender":{"key":"hellmuth@ira.uka.de","avatar":null},"body":"On 28.02.2012 16:40, Jon Jagger wrote:\n> Hi,\n> I don't know a lot about git - I use it as a tool behind\n> http://cyber-dojo.com\n> which is an online coding dojo server.\n> I have a quick question...\n> If I do a\n> git commit ....\n> in one thread and a\n> git tag | sort -g\n> in another thread is the output of the git tag guaranteed to be atomic?\n\nCan a \"git commit\" add or remove tags? AFAIK it can't and so the two \ncommands don't conflict in any way.\n"},{"id":"185633","messageId":"CADWOt=ig5=Bhhkjs9-wbm2djtwWPOfPGtYt9pH-U3YuQ+iyXzg@mail.gmail.com","threadId":"29778","inReplyTo":"4F4D04F4.80905@ira.uka.de","subject":"Re: git (commit|tag) atomicity","fromName":"Jon Jagger","fromEmail":"jon@jaggersoft.com","sentAt":"2012-02-28T17:12:54Z","receivedAt":"2012-02-28T17:12:54Z","isPatch":false,"sender":{"key":"jon@jaggersoft.com","avatar":"https://gravatar.com/avatar/5e11dcd7b4c298022da2e37455fbe0249dee8bb79cf4342f6a4dd10040153ff8?d=mp&s=160"},"body":"On Tue, Feb 28, 2012 at 4:46 PM, Holger Hellmuth wrote:\n> On 28.02.2012 16:40, Jon Jagger wrote:\n>>\n>> Hi,\n>> I don't know a lot about git - I use it as a tool behind\n>> http://cyber-dojo.com\n>> which is an online coding dojo server.\n>> I have a quick question...\n>> If I do a\n>>    git commit ....\n>> in one thread and a\n>>    git tag | sort -g\n>> in another thread is the output of the git tag guaranteed to be atomic?\n>\n>\n> Can a \"git commit\" add or remove tags? AFAIK it can't and so the two\n> commands don't conflict in any way.\n\nSorry, I failed to ask the question I really wanted to ask...\n\nI mean in one thread\n git tag -m 'AAA' BBB HEAD\nand in another thread\n git tag | sort -g\n\nand the question is whether the output of the git tag|sort -g command\nis guaranteed to be from before the git tag -m... or from after the\ngit tag -m... but not \"interleaved\" in any way....\n\nCheers\nJon\n"},{"id":"185641","messageId":"m3aa42vosb.fsf@localhost.localdomain","threadId":"29778","inReplyTo":"CADWOt=ig5=Bhhkjs9-wbm2djtwWPOfPGtYt9pH-U3YuQ+iyXzg@mail.gmail.com","subject":"Re: git (commit|tag) atomicity","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-02-28T17:41:28Z","receivedAt":"2012-02-28T17:41:28Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jon Jagger writes:\n> On Tue, Feb 28, 2012 at 4:46 PM, Holger Hellmuth wrote:\n> > On 28.02.2012 16:40, Jon Jagger wrote:\n>>>\n>>> I don't know a lot about git - I use it as a tool behind\n>>> http://cyber-dojo.com\n>>> which is an online coding dojo server.\n>>> I have a quick question...\n>>> If I do a\n>>>    git commit ....\n>>> in one thread and a\n>>>    git tag | sort -g\n>>> in another thread is the output of the git tag guaranteed to be atomic?\n>>\n>> Can a \"git commit\" add or remove tags? AFAIK it can't and so the two\n>> commands don't conflict in any way.\n> \n> Sorry, I failed to ask the question I really wanted to ask...\n> \n> I mean in one thread\n> git tag -m 'AAA' BBB HEAD\n> and in another thread\n> git tag | sort -g\n> \n> and the question is whether the output of the git tag|sort -g command\n> is guaranteed to be from before the git tag -m... or from after the\n> git tag -m... but not \"interleaved\" in any way....\n\nCreating a tag or a commit is guaranteed to be atomic. Git first\natomically adds tag or a commit to object database (atomic file write)\nas loose object, then atomically writes tag reference as loose tag\n('.git/refs/tags/foo' file, containing SHA-1 id of newly created tag).\n\n\"git tag\", which list all tags, recursively scans (reads) 'refs/tags/'\ndirectory, so it could theoretically happen that if you have very\nlarge number of loose (unpacked) tags, \"git tag\" might theoretically\nlist tag 'zzz' created after start of command, but not list 'aaa' tag\ncreated after start of command.\n\nBut I am not sure... that probably depends on how opendir(3) and\nreaddir(3) works on given filesystem wrt. updates to opened directory.\nI think VFS on Linux ensures that you see view of filesystem as it was\non opendir().\n\n-- \nJakub Narebski\n"},{"id":"185651","messageId":"4F4D2391.9020701@zabbo.net","threadId":"29778","inReplyTo":"m3aa42vosb.fsf@localhost.localdomain","subject":"Re: git (commit|tag) atomicity","fromName":"Zach Brown","fromEmail":"zab@zabbo.net","sentAt":"2012-02-28T18:57:21Z","receivedAt":"2012-02-28T18:57:21Z","isPatch":false,"sender":{"key":"zab@zabbo.net","avatar":null},"body":"\nIt's a bit of a tangent, but just to be sure people don't get the wrong\nimpression..\n\n> But I am not sure... that probably depends on how opendir(3) and\n> readdir(3) works on given filesystem wrt. updates to opened directory.\n> I think VFS on Linux ensures that you see view of filesystem as it was\n> on opendir().\n\nNo, readdir() does not give you a static view of the entries in a\ndirectory as it was on opendir(). readdir() will reflect modifications\nthat are done after opendir(). The specifics for a given situation\ndepend on how the file system maps the readdir position (f_pos) to\ndirectory entries. You can see very different results when comparing,\nsay, stock ext2, indexed ext[34], and btrfs.\n\n- z\n(your message probably caught my eye because telldir()/seekdir() is\n*loathed* by file system designers)\n"},{"id":"185672","messageId":"CADWOt=iz91AjBbkrc6cJqSqadyP9nDqBg92j0qDwBmHxkSUqZg@mail.gmail.com","threadId":"29778","inReplyTo":"4F4D2391.9020701@zabbo.net","subject":"Re: git (commit|tag) atomicity","fromName":"Jon Jagger","fromEmail":"jon@jaggersoft.com","sentAt":"2012-02-28T20:43:21Z","receivedAt":"2012-02-28T20:43:21Z","isPatch":false,"sender":{"key":"jon@jaggersoft.com","avatar":"https://gravatar.com/avatar/5e11dcd7b4c298022da2e37455fbe0249dee8bb79cf4342f6a4dd10040153ff8?d=mp&s=160"},"body":"On Tue, Feb 28, 2012 at 6:57 PM, Zach Brown wrote:\n>\n> It's a bit of a tangent, but just to be sure people don't get the wrong\n> impression..\n>\n>\n>> But I am not sure... that probably depends on how opendir(3) and\n>> readdir(3) works on given filesystem wrt. updates to opened directory.\n>> I think VFS on Linux ensures that you see view of filesystem as it was\n>> on opendir().\n>\n>\n> No, readdir() does not give you a static view of the entries in a\n> directory as it was on opendir().  readdir() will reflect modifications\n> that are done after opendir().  The specifics for a given situation\n> depend on how the file system maps the readdir position (f_pos) to\n> directory entries.  You can see very different results when comparing,\n> say, stock ext2, indexed ext[34], and btrfs.\n\nOk. Thanks.\n"}]}