New branch for No Gnus

New branch for No Gnus

[Lars Ingebrigtsen]

As previously discussed, we need to do a new Gnus branch so that we can
continue adding new feetchers to Gnus.  I think the best way would be to
create a No Gnus branch for bug fixes, and then continue developing on
the trunk.

As usual, I have no idea how to actually do something like that with
git, so could someone give a recipe?  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Raphael Kubo da Costa]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As previously discussed

Shamefully, I have not watched all the recent threads here, so I'm not
sure what the purpose of keeping master from a "stable" branch is. Would
it be possible to clarify that to a newcomer (ie. only the stable branch
is merged back into Emacs etc)?

> As usual, I have no idea how to actually do something like that with
> git, so could someone give a recipe?  :-)

I guess it depends on the above: one possibility would be creating a
branch off master and regularly (or whenever you guys feel it's
necessary) merge it back into master to make it receive the bug fixes as
well. What's not clear is whether the same branch will be used in the
future for the same purpose. If it's not, one could do something as
follows:

 $ git checkout -b no-gnus-with-unique-version-identifier master
 $ # edit files, commit etc
 $ git push origin no-gnus-with-unique-version-identifier

And then later:
 $ git checkout master
 $ git merge [--log] no-gnus-with-unique-version-identifier
 $ git push origin master

Merging the ChangeLog entries can be problematic, though.

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Raphael Kubo da Costa <rakuco@FreeBSD.org> writes:

> Shamefully, I have not watched all the recent threads here, so I'm not
> sure what the purpose of keeping master from a "stable" branch is. Would
> it be possible to clarify that to a newcomer (ie. only the stable branch
> is merged back into Emacs etc)?

Yes.  Emacs 24 is in a feature freeze.

>  $ git checkout -b no-gnus-with-unique-version-identifier master
>  $ # edit files, commit etc
>  $ git push origin no-gnus-with-unique-version-identifier
>
> And then later:
>  $ git checkout master
>  $ git merge [--log] no-gnus-with-unique-version-identifier
>  $ git push origin master
>
> Merging the ChangeLog entries can be problematic, though.

Right.  I think I saw something about a ChangeLog plugin for git,
though...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Andreas Schwab]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> As usual, I have no idea how to actually do something like that with
> git, so could someone give a recipe?  :-)

$ git branch no-gnus
$ git push origin no-gnus

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Andreas Schwab <schwab@linux-m68k.org>:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>> As usual, I have no idea how to actually do something like that with
>> git, so could someone give a recipe?  :-)

> $ git branch no-gnus
> $ git push origin no-gnus

I usually do
 git checkout -b no-gnus
 git push origin HEAD
(after this you are on the no-gnus branch, and it is a copy of master
 up to the point when you did the checkout)

Another command to know, is
 git branch

This command will list all local branches, with the one you're currently
on, marked with a "*".


To work on master and get the latest updates, do
 git checkout master
 git pull
(now you can work, and when finished, do)
 git push origin HEAD

To get the latest from master into the no-gnus branch:
 git checkout no-gnus
 git fetch
 git merge origin/master
(and if there are no conflicts, do)
 git push origin HEAD

Note: The big thing about to learn about git isn't that it is a
distributed VCS.  The big thing to learn in git, is branching and
merging.  If you are thinking about branching and merging in the mindset
of CVS or SVN, you have the wrong mental view of things.  Branching and
merging are _cheap_ operations in git

Chapter 3, of the "Pro Git" book, is recommended reading:
 http://progit.org/book/ch3-0.html

The whys and hows of git's behaviour became much clearer to me after
reading that chapter.

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> To work on master and get the latest updates, do
>  git checkout master
>  git pull
> (now you can work, and when finished, do)
>  git push origin HEAD
>
> To get the latest from master into the no-gnus branch:
>  git checkout no-gnus
>  git fetch
>  git merge origin/master
> (and if there are no conflicts, do)
>  git push origin HEAD

Well, I'll probably be having separate directories ngnus and mgnus for
the two branches, so that I can test and run them concurrently.  So I
won't be pivoting branches (in the same directory) any, I think?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> Well, I'll probably be having separate directories ngnus and mgnus for
> the two branches, so that I can test and run them concurrently.  So I
> won't be pivoting branches (in the same directory) any, I think?

This is not a good idea if you want to easily merge changes between the
two branches.  Then you should have the same layout and two separate git
branches. 

In short: you lose the main advantage of git ("merge is *easy*")

First of all: switching branches is a very low cost operation, so your
main time usage when switching will be building gnus.

Secondly, you can easily have two gnusen side by side without
sacrificing any git-goodies:
 mkdir ~/git
 cd ~/git
 git clone https://git.gnus.org/gnus.git
 mv gnus ngnus
 cd ngnus
 git checkout -b no-gnus
 git push origin HEAD
 git checkout master
 git branch -D no-gnus
 git checkout no-gnus
 git branch -D master
 git clone https://git.gnus.org/gnus.git
 mv gnus mgnus

This will give you two gnusen side by side, each on a different git
branch, with no other clutter (that's what the "git branch -D" is
about), and merging between the branches can be done by pushing and
fetching from origin.

The ngnus directory is on the no-gnus branch.

Alternatively, if ngnus is to remain the master branch until emacs 24 is
out (to ease updating beteen emacs bzr and gnus git), your can do this:
 mkdir ~/git
 cd ~/git
 git clone https://git.gnus.org/gnus.git
 mv gnus ngnus
 git clone https://git.gnus.org/gnus.git
 mv gnus mgnus
 cd mgnus
 git checkout -b mgnus
 git push origin HEAD
 git checkout master
 git branch -D mgnus
 git checkout mgnus
 git branch -D master

Then ~/git/mgnus/ will be on the mgnus branch.

With this configuration, to get the newest ngnus changes into mgnus, do
this:
 cd ~/git/mgnus/
 git fetch
 git merge origin/master
 git push origin HEAD

Most of the time, merge will be a painless and conflict free operation.

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> First of all: switching branches is a very low cost operation, so your
> main time usage when switching will be building gnus.

Yes, and that's not an option.  I will usually be using Ma Gnus, but
testing bug fixes with No Gnus, and a work flow that requires me to...
do something...  to switch between the two is just out of the question.

> Secondly, you can easily have two gnusen side by side without
> sacrificing any git-goodies:

Yes, that's what I was meaning to say.  :-)  Two directories that point
to different branches.  

>  mkdir ~/git
>  cd ~/git
>  git clone https://git.gnus.org/gnus.git
>  mv gnus ngnus
>  cd ngnus
>  git checkout -b no-gnus
>  git push origin HEAD
>  git checkout master
>  git branch -D no-gnus
>  git checkout no-gnus
>  git branch -D master
>  git clone https://git.gnus.org/gnus.git
>  mv gnus mgnus
>
> This will give you two gnusen side by side, each on a different git
> branch, with no other clutter (that's what the "git branch -D" is
> about), and merging between the branches can be done by pushing and
> fetching from origin.

Thanks.  I think all merging will be from no-gnus to ma-gnus, and not
the other way around.  Unless I mess stuff up.  :-)

> Most of the time, merge will be a painless and conflict free operation.

Except for the ChangeLog, but I've installed git-merge-changelog now,
and hope that that'll fix stuff.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> Thanks.  I think all merging will be from no-gnus to ma-gnus, and not
> the other way around.  Unless I mess stuff up.  :-)

As I did earlier in the thread, I highly recommend chapter three ("Git
Branching") of the "Pro Git" book: http://progit.org/book/ch3-0.html

As well as being extremely useful in understanding how git operates, the
chapter is interesting from a software engineering point of view.

The book is available for download in PDF, Mobi and Epub from the web
site. See "Also available in" on the TOC page: http://progit.org/book/

(Or you can buy the paper version and support the above web site)

Disclaimer: I have no affilation with the book but have it in the paper
version, as well as in epub format on my Sony Reader

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Ok, the new No Gnus branch has been created, and Ma Gnus has been
started.  Let's see whether I can actually do merges now, then.  :-)

But I guess I don't really want to merge No Gnus as is into master.  I
just want to cherry-pick any commits I make, I guess?  I certainly don't
want to merge the commit I just did that bumped the version number to No
Gnus 0.20, for instance.

So how do I cherry-pick commits?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Richard Riley]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ok, the new No Gnus branch has been created, and Ma Gnus has been
> started.  Let's see whether I can actually do merges now, then.  :-)
>
> But I guess I don't really want to merge No Gnus as is into master.  I
> just want to cherry-pick any commits I make, I guess?  I certainly don't
> want to merge the commit I just did that bumped the version number to No
> Gnus 0.20, for instance.
>
> So how do I cherry-pick commits?

So which branch do those of us wanting new fixes/updates now
clone/checkout? Any emacs pulling in a "stable" gnus can surely do it
from tag id or checkin hash? I guess I've kind of lost what master is
supposed to be now.

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Richard Riley <rileyrg@gmail.com> writes:

> So which branch do those of us wanting new fixes/updates now
> clone/checkout? Any emacs pulling in a "stable" gnus can surely do it
> from tag id or checkin hash? I guess I've kind of lost what master is
> supposed to be now.

Development is on the master branch.  Bug fixes on the no-gnus branch.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Richard Riley]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Richard Riley <rileyrg@gmail.com> writes:
>
>> So which branch do those of us wanting new fixes/updates now
>> clone/checkout? Any emacs pulling in a "stable" gnus can surely do it
>> from tag id or checkin hash? I guess I've kind of lost what master is
>> supposed to be now.
>
> Development is on the master branch.  Bug fixes on the no-gnus branch.

So no-gnus is released gnus with critical bug fixes? And master is
"latest being worked on"?

Re: New branch for No Gnus

[Raphael Kubo da Costa]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But I guess I don't really want to merge No Gnus as is into master.  I
> just want to cherry-pick any commits I make, I guess?  I certainly don't
> want to merge the commit I just did that bumped the version number to No
> Gnus 0.20, for instance.

You'd get a merge conflict at that point when merging anyway, so I don't
think this kind of thing would end up slipping under the radar.

> So how do I cherry-pick commits?

git cherry-pick [-x] [--edit] <COMMIT>, where <COMMIT> can be the SHA-1
hash or any other way of pointing to a certain commit. I still think
merging makes more sense, though.

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Raphael Kubo da Costa <rakuco@FreeBSD.org> writes:

> You'd get a merge conflict at that point when merging anyway, so I don't
> think this kind of thing would end up slipping under the radar.

So I should just merge, and then delete all the stuff that Git put into
Ma Gnus from No Gnus?  (I mean, right now.  None of the changes to No
Gnus, which are just version numbers, apply to Ma Gnus.)

And then after doing that, then all further changes will just apply
nicely?  I mean, if I then do an actual bug fix in No Gnus, and then
merge that into Ma Gnus?  That'd be nice.  :-)

>> So how do I cherry-pick commits?
>
> git cherry-pick [-x] [--edit] <COMMIT>, where <COMMIT> can be the SHA-1
> hash or any other way of pointing to a certain commit. I still think
> merging makes more sense, though.

Right.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Raphael Kubo da Costa]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I should just merge, and then delete all the stuff that Git put into
> Ma Gnus from No Gnus?  (I mean, right now.  None of the changes to No
> Gnus, which are just version numbers, apply to Ma Gnus.)

Yes. Depending on how much free time you have these days, you might also
want to take a look at git merge's different merge strategies, and also
the `git rerere' command, which records conflict resolutions for the
future.

> And then after doing that, then all further changes will just apply
> nicely?  I mean, if I then do an actual bug fix in No Gnus, and then
> merge that into Ma Gnus?  That'd be nice.  :-)

That's the idea ;)

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Raphael Kubo da Costa <rakuco@FreeBSD.org> writes:

> Yes. Depending on how much free time you have these days, you might also
> want to take a look at git merge's different merge strategies, and also
> the `git rerere' command, which records conflict resolutions for the
> future.

