{"thread":{"id":"8567","subject":"[PATCH 0/3] Support config-based names","startedAt":"2007-06-12T03:10:39Z","lastAt":"2007-06-12T06:44:43Z","messageCount":6,"participants":["Daniel Barkalow","Shawn O. Pearce","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"44785","messageId":"Pine.LNX.4.64.0706112244210.5848@iabervon.org","threadId":"8567","inReplyTo":null,"subject":"[PATCH 0/3] Support config-based names","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-12T03:10:39Z","receivedAt":"2007-06-12T03:10:39Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"It can be useful to refer to commits in remotes based on their configured \nrelationship to local branches. For example, \"git log HEAD^[push]..HEAD\" \nwould, when pushing is set up, show what hasn't been pushed yet.\n\nI picked base^[word] as the format for sha1 names which are some arbitrary \nfunction of base. I think this format isn't used for anything yet, isn't \nvalid as ref names, and is structureally suitable for having a variety of \nextensions. I added {branch}^[merge] for the default head to merge into \n{branch} and {branch}^[push] for the tracking ref for the remote branch to \npush {branch} to. The push one could be extended to include the branch to \npush to by default at other remotes as {branch}^[push:{remote}]. I'm not \ntoo picky about the format for this, if there's something better for the \nspace of sha1 names that don't have to be super compact and may have lots \nof options.\n\n(In order to prepare this email, I set up a push default of my branch to \nnext, and did: \"git log --reverse HEAD^[push]..HEAD\" and \"git diff --stat \nHEAD^[push]...HEAD\")\n\nPatch 1 is likely to be independantly useful for things like a \nbuiltin-fetch, which needs to get configuration for branches along with \nremotes.\n\n Patch 1: Parse and report branch config\n Patch 2: Search for matching push refspec in configuration\n Patch 3: Add sha1 names using the preceding functions\n\n remote.c | 109 +++++++++++++++++++++++++++++++++++++++++++++++++++-------\n remote.h | 22 +++++++++++-\n sha1_name.c | 50 +++++++++++++++++++++++++++\n 3 files changed, 166 insertions(+), 15 deletions(-)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"44789","messageId":"20070612033134.GS6073@spearce.org","threadId":"8567","inReplyTo":"Pine.LNX.4.64.0706112244210.5848@iabervon.org","subject":"Re: [PATCH 0/3] Support config-based names","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-12T03:31:34Z","receivedAt":"2007-06-12T03:31:34Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Daniel Barkalow wrote:\n> It can be useful to refer to commits in remotes based on their configured \n> relationship to local branches. For example, \"git log HEAD^[push]..HEAD\" \n> would, when pushing is set up, show what hasn't been pushed yet.\n\nInteresting.\n\nWhat about `git diff master^[push]@{3.days.ago}^{tree} master` ?\n\nCan anyone even understand that? Can Git even understand it?\nAs I follow your code I don't think it would, as the ^[push]\noperator seems like it needs to be on the very end of the string,\nand it assumes everything to the left of the ^[ is the branch name.\nSo I also couldn't phrase that as:\n\n git diff master@{3.days.ago}^[push]^{tree} master\n\nMore interesting is just what do you want going on here with the\nreflog query and the ^[push] query. Should the reflog operator apply\nbefore the ^[push] translation, or after? Or should it depend on\nthe order of them in the statement? I can see where you would want\nto look at your local tracking branch for the current branch 3 days\nago, which might be \"HEAD^[push]@{3.days.ago}\". But I'm not really\nsure what the meaning of \"HEAD@{3.days.ago}^[push]\" is. Is that\nthe branch that HEAD was on 3 days ago's push branch? Huh? ;-)\n\nFood for thought.\n\nIn general it seems our \"operators\" are ^{foo} or @{foo}, so I wonder\nwhy not ^{push}. push is not a valid object type, and probably\nnever will be, so peeling the onion back to get to what ^{push}\nmeans (even though its not an object type) is probably OK.\n\n-- \nShawn.\n"},{"id":"44790","messageId":"Pine.LNX.4.64.0706112354330.5848@iabervon.org","threadId":"8567","inReplyTo":"20070612033134.GS6073@spearce.org","subject":"Re: [PATCH 0/3] Support config-based names","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-12T04:13:42Z","receivedAt":"2007-06-12T04:13:42Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 11 Jun 2007, Shawn O. Pearce wrote:\n\n> Daniel Barkalow wrote:\n> > It can be useful to refer to commits in remotes based on their configured \n> > relationship to local branches. For example, \"git log HEAD^[push]..HEAD\" \n> > would, when pushing is set up, show what hasn't been pushed yet.\n> \n> Interesting.\n> \n> What about `git diff master^[push]@{3.days.ago}^{tree} master` ?\n> \n> Can anyone even understand that? Can Git even understand it?\n> As I follow your code I don't think it would, as the ^[push]\n> operator seems like it needs to be on the very end of the string,\n> and it assumes everything to the left of the ^[ is the branch name.\n\nAh, but the code actually peels off parts and parses the part under, so \nHEAD^[push]^{tree} actually works. However, it doesn't treat HEAD^[push] \nas an alias for a branch, so it doesn't find the reflog.\n\n> So I also couldn't phrase that as:\n> \n> git diff master@{3.days.ago}^[push]^{tree} master\n> \n> More interesting is just what do you want going on here with the\n> reflog query and the ^[push] query. Should the reflog operator apply\n> before the ^[push] translation, or after? Or should it depend on\n> the order of them in the statement? I can see where you would want\n> to look at your local tracking branch for the current branch 3 days\n> ago, which might be \"HEAD^[push]@{3.days.ago}\". But I'm not really\n> sure what the meaning of \"HEAD@{3.days.ago}^[push]\" is. Is that\n> the branch that HEAD was on 3 days ago's push branch? Huh? ;-)\n\nWhatever that means, I bet we don't track the necessary information. I \nthink ^[push] only applies to ref names. But it should probably resolve as \na ref name itself, so that HEAD^[push]@{3.days.ago} would work. Not sure \nhow to write the code for that, though.\n\n> In general it seems our \"operators\" are ^{foo} or @{foo}, so I wonder\n> why not ^{push}. push is not a valid object type, and probably\n> never will be, so peeling the onion back to get to what ^{push}\n> means (even though its not an object type) is probably OK.\n\n^{push} and ^{merge} are certainly possible, if the namespace of object \ntypes and the namespace of functions aren't going to overlap. I wasn't \nsure if this would be true in general with future additions to both \nnamespaces.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"44794","messageId":"7vbqfln3mf.fsf@assigned-by-dhcp.pobox.com","threadId":"8567","inReplyTo":"Pine.LNX.4.64.0706112244210.5848@iabervon.org","subject":"Re: [PATCH 0/3] Support config-based names","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-12T05:28:08Z","receivedAt":"2007-06-12T05:28:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> It can be useful to refer to commits in remotes based on their configured \n> relationship to local branches. For example, \"git log HEAD^[push]..HEAD\" \n> would, when pushing is set up, show what hasn't been pushed yet.\n\nIt's not like we will be adding 'push' objects and 'merge'\nobjects, so I think HEAD^{push} (curly brace, not bracket) is\ngood enough.\n\nWe need to see how useful this would be in practice; we would\nnot want to add new syntax without a set of convincing use\ncases. At this point, it still feels as if it is a feature that\nwas implemented only because it could, not because there was a\nreal need.\n"},{"id":"44796","messageId":"Pine.LNX.4.64.0706120131010.5848@iabervon.org","threadId":"8567","inReplyTo":"7vbqfln3mf.fsf@assigned-by-dhcp.pobox.com","subject":"Re: [PATCH 0/3] Support config-based names","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-06-12T05:56:16Z","receivedAt":"2007-06-12T05:56:16Z","isPatch":true,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 11 Jun 2007, Junio C Hamano wrote:\n\n> Daniel Barkalow writes:\n> \n> > It can be useful to refer to commits in remotes based on their configured \n> > relationship to local branches. For example, \"git log HEAD^[push]..HEAD\" \n> > would, when pushing is set up, show what hasn't been pushed yet.\n> \n> It's not like we will be adding 'push' objects and 'merge'\n> objects, so I think HEAD^{push} (curly brace, not bracket) is\n> good enough.\n\nWhat I'm worried about is whether we'll eventually want some sort of \nfunction and an object with the same name, and then have to have a syntax \nproblem with legacy functions being confusing.\n\n> We need to see how useful this would be in practice; we would\n> not want to add new syntax without a set of convincing use\n> cases. At this point, it still feels as if it is a feature that\n> was implemented only because it could, not because there was a\n> real need.\n\nI'd be a lot more reliable at using git if git-commit reported \"git log \n--pretty=oneline HEAD^{push}..HEAD\" after each commit (if there is a \nHEAD^{push}). I'm forever committing things and forgetting to push them \nwhen I mean to. My original series actually ended with adding something to \ngit-commit.sh, but I decided I didn't like the implementation of that \nactual patch.\n\nI didn't have a particular need for ^{merge}, but I accidentally wrote it \nfirst because I was confused as to what I wanted. I think \"git diff \nHEAD^{merge}\" might be good for finding out what work you've done that \nhasn't gotten in yet.\n\nOf course, for particular cases, it's just as easy to type the actual \ntracking branch name on the command line, but ^{push} and ^{merge} can be \nused genericly in scripts, because the same common or pattern works for \nany branch.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"44799","messageId":"7vfy4xllic.fsf@assigned-by-dhcp.pobox.com","threadId":"8567","inReplyTo":"Pine.LNX.4.64.0706120131010.5848@iabervon.org","subject":"Re: [PATCH 0/3] Support config-based names","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-12T06:44:43Z","receivedAt":"2007-06-12T06:44:43Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow writes:\n\n> On Mon, 11 Jun 2007, Junio C Hamano wrote:\n>\n>> Daniel Barkalow writes:\n>\n> What I'm worried about is whether we'll eventually want some sort of \n> function and an object with the same name, and then have to have a syntax \n> problem with legacy functions being confusing.\n\nI would agree that I'd worry about that; we will eventually want\nsome sort of function that is user customizable from command\nline, in the same sense as \"@{any date specifier}\" but possibly\nstronger. And at that point, even [] would get in the way of\nthat scriptable part. I'd prefer to provide a set of well\ndefined and usable \"atoms\" and let the people script with them.\n\n>> We need to see how useful this would be in practice; we would\n>> not want to add new syntax without a set of convincing use\n>> cases. At this point, it still feels as if it is a feature that\n>> was implemented only because it could, not because there was a\n>> real need.\n>\n> I'd be a lot more reliable at using git if git-commit reported \"git log \n> --pretty=oneline HEAD^{push}..HEAD\" after each commit (if there is a \n> HEAD^{push}). I'm forever committing things and forgetting to push them \n> when I mean to.\n\nFirst, I think 'push' is a misnomer for that purpose, as your\nwidely popular \"pretend we immediately fetched back\" topic made\nremote tracking branches, which were originally associated more\nstrongly to 'fetch', associated equally well to 'push'. You are\ncomparing what the remote counterpart of your current branch has\n(or supposed to have) with what you built. So I would have\ncalled it 'remote'.\n\nSecond, more importantly, that functionality to do log or diff\nwould go to post commit hook script, and you shouldn't have to\nhave such a built-in \"function\" and new syntax to implement\nthat. I think more generally useful would be a change to \"git\nremote\" to teach what \"git-parse-remote\" historically has done,\nso that scripts can ask things like:\n\n - what is the symbolic name of the remote associated with my\n current branch (i.e. branch.$current.remote)?\n\n - what is the url of the remote given its symbolic name\n (i.e. remote.$remote.url and URL: in .git/remotes/$remote)?\n\n - what branch at the remote would my current branch pushed to\n (i.e. $current mapped through remote.$remote.push and Push: in\n .git/remotes/$remote)?\n\n - what remote tracking branch I am using to track that branch\n (i.e. that remote branch mapped through remote.$remote.fetch\n and Pull: in .git/remotes/$remote)?\n\n - what remote branch do I usually merge into my current branch\n (i.e. branch.$current.merge or the \"first refspec listed\"\n fallback)?\n\nand combinations of the above. I would even prefer the\n\"combinations\" to be performed by callers of \"git remote\", iow,\nin your hook script, not as myriad of \"git remote\" options.\n\n> I didn't have a particular need for ^{merge}, but I accidentally wrote it \n> first because I was confused as to what I wanted.\n\nThe last question above is there for completeness. I think it\nwould also be a good thing to give to the user.\n\nIn other words, I think the questions I listed above are \"atoms\"\nat more appropriate granularity to build flexible tools out of\nin order to fit people's different workflow, and I think it is\nway premature to embed only a selected-few combinations of them\ninto syntax sha1_name.c understands.\n"}]}