Jagan: On Fri, Mar 14, 2014 at 12:39 PM, Jagan Teki <jagannadh.t...@gmail.com> wrote: > Hi,
Hello, > I have two branch in one repo that I need to maintain for 2 different > deliveries. > Say branch1 and branch2 in test.git repo. > > test.git > - branch1 > foo_v1/text.txt > foo_v2/text.txt > - branch2 > foo/text.txt > > branch1 is developers branch all source looks version'ed manner and > branch2 is superset for branch1, example foo_v1 and foo_v2 are the directories > in branch1 where developer will update the latest one here foo_v2 and branch2 > foo is same as the latest one of branch1 for an instance. > > Suppose developer send 10 patches on branch1 where are changes in terms > of <dir>_<version>/ then I need to apply on my local repo branch1, till now > is fine then I need to apply same 10 patches on to my branch2 where source > tree <dir> which is quite question here how can I do. > > Request for any help! let me know for any questions. This just sounds like a painful workflow to me. I would suggest not doing this at all, but rather using tags to mark specific releases, and using individual branches for continued development (e.g., stable or v1.x or whatever is most appropriate). You can have unstable or master or dev or whatever for developers to work on freely without breaking releases (albeit, there are many different workflows you can use to manage the transition from unstable to stable code). I would avoid using subtrees (subdirectories) within a Git repository to represent different releases of the code. Git already tracks versions. That is redundant and messy. It's really an outdated way of thinking about version control. /my 2 cents Regards, -- Brandon McCaig <bamcc...@gmail.com> <bamcc...@castopulence.org> Castopulence Software <https://www.castopulence.org/> Blog <http://www.bamccaig.com/> perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }. q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.}; tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say' -- 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
