...

then a query to the git tree will show you precisely where a certain

commit is located

- how exactly would you perform such a query? - what is the preferred format for reporting such a commit number in a bug report?

<somewhat off-topic, perhaps, but you need to remember that a lot of bug triage and analysis has in the past been performed by people who are not necessarily programmers, and who may not have a great deal of patience, or tolerance, for a system that has suddenly become extremely abstruse, to put it as politely as possible.>

Alvin

-- View this message in context: http://inkscape.13.x6.nabble.com/two-trivial-questions-concerning-the-gitlab... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

thanks, on my system that produced the answer:

git log -1 --date=local --format="%cd (%h)" Thu Jun 22 22:09:08 2017 (213013a)

I think this answer is probably correct since there was indeed a commit made at: commit 213013a5a08d37bd29da167eece256be75cebe7c Author: Felipe Corrêa da Silva Sanches <juca@...2270...> Date: Thu Jun 22 23:09:08 2017 -0300

However, it does not exactly answer my question. Assume that someone has reported that a bug was fixed in commit number: '0edfdf95' How would I find out when this was done? In other words, what is the mechanism whereby someone can verbally report that a bug was fixed in a certain commit, and that someone else can independently confirm when it was fixed? Sorry to be a pest, but this is an essential feature of a bug reporting/fixing system.

Alvin

-- View this message in context: http://inkscape.13.x6.nabble.com/two-trivial-questions-concerning-the-gitlab... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

On Fri, Jun 23, 2017 at 10:10:15AM -0500, Terry Brown wrote:

On Fri, 23 Jun 2017 07:42:29 -0700 (MST) alvinpenner <penner@...1856...> wrote:

...

However, it does not exactly answer my question. Assume that someone has reported that a bug was fixed in commit number: '0edfdf95' How would I find out when this was done? In other words, what is the

If you just want to relate git hashes to dates:

git log --pretty='format:%H %ci'

