New subject: Microsoft switched to Git

16 Feb 2017

I too have no idea where this "history limit" comes into play. I work on
and have repos spaning 50-100 developers working on dozens of thousands of
branches over two dozen repos with almost 8 years of history. Some people
rebase, but most people don't.
It is extremely easy to have a clean history due to the fact we enforce the
"[COMPONENT] Description" commit message (and can use a git hook to make
sure it looks this way). It is then trivial to write a script that only
looks for those commits. Heck you can even auto-squash/rebase anything that
doesn't match.
That being said, that type of "dirty history" only happens if you heavily
work with branches. That's not how reactos developers work -- we don't open
PRs and separate branches for every checkin.
These ALL sound like manufactured problems or poor/strange use of git.
On Thu, Feb 16, 2017 at 12:02 AM David Quintana (gigaherz) <
gigaherz(a)gmail.com&gt; wrote:
...
  If git has an upper limit on history, it's the
first time I hear about it,
 and it would be an issue I was simply not aware of. So far as I was aware,
 git just keeps a parent hash on each commit, and the GC just deletes
 commits without any reference. In fact, we use Git at my current job, and
 the history goes back many years, and it seems perfectly capable of
 tracking it. And no, we don't rebase or squash, ever. We are not allowed to
 do any operation that changes commit history. So it's quite a mess of merge
 commits, but even then it's manageable.
 I disagree on needing a single person responsible for merges. The the PR
 workflow we have at my current job is that the developer submits a PR for
 review, and adds to the PR two other developers, who have to approve the
 changes or request fixes. Once it's approved, the original developer can
 click the merge button themselves. For external PRs done by contributors,
 then one of the reviewers is the responsible for clicking the merge button.
 And even if you do choose to require a commit-master, with the way
 github's merge button works, you can choose to have a merge commit, or to
 squash & rebase implicitly, and the history ends up with one single commit
 attributed to all the developers that were involved in the merge. As an
 example, I have a hobby writing Minecraft mods, and they use Forge to work:
 https://github.com/MinecraftForge/MinecraftForge/commits/1.11.x -- you'll
 see many "<someone> commited with LexManos". That's because
there's an
 author, and a commiter, in the git info.
 I do agree, git history can get messy, and ugly, and hard to track -- if
 you abuse merge commits. I, unlike Alex, am a fan of manual rebases, and
 leaving a clean history before you submit the changes for review. But I
 understand that constantly rewriting history means you end up with a
 fabricated history at the end. So the policy choices should probably either
 be no merges at all, or no rebasing at all. But that's where "git blame"
 comes in. With a proper tool, you can see exactly who changed a file, and
 when, and you can use it to track back the history of that file, or that
 specific line of code.
 On 16 February 2017 at 03:45, Zachary Gorden &lt;drakekaizer666(a)gmail.com&gt;
 wrote:
 I've used both git and svn in work environments. If all you do is git pull
 and git push, you end up with lots of noise in the commit log with git
 tracking every single merge because you don't rebase. Combined with the
 fact that git has an upper limit on how much history it can track and the
 solution literally being to purge history, I'm not exactly sure why all of
 you are so enthused about it. Unless the team wants to adopt having a
 single person being responsible for all commits going into the canonical
 master repo to avoid all of the problems with how git tracks history, the
 commit log is going to be next to useless for actual tracking of history.
 If you don't care about the commit history, then sure, go ahead, but I
 personally would like to be able to easily track changes back cleanly. We
 get that basically for free with svn right now. With git, the usage
 patterns that those of you pushing for git are promoting actively works
 against keeping a clean history.
 On Wed, Feb 15, 2017 at 7:32 PM, Alex Ionescu &lt;ionucu(a)videotron.ca&gt; wrote:
 Sure, I didn't count git add because you can do it with git commit -a.
 git status/log are the same as the svn equivalents. just like git
 diff/svn diff. I was mainly referring to regular workflow.
 In fact, I think outside of stash (which is an optional, but awesome,
 feature) fetch and rebase (which I refuse to learn), all commands map
 1:1 with svn. That's why I don't get this whole "it takes way more
 commands/steps in git".
 git commit -a -m "[BOOTLIB] Fix yet another bug]"
 git push
 Done.
 Best regards,
 Alex Ionescu
 On Wed, Feb 15, 2017 at 3:48 PM, David Quintana (gigaherz)
 &lt;gigaherz(a)gmail.com&gt; wrote:
  My command set is a bit more extended:
 git clone -- similar to svn checkout into a new folder
 git checkout -- for changing the current branch
 git pull -- effectively the same as "svn update", xcept it gets the 
entire
  change history, not just the latest commit data
 git push [--force] -- for sending changes into the repository
 git fetch -- downloads stuff but doesn't apply it to the checkout copy
 git merge -- can be used to merge the remote data (in which case it's  like
  svn update), or to merge from another branch
 git branch
 git add
 git commit
 git stash save/pop -- can be used to temporarily undo some changes, and  be
  able to recover them afterward
 git status, git log, ... -- for getting info about the state of the
 repository and the uncommited changes
 ... and more I that I use less often
 I do agree that it is a bit annoying that git has so much trouble pulling
 with local changes, and that is the one area where svn just simply works
 better. In every other aspect, I have come to like the "git way" more.
 That said, I avoid commandline git as much as possible. I prefer to use
 TortoiseGit (in Windows, at home), or SourceTree (at work, where I use a
 mac, and SourceTree is probably the least shitty frontend for git).
 I like to say, that for someone who knows Subversion, learning git  starts by
  realizing that all the usual svn concepts, apply
to git, just NOT with  the
  remote repository. The svn-like commands work
with the local repository
 clone, and then it has a separate command set for interacting with  remotes.
  Of course it's not a 1:1 match, but it's
a good starting point. If you  are
  able to "catch" that, then learning how
to work with git becomes a LOT
 easier.
 On 16 February 2017 at 00:31, Alex Ionescu &lt;ionucu(a)videotron.ca&gt; wrote:

 On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
 &lt;drakekaizer666(a)gmail.com&gt; wrote:
  Why is there a need for anything beyond "git
commit" or "git push" or
 "git
 pull" to do anything? 
 Good question. I've never used any other git command other than those
 (except git checkout). Oh, that's lie, I've also used "git branch",
 just like on svn, to create a branch.
 Sounds like you've never actually used git? I've never rebased in my
 life, and I don't know what other commands even exist.
 Best regards,
 Alex Ionescu
 _______________________________________________
 Ros-dev mailing list
 Ros-dev(a)reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev 
 _______________________________________________
 Ros-dev mailing list
 Ros-dev(a)reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev

 _______________________________________________
 Ros-dev mailing list
 Ros-dev(a)reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev
 _______________________________________________
 Ros-dev mailing list
 Ros-dev(a)reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev
 _______________________________________________
 Ros-dev mailing list
 Ros-dev(a)reactos.org
 http://www.reactos.org/mailman/listinfo/ros-dev
 --
Best regards,
Alex Ionescu

Re: [ros-dev] Microsoft switched to Git