felipec / git-reintegrate Goto Github PK

git-reintegrates commits all changes when merging, and this possibly includes spurious submodule changes.

Cases where this happens includes:

• switch to integration branch from another branch which has different submodule commits
• merging branches which do introduce submodule changes

Hi there, thanks a lot for sharing this tool!

I'm wondering if you (or anyone) are able to give details on how it differs from git-assembler?

I haven't looked at either in much detail yet, but on the surface it seems maybe they have somewhat similar functionality. If so, I was hoping someone could share a high-level comparison to make it easier to understand the similarities and differences. Thanks!

P.S. I wrote something similar myself (look for git-mixdown and git-mix under https://github.com/aspiers/git-config) but they were fairly ugly and poorly documented hacks so I never actively promoted them to other people.

The following test case shows the issue. Note that the commit_file function has been updated to be able to create files in a directory.

commit_file() {
    local filename="$1"
    local dirname="$(dirname $filename)"
    test -d $dirname || mkdir -p $dirname
    echo "$2" > $filename &&
    git add -f $filename &&
    git commit -q -m "commit $filename"
}

write_script .git/EDITOR <<\EOF &&
#!/bin/sh
cat > "$1" <<EOM
base master
merge branch1
merge branch2
merge branch3
merge branch4
EOM
EOF

test_expect_success 'invoking from new subfolder should not fail' '
    git checkout -b branch4 master &&
    commit_file dir4/branch4 branch4 &&
    GIT_EDITOR=.git/EDITOR git reintegrate --edit pu &&
    git reintegrate --rebuild pu &&
    git checkout branch4 &&
    cd dir4 &&
    git reintegrate --rebuild pu
'

What should the solution look like? Should

• git-reintegrate cds into the working dir's root before integrating. But, should it try to return to the directory it was in? What happens when it does not exist in the integrated commit?
• git- reintegrate should not proceed unless invoked from the working dir's root.

It is not clear how to dispose of an integration branch created via git reintegrate --create.

Simply deleting the head branch is not enough, and provokes errors such as:

fatal: ambiguous argument 'refs/heads/integration': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
fatal: no such branch: integration

Ideally a new option git reintegrate --delete would be added, that can take care of deleting all branches and any other objects related to an integration branch.

I have been playing with "git reintegrate", and really like, it, but I run into one snag: My EDITOR variable contains a command with arguments, i.e. not just "foo" but rather "foo --param". This has worked fine for me so far (and works e.g. with git commit and rebase -i), but git reintegrate chokes on it.

I can work around this by putting the whole editor command into a shell script and then let EDITOR point at that script. But it would of course be nicer if "git reintegrate" would just grok it as it is. Or, barring that, at least print a more helpful error message than fatal: ;-)

reintegration.autocontinue does not seem to be honored by fixups:

(redacted for local paths)

$ git reintegrate --continue
* Merging branch multiclient...
* Fixing up with fixups/<ref>
Auto-merging <file>
CONFLICT (content): Merge conflict in <file>
error: could not apply 2e5ae1b... fixup! Merge branch 'multiclient' into experimental
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
Resolved '<file>' using previous resolution.
failed to fixup

Once you have resolved this, run:

  git reintegrate --continue

NOTE: Any changes to the instruction sheet will not be saved.