{"thread":{"id":"1642","subject":"Storing state in $GIT_DIR","startedAt":"2005-08-25T03:32:57Z","lastAt":"2005-08-27T00:23:10Z","messageCount":17,"participants":["Martin Langhoff","Linus Torvalds","Junio C Hamano","Eric W. Biederman","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"7738","messageId":"46a038f905082420323b025e3b@mail.gmail.com","threadId":"1642","inReplyTo":null,"subject":"Storing state in $GIT_DIR","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-25T03:32:57Z","receivedAt":"2005-08-25T03:32:57Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Is there a convention of where/how it is safe to store additional\n(non-git) data in $GIT_DIR?\n\nThe arch import needs to keep a cache with arch-commit-id  =\ngit-commit-id mappings, and some notes about what patch-trading Arch\nrecorded. It'd be great to be able to store those in\n$GIT_DIR/archimport/ . Is that supported?\n\nIt does not need to be replicated with push or pull, merely preserved. \n\ncheers,\n\n\nmartin\n"},{"id":"7750","messageId":"Pine.LNX.4.58.0508251053000.3317@g5.osdl.org","threadId":"1642","inReplyTo":"46a038f905082420323b025e3b@mail.gmail.com","subject":"Re: Storing state in $GIT_DIR","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-25T18:16:00Z","receivedAt":"2005-08-25T18:16:00Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\n[ Junio, the fact that you can't script the initial commit with \"git \n  commit\" is _really_ irritating. ]\n\nOn Thu, 25 Aug 2005, Martin Langhoff wrote:\n>\n> Is there a convention of where/how it is safe to store additional\n> (non-git) data in $GIT_DIR?\n\nThere's no convention, but I have a suggestion.\n\n> The arch import needs to keep a cache with arch-commit-id  =\n> git-commit-id mappings, and some notes about what patch-trading Arch\n> recorded. It'd be great to be able to store those in\n> $GIT_DIR/archimport/ . Is that supported?\n\nGit won't care, so it will work, but things like clone/pull etc also won't\nactually ever look there, so it will only work for that one repo.\n\nNow, I have what I consider a clever idea (I've mentioned variations on it \nbefore), but it's entirely possible that people hate it.\n\nThe thing is, I think you _do_ want to revision-control the git-commit-id\nmappings, but at the same time, you do _not_ want to mess up the resulting\ngit commit history with arch information.\n\nThe reason you want to revision-control them is that that way you get them \non clones, and you can use push/pull to update them. And the reason you \ndon't want to mess up the commit history is that it's just wrong and ugly.\n\nThe git solution to this (which nobody has ever _used_, but which\ntechnically is wonderful) is to have a \"side branch\" that does not share\nany commits (or files, for that matter) in common with the \"real branch\",\nand which is used to track any metadata. In fact, you can obviously have \nany number of side branches.\n\nSo that \"metadata branch\" is a real git branch in its own right, but it\ndoesn't share the same root as the \"normal\" branch, and it's really\ntotally independent: you can pull just the main branch (ie somebody who\nisn't arch-aware and has no reason to want the arch mappings), or you\ncould pull just the metadata branch (for example, somebody who doesn't\nwant to use git, but is trying to match up a git commit ID to whatever\nID's arch uses).\n\nThe way to maintain a metadata branch is to have not only a different \nbranch name (obviously), but also use a totally different index file, so \nthat you can index both branches in parallell, and you don't actually need \nto check out one or the other.\n\nNow, your arch import tools would then use the raw git commands explicitly \nto maintain the metadata branch. Every time you do an incremental import \nfrom an arch project, your import scripts would save away the mapping \ninformation into the metadata branch.\n\nI'll make a _really_ stupid example for you, just to make this a bit more \nconcrete:\n\n\tmkdir silly-example\n\tcd silly-example\n\n\t#\n\t# The normal \"main branch\": use regular git\n\t# infrastructure\n\t#\n\tgit init-db\n\techo \"Hello\" > file\n\tgit update-cache --add file\n\tgit commit -m \"Main branch\"\n\n\t#\n\t# The metadata branch: magic, very special stuff\n\t#\n\techo \"initial commit:\" $(git-rev-parse HEAD) > .archdata\n\tGIT_INDEX_FILE=.git/archindex git-update-cache --add .archdata\n\tarch_index_tree=$(GIT_INDEX_FILE=.git/archindex git-write-tree)\n\techo \"arch index\" | git-commit-tree $arch_index_tree > .git/refs/heads/arch-index\n\n(Btw, the above example shows that the initial \"git commit\" won't take a \n\"-m\" flag, which is really irritating for scripts.)\n\nThen do a \"gitk --all\", see the two different branches, and realize that \nthe \"arch-index\" branch can now contain all the tracking information \nnecessary to go back-and-forth. \n\n\t\tLinus\n"},{"id":"7773","messageId":"46a038f905082518306e9d7d2a@mail.gmail.com","threadId":"1642","inReplyTo":"Pine.LNX.4.58.0508251053000.3317@g5.osdl.org","subject":"Re: Storing state in $GIT_DIR","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-26T01:30:46Z","receivedAt":"2005-08-26T01:30:46Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"Linus, \n\nI like the solution you are suggesting, but I suspect it will create\nmore problems that it will solve, and while the coolness factor is\ndrawing me in.... we ain't gonna need it, as the xp people say.\n\nMore below...\n\nOn 8/26/05, Linus Torvalds <torvalds@osdl.org> wrote:\n> Git won't care, so it will work, but things like clone/pull etc also won't\n> actually ever look there, so it will only work for that one repo.\n\nStoring things there _works_ in the sense that it will be ignored, and\nthat is fine with me. So I could just be lazy and have it strictly\ntied to the repo. In practice, if you are tracking an external Arch\nrepo, you really have it scripted, and use a dedicated git repo for\nthat.\n\nNot using a dedicated repo is quite... messy. If you do other things\nin that particular repo, the import script may find it dirty, and mess\nthings up on import. And after the import, you'll probably run\ngit-push-script --all because it's bringing a dynamically growing\nforest of heads from the arch repo. That's another reason why your\nprivate branches should be elsewhere.\n\nOTOH, storing the metadata in a branch will allow us to run the import\nin alternating repositories. But as Junio points out, unless I can\nguarantee that the metadata and the tree are in sync, I cannot\ntrivially resume the import cycle from a new repo.\n\n> The git solution to this (which nobody has ever _used_, but which\n> technically is wonderful) is to have a \"side branch\" that does not share\n> any commits (or files, for that matter) in common with the \"real branch\",\n> and which is used to track any metadata. In fact, you can obviously have\n> any number of side branches.\n\nA couple of days ago, playing with the import, I realised that the git\nrepo can hold unrelated projects, too, if you just commit orphan trees\nas new heads. I mean - it was a bug in my script but I thought it was\ncool. ;)\n\n> The way to maintain a metadata branch is to have not only a different\n> branch name (obviously), but also use a totally different index file, so\n> that you can index both branches in parallell, and you don't actually need\n> to check out one or the other.\n\nHmmm. Now that's voodoo magic! I was thinking of reading the file by\nasking directly for the object by its sha, or doing a checkout in a\ntmpdir. Interesting.\n\ncheers,\n\n\nmartin\n"},{"id":"7774","messageId":"46a038f905082518575b84bf66@mail.gmail.com","threadId":"1642","inReplyTo":"7vwtm9u5jj.fsf@assigned-by-dhcp.cox.net","subject":"Re: Storing state in $GIT_DIR","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-26T01:57:27Z","receivedAt":"2005-08-26T01:57:27Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/26/05, Junio C Hamano <junkio@cox.net> wrote:\n> If I am not mistaken, we have another foreign SCM import\n> interface that can repeatedly slurp from the same foreign SCM to\n> get updates.  Doesn't cvsimport have the same issue?  \n\nYes and no. \n\ncvsimport uses cvsps which uses in ~/.cvsps as a cache. Other than\nthat, all the info is transient - cvsimport doesn't need to know that\nmuch about past commits -- when it sees BRANCH_A_A1 open from BRANCH_A\nit opens a new head BRANCH_A_A1 with the parent in the _latest_\nBRANCH_A.\n\nThis is a bug/limitation that only hits you when you are tracking an\nevolving cvs project, because cvsps will otherwise mark the branching\npoint in order, right after the 'correct' commit. IOW cvsimport gets\nit kind-of-right most of the time due to cvsps behaviour and sheer\nluck, but doesn't do it strictly right either.\n\nWith Arch, we cannot even fake it. We see the branch in its own time,\nand it can branch off any point in the source branch history. We have\nthe correct parent information -- it'd be silly to drop it. All we\nhave to do, is map the parents correctly...\n\ncheers,\n\n\nmartin\n"},{"id":"7782","messageId":"7vzmr5laj4.fsf@assigned-by-dhcp.cox.net","threadId":"1642","inReplyTo":"Pine.LNX.4.58.0508251053000.3317@g5.osdl.org","subject":"[PATCH] Accept -m and friends for initial commits and merge commits.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-26T02:03:27Z","receivedAt":"2005-08-26T02:03:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yes it was irritating.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n\n---\n\n    Linus Torvalds <torvalds@osdl.org> writes:\n    > [ Junio, the fact that you can't script the initial commit with \"git \n    >   commit\" is _really_ irritating. ]\n\n git-commit-script |   86 ++++++++++++++++++++++++-----------------------------\n 1 files changed, 39 insertions(+), 47 deletions(-)\n\nc038244ac9260c8c895bf791ff587103bacadaba\ndiff --git a/git-commit-script b/git-commit-script\n--- a/git-commit-script\n+++ b/git-commit-script\n@@ -110,57 +110,51 @@ t)\n \tfi\n esac\n \n+if [ ! -r \"$GIT_DIR/HEAD\" ]\n+then\n+\techo \"#\"\n+\techo \"# Initial commit\"\n+\techo \"#\"\n+\tgit-ls-files | sed 's/^/# New file: /'\n+\techo \"#\"\n+elif [ -f \"$GIT_DIR/MERGE_HEAD\" ]; then\n+\techo \"#\"\n+\techo \"# It looks like your may be committing a MERGE.\"\n+\techo \"# If this is not correct, please remove the file\"\n+\techo \"#\t$GIT_DIR/MERGE_HEAD\"\n+\techo \"# and try again\"\n+\techo \"#\"\n+fi >.editmsg\n+if test \"$log_message\" != ''\n+then\n+\techo \"$log_message\"\n+elif test \"$logfile\" != \"\"\n+then\n+\tif test \"$logfile\" = -\n+\tthen\n+\t\ttest -t 0 &&\n+\t\techo >&2 \"(reading log message from standard input)\"\n+\t\tcat\n+\telse\n+\t\tcat <\"$logfile\"\n+\tfi\n+elif test \"$use_commit\" != \"\"\n+then\n+\tgit-cat-file commit \"$use_commit\" | sed -e '1,/^$/d'\n+fi | git-stripspace >>.editmsg\n+\n PARENTS=\"-p HEAD\"\n if [ ! -r \"$GIT_DIR/HEAD\" ]; then\n \tif [ -z \"$(git-ls-files)\" ]; then\n \t\techo Nothing to commit 1>&2\n \t\texit 1\n \tfi\n-\t{\n-\t\techo \"#\"\n-\t\techo \"# Initial commit\"\n-\t\tcase \"$no_edit\" in\n-\t\tt) echo \"# (ignoring your commit message for initial commit)\"\n-\t\t   no_edit= \n-\t\tesac\n-\t\techo \"#\"\n-\t\tgit-ls-files | sed 's/^/# New file: /'\n-\t\techo \"#\"\n-\t} >.editmsg\n \tPARENTS=\"\"\n-\tno_edit=\n else\n \tif [ -f \"$GIT_DIR/MERGE_HEAD\" ]; then\n-\t\t{\n-\t\techo \"#\"\n-\t\techo \"# It looks like your may be committing a MERGE.\"\n-\t\techo \"# If this is not correct, please remove the file\"\n-\t\techo \"#\t$GIT_DIR/MERGE_HEAD\"\n-\t\techo \"# and try again\"\n-\t\tcase \"$no_edit\" in\n-\t\tt) echo \"# (ignoring your commit message for merge commit)\"\n-\t\t   no_edit= \n-\t\tesac\n-\t\techo \"#\"\n-\t\t} |\n-\t\tgit-stripspace >.editmsg\n \t\tPARENTS=\"-p HEAD -p MERGE_HEAD\"\n-\telif test \"$log_message\" != ''\n-\tthen\n-\t\techo \"$log_message\" |\n-\t\tgit-stripspace >.editmsg\n-\telif test \"$logfile\" != \"\"\n-\tthen\n-\t\tif test \"$logfile\" = -\n-\t\tthen\n-\t\t\ttest -t 0 &&\n-\t\t\techo >&2 \"(reading log message from standard input)\"\n-\t\t\tcat\n-\t\telse\n-\t\t\tcat <\"$logfile\"\n-\t\tfi |\n-\t\tgit-stripspace >.editmsg\n-\telif test \"$use_commit\" != \"\"\n+\tfi\n+\tif test \"$use_commit\" != \"\"\n \tthen\n \t\tpick_author_script='\n \t\t/^author /{\n@@ -188,22 +182,20 @@ else\n \t\texport GIT_AUTHOR_NAME\n \t\texport GIT_AUTHOR_EMAIL\n \t\texport GIT_AUTHOR_DATE\n-\t\tgit-cat-file commit \"$use_commit\" |\n-\t\tsed -e '1,/^$/d' |\n-\t\tgit-stripspace >.editmsg\n \tfi\n-\n \tcase \"$signoff\" in\n \tt)\n \t\tgit-var GIT_COMMITTER_IDENT | sed -e '\n \t\t\ts/>.*/>/\n-\t\t\ts/^/Signed-off-by: /' >>.editmsg ;;\n+\t\t\ts/^/Signed-off-by: /\n+\t\t' >>.editmsg\n+\t\t;;\n \tesac\n \tgit-status-script >>.editmsg\n fi\n if [ \"$?\" != \"0\" -a ! -f $GIT_DIR/MERGE_HEAD ]\n then\n-\tcat .editmsg\n+\tsed -ne '/^#/p' .editmsg\n \trm .editmsg\n \texit 1\n fi\n"},{"id":"7765","messageId":"Pine.LNX.4.58.0508252051400.3317@g5.osdl.org","threadId":"1642","inReplyTo":"46a038f905082518306e9d7d2a@mail.gmail.com","subject":"Re: Storing state in $GIT_DIR","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-26T03:54:45Z","receivedAt":"2005-08-26T03:54:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 26 Aug 2005, Martin Langhoff wrote:\n> \n> OTOH, storing the metadata in a branch will allow us to run the import\n> in alternating repositories. But as Junio points out, unless I can\n> guarantee that the metadata and the tree are in sync, I cannot\n> trivially resume the import cycle from a new repo.\n\nBut you can.\n\nRemember: the metadata is the pointers to the original git conversion, and \nobjects are immutable.\n\nIn other words, if you just have a \"last commit\" pointer in your \nmeta-data, then git is _by_definition_ in sync. There's never anything to \nget out of sync, because objects aren't going to change.\n\nSo you can think of your meta-data as a strange kind of head ref. Or \nrather, a _collection_ of these strange refs.\n\nAnd it doesn't matter if somebody ends up committing on top of an arch \nimport. The metadata by definition doesn't know about it, so the \"import\" \nhead doesn't move anywhere (if you do git and arch work in parallell, you \ncan then merge the two heads with git, of course).\n\n\t\t\tLinus\n"},{"id":"7789","messageId":"46a038f90508252115415acc04@mail.gmail.com","threadId":"1642","inReplyTo":"Pine.LNX.4.58.0508252051400.3317@g5.osdl.org","subject":"Re: Storing state in $GIT_DIR","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-26T04:15:37Z","receivedAt":"2005-08-26T04:15:37Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/26/05, Linus Torvalds <torvalds@osdl.org> wrote:\n> > OTOH, storing the metadata in a branch will allow us to run the import\n> > in alternating repositories. But as Junio points out, unless I can\n> > guarantee that the metadata and the tree are in sync, I cannot\n> > trivially resume the import cycle from a new repo.\n> \n> But you can.\n> \n> Remember: the metadata is the pointers to the original git conversion, and\n> objects are immutable.\n> \n> In other words, if you just have a \"last commit\" pointer in your\n> meta-data, then git is _by_definition_ in sync. There's never anything to\n> get out of sync, because objects aren't going to change.\n\nHmmm. That repo is in sync, but there are no guarantees that they will\ntravel together to a different repo. In fact, the push/pull\ninfrastructure wants to push/pull one head at a time.\n\nAnd if they are not in sync, I have no way of knowing. Hmpf. I lie:\nthe arch metadata could keep track of what it expects the last head\ncommits to be, and complain bitterly if something smells rotten.\n\nlet me think about it ;)\n\n\nmartin\n"},{"id":"7786","messageId":"7v3boxl3o1.fsf@assigned-by-dhcp.cox.net","threadId":"1642","inReplyTo":"46a038f90508252115415acc04@mail.gmail.com","subject":"Re: Storing state in $GIT_DIR","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-26T04:31:42Z","receivedAt":"2005-08-26T04:31:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n>> In other words, if you just have a \"last commit\" pointer in your\n>> meta-data, then git is _by_definition_ in sync. There's never anything to\n>> get out of sync, because objects aren't going to change.\n>\n> Hmmm. That repo is in sync, but there are no guarantees that they will\n> travel together to a different repo. In fact, the push/pull\n> infrastructure wants to push/pull one head at a time.\n\nWrong as of last week ;-), and definitely wrong since this morning.\n\n> And if they are not in sync, I have no way of knowing. Hmpf. I lie:\n> the arch metadata could keep track of what it expects the last head\n> commits to be, and complain bitterly if something smells rotten.\n\nWhat Linus suggests is doable by using an object that can hold\na pointer to at least one commit---you used that to record the\nhead commit of the corresponding git branch that the arch\nmetainfo represents.\n\nYou only pull arch metainfo branch; the objects associated with\nthe corresponding git branch head will be pulled together when\nyou pull it.  You do not have to tell git to pull git-part of\nthe commit chain.  There is no need to worry about version skew\nwhen you use git this way.\n\nNow, among the existing object types, there are only two kinds\nof objects you can use for this.  If the only thing you need to\nrecord is some textual information with one pointer to git\nbranch head, then you can use tag that points at the git head,\nand store everything else as the tag comment.  This is doable\nbut unwieldy.\n\nYou could abuse a commit object as well; you store commit\nobjects (such as the corresponding git branch head) as parent\ncommits, and put everything else in a tree that is associated\nwith that commit.\n"},{"id":"7785","messageId":"Pine.LNX.4.63.0508260101390.23242@iabervon.org","threadId":"1642","inReplyTo":"7v3boxl3o1.fsf@assigned-by-dhcp.cox.net","subject":"Re: Storing state in $GIT_DIR","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-08-26T05:08:14Z","receivedAt":"2005-08-26T05:08:14Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 25 Aug 2005, Junio C Hamano wrote:\n\n> Now, among the existing object types, there are only two kinds\n> of objects you can use for this.  If the only thing you need to\n> record is some textual information with one pointer to git\n> branch head, then you can use tag that points at the git head,\n> and store everything else as the tag comment.  This is doable\n> but unwieldy.\n\nI don't think this buys you anything, because then the tag needs to be\naccessible from something, which is the same problem you were trying to\nsolve for the commit.\n\n> You could abuse a commit object as well; you store commit\n> objects (such as the corresponding git branch head) as parent\n> commits, and put everything else in a tree that is associated\n> with that commit.\n\nIf you want to go that way, you could add a new field to commits with\nminimal effort: you just need to parse it in commit.c, generate it in\ngit-commit-tree (with an option), and pull it in pull.c, and everything\nshould work as far as making the git portion follow the metadata around.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"7788","messageId":"Pine.LNX.4.58.0508252219520.3317@g5.osdl.org","threadId":"1642","inReplyTo":"Pine.LNX.4.63.0508260101390.23242@iabervon.org","subject":"Re: Storing state in $GIT_DIR","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-26T05:31:35Z","receivedAt":"2005-08-26T05:31:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 26 Aug 2005, Daniel Barkalow wrote:\n> \n> I don't think this buys you anything, because then the tag needs to be\n> accessible from something, which is the same problem you were trying to\n> solve for the commit.\n\nYes. \n\nWe had an earlier discussion somewhat along these lines, where a \n\"collection\" object might be useful. The \"tree\" object is that, of course, \nbut the tree object really is very strictly structured (and has to be that \nway). There might be a valid case for an object that can point to an \narbitrary collection of other objects, and have a free-form tail to it.\n\nOf course, such an object would inevitably look very much like a \ngeneralized \"tag\" object, so one possibility might be to just allow a tag \nto have multiple object pointers.\n\nWe could easily generalize the tag format: just make it be something like\n\n - 1 or more lines of \"object <sha1>\"\n - make the \"type \" line optional (it used to have an implementation \n   reason: the internal interfaces always used to want to know the type \n   up-front, but we've moved away from that).\n - a single \"tag\" line to start the free-form section, and to name the \n   collection some way.\n\nThat kind of extension shouldn't be too hard, and might make tags much \nmore generally usable (ie you could say \"I sign these <n> official \nreleases\" or something).\n\n\t\t\tLinus\n"},{"id":"7790","messageId":"7virxti6y5.fsf@assigned-by-dhcp.cox.net","threadId":"1642","inReplyTo":"Pine.LNX.4.58.0508252219520.3317@g5.osdl.org","subject":"Re: Storing state in $GIT_DIR","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-26T05:49:06Z","receivedAt":"2005-08-26T05:49:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> That kind of extension shouldn't be too hard, and might make tags much \n> more generally usable (ie you could say \"I sign these <n> official \n> releases\" or something).\n\nWell, I admit that once I advocated changing \"tag\" to \"bag\", but\none problem is how you would dereference something like that.\n\n\"v0.99.5^0\" means \"look at the named object v0.99.5, dereference\nit repeatedly until you get a non-tag, and take the result,\nwhich had better be a commit\".  If a tag can contain more than\none pointers, I do not know what it means.\n"},{"id":"7767","messageId":"7v8xypi6s6.fsf@assigned-by-dhcp.cox.net","threadId":"1642","inReplyTo":"Pine.LNX.4.63.0508260101390.23242@iabervon.org","subject":"Re: Storing state in $GIT_DIR","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-08-26T05:52:41Z","receivedAt":"2005-08-26T05:52:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> I don't think this buys you anything, because then the tag needs to be\n> accessible from something, which is the same problem you were trying to\n> solve for the commit.\n\nActually not.  My suggestion was a qualified one: \"If all you\nneed is a textual information plus a single pointer to a commit\nobject\", and Martin did not say different generations of arch\nmetainfo needs to be strung together, so you could keep updating\nthe tag object in \"refs/tags/arch-meta-info\", which has such a\npointer and textual arch meta info and nothing else.\n"},{"id":"7771","messageId":"46a038f905082523431c3b577f@mail.gmail.com","threadId":"1642","inReplyTo":"7v3boxl3o1.fsf@assigned-by-dhcp.cox.net","subject":"Re: Storing state in $GIT_DIR","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-26T06:43:26Z","receivedAt":"2005-08-26T06:43:26Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/26/05, Junio C Hamano <junkio@cox.net> wrote:\n> > Hmmm. That repo is in sync, but there are no guarantees that they will\n> > travel together to a different repo. In fact, the push/pull\n> > infrastructure wants to push/pull one head at a time.\n> \n> Wrong as of last week ;-), and definitely wrong since this morning.\n\nHaven't had time to learn what the new conventions are for push/pull\nscenarios. Will try and read up...\n\n> > And if they are not in sync, I have no way of knowing. Hmpf. I lie:\n> > the arch metadata could keep track of what it expects the last head\n> > commits to be, and complain bitterly if something smells rotten.\n> \n> What Linus suggests is doable by using an object that can hold\n> a pointer to at least one commit---you used that to record the\n> head commit of the corresponding git branch that the arch\n> metainfo represents.\n\nYes. If I have my \"arch-metadata\" head, I can have several files\nthere, one of them containing a list of head \"names\" and the sha we\nexpect them to correspond to. If the thing doesn't match, we crash and\nburn because we are out of sync.\n\nNow, during import I'll have to be extra careful at commit-time, and\nupdate and commit the arch-metadata head immediately after I commit\nthe head I'm importing, with strong error-handling. This should\nminimize the out-of-sync situation.\n\nIf we _are_ out-of-sync, I could have a recovery mode that rewinds the\nheads to the 'last known good' position and replays things forward. If\nmy script is stable, the results should be stable too...\n\n> You only pull arch metainfo branch; the objects associated with\n> the corresponding git branch head will be pulled together when\n> you pull it.  You do not have to tell git to pull git-part of\n> the commit chain.  There is no need to worry about version skew\n> when you use git this way.\n\n>From here onwards, you lost me, mate ;)\n\ncheers,\n\n\nmartin\n"},{"id":"7770","messageId":"m17je9tcj0.fsf@ebiederm.dsl.xmission.com","threadId":"1642","inReplyTo":"46a038f90508252115415acc04@mail.gmail.com","subject":"Re: Storing state in $GIT_DIR","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-08-26T06:53:07Z","receivedAt":"2005-08-26T06:53:07Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> Hmmm. That repo is in sync, but there are no guarantees that they will\n> travel together to a different repo. In fact, the push/pull\n> infrastructure wants to push/pull one head at a time.\n>\n> And if they are not in sync, I have no way of knowing. Hmpf. I lie:\n> the arch metadata could keep track of what it expects the last head\n> commits to be, and complain bitterly if something smells rotten.\n>\n> let me think about it ;)\n\n\nThinking about it going from arch to git should be just a matter\nof checking sha1 hashes, possibly back to the beginning of the\narch tree.  \n\nGoing from git to arch is the trickier mapping, because you\nneed to know the full repo--category--branch--version--patch\nmapping.\n\nHmm.  Thinking about arch from a git perspective arch tags every\ncommit.  So the really sane thing to do (I think) is to create\na git tag object for every arch commit.\n\nWith that structure you would just need to create a git-arch-rev-list\nso you can get a list of which arch branches you already have.\nAnd then a git-arch-push and a git-arch-pull should be just a matter\nof finding the common ancestor and continuing along the branch until\nyou reach the head.  Handling all heads in an arch repository is a\nlittle trickier but should not be too bad.\n\nOn the push side you can just treat git as an arch working directory \nand push changsets into the appropriate branch.  For branches that\ndo not have tla as the ancestor you can do the equivalent of\ntla archive-mirror.\n\nChanges can be merged on whichever side make sense.\n\nWith patch trading (Martin I think I know what you are refering to)\narch does seem to have a concept that does not map very well to git,\nand this I think is a failing in git.  Arch can record that just the\nchanges from a single changset/patch were merged.  This happens all\nof the time in the kernel tree when patches are merged.  The\ninteresting case for merge algorithms is when two maintainers merge\nthe same patches into separate branches and then the branches are\nmerged.  Does git have a good way of coping with that case?\n\nOn the simple side it for patch trading it might just be worth\ntreating them as a special git merge with just one parent in\nthe parents line and the real parent listed in the merge comment,\nalong with the original parents commit comment.  But that just\nmight be too ugly to think about.\n\nHow does StGit handle this?\n\nEric\n"},{"id":"7775","messageId":"46a038f90508260008d1013ea@mail.gmail.com","threadId":"1642","inReplyTo":"m17je9tcj0.fsf@ebiederm.dsl.xmission.com","subject":"Re: Storing state in $GIT_DIR","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-08-26T07:08:47Z","receivedAt":"2005-08-26T07:08:47Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/26/05, Eric W. Biederman <ebiederm@xmission.com> wrote:\n> Thinking about it going from arch to git should be just a matter\n> of checking sha1 hashes, possibly back to the beginning of the\n> arch tree.\n\nYup, though actually replaying the tree to compute the hashes is\nsomething I just _won't_ do ;)\n\n> Going from git to arch is the trickier mapping, because you\n> need to know the full repo--category--branch--version--patch\n> mapping.\n\nMy plan doesn't include git->arch support... yet...\n\n> Hmm.  Thinking about arch from a git perspective arch tags every\n> commit.  So the really sane thing to do (I think) is to create\n> a git tag object for every arch commit.\n\nNow I like that interesting idea. It doesn't solve all my problems,\nbut is a reasonable mapping point. Will probably do it.\n\n> With patch trading (Martin I think I know what you are refering to)\n> arch does seem to have a concept that does not map very well to git,\n> and this I think is a failing in git.\n\nI won't get into _that_ flamewar ;)\n\nMy plan for merges is to detect when two branches up until what point\nbranches are fully merged, and mark that in git -- because that is\nwhat git considers a merge. The rest will be known to the importer,\nbut nothing else.\n\ncheers,\n\n\nmartin\n"},{"id":"7808","messageId":"m13bowu631.fsf@ebiederm.dsl.xmission.com","threadId":"1642","inReplyTo":"46a038f90508260008d1013ea@mail.gmail.com","subject":"Re: Storing state in $GIT_DIR","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-08-26T14:26:58Z","receivedAt":"2005-08-26T14:26:58Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Martin Langhoff <martin.langhoff@gmail.com> writes:\n\n> On 8/26/05, Eric W. Biederman <ebiederm@xmission.com> wrote:\n>> Thinking about it going from arch to git should be just a matter\n>> of checking sha1 hashes, possibly back to the beginning of the\n>> arch tree.\n>\n> Yup, though actually replaying the tree to compute the hashes is\n> something I just _won't_ do ;)\n\nI guess if you have the tla branch names it won't be necessary.\nIf you are careful how you do the import you can have two parallel\nimports of the same data and produce exactly the same git tree.\nThat is largely why I care about a stable algorithm for the hashes.\n\n>> Going from git to arch is the trickier mapping, because you\n>> need to know the full repo--category--branch--version--patch\n>> mapping.\n>\n> My plan doesn't include git->arch support... yet...\n\nOne of my interests, and if I get the time to worry about it\nis to get a scm that is a sufficient superset of what other\nscms do so it can serve as a bidirectional gateway.\n\ngit is fairly close to what is needed to implement that.\n\nHmm.  I wonder if a git metadata branch in general is sufficient to\nstore information that does not map to git natively?\n\n>> Hmm.  Thinking about arch from a git perspective arch tags every\n>> commit.  So the really sane thing to do (I think) is to create\n>> a git tag object for every arch commit.\n>\n> Now I like that interesting idea. It doesn't solve all my problems,\n> but is a reasonable mapping point. Will probably do it.\n>\n>> With patch trading (Martin I think I know what you are refering to)\n>> arch does seem to have a concept that does not map very well to git,\n>> and this I think is a failing in git.\n>\n> I won't get into _that_ flamewar ;)\n\n<pouts> No flamewar </pouts>\n\n> My plan for merges is to detect when two branches up until what point\n> branches are fully merged, and mark that in git -- because that is\n> what git considers a merge. The rest will be known to the importer,\n> but nothing else.\n\nI looked at least back to the StGit announcement and it helped to\nclarify my thinking.  A patch is equivalent to a branch with\njust one change. This makes cherry picking a single patch roughly\nequivalent to describing that patch as a single commit branch\nat the fork point from the common ancestor of the two branches,\nand then having the single commit merged.\n\nThe fact that the original branch that was cherry picked from\ncan really only be represented as a an graft.  Like the original\nlinux kernel history.\n\nThe shortcoming I see in git-applypatch is that it doesn't attempt\nto find the original base of a patch and instead simply assumes it\nis against the current tree.\n\nThere is a similar short coming in git-diff-tree where it reports\nthe commit that you are on when take the diff, but it does not\nreport the commit the diff is against. \n\n......\n\nThinking a little more there is also a connection with reverting\npatches.  Cherry picking changes from a branch may also be thought of\nas reverting all of the other changes from a branch and then merging\nthe branch.\n\nThe practical impact of all of these things is there a form that\nwill allow future merges to realize the same change has already\nbeen applied so it can skip it the second time.\n\nInter-operating with darcs, tla, quilt, and raw diff/patch brings up\nthese issues.\n\nSo my practical questions are:\n- What information can a current git merge algorithms and more\n  sophisticated merge algorithms use to avoid having conflicts when\n  the same changes are merged into the same branch multiple times?\n\n- Is the git meta data sufficient to represent the history\n  sophisticated merge algorithms can use.\n\n- Is the git meta data sufficient to represent the result\n  of sufficient meta data operations.\n\n- Is the current representation of a reverted change sufficient\n  for the merge algorithms, or could they do a better job if\n  they new a change was revert of a previous change.\n\nI'm just trying to think through the issues that working with patch\nbased systems bring up.\n\nEric\n"},{"id":"7824","messageId":"Pine.LNX.4.58.0508261722410.3317@g5.osdl.org","threadId":"1642","inReplyTo":"7virxti6y5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Storing state in $GIT_DIR","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-08-27T00:23:10Z","receivedAt":"2005-08-27T00:23:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 25 Aug 2005, Junio C Hamano wrote:\n> \n> \"v0.99.5^0\" means \"look at the named object v0.99.5, dereference\n> it repeatedly until you get a non-tag, and take the result,\n> which had better be a commit\".  If a tag can contain more than\n> one pointers, I do not know what it means.\n\nYeah, we'd have to either just say \"I can't do that, Dave\", or specify \nthat it only looks at the first object in the list.\n\n\t\tLinus\n"}]}