On Mon, Apr 28, 2014 at 2:32 PM, Adrien Nader <[email protected]> wrote:
> On Mon, Apr 28, 2014, Jon wrote:
> > On Mon, Apr 28, 2014 at 10:03 AM, LRN <[email protected]> wrote:
> >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > On 28.04.2014 17:04, JonY wrote:
> > > > On 4/28/2014 19:53, Ruben Van Boxem wrote:
> > > >> Different repositories may sound like a nice idea, but keeping them
> in
> > > >> sync can be a pain, depending on the complexity of the subprojects.
> I
> > > >> believe stuff like ironcrate, winpthreads and perhaps the
> > > >> mingw-w64-tools folder deserve their own repo, as they are very
> seperate
> > > >> from the headers+crt. These latter two I'd suggest to keep
> together, as
> > > >> that will reduce the chances of wrong versions being used together
> and
> > > >> allow 1 commit to change both to keep them aligned without any
> hassle.
> > > >> In contrast, I would try to move away from a seperate "experimental"
> > > >> directory, and instead inject these changes into a branch (or
> several,
> > > >> so that each finished feature can be merged easily). Branches and
> > > >> merging are the git way, and rebasing allows for clean merges.
> > > >>
> > > >
> > > > For ease of migration, every module in trunk would go into the same
> repo,
> > > > so that would include winpthreads and mingw-w64-tools. I'm not sure
> if we
> > > > can "exclude" files from the import unless we want to completely
> break
> > > > apart trunk into components. However, I am also trying to avoid too
> many
> > > > separate repos and git submodules.
> > > >
> > > > Right now, I am thinking of splitting it 3 ways, the mingw-w64 proper
> > > > (with anything from experimental if applicable), web, and
> experimental
> > > (if
> > > > it actually justifies a separate repo, otherwise, it might be
> archived
> > > and
> > > > left as is on SVN).
> > >
> > > My experience so far:
> > > 1) When i build gcc, i often need to build mingw-w64-headers,
> mingw-w64-crt
> > > and winpthreads not together, but separately, at different points of
> time.
> > > To
> > > this end i'm svn-checkouting from a subdirectory to get only one of the
> > > three.
> > > I don't remember whether git has that ability; possibly not. If that
> is the
> > > case, these may need to go into separate repos (possibly submodules?).
> > >
> > > 2) The git branches are for "branching out" from the main development
> line
> > > (and merging back at some later point), not for completely separate
> stuff.
> > > If
> > > you keep completely different stuff in different branches, switching
> > > branches
> > > (which usually takes less than a second) will take a long time
> (depending
> > > on
> > > the size, up to 10 seconds or more). The svn "branches" are more like
> git
> > > "repos" - completely independent, they just "live together" :)
> > >
> > >
> > While you're investigating different git repo structures, I highly
> suggest
> > you investigate git's lightly documented "orphan" branches. These allow
> > multiple disparate branches to exist in a single repo. They allow you to
> > create "blank slate" style branches based upon a very early initial
> commit.
> > They work quite different than the merge friendly git branches you
> > typically see documented. You can still cherrypick from other branches if
> > needed.
> >
> > https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html
> >
> > For example, say you want winpthreads on it's own branch that doesn't
> > contain winpthreads unrelated commits. Create the orphan branch similar
> to
> >
> > # <start_point> is an initial commit that typically includes only your
> > `.gitattributes` and `.gitignore` files. Consider
> > # <start_point> to be the "primordial" branch commit.
> > git checkout --orphan winpthreads <start_point>
> >
> > # discover that the primordial branch commit <start_point> is already
> > staged; commit it
> > # as the winpthreads branch initial commit
> > git commit -m "Initial commit; project attributes and ignores"
> >
> > # add all the winpthreads specific code to this otherwise
> > git commit -am "Add winpthreads source"
> >
> > # tag the commit with a well-known tag (IIRC, these types of tags are
> > isolated to a single branch so you
> > # likely want some namespacing)
> > git tag winpthreads-0.5.1
> >
> > # what have I just done?
> > git log --decorate --oneline
> >
> > # make it so
> > git push && git push --tags
>
> Aren't they a bit difficult to manipulate and error-prone (accidental
> merges or data exchange between branches)? At least that's my feeling.
>
>
I don't see how using orphan branches are any more error-prone than any
other type of branch. That said, since stand-alone orphan branches likely
are not used as much as feature branches, perhaps this could be a valid
concern. Try creating a clean history orphan branch and play with it. I
think you find it useful for certain scenarios. It's an easy way to emulate
a repo-within-a-repo type structure without too many mental hijinks.
Regarding per-file (emulated) attributes, check out
https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html While
EOL and binary file issues are easily solved, I'm not sure how mime type
issues are best solved, if at all, with gitattributes.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
