Differences between revisions 2 and 8 (spanning 6 versions)
Revision 2 as of 2020-02-25 14:31:09
Size: 1643
Editor: JendrikSeipp
Comment:
Revision 8 as of 2020-06-30 09:26:31
Size: 2983
Editor: JendrikSeipp
Comment: reflect Zoom discussion
Deletions are marked like this. Additions are marked like this.
Line 8: Line 8:
 * we want to use branches for issues as with Mercurial (TODO: is there a precise workflow we follow, e.g., from the slides Gabi showed us? Or the git project we looked at?)  * we want to use branches for issues and basically follow our previous Mercurial workflow, i.e., have one feature branch for each issue
Line 11: Line 11:
 * to identify commits on a branch, we prepend "issue999: " to all commits of the branch issue999  * to identify commits on a branch, we prepend "[issue999] " to all commits of the branch issue999
Line 13: Line 13:
   * [Jendrik] I'd prefer "[issue999] Fix bug" over "issue999: Fix bug".    * We want to use the "[main] " prefix for commits to the main branch.
 * We want to use GitHub's autolink feature to link from commit messages to the issue tracker (https://help.github.com/en/github/writing-on-github/autolinked-references-and-urls).
Line 15: Line 16:
TODO: add infos on how to do something like git bisect with --first-parent etc. (Malte sent a few links) Best practices:
 * TODO: git bisect with --first-parent etc. (Malte sent a few links)
 * TODO: how to configure git + meld
 * TODO: can we use github's facilities on the webpage for, e.g., merging pull requests or does this do "wrong" things?
Line 17: Line 21:
TODO: github workflow: can we use their features, such as for merging pull request of extern collaborators, if that ever happens?

TODO: old suggestion for workflow, needs to be adapted according to above discussion:
 * git branch issue999
 * git checkout issue999
 * git commit --allow-empty -m "start branch issue999"
Suggested workflow:
 * git checkout -b issue999
Line 29: Line 29:
 * ...
 * git checkout master
 * git merge --no-ff issue999
 * git branch -d issue999
 * git push

.gitconfig file:
{{{
[merge]
tool = meld

[mergetool "meld"]
#cmd = meld "$LOCAL" "$BASE" "$REMOTE" --output "$MERGED"
cmd = meld "$LOCAL" "$MERGED" "$REMOTE" --output "$MERGED"

[diff]
tool = meld

[difftool "meld"]
cmd = meld "$LOCAL" "$REMOTE"

[difftool]
prompt = false

[alias]
ci = commit
st = status
meld = difftool

# aliases that match the hg in / out commands
out = !git fetch && git log FETCH_HEAD..
in = !git fetch && git log ..FETCH_HEAD
}}}
 * [Silvan] I also found out that meld actually knows about hg/git, so instead of configuring above and typing hg meld/git meld, one could also just type meld .
 * [Silvan] Unfortunately, I haven't found a way for git merge to automatically open meld instead of first doing an incomplete merge and then viewing the failed merge via hg mergetool, which, if configured as above to take $MERGED as the middle file, contains the failed merge in the >>>> ... <<<< ... format, which I really don't like. If anyone finds out how to let git automatically merge what it can and then immediately prompt the user via mergetool instead of requiring this to be called manually, and even better, without showing the failed merge, I would be very happy.

Back to developer page.

Git

Our Git workflow (work in progress)

Outcome of the discussion in the Fast Downward meeting on 21 February:

Best practices:

  • TODO: git bisect with --first-parent etc. (Malte sent a few links)
  • TODO: how to configure git + meld
  • TODO: can we use github's facilities on the webpage for, e.g., merging pull requests or does this do "wrong" things?

Suggested workflow:

  • git checkout -b issue999
  • ...
  • git commit -m "some changes"
  • ...
  • git tag -a issue999-base -m "add tag issue999-base" <rev>

  • git tag -a issue999-v1 -m "add tag issue999-v1" <rev>

  • git push --set-upstream origin issue999 --tags
  • ...
  • git checkout master
  • git merge --no-ff issue999
  • git branch -d issue999
  • git push

.gitconfig file:

[merge]
tool = meld

[mergetool "meld"]
#cmd = meld "$LOCAL" "$BASE" "$REMOTE" --output "$MERGED"
cmd = meld "$LOCAL" "$MERGED" "$REMOTE" --output "$MERGED"

[diff]
tool = meld

[difftool "meld"]
cmd = meld "$LOCAL" "$REMOTE"

[difftool]
prompt = false

[alias]
ci = commit
st = status
meld = difftool

# aliases that match the hg in / out commands
out = !git fetch && git log FETCH_HEAD..
in = !git fetch && git log ..FETCH_HEAD
  • [Silvan] I also found out that meld actually knows about hg/git, so instead of configuring above and typing hg meld/git meld, one could also just type meld .
  • [Silvan] Unfortunately, I haven't found a way for git merge to automatically open meld instead of first doing an incomplete merge and then viewing the failed merge via hg mergetool, which, if configured as above to take $MERGED as the middle file, contains the failed merge in the >>>> ... <<<< ... format, which I really don't like. If anyone finds out how to let git automatically merge what it can and then immediately prompt the user via mergetool instead of requiring this to be called manually, and even better, without showing the failed merge, I would be very happy.

FastDownward: ForDevelopers/Git (last edited 2023-02-14 15:29:06 by SilvanSievers)