git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Volkmar Glauche <volkmar.glauche@uniklinik-freiburg.de>
To: git@vger.kernel.org
Subject: subtree merge strategy - merge upstream branches that share history
Date: Thu, 11 Jul 2013 12:35:39 +0200	[thread overview]
Message-ID: <20130711123539.kya5rtfpc4gs08w4@webmail1.uniklinik-freiburg.de> (raw)

[-- Attachment #1: Type: text/plain, Size: 2240 bytes --]

Dear list,

I would like to set up a repository that has multiple branches from a  
upstream project merged at different paths. Also, I would like to be  
able to access upstream history in my project (it is interpreted code,  
and I would like to git-blame to display a mix of local and upstream  
history line-by-line in the code).
I have documented the steps to demonstrate my desired repository  
layout in the attached shell script snippet. It is self-contained and  
sets up two repositories upstream and main-repo in /tmp. It then reads  
two branches featureA and featureB from upstream into separate paths  
in main-repo.
Then, the script modifies contents in the upstream repository. There  
are modifications that apply to both featureA and featureB as well as  
modifications to one branch only.
Up to this point, things seemed to work well using either git-subtree  
or a combination of git-read-tree and "subtree" merge strategy.
Finally, the changes to upstream are to be pulled into the  
corresponding paths in main-repo. Here, neither git-subtree nor git  
pull with subtree merge do what I want. The changes that apply to one  
of the features only are applied correctly. However, changes from the  
common history of featureA and featureB are only applied to the path  
that is updated first.
Apparently, git records that the common change has been applied and  
doesn't apply it a second time (which is correct for ~99.9999999% of  
all use cases). In this special case however, git does not take into  
account that it applied the common change to a different path.
I found that git pull --squash would apply the right set of updates to  
both featureA and featureB in main-repo (i.e. in this case, the common  
change would be applied on each path). However, this would leave me  
unlinked to upstream history.
Now:
1) Am I doing something completely wrong, am I missing some important detail?
2) Am I asking for something impossible?
3) Is it expected behaviour, that --squash adds a different set of  
text changes than a pull without squash?

Best,

Volkmar




-- 
Freiburg Brain Imaging
http://fbi.uniklinik-freiburg.de/
Tel. +761 270-54783
Fax. +761 270-54819


[-- Attachment #2: upstream-example.sh --]
[-- Type: application/x-shellscript, Size: 2780 bytes --]

                 reply	other threads:[~2013-07-11 10:44 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130711123539.kya5rtfpc4gs08w4@webmail1.uniklinik-freiburg.de \
    --to=volkmar.glauche@uniklinik-freiburg.de \
    --cc=git@vger.kernel.org \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).