Hi all,

This is a complicated question to try and ask, let alone answer, so I had best 
give some background.

I have two repositories --- one of them, which I'll call "repoA", is the main 
repository, it's the one which most of the code we develop ends up.  The other 
repository, "repoB" is our portable version of the code---the one which is used 
to deploy on systems other than the one which repoA is deployed on.  As such, 
"repoB" often (and does) contain commits specific to repoB which will never 
appear in repoA, such as OS-specific things.

In this case, in repoA we have a man page.  Up until recently, this used to be 
the same file in both repositories.  But because of the way the files in repoB 
are deployed, unlike in repoA this file has had its name changed from:

foo.1 -> foo.1.in

Because the man page is run through some sed script to replace various things 
which never need to happen in repoA

Now, as you might guess, foo.1 in repoA doesn't change.  When I merge in 
changes from repoA to repoB, there is no way for the repositories to know that 
repoA:foo.1 is really repoB:foo.1.in -- which means a new file is created every 
time.

I appreciate I could just rename foo.1.in back to foo.1 in repoB, but this 
would cause some ambiguity with users who try to run the file through "man", 
because the tradition of .in files is well-understood.

So short of renaming the file in repoB back to foo.1, my question is this:  
when merging repoA to repoB, can I somehow map the file contents from foo.1 to 
be foo.1.in in repoB?

Kindly,

Jason
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to