Skip to content

Commit 70a55be

Browse files
committed
rn-35: add svn to git article
1 parent f9be265 commit 70a55be

File tree

1 file changed

+71
-2
lines changed

1 file changed

+71
-2
lines changed

rev_news/drafts/edition-35.md

Lines changed: 71 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -25,9 +25,78 @@ This edition covers what happened during the month of December 2017.
2525
### Reviews
2626
-->
2727

28-
<!---
2928
### Support
30-
-->
29+
30+
* [Need help migrating workflow from svn to git](https://public-inbox.org/git/[email protected]/)
31+
32+
Josef Wolf first described is current workflow that uses Subversion
33+
(SVN).
34+
35+
Josef has a number of machines that all have a working copy of the
36+
same repository in a specific directory. A cron job updates the
37+
working copies and then run scripts contained in the working copies.
38+
39+
When using `svn updates` to update those copies, the changes made
40+
locally on the machines are automatically merged with the upstream
41+
changes usually without conflict.
42+
43+
Then Josef explained what would happen with Git:
44+
45+
> With git, by contrast, this won't work. Git will refuse to pull
46+
> anything as long as there are ANY local modifications. The cron job
47+
> would need to
48+
>
49+
> git stash
50+
> git pull
51+
> git stash pop
52+
>
53+
> But this will temporarily remove my local modifications. If I happen
54+
> to do a test run at this time, the test run would NOT contain the
55+
> local modifications which I was about to test.
56+
57+
Randall S. Becker suggested using `git fetch` instead of `git pull` to
58+
be able to first tell if changes from upstream have to be applied to
59+
the local copy, and also using a branch for each machine to better
60+
track local changes and merge them with upstream changes.
61+
62+
Josef replied to Randall by asking for a way to "properly check
63+
whether a merge is actually needed" as it looks like `git status` or
64+
`git diff` are not very well suited for that purpose.
65+
66+
Igor Djordjevic, alias Buga, wondered about the possibility, in the
67+
original workflow, of running scripts that are being worked on. Buga
68+
also said that using `git stash` would probably have other issues, so
69+
he suggested the "(scripted) creation of a temporary branch at fetched
70+
remote branch position, and using something like
71+
`git checkout --merge <temp_branch>` to merge ... local modifications
72+
to latest changes fetched from remote".
73+
74+
In a later email Buga alternatively suggested "using
75+
`git worktree add <temp_copy_path>` to create a temporary working tree
76+
... alongside a temporary branch" and deleting those after having
77+
commited, merged and pushed the local changes made there.
78+
79+
Josef replied to Buga that some potential issues Buga worried about
80+
are not relevant when using SVN because of the specifics of his work,
81+
while others are indeed relevant when using Git.
82+
83+
About the solutions Buga had suggested, Josef and Buga started to
84+
discuss them, but at this point Junio Hamano, the Git maintainer,
85+
suggested using just:
86+
87+
> git fetch <remote> <branch>
88+
> git checkout -m -B <master> FETCH_HEAD
89+
90+
with:
91+
92+
> <remote> <branch>: the branch at the remote you are pulling from
93+
> <master>: whatever branch you are using
94+
95+
After some tests and further discussion, Josef agreed that it was a
96+
good solution. Buga also suggested using `git add -u` and `git reset`
97+
after or before the above commands to avoid failures in case the
98+
script runs many times and there are conflicts.
99+
31100

32101
<!---
33102
## Developer Spotlight:

0 commit comments

Comments
 (0)