{"thread":{"id":"19754","subject":"[PATCH] show-branch: fix segfault when showbranch.default exists","startedAt":"2009-06-09T06:26:44Z","lastAt":"2009-06-10T19:14:20Z","messageCount":12,"participants":["Junio C Hamano","Stephen Boyd","Pierre Habouzit","Harry Duin","Alex Riesen","Jakub Narebski","Nicolas Pitre","Linus Torvalds","Daniel Barkalow"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"115874","messageId":"7vfxe9udln.fsf@alter.siamese.dyndns.org","threadId":"19754","inReplyTo":null,"subject":"[PATCH] show-branch: fix segfault when showbranch.default exists","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-09T06:26:44Z","receivedAt":"2009-06-09T06:26:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When running \"git show-branch\" without any parameter in a repository that\nhas showbranch.default defined, we used to rely on the fact that our\nhandcrafted option parsing loop never looked at av[0].\n\nThe array of default strings had the first real command line argument in\ndefault_arg[0], but the option parser wanted to look at the array starting\nat av[1], so we assigned the address of -1th element to av to force the\nloop start working from default_arg[0].\n\nThis no longer worked since 5734365 (show-branch: migrate to parse-options\nAPI, 2009-05-21), as parse_options_start() saved the incoming &av[0] in\nits ctx->out and later in parse_options_end() it did memmove to ctx->out\n(with ctx->cpidx == 0), overwriting the memory before default_arg[] array.\n\nI am not sure if this is a bug in parse_options(), or a bug in the caller,\nand tonight I do not have enough concentration to figure out which. In\nany case, this patch works the issue around.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-show-branch.c | 14 +++++++++++---\n 1 files changed, 11 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin-show-branch.c b/builtin-show-branch.c\nindex 01bea3b..baec9ed 100644\n--- a/builtin-show-branch.c\n+++ b/builtin-show-branch.c\n@@ -565,7 +565,15 @@ static int git_show_branch_config(const char *var, const char *value, void *cb)\n \tif (!strcmp(var, \"showbranch.default\")) {\n \t\tif (!value)\n \t\t\treturn config_error_nonbool(var);\n-\t\tif (default_alloc <= default_num + 1) {\n+\t\t/*\n+\t\t * default_arg is now passed to parse_options(), so we need to\n+\t\t * mimick the real argv a bit better.\n+\t\t */\n+\t\tif (!default_num) {\n+\t\t\tdefault_alloc = 20;\n+\t\t\tdefault_arg = xcalloc(default_alloc, sizeof(*default_arg));\n+\t\t\tdefault_arg[default_num++] = \"show-branch\";\n+\t\t} else if (default_alloc <= default_num + 1) {\n \t\t\tdefault_alloc = default_alloc * 3 / 2 + 20;\n \t\t\tdefault_arg = xrealloc(default_arg, sizeof *default_arg * default_alloc);\n \t\t}\n@@ -692,8 +700,8 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)\n \n \t/* If nothing is specified, try the default first */\n \tif (ac == 1 && default_num) {\n-\t\tac = default_num + 1;\n-\t\tav = default_arg - 1; /* ick; we would not address av[0] */\n+\t\tac = default_num;\n+\t\tav = default_arg;\n \t}\n \n \tac = parse_options(ac, av, prefix, builtin_show_branch_options,\n"},{"id":"115878","messageId":"4A2E0C88.70805@gmail.com","threadId":"19754","inReplyTo":"7vfxe9udln.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] show-branch: fix segfault when showbranch.default exists","fromName":"Stephen Boyd","fromEmail":"bebarino@gmail.com","sentAt":"2009-06-09T07:17:28Z","receivedAt":"2009-06-09T07:17:28Z","isPatch":true,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"Junio C Hamano wrote:\n> I am not sure if this is a bug in parse_options(), or a bug in the caller,\n> and tonight I do not have enough concentration to figure out which. In\n> any case, this patch works the issue around.\n\nI am low on concentration tonight as well, but this looks right to me.\nParse options is expecting the regular old argv and argc. I overlooked\nthis code path during the conversion (though I remember figuring out\nwhat this path was doing). Faking the argv and argc a little more\naccurately, like you do, should work fine.\n\nOn a side note, I can't remember why I used \nPARSE_OPT_STOP_AT_NON_OPTION. I think it should be 0.\n"},{"id":"115883","messageId":"20090609080612.GG9993@laphroaig.corp","threadId":"19754","inReplyTo":"4A2E0C88.70805@gmail.com","subject":"Re: [PATCH] show-branch: fix segfault when showbranch.default exists","fromName":"Pierre Habouzit","fromEmail":"madcoder@madism.org","sentAt":"2009-06-09T08:06:13Z","receivedAt":"2009-06-09T08:06:13Z","isPatch":true,"sender":{"key":"madcoder@madism.org","avatar":null},"body":"On Tue, Jun 09, 2009 at 12:17:28AM -0700, Stephen Boyd wrote:\n> Junio C Hamano wrote:\n> > I am not sure if this is a bug in parse_options(), or a bug in the caller,\n> > and tonight I do not have enough concentration to figure out which. In\n> > any case, this patch works the issue around.\n> \n> I am low on concentration tonight as well, but this looks right to me.\n> Parse options is expecting the regular old argv and argc. I overlooked\n> this code path during the conversion (though I remember figuring out\n> what this path was doing). Faking the argv and argc a little more\n> accurately, like you do, should work fine.\n\nyes, that's it.\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"115920","messageId":"7viqj5nzgz.fsf@alter.siamese.dyndns.org","threadId":"19754","inReplyTo":"20090609080612.GG9993@laphroaig.corp","subject":"Re: [PATCH] show-branch: fix segfault when showbranch.default exists","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-06-09T16:28:28Z","receivedAt":"2009-06-09T16:28:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pierre Habouzit writes:\n\n> On Tue, Jun 09, 2009 at 12:17:28AM -0700, Stephen Boyd wrote:\n>> Junio C Hamano wrote:\n>> > I am not sure if this is a bug in parse_options(), or a bug in the caller,\n>> > and tonight I do not have enough concentration to figure out which. In\n>> > any case, this patch works the issue around.\n>> \n>> I am low on concentration tonight as well, but this looks right to me.\n>> Parse options is expecting the regular old argv and argc. I overlooked\n>> this code path during the conversion (though I remember figuring out\n>> what this path was doing). Faking the argv and argc a little more\n>> accurately, like you do, should work fine.\n>\n> yes, that's it.\n\nWait a minute, please.\n\nWhy is parse_options() allowed to clobber argv[0] in parse_options_end()\nin the first place?\n\nI think the memmove() is there to allow the caller to find the remaining\narguments after the library parsed out the options in argv[], but wouldn't\nthe caller be expecting to inspect argv[] starting from position 1?\n\nIn other words, anything moved to the position of original argv[0] would\nbe lost, and the problem I stumbled upon was exactly that (it triggered\nbecause the location of argv[0] was invalid and parse_options_end() wrote\ninto it).\n"},{"id":"115924","messageId":"20090609172302.GH9993@laphroaig.corp","threadId":"19754","inReplyTo":"7viqj5nzgz.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] show-branch: fix segfault when showbranch.default exists","fromName":"Pierre Habouzit","fromEmail":"madcoder@madism.org","sentAt":"2009-06-09T17:23:02Z","receivedAt":"2009-06-09T17:23:02Z","isPatch":true,"sender":{"key":"madcoder@madism.org","avatar":null},"body":"On Tue, Jun 09, 2009 at 09:28:28AM -0700, Junio C Hamano wrote:\n> Pierre Habouzit writes:\n> \n> > On Tue, Jun 09, 2009 at 12:17:28AM -0700, Stephen Boyd wrote:\n> >> Junio C Hamano wrote:\n> >> > I am not sure if this is a bug in parse_options(), or a bug in the caller,\n> >> > and tonight I do not have enough concentration to figure out which. In\n> >> > any case, this patch works the issue around.\n> >> \n> >> I am low on concentration tonight as well, but this looks right to me.\n> >> Parse options is expecting the regular old argv and argc. I overlooked\n> >> this code path during the conversion (though I remember figuring out\n> >> what this path was doing). Faking the argv and argc a little more\n> >> accurately, like you do, should work fine.\n> >\n> > yes, that's it.\n> \n> Wait a minute, please.\n> \n> Why is parse_options() allowed to clobber argv[0] in parse_options_end()\n> in the first place?\n> \n> I think the memmove() is there to allow the caller to find the remaining\n> arguments after the library parsed out the options in argv[], but wouldn't\n> the caller be expecting to inspect argv[] starting from position 1?\n> \n> In other words, anything moved to the position of original argv[0] would\n> be lost, and the problem I stumbled upon was exactly that (it triggered\n> because the location of argv[0] was invalid and parse_options_end() wrote\n> into it).\n\nit does because it supposes that the command is there, and that when I\nported the old parsing stuff it's what it was doing.\n\nFWIW I believe it's a misfeature.\n\n-- \n·O· Pierre Habouzit\n··O madcoder@debian.org\nOOO http://www.madism.org\n"},{"id":"115925","messageId":"08614AC584A6ED42BD836DE9286376E12A211FA9CA@spswchi6mail1.peak6.net","threadId":"19754","inReplyTo":"20090609172302.GH9993@laphroaig.corp","subject":"branch management","fromName":"Harry Duin","fromEmail":"hduin@optionshouse.com","sentAt":"2009-06-09T17:35:24Z","receivedAt":"2009-06-09T17:35:24Z","isPatch":false,"sender":{"key":"hduin@optionshouse.com","avatar":null},"body":"I have a few questions on using git. This forum does not seem to\naddress much usage questions, so feel free to direct me to another\nplace, if I am at the wrong address :-)\n\nMy questions are on branch management. We are about to switch to git\nand are figuring out some best practices. We would like to be able\nto maintain our branch history for a certain period of time (years).\n\n1. We have different repos for doing the integration merging. In\naddition to that we have a golden repos, containing what is in\nproduction. The branch history gets pushed by developers to the\nintegration repos, but not to the golden repos. Since our integration\nrepos are created for each integration, this means I have lost my\nbranch history when an integration repos gets deleted.. For now, we\nare thinking of having the integrator (an actual person) push the\nbranch history to another golden repos that will be used to simply\nhold all branch history. We could push all branch history to the one\ngolden repos (that holds production), but it seems like the vast\namount of history might be disadvantageous when we clone repos. Anyone\nhave a suggestion as to what is the best approach?\n\n\n2. What command do I use to display only the list of files updated by/for a\nbranch? This means I want to exclude files that were merged in from say\nmaster - these files are not part of the branch development.\n\nThanks,\n\nHarry\n\n\n_______________________________________________________\n\nwww.peak6.com\n\nThe information in this email or in any file attached\nhereto is intended only for the personal and confiden-\ntial use of the individual or entity to which it is\naddressed and may contain information that is propri-\netary and confidential. If you are not the intended\nrecipient of this message you are hereby notified that\nany review, dissemination, distribution or copying of\nthis message is strictly prohibited. This communica-\ntion is for information purposes only and should not\nbe regarded as an offer to sell or as a solicitation\nof an offer to buy any financial product. Email trans-\nmission cannot be guaranteed to be secure or error-\nfree. P6070214\n\n"},{"id":"115982","messageId":"20090609195018.GA17848@blimp.localdomain","threadId":"19754","inReplyTo":"08614AC584A6ED42BD836DE9286376E12A211FA9CA@spswchi6mail1.peak6.net","subject":"Re: branch management","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-06-09T19:50:18Z","receivedAt":"2009-06-09T19:50:18Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"Harry Duin, Tue, Jun 09, 2009 19:35:24 +0200:\n> My questions are on branch management. \n\nYou seem to think about branches as they are in CVS or SVN (just\ndirectories with in-system metadata). You'll find the Git's branching\ndifferent (being more about history, not at all about directory\nstructure).\n\n> 1. We have different repos for doing the integration merging. In\n> addition to that we have a golden repos, containing what is in\n> production. The branch history gets pushed by developers to the\n> integration repos, but not to the golden repos. Since our integration\n> repos are created for each integration, this means I have lost my\n> branch history when an integration repos gets deleted..\n\nNo. As long as there is something, basing its history on the history\nof the integration repos (and I assume that your \"golden\", aka\n\"release\" or \"maintenance\" elsewhere, do just that) the history is\nthere. Forever. As it is on every developers machine with a\ndistributed VCS.\n\n> 2. What command do I use to display only the list of files updated by/for a\n> branch?\n\nDo you mean the files changed since the branch (presumably \"development\")\ndiverged from some other branch (presumably \"golden\")?\nWhat for?\n\n> This means I want to exclude files that were merged in from say\n> master - these files are not part of the branch development.\n\nYou better not exclude files (and while at it, stop thinking about\nfiles when working with _history_).\n\nTry describing the problem on _change_ (aka \"commit\", or point in time\nor history) level.\n\nP.S. Your (re?)mailer seems to be broken. This mail is not very\ncorrect base64 and gmail does not even decode it.\n"},{"id":"116007","messageId":"08614AC584A6ED42BD836DE9286376E12A211FA9D0@spswchi6mail1.peak6.net","threadId":"19754","inReplyTo":"20090609195018.GA17848@blimp.localdomain","subject":"RE: branch management","fromName":"Harry Duin","fromEmail":"hduin@optionshouse.com","sentAt":"2009-06-10T14:02:54Z","receivedAt":"2009-06-10T14:02:54Z","isPatch":false,"sender":{"key":"hduin@optionshouse.com","avatar":null},"body":"Yes, I am aware that branching is different in git than what I have used so far with SVN. But apart from the implementation, I have some information that I want to gather about work done on a branch. Here are a few questions/scenarios that I want to make sure we can handle. Remember that our branches are mapped one to one to a Jira ticket.\n\n1. show all code changes performed on a branch (for code review)\n2. show list of files/directories touched by a branch (useful when looking for past fixes, but are unsure where the fix was done)\n\nSo far I have not found the exact syntax to get this information, but am convinced that git can provide it!\n\n-Harry\n\n-----Original Message-----\nFrom: Alex Riesen [mailto:raa.lkml@gmail.com] \nSent: Tuesday, June 09, 2009 2:50 PM\nTo: Harry Duin\nCc: git@vger.kernel.org\nSubject: Re: branch management\n\nHarry Duin, Tue, Jun 09, 2009 19:35:24 +0200:\n> My questions are on branch management. \n\nYou seem to think about branches as they are in CVS or SVN (just\ndirectories with in-system metadata). You'll find the Git's branching\ndifferent (being more about history, not at all about directory\nstructure).\n\n> 1. We have different repos for doing the integration merging. In\n> addition to that we have a golden repos, containing what is in\n> production. The branch history gets pushed by developers to the\n> integration repos, but not to the golden repos. Since our integration\n> repos are created for each integration, this means I have lost my\n> branch history when an integration repos gets deleted..\n\nNo. As long as there is something, basing its history on the history\nof the integration repos (and I assume that your \"golden\", aka\n\"release\" or \"maintenance\" elsewhere, do just that) the history is\nthere. Forever. As it is on every developers machine with a\ndistributed VCS.\n\n> 2. What command do I use to display only the list of files updated by/for a\n> branch?\n\nDo you mean the files changed since the branch (presumably \"development\")\ndiverged from some other branch (presumably \"golden\")?\nWhat for?\n\n> This means I want to exclude files that were merged in from say\n> master - these files are not part of the branch development.\n\nYou better not exclude files (and while at it, stop thinking about\nfiles when working with _history_).\n\nTry describing the problem on _change_ (aka \"commit\", or point in time\nor history) level.\n\nP.S. Your (re?)mailer seems to be broken. This mail is not very\ncorrect base64 and gmail does not even decode it.\n\n_______________________________________________________\n\nwww.peak6.com\n\nThe information in this email or in any file attached\nhereto is intended only for the personal and confiden-\ntial use of the individual or entity to which it is\naddressed and may contain information that is propri-\netary and confidential. If you are not the intended\nrecipient of this message you are hereby notified that\nany review, dissemination, distribution or copying of\nthis message is strictly prohibited. This communica-\ntion is for information purposes only and should not\nbe regarded as an offer to sell or as a solicitation\nof an offer to buy any financial product. Email trans-\nmission cannot be guaranteed to be secure or error-\nfree. P6070214\n"},{"id":"116013","messageId":"m3d49c40ai.fsf@localhost.localdomain","threadId":"19754","inReplyTo":"08614AC584A6ED42BD836DE9286376E12A211FA9D0@spswchi6mail1.peak6.net","subject":"Re: branch management","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-06-10T14:43:25Z","receivedAt":"2009-06-10T14:43:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Harry Duin writes:\n\n> Yes, I am aware that branching is different in git than what I have\n> used so far with SVN. But apart from the implementation, I have some\n> information that I want to gather about work done on a branch. Here\n> are a few questions/scenarios that I want to make sure we can\n> handle. Remember that our branches are mapped one to one to a Jira\n> ticket.\n>\n\nFirst, the syntax to get all commits in a branch 'branch' which was\ncreated ffrom trunk, i.e. branch named 'master' would be\n\n master..branch\n\nSee git-rev-list(1), git-rev-parse(1) and git-log(1) for details\nof A..B syntax.\n\n> 1. show all code changes performed on a branch (for code review)\n\n$ git log -p master..branch\n\n> 2. show list of files/directories touched by a branch (useful when\n> looking for past fixes, but are unsure where the fix was done)\n\nIf you can use pickaxe search (git log -S...), or git-blame, or just\nlooking throught \"git log ... -- \", you can use\n\n$ git rev-list master..branch | \n git diff-tree --stdin -r --name-only |\n sort -u\n\n(excluding sha1 hashes).\n\n> \n> So far I have not found the exact syntax to get this information,\n> but am convinced that git can provide it!\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"116015","messageId":"alpine.LFD.2.00.0906101118070.31536@xanadu.home","threadId":"19754","inReplyTo":"m3d49c40ai.fsf@localhost.localdomain","subject":"Re: branch management","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2009-06-10T15:28:21Z","receivedAt":"2009-06-10T15:28:21Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 10 Jun 2009, Jakub Narebski wrote:\n\n> Harry Duin writes:\n> \n> > 2. show list of files/directories touched by a branch (useful when\n> > looking for past fixes, but are unsure where the fix was done)\n> \n> If you can use pickaxe search (git log -S...), or git-blame, or just\n> looking throught \"git log ... -- \", you can use\n> \n> $ git rev-list master..branch | \n> git diff-tree --stdin -r --name-only |\n> sort -u\n\nWhat I use in that case is simply\n\n\tgit diff --stat master...branch\n\n\nNicolas\n"},{"id":"116020","messageId":"alpine.LFD.2.01.0906101026121.6847@localhost.localdomain","threadId":"19754","inReplyTo":"alpine.LFD.2.00.0906101118070.31536@xanadu.home","subject":"Re: branch management","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2009-06-10T17:37:16Z","receivedAt":"2009-06-10T17:37:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 10 Jun 2009, Nicolas Pitre wrote:\n\n> On Wed, 10 Jun 2009, Jakub Narebski wrote:\n> \n> > Harry Duin writes:\n> > \n> > > 2. show list of files/directories touched by a branch (useful when\n> > > looking for past fixes, but are unsure where the fix was done)\n> > \n> > If you can use pickaxe search (git log -S...), or git-blame, or just\n> > looking throught \"git log ... -- \", you can use\n> > \n> > $ git rev-list master..branch | \n> > git diff-tree --stdin -r --name-only |\n> > sort -u\n> \n> What I use in that case is simply\n> \n> \tgit diff --stat master...branch\n\nNo, that's not going to work in general. The \"master...branch\" thing works \nmost of the time, but there isn't always a single merge-point, and in the \ncase of criss-cross merges, you'll get it wrong.\n\nIt will also hide changes that got reverted (or undone some other way), \nwhich can be relevant.\n\nThat said, the \"git rev-list | git diff-tree\" thing has a new name. We \ncall it \"git log\". \n\nSo what Jakub wrote can generally be written as\n\n\tgit log --name-only --pretty=format:'' master..branch | sort -u\n\nif you're willing to accept the empty line from all the suppressed commit \nmessages (with that \"git diff-tree\" he'll see all the commit numbers, \nthough, so I guess the 'git log' thing is still better)\n\n\t\t\tLinus\n"},{"id":"116026","messageId":"alpine.LNX.2.00.0906101425420.2147@iabervon.org","threadId":"19754","inReplyTo":"08614AC584A6ED42BD836DE9286376E12A211FA9D0@spswchi6mail1.peak6.net","subject":"RE: branch management","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-06-10T19:14:20Z","receivedAt":"2009-06-10T19:14:20Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 10 Jun 2009, Harry Duin wrote:\n\n> Yes, I am aware that branching is different in git than what I have used \n> so far with SVN. But apart from the implementation, I have some \n> information that I want to gather about work done on a branch. Here are \n> a few questions/scenarios that I want to make sure we can handle. \n> Remember that our branches are mapped one to one to a Jira ticket. \n\nWith respect to the branches that other people see, work in git isn't done \n\"on\" a branch, but rather \"for\" a branch (or more than one branch); it's \nmost literally done \"on\" a branch on somebody's workstation that doesn't \nmatter to anybody else, and it may be borrowed from some other developer \nwho happens to have done something relevant but not gotten it into \nproduction yet. This actually should match your model much better than \nSVN. I'd say you should have a git repository associated with Jira, where\nyou've got a branch for each ticket. This repository gets maintained along \nwith your ticket database, since it's really not about the history of work \non the product but the disposition of bugs in the bug tracker.\n\n> 1. show all code changes performed on a branch (for code review)\n\nGenerally, you want \"git log master..branch\", but note that this only \nworks for code review, not after the fact, because that branch becomes \npart of master when it gets integrated. If you're looking for \"the new \ncode that goes to this ticket\", this kind of makes sense, because when the \nticket is done, the code isn't new any more.\n\nAlso, if you've got a cluster of related tickets, some code may be done \nthat goes towards all of them, and therefore appears new the first time \nany of them is code reviewed, but becomes part of master before the last \nticket is reviewed; so the results here may change (with stuff becoming no \nlonger worth reviewing) after the code is complete but before review is \ncomplete.\n\nYou may also want to have a branch for \"master relative to this ticket\", \nwhich is master as of the point where the problem was still there (but \nwhich includes all of the changes that the developer merged in from other \npeople that aren't part of the work for the ticket). Then you can do \"git \nlog base-100..ticket-100\" to see the work that contributes to the ticket \nbeing resolved that didn't get into master for any other ticket. (That is \nto say, tickets generally assume that the rest of the product exists and \nworks well enough to get to the point of the particular ticket but not to \nresolve the ticket; in order to maintain in the future a record of what \nthis reference state was, you need another branch for that, because the \nfuture of your product has the ticket resolved and no work at all needed \nfor it).\n\n> 2. show list of files/directories touched by a branch (useful when \n> looking for past fixes, but are unsure where the fix was done) \n\n\"git log --stat ticket-branch\" will probably answer your question pretty \nquickly (maybe requiring looking through several commits, though). If \nyou've got a reference branch from above, you can use \"git log --stat \nbase-branch..ticket-branch\".\n\nOf course, there's the conceptual issue that maybe somebody else, working \non something different, will have done some work that is useful and turns \nout to be critical to the eventual resolution of the ticket. And it's also \nlikely that other stuff was done that's totally irrelevant. And the \ndifference is not captured electronically at all, but is entirely a matter \nof whether the developer decided to merge master back into their branch \nwith the goal of getting that particular change or some other change that \nwent gold around the same time.\n\nSo it's probably best to do \"git log --stat ticket-branch\" and keep \nlooking through the results until you find what you're looking for, no \nmatter how it got there.\n\n> So far I have not found the exact syntax to get this information, but am \n> convinced that git can provide it! \n\nGit can provide all sorts of stuff, but it's also able to provide lots of \ninformation that SVN can't provide, and can't necessarily limit itself to \ntelling you things that SVN would be able to capture. So it tells you many \nthings, starting from the most likely relevant and going down to very \nunlikely (but still vaguely possible).\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}