We are now using GIT

[MarkMLl]

OK, but it's not possible to find out from the IDE whether a particular patch etc. has been applied?

MarkMLl

[Martin_fr]

OK, but it's not possible to find out from the IDE whether a particular patch etc. has been applied?

No, but it wasn't before.

Say you knew a patch was applied in svn 55123 and the IDE was at 55500, then you still had to check that 55123 was on the same svn branch (fixes or trunk) as the IDE build on 55500.

Now you know the sha1 (and the branch, derived from the tag). You then have to check the git log, same as with svn.

Of course if you know the patch was applied at
   main-2_3-106-.....
And you know you current main is not on a diverged part of main, then you know if it is in or not.

[dsiders]

OK, but it's not possible to find out from the IDE whether a particular patch etc. has been applied?

MarkMLl

For any given git question, you'll get 100+ ways to do any given thing. Here's what I use:

There is a commit that fixes some QT issues.

Code: Bash  [Select][+][-]

1. 52f2a8b88f Qt,Qt5: Fixed menu radio items. issue #37741

It has been applied to main, but not fixes_2_2. I use the git command lines:

Code: Bash  [Select][+][-]

1. git  log --oneline origin/main | grep 52f2a8b88f
2. git  log --oneline origin/fixes_2_2 | grep 52f2a8b88f

That'll show a result in main, and no result in fixes_2_2.

YMMV.

[MarkMLl]

That'll show a result in main, and no result in fixes_2_2.

YMMV.

But I'm not asking about the repository, I'm asking about the IDE.

MarkMLl

[Martin_fr]

Code: Bash  [Select][+][-]

1. git  log --oneline origin/main | grep 52f2a8b88f
2. git  log --oneline origin/fixes_2_2 | grep 52f2a8b88f

That'll show a result in main, and no result in fixes_2_2.

@Dsiders: While you did not put it as a question, I add some more answer anyway (not reaching 100+ though):

Code: Text  [Select][+][-]

1.  git log -1 "main^{/issue #37741}"
2.  git log -1 "fixes_2_2^{/issue #37741}"

or If you know its a commit in main (check with)

Code: Text  [Select][+][-]

1.  git branch --contains 52f2a8b88f --all