Do I need the "git rerere" if I never do a "git reset"?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Raphael Kubo da Costa]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Raphael Kubo da Costa <rakuco@FreeBSD.org> writes:
>
>> Yes. Depending on how much free time you have these days, you might also
>> want to take a look at git merge's different merge strategies, and also
>> the `git rerere' command, which records conflict resolutions for the
>> future.
>
> Do I need the "git rerere" if I never do a "git reset"?

I don't think I've fully understood the question; both commands seem
orthogonal to me. Progit [1] will probably make more sense than anything
I say :)

[1] http://progit.org/2010/03/08/rerere.html

Re: New branch for No Gnus

[Andreas Schwab]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I should just merge, and then delete all the stuff that Git put into
> Ma Gnus from No Gnus?  (I mean, right now.  None of the changes to No
> Gnus, which are just version numbers, apply to Ma Gnus.)

You will get a merge conflict, which you resolve.

$ git merge origin/no-gnus 
Auto-merging texi/message.texi
CONFLICT (content): Merge conflict in texi/message.texi
Auto-merging texi/gnus.texi
CONFLICT (content): Merge conflict in texi/gnus.texi
Auto-merging lisp/gnus.el
CONFLICT (content): Merge conflict in lisp/gnus.el
Auto-merging lisp/ChangeLog
Recorded preimage for 'lisp/gnus.el'
Recorded preimage for 'texi/gnus.texi'
Recorded preimage for 'texi/message.texi'
Automatic merge failed; fix conflicts and then commit the result.

The messages about recording preimage are part of the rerere support.
There is no conflict report for lisp/ChangeLog since I have set up
git-merge-changelog.  Use git reset --merge to abort a failed merge.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> So I should just merge, and then delete all the stuff that Git put into
> Ma Gnus from No Gnus?  (I mean, right now.  None of the changes to No
> Gnus, which are just version numbers, apply to Ma Gnus.)

If you know that the current changes in no-gnus that differ from master
don't apply, then just
 git fetch
 git merge -s ours orgin/no-gnus
and you won't be bothered by those changes on future merges (until those
files change again)

"-s ours" means "make it look like a merge, but all stuff on the current
branch stays the way it is".

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> If you know that the current changes in no-gnus that differ from master
> don't apply, then just
>  git fetch
>  git merge -s ours orgin/no-gnus
> and you won't be bothered by those changes on future merges (until those
> files change again)
>
> "-s ours" means "make it look like a merge, but all stuff on the current
> branch stays the way it is".

Great!  That has to be just what I need right now, I think, since none
of the changes I made to No Gnus should end up in Ma Gnus.

I'll try that now...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Raphael Kubo da Costa]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Steinar Bang <sb@dod.no> writes:
>
>> If you know that the current changes in no-gnus that differ from master
>> don't apply, then just
>>  git fetch
>>  git merge -s ours orgin/no-gnus
>> and you won't be bothered by those changes on future merges (until those
>> files change again)
>>
>> "-s ours" means "make it look like a merge, but all stuff on the current
>> branch stays the way it is".
>
> Great!  That has to be just what I need right now, I think, since none
> of the changes I made to No Gnus should end up in Ma Gnus.
>
> I'll try that now...

Are you sure "-s ours" is what you are looking for? If you are on branch
master and use `git merge -s ours no-gnus`, it will effectively bring
no-gnus' history in, but discard _all_ changes from no-gnus.

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Raphael Kubo da Costa <rakuco@FreeBSD.org> writes:

> Are you sure "-s ours" is what you are looking for? If you are on branch
> master and use `git merge -s ours no-gnus`, it will effectively bring
> no-gnus' history in, but discard _all_ changes from no-gnus.

I didn't want the history, either, but I did want to discard all the
changes.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Raphael Kubo da Costa]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Raphael Kubo da Costa <rakuco@FreeBSD.org> writes:
>
>> Are you sure "-s ours" is what you are looking for? If you are on branch
>> master and use `git merge -s ours no-gnus`, it will effectively bring
>> no-gnus' history in, but discard _all_ changes from no-gnus.
>
> I didn't want the history, either, but I did want to discard all the
> changes.

I thought the opposite was the desired outcome? I mean, if you are in
master and merge no-gnus, you'd want the commits made to no-gnus in the
commit log and also the bug fixes they bring. If you use "-s ours",
you'll only get the history, but all the commit contents (ie. bug fixes)
will be dropped.

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Raphael Kubo da Costa <rakuco@FreeBSD.org>:


> I thought the opposite was the desired outcome? I mean, if you are in
> master and merge no-gnus, you'd want the commits made to no-gnus in
> the commit log and also the bug fixes they bring. If you use "-s
> ours", you'll only get the history, but all the commit contents
> (ie. bug fixes) will be dropped.

The no-gnus branch had just recently been created off master, so the two
branches shared ancestry except for the two commits that weren't
supposed to be applied to master (version number changes).

Until those version number files are touched again, regular merge can be
used. 

Once those files are touched again, either
 1. "git merge --no-ff --no-commit origin/no-gnus" and revert the
    undesired files
or
 2. Do a "git merge sha1-of-commit-before-the-version-change-commits"
    followed by a "git merge -s ours origin/no-gnus" (or merge with the
    sha1 of the latest commit, if the version number commits are not at
    the head of the no-gnus branch)

Re: New branch for No Gnus

[Andreas Schwab]

Raphael Kubo da Costa <rakuco@FreeBSD.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Steinar Bang <sb@dod.no> writes:
>>
>>> If you know that the current changes in no-gnus that differ from master
>>> don't apply, then just
>>>  git fetch
>>>  git merge -s ours orgin/no-gnus
>>> and you won't be bothered by those changes on future merges (until those
>>> files change again)
>>>
>>> "-s ours" means "make it look like a merge, but all stuff on the current
>>> branch stays the way it is".
>>
>> Great!  That has to be just what I need right now, I think, since none
>> of the changes I made to No Gnus should end up in Ma Gnus.
>>
>> I'll try that now...
>
> Are you sure "-s ours" is what you are looking for? If you are on branch
> master and use `git merge -s ours no-gnus`, it will effectively bring
> no-gnus' history in, but discard _all_ changes from no-gnus.

The two commits that were merged here are only intended for the no-gnus
branch, so it looks good.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New branch for No Gnus

[Katsumi Yamaoka]

Er, is it me who broke the no-gnus branch?
Now it looks like having been overridden by the trunk.

$ grep gnus-version ngnus/lisp/gnus.el
(defconst gnus-version-number "0.2"
(defconst gnus-version (format "Ma Gnus v%s" gnus-version-number)
                                        gnus-version (gnus-emacs-version)))

I did the recipe, Steinar Bang wrote in <87aa54riih.fsf@dod.no>.
The cvslog list did no report about it so far, though.

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Er, is it me who broke the no-gnus branch?

I think so.  :-)  I sent you an email a while ago...

> Now it looks like having been overridden by the trunk.

[...]

> I did the recipe, Steinar Bang wrote in <87aa54riih.fsf@dod.no>.

Yeah, that was just for creating the branch and stuff.  You should just
have to have done "cvs checkout no-gnus" to get the No Gnus branch.
Nothing further would have been necessary, I think?

Anyway, anybody know what's the best way to clean this up?  Does git
have a total "rollback" feature?  Or is it better to just apply
reverse-patches to the No Gnus branch?

And the ma-gnus branch has to be deleted, but that's easy, I think.  I
think I saw that somewhere...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Katsumi Yamaoka]

Lars Ingebrigtsen wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Er, is it me who broke the no-gnus branch?

> I think so.  :-)  I sent you an email a while ago...

Oops, sorry.  Could you please fix it?  I'm not fit for doing it,
since I'm quite capable of making other problems. (^^;;)

[...]

>> I did the recipe, Steinar Bang wrote in <87aa54riih.fsf@dod.no>.

> Yeah, that was just for creating the branch and stuff.  You should just
> have to have done "cvs checkout no-gnus" to get the No Gnus branch.
> Nothing further would have been necessary, I think?

> Anyway, anybody know what's the best way to clean this up?  Does git
> have a total "rollback" feature?  Or is it better to just apply
> reverse-patches to the No Gnus branch?

> And the ma-gnus branch has to be deleted, but that's easy, I think.  I
> think I saw that somewhere...

TIA

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Oops, sorry.  Could you please fix it?  I'm not fit for doing it,
> since I'm quite capable of making other problems. (^^;;)

I think I probably fixed it now...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Ok, now things look almost OK, so I'm going to bed.  The only thing that
remains is to delete the ma-gnus branch on git.gnus.org...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> Ok, now things look almost OK, so I'm going to bed.  The only thing that
> remains is to delete the ma-gnus branch on git.gnus.org...

git push origin :ma-gnus

(`M-x man RET git-push RET' followed by a search for "origin :experimental"
(without the quotes))

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> git push origin :ma-gnus

