Git transition workflow

Git transition workflow

[Paul Michael Reilly]

[-- Attachment #1: Type: text/plain, Size: 480 bytes --]

When we switched to using Bazaar, there was quite a bit of email traffic on
workflow: how best to use bzr when developing Emacs.  I realize that there
are already some workflows for using git with mirrors but I would be
shocked if there wasn't some varied opinions on how best to use git after
Eric pushes that magic button.  Am I wrong, and it is intuitively obvious
how we are going to deal with git and branches, rebasing, reviews, etc?
 That a consensus already exists?

-pmr

[-- Attachment #2: Type: text/html, Size: 535 bytes --]

Git transition workflow

[Stephen J. Turnbull]

Paul Michael Reilly writes:

 > Am I wrong, and it is intuitively obvious how we are going to deal
 > with git and branches, rebasing, reviews, etc?

Having observed several of these transitions, including Emacs's
CVS->Bazaar transition, it's really not a problem as long as the git
fans accept that several major contributors just want a CVS-like
workflow, and git commands that implement that workflow are explained
in straightforward terms.

Based on bzr experience, Emacs is not going to change its basic focus
of on-trunk development with release branches (and there's no need to
do so at present).  The people who might actually want to rebase
already know why it can be dangerous, and how to do it safely.  The
review process isn't going to change (and there's no pressing need to
do so, and several potential minuses to making it more stringent -- cf
the famous play, "Death of a Version Control System", whose
protagonists were really big on formal process).

Re: Git transition workflow

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> Paul Michael Reilly writes:
> 
>  > Am I wrong, and it is intuitively obvious how we are going to deal
>  > with git and branches, rebasing, reviews, etc?
> 
> Having observed several of these transitions, including Emacs's
> CVS->Bazaar transition, it's really not a problem as long as the git
> fans accept that several major contributors just want a CVS-like
> workflow, and git commands that implement that workflow are explained
> in straightforward terms.

Furthermore, the workflow documentation is already up on the wiki.
That's one of the first things I did.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition workflow

[Paul Michael Reilly]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Mon, Aug 11, 2014 at 10:58 PM, Eric S. Raymond <esr@thyrsus.com> wrote:

> Stephen J. Turnbull <stephen@xemacs.org>:
> > Paul Michael Reilly writes:
> >
> >  > Am I wrong, and it is intuitively obvious how we are going to deal
> >  > with git and branches, rebasing, reviews, etc?
> >
> > Having observed several of these transitions, including Emacs's
> > CVS->Bazaar transition, it's really not a problem as long as the git
> > fans accept that several major contributors just want a CVS-like
> > workflow, and git commands that implement that workflow are explained
> > in straightforward terms.
>
> Furthermore, the workflow documentation is already up on the wiki.
> That's one of the first things I did.
>

And would the URL for this workflow documentation be:
http://www.emacswiki.org/emacs-es/GitForEmacsDevs ?

-pmr

[-- Attachment #2: Type: text/html, Size: 1464 bytes --]

Re: Git transition workflow

[Eric S. Raymond]

Paul Michael Reilly <pmr@pajato.com>:
> > Furthermore, the workflow documentation is already up on the wiki.
> > That's one of the first things I did.
> >
> 
> And would the URL for this workflow documentation be:
> http://www.emacswiki.org/emacs-es/GitForEmacsDevs ?

Yes.  There's an associated quick start page as well.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Git transition workflow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

I hope someone will provide an introduction to a simple way of using
Git, just as someone did with Bzr.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

Re: Git transition workflow

[Rüdiger Sonderfeld]

On Monday 11 August 2014 23:16:12 Richard Stallman wrote:
> I hope someone will provide an introduction to a simple way of using
> Git, just as someone did with Bzr.

ESR already took care of it:

- http://www.emacswiki.org/emacs/GitQuickStartForEmacsDevs
- http://www.emacswiki.org/emacs/GitForEmacsDevs

There was talk about moving the document to the GNU Emacs repo.  But I guess 
that will have to wait until the transition actually happens.

Regards,
Rüdiger

Re: Git transition workflow

[Jan Nieuwenhuizen]

Rüdiger Sonderfeld writes:

> ESR already took care of it:
>
> - http://www.emacswiki.org/emacs/GitQuickStartForEmacsDevs

    Daily work
    If you’re using the command-line:

    git pull

May I suggest to change this to
 
    git pull --rebase / git pull -r

or we're going to see a whole lot of merge commits.
Greetings,
Jan

-- 
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

Re: Git transition workflow

[Achim Gratz]

Jan Nieuwenhuizen writes:
>     Daily work
>     If you’re using the command-line:
>
>     git pull
>
> May I suggest to change this to
>  
>     git pull --rebase / git pull -r
>
> or we're going to see a whole lot of merge commits.

If you have local branches you _want_ to rebase, then it is generally
much more useful to set them "rebase=true" in the Git config.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: Git transition workflow

[Stephen J. Turnbull]

Achim Gratz writes:
 > Jan Nieuwenhuizen writes:
 > >     Daily work
 > >     If you’re using the command-line:
 > >
 > >     git pull
 > >
 > > May I suggest to change this to
 > >  
 > >     git pull --rebase / git pull -r
 > >
 > > or we're going to see a whole lot of merge commits.

This requires people who don't already know how to "git rebase" to
learn it (I mean the resolution workflow, not the command, of course).
It will get a lot of pushback, and I expect that those users will
revert to "git pull".  On the other hand, merge conflicts are familiar
from ancient times, and doesn't require learning a new workflow.

You'll probably get used to it; I did when XEmacs moved to hg (and
after several years of git use with rebasing before pushing, I was
pretty disgusted by the XEmacs repo's DAG in the early days).  It was
not a big deal for most of our developers, so I accepted the
inevitable.  You probably should too.

It should be "easy" to write a commit hook that just exchanges parents
of a merge commit when the first parent's committer (author?) is the
same as the merge commit's and the other parent is different.  This
(with high probability) preserves the mainline in a bzr-like fashion,
and would be easy for CVS-like users to adopt (since only the merge
commit object is manipulated, and that is automagic, no workflow
change is involved).

Then developers who really hate "redundant" merge commits can use
"log --first-parent" to see pretty much what they want (the merge
commit that integrates a trivial one-or-two-commit branch, and rebased
commits that fast-forward when pushed).  You'll miss important history
from a few feature branches, but that's generally fixable with
"log --committer" (plus --date or --skip to drill down).  This is a
workflow change for you, I grant, but you are more able to adopt it
easily or do without, and your decision affects only you.

Note that I generally agree with you about best practice (and disagree
with the "even private history is sacred"/"rebased commits need
testing" crowd).  However, as I wrote before, Emacs doesn't *need*
such best practice (let alone generally conform to it currently), and
my experience with the Python, XEmacs, and Emacs CVCS-to-DVCS
migrations is that trying to implement workflow changes at the same as
changing VCSes doesn't work -- people too important to discipline balk
and/or threaten to delay the move (cf. "vc-find-conflicting-files must
work"), new committers don't know about the policies, etc.

Take an improvement in 

Re: Git transition workflow

[Ashton Kemerling]

Furthermore, the increasing dominance of Github and its
pullrequest+merge workflow proves that merge commits are not a complete
hinderence even on similarly massive projects like RoR. 

While I certainly am in the "I don't like merge commits" camp, I don't
think the presence or absence of merge commits is really worth humming
and hawing over a lot, especially if it would delay a git
conversion. I've worked in organizations that allowed them, and worked
in organizations that hated them, and I noticed very little difference
between the two on that front.

-- 
Ashton Kemerling

Re: Git transition workflow

[Sergey Organov]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Achim Gratz writes:
>  > Jan Nieuwenhuizen writes:
>  > >     Daily work
>  > >     If you’re using the command-line:
>  > >
>  > >     git pull
>  > >
>  > > May I suggest to change this to
>  > >  
>  > >     git pull --rebase / git pull -r
>  > >
>  > > or we're going to see a whole lot of merge commits.
>
> This requires people who don't already know how to "git rebase" to
> learn it (I mean the resolution workflow, not the command, of course).
> It will get a lot of pushback, and I expect that those users will
> revert to "git pull".  On the other hand, merge conflicts are familiar
> from ancient times, and doesn't require learning a new workflow.

1. CVS in fact does the rebase when you "cvs update" with local
   modifications, so functionally 'git pull --rebase' is closer to
   original CVS "cvs update" than 'git pull --rebase=false' (i.e.,
   merge).

2. When there is no merge conflicts, everything just works in both cases
   without user intervention.
   
3. Merge conflicts, if any, as well as their resolution, are very
   similar in both workflows. The only difference is that one needs to
   learn to use "git rebase --continue" instead of "git commit" after
   conflicts are resolved.

4. Setting "pull.rebase" configuration value to 'preserve' or 'true'
   hides pull invocation differences (minor convenience).

From within emacs, magit helps a lot (with any workflow).

-- 
Sergey.

Re: Git transition workflow

[Stefan Monnier]

> 3. Merge conflicts, if any, as well as their resolution, are very
>    similar in both workflows. The only difference is that one needs to
>    learn to use "git rebase --continue" instead of "git commit" after
>    conflicts are resolved.

There's one big difference here: in the merge case, all the state is
directly visible in the files, whereas for rebase, some of the state is
stashed away in the .git directory (hence the need to use "git
rebase --continue" which fetches the leftover state and keeps on
processing it).

It definitely takes some getting used it.


        Stefan

Re: Git transition workflow

[Sergey Organov]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> 3. Merge conflicts, if any, as well as their resolution, are very
>>    similar in both workflows. The only difference is that one needs to
>>    learn to use "git rebase --continue" instead of "git commit" after
>>    conflicts are resolved.
>
> There's one big difference here: in the merge case, all the state is
> directly visible in the files,

Not exactly, as staging area does have some hidden state. That's why you
need to "git add" a file after you resolve conflicts (unlike CVS).

> whereas for rebase, some of the state is stashed away in the .git
> directory (hence the need to use "git rebase --continue" which fetches
> the leftover state and keeps on processing it).
>
> It definitely takes some getting used it.

Yes, indeed, it's unnatural to use "git rebase --continue" to continue
interrupted "git pull". But fundamentally rebase is just a sequence of 1
or more merges ( = the number of commits to rebase, so still exactly 1
merge for typical quick fix). Nothing very new.

-- 
Sergey.

Re: Git transition workflow

[Stefan Monnier]

>> There's one big difference here: in the merge case, all the state is
>> directly visible in the files,
> Not exactly, as staging area does have some hidden state.  That's why you
> need to "git add" a file after you resolve conflicts (unlike CVS).

Right, but that's only metadata.  In contrast in the rebase case, the
hidden info can include actual textual changes you've made to the files
(which have been temporarily removed, and will be (hopefully) reapplied
after (some number of) "git rebase --continue").


        Stefan

Re: Git transition workflow

[David Caldwell]

[-- Attachment #1: Type: text/plain, Size: 1686 bytes --]

On 8/13/14 7:16 AM, Sergey Organov wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
>>> 3. Merge conflicts, if any, as well as their resolution, are very
>>>    similar in both workflows. The only difference is that one needs to
>>>    learn to use "git rebase --continue" instead of "git commit" after
>>>    conflicts are resolved.
>>
>> …whereas for rebase, some of the state is stashed away in the .git
>> directory (hence the need to use "git rebase --continue" which fetches
>> the leftover state and keeps on processing it).
>>
>> It definitely takes some getting used it.
> 
> Yes, indeed, it's unnatural to use "git rebase --continue" to continue
> interrupted "git pull".

To git's credit, it at least prints that arcana out when you need it:

    $ git pull --rebase ../b
    remote: Counting objects: 3, done.
    remote: Total 3 (delta 0), reused 0 (delta 0)
    Unpacking objects: 100% (3/3), done.
    From ../b
     * branch            HEAD       -> FETCH_HEAD
    First, rewinding head to replay your work on top of it...
    Applying: a
    Using index info to reconstruct a base tree...
    M	a
    Falling back to patching base and 3-way merge...
    Auto-merging a
    CONFLICT (content): Merge conflict in a
    Failed to merge in the changes.
    Patch failed at 0001 a
    The copy of the patch that failed is found in:
       /private/tmp/a/.git/rebase-apply/patch

>   When you have resolved this problem, run "git rebase --continue".
>   If you prefer to skip this patch, run "git rebase --skip" instead.
>   To check out the original branch and stop rebasing, run "git rebase
>   --abort".

-David


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4219 bytes --]

Re: Git transition workflow

[Stephen J. Turnbull]

Sergey Organov writes:

 > 1. CVS in fact does the rebase

Great!  Plenty of git fans without a clue about what "workflow" means,
who are perfectly qualified to advocate making the same mistakes I did
in the CVS to Bazaar transition!

I can wash my hands of this now.  Enjoy the ride!

Steve

Re: Git transition workflow

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 526 bytes --]

For those of us with short memories could you remind us what position you
once advocated but now view as a mistake?

/john


On Wed, Aug 13, 2014 at 12:17 PM, Stephen J. Turnbull <stephen@xemacs.org>
wrote:

> Sergey Organov writes:
>
>  > 1. CVS in fact does the rebase
>
> Great!  Plenty of git fans without a clue about what "workflow" means,
> who are perfectly qualified to advocate making the same mistakes I did
> in the CVS to Bazaar transition!
>
> I can wash my hands of this now.  Enjoy the ride!
>
> Steve
>
>
>
>

[-- Attachment #2: Type: text/html, Size: 933 bytes --]

Re: Git transition workflow

[Stephen J. Turnbull]

John Yates writes:

 > For those of us with short memories could you remind us what
 > position you once advocated but now view as a mistake?

I've said what needed saying, four posts back in this thread.

Regards,

Re: Git transition workflow

[Achim Gratz]

Stephen J. Turnbull writes:
> I've said what needed saying, four posts back in this thread.

That posting, while already long seems to have been truncated midway.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Git transition workflow

[Stephen J. Turnbull]

Achim Gratz writes:
 > Stephen J. Turnbull writes:
 > > I've said what needed saying, four posts back in this thread.
 > 
 > That posting, while already long seems to have been truncated
 > midway.

It was intended to end "Take the improved VCS and leave workflow
changes for another day, please."

Re: Git transition workflow

[Sergey Organov]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> Sergey Organov writes:
>
>  > 1. CVS in fact does the rebase
>
> Great!  Plenty of git fans without a clue about what "workflow" means,
> who are perfectly qualified to advocate making the same mistakes I did
> in the CVS to Bazaar transition!

I'm sorry, I probably was just lucky to switch from cvs right to git
instead, avoiding the main mistake you made (or was forced to make)
altogether, though I did consider bzr at some point.

-- 
Sergey.

Re: Git transition workflow

[Michael Mattie]

On Thu, 14 Aug 2014 01:09:13 +0400
Sergey Organov <sorganov@gmail.com> wrote:

> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
> 
> > Sergey Organov writes:
> >
> >  > 1. CVS in fact does the rebase
> >
> > Great!  Plenty of git fans without a clue about what "workflow"
> > means, who are perfectly qualified to advocate making the same
> > mistakes I did in the CVS to Bazaar transition!
> 
> I'm sorry, I probably was just lucky to switch from cvs right to git
> instead, avoiding the main mistake you made (or was forced to make)
> altogether, though I did consider bzr at some point.
> 

Just a quick thought from the peanut gallery. It might really help
to create some git aliases based on the Emacs developers workflows
and some basic git usage.

a setup could create a local branch for the dev. a merge would
merge local branch to master etc...

The full git usage involves alot of options and commands and
the chatter from getting a basic workflow straightened out,
and cut & pasted into various places can be avoided largely.

Mike M

Re: Git transition workflow

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    ESR already took care of it:

I will take a look at them.  Thanks.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.