Skip to contentSkip to conversation

suggestion? only pull cleanly applying commits

DISCUSSION Maximilian Mehnert 2 participants 2 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

Hi!

I've a scenario where I don't really want to do a full merge but rather to pull all commits from another repository that merge without conflicts.

I've put together the script at the bottom which seems to work ok but is damn slow.

Is there a smarter and faster way to do this that I missed reading the documentation?

Any help would be really appreciated! :-)

Regards,
Maximilian

#!/bin/sh

for commit in git rev-list --reverse HEAD..other-repository/master; do
git diff-tree -p $commit|patch --dry-run -p1 -N -f >/dev/null if [ $? -eq 0 ]; then
echo "getting $commit"
parents=git rev-list --parents -n1 $commit|wc -w if [ $parents -eq 2 ]; then
git cherry-pick $commit
else
git cherry-pick -m1 $commit
fi
fi
done

#1 lore raw
Quoted 19 lines · Maximilian Mehnert

Hi!

I've a scenario where I don't really want to do a full merge but rather to pull all commits from another repository that merge without conflicts.

I've put together the script at the bottom which seems to work ok but is damn slow.

Is there a smarter and faster way to do this that I missed reading the documentation?

Any help would be really appreciated! :-)

Regards,
Maximilian

#!/bin/sh

Quoted 13 lines

for commit in git rev-list --reverse HEAD..other-repository/master; do
git diff-tree -p $commit|patch --dry-run -p1 -N -f >/dev/null if [ $? -eq 0 ]; then
echo "getting $commit"
parents=git rev-list --parents -n1 $commit|wc -w if [ $parents -eq 2 ]; then
git cherry-pick $commit
else
git cherry-pick -m1 $commit
fi
fi
done

The fact that you're cherry-picking the commits means you create new ones, constantly. It's very, very, very bad practice to do from a script with commits you're getting from somewhere else. Git can (and will) handle it properly come merge-day, but your history will be a stinking pile of horse-manure if you keep it up for very long.

There are more important questions, however.

1. Why do you have to merge so often? Merging is something that should not be undertaken lightly, and you shouldn't do it "just to stay up to date".
2. Why can't you just merge (resolving conflicts as they appear) when you're done with what you're working on?

Remember that "conflict-free" means totally different things depending on which way you're looking at it. Upstream could rename a function that you're using, and it would merge without *textual* conflicts, but your stuff would be totally broken afterwards. Such design-scope conflicts can only be protected from with testing. Git will not handle them for you.

Signature · 3 lines
Andreas Ericsson                   [email protected]
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231