larsi@rusty:~/mgnus$ git push origin :ma-gnus
remote: error: denying ref deletion for refs/heads/ma-gnus

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@dod.no> writes:
>> git push origin :ma-gnus

> larsi@rusty:~/mgnus$ git push origin :ma-gnus
> remote: error: denying ref deletion for refs/heads/ma-gnus

Some possible causes here:
 http://stackoverflow.com/questions/5723511/how-do-i-remove-a-remote-branch-when-i-get-an-error

Summary of possible causes:
 1. privileges of the user
 2. remote repo has "denyDeletes = true" in its config

There is a brute force workaround at the end of the StackOverflow
thread: log in on the remote server, and to "branch -D ma-gnus" in the
repository there

Re: New branch for No Gnus

[Ted Zlatanov]

On Wed, 01 Feb 2012 15:30:00 +0100 Steinar Bang <sb@dod.no> wrote: 

>>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

>> larsi@rusty:~/mgnus$ git push origin :ma-gnus
>> remote: error: denying ref deletion for refs/heads/ma-gnus

SB> Summary of possible causes:
SB>  1. privileges of the user
SB>  2. remote repo has "denyDeletes = true" in its config

SB> There is a brute force workaround at the end of the StackOverflow
SB> thread: log in on the remote server, and to "branch -D ma-gnus" in the
SB> repository there

