Once you rebase you simply move the branch pointer to a new chain of
commits (they're rewritten because of the rebase, and thus have different
hashes), however the old version of the branch still exists in the reflog.
So locally you can definitely see your previous versions of your 'commit
stack' by just pointing the branch pointer to the old commit hash or
checking out that commit hash directly. However as far as I'm aware neither
GitHub and gitlab expose this in their UI.
On Fri, Nov 2, 2018, 09:59 Herbert Valerio Riedel On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: What about the wiki? Can we migrate that off Trac too? I worry that it's a lot of work to migrate it away while preserving the
special markup and features that Trac provides; so the resulting pages
will require a significant amount of manual cleanup and finding ways to
emulate the previous features; for instance, I've been using features
like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow
to highlight important information and footnote-like annotations in; and
thus IMO help contribute to present the information less
wall-of-text-ish which is harder to digest. [...] I suppose we can do a squash-merge when committing to keep the history
clean, but then contributors have a choice - either do GitHub-style
where you add commits to a PR to update it and we squash on merge, OR
Phabricator-style where you keep the same set of commits and rebase
the stack to update it. (Minor nitpick: in GitLab there are no pull-requests (PRs) anymore;
they're called "MRs" for "merge-request", which is probably a more
accurate term to describe the concept than "PR" is) Well, if MRs are to be squashed on merge anyway, I'm definitely not
going to waste my time carefully grooming a stack of atomic individually
validating commits via git-rebase-interactive... If you want to do dependent commits then you have to use Phabricator
style. Choices between workflows make things more complicated for
contributors, and that worries me. ...submitting a stacked set of commits as invidual overlapping MRs
(i.e. where the first MR has only the first commit, the 2nd has the
first two commits from the stack, and so on) -- if that's what you're
referring to as "Phabricator-style" -- sounds like an awkward workflow
to me. Does GitLab keep the history of a PR after it has been updated, like in
Phabricator? So we can see what happened between versions of a PR? I wonder too how this is represented in GitLab... especially when a MR
is comprised of multiple commits, and those individual commits evolve,
might get reordered, commits added or removed fromt he stack, or when
the whole MR gets rebased in the process...
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs