lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <>
Subject Re: The Old Git Discussion
Date Sat, 04 Jan 2014 21:13:03 GMT
> This actually might be considered a detriment.  Let's say that you're
> someplace you can review a change but not apply it.  So you review it
> and determine that it's good.  Then the patch creator changes it in a
> way that you don't find acceptable, but still passes all the tests.

When merging a pull request to a GitHub repo, you see all changes and
commits right there in the GUI and can follow the evolution of the PR.

If we were to mimic PR's using plain git (no HUB) then of course we'd need to first fetch
and merge the remote branch, then review and test 
and finally commit. Should the PR author be requested to update his fix, he could do so in
the same remote feature branch and a git pull by the committer would merge in
the latest changes from that feature-branch. Takes some getting used to, but sounds compelling
to me!

> I'm pretty sure pull requests close over the current branch revision, so there's no way
to post ipso facto modify them from the sender's perspective.
Well, take this GitHub PR of mine, I first opened the request, then added another commit to
it before Nolan merged it in:

> But us accepting pull requests from github is completely distinct from
> whether we use svn or git as a version control system: using git
> doesnt even make it easier.

Sure, it's just another channel for contributions. We can still work with patch files in JIRA.
There may be a few git steps (remote add, fetch, checkout) to pull down the remote code which
takes some time getting used to, but all this is made up for due to Git's super-fast branching.
No need to have a bunch of duplicate svn checkouts lying around or wait for svn to checkout
or merge...

Jan Høydahl, search solution architect
Cominvent AS -

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message