On Wed, 01 Feb 2012 12:31:03 +0100 Andreas Schwab <schwab@linux-m68k.org> wrote: 

AS> You always need to pull first, since the server will not allow
AS> non-fast-forward pushes.

We deny deletes and non-fast forwards over HTTP on the Gnus Git repo, so
Lars or I can delete a branch manually if it ever is necessary.  I would
have helped with this normally, but was not available for the fun yesterday.

Ted

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> We deny deletes and non-fast forwards over HTTP on the Gnus Git repo, so
> Lars or I can delete a branch manually if it ever is necessary.  I would
> have helped with this normally, but was not available for the fun yesterday.

Could you delete the ma-gnus branch?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Ted Zlatanov]

On Wed, 01 Feb 2012 19:30:10 +0100 Lars Ingebrigtsen <larsi@gnus.org> wrote: 

LI> Ted Zlatanov <tzz@lifelogs.com> writes:
>> We deny deletes and non-fast forwards over HTTP on the Gnus Git repo, so
>> Lars or I can delete a branch manually if it ever is necessary.  I would
>> have helped with this normally, but was not available for the fun yesterday.

LI> Could you delete the ma-gnus branch?

Done.  People who made new clones in this troubled time will have
references to origin/ma-gnus but we can't help that.

Ted

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Ted Zlatanov <tzz@lifelogs.com>:

> Done.  People who made new clones in this troubled time will have
> references to origin/ma-gnus but we can't help that.

If they do
 git remote prune origin
it should fix things for them.

Re: New branch for No Gnus

[Ted Zlatanov]

On Wed, 01 Feb 2012 22:59:26 +0100 Steinar Bang <sb@dod.no> wrote: 

>>>>>> Ted Zlatanov <tzz@lifelogs.com>:
>> Done.  People who made new clones in this troubled time will have
>> references to origin/ma-gnus but we can't help that.

SB> If they do
SB>  git remote prune origin
SB> it should fix things for them.

Nice trick, I didn't know this.  We can't make that reference disappear
from their repo clone without some local command, unfortunately :)  But
that should do it, and of course when we actually create a ma-gnus
branch things should Just Work.

Thanks
Ted

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Nice trick, I didn't know this.  We can't make that reference disappear
> from their repo clone without some local command, unfortunately :)  But
> that should do it, and of course when we actually create a ma-gnus
> branch things should Just Work.

Yup; works for me.  Now "git branch -a" no longer lists the ma-gnus
branch.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Andreas Schwab]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Done.  People who made new clones in this troubled time will have
> references to origin/ma-gnus but we can't help that.

$ git fetch --prune

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> Yeah, that was just for creating the branch and stuff.  You should just
> have to have done "cvs checkout no-gnus" to get the No Gnus branch.

"git checkout no-gnus", perhaps...? :-)

> Nothing further would have been necessary, I think?

Correct.

> Anyway, anybody know what's the best way to clean this up?  Does git
> have a total "rollback" feature?

Oh yes!  But it is somewhat dangerous (I have lost work this way):
 git checkout no-gnus
 git reset --hard sha1-of-last-commit-that-was-good
 git push -f origin HEAD

(the last one, "push -f" after a reset, is somewhat rude if others have
pulled in the meantime, and started adding commits to the stuff that you
have reset.  Should be used with utmost caution)

