I was not able to reproduce the problem in my checkout, but I guess if I remove the origin remote I should be able to now. But I am not sure what is the desired way to do this? Is it better to get rid of that "local" variable and be happy with what it was before?
2015-09-14 5:40 GMT+02:00 Joseph Chen <[email protected]>: > @Wayne, > > In case of emergency, you can reverse my previous patch by applying the > attached patch. It will revert to the clean state as before for the single > file of CreateGitVersionHearder.cmake. > > I am embarrassed that the previous patch causes lots of troubles for ones > not using a true git repo in their development environment, and I apologized > sincerely. > > --Joe Chen > > > On 09/13/2015 12:57 PM, Wayne Stambaugh wrote: >> >> Please throw me together a quick patch so I can fix it. I just >> committed Joseph's patch. Would these changes fix the issue @Simon just >> reported? >> >> On 9/13/2015 2:14 PM, Nick Østergaard wrote: >>> >>> Looks ok to me, except that the naming of the _git_LONG_HASH_ORIGIN >>> variable does not match what it is, it should have been >>> _git_LONG_HASH_LOCAL instead. >>> >>> And the line, >>> >>> message(STATUS "Git hash: ${_git_LONG_HASH_ORIGIN}") >>> >>> should also be corrected, I guess. >>> >>> >>> 2015-09-13 20:05 GMT+02:00 Wayne Stambaugh <[email protected]>: >>>> >>>> Joseph, >>>> >>>> I committed your patch in the product branch r6191. Thank you for you >>>> contribution to KiCad. >>>> >>>> Cheers, >>>> >>>> Wayne >>>> >>>> On 9/13/2015 12:50 AM, Joseph Chen wrote: >>>>> >>>>> @Wayne & @Nick, >>>>> >>>>> Attached you can find the new patch file that I've incorporated the >>>>> Nick's inputs. >>>>> >>>>> Thanks, >>>>> >>>>> --Joe >>>>> >>>>> >>>>> On 09/11/2015 08:27 AM, Wayne Stambaugh wrote: >>>>>> >>>>>> Joseph, >>>>>> >>>>>> Please make these changes and resubmit your patch and I will commit >>>>>> it. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Wayne >>>>>> >>>>>> On 9/11/2015 10:19 AM, Nick Østergaard wrote: >>>>>>> >>>>>>> Hi Joseph >>>>>>> >>>>>>> Yes, I agree with you and understand the reasoning. I was just not >>>>>>> able to see the file patched and only reviewed the patch file itself. >>>>>>> I have now tried to apply it. >>>>>>> >>>>>>> Some comments: >>>>>>> >>>>>>> 1. The line just before "# Get origin Repo HEAD" should probably be >>>>>>> an >>>>>>> empth line to match the rest of the execute_process'. >>>>>>> >>>>>>> 2. We also create a long hash variable, although it is not used >>>>>>> anywhere else than for the cmake messaging, but we should probably me >>>>>>> explicit on which exact has that is. As is not that is a _LOCAL hash. >>>>>>> This to match the short hash. >>>>>>> >>>>>>> If you adjust those two points, I think it is fine to merge it. >>>>>>> >>>>>>> 2015-09-11 10:16 GMT+02:00 Joseph Chen <[email protected]>: >>>>>>>> >>>>>>>> Hi Nick, >>>>>>>> >>>>>>>> I very much like the true BZR version number that is produced by >>>>>>>> your script >>>>>>>> when compiling from the git mirror source. This is very helpful >>>>>>>> when >>>>>>>> tracking the matching version of KiCAD from the bzr repo. >>>>>>>> >>>>>>>> In the new way that I proposed for producing BZR version number, I >>>>>>>> pretty >>>>>>>> much borrowed the tick that is being used by Linux kernel: when a >>>>>>>> cloned >>>>>>>> local source tree is the same as the up stream's, the version string >>>>>>>> is like >>>>>>>> "3.2.1" as the official release number. But, after some changes, >>>>>>>> the >>>>>>>> version string becomes "3.2.1-dirty-f6cd3", where "f6cd3" is the >>>>>>>> short hash >>>>>>>> of the local head. This means that the version is not official >>>>>>>> release any >>>>>>>> more. >>>>>>>> >>>>>>>> I hope this trivial patch can help in distinguish a true BZR version >>>>>>>> from >>>>>>>> those with local modifications. >>>>>>>> >>>>>>>> --Joe >>>>>>>> >>>>>>>> >>>>>>>> On 09/10/2015 05:54 PM, Nick Østergaard wrote: >>>>>>>>> >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> This is a matter of what we really want. When I wrote the logic at >>>>>>>>> first, my goal was just to make sure to generate a bzr version that >>>>>>>>> matches how the bzr cmake module did it, when building with an >>>>>>>>> unmodified tree. I think my version complies to that; that is not >>>>>>>>> taking care about weather or not you are on a local banch. >>>>>>>>> >>>>>>>>> I have not tested this patch, but it looks alright to me. I am fine >>>>>>>>> with extending it with this detail, although one could argue that >>>>>>>>> holding the bzr rev as is, is not entirely correct, but if you get >>>>>>>>> the >>>>>>>>> complete version string you can deduce that there are changes. For >>>>>>>>> example as you state the HEAD for the bzr number, you could also >>>>>>>>> state >>>>>>>>> the HEAD and origin/HEAD for the bzr number, like, BZR 1234-1236 if >>>>>>>>> you have two commits in difference from the product branch. >>>>>>>>> >>>>>>>>> I am ok with either, but some people might find it odd as is. >>>>>>>>> >>>>>>>>> But I think the patch is not complete, the auxilarry variables >>>>>>>>> should >>>>>>>>> probably be of the last local commit. That is the variables like >>>>>>>>> _git_LAST_COMITTER and _git_LONG_HASH. (Maybe they are ok, hard to >>>>>>>>> see >>>>>>>>> properly in the patch only, I did not apply it.) >>>>>>>>> >>>>>>>>> Nick >>>>>>>>> >>>>>>>>> 2015-09-10 17:15 GMT+02:00 Wayne Stambaugh <[email protected]>: >>>>>>>>>> >>>>>>>>>> @Nick, have you had a chance to look at this patch? Since you >>>>>>>>>> wrote >>>>>>>>>> this I thought you should have some input. I'm not sure if this >>>>>>>>>> the >>>>>>>>>> correct behavior when using git to generate the KiCad version >>>>>>>>>> string. >>>>>>>>>> It seems as though Joseph is correct. Would you please take a >>>>>>>>>> look at >>>>>>>>>> it when you get a chance and let me know if it should be >>>>>>>>>> committed. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Wayne >>>>>>>>>> >>>>>>>>>> On 8/30/2015 4:24 PM, Joseph Chen wrote: >>>>>>>>>>> >>>>>>>>>>> Please review and apply the attached patch file of >>>>>>>>>>> CreateGitVersion.cmake. >>>>>>>>>>> >>>>>>>>>>> *Issue to be fixed: a False BZR version number** >>>>>>>>>>> * >>>>>>>>>>> The details: >>>>>>>>>>> After cloning the repo of git-source-mirror, and working in my >>>>>>>>>>> own local >>>>>>>>>>> branch, and committing a X times, the BZR version-number that is >>>>>>>>>>> generated by file CreateGitVersion.cmake is incremented by X >>>>>>>>>>> number. >>>>>>>>>>> This is a mismatch of the true BZR number. >>>>>>>>>>> >>>>>>>>>>> The tests: >>>>>>>>>>> _Before applying this patch_: >>>>>>>>>>> >>>>>>>>>>> The command "Copy Version Info" built from the origin "master" >>>>>>>>>>> branch >>>>>>>>>>> displays the following: >>>>>>>>>>> Version: (2015-08-30 *BZR 6134, Git 4e94d52*)-product >>>>>>>>>>> release >>>>>>>>>>> build >>>>>>>>>>> which is correct. >>>>>>>>>>> >>>>>>>>>>> _However_, after creating a local branch based off the "master" >>>>>>>>>>> branch, >>>>>>>>>>> and having committed 2 more times in the local branch, the >>>>>>>>>>> command "Copy >>>>>>>>>>> Version Info" built from the local branch displays the following >>>>>>>>>>> false >>>>>>>>>>> BZR number: >>>>>>>>>>> Version: (2015-08-30 *BZR 6136, Git edfb32e*)-product >>>>>>>>>>> release >>>>>>>>>>> build >>>>>>>>>>> which is _false_, because at the time the official BZR number is >>>>>>>>>>> only >>>>>>>>>>> *6134*. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _After applying this_patch_: >>>>>>>>>>> The command "Copy Version Info" built from the "master" branch >>>>>>>>>>> displays >>>>>>>>>>> the following: >>>>>>>>>>> Version: (2015-08-30 *BZR 6134, Git 4e94d52*)-product >>>>>>>>>>> release >>>>>>>>>>> build >>>>>>>>>>> which is still correct. >>>>>>>>>>> >>>>>>>>>>> Now, the command "Copy Version Info" built from the local branch >>>>>>>>>>> that >>>>>>>>>>> has 2 extra commits displayes the following: >>>>>>>>>>> Version: (2015-08-30 *BZR 6134, Git >>>>>>>>>>> 4e94d52-ede23f9*)-product >>>>>>>>>>> release build >>>>>>>>>>> which is still correct with a _true_ *BZR 6134*, plus it has an >>>>>>>>>>> *added >>>>>>>>>>> GIT short hash* from the local branch HEAD. >>>>>>>>>>> >>>>>>>>>>> This added GIT short hash tells us that the running version is >>>>>>>>>>> built >>>>>>>>>>> based off a true BZR 6134, plus some local modifications up to >>>>>>>>>>> GIT short >>>>>>>>>>> hash of *ede23f9.* >>>>>>>>>>> >>>>>>>>>>> --Joe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>>> Post to : [email protected] >>>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>>>>>> Post to : [email protected] >>>>>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>>>>>> More help : https://help.launchpad.net/ListHelp >>>>>> >>>>>> _______________________________________________ >>>>>> Mailing list: https://launchpad.net/~kicad-developers >>>>>> Post to : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> More help : https://help.launchpad.net/ListHelp >>>>> >>>>> >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> Mailing list: https://launchpad.net/~kicad-developers >>>> Post to : [email protected] >>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>> More help : https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
