Re: [lldb-dev] [llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits

[Jameson Nash via lldb-dev]

> The way it decides that there are "outdated comments" and that those
comments should be hard to does not win it any points in my book (Hubert
Tong)

IIUC, Github has recently changed this, and is now more like Phabricator.
(in that it now seems to add a mark to say the diff is likely outdated, but
has a separate "Resolve Conversation" button). That said, this might bring
up a different incentive for staying with Phabricator, which is that Github
can and does make minor changes to their PR workflow over time, while LLVM
would retain more control over their Phabricator instance.


> Full disclosure: "Revert" commits also wreak havoc on "git bisect" and
"git blame"

As an outsider, I'm not sure I fully understand the comments about `git
bisect` (and blame) not being able to deal with merge and revert commits.
Having worked mostly on the JuliaLang project (which does not discourage
merge commits), we've not typically had much difficulty with either. The
bisect tool is intelligent about being able to isolate which branch of the
graph introduced (or fixed) the behavior of interest, and can isolate
within that branch which commit first show the change. The presence of a
revert commit can be a minor speed-bump (especially if it means the build
previously failed), but "wreak havoc" seems like a bit of hyperbole for
needing to call git blame again—and doesn't seem much different from how
svn would necessarily handle the same situation?

One point that may be worth mentioning though is that merge commits are
also themselves unrestricted changes(*), which can be an interesting gotcha
(it's hard to represent this diff). So if merges are allowed in the
timeline, LLVM may additionally decide whether to permit human-assisted
merges, or to ask that developers rebase the branch first in that case.
(*In git, each commit is a record of the state of all contents of the repo,
plus one or more parent links to the previous state. A merge commit is
distinct only in that it has multiple parents that are indicated as
contributing in some way to the final state, but they aren't otherwise
restricted in what gets changed.)

There is however a philosophic difference of various git coding styles that
LLVM can chose. One school of thought suggests that you should never rebase
code, and instead frequently merge branches in all directions. This gives
the advantage that a `git bisect` attempt will be considering the code as
originally written, and so the result of `git bisect` or `blame` may be
more likely to tell whether a later discovered issue (or other archeology
reason) arose from an issue with the original commit, or arose as a result
of a conflict with a simultaneous change.

A counter school of thought instead argues for preserving a simpler (or in
the limit, a linear) ordering of all commits. I won't say as much about
this, since I think the benefits of this are already obvious to a community
that already requires it.

I also won't say that one school is better or worse than the other (I
happen to use a hybrid in most of my projects). There are also other
approaches to commit management I haven't mentioned, but I wanted to at
least share some thoughts, in the hopes that someone might find the
information useful.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] GitHub anyone?

[Jameson Nash via lldb-dev]

For the JuliaLang project, we started with git-submodules for building some
of our loosly-coupled external dependencies, but eventually moved to a
custom-built solution (we call it "git-externals") to overcome some of the
workflow limitations. I haven't yet run across a similar suggestion
elsewhere as a replacement for git-submodules (although it's perhaps an
expansion on "Simply require multiple clones + tooling for bisect"), so I
thought I would suggest it for consideration too. As the author of this
code, I may be a bit biased, but I think it takes a slightly different
approach to understanding the problem: it approaches the question as being
part of the domain of the build system (of ensuring a reproducible and
automated build, as controlled by the committer) rather than being the
domain of the source-management system (of describing a reproducible
checkout, but controlled by the user). Our implementation is an inscrutable
`make` script, but really only consists of a couple lines, as I'll describe
later.

For other similar prior art, I consider package management like the Rust
Cargo lock file (http://doc.crates.io/guide.html#cargotoml-vs-cargolock) to
be a roughly equivalent concept for approaching the problem from the other
direction (as build-dependency version-management, as opposed to
considering alternative implementations of git-submodules).

As others have mentioned, one of the issues JuliaLang was encountering with
git-submodules was that the basic git commands (such as pull and bisect)
don't natively consider submodules and require extra flags to ensure
everything in sync. Our initial solution for this was to call `git
submodule update --init` as part of calling `make`. This seemed to work
much better for the casual user at keeping the build "just working" with
minimal git experience.

The second limitation we encountered was that the submodule state is not
available as a normal file in the repo. This meant that packaging the repo
required more work than simply `tar cjf` and the download link
auto-generated by Github (
https://github.com/JuliaLang/julia/archive/master.zip) was unable to build.

Our solution was to have the build system (`make` in our case) be fully
responsible for managing the state of the external dependencies, instead of
involving `git submodule` at all. Now we can store the dependency
information as a regular makefile (for an example, see
https://github.com/JuliaLang/julia/blob/master/deps/utf8proc.version). The
build system would include this `$(EXT).version` file, then inspect the
resulting variables `$(EXT)_SHA1` and `$(EXT)_BRANCH` to pick the right
commit (`git fetch $(EXT)_BRANCH && git checkout $(EXT)_SHA1`). The trigger
for this checkout is the relative timestamp of `$(EXT).version` vs.
`$(EXT)/.git/HEAD`; this (heuristically) allows the user to make edits to
the sub-repo without triggering the checkout code, but ensures that a
checkout of the updated version will be triggered whenever the
`$(EXT).version` file is modified, such as by pull or bisect in the parent
repo.

-Jameson

On Thu, Jun 2, 2016 at 2:29 PM via llvm-dev  wrote:

> Renato Golin via cfe-dev  writes:
>
> I'd like to generate and add to your notes a list of submodule
> alternatives so we can explore options.  Here's a start.  Not all of
> these are equally good IMHO.
>
> - Creating one big repository
> - Simply require multiple clones + tooling for bisect
> - git-subtree (with to-be-contributed enhancements)
> - Google repo
>
> -David
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev