check merge failure on Trac

[Reimundo Heluani]

Hello, I am not familiar with the Trac server, I have a branch based on
9.2.beta2 locally that fails the automerge on trac. I suppose something
changed between 9.2.beta2 and 9.2.beta10. Is there any way of seeing the logs
to check what are the conflicts on the Trac server instead of trying to merge in my
local copy? this is my working copy of Sage and I would not want to trigger
recompilation of a bunch of packages that I've changed.

R.

[Dima Pasechnik]

your best bet is to git fetch the current development branch and
locally do a git diff against it.
Trac git server is pretty basic, there are no GitHub/GitLab-like
features for online diffs.

HTH
Dima

>
> R.
>
> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/20200828113913.GA3893914%40vertex.

[Reimundo Heluani]

Thanks, I guess recompilation is unavoidable then, the worst part is that it was one of my own tickets :)

R.

>To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq1RXqSB%3Dqq5_kF9_OLmh815%2B1LhkZcNPFxCeXpp4u-BuA%40mail.gmail.com.

[Dima Pasechnik]

On Fri, Aug 28, 2020 at 1:23 PM 'Reimundo Heluani' via sage-devel
<sage-...@googlegroups.com> wrote:
>
> Thanks, I guess recompilation is unavoidable then, the worst part is that it was one of my own tickets :)

well, why, just doing git diff against another branch does not touch
your current tree.
But, well, you are better off closely following the current beta.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/20200828122340.GA39916%40rye.

[Michael Orlitzky]

On 2020-08-28 08:23, 'Reimundo Heluani' via sage-devel wrote:
> Thanks, I guess recompilation is unavoidable then, the worst part is that it was one of my own tickets :)
>

Dima meant "git fetch" literally. That will pull down the changes, but
won't try to merge them into your local branch (like "git pull" would).

[Reimundo Heluani]

yeah but looking at a diff would be impossible to find conflicts with such a
large patch. The only way I know of is attempting a merge, and if there are
conflicts this always results in changing the working tree.

R

>--
>You received this message because you are subscribed to the Google Groups "sage-devel" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

>To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/0364d6e6-1d82-537e-694c-afe8fa7d05ea%40orlitzky.com.

[Reimundo Heluani]

On Aug 28, Dima Pasechnik wrote:
>On Fri, Aug 28, 2020 at 1:23 PM 'Reimundo Heluani' via sage-devel
><sage-...@googlegroups.com> wrote:
>>
>> Thanks, I guess recompilation is unavoidable then, the worst part is that it was one of my own tickets :)
>
>well, why, just doing git diff against another branch does not touch
>your current tree.
>But, well, you are better off closely following the current beta.
>>

I didn't pull, just fetch and tried the merge against FETCH_HEAD

R

>To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0v5dutrpCeQgtsUmrzkY6ie%2BM1QqbNkONNxCeExOTAcQ%40mail.gmail.com.

[Michael Orlitzky]

On 2020-08-28 08:40, 'Reimundo Heluani' via sage-devel wrote:
> On Aug 28, Michael Orlitzky wrote:
>> On 2020-08-28 08:23, 'Reimundo Heluani' via sage-devel wrote:
>>> Thanks, I guess recompilation is unavoidable then, the worst part is that it was one of my own tickets :)
>>>
>>
>> Dima meant "git fetch" literally. That will pull down the changes, but
>> won't try to merge them into your local branch (like "git pull" would).
>>
> yeah but looking at a diff would be impossible to find conflicts with such a
> large patch. The only way I know of is attempting a merge, and if there are
> conflicts this always results in changing the working tree.

You can try creating a patch with `git format-patch`, and then applying
it with `git apply --check`.

I have a branch of the ClamAV project right now that conflicts with
upstream, so I'm using that as my example. First I have to find the
latest common ancestor of my branch and the upstream one,

$ git merge-base HEAD upstream/dev/0.103
854d38de546a53e3c27b90965b8d89804acfdf02

Now if I format-patch that against the upstream branch, I get...

$ git format-patch 854d38de546..upstream/dev/0.103
0000-cover-letter.patch
0001-Add-newlines-at-end-of-sources-to-satisfy-strict-war.patch
0002-Update-acknowledgements-in-the-NEWS.patch
0003-Remove-v-typo-from-unit-test-source.patch
0004-bb12596-Fix-build-issue-when-libcheck-missing.patch
0005-Add-autogen.sh-to-Autotools-dist.patch
0006-Autotools-freshclam-remove-BUILD_CLAMD-macro.patch
0007-CMake-Fix-libclamav-pcre2-include-path-issue.patch
0008-clam-d-scan-win32-fix-RO-directory-remove-bug.patch
0009-Autotools-Add-pkg-config-support-for-finding-pcre2.patch
0010-Update-acknowledgements-in-the-NEWS.patch

And one of those should fail to apply:

$ git apply --check 0001*.patch
$ git apply --check 0002*.patch
$ git apply --check 0003*.patch
$ git apply --check 0004*.patch
$ git apply --check 0005*.patch
$ git apply --check 0006*.patch
error: patch failed: clamav-milter/Makefile.am:36
error: clamav-milter/Makefile.am: patch does not apply
error: patch failed: clamd/Makefile.am:46
error: clamd/Makefile.am: patch does not apply
error: patch failed: etc/Makefile.am:23
error: etc/Makefile.am: patch does not apply

That last one is responsible for the conflict, and `git status` shows
that my local tree hasn't been changed (aside from the new patch files).

[Reimundo Heluani]

This is very good to know thanks, I'll try this. But I think in general the problem that I want to avoid would not be seen by simply a git status. Since

$git checkout develop
$git checkout mybranch

Will trigger recompilation because of the timestamp changes. And git status would show everything clean. If the format patch check does not change timestamps that's exactly what I was looking for. Thanks

R
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Dima Pasechnik]

why would you need to checkout develop?

> $git checkout mybranch

Anyhow, ticker reviewers will want a branch as close to trac/develop
as possible, for many reasons.

>
> Will trigger recompilation because of the timestamp changes. And git status would show everything clean. If the format patch check does not change timestamps that's exactly what I was looking for. Thanks

only checkouts/merges/rebases change timestamps (on the files that get
changed, not on all the files).
So this is a kind of necessary evil.

>
> R
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/E91F7307-E2B3-47AC-815C-729B0BDA51C3%40potuz.net.

[Travis Scrimshaw]

I normally do

$ git checkout -b local_branch develop

$ git pull trac branch_on_trac

This will add a merge commit, but it will allow you to do the diff and not recompile.

Best,

Travis

> To unsubscribe from this group and stop receiving emails from it, send an email to sage-...@googlegroups.com.

[Markus Wageringel]

Another option is to use git worktree to create a second copy of the source tree in the repository.

$ git worktree add my_worktree

$ cd my_worktree/

$ ln -s ../upstream/ .

This creates a subdirectory with a copy of all source files, where one can merge the branches without touching the main tree. The last command is useful in case one decides to build a second copy of sage in the subdirectory.