* git (commit|tag) atomicity
@ 2012-02-28 15:40 Jon Jagger
2012-02-28 16:46 ` Holger Hellmuth
0 siblings, 1 reply; 6+ messages in thread
From: Jon Jagger @ 2012-02-28 15:40 UTC (permalink / raw)
To: git
Hi,
I don't know a lot about git - I use it as a tool behind
http://cyber-dojo.com
which is an online coding dojo server.
I have a quick question...
If I do a
git commit ....
in one thread and a
git tag | sort -g
in another thread is the output of the git tag guaranteed to be atomic?
That is, the output will be from before the git commit or after it but
not a mixture?
Logically, I assume so but cannot find anything definitive on google
or in my git books or from the lips of my friends.
Thanks for any help
Jon Jagger
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git (commit|tag) atomicity
2012-02-28 15:40 git (commit|tag) atomicity Jon Jagger
@ 2012-02-28 16:46 ` Holger Hellmuth
2012-02-28 17:12 ` Jon Jagger
0 siblings, 1 reply; 6+ messages in thread
From: Holger Hellmuth @ 2012-02-28 16:46 UTC (permalink / raw)
To: Jon Jagger; +Cc: git
On 28.02.2012 16:40, Jon Jagger wrote:
> Hi,
> I don't know a lot about git - I use it as a tool behind
> http://cyber-dojo.com
> which is an online coding dojo server.
> I have a quick question...
> If I do a
> git commit ....
> in one thread and a
> git tag | sort -g
> in another thread is the output of the git tag guaranteed to be atomic?
Can a "git commit" add or remove tags? AFAIK it can't and so the two
commands don't conflict in any way.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git (commit|tag) atomicity
2012-02-28 16:46 ` Holger Hellmuth
@ 2012-02-28 17:12 ` Jon Jagger
2012-02-28 17:41 ` Jakub Narebski
0 siblings, 1 reply; 6+ messages in thread
From: Jon Jagger @ 2012-02-28 17:12 UTC (permalink / raw)
To: git
On Tue, Feb 28, 2012 at 4:46 PM, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> On 28.02.2012 16:40, Jon Jagger wrote:
>>
>> Hi,
>> I don't know a lot about git - I use it as a tool behind
>> http://cyber-dojo.com
>> which is an online coding dojo server.
>> I have a quick question...
>> If I do a
>> git commit ....
>> in one thread and a
>> git tag | sort -g
>> in another thread is the output of the git tag guaranteed to be atomic?
>
>
> Can a "git commit" add or remove tags? AFAIK it can't and so the two
> commands don't conflict in any way.
Sorry, I failed to ask the question I really wanted to ask...
I mean in one thread
git tag -m 'AAA' BBB HEAD
and in another thread
git tag | sort -g
and the question is whether the output of the git tag|sort -g command
is guaranteed to be from before the git tag -m... or from after the
git tag -m... but not "interleaved" in any way....
Cheers
Jon
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git (commit|tag) atomicity
2012-02-28 17:12 ` Jon Jagger
@ 2012-02-28 17:41 ` Jakub Narebski
2012-02-28 18:57 ` Zach Brown
0 siblings, 1 reply; 6+ messages in thread
From: Jakub Narebski @ 2012-02-28 17:41 UTC (permalink / raw)
To: Jon Jagger; +Cc: git, Holger Hellmuth
Jon Jagger <jon@jaggersoft.com> writes:
> On Tue, Feb 28, 2012 at 4:46 PM, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> > On 28.02.2012 16:40, Jon Jagger wrote:
>>>
>>> I don't know a lot about git - I use it as a tool behind
>>> http://cyber-dojo.com
>>> which is an online coding dojo server.
>>> I have a quick question...
>>> If I do a
>>> git commit ....
>>> in one thread and a
>>> git tag | sort -g
>>> in another thread is the output of the git tag guaranteed to be atomic?
>>
>> Can a "git commit" add or remove tags? AFAIK it can't and so the two
>> commands don't conflict in any way.
>
> Sorry, I failed to ask the question I really wanted to ask...
>
> I mean in one thread
> git tag -m 'AAA' BBB HEAD
> and in another thread
> git tag | sort -g
>
> and the question is whether the output of the git tag|sort -g command
> is guaranteed to be from before the git tag -m... or from after the
> git tag -m... but not "interleaved" in any way....
Creating a tag or a commit is guaranteed to be atomic. Git first
atomically adds tag or a commit to object database (atomic file write)
as loose object, then atomically writes tag reference as loose tag
('.git/refs/tags/foo' file, containing SHA-1 id of newly created tag).
"git tag", which list all tags, recursively scans (reads) 'refs/tags/'
directory, so it could theoretically happen that if you have very
large number of loose (unpacked) tags, "git tag" might theoretically
list tag 'zzz' created after start of command, but not list 'aaa' tag
created after start of command.
But I am not sure... that probably depends on how opendir(3) and
readdir(3) works on given filesystem wrt. updates to opened directory.
I think VFS on Linux ensures that you see view of filesystem as it was
on opendir().
--
Jakub Narebski
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: git (commit|tag) atomicity
2012-02-28 17:41 ` Jakub Narebski
@ 2012-02-28 18:57 ` Zach Brown
2012-02-28 20:43 ` Jon Jagger
0 siblings, 1 reply; 6+ messages in thread
From: Zach Brown @ 2012-02-28 18:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jon Jagger, git, Holger Hellmuth
It's a bit of a tangent, but just to be sure people don't get the wrong
impression..
> But I am not sure... that probably depends on how opendir(3) and
> readdir(3) works on given filesystem wrt. updates to opened directory.
> I think VFS on Linux ensures that you see view of filesystem as it was
> on opendir().
No, readdir() does not give you a static view of the entries in a
directory as it was on opendir(). readdir() will reflect modifications
that are done after opendir(). The specifics for a given situation
depend on how the file system maps the readdir position (f_pos) to
directory entries. You can see very different results when comparing,
say, stock ext2, indexed ext[34], and btrfs.
- z
(your message probably caught my eye because telldir()/seekdir() is
*loathed* by file system designers)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: git (commit|tag) atomicity
2012-02-28 18:57 ` Zach Brown
@ 2012-02-28 20:43 ` Jon Jagger
0 siblings, 0 replies; 6+ messages in thread
From: Jon Jagger @ 2012-02-28 20:43 UTC (permalink / raw)
To: git
On Tue, Feb 28, 2012 at 6:57 PM, Zach Brown <zab@zabbo.net> wrote:
>
> It's a bit of a tangent, but just to be sure people don't get the wrong
> impression..
>
>
>> But I am not sure... that probably depends on how opendir(3) and
>> readdir(3) works on given filesystem wrt. updates to opened directory.
>> I think VFS on Linux ensures that you see view of filesystem as it was
>> on opendir().
>
>
> No, readdir() does not give you a static view of the entries in a
> directory as it was on opendir(). readdir() will reflect modifications
> that are done after opendir(). The specifics for a given situation
> depend on how the file system maps the readdir position (f_pos) to
> directory entries. You can see very different results when comparing,
> say, stock ext2, indexed ext[34], and btrfs.
Ok. Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-02-28 20:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-28 15:40 git (commit|tag) atomicity Jon Jagger
2012-02-28 16:46 ` Holger Hellmuth
2012-02-28 17:12 ` Jon Jagger
2012-02-28 17:41 ` Jakub Narebski
2012-02-28 18:57 ` Zach Brown
2012-02-28 20:43 ` Jon Jagger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).