@@ -25,9 +25,78 @@ This edition covers what happened during the month of December 2017.
25
25
### Reviews
26
26
-->
27
27
28
- <!-- -
29
28
### 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
+
31
100
32
101
<!-- -
33
102
## Developer Spotlight:
0 commit comments