two trivial questions concerning the gitlab repository
1. currently, if I compile Inkscape from gitlab, it reports the rev number as follows: Inkscape 0.92+devel unknown Are there any plans to include a rev number into this report?
2. currently, if I execute git log, I get the following sequence of commit numbers: commit 213013a5a08d37bd29da167eece256be75cebe7c commit 0868ec95edd45394fcf583bf3f1cfa311e8a4c1d commit f836a482511f299034e84f2e153f31698904f92b commit 27f13805c97fcb517982009e2bfb3fd9ad6e413f commit 6e1ecba04f030e650e12edec2ad7a57530c661e4 commit 506e737427861bc1d288c498723d63d56a8075ce commit 0edfdf950796befdb42ab9b2ef76c76483d9dbb1
where I have edited out the text info. I am not able to detect the chronological sequence of these numbers. I understand that the first 8 digits can be used as a shorthand, but these do not seem to be chronologically ordered either. For purposes of bug tracking it would be very helpful to be able to report a rev number that was chronologically ordered. Are there any plans to do so, or am I missing something really obvious here?
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.
Hi Alvin,
Git doesn't have revision numbers, it just has hashes. In a way this is good, because you could theoretically prepend commits and the commit hash would stay the same.
The bad news is that it's not possible to get a solid rev number as such. You can add up all the revisions so far, but that isn't useful on the command line.
So we're stuck with non-chronological commit hashes.
Although we can also uses tags, which makes it a bit easier for the bigger revision markers.
Best Regards, Martin Owens
On Fri, 2017-06-23 at 04:21 -0700, alvinpenner wrote:
- currently, if I compile Inkscape from gitlab, it reports the rev
number as follows: Inkscape 0.92+devel unknown Are there any plans to include a rev number into this report?
- currently, if I execute git log, I get the following sequence of
commit numbers: commit 213013a5a08d37bd29da167eece256be75cebe7c commit 0868ec95edd45394fcf583bf3f1cfa311e8a4c1d commit f836a482511f299034e84f2e153f31698904f92b commit 27f13805c97fcb517982009e2bfb3fd9ad6e413f commit 6e1ecba04f030e650e12edec2ad7a57530c661e4 commit 506e737427861bc1d288c498723d63d56a8075ce commit 0edfdf950796befdb42ab9b2ef76c76483d9dbb1
where I have edited out the text info. I am not able to detect the chronological sequence of these numbers. I understand that the first 8 digits can be used as a shorthand, but these do not seem to be chronologically ordered either. For purposes of bug tracking it would be very helpful to be able to report a rev number that was chronologically ordered. Are there any plans to do so, or am I missing something really obvious here?
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/two-tr ivial-questions-concerning-the-gitlab-repository-tp4980326.html 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
These are the git repo commit hashes. Yes, you are correct that they do not explicitely convey a cronological ordering. But they implicitely do so, since they point to specific commits in the git tree. Since git is distributed, there really no way (as far as I can tell) of attributing sequential numbers to commits, because there may be developers creating new commits in their own branches or remote repos, and there's no central authority emitting such ascending order numbers.
We could, of course, append a date&time string to the version-id if the concern is that we'd like to grasp the age of a certain build. If the concern is bug tracking, then a query to the git tree will show you precisely where a certain commit is located, based on its hash.
2017-06-23 8:21 GMT-03:00 alvinpenner <penner@...1856...>:
- currently, if I compile Inkscape from gitlab, it reports the rev number as
follows: Inkscape 0.92+devel unknown Are there any plans to include a rev number into this report?
- currently, if I execute git log, I get the following sequence of commit
numbers: commit 213013a5a08d37bd29da167eece256be75cebe7c commit 0868ec95edd45394fcf583bf3f1cfa311e8a4c1d commit f836a482511f299034e84f2e153f31698904f92b commit 27f13805c97fcb517982009e2bfb3fd9ad6e413f commit 6e1ecba04f030e650e12edec2ad7a57530c661e4 commit 506e737427861bc1d288c498723d63d56a8075ce commit 0edfdf950796befdb42ab9b2ef76c76483d9dbb1
where I have edited out the text info. I am not able to detect the chronological sequence of these numbers. I understand that the first 8 digits can be used as a shorthand, but these do not seem to be chronologically ordered either. For purposes of bug tracking it would be very helpful to be able to report a rev number that was chronologically ordered. Are there any plans to do so, or am I missing something really obvious here?
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
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.
For inkscape-web, we're using: git log -1 --date=local --format="%cd (%h)"
resulting in Thu Jun 15 18:07:08 2017 (a170251)
Maren
Am 23.06.2017 um 14:59 schrieb alvinpenner:
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.
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
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, 23 Jun 2017 07:42:29 -0700 (MST) alvinpenner <penner@...1856...> wrote:
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'
/an/ answer at the end of my response below (somewhat out of sequence because of email issues).
A project I work on uses YYYMMDDHHMMSS to ID commits (in addition to the git hash). Chances of two authors submitting at the same second are minuscule. I think, the way we set it up, it reports local time, so that could be confusing in some cases.
We use that for a few reasons. A download of a git commit can't include its own hash. Non-programmers probably understand 20170623075434 as a build ID more intuitively than 42da7b2. The third thing I forgot.
We use a git commit hook to update this value in a file the code reads and reports at runtime, and also to add the number at the bottom of the commit msg. This only works when developers install the git hook (trivial but easy to forget), so we just handle its absence gracefully.
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)
Cheers -Terry
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.
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
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 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'
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 :)
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.
visit the webpage:
https://gitlab.com/inkscape/inkscape/commit/0868ec95
thanks for the advice. I agree that this command works, but it is not very user-friendly. It would be better if the log command could be used for this purpose, except that I have not yet figured out how...
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 for the help, I had good success with the command:
git log 0edfdf95
Well, that was embarrassingly easy. I think the problem was that the git documentation was attempting to teach me how to run, when I did not yet know how to crawl. A simple example is worth a thousand words.
sorry for the noise, 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.
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.
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
On Fri, 23 Jun 2017 09:21:24 -0700 (MST) alvinpenner <penner@...1856...> wrote:
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:
Yes, that was my mistake, not really git related, unix command line uses "" and '', with different but often interchangeable effect, whereas Windows command line only uses "".
Cheers -Terry
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
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.
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
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.
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 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
no, I used the pull command. The normal command I use is as follows:
..............................................................................
C:\Users\penne_000\AppData\Roaming\InkscapeGit>git pull https://gitlab.com/inkscape/inkscape.git remote: Counting objects: 75, done. remote: Compressing objects: 100% (39/39), done. remote: Total 75 (delta 56), reused 55 (delta 36) Unpacking objects: 100% (75/75), done.
* branch HEAD -> FETCH_HEAD Updating 213013a..d010732 Fast-forward share/ui/CMakeLists.txt | 2 +- share/ui/commands-toolbar.ui | 38 +++ share/ui/menus.xml | 304 +++++++++++++++++++++++ share/ui/select-toolbar.ui | 383 +++++++++++++++++++++++++++++ share/ui/snap-toolbar.ui | 28 +++ share/ui/tool-toolbar.ui | 39 +++ src/io/resource.cpp | 36 ++- src/io/resource.h | 2 + src/widgets/toolbox.cpp | 563 ++++--------------------------------------- 9 files changed, 875 insertions(+), 520 deletions(-) create mode 100644 share/ui/commands-toolbar.ui create mode 100644 share/ui/menus.xml create mode 100644 share/ui/select-toolbar.ui create mode 100644 share/ui/snap-toolbar.ui create mode 100644 share/ui/tool-toolbar.ui ........................................................................................................ this gives me the history in the form:
C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log commit d010732ae4710cd01b7fbe335663a0920055adbd Merge: 213013a aa0f0c0 Author: Martin Owens <doctormo@...400...> Date: Fri Jun 23 11:42:10 2017 -0400
Merge branch 'ui-files-for-ui-xml'
-- 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, 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
the response I get is: C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --format=oneline | wc -l 'wc' is not recognized as an internal or external command, operable program or batch file.
as for the initial creation of the repository, I followed the documentation at the location: http://wiki.inkscape.org/wiki/index.php/Working_with_Git
-- 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.
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.
Am Sonntag, 25. Juni 2017, 08:13:19 CEST schrieb alvinpenner:
the response I get is: C:\Users\penne_000\AppData\Roaming\InkscapeGit>git log --format=oneline | wc -l 'wc' is not recognized as an internal or external command, operable program or batch file.
Right, sorry, that won't work on Windows.
as for the initial creation of the repository, I followed the documentation at the location: http://wiki.inkscape.org/wiki/index.php/Working_with_Git
That page lists both regular "git clone" and shallow clones with "--depth 1". Can you remember which one you used? If unsure I'd advice to nuke your checkout and start over fresh. With a complete git clone. The end result should be about 1.5 GB in size. The shallow clone is just a few hundred MB. That may also tell you what you got.
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.
okay, the following sequence of commands appears to work:
git init git clone https://gitlab.com/inkscape/inkscape.git cd inkscape git pull https://gitlab.com/inkscape/inkscape.git
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
* 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.
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 help. I did actually, initially, try the command 'git pull', but it didn't work, which was why I switched to the use of 'git pull https://gitlab.com/inkscape/inkscape.git' instead. I will now use 'git pull' in the future. I think the problem with the Wiki page (https://inkscape.org/en/develop/inkscape-git/) is that it does not explicitly indicate that one needs to switch directories before executing some of these commands. It seems to imply that all of these commands can be executed from within the same directory, which is not true. It might be helpful to indicate precisely when one should switch directories, or perhaps which directory one should be in when executing a specific command.
in any event, thanks for your help, I think I am now up and running, 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.
participants (11)
-
alvinpenner
-
Bryce Harrington
-
Eduard Braun
-
Felipe Sanches
-
Gord Caswell
-
Krzysztof Kosiński
-
Maren Hachmann
-
Martin Owens
-
Mattia Rizzolo
-
Terry Brown
-
Tobias Ellinghaus