> Or is it better to just apply reverse-patches to the No Gnus branch?

Depends on what the branch was looking like after it was b0rked.  But
since it is fixed now, I guess you're good...?

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

>  git fetch
>  git merge -s ours orgin/no-gnus

larsi@rusty:~/mgnus$ git merge -s ours orgin/no-gnus
fatal: 'orgin/no-gnus' does not point to a commit

Hm.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> larsi@rusty:~/mgnus$ git merge -s ours orgin/no-gnus
> fatal: 'orgin/no-gnus' does not point to a commit

"origin".  Me so smart S.M.R.T.

And now I'll try to merge a real change made in No Gnus...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And now I'll try to merge a real change made in No Gnus...

And I think it went without a hitch!  :-)

http://git.gnus.org/cgit/gnus.git/log/

Well, I hope so, at least.

Anyway, thanks for all the help, everybody...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Lars Ingebrigtsen]

What happened!

Subject: [gnus git]  branch no-gnus updated: m0-1-12-g7c576ff =11= Merge
 remote-tracking branch 'origin/no-gnus' ; Merge remote-tracking branch
 'origin/no-gnus' ; Start the Ma Gnus news file off. ; (etc)

Two minutes ago?  I didn't do anything two minutes ago.

And now all the Ma Gnus stuff is in No Gnus?  WTF?
 
-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Lars Ingebrigtsen]

An now this just happened:

Subject: [gnus git]  branch ma-gnus created: m0-1-12-g7c576ff =0=
Date: Wed, 01 Feb 2012 00:29:00 +0100 (2 minutes, 33 seconds ago)

The "From" address points to me, but I don't think I'm doing anything.
Is somebody er doing something?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The "From" address points to me, but I don't think I'm doing anything.
> Is somebody er doing something?

Somebody must be doing something.  Two branches, "master" and "ma-gnus"
were just created in the repository.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Lars Ingebrigtsen]

So does anybody know how to make git spit who created a branch?  I sure
can't, after googling for half an hour.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Andreas Schwab]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So does anybody know how to make git spit who created a branch?  I sure
> can't, after googling for half an hour.

You can only find that out from the server log, to see who ran the push.

To undo the damange, you can do "git revert -m 2 HEAD" on the no-gnus
branch.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> To undo the damange, you can do "git revert -m 2 HEAD" on the no-gnus
> branch.

Great!  I'll do that...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> To undo the damange, you can do "git revert -m 2 HEAD" on the no-gnus
>> branch.
>
> Great!  I'll do that...

Just to be totally sure I'm not screwing anything up:  Should I do a
"git pull" in my local No Gnus tree before saying "git revert -m 2
HEAD", and then pushing out, or should I just do the revert without
pulling from git.gnus.org first?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> Just to be totally sure I'm not screwing anything up:  Should I do a
> "git pull" in my local No Gnus tree before saying "git revert -m 2
> HEAD", and then pushing out, or should I just do the revert without
> pulling from git.gnus.org first?

I assume that this is the fix to the messup that was mentioned earlier
in the thread?

I've never used git-revert myself, but I would have done it this way:
 git checkout no-gnus
 git revert -m 2 HEAD
 git push -f origin HEAD

I could try to explain the logic behind this...?  Or I could just mention
chapter 3 of "Pro Git" again...:-)

Briefly:
  - if you do "git branch" you will see all local branches in your git
    repository.
  - If you do "git branch -a" you will see more branches, some with
    "remotes/origin/" in front of them.
  - All local branches exist only in your local .git directory (they do
    not exist upstream (though for tracking branches (mentioned later)
    that is a question of semantics...))
  - You can only check out and work on a local branch
  - Some local branches have a special relationship with a remote
    branch.  These local branches are called "tracking branches".  In
    your case, no-gnus and master are tracking branches
  - When you work on "no-gnus", you can't update
    "remotes/origin/no-gnus" to have the same commits, in other way than
    pushing the commits on "no-gnus" to origin.  So what I did over, was
    to: 
     - check out the local tracking branch no-gnus
     - revert the last two commits on that branch
     - push the current state of the branch to no-gnus on the remote
       called "origin", updating the "remotes/origin/no-gnus" branch in
       your local .git directory in the process
     - the "-f" ("force") flag to push is necessary to make it drop
       commits already on the branch in the origin remote

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Steinar Bang <sb@dod.no> writes:

