From: Andreas Ericsson <ae@op5.se>
To: Maximilian Mehnert <maximilian.mehnert@googlemail.com>
Cc: git@vger.kernel.org
Subject: Re: suggestion? only pull cleanly applying commits
Date: Wed, 26 Nov 2008 14:30:54 +0100 [thread overview]
Message-ID: <492D4F8E.10002@op5.se> (raw)
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
prev parent reply other threads:[~2008-11-26 13:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 11:48 suggestion? only pull cleanly applying commits Maximilian Mehnert
2008-11-26 13:30 ` Andreas Ericsson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=492D4F8E.10002@op5.se \
--to=ae@op5.se \
--cc=git@vger.kernel.org \
--cc=maximilian.mehnert@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).