{"thread":{"id":"4378","subject":"Gitk feature - show nearby tags","startedAt":"2006-06-03T09:38:27Z","lastAt":"2006-06-05T21:11:33Z","messageCount":29,"participants":["Paul Mackerras","Junio C Hamano","Marco Costalba","Jonas Fonseca","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21131","messageId":"17537.22675.678700.118093@cargo.ozlabs.ibm.com","threadId":"4378","inReplyTo":null,"subject":"Gitk feature - show nearby tags","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-06-03T09:38:27Z","receivedAt":"2006-06-03T09:38:27Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"I just pushed out an update to the \"new\" branch of the gitk.git\nrepository, which adds a feature that I have often wished for: it will\nnow show the nearest preceding and following tags when you select a\ncommit. This is very useful if you need to identify which release was\nthe first to incorporate a particular patch, or if you need to know\nwhich release a patch might have been based on.\n\n(Specifically, it shows the tags for all tagged descendents that are\nnot descendents of another tagged descendent of the selected commit,\nand the tags for all tagged ancestors that are not ancestors of\nanother tagged ancestor of the selected commit.)\n\nSince there is a one-off computation that gitk does to work this out,\nwhich takes an appreciable time (about 1.5 seconds on my G5 on the\nkernel repository), I have made gitk do the computation in the\nbackground, and update the diff/file display window when it's done.\nThere is also a checkbox in the preferences window where you can turn\nit off if you don't want gitk to do this computation.\n\nComments/suggestions welcome.\n\nPaul.\n"},{"id":"21133","messageId":"7vslmm8rcd.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"17537.22675.678700.118093@cargo.ozlabs.ibm.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-03T10:29:38Z","receivedAt":"2006-06-03T10:29:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> I just pushed out an update to the \"new\" branch of the gitk.git\n> repository, which adds a feature that I have often wished for: it will\n> now show the nearest preceding and following tags when you select a\n> commit. This is very useful if you need to identify which release was\n> the first to incorporate a particular patch, or if you need to know\n> which release a patch might have been based on.\n\nAnother thing that would equally be useful is to show which\nbranch a particular commit is on, so for example I can pick one\ncommit while doing \"gitk next\" to view the next branch and see\nwhich topic it belongs to, and \"gitk this-topic\" to see which\ncommits on that topic, if any, are not yet in the \"next\" branch.\n\nFor a graphical interface like gitk it may not be such a big\ndeal (you can always follow the line), but an interface like tig\nthat shows commits in a linear fashion it would make a big\ndifference in usability.\n\nBTW, what's the maintenance/rewind policy on the \"new\" branch of\ngitk.git? If you are never going to rewind it, I could pull it\nin \"next\" (and keep pulling your \"master\" in my \"master\") for\nwider exposure if you like.\n"},{"id":"21134","messageId":"e5bfff550606030416s2ef6182crbde1395dd29e5b94@mail.gmail.com","threadId":"4378","inReplyTo":"7vslmm8rcd.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-06-03T11:16:45Z","receivedAt":"2006-06-03T11:16:45Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/3/06, Junio C Hamano wrote:\n> Paul Mackerras writes:\n>\n> > I just pushed out an update to the \"new\" branch of the gitk.git\n> > repository, which adds a feature that I have often wished for: it will\n> > now show the nearest preceding and following tags when you select a\n> > commit. This is very useful if you need to identify which release was\n> > the first to incorporate a particular patch, or if you need to know\n> > which release a patch might have been based on.\n>\n> Another thing that would equally be useful is to show which\n> branch a particular commit is on, so for example I can pick one\n> commit while doing \"gitk next\" to view the next branch and see\n> which topic it belongs to, and \"gitk this-topic\" to see which\n> commits on that topic, if any, are not yet in the \"next\" branch.\n>\n\nIf I have understood correctly the patch runs a 'git rev-list --all\n--topo-order --parents'\nand then does a tree walking.\n\nI am wandering if there exist any native git way to found the previous tag.\n\nAs example given a selected revision with id is it possible to\ndo something like this to fond the ancestor?\n\n1) get the tag list with git-peek-remote or something similar if tags\nare not already loaded\n\n2) given the tagList vector with n elements run\n\n git-rev-list --topo-order ^tagList[0] ^tagList[1] ....\n ^tagList[n-1]\n\n3) take the last sha spit out by git-rev-list, be it .\n\n4) Previous nearest tag is the parent of lastSha\n\nI've missed something?\n\n Marco\n"},{"id":"21135","messageId":"17537.32585.260926.48759@cargo.ozlabs.ibm.com","threadId":"4378","inReplyTo":"7vslmm8rcd.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-06-03T12:23:37Z","receivedAt":"2006-06-03T12:23:37Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Junio C Hamano writes:\n\n> Another thing that would equally be useful is to show which\n> branch a particular commit is on, so for example I can pick one\n> commit while doing \"gitk next\" to view the next branch and see\n> which topic it belongs to, and \"gitk this-topic\" to see which\n> commits on that topic, if any, are not yet in the \"next\" branch.\n\nThat wouldn't be hard to do, it's just a matter of finding which heads\nare descendents of the selected commit. I think that with heads, you\nwould want to see all the descendent heads, rather than just the\nnearest ones (those that aren't descendents of another descendent\nhead) as I do with tags. What do you think? If one head is a\ndescendent of another, and both are descendents of the selected\ncommit, should I show both?\n\n> BTW, what's the maintenance/rewind policy on the \"new\" branch of\n> gitk.git? If you are never going to rewind it, I could pull it\n> in \"next\" (and keep pulling your \"master\" in my \"master\") for\n> wider exposure if you like.\n\nI intend to pull \"new\" into \"master\" shortly, assuming I don't get any\nbug reports for the \"new\" branch. :)\n\nIf you pull my \"new\" into your \"next\", and you then pull your \"next\"\ninto your \"master\", and I pull my \"new\" into my \"master\", and you pull\nmy \"master\" into your \"master\", won't we end up with duplicate merges?\n\nPaul.\n"},{"id":"21137","messageId":"20060603151240.GA4024@diku.dk","threadId":"4378","inReplyTo":"7vslmm8rcd.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2006-06-03T15:12:40Z","receivedAt":"2006-06-03T15:12:40Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Junio C Hamano wrote Sat, Jun 03, 2006:\n> For a graphical interface like gitk it may not be such a big\n> deal (you can always follow the line), but an interface like tig\n> that shows commits in a linear fashion it would make a big\n> difference in usability.\n\nI already took your hint from the other day on irc and have begun on\nimplementing this revision graph visualization for tig. :)\n\nThe problem is of course to come up with some ascii-art which is both\nreadable and dense. Below is my mockup of something not using line\ngraphics, however using line graphics it might be possible to get\nsomething more unambiguos but also more \"edgy\".\n\n\t* [release] Sync docs\n\tM Merge ...\n\t|`* [master] Fix spelling\n\t| * Implement ...\n\tM | Merge ...\n\t|`M Merge ...\n\t| |`* Topic B ...\n\t| | * Topic B ...\n\t| * | Topic A\n\t| * | Topic A\n\t| *' Update docs\n\t: :\n\tM | Merge ...\n\t|`M Merge ...\n\t| *`. Topic B ...\n\t| * | Topic B ...\n\t| | * Topic A\n\t| | * Topic A\n\t| *' Update docs\n\t: :\n\tM | Merge ...\n\t|`M Merge ...\n\t| *`. Topic B ...\n\t| * | Topic B ...\n\t| | * Topic A\n\tM `.`. Merge\n\t|`* | | Update docs\n\n-- \nJonas Fonseca\n"},{"id":"21138","messageId":"e5sa47$qv8$1@sea.gmane.org","threadId":"4378","inReplyTo":"20060603151240.GA4024@diku.dk","subject":"Re: Gitk feature - show nearby tags","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-03T15:33:30Z","receivedAt":"2006-06-03T15:33:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jonas Fonseca wrote:\n\n> I already took your hint from the other day on irc and have begun on\n> implementing this revision graph visualization for tig. :)\n> \n> The problem is of course to come up with some ascii-art which is both\n> readable and dense. Below is my mockup of something not using line\n> graphics,[...]\n\nAs I can see you use 'vertical' layout. Do I understand correctly that '*'\nrefers to commit on marked (by column) branch, and '|' means pass-thru?\n\nBTW. you might want to take a look at http://revctrl.org/ diagrams;\nAFAICT all the git documentation uses 'horizontal' layout, which is good\nfor example but perhaps not for long-lived development...\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"21139","messageId":"20060603161900.GA4882@diku.dk","threadId":"4378","inReplyTo":"e5sa47$qv8$1@sea.gmane.org","subject":"Re: Gitk feature - show nearby tags","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2006-06-03T16:19:01Z","receivedAt":"2006-06-03T16:19:01Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Jakub Narebski wrote Sat, Jun 03, 2006:\n> Jonas Fonseca wrote:\n> \n> > I already took your hint from the other day on irc and have begun on\n> > implementing this revision graph visualization for tig. :)\n> > \n> > The problem is of course to come up with some ascii-art which is both\n> > readable and dense. Below is my mockup of something not using line\n> > graphics,[...]\n> \n> As I can see you use 'vertical' layout. Do I understand correctly that '*'\n> refers to commit on marked (by column) branch, and '|' means pass-thru?\n\nYes, and 'M' marks merges. Putting information in the \"commit node\"\nshould make certain things more obvious. You could encode information\nsuch as whether a commit is a \"unique head\" (nothing other revisions\nreferences this commit). For example the first commit will always be\nunique, but when using --all other heads might show up \"unique\".\n\n\t+ [master] ...\n\t* ...\n\t| + [unmerged/topic] ...\n\t| * ...\n\t*' ...\n\n> BTW. you might want to take a look at http://revctrl.org/ diagrams;\n> AFAICT all the git documentation uses 'horizontal' layout, which is good\n> for example but perhaps not for long-lived development...\n\nLooking at the examples on http://revctrl.org/StaircaseMerge: it might\nbe more readable but not as dense as I would like, namely one commit pr\nline.\n\n-- \nJonas Fonseca\n"},{"id":"21141","messageId":"7vy7wedvyx.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"17537.32585.260926.48759@cargo.ozlabs.ibm.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-03T16:50:46Z","receivedAt":"2006-06-03T16:50:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Paul Mackerras writes:\n\n> ... I think that with heads, you\n> would want to see all the descendent heads, rather than just the\n> nearest ones (those that aren't descendents of another descendent\n> head) as I do with tags. What do you think? If one head is a\n> descendent of another, and both are descendents of the selected\n> commit, should I show both?\n\nThat would be useful I think.\n\n>> BTW, what's the maintenance/rewind policy on the \"new\" branch of\n>> gitk.git? If you are never going to rewind it, I could pull it\n>> in \"next\" (and keep pulling your \"master\" in my \"master\") for\n>> wider exposure if you like.\n>\n> I intend to pull \"new\" into \"master\" shortly, assuming I don't get any\n> bug reports for the \"new\" branch. :)\n>\n> If you pull my \"new\" into your \"next\", and you then pull your \"next\"\n> into your \"master\", and I pull my \"new\" into my \"master\", and you pull\n> my \"master\" into your \"master\", won't we end up with duplicate merges?\n\nYes, but I rarely if ever pull \"next\" as a whole into \"master\".\n"},{"id":"21180","messageId":"17538.15550.732964.349428@cargo.ozlabs.ibm.com","threadId":"4378","inReplyTo":"7vy7wedvyx.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-06-04T01:51:58Z","receivedAt":"2006-06-04T01:51:58Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Junio C Hamano writes:\n\n> That would be useful I think.\n\nDone. It was pretty easy with the infrastructure for doing the tags\nin place.\n\n> Yes, but I rarely if ever pull \"next\" as a whole into \"master\".\n\nI see. In that case it probably would be good if you pulled the gitk\n\"new\" branch into \"next\".\n\nPaul.\n"},{"id":"21181","messageId":"17538.16015.53244.876090@cargo.ozlabs.ibm.com","threadId":"4378","inReplyTo":"e5bfff550606030416s2ef6182crbde1395dd29e5b94@mail.gmail.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2006-06-04T01:59:43Z","receivedAt":"2006-06-04T01:59:43Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Marco Costalba writes:\n\n> If I have understood correctly the patch runs a 'git rev-list --all\n> --topo-order --parents'\n> and then does a tree walking.\n\nYes, that's right. It means that gitk can show the nearest tags even\nif they aren't included in the current view.\n\n> I am wandering if there exist any native git way to found the previous tag.\n\nI don't know of any. Doing the tree walking in Tcl turned out to be\nnot too much of an overhead, though; it does the whole kernel\nrepository in 1.5 seconds on my G5.\n\n> As example given a selected revision with id is it possible to\n> do something like this to fond the ancestor?\n> \n> 1) get the tag list with git-peek-remote or something similar if tags\n> are not already loaded\n> \n> 2) given the tagList vector with n elements run\n> \n> git-rev-list --topo-order ^tagList[0] ^tagList[1] ....\n> ^tagList[n-1]\n> \n> 3) take the last sha spit out by git-rev-list, be it .\n> \n> 4) Previous nearest tag is the parent of lastSha\n> \n> I've missed something?\n\nI'm not sure exactly what that would do, but gitk can show more than\none tag (the term \"nearest tag\" is only a shorthand approximation for\nwhat it does). For example, if you have two tagged commits where\nneither is an ancestor of the other, and do a merge of the two, gitk\nwill show both tags when you select the merge. It doesn't actually\nhappen in the kernel repository, though, because the tags there form a\nlinear list (at least the tags in the upstream repository do).\n\nPaul.\n"},{"id":"21190","messageId":"e5bfff550606040008m4dbf02bdga4f4e6bc2d2fe9d@mail.gmail.com","threadId":"4378","inReplyTo":"17538.16015.53244.876090@cargo.ozlabs.ibm.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-06-04T07:08:24Z","receivedAt":"2006-06-04T07:08:24Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/06, Paul Mackerras wrote:\n> Marco Costalba writes:\n>\n> > If I have understood correctly the patch runs a 'git rev-list --all\n> > --topo-order --parents'\n> > and then does a tree walking.\n>\n> Yes, that's right. It means that gitk can show the nearest tags even\n> if they aren't included in the current view.\n>\n> > I am wandering if there exist any native git way to found the previous tag.\n>\n> I don't know of any. Doing the tree walking in Tcl turned out to be\n> not too much of an overhead, though; it does the whole kernel\n> repository in 1.5 seconds on my G5.\n>\n> > As example given a selected revision with id is it possible to\n> > do something like this to fond the ancestor?\n> >\n> > 1) get the tag list with git-peek-remote or something similar if tags\n> > are not already loaded\n> >\n> > 2) given the tagList vector with n elements run\n> >\n> > git-rev-list --topo-order ^tagList[0] ^tagList[1] ....\n> > ^tagList[n-1]\n> >\n> > 3) take the last sha spit out by git-rev-list, be it .\n> >\n> > 4) Previous nearest tag is the parent of lastSha\n> >\n> > I've missed something?\n>\n> I'm not sure exactly what that would do, but gitk can show more than\n> one tag (the term \"nearest tag\" is only a shorthand approximation for\n> what it does). For example, if you have two tagged commits where\n> neither is an ancestor of the other, and do a merge of the two, gitk\n> will show both tags when you select the merge.\n\nWhat you suggest we need it's a kind of history of tags.\n\nCurrently we can run\n\ngit-rev-list --top-order --parents HEAD -- foo.c\n\nand we get an history of file foo.c *with modified parents*\n\nJunio, could be possible have something like\n\ngit-rev-list --top-order --parents --tags\n\nwith the history of tags ?\n\nAnd, according to Paul suggestions, not only tags, but merge revisions\nbetween tags.\n\nA more general and IMHO very powerful tool could be something like\n\ngit-rev-list --top-order --parents --selected-only HEAD -- \n ..... \n\nWhere git rev list gives the history, with modified parents, of the\ngiven revisions _only_ plus the merging revisions among them.\n\nThis could be used for tags (got from git-peek-remote), for branches\nand in general for a given set of interesting revisions.\n\nOnce we have the history of tags, perhaps requested once at startup,\nwe can get the previous tags of a given revision, our original\nproblem, with\n\ngit-rev-list --topo-order ^tagList[0] ^tagList[1] ....\n^tagList[n-1] ^merge[0] ... ^merge[k]\n\nAnd have one or more tags according if results is a rev in tagList or\nmergeList. Having the tag history it's easy to look up _all_ the tag\nancestors.\n\n Marco\n\nP.S: another use of\n\ngit-rev-list --top-order --parents --selected-only HEAD -- \n ..... \n\ncould be this:\n\nCurrently both qgit and gitk can filter revisions with a given set of\nfilter rules, but the results are shown together with the other\nrevisions or as a list of matching revisions with no useful graph\ninformation.\nWe could feed git-rev-list --top-order --parents --selected-only with\nthe list of matching revisions and have a pretty and sensible graph\ntoo.\n"},{"id":"21194","messageId":"7vodx9cm3g.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"e5bfff550606030416s2ef6182crbde1395dd29e5b94@mail.gmail.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-04T09:21:39Z","receivedAt":"2006-06-04T09:21:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> As example given a selected revision with id is it possible to\n> do something like this to fond the ancestor?\n>\n> 1) get the tag list with git-peek-remote or something similar if tags\n> are not already loaded\n>\n> 2) given the tagList vector with n elements run\n>\n> git-rev-list --topo-order ^tagList[0] ^tagList[1] ....\n> ^tagList[n-1]\n>\n> 3) take the last sha spit out by git-rev-list, be it .\n>\n> 4) Previous nearest tag is the parent of lastSha\n\nSorry, I do not understand what you are doing here at all.\nSuppose you have this simple history.\n\n (root)\n\n a---b---d---e---f---g\n t1 \\ / t3 \n ---c\n t2\n\nand in (2) is \"e\". When tagList = (t1, t2, t3), the\nabove rev-list would return empty. For tagList = (t1, t2), the\nrev-list would return \"e\", and then \"d\". Parent of \"d\" are \"b\"\nand \"c\", and c is tagged but b is not. So if you are willing to\ntry 2^N permutations of what tagList to use, then the above\nsequence, with a bit of tweak to step (4) to see which parents\nare tagged, would yield the closest tag in the past of \"e\", but\nis that what you are suggesting?\n"},{"id":"21195","messageId":"7vk67xclx7.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"e5bfff550606040008m4dbf02bdga4f4e6bc2d2fe9d@mail.gmail.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-04T09:25:24Z","receivedAt":"2006-06-04T09:25:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> What you suggest we need it's a kind of history of tags.\n\nI do not understand what you mean by \"history of tags\". Are you\ntalking about \"tag v1.0.0 was pointing at X commit yesterday but\nnow today it points at Y commit\"?\n\n> And, according to Paul suggestions, not only tags, but merge revisions\n> between tags.\n>\n> A more general and IMHO very powerful tool could be something like\n>\n> git-rev-list --top-order --parents --selected-only HEAD -- \n> ..... \n>\n> Where git rev list gives the history, with modified parents, of the\n> given revisions _only_ plus the merging revisions among them.\n\nYou completely lost me here. The '--' markers are to mean \"from\nhere on the parameters are not revisions but are path limiters\",\nso you are doing something else. What are these , ,...\nin this? Are they revisions (i.e. commit object names)?\n"},{"id":"21198","messageId":"e5bfff550606040240p61dfcddaw987da180358c40fb@mail.gmail.com","threadId":"4378","inReplyTo":"7vk67xclx7.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-06-04T09:40:43Z","receivedAt":"2006-06-04T09:40:43Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/06, Junio C Hamano wrote:\n> \"Marco Costalba\" writes:\n>\n> > What you suggest we need it's a kind of history of tags.\n>\n> I do not understand what you mean by \"history of tags\". Are you\n> talking about \"tag v1.0.0 was pointing at X commit yesterday but\n> now today it points at Y commit\"?\n>\n> > And, according to Paul suggestions, not only tags, but merge revisions\n> > between tags.\n> >\n> > A more general and IMHO very powerful tool could be something like\n> >\n> > git-rev-list --top-order --parents --selected-only HEAD -- \n> > ..... \n> >\n> > Where git rev list gives the history, with modified parents, of the\n> > given revisions _only_ plus the merging revisions among them.\n>\n> You completely lost me here. The '--' markers are to mean \"from\n> here on the parameters are not revisions but are path limiters\",\n> so you are doing something else. What are these , ,...\n> in this? Are they revisions (i.e. commit object names)?\n\nYes they are.\n\nInsted of path limiters I meant revisions limiters.\n\nGiven a revision history like\n\na\nb--|\n| f\n| g\nc\nd\ne\n\ngit-rev-list --top-order --parents --selected-only HEAD -- \n\nShould output something like\n\na\nb--|\n| g\nd\n\nOf course with modified parent information as does git-rev-list\n--parents -- foo.c\n"},{"id":"21199","messageId":"e5bfff550606040254n1449b62ta70c209ad8e1a0c@mail.gmail.com","threadId":"4378","inReplyTo":"7vodx9cm3g.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-06-04T09:54:25Z","receivedAt":"2006-06-04T09:54:25Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/06, Junio C Hamano wrote:\n> \"Marco Costalba\" writes:\n>\n> > As example given a selected revision with id is it possible to\n> > do something like this to fond the ancestor?\n> >\n> > 1) get the tag list with git-peek-remote or something similar if tags\n> > are not already loaded\n> >\n> > 2) given the tagList vector with n elements run\n> >\n> > git-rev-list --topo-order ^tagList[0] ^tagList[1] ....\n> > ^tagList[n-1]\n> >\n> > 3) take the last sha spit out by git-rev-list, be it .\n> >\n> > 4) Previous nearest tag is the parent of lastSha\n>\n> Sorry, I do not understand what you are doing here at all.\n> Suppose you have this simple history.\n>\n> (root)\n>\n> a---b---d---e---f---g\n> t1 \\ / t3\n> ---c\n> t2\n>\n> and in (2) is \"e\". When tagList = (t1, t2, t3), the\n> above rev-list would return empty.\n\nThis is enough!\n\nEmpty list is an useful and enough information.\n\nIt means:\n\n1) Parent of current revision (\"e\" in our case) is a tag, indeed our seeked tag.\n2) If previous point is not true then there are no previous tags.\n\nIn a less corner case, just to better explaing my idea, consider this:\n\n a---b---d---e---f---g---h\n t1 \\ / t3\n ---c\n t2\n\nWhere our sha1 is still \"e\", in this case\n\ngit-rev-list --topo-order ^a ^c ^g\n\ngives, as last revision in output list, \"f\"\nThen parentOf() is and our looked for tag is t3\n\n Marco\n"},{"id":"21200","messageId":"7vbqt9ck05.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"e5bfff550606040254n1449b62ta70c209ad8e1a0c@mail.gmail.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-04T10:06:50Z","receivedAt":"2006-06-04T10:06:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> In a less corner case, just to better explaing my idea, consider this:\n>\n> a---b---d---e---f---g---h\n> t1 \\ / t3\n> ---c\n> t2\n>\n> Where our sha1 is still \"e\", in this case\n>\n> git-rev-list --topo-order ^a ^c ^g\n>\n> gives, as last revision in output list, \"f\"\n> Then parentOf() is and our looked for tag is t3\n\nSorry, in the example time flows from left to right. If you\nexclude g then you are excluding everything that is reachable\nfrom g so you would not see \"f\".\n\nEven if your example is different from what I gave (which had\n\"a\" as the root commit) and h is the root commit, your ^a and ^c\nwould exclude everything that is reachable from either a or c,\nso you would get an empty set. So your \"last revision in\noutput\" would not be \"f\" either.\n"},{"id":"21201","messageId":"7v7j3xcjti.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"7vbqt9ck05.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-04T10:10:49Z","receivedAt":"2006-06-04T10:10:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> \"Marco Costalba\" writes:\n>\n>> In a less corner case, just to better explaing my idea, consider this:\n>>\n>> a---b---d---e---f---g---h\n>> t1 \\ / t3\n>> ---c\n>> t2\n>>\n>> Where our sha1 is still \"e\", in this case\n>>\n>> git-rev-list --topo-order ^a ^c ^g\n>>\n>> gives, as last revision in output list, \"f\"\n>> Then parentOf() is and our looked for tag is t3\n>\n> Sorry, in the example time flows from left to right. If you\n> exclude g then you are excluding everything that is reachable\n> from g so you would not see \"f\".\n>\n> Even if your example is different from what I gave (which had\n> \"a\" as the root commit) and h is the root commit, your ^a and ^c\n> would exclude everything that is reachable from either a or c,\n> so you would get an empty set. So your \"last revision in\n> output\" would not be \"f\" either.\n\nBTW, that was exactly what I meant by \"2^N permutations of\ntags\". If you exclude all tags that are older than \"e\" then\nyour algorithm would work beautifully, but the algorithm is\nabout finding out which tags are older than \"e\" to begin with,\nso...\n"},{"id":"21202","messageId":"e5bfff550606040333h1180bbep88fa90ea9928d062@mail.gmail.com","threadId":"4378","inReplyTo":"7vbqt9ck05.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-06-04T10:33:34Z","receivedAt":"2006-06-04T10:33:34Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/06, Junio C Hamano wrote:\n> \"Marco Costalba\" writes:\n>\n> > In a less corner case, just to better explaing my idea, consider this:\n> >\n> > a---b---d---e---f---g---h\n> > t1 \\ / t3\n> > ---c\n> > t2\n> >\n> > Where our sha1 is still \"e\", in this case\n> >\n> > git-rev-list --topo-order ^a ^c ^g\n> >\n> > gives, as last revision in output list, \"f\"\n> > Then parentOf() is and our looked for tag is t3\n>\n> Sorry, in the example time flows from left to right. If you\n> exclude g then you are excluding everything that is reachable\n> from g so you would not see \"f\".\n>\nFrom today git:\n\ntag list is:\n\nv1.3.3 1b9bc5a7b7434d771726011613a00cb202bd9f44\nv1.3.2 7abd7117ec57b8c3c2a469db62c7811fdac5c655\nv1.3.1 7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019\nv1.3.0 4baff50551545e2b6825973ec37bcaf03edb95fe\n\nselected sha is ccb365047a1081455b767867f0887e7b4334f9d8\n(Allow \"git repack\" users to specify repacking window/depth)\n\n$ git-rev-list --topo-order ccb365047a1081455b767867f0887e7b4334f9d8\n^1b9bc5a7b7434d771726011613a00cb202bd9f44\n^7abd7117ec57b8c3c2a469db62c7811fdac5c655\n^7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019\n^4baff50551545e2b6825973ec37bcaf03edb95fe\n\nccb365047a1081455b767867f0887e7b4334f9d8\n85e6326cc3e7c272566c60a39741f84391830d49\n4262c1b0c38613a8c5ae729bd4d3f18f0df3ec44\n24735cfc500feb2a8dba9f140080ab3476363d28\ncaef71a5354ca162cc5a6914a7a643efbc9ae28a\n34e98ea56414adc5a582e6368e8ec9c109dbee48\n3a624b346db02a07b0317743b362d1a15c6c3c18\n965f803c323bb72a9dedbbc8f7ba00bbadb6cf58\nb073f26b256cded6252bafd34982eb6f69d2a4b6\na4d34e2db5565e6b75f79f9d3938aa9151e72e44\neab144ac49c18d981261c2d0ba964d6380d9f1da\n9153983310a169a340bd1023dccafd80b70b05bc\ndb89665fbf86d4e0166b2f252a939ed8bf6782fe\n78fff6ebbafe2d23464a2b059104954bfe8732c7\ncb8f64b4e3f263c113b7a2f156af74b810e969ff\nd4ed9793fd981ea5a35ebaa8e337446bb29f6d55\nb2934926dd7455de61577c1dfdf4c12d224e7ae0\nba1d45051e050cbcf68ccccacea86a4b6ecde731\n5b84f4d87a1bd58c7540e9ea82ee3673ecddbad5\n7594c4b2d7cc81f806453402aefe1bf71ae6dd53\n6b9c58f4669b3832ed2830f0cb1a307ea6bc6063\n8c1f0b44c59530dea8007a9f5b69d0fac6aea3b1\n8e8f998739db6526fe890fabc88c866759bc2ac3\ncd2bdc5309461034e5cc58e1d3e87535ed9e093b\n\nParent of cd2bdc5309461034e5cc58e1d3e87535ed9e093b is\n\n4baff50551545e2b6825973ec37bcaf03edb95fe\n\naka tag v1.3.0\n\nAm I missing something?\n"},{"id":"21204","messageId":"e5bfff550606040342q5e485ae2lcc00e36ed405be8c@mail.gmail.com","threadId":"4378","inReplyTo":"e5bfff550606040333h1180bbep88fa90ea9928d062@mail.gmail.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-06-04T10:42:16Z","receivedAt":"2006-06-04T10:42:16Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/06, Marco Costalba wrote:\n> On 6/4/06, Junio C Hamano wrote:\n> > \"Marco Costalba\" writes:\n> >\n> > > In a less corner case, just to better explaing my idea, consider this:\n> > >\n> > > a---b---d---e---f---g---h\n> > > t1 \\ / t3\n> > > ---c\n> > > t2\n> > >\n> > > Where our sha1 is still \"e\", in this case\n> > >\n> > > git-rev-list --topo-order ^a ^c ^g\n> > >\n> > > gives, as last revision in output list, \"f\"\n> > > Then parentOf() is and our looked for tag is t3\n> >\n> > Sorry, in the example time flows from left to right. If you\n> > exclude g then you are excluding everything that is reachable\n> > from g so you would not see \"f\".\n\nTo better explain what I mean, that's the algorithm :\n\ncmd = \"git-rev-list --topo-order --parents \" + sha;\nfor (uint i = 0; i < tagList.count(); i++)\n\tcmd.append(\" ^\" + tagList[i]);\n\noutput = run(cmd);\n\nif (output.isEmpty()) {\n\tparent = parentOf(sha);\n\treturn (parent && parent->isTag()) ? parent->tag() : NO_TAG;\n}\n\nlastSha = getLastLine(output);\nparent = parentOf(lastSha);\nreturn (parent && parent->isTag()) ? parent->tag() : NO_TAG;\n"},{"id":"21203","messageId":"7v3belcicq.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"e5bfff550606040333h1180bbep88fa90ea9928d062@mail.gmail.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-04T10:42:29Z","receivedAt":"2006-06-04T10:42:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n>> Sorry, in the example time flows from left to right. If you\n>> exclude g then you are excluding everything that is reachable\n>> from g so you would not see \"f\".\n>>\n> From today git:\n>\n> tag list is:\n>\n> v1.3.3 1b9bc5a7b7434d771726011613a00cb202bd9f44\n> v1.3.2 7abd7117ec57b8c3c2a469db62c7811fdac5c655\n> v1.3.1 7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019\n> v1.3.0 4baff50551545e2b6825973ec37bcaf03edb95fe\n>\n> selected sha is ccb365047a1081455b767867f0887e7b4334f9d8\n> (Allow \"git repack\" users to specify repacking window/depth)\n>\n> $ git-rev-list --topo-order ccb365047a1081455b767867f0887e7b4334f9d8\n> ^1b9bc5a7b7434d771726011613a00cb202bd9f44\n> ^7abd7117ec57b8c3c2a469db62c7811fdac5c655\n> ^7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019\n> ^4baff50551545e2b6825973ec37bcaf03edb95fe\n>\n> ccb365047a1081455b767867f0887e7b4334f9d8\n> ...\n> cd2bdc5309461034e5cc58e1d3e87535ed9e093b\n>\n> Parent of cd2bdc5309461034e5cc58e1d3e87535ed9e093b is\n>\n> 4baff50551545e2b6825973ec37bcaf03edb95fe\n>\n> aka tag v1.3.0\n>\n> Am I missing something?\n\nNo, just that I am not getting what you are trying to prove\nhere. The tags are all older than your chosen commit.\n\n$ git-rev-list --topo-order ^v1.3.0 ^v1.3.1 ^v1.3.2 ^v1.3.3 e923eff\n\nwould show nothing -- and you propose to find out that commit is\nbetween v1.3.1 and v1.3.2 by using the information that the\ncommand gives an empty result but I do not know how?\n\n$ git show-branch v1.3.1 e923eff v1.3.2\n\ndoes show it is between these two, but that is because it avoids\nthe 2^N permutations by using 1-bit per revision that it wants to\ncheck the reachability across.\n"},{"id":"21206","messageId":"e5bfff550606040657p5c1a3dceq3eef254ab64f0e3a@mail.gmail.com","threadId":"4378","inReplyTo":"7v3belcicq.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-06-04T13:57:25Z","receivedAt":"2006-06-04T13:57:25Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/4/06, Junio C Hamano wrote:\n> \"Marco Costalba\" writes:\n>\n> >> Sorry, in the example time flows from left to right. If you\n> >> exclude g then you are excluding everything that is reachable\n> >> from g so you would not see \"f\".\n> >>\n> > From today git:\n> >\n> > tag list is:\n> >\n> > v1.3.3 1b9bc5a7b7434d771726011613a00cb202bd9f44\n> > v1.3.2 7abd7117ec57b8c3c2a469db62c7811fdac5c655\n> > v1.3.1 7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019\n> > v1.3.0 4baff50551545e2b6825973ec37bcaf03edb95fe\n> >\n> > selected sha is ccb365047a1081455b767867f0887e7b4334f9d8\n> > (Allow \"git repack\" users to specify repacking window/depth)\n> >\n> > $ git-rev-list --topo-order ccb365047a1081455b767867f0887e7b4334f9d8\n> > ^1b9bc5a7b7434d771726011613a00cb202bd9f44\n> > ^7abd7117ec57b8c3c2a469db62c7811fdac5c655\n> > ^7d09fbe4ab7f080a8f8f5dcef7e0f3edf5e26019\n> > ^4baff50551545e2b6825973ec37bcaf03edb95fe\n> >\n> > ccb365047a1081455b767867f0887e7b4334f9d8\n> > ...\n> > cd2bdc5309461034e5cc58e1d3e87535ed9e093b\n> >\n> > Parent of cd2bdc5309461034e5cc58e1d3e87535ed9e093b is\n> >\n> > 4baff50551545e2b6825973ec37bcaf03edb95fe\n> >\n> > aka tag v1.3.0\n> >\n> > Am I missing something?\n>\n> No, just that I am not getting what you are trying to prove\n> here. The tags are all older than your chosen commit.\n>\n> $ git-rev-list --topo-order ^v1.3.0 ^v1.3.1 ^v1.3.2 ^v1.3.3 e923eff\n>\n> would show nothing -- and you propose to find out that commit is\n> between v1.3.1 and v1.3.2 by using the information that the\n> command gives an empty result but I do not know how?\n>\n\nOK. Now I understand.\n\nI was erroneously thinking that in\n\n$ git-rev-list --topo-order e923eff ^v1.3.0 ^v1.3.1 ^v1.3.2 ^v1.3.3\n\nthe listing (and searching) was _starting_ from e923eff, i.e. all the\nprevious stuff, in our case v1.3.2 and v1.3.3 was never seen neither\nfiltered out.\n\nFollowing an extract from git-rev-list documentation.\n\nDESCRIPTION\n-----------\nLists commit objects in reverse chronological order *starting at the\ngiven commit(s)*, taking ancestry relationship into account. This is\nuseful to produce human-readable log output.\n\nCommits which are stated with a preceding '{caret}' *cause listing to stop at\nthat point*. Their parents are implied. \"git-rev-list foo bar {caret}baz\" thus\nmeans \"list all the commits which are included in 'foo' and 'bar', but\nnot in 'baz'\".\n\n\n\nPerhaps it's me, but I really don't found clear from documentation\nthat git-rev-list anySha ^HEAD gives _always_ an empty result.\n\nWhat I understand is that git-rev-list lists _first_ the given commit,\nthen his parents, then his grandparents and so on _until_ a commit\nwhich is stated with a preceding '{caret}' is found.\nSo everything that is between the given commit and HEAD is never found\nand ignored.\n\nIs it a problem to change the git-rev-list behaviour to reflect (my\nunderstanding of) documentation or it breaks something?\n\nIf I have understood correctly with this change the above proposed\nalgorithm should work.\n\n Marco\n"},{"id":"21224","messageId":"7vejy48wp5.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"20060603151240.GA4024@diku.dk","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-04T20:58:30Z","receivedAt":"2006-06-04T20:58:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonas Fonseca writes:\n\n> The problem is of course to come up with some ascii-art which is both\n> readable and dense. Below is my mockup of something not using line\n> graphics, however using line graphics it might be possible to get\n> something more unambiguos but also more \"edgy\".\n\nI do not necessarily think an ascii-art is needed, nor an\nappropriate way to present it to the curses user. When the user\nwants to \"view\" a commit, you could show from which branch heads\nand from which tags the commit is reachable, and perhaps which\ntag is the latest among the ones reachable from that commit, as\npart of the commit detail information you display on the lower\npane (log/diff view).\n\nI may not be using tig in the way it was intended to, but I\noften find it frustrating having to do the following:\n\n - start tig, which shows list of one-line logs. Wonderful.\n\n - browsing around by UP or DOWN and stop at one particular commit\n I want to view closely. Press Enter and the screen split\n into two and I see what I want to see. Again, wonderful.\n\n - I want to see the neighbouring commits, but UP or DOWN\n does not do what I naïvely expect. It scrolls the lower\n pane. I say TAB to go up.\n\n - Press UP or DOWN and I can move the highlight to\n neighbouring commits. This is wonderful, but the lower\n pane does not follow this -- it keeps showing the original\n commit, and I have to say ENTER again.\n\nIt might make sense to make the log/diff view follow what\nhappens on the main view when both are on-screen.\n"},{"id":"21239","messageId":"20060605000423.GA29521@diku.dk","threadId":"4378","inReplyTo":"7vejy48wp5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2006-06-05T00:04:23Z","receivedAt":"2006-06-05T00:04:23Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Junio C Hamano wrote Sun, Jun 04, 2006:\n> \n> I may not be using tig in the way it was intended to, but I\n> often find it frustrating having to do the following:\n> \n> - start tig, which shows list of one-line logs. Wonderful.\n> \n> - browsing around by UP or DOWN and stop at one particular commit\n> I want to view closely. Press Enter and the screen split\n> into two and I see what I want to see. Again, wonderful.\n> \n> - I want to see the neighbouring commits, but UP or DOWN\n> does not do what I naïvely expect. It scrolls the lower\n> pane. I say TAB to go up.\n\nI wonder what tig version you are using. If you are using the tig\nversion from my git repo this should also be working to your\nexpectation, making ...\n\n> - Press UP or DOWN and I can move the highlight to\n> neighbouring commits. This is wonderful, but the lower\n> pane does not follow this -- it keeps showing the original\n> commit, and I have to say ENTER again.\n\n.. this unnecessary. At least, I'd like to keep the one-line log view\nfrom forcing updates of the diff view so it is more responsive over slow\nlinks.\n\n> It might make sense to make the log/diff view follow what\n> happens on the main view when both are on-screen.\n\nWith my current version, the two views are much more integrated, e.g.\nyou can press 'd' to show full-screen diff view and use Up and Down to\nnavigate the log view.\n\n-- \nJonas Fonseca\n"},{"id":"21244","messageId":"7v3bek7589.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"20060605000423.GA29521@diku.dk","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-05T01:37:10Z","receivedAt":"2006-06-05T01:37:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonas Fonseca writes:\n\n>> - I want to see the neighbouring commits, but UP or DOWN\n>> does not do what I naïvely expect. It scrolls the lower\n>> pane. I say TAB to go up.\n>\n> I wonder what tig version you are using. If you are using the tig\n> version from my git repo this should also be working to your\n> expectation, making ...\n\nWhichever was the latest when I wrote the message. I see you\nhave added a handful commits on it since then.\n\n>> - Press UP or DOWN and I can move the highlight to\n>> neighbouring commits. This is wonderful, but the lower\n>> pane does not follow this -- it keeps showing the original\n>> commit, and I have to say ENTER again.\n>\n> .. this unnecessary.\n\nMaybe I am misusing it then.\n\n\"full-screen\" diff view and being able to do [UP] and [DOWN] to\nmove around there do not feel useful to me that much. It is\nsomething \"git log -p\" does already, thanks to its output paged\nvia \"less\" by default.\n\nI like viewing the list in the upper and diff/log in the lower\nat the same time, and that is the primary reason I liked tig, so\nmoving around in the commit list view and not seeing the\ndiff/log updated in sync was major dissapointment at least for\nme.\n"},{"id":"21253","messageId":"7vhd305dk9.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"e5bfff550606040657p5c1a3dceq3eef254ab64f0e3a@mail.gmail.com","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-05T06:20:06Z","receivedAt":"2006-06-05T06:20:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> What I understand is that git-rev-list lists _first_ the given commit,\n> then his parents, then his grandparents and so on _until_ a commit\n> which is stated with a preceding '{caret}' is found.\n> So everything that is between the given commit and HEAD is never found\n> and ignored.\n\nAs you now know, the way it works is that it takes an unordered\nset of committishes, and performs a set operation that says\n\"include everybody reachable from positive ones while excluding\neverybody reachable from negative ones\". --topo-order tells it\nto topologically (instead of doing the commit date-order which\nit does by default) sort the resulting list. The resulting list\nis then written out.\n\n> Is it a problem to change the git-rev-list behaviour to reflect (my\n> understanding of) documentation or it breaks something?\n\nI suspect it would break quite many things. Existing users use\nthe command knowing it is a set operation on an unordered set of\ncommittishes, and expect the command to behave that way. Also\nthe most typical use A..B translates to ^B A (either internally\nor by rev-parse) so \"the first\" would typically be a negative\none.\n\nI think your \"start from positive ones, traverse one by one and\nstop traversal that hits the negative one\" logic requires the\nnegative one to be directly on the traversal paths starting from\npositive ones to have _any_ effect. We often ask \"what's the\nones that are still not merged to the master from the side\nbranch\" while dealing with topic branches:\n\n c-------d---e master time flows from\n / / left to right\n --a---b---x---y---z side\n\nand the way to ask that question is \"rev-list master..side\"\n(which is \"rev-list side ^master\"). It should list z and not\nshow y nor x nor b nor a.\n\nIn order for it to be able to notice that y should not be\nlisted, it needs to perform traversals from negative ones as\nwell in order to learn that y is reachable from master. \n\nHow would you ask the same question to the modified rev-list\nthat does \"start from positive ones, traverse one by one and\nstop traversal that hits the negative one\" logic?\n\nI think one useful thing we can do is to generalize what\n\"describe\", \"nave-rev\", and \"merge-base\" do to have a command\nthat takes a committish X and a set of other committish T1..Tn,\nand examines if Ti (1<=i<=n) is reachable from X and if X is\nreachable from Ti (1<=i<=n), and give a short-hand to specify\nthe set of T for common patterns like --heads --tags and --all.\n\nBut that would not be rev-list; I suspect you would end up doing\nsomething quite similar to what show-branch does.\n"},{"id":"21256","messageId":"e5bfff550606050454l32a8a3b1kffa40fcc4d018778@mail.gmail.com","threadId":"4378","inReplyTo":"7vhd305dk9.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2006-06-05T11:54:35Z","receivedAt":"2006-06-05T11:54:35Z","isPatch":false,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On 6/5/06, Junio C Hamano wrote:\n> \"Marco Costalba\" writes:\n>\n> I think your \"start from positive ones, traverse one by one and\n> stop traversal that hits the negative one\" logic requires the\n> negative one to be directly on the traversal paths starting from\n> positive ones to have _any_ effect. We often ask \"what's the\n> ones that are still not merged to the master from the side\n> branch\" while dealing with topic branches:\n>\n> c-------d---e master time flows from\n> / / left to right\n> --a---b---x---y---z side\n>\n> and the way to ask that question is \"rev-list master..side\"\n> (which is \"rev-list side ^master\"). It should list z and not\n> show y nor x nor b nor a.\n>\n> In order for it to be able to notice that y should not be\n> listed, it needs to perform traversals from negative ones as\n> well in order to learn that y is reachable from master.\n>\n\nThanks for your clear explanation. Now I see much better what's the deal.\n\n>\n> I think one useful thing we can do is to generalize what\n> \"describe\", \"nave-rev\", and \"merge-base\" do to have a command\n> that takes a committish X and a set of other committish T1..Tn,\n> and examines if Ti (1<=i<=n) is reachable from X and if X is\n> reachable from Ti (1<=i<=n), and give a short-hand to specify\n> the set of T for common patterns like --heads --tags and --all.\n>\n\nI don't know if this is enough for our original problem to find previous tag.\n\nOur problem is indeed not only to find previous tags, but _nearest_\nprevious, so I think we have to think to a generalization that takes\nin account also a kind of 'metric' among tags because the only\nreachability seems to fall short in finding the nearset one.\n\nBut definitely I need to think more about this ;-)\n\n Marco\n"},{"id":"21277","messageId":"7v4pyz4b7w.fsf@assigned-by-dhcp.cox.net","threadId":"4378","inReplyTo":"7v3bek7589.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-05T20:08:19Z","receivedAt":"2006-06-05T20:08:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jonas Fonseca writes:\n>\n> Whichever was the latest when I wrote the message. I see you\n> have added a handful commits on it since then.\n>\n>>> - Press UP or DOWN and I can move the highlight to\n>>> neighbouring commits. This is wonderful, but the lower\n>>> pane does not follow this -- it keeps showing the original\n>>> commit, and I have to say ENTER again.\n>>\n>> .. this unnecessary.\n>\n> Maybe I am misusing it then.\n\nSorry, I *was* misusing it. I was doing PageUp/PageDown. Duh.\n\nI typed uparrow and downarrow while in the split view and it was\ndoing what I wanted to do.\n"},{"id":"21280","messageId":"20060605201902.GB17300@diku.dk","threadId":"4378","inReplyTo":"7v3bek7589.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2006-06-05T20:19:02Z","receivedAt":"2006-06-05T20:19:02Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Junio C Hamano wrote Sun, Jun 04, 2006:\n> Jonas Fonseca writes:\n> \n> >> - I want to see the neighbouring commits, but UP or DOWN\n> >> does not do what I naïvely expect. It scrolls the lower\n> >> pane. I say TAB to go up.\n> >\n> > I wonder what tig version you are using. If you are using the tig\n> > version from my git repo this should also be working to your\n> > expectation, making ...\n> \n> Whichever was the latest when I wrote the message. I see you\n> have added a handful commits on it since then.\n\nYes, I added your Makefile patch. Thanks for that one.\n\n> >> - Press UP or DOWN and I can move the highlight to\n> >> neighbouring commits. This is wonderful, but the lower\n> >> pane does not follow this -- it keeps showing the original\n> >> commit, and I have to say ENTER again.\n> >\n> > .. this unnecessary.\n> \n> Maybe I am misusing it then.\n\nI admit the basic user controls might still have some rough spots.\nHere is my take on what you are trying to do:\n\n - When you open tig, UP/DOWN will move the cursor line.\n\n - When you press ENTER on the commit you would like to see, it will\n open the split view and move focus to the diff view. So if you press\n Enter again it will start scrolling the diff view. This is much like\n the way Mutt works.\n\n - If you press UP/DOWN (while the diff view is focused) you will move\n to previous or next commit in the main view (the one-line log view)\n and load it in the diff view. That is, there is no reason to switch\n to the main view unless you want to navigate to a commit without\n repeatedly reloading the diff view which is clearly not what you are\n requesting.\n\nIs this not what you requested? That you can \"see neighbouring commit\"\nby pressing UP and DOWN? But without having to press ENTER again.\n\nNow, I've experienced some problems with ncurses and key detection but\nonly for Insert/Delete and Home/End. If UP/DOWN scrolls the diff view\nsomething is terrible wrong.\n\n> I like viewing the list in the upper and diff/log in the lower\n> at the same time, and that is the primary reason I liked tig, so\n> moving around in the commit list view and not seeing the\n> diff/log updated in sync was major dissapointment at least for\n> me.\n\nOk, well I can just make it optional, if you want the split view always\nto be in sync, even while moving when the main view is in focus.\n\n-- \nJonas Fonseca\n"},{"id":"21282","messageId":"20060605211133.GC17300@diku.dk","threadId":"4378","inReplyTo":"7vejy48wp5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Gitk feature - show nearby tags","fromName":"Jonas Fonseca","fromEmail":"fonseca@diku.dk","sentAt":"2006-06-05T21:11:33Z","receivedAt":"2006-06-05T21:11:33Z","isPatch":false,"sender":{"key":"fonseca@diku.dk","avatar":"https://gravatar.com/avatar/f82f3ad698717c51873b020c750a92438c820a24056dc39fe4d07baa10a92264?d=mp&s=160"},"body":"Junio C Hamano wrote Sun, Jun 04, 2006:\n> I do not necessarily think an ascii-art is needed, nor an\n> appropriate way to present it to the curses user.\n\nWith certain limitations, I think it could be useful for some\nepositories. Optionally, of course.\n\n> When the user wants to \"view\" a commit, you could show from which\n> branch heads and from which tags the commit is reachable, and perhaps\n> which tag is the latest among the ones reachable from that commit, as\n> part of the commit detail information you display on the lower pane\n> (log/diff view).\n\nThanks for recapping, I've added this to the TODO file.\n\n-- \nJonas Fonseca\n"}]}