Re: git workflow for D
On Wednesday, December 06, 2017 04:56:17 Arun Chandrasekaran via Digitalmars-d-learn wrote: > Looks like Mercurial is going to be rewritten in Rust > https://www.mercurial-scm.org/wiki/OxidationPlan > > So Facebook don't use D? As I understand it, the main languages at Facebook are C++ and PHP, but they use a variety of languages depending on who's doing the work and what part of Facebook they're in. Some of them were using D while Andrei was working there. I don't know if they're using it now or not. But even if some of them are still using D, others could be using Rust or whatever took their fancy and their bosses let them use. IIRC, some of the Facebook guys in London were even using Haskell. - Jonathan M Davis
Re: git workflow for D
On Monday, 4 December 2017 at 01:26:45 UTC, Arun Chandrasekaran wrote: On Sunday, 3 December 2017 at 23:39:49 UTC, Basile B. wrote: [...] If you still lose changes, you could try using Mercurial with hggit. It can be a bit slow, but not destructive as git itself. ;) I really wish Mercurial won instead of git. Now that hg evolve and hg topic are stable, that actually alleviates the need for git. But the world talks git now. So everyone else is forced to talk in git :( I guess, without StackOverflow and GitHub, no one would be using git. Facebook uses Mercurial and their team is working on a Mercurial server in Rust. https://github.com/facebookexperimental/mononoke I thought Facebook uses DLang as well. No one's motivated to write one in DLang? Looks like Mercurial is going to be rewritten in Rust https://www.mercurial-scm.org/wiki/OxidationPlan So Facebook don't use D?
Re: git workflow for D
On Mon, Dec 04, 2017 at 12:02:37PM -0800, Ali Çehreli via Digitalmars-d-learn wrote: [...] > Paraphrasing someone I trust very much, "Never 'pull', always 'fetch > -p' and then rebase." I always use `git pull --ff-only`. Lets me pull when it's "safe", aborts if it will end up in a mess (i.e., tell me when I've made a boo-boo and committed to master). Usually, I only make changes in a local branch, so it's just a matter of rebasing the local branch afterwards. T -- Right now I'm having amnesia and deja vu at the same time. I think I've forgotten this before.
Re: git workflow for D
On Mon, Dec 04, 2017 at 06:51:42AM -0500, Nick Sabalausky (Abscissa) via
Digitalmars-d-learn wrote:
> On 12/03/2017 03:05 PM, bitwise wrote:
> > I've finally started learning git, due to our team expanding beyond
> > one person - awesome, right?
>
> PROTIP: Version control systems (no matter whether you use git,
> subversion, or whatever), are VERY helpful on single-person projects,
> too! Highly recommended! (Or even any time you have a directory tree
> where you might want to enable undo/redo/magic-time-machine on!)
+100! (and by '!' I mean 'factorial'. :-P)
I've been using version control for all my personal projects, and I
cannot tell you how many times it has saved me from my own stupidity
(i.e., have to rollback a whole bunch of changes, or just plain ole
consult an older version of the code that I've forgotten). Esp. with
git, it also lets me play with experimental code changes without ever
worrying that if things don't work out I might have to revert everything
by hand (not fun! and very error-prone).
In fact, I use version control for more than just code: *anything*
that's text-based is highly recommended to be put under version control
if you're doing any serious amount of editing with it, because it's just
such a life-saver. Of course, git works with binaries too, but diffing
and such become a lot easier if everything is text-based. This is why I
always prefer text-based file formats when it comes to authoring.
Websites are a good example that really ought to be under version
control. Git, especially, lets you clone the website to a testing
server where you can experiment with changes without fear, and once
you're happy with the changes, commit and push to the "real" web server.
Notice an embarrassing mistake that isn't easy to fix? No problem, just
git checkout HEAD^, and that buys you the time you need to fix the
problem locally, then re-push.
I've also recently started putting certain subdirectories under /etc in
git. Another life-saver when you screw up a configuration accidentally
and need to revert to the last-known good config. Also good for
troubleshooting to see exactly what changes were made that led to the
current state of things.
tl;dr: use version control WHEREVER you can, even for personal 1-man
projects, not only for code, but for *everything* that involves a lot of
changes over time.
> > Anyways, I've got things more or less figured out, which is nice,
> > because being clueless about git is a big blocker for me trying to
> > do any real work on dmd/phobos/druntime. As far as working on a
> > single master branch works, I can commit, rebase, merge, squash,
> > push, reset, etc, like the best of em.
>
> Congrats! Like Arun mentioned, git's CLI can be a royal mess. I've
> heard it be compared to driving a car by crawling under the hood and
> pulling on wires - and I agree.
>
> But it's VERY helpful stuff to know, and the closer you get to
> understanding it inside and out, the better off you are. (And I admit,
> I still have a long ways to go myself.)
Here's the thing: in order to use git effectively, you have to forget
all the traditional notions of version control. Yes, git does use many
of the common VC terminology, and, on the surface, does work in similar
ways.
BUT.
You will never be able to avoid problems and unexpected behaviours
unless you forget all the traditional VC notions, and begin to think in
terms of GRAPHS. Because that's what git is: a system for managing a
graph. To be precise, a directed acyclic graph (DAG).
Roughly speaking, a git repo is just a graph (a DAG) of commits,
objects, and refs. Objects are the stuff you're tracking, like files
and stuff. Commits are sets of files (objects) that are considered to
be part of a changeset. Refs are just pointers to certain nodes in the
graph.
A git 'branch' is nothing but a pointer to some node in the DAG. In git,
a 'branch' in the traditional sense is not a first-class entity; what
git calls a "branch" is nothing but a node pointer. The traditional
"branch" is merely a particular configuration of nodes in the DAG that
has no special significance to git.
Git maintains a notion of the 'current branch', i.e., which pointer will
serve as the location where new nodes will be added to the DAG. By
default, this is the 'master' branch (i.e., a pointer named 'master'
pointing to some node in the DAG).
When you run `git commit`, what you're doing is creating a new node in
the DAG, with the parent pointer set to the current branch pointer. So
if the current branch is 'master', and it's pointing to the node with
SHA hash 012345, then `git commit` will create a new node with its
parent pointer set to 012345. After this node is added to the graph,
the current pointer, 'master', is updated to point to the new node.
By performing a series of `git commit`s, what you end up with is a
linear chain of nodes, with the current branch ('master') pointing to
the last node. This, we traditionally view as a
Re: git workflow for D
On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote:
{snip} If anyone can offer any kind of advice, or an article
that explains these things concisely and effectively, that
would be helpful.
I found some git-specific info in this wiki page:
Re: git workflow for D
On 12/4/17 3:14 PM, Ali Çehreli wrote:
Dear git experts, given 3 repos, now what are the steps? Is the
following correct? What are the exact commands?
Disclaimer: I'm not a git expert.
- Only once, create the original repo as an upstream of your local repo.
The wording is off (s/repo/remote), but yes. This one I always have to
look up, because I don't remember the order of the URL vs. the name, and
git doesn't care if you swap them. But the command is this:
git remote add upstream
Where url is the https version of dlang's repository (IMPORTANT: for
dlang members, do NOT use the ssh version, as then you can accidentally
push to it without any confirmation).
- For each change:
1) Fetch from upstream
git fetch upstream
will fetch EVERYTHING, all branches. But just for reference so you can
use it without affecting your local repo.
2) Rebase origin/master (on upstream, right?)
No, don't do this every time! If you never commit to your local master
(which you shouldn't), you do it this way:
# This checks out your local master branch
git checkout master
# This moves your local master branch along to match that of master.
# The --ff-only is to ensure it only works if the merge is a fast-forward.
# A fast forward merge happens when your master is on the same commit
# history as the upstream master.
git merge --ff-only upstream/master
Optionally you can push your local master to origin, but it's not
strictly necessary:
git push origin master
3) Make changes
Step 2.1: checkout a local branch. You can even do this after you have
changed some files but *before* you have committed them (IMO one of the
best features of git as compared to, say, subversion).
# creates a new branch called mylocalfix based on local master, and
checks it out.
git checkout -b mylocalfix
4) Commit (potentially after 'add')
Protip: git commit -a automatically adds any modified files that are
currently in the repo, but have been changed.
5) Repeat steps 3 and 4 as needed
Correct!
6) 'git push -force' so that your GitHub repo is up-to-date right?
(There, I mentioned "force". :) )
I'd say:
git push origin mylocalfix
This pushes *only* your mylocalfix branch to *your* fork of the repo.
No need to force as long as you do not want to squash. Squashing is when
you merge multiple commits into one commit so that the history looks
cleaner. I'd recommend never using force (btw, it's --force with 2
dashes) unless it complains. And then, make sure you aren't doing
something foolish before using the --force command! Because you are
committing only to your fork, and to your branch, even if you mess up
here, it's pretty easy to recover.
A couple of examples:
1. You commit, but missed a space between "if" and "(". Instead of
generating a commit and log for the typo, you just squash the new commit
into the first one.
2. You commit a work in progress, but then change the design. The first
commit is useless in the history, as it probably doesn't even apply
anymore, so you squash them together, as if you only ever committed the
correct version.
To squash the last few commits, I recommend using rebase -i:
# Replace 3 with the number of the last few commits you want to work with.
# IMPORTANT: this must contain the commit you want to squash into!
git rebase -i HEAD~3
This will pop up an editor. Follow the instructions listed there! If you
want to squash 2 commits together, use "fixup", or even just "f". Note:
do NOT "fixup" your first commit, as this will try to squash into
someone else's commit that happened before you changed anything!
Once you write the file and exit, git will rebase using your directions.
At this point you need to use --force to push (as long as you have
already pushed before), as your commit history now differs from github's.
7) Go to GitHub and press the big button to create a pull request
Correct! After you do this, you can continue to run steps 3, 4, 6 to
update your PR.
One further step that I like to do to keep my repo clean:
8) When your PR is pulled:
git fetch upstream
git checkout master
git merge --ff-only upstream/master
git branch -d mylocalfix
This pulls the new changes that were successfully merged into dlang's
master into your master. Then it deletes the mylocalfix branch (no
longer needed). The lower case -d means to only delete if the changes
have been merged (git will complain if they aren't in the history). This
is a nice way to clean your local branches up, and verify there isn't
anything amiss.
Note also, if you want to work on several fixes at once, you can
checkout more than one local branch, and switch between them. Just
remember to commit before you checkout the different branches (git will
complain if you have uncommitted files, but not files that haven't ever
been added).
Hope this all helps!
-Steve
Re: git workflow for D
I'm going to answer with something that others may not agree with, maybe they can enlighten me, but let me first get a generic principle of git and answer some questions. Git has 2 types of branches, local branches (you know them as just branches) and remotes (which have their own local branches). I say this to remove the confusion with having an original repository, a forked repository, and a cloned repository. When it comes to interactions with these repositories the only difference from your local branches is that you can't interact directly with them (i.e. you can't commit to them) and the interactions require specifying the remote location of the branch. Some of your other questions are about GitHub and Forking. Git doesn't know what a fork is, but GitHub ties a pull request to a branch. This means you can update/change your pull request by updating/changing your branch. From that you should realize each pull request needs its own branch. Back to git remotes. I'm sure you're aware of the commonly named "origin" remote and possible the second common "upstream." When you're dealing with many remotes your local branches can get complicated. For example many people utilize 'master' as a *tracking* branch to "origin" well, "upstream" if there is one. I'm to the point that in this situation my recommendation is just delete your 'master' branch both local and "origin." Don't worry you can bring it back if you need it, you won't need it. Here is the thing, you already have two, maybe 3 master branches 'master' 'origin/master' 'upstream/master' these are local branches (they are special in that you can't commit to them). And these are also your true tracking branches, whenever you fetch/pull from your remote these branches are updated, they will always reflect the branch of the remote and they will never conflict during updates. You can always create your own master $ git branch master upstream/master I want to note that 'origin/master' is different from such commands as `$ git push origin master` because in the first you are referring to a local branch and the second you reference your remote followed by your remotes local branch (actually I could be wrong here because the full syntax is `$ git push origin master:master` where the left: is your local and :right is the remote local branch [and note that `push origin :master` would delete the remote master branch because you're push no branch to it.). I hope that this along with answers other have given will help you to answer all of your questions.
Re: git workflow for D
On Monday, 4 December 2017 at 20:14:15 UTC, Ali Çehreli wrote: 6) 'git push -force' so that your GitHub repo is up-to-date right? (There, I mentioned "force". :) ) The right option name is --force-with-lease ).
Re: git workflow for D
On Monday, December 04, 2017 12:02:37 Ali Çehreli via Digitalmars-d-learn wrote: > On 12/04/2017 09:38 AM, Patrick Schluter wrote: > > So, avoid pull, look first what fetch does and if that is what you > > thought it would do, do the merge and be happy. > > +1 > > Paraphrasing someone I trust very much, "Never 'pull', always 'fetch -p' > and then rebase." I use pull all the time, but it's always pulling master from upstream, and I never make any changes to my local master; all my changes go on branches. Using github or gitlab, I really don't have any other reason to pull or fetch, because the only place that I normally care about getting code from is upstream master. Any code being merged from someone else is merged into upstream master via github/gitlab, and my code is all done on separate branches that get pushed up to github/gitlab to be merged. With different workflows (like sharing work directly with someone rather than using github or gitlab), I could see reasons to be wary of pull, but in the typical workflow with github/gitlab, I really don't see any reason to be wary of it - not when the only time it's needed is to sync my local master with the main one on github/gitlab. - Jonathan M Davis
Re: git workflow for D
On 12/04/2017 12:14 PM, Ali Çehreli wrote: 2) Rebase origin/master (on upstream, right?) 2.5) Create a branch and do all work on that branch 3) Make changes Ali
Re: git workflow for D
On 12/03/2017 12:05 PM, bitwise wrote: > I've finally started learning git git is one of those things where as soon as you understand how it works, you lose the ability to teach. :) I'm watching this thread with amusement because like most online tutorials, nobody is mentioning the relationship of *three* repos in the picture: - The original repo, which will be updated by others frequently - Your clone of it on GitHub which will be hopelessly behind unless you update it (if I'm not mistaken, none of the replies mentioned '-force') - Your local (e.g. laptop) clone of your GitHub clone, where you do all the work Dear git experts, given 3 repos, now what are the steps? Is the following correct? What are the exact commands? - Only once, create the original repo as an upstream of your local repo. - For each change: 1) Fetch from upstream 2) Rebase origin/master (on upstream, right?) 3) Make changes 4) Commit (potentially after 'add') 5) Repeat steps 3 and 4 as needed 6) 'git push -force' so that your GitHub repo is up-to-date right? (There, I mentioned "force". :) ) 7) Go to GitHub and press the big button to create a pull request Since I still don't know how git works, :) I trust my steps above but I know the steps can use improvement. Ali
Re: git workflow for D
On 12/04/2017 09:38 AM, Patrick Schluter wrote: > So, avoid pull, look first what fetch does and if that is what you > thought it would do, do the merge and be happy. +1 Paraphrasing someone I trust very much, "Never 'pull', always 'fetch -p' and then rebase." Ali
Re: git workflow for D
On Monday, 4 December 2017 at 11:51:42 UTC, Nick Sabalausky (Abscissa) wrote: On 12/03/2017 03:05 PM, bitwise wrote: One thing to keep in mind: Any time you're talking about moving anything from one repo to another, there's exactly two basic primitives there: push and pull. Both of them are basically the same simple thing: All they're about is copying the latest new commits (or tags) from WW branch on XX repo, to YY branch on ZZ repo. All other git commands that move anything bewteen repos start out with this basic "push" or "pull" primitive. (Engh, technically "fetch" is even more of a primitive than those, but I find it more helpful to think in terms of "push/pull" for the most typical daily tasks.) No, the pair us push/fetch. pull is fetch+merge and a lot of confusion comes from that in fact. I've seen several people cursing git because of that idea that pull is the opposite of push. When I explained that they should never use git pull, but always separating fetch from the merge, it clicked every time. So, avoid pull, look first what fetch does and if that is what you thought it would do, do the merge and be happy.
Re: git workflow for D
On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote: I've finally started learning git, due to our team expanding beyond one person - awesome, right? Anyways, I've got things more or less figured out, which is nice, because being clueless about git is a big blocker for me trying to do any real work on dmd/phobos/druntime. [snip] Here's my usual workflow. 1) Fork project 2) Add upstream 3) Create a new branch 4) Make changes 5) Add/Commit to branch 6) Push I sometimes find myself getting tripped up if I need to deviate from this. Ideally, I could just make the change, push it, and it gets accepted. Sometimes though you have to make changes to what you've done and add more commits and then the master has additional updates and you may need to handle merge conflicts. I make fewer mistakes now than when I started, but I'm still nowhere near as good with it as I should be.
Re: git workflow for D
On 12/3/17 3:48 PM, Basile B. wrote: On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote: or just some specific files? and do I need a separate branch for each pull request, Yes, yes yes, again. ~master is sacrosanct. For good reason. If you commit things to your master, and they don't get merged into the mainline master, now you have a borked master, and you have to reset it. One other thing to mention, whenever I update my master from the upstream fork, I always always specify --ff-only, which means I'm only going to let you merge if both my master and the upstream master are exactly the same (i.e. my master is just an earlier version of upstream master). Even though I never *intentionally* commit to master, this is a sanity check to make sure I didn't *accidentally* do it. If you have to reset master, then I recommend reading articles. I always use this website for any git questions: https://git-scm.com/book/en/v2 Or just do a search on google. You will probably find the answers in stack-overflow. -Steve
Re: git workflow for D
On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote: How does one keep their fork up to date? For example, if I fork https://help.github.com/articles/syncing-a-fork/
Re: git workflow for D
On Monday, 4 December 2017 at 04:45:01 UTC, Patrick Schluter wrote: On Monday, 4 December 2017 at 01:54:57 UTC, ketmar wrote: Basile B. wrote: On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote: Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Who hasn't ;) me. Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch. "git reflog". nothing commited is *ever* lost until you do "git gc". Actually (and i reply to ketmar too) i've never lost commits either. What 's happened to me is that i lost non-validated stuff in the staging area b/c as you noticed otherwise it would be recoverable. Now i use "git submodule foreach git clean -f" to clean submodules.
Re: git workflow for D
On 12/03/2017 03:05 PM, bitwise wrote: I've finally started learning git, due to our team expanding beyond one person - awesome, right? PROTIP: Version control systems (no matter whether you use git, subversion, or whatever), are VERY helpful on single-person projects, too! Highly recommended! (Or even any time you have a directory tree where you might want to enable undo/redo/magic-time-machine on!) Anyways, I've got things more or less figured out, which is nice, because being clueless about git is a big blocker for me trying to do any real work on dmd/phobos/druntime. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. Congrats! Like Arun mentioned, git's CLI can be a royal mess. I've heard it be compared to driving a car by crawling under the hood and pulling on wires - and I agree. But it's VERY helpful stuff to know, and the closer you get to understanding it inside and out, the better off you are. (And I admit, I still have a long ways to go myself.) What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in. Yea. It's fundamental stuff, but it can be frustratingly convoluted for the uninitiated. TBH, I really wish we had widespread tools that cater to what have emerged as the most common best-practice workflows and the basic primitives of those workflows. I even went so far as to get started on such a tool (I call it "wit"), but it's been kind of on the back burner lately, and it's still far too embryonic for any kind of release. (I am still using a git repo for it locally though! Again, highly recommeded. At the very least, just because there's nothing worse than accidentally loosing a bunch of important code, or finding you need to undo a bunch of changes that didn't work out.) One thing to keep in mind: Any time you're talking about moving anything from one repo to another, there's exactly two basic primitives there: push and pull. Both of them are basically the same simple thing: All they're about is copying the latest new commits (or tags) from WW branch on XX repo, to YY branch on ZZ repo. All other git commands that move anything bewteen repos start out with this basic "push" or "pull" primitive. (Engh, technically "fetch" is even more of a primitive than those, but I find it more helpful to think in terms of "push/pull" for the most typical daily tasks.) How does one keep their fork up to date? For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Yes. "pull" from the official ~master to your local repo's ~master, if necessary rebasing your changes on top of the new ~master. Although generally, you shouldn't have much (or any) changes in your own ~master branch, so typically the rebase part really shouldn't be needed at all, since you shouldnt have any local changes on ~master which would need to be rebased (this ideal is a situation git refers to as "fast-forward"). Unless, of course, you happen to be futzing around making some changes and making your commits to your ~master (which you're not *supposed* to be doing anyway - standard best practice is to do all your work within a branch). In this case you probably will need to rebase. (The other alternative to rebasing is always a merge, but in the specific situation you're describing, rebase is definitely cleaner and will lead to less problems). Will that actually work, Yes. or is that impossible across separate forks/branches? Totally possible. In fact, that's exactly the sort of stuff git is designed to handle. What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch? You pretty much already got this right. First, you do just as you said above: 1. Pull from the official repo's ~master to your local repo's ~master (rebasing, if necessary, any commits you may have on your local ~master. Although, like Bastile said, if you're making local commits to ~master then *technically* "you're doing it wrong"). 2. And then, after you've pulled (and maybe rebased) the lastest official updates to your local machine...maybe then you added some more commits of your own...then you can push it all from your local machine's clone to your remote fork. Think of your remote github fork as the "published" copy of your local repo. It should exactly mirror your local repo (minus whatever branches/commits you're not yet ready to unleash upon the world): You do your work locally, and whenever you want to "publish" or "make public" your local work, you push it from your local repo to your remote github fork. That's all your remote github fork is: A copy of your whatever parts of your local repo that you've chosen to publish. And how does a pull request
Re: git workflow for D
On Monday, 4 December 2017 at 01:54:57 UTC, ketmar wrote: Basile B. wrote: On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote: Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Who hasn't ;) me. Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch. "git reflog". nothing commited is *ever* lost until you do "git gc". This needs to be repeated: nothing in git is ever lost if it had been commited. You can lose untracked files, but commits do not disappear. If you're unsure before an operation and have difficulties to use git reflog. Before doing the operation, do a simple git branch life-draft (or whatever you want). After the operation if it failed, you still have the commit your HEAD was on referenced by the life-draft branch. branches and tags are just pointers in the directed graph a git repositery is. The interface only does not display the branches that have no entry pointer. git sometimes does GC on its own, so you can turn it off with: git config --global gc.auto 0 don't forget to manually GC your repo then with "git gc", or it may grow quite huge.
Re: git workflow for D
Basile B. wrote: On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote: Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Who hasn't ;) me. Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch. "git reflog". nothing commited is *ever* lost until you do "git gc". git sometimes does GC on its own, so you can turn it off with: git config --global gc.auto 0 don't forget to manually GC your repo then with "git gc", or it may grow quite huge.
Re: git workflow for D
On Sunday, 3 December 2017 at 23:39:49 UTC, Basile B. wrote: On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote: Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Who hasn't ;) Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch. If you still lose changes, you could try using Mercurial with hggit. It can be a bit slow, but not destructive as git itself. ;) I really wish Mercurial won instead of git. Now that hg evolve and hg topic are stable, that actually alleviates the need for git. But the world talks git now. So everyone else is forced to talk in git :( I guess, without StackOverflow and GitHub, no one would be using git. Facebook uses Mercurial and their team is working on a Mercurial server in Rust. https://github.com/facebookexperimental/mononoke I thought Facebook uses DLang as well. No one's motivated to write one in DLang?
Re: git workflow for D
On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote: Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Who hasn't ;) Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch. Since then I always access git via mercurial. In comparison Mercurial is far better a VCS tool. I use git gui (i find other GUIs slower even if nicer) but even...there are few commands to know: - checkout /*select a branch or a commit in the history*/ - commit /*validate changes*/ - pull /*get upstream changes*/ - push /*send upstream changes*/ - rebase /*squash - fixup*/ - stash /*backup before pull in case of...*/ you can live with that.
Re: git workflow for D
Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Since then I always access git via mercurial. In comparison Mercurial is far better a VCS tool.
Re: git workflow for D
On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote: I've finally started learning git, due to our team expanding beyond one person - awesome, right? Anyways, I've got things more or less figured out, which is nice, because being clueless about git is a big blocker for me trying to do any real work on dmd/phobos/druntime. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in. How does one keep their fork up to date? For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Will that actually work, or is that impossible across separate forks/branches? What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch? you can fork it, set dmd/master as upstream and then git fetch upstream. you can then rebase. And how does a pull request actually work? Is it a request to merge my entire branch, or just some specific files? and do I need a separate branch for each pull request, or is the pull request itself somehow isolated from my changes? commits can be cherrypick-ed or you can request your entire branch to be merged. it doesn't always have to be the master branch. for example, if there's std.experimental.logger branch, you can ask for your branch to be merged with that. having a seperate branch for each feature is most of the time the way to go. makes it cleaner for yourself. later on you can delete those merged branches. Anyways, I'd just be rambling if I kept asking questions. If anyone can offer any kind of advice, or an article that explains these things concisely and effectively, that would be helpful. Thanks
Re: git workflow for D
On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote: I've finally started learning git, due to our team expanding beyond one person - awesome, right? Anyways, I've got things more or less figured out, which is nice, because being clueless about git is a big blocker for me trying to do any real work on dmd/phobos/druntime. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in. How does one keep their fork up to date? Just push to your fork/master after pulling from the (shared) origin/master. For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Will that actually work, or is that impossible across separate forks/branches? What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch? In a non personal project you NEVER commit to master. You make each single fucking change in a specific branch (sorry for the language, it's intentionally gross). the master branch is only updated when you pull from the origin. And how does a pull request actually work? Is it a request to merge my entire branch, Yes it's a merge. Optionally all the commits can be squashed. or just some specific files? and do I need a separate branch for each pull request, Yes, yes yes, again. ~master is sacrosanct. or is the pull request itself somehow isolated from my changes? Anyways, I'd just be rambling if I kept asking questions. If anyone can offer any kind of advice, or an article that explains these things concisely and effectively, that would be helpful. Thanks The only article i've ever read about git was when the first time i needed to squash (actually i rather do "fixup" 99% of the time...) so i have nothing else to add.
git workflow for D
I've finally started learning git, due to our team expanding beyond one person - awesome, right? Anyways, I've got things more or less figured out, which is nice, because being clueless about git is a big blocker for me trying to do any real work on dmd/phobos/druntime. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in. How does one keep their fork up to date? For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Will that actually work, or is that impossible across separate forks/branches? What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch? And how does a pull request actually work? Is it a request to merge my entire branch, or just some specific files? and do I need a separate branch for each pull request, or is the pull request itself somehow isolated from my changes? Anyways, I'd just be rambling if I kept asking questions. If anyone can offer any kind of advice, or an article that explains these things concisely and effectively, that would be helpful. Thanks