> I could try to explain the logic behind this...?  Or I could just mention
> chapter 3 of "Pro Git" again...:-)
>
> Briefly:

Thanks for the explanation.  It's now slightly clearer in my mind.  :-)

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Andreas Schwab]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>>> To undo the damange, you can do "git revert -m 2 HEAD" on the no-gnus
>>> branch.
>>
>> Great!  I'll do that...
>
> Just to be totally sure I'm not screwing anything up:  Should I do a
> "git pull" in my local No Gnus tree before saying "git revert -m 2
> HEAD", and then pushing out, or should I just do the revert without
> pulling from git.gnus.org first?

You always need to pull first, since the server will not allow
non-fast-forward pushes.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> You always need to pull first, since the server will not allow
> non-fast-forward pushes.

Right.  I went ahead and did that, and things look OK now.  I think.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

Re: New branch for No Gnus

[Steinar Bang]

>>>>> Lars Ingebrigtsen <larsi@gnus.org>:

> But I guess I don't really want to merge No Gnus as is into master.  I
> just want to cherry-pick any commits I make, I guess? 

Merges are always better than cherry picks: with merges the commits gets
their original identity and commit time.  You also get a clear ancestry
for the file, and the commits in the file.

> I certainly don't want to merge the commit I just did that bumped the
> version number to No Gnus 0.20, for instance.

What you can do, is always merge with
 cd ~/git/mgnus/
 git fetch
 git merge --no-ff --no-commit orgin/no-gnus

The "--no-ff" means that the merge will always create a merge commit in
the branch you're merging into.  History-wise that's a good thing.

The "--no-commit" tells git merge not to do an auto-commit, but stop,
like it always does of there is a commit.

If you then do `M-x magit-status RET' in cd ~/git/mgnus/ you will see
all files affected by the merge.  And entering the files and doing
`C-x v =' will show the diffs with the current branch.

If you don't want the changes for a particular file at all, eg. you want
to keep the current version of the lisp/silly.el file, do
 git checkout origin/master lisp/silly.el

If you do a `g' in the "magit: mgnus" buffer, you will see that
lisp/silly.el has gone away.

If you get a conflict: enter the file, look at the conflict markers and
edit the file to your satisfaction, and then stage the file.

Once you're satisfied with the merge results, just press `c' in the
"magit: mgnus" buffer, og do
 git commit
at the command line, whatever suits you best.

The best thing about this, is that if the files you don't want merged
doesn't have any changes on the no-gnus branch, you won't be bothered by
them on the next merge.  As far as git is concerned it has already been
merged with the master branch, and the current version on master (which
was the old version on master) is the result.

> So how do I cherry-pick commits?

  git cherry-pick sha1-of-commit

But like I said earlier: if you can do it with regular merges, that's
much to be preferred.

(it's chapter 3 in that book again...)

Re: New branch for No Gnus

[Eric S Fraga]

Steinar Bang <sb@dod.no> writes:

> What you can do, is always merge with
>  cd ~/git/mgnus/
>  git fetch
>  git merge --no-ff --no-commit orgin/no-gnus
 
[...]  very useful stuff omitted

Just to say that this was the most helpful yet concise explanation on
how to merge branches in git that I have run into.  One email that I
will keep for posterity.

Thank you!

-- 
: Eric S Fraga (GnuPG: 0xC89193D8FFFCF67D) in Emacs 24.0.92.1 + Ma Gnus v0.2

Re: New branch for No Gnus

[Michael Welsh Duggan]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Ok, the new No Gnus branch has been created, and Ma Gnus has been
> started.  Let's see whether I can actually do merges now, then.  :-)

Hmm...  The no-gnus branch includes the following Changelog message:

2012-01-31  Lars Ingebrigtsen  <larsi@gnus.org>

	* gnus.el (gnus-version): Change name to "Ma Gnus".


Which is a little confusing.

-- 
Michael Welsh Duggan
(md5i@md5i.com)

Re: New branch for No Gnus

[Lars Ingebrigtsen]

Andreas Schwab <schwab@linux-m68k.org> writes:

> $ git branch no-gnus
> $ git push origin no-gnus

Thanks.

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome