# suggestion? only pull cleanly applying commits

2 messages from 2008-11-26 to 2008-11-26. Participants: Maximilian Mehnert, Andreas Ericsson.
Thread: https://gitlist.dev/t/16474

## Maximilian Mehnert, 2008-11-26 11:48

Subject: suggestion? only pull cleanly applying commits
Message-ID: <492D37A2.4010500@googlemail.com>
URL: https://gitlist.dev/e/492D37A2.4010500%40googlemail.com

```
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

```

## Andreas Ericsson, 2008-11-26 13:30

Subject: Re: suggestion? only pull cleanly applying commits
Message-ID: <492D4F8E.10002@op5.se>
URL: https://gitlist.dev/e/492D4F8E.10002%40op5.se
In-Reply-To: <492D37A2.4010500@googlemail.com>

```
Maximilian Mehnert wrote:
> 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
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

```