Then you can search fixes (assuming there is a "cherry picked" notice

Code: Text  [Select][+][-]

1.  git log -1 fixes_2_2^{/52f2a8b88f}

or you could check, if an unmodified merge (no conflict / same patch) exists

Code: Text  [Select][+][-]

1. git cherry fixes_2_2   52f2a8b88f 52f2a8b88f~1

52f2a8b88f is in main, the result will either be +52f2a8b88f or -52f2a8b88f => where "-" means it is merged. ("+" still avail for merging)
But that does not work if there was a conflict, or if the merge for some other reason was modified.

[dsiders]

@Dsiders: While you did not put it as a question, I add some more answer anyway (not reaching 100+ though):
...
 does not work if there was a conflict, or if the merge for some other reason was modified.

Thank you @Martin_fr. I'll add some of these to my cheat sheet.

[prof7bit]

From my "main" build:

Code: Text  [Select][+][-]

1. Lazarus 2.3.0 rmain-2_3-306-gbbe0b81f62 FPC 3.2.0 x86_64-win64-win32/win64

That is "git desclibe"

306 commits since the tag main-2_3 on commit bbe0b81f62

The 306 is not always "exact". In case of branches (within main) it could be on either side. After a merge it counts both sides.

If git describe is called with

Code: Pascal  [Select][+][-]

1. --first-parent

then it will not search along merge branches.

The output of git describe is a "commit-ish", that is it can be used to specify a revision in any of the commands that expect a hash, a tag, a branch name, it can be checked out, reverted or or cherry-picked or anything else you can do with a commit.

[prof7bit]

That'll show a result in main, and no result in fixes_2_2.

YMMV.

But I'm not asking about the repository, I'm asking about the IDE.

For this to work the compiled IDE would need to have the entire git log compiled into it, that would currently be 61115 entries in the main branch as of today.

[Martin_fr]

From my "main" build:

Code: Text  [Select][+][-]

1. Lazarus 2.3.0 rmain-2_3-306-gbbe0b81f62 FPC 3.2.0 x86_64-win64-win32/win64

That is "git desclibe"

306 commits since the tag main-2_3 on commit bbe0b81f62

The 306 is not always "exact". In case of branches (within main) it could be on either side. After a merge it counts both sides.

If git describe is called with

Code: Pascal  [Select][+][-]

1. --first-parent

then it will not search along merge branches.

Yes, but the "306" is still not "exact" => as in: you can recompute the commit from the 306.

The 306 is in both cases "exact" as in reproducible.

If I have commits on main as follows:

Code: Text  [Select][+][-]

1. main-2_3 => C1 => C2 => C3 => C4=> M => C5
2.                \> M1 => M2        =^
3.  

Then with or without first-parent:
- if I am on C2 I get: main-2_3-  2  -gC2
- if I am on M2 I get: main-2_3-  2  -gM2
In both cases, I am 2 commits after the tag.

However if I am on C5 then first-parent makes a diff
- with first-parent: main-2_3-  6  -gC5
- without first-parent: main-2_3-  8  -gC5

Both is correct, as long as you know which setting was used.

Neither contains any info if a reference to
  main-2_3-123-gxxxxx
is on the official repo,
or an un-merged branch on a fork.

[Martin_fr]

For this to work the compiled IDE would need to have the entire git log compiled into it, that would currently be 61115 entries in the main branch as of today.

I had to look it up the original question was

OK, but it's not possible to find out from the IDE whether a particular patch etc. has been applied?

And I said before

No, but it wasn't before.

Say you knew a patch was applied in svn 55123 and the IDE was at 55500, then you still had to check that 55123 was on the same svn branch (fixes or trunk) as the IDE build on 55500.

So the revision info in the IDE dialog has at no point in time (with the exception before the first fixes branch in svn was created) given any info about a particular fix/patch being included or not.


Mind that I have seen examples where fixes/patches were first committed to the fixes branch, and then merged to main.
While I am not aware of any "fix being forgotten to be merged to main", that could happen, and therefore even in svn, if you were on a higher revision than that of the fix, you might not have the fix at all.

[prof7bit]

If I have commits on main as follows:

Code: Text  [Select][+][-]

1. main-2_3 => C1 => C2 => C3 => C4=> M => C5
2.                \> M1 => M2        =^
3.  

However if I am on C5 then first-parent makes a diff
- with first-parent: main-2_3-  6  -gC5
- without first-parent: main-2_3-  8  -gC5

Edit: Ignore the next sentence, I just put my glasses on and noticed the symbol that indicates the merge.

Are you sure? I would expect it to output 6 in both cases.

First parent is for constellations where a side branch was merged back INTO the current branch, for example a merge request was merged into main. In that case first-parent would ignore everything on the side branch and follow only the branch it was merged INTO, in this case the main branch.

If you place tags on strategic places you can get pretty descriptive output from git describe. And if I see this correctly then the Lazarus devs have placed tags at the beginnings of (important) branches exactly for that purpose.

In your example if you place a tag called "feature_foo" on M1 to indicate that here you branched for the new foo feature and call git describe on M2 it would print "feature_foo-1-gM2".

If you then merge it back into the upper branch and use --first-parent then it would ignore that tag, even if it is much closer than "main-2_3".

Edit2: I keep writing "label" when I really mean "tag", I don't know what causes this even after 5 years of using git.

[Martin_fr]

Well, yes. first parent may have some advantages.
Need to see, if that should be changed.

And in case, if all the scripts could be updated in time.
tools/installer/* contain scripts, duplicating svn2revisioninc.