commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@sandglass-software.com>
Subject Re: [Math] Controlled and and assisted switch to "Git"
Date Wed, 27 Nov 2013 13:25:16 GMT
git stash is the same as svn create patch and revert. So, you're 
creating a local patch, reverting your local changes, updating your 
local copy from the repo (git pull), then git stash pop will restore 
your previous local changes - the same as svn apply patch.

The only way that using git instead of svn will become "easy" is by 
doing it - like anything else.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 11/27/2013 7:47 AM, Gilles wrote:
> On Wed, 27 Nov 2013 12:44:27 +0100, Emmanuel Bourg wrote:
>> Le 27/11/2013 12:13, Gilles a écrit :
>>
>>> I'm only a bit worried about the timing, and whether knowledgeable
>>> people will be willing to detail the move and explain what to do to
>>> so that the total ignorant can indeed continue contributing "à la
>>> svn"[1]
>>> until he finds the time to study the more advanced features.
>>
>> If you don't apply a fancy branch model Git can be used just like
>> Subversion
>>
>> Checkout:
>>
>>    git clone <url>
>>
>> Commit all changes:
>>
>>    git commit -a
>>    git push
>>
>> Update from the repository:
>>
>>    git pull
>
> Quite clear up to here.
>
>>
>> The one thing Git doesn't do as well as Subversion is merging the local
>> changes with the remote changes when updating the local copy. He will
>> refuse to update the local copy if there are conflicting changes. In
>> this case you either have to commit your local modifications, or stash
>> them before updating. You can then resolve the conflicts as usual.
>>
>>    git stash
>>    git pull
>>    git stash pop
>
> What is "stash", what is "stash pop"?
>
> You see, from my zero knowledge, I infer from a previous post that some
> non-committer contributor can provide an "outdated" patch, and I, as a
> committer, should still be able to commit it (i.e. without asking him
> to update the patch with the newer trunk). How? On what condition is it
> possible, and when does that approach become impossible?
>
> So I could say that the "limitations" of the current system have the
> good consequence that contributors and committers are _obliged_ to work
> together. [E.g. the contributor of an old patch must stick around or,
> if he didn't, that could hint that it could be "risky" to commit a
> (non-trivial) code with nobody to maintain it.]
> Thus, IIUC, in the new system the committers will somehow be expected to do
> more work, since Git makes it possible to "easily" integrate/merge (?)
> individual repositories.
>
>> This is enough to get started. You can then learn gradually how to play
>> with branches, tags, remotes.
>
> Gradually?
> That's my fear (and problem). I should be able to prepare a release by
> simply following the (updated) recipe in "doc/release/release.howto.txt",
> i.e. without any assumption which a seasoned Git-user would consider
> trivial.
>
>
> Thanks,
> Gilles
>
> [1] Describing one and only one fail-safe way.
>
>>
>> http://git-scm.com/book
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message