Opened 5 years ago

Closed 5 years ago

#22451 closed enhancement (fixed)

developer guide: Explain merging in new SageMath version without triggering many recompilations

Reported by: dkrenn Owned by:
Priority: major Milestone: sage-7.6
Component: documentation Keywords:
Cc: Merged in:
Authors: Daniel Krenn Reviewers: Matthias Koeppe
Report Upstream: N/A Work issues:
Branch: c42dd1a (Commits, GitHub, GitLab) Commit: c42dd1ab176c43af397717158cc9b5fc7a46753a
Dependencies: Stopgaps:

Status badges

Description

Write a section in Advanced Git of the developer guide

Change History (18)

comment:1 Changed 5 years ago by dkrenn

  • Branch set to u/dkrenn/t/22451

comment:2 Changed 5 years ago by dkrenn

  • Authors set to Daniel Krenn
  • Commit set to 956c0d028ff4742c5217d532d0d2ad202dd8d99f
  • Status changed from new to needs_review

New commits:

95d12b6advanced git: write section on merging new SageMath version
b13d5c5rewrite intro
956c0d0changes after proof reading

comment:3 follow-up: Changed 5 years ago by defeo

Being on some new SageMath (e.g. on branch develop) which runs successfully, it would be possible to merge in our branch some/code into develop. This would produce the same source files and avoid unnecessary recompilations. However, it destroys git's history. Thus, for example, it is hard to keep track of changes etc., as one cannot simply persue the first parent of each git commit.

Isn't "destroys" a bit of an overstatement?

comment:4 follow-up: Changed 5 years ago by paulmasson

We first create a new working tree in a directory merge and switch to this directory::

I find it a bit confusing to have a directory with the same name as a command. How about using new_copy for the directory name instead of merge?

Also, having a branch name with slashes looks to me like a subfolder in the branch. How about calling it some_code instead of some/code?

comment:5 follow-up: Changed 5 years ago by novoselt

This is quite convoluted for a non-initiate... Would be nice to have some

 git trac upgrade_to_latest old_branch

command or similar.

comment:6 Changed 5 years ago by git

  • Commit changed from 956c0d028ff4742c5217d532d0d2ad202dd8d99f to 6095e908045a1e34ee808469c0509af8c010a844

Branch pushed to git repo; I updated commit sha1. New commits:

a89b972Trac #22541 review: rename branch to some_code
4e61be0Trac #22541 review: rename sub directory to new_worktree
6095e90Trac #22541 review: rephrase "destroy history"

comment:7 in reply to: ↑ 3 Changed 5 years ago by dkrenn

Replying to defeo:

Being on some new SageMath (e.g. on branch develop) which runs successfully, it would be possible to merge in our branch some/code into develop. This would produce the same source files and avoid unnecessary recompilations. However, it destroys git's history. Thus, for example, it is hard to keep track of changes etc., as one cannot simply persue the first parent of each git commit.

Isn't "destroys" a bit of an overstatement?

Fair enough; rewritten.

comment:8 in reply to: ↑ 4 Changed 5 years ago by dkrenn

Replying to paulmasson:

We first create a new working tree in a directory merge and switch to this directory::

I find it a bit confusing to have a directory with the same name as a command. How about using new_copy for the directory name instead of merge?

Changed, but to "new_worktree", as I find "new_copy" ambiguous.

Also, having a branch name with slashes looks to me like a subfolder in the branch. How about calling it some_code instead of some/code?

Changed.

comment:9 in reply to: ↑ 5 Changed 5 years ago by dkrenn

Replying to novoselt:

This is quite convoluted for a non-initiate... Would be nice to have some

 git trac upgrade_to_latest old_branch

command or similar.

Propose this to

https://github.com/sagemath/git-trac-command

comment:10 follow-up: Changed 5 years ago by mkoeppe

The trick with the worktree is quite useful, +1 on including it. But shouldn't it also show instructions on how to get rid of the worktree after this is done?

comment:11 Changed 5 years ago by git

  • Commit changed from 6095e908045a1e34ee808469c0509af8c010a844 to a08f20c016f6e7c8002fc4597fa77ba254eb6f41

Branch pushed to git repo; I updated commit sha1. New commits:

11beb3aTrac #22541 review: explain removing worktree
a08f20cTrac #22541: typo with ::

comment:12 Changed 5 years ago by git

  • Commit changed from a08f20c016f6e7c8002fc4597fa77ba254eb6f41 to 5a30f8358285a29dd97cd5c57dc6bf9a5a37eee6

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

06e55ffTrac #22451 review: explain removing worktree
5a30f83Trac #22451: typo with ::

comment:13 in reply to: ↑ 10 Changed 5 years ago by dkrenn

Replying to mkoeppe:

The trick with the worktree is quite useful, +1 on including it. But shouldn't it also show instructions on how to get rid of the worktree after this is done?

Yes; added instructions for this.

comment:14 follow-up: Changed 5 years ago by mkoeppe

typo "persue"

comment:15 Changed 5 years ago by git

  • Commit changed from 5a30f8358285a29dd97cd5c57dc6bf9a5a37eee6 to c42dd1ab176c43af397717158cc9b5fc7a46753a

Branch pushed to git repo; I updated commit sha1. New commits:

c42dd1aTrac #22451 review: typo "persue"

comment:16 in reply to: ↑ 14 Changed 5 years ago by dkrenn

Replying to mkoeppe:

typo "persue"

Corrected. Thanks.

comment:17 Changed 5 years ago by mkoeppe

  • Reviewers set to Matthias Koeppe
  • Status changed from needs_review to positive_review

comment:18 Changed 5 years ago by vbraun

  • Branch changed from u/dkrenn/t/22451 to c42dd1ab176c43af397717158cc9b5fc7a46753a
  • Resolution set to fixed
  • Status changed from positive_review to closed
Note: See TracTickets for help on using tickets.