(see https://git-scm.com/docs/git-log#_pretty_formats)

this would istantly show you that commit (I personally find `show` more useful than `log` for this use case): git show 0edfdf95 If you want to change the current working tree to that commit so you can e.g. try to build it there and do whatever you want to do: git checkout 0edfdf95

I can see that you feel a bit lost with git. It's just a different program with its own options that are different than bzr's, don't feel angry toward it :)

one final comment and then I promise we will never speak of this again. It is possible that this is a Windows-specific issue. On Windows the format '%H %ci' is not acceptable while the format "%H %ci" works correctly, see below:

....................................................................... C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty=format:'%H %ci' 0edfdf95 fatal: ambiguous argument '%ci'': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty=format:"%H %ci" 0edfdf95 0edfdf950796befdb42ab9b2ef76c76483d9dbb1 2017-06-21 21:04:53 -0300

-- View this message in context: http://inkscape.13.x6.nabble.com/two-trivial-questions-concerning-the-gitlab... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Am 23.06.2017 um 18:21 schrieb alvinpenner:

one final comment and then I promise we will never speak of this again. It is possible that this is a Windows-specific issue. On Windows the format '%H %ci' is not acceptable while the format "%H %ci" works correctly, [...]

You might try to ask / file an issue at https://github.com/git-for-windows/git/issues (maybe they know the answer, maybe it's an actual bug).

That being said there are alternatives to using git from cmd.exe that will make your life easier:

* Use "Git Bash" (it ships with Git for Windows and provides a proper shell environment like it is available on Linux. It makes struggling with the limitations of the Windows command line unnecessary and already contains a lot of helpful tools (like 'diff') * Use MSYS2 (as a matter of fact Git for Windows is based on / compiled with MSYS2 and the "Git Bash" is basically an MSYS2 shell). I'd suggest you to look into it eventually anyway, since at this point I'd say MSYS2 is the recommended way to build Inkscape on Windows. I certainly won't touch devlibs for master anymore and I'm even considering to compile 0.92.2 with it, at least as a "beta" or "technology preview". All my development happens on MSYS2 nowadays. * Use "Git GUI". It ships with Git for Windows and simplifies stuff like looking at diffs and the log greatly. * Use a dedicated GUI front-end for Git. Personally I'm working a lot with SourceTree [1] which has a lot of features that I use regularly and are not convenient to use on the command line (at least for me), e.g. o looking at / searching in commit history o git blame o looking at commit diffs o staging / adding a list of files (simply by using checkboxes instead of specifying all filenames); it even supports staging parts of files (e.g. I can choose to exclude my debug output from a commit line-by-line - try that on a command line without crying!).

Regards, Eduard

[1] https://www.sourcetreeapp.com/

There is also the command "git describe", which will show how many commits were made from the most recent tag:

$ git describe --tags INKSCAPE_0_92_PRE1-1666-gd010732ae4

1666 is the number of commits since Inkscape 0.92-pre1. However, this is not a recommended way to identify commits.

2017-06-23 12:16 GMT-07:00 alvinpenner <penner@...1856...>:

thanks for all the help, I have submitted a bug report to git at:

https://github.com/git-for-windows/git/issues/1216

Alvin

-- View this message in context: http://inkscape.13.x6.nabble.com/two-trivial-questions-concerning-the-gitlab... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

---

Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

Am Samstag, 24. Juni 2017, 16:44:17 CEST schrieb alvinpenner:

strange, in my case, when I run this command, I get:

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git describe --tags fatal: No names found, cannot describe anything.

Did you maybe make a shallow clone (using --depth or suchlike)? Those don't contain any history, so of course they lack tags, too.

Alvin

Tobias

Am Sonntag, 25. Juni 2017, 03:25:11 CEST schrieb alvinpenner:

no, I used the pull command. The normal command I use is as follows:

That is for updating your copy. I meant the initial "git clone".

What does "git log --format=oneline | wc -l" return? For me it's 19048.

[...]

Tobias

okay, I have temporarily modified my path to include the program wc, so now I get:

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --format=oneline | wc -l 19048

-- View this message in context: http://inkscape.13.x6.nabble.com/two-trivial-questions-concerning-the-gitlab... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

this was done about a month ago, so I forget the details, but here is the documentation that I kept of what I did. I executed the three commands:

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git init git clone https://gitlab.com/inkscape/inkscape.git git pull https://gitlab.com/inkscape/inkscape.git

- the clone command downloaded about 2 GB of data. - then the pull command also downloaded about 2 GB of data. - then I discovered that I had two duplicate versions of the entire inkscape directory in two different locations. So I decided to try to find out which one was the correct one. So I waited a day or two and executed the pull command again, and found out which particular repository got updated. The location that got updated was in the directory: C:\Users\penne_000\AppData\Roaming\InkscapeGit\src> - so now that I knew which version was the correct version, I deleted the other version which was not needed. - so I have been executing pull commands successfully to this version, and also compiling it successfully as well. - ideally it would have been nice if the clone command and the pull command would both use the same directory and the same repository, but that does not seem to be possible, so at this point I gave up and just used it as is.

Alvin

-- View this message in context: http://inkscape.13.x6.nabble.com/two-trivial-questions-concerning-the-gitlab... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

Am Sonntag, 25. Juni 2017, 12:15:58 CEST schrieb alvinpenner:

okay, the following sequence of commands appears to work:

git init

"git init" is not needed. I am not sure if it can cause problems.

git clone https://gitlab.com/inkscape/inkscape.git cd inkscape git pull https://gitlab.com/inkscape/inkscape.git

Just run "git pull". No need to specify the remote side.

with this sequence, the following command works: C:\Users\penne_000\AppData\Roaming\InkscapeGit\inkscape>git describe --tags INKSCAPE_0_92_PRE1-1666-gd010732

I have not yet been able to confirm the pull command because nobody has yet committed anything since my clone, currently I get: C:\Users\penne_000\AppData\Roaming\InkscapeGit\inkscape>git pull https://gitlab.com/inkscape/inkscape.git From https://gitlab.com/inkscape/inkscape

• branch HEAD -> FETCH_HEAD

Already up-to-date.

I will try to confirm the pull command tomorrow, with fresh data. I wonder if someone could confirm this, or update the Inkscape documentation to include the necessary 'cd inkscape' command, because this command seems to be essential in order to make sure that the pull data goes into the correct location.

If you just used "git pull" as is written in the Wiki page then it would have complained instead of fetching another copy as it seemed to do.

So, in the end you need:

git clone https://gitlab.com/inkscape/inkscape.git

which gives you a directory "inkscape". Everything else from now on will happen inside that directory, including the regular

git pull

Alvin

Tobias

thanks for the advice, I like the idea of the date/time format. as far as the log command is concerned, I have not been able to get it to work. Attached are some of the attempts I made, all of which failed. Do you have a specific example of how to use this command to get the date/time for a specific commit? again, I apologize for asking such obvious questions, but I find the git documentation to be unintelligible, and I am deliberately trying to approach this from the point of view of a non-expert user, not a programmer.

Alvin ...............................................................................................

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty='format:%H %ci' fatal: ambiguous argument '%ci'': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty='format:%H %ci' 12345678 fatal: ambiguous argument '%ci'': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty='format:%H %ci' 0edfdf95 fatal: ambiguous argument '%ci'': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty='format:%H %ci' '0edfdf95' fatal: ambiguous argument '%ci'': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty='format:%H %ci' commit 0edfdf95 fatal: ambiguous argument '%ci'': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]'

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty='format:%H %ci' commit <0edfdf95> The syntax of the command is incorrect.

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty='format:%H %ci' <0edfdf95> The syntax of the command is incorrect.

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty='format:%H' <0edfdf95> The syntax of the command is incorrect.

C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --pretty='format:%H' 0edfdf95 'format:0edfdf950796befdb42ab9b2ef76c76483d9dbb1'

-- View this message in context: http://inkscape.13.x6.nabble.com/two-trivial-questions-concerning-the-gitlab... Sent from the Inkscape - Dev mailing list archive at Nabble.com.

2017-06-23 9:59 GMT-03:00 alvinpenner <penner@...1856...>:

...

...

then a query to the git tree will show you precisely where a certain

commit is located

• how exactly would you perform such a query?

visit the webpage: https://gitlab.com/inkscape/inkscape/commit/0868ec95

replacing 0868ec95 with the actual commit you're interested in. That will show you all the metadata such as author, commit date&time, description, code changes, etc...

• what is the preferred format for reporting such a commit number in a bug

report?

Please, always refer to the commit hash when reporting a bug, because that is absolutely the most precise way to refer to a commit unambiguously.

On Fri, Jun 23, 2017 at 12:23:38PM -0300, Felipe Sanches wrote:

2017-06-23 9:59 GMT-03:00 alvinpenner <penner@...1856...>:

...

...

...

then a query to the git tree will show you precisely where a certain

commit is located

• how exactly would you perform such a query?

visit the webpage: https://gitlab.com/inkscape/inkscape/commit/0868ec95

replacing 0868ec95 with the actual commit you're interested in. That will show you all the metadata such as author, commit date&time, description, code changes, etc...

Alvin, if you haven't already, try:

git show 0868ec95

I find I use this command a lot.

...

• what is the preferred format for reporting such a commit number in a bug

report?

Please, always refer to the commit hash when reporting a bug, because that is absolutely the most precise way to refer to a commit unambiguously.

In bug reports, a common practice I've seen in the linux and x.org communities is to cut and paste the commit message, so like:

Bug 123 ------------------------------------------------------------------------

... In testing your suggested change, I no longer saw the issue.

Great, thanks for testing. Pushed:

commit 0868ec95edd45394fcf583bf3f1cfa311e8a4c1d Author: Felipe Corrêa da Silva Sanches <juca@...2270...> AuthorDate: Thu Jun 22 21:56:51 2017 -0300 Commit: Felipe Corrêa da Silva Sanches <juca@...2270...> CommitDate: Thu Jun 22 21:58:21 2017 -0300

rename SPIVariableFontAxisOrNormal => SPIFontVariationSettings and implement full parsing of multiple axes and respective design-space coordiantes. ------------------------------------------------------------------------

For the triager it's no extra work to cut and paste the entire description versus just the commit SHA, but it communicates a lot more information to the reader.

Bryce