Opened 6 years ago

Closed 6 years ago

#22451 closed enhancement (fixed)

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

Reported by: Daniel Krenn 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 6 years ago by Daniel Krenn

Branch: u/dkrenn/t/22451

comment:2 Changed 6 years ago by Daniel Krenn

Authors: Daniel Krenn
Commit: 956c0d028ff4742c5217d532d0d2ad202dd8d99f
Status: newneeds_review

New commits:

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

comment:3 Changed 6 years ago by Luca De Feo

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 Changed 6 years ago by Paul Masson

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 Changed 6 years ago by Andrey Novoseltsev

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 6 years ago by git

Commit: 956c0d028ff4742c5217d532d0d2ad202dd8d99f6095e908045a1e34ee808469c0509af8c010a844

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 6 years ago by Daniel Krenn

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 6 years ago by Daniel Krenn

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 6 years ago by Daniel Krenn

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 Changed 6 years ago by Matthias Köppe

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 6 years ago by git

Commit: 6095e908045a1e34ee808469c0509af8c010a844a08f20c016f6e7c8002fc4597fa77ba254eb6f41

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

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

comment:12 Changed 6 years ago by git

Commit: a08f20c016f6e7c8002fc4597fa77ba254eb6f415a30f8358285a29dd97cd5c57dc6bf9a5a37eee6

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 6 years ago by Daniel Krenn

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 Changed 6 years ago by Matthias Köppe

typo "persue"

comment:15 Changed 6 years ago by git

Commit: 5a30f8358285a29dd97cd5c57dc6bf9a5a37eee6c42dd1ab176c43af397717158cc9b5fc7a46753a

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

c42dd1aTrac #22451 review: typo "persue"

comment:16 in reply to:  14 Changed 6 years ago by Daniel Krenn

Replying to mkoeppe:

typo "persue"

Corrected. Thanks.

comment:17 Changed 6 years ago by Matthias Köppe

Reviewers: Matthias Koeppe
Status: needs_reviewpositive_review

comment:18 Changed 6 years ago by Volker Braun

Branch: u/dkrenn/t/22451c42dd1ab176c43af397717158cc9b5fc7a46753a
Resolution: fixed
Status: positive_reviewclosed
Note: See TracTickets for help on using tickets.