16 Feb
2017
16 Feb
'17
1:32 a.m.
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)
<gigaherz(a)gmail.com> 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 <ionucu(a)videotron.ca> wrote:
On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
<drakekaizer666(a)gmail.com> wrote:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
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 
16 Feb
16 Feb
2:45 a.m.
New subject: Microsoft switched to Git
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 <ionucu(a)videotron.ca> 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)
<gigaherz(a)gmail.com> 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 <ionucu(a)videotron.ca> wrote:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
<drakekaizer666(a)gmail.com> wrote:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
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 
7:45 a.m.
New subject: Microsoft switched to Git
That... isnt actually true? I have used repos that spans more than a couple
of thousands commits, spanning several years back?
Den 16 feb. 2017 3:46 fm skrev "Zachary Gorden"
<drakekaizer666(a)gmail.com>om>:
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 <ionucu(a)videotron.ca> 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)
<gigaherz(a)gmail.com> wrote:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
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 <ionucu(a)videotron.ca> wrote:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
<drakekaizer666(a)gmail.com> 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
8:02 a.m.
New subject: Microsoft switched to Git
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 <drakekaizer666(a)gmail.com>
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 <ionucu(a)videotron.ca> 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)
<gigaherz(a)gmail.com> wrote:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
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 <ionucu(a)videotron.ca> wrote:
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden
<drakekaizer666(a)gmail.com> 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
8:37 a.m.
New subject: Microsoft switched to Git
Am 16.02.2017 um 03:45 schrieb Zachary Gorden:
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.
To give a picture of what he is talking about:
http://fs5.directupload.net/images/170216/tfchxvni.png
(random example repo on GitHub)
You see how parallel streams of history emerge with every new committer
when just using git commit, git pull and git push. Commits in the list
are not even in chronological order anymore.
Now what is the least painful way to avoid these automatic merges?
We don't want to make life harder for any Git user..
- Colin
8:43 a.m.
New subject: Microsoft switched to Git
You can change one config entry and you can forget about merging strategy:
|git config --globalpull.rebase true |
||You just have to force everyone to using it. Then simple git pull
automatically rebases. We use it in work for all projects and history is
linear.
||
W dniu 16.02.2017 o 09:37, Colin Finck pisze:
Am 16.02.2017 um 03:45 schrieb Zachary Gorden:
---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe
Avast.
https://www.avast.com/antivirus
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.
To give a picture of
what he is talking about:
http://fs5.directupload.net/images/170216/tfchxvni.png
(random example repo on GitHub)
You see how parallel streams of history emerge with every new committer
when just using git commit, git pull and git push. Commits in the list
are not even in chronological order anymore.
Now what is the least painful way to avoid these automatic merges?
We don't want to make life harder for any Git user..
- Colin
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
9 a.m.
New subject: Microsoft switched to Git
Note that rebasing will mean you then later have to force-push into your
work branches. And yes, work branches only, please. I strongly recommend
against force-pushing to master. Or or pushing to master without a PR,
either way.
On 16 February 2017 at 09:43, Rafał Harabień <rafalh(a)reactos.org> wrote:
You can change one config entry and you can forget
about merging strategy:
git config --global pull.rebase true
You just have to force everyone to using it. Then simple git pull
automatically rebases. We use it in work for all projects and history is
linear.
W dniu 16.02.2017 o 09:37, Colin Finck pisze:
Am 16.02.2017 um 03:45 schrieb Zachary Gorden:
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.
To give a picture of what he is talking about:
http://fs5.directupload.net/images/170216/tfchxvni.png
(random example repo on GitHub)
You see how parallel streams of history emerge with every new committer
when just using git commit, git pull and git push. Commits in the list
are not even in chronological order anymore.
Now what is the least painful way to avoid these automatic merges?
We don't want to make life harder for any Git user..
- Colin
_______________________________________________
Ros-dev mailing listRos-dev@reactos.orghttp://www.reactos.org/mailman/listinfo/ros-dev
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
Wolny
od wirusów. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient>
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
2772
days inactive
2772
days old
6 comments
6 participants
participants (6)
-
Alex Ionescu -
Colin Finck -
David Quintana (gigaherz) -
Magnus Johnsson -
Rafał Harabień -
Zachary Gorden