unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Git transition workflow
@ 2014-08-11 11:36 Paul Michael Reilly
  2014-08-12  2:28 ` Stephen J. Turnbull
  2014-08-12  3:16 ` Richard Stallman
  0 siblings, 2 replies; 24+ messages in thread
From: Paul Michael Reilly @ 2014-08-11 11:36 UTC (permalink / raw)
  To: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Git transition workflow
  2014-08-11 11:36 Git transition workflow Paul Michael Reilly
@ 2014-08-12  2:28 ` Stephen J. Turnbull
  2014-08-12  2:58   ` Eric S. Raymond
  2014-08-12  3:16 ` Richard Stallman
  1 sibling, 1 reply; 24+ messages in thread
From: Stephen J. Turnbull @ 2014-08-12  2:28 UTC (permalink / raw)
  To: Paul Michael Reilly; +Cc: emacs-devel

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).



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-12  2:28 ` Stephen J. Turnbull
@ 2014-08-12  2:58   ` Eric S. Raymond
  2014-08-12  4:09     ` Paul Michael Reilly
  0 siblings, 1 reply; 24+ messages in thread
From: Eric S. Raymond @ 2014-08-12  2:58 UTC (permalink / raw)
  To: Stephen J. Turnbull; +Cc: Paul Michael Reilly, emacs-devel

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>



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-11 11:36 Git transition workflow Paul Michael Reilly
  2014-08-12  2:28 ` Stephen J. Turnbull
@ 2014-08-12  3:16 ` Richard Stallman
  2014-08-12  8:07   ` Rüdiger Sonderfeld
  1 sibling, 1 reply; 24+ messages in thread
From: Richard Stallman @ 2014-08-12  3:16 UTC (permalink / raw)
  To: Paul Michael Reilly; +Cc: emacs-devel

[[[ 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.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-12  2:58   ` Eric S. Raymond
@ 2014-08-12  4:09     ` Paul Michael Reilly
  2014-08-12  4:14       ` Eric S. Raymond
  0 siblings, 1 reply; 24+ messages in thread
From: Paul Michael Reilly @ 2014-08-12  4:09 UTC (permalink / raw)
  To: Eric Raymond; +Cc: Stephen J. Turnbull, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-12  4:09     ` Paul Michael Reilly
@ 2014-08-12  4:14       ` Eric S. Raymond
  0 siblings, 0 replies; 24+ messages in thread
From: Eric S. Raymond @ 2014-08-12  4:14 UTC (permalink / raw)
  To: Paul Michael Reilly; +Cc: Stephen J. Turnbull, emacs-devel

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>



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-12  3:16 ` Richard Stallman
@ 2014-08-12  8:07   ` Rüdiger Sonderfeld
  2014-08-12  8:33     ` Jan Nieuwenhuizen
  2014-08-13  3:56     ` Richard Stallman
  0 siblings, 2 replies; 24+ messages in thread
From: Rüdiger Sonderfeld @ 2014-08-12  8:07 UTC (permalink / raw)
  To: emacs-devel, rms; +Cc: Paul Michael Reilly

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




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-12  8:07   ` Rüdiger Sonderfeld
@ 2014-08-12  8:33     ` Jan Nieuwenhuizen
  2014-08-12 19:13       ` Achim Gratz
  2014-08-13  3:56     ` Richard Stallman
  1 sibling, 1 reply; 24+ messages in thread
From: Jan Nieuwenhuizen @ 2014-08-12  8:33 UTC (permalink / raw)
  To: Rüdiger Sonderfeld; +Cc: Paul Michael Reilly, rms, emacs-devel

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  



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-12  8:33     ` Jan Nieuwenhuizen
@ 2014-08-12 19:13       ` Achim Gratz
  2014-08-13  3:59         ` Stephen J. Turnbull
  0 siblings, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2014-08-12 19:13 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-12  8:07   ` Rüdiger Sonderfeld
  2014-08-12  8:33     ` Jan Nieuwenhuizen
@ 2014-08-13  3:56     ` Richard Stallman
  1 sibling, 0 replies; 24+ messages in thread
From: Richard Stallman @ 2014-08-13  3:56 UTC (permalink / raw)
  To: Rüdiger Sonderfeld; +Cc: pmr, emacs-devel

[[[ 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.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-12 19:13       ` Achim Gratz
@ 2014-08-13  3:59         ` Stephen J. Turnbull
  2014-08-13  4:14           ` Ashton Kemerling
  2014-08-13 10:30           ` Sergey Organov
  0 siblings, 2 replies; 24+ messages in thread
From: Stephen J. Turnbull @ 2014-08-13  3:59 UTC (permalink / raw)
  To: Achim Gratz; +Cc: emacs-devel

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 



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13  3:59         ` Stephen J. Turnbull
@ 2014-08-13  4:14           ` Ashton Kemerling
  2014-08-13 10:30           ` Sergey Organov
  1 sibling, 0 replies; 24+ messages in thread
From: Ashton Kemerling @ 2014-08-13  4:14 UTC (permalink / raw)
  To: Stephen J. Turnbull; +Cc: Achim Gratz, emacs-devel

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



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13  3:59         ` Stephen J. Turnbull
  2014-08-13  4:14           ` Ashton Kemerling
@ 2014-08-13 10:30           ` Sergey Organov
  2014-08-13 12:52             ` Stefan Monnier
  2014-08-13 16:17             ` Stephen J. Turnbull
  1 sibling, 2 replies; 24+ messages in thread
From: Sergey Organov @ 2014-08-13 10:30 UTC (permalink / raw)
  To: emacs-devel

"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.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 10:30           ` Sergey Organov
@ 2014-08-13 12:52             ` Stefan Monnier
  2014-08-13 14:16               ` Sergey Organov
  2014-08-13 16:17             ` Stephen J. Turnbull
  1 sibling, 1 reply; 24+ messages in thread
From: Stefan Monnier @ 2014-08-13 12:52 UTC (permalink / raw)
  To: Sergey Organov; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 12:52             ` Stefan Monnier
@ 2014-08-13 14:16               ` Sergey Organov
  2014-08-13 15:59                 ` Stefan Monnier
  2014-08-13 18:15                 ` David Caldwell
  0 siblings, 2 replies; 24+ messages in thread
From: Sergey Organov @ 2014-08-13 14:16 UTC (permalink / raw)
  To: emacs-devel

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.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 14:16               ` Sergey Organov
@ 2014-08-13 15:59                 ` Stefan Monnier
  2014-08-13 18:15                 ` David Caldwell
  1 sibling, 0 replies; 24+ messages in thread
From: Stefan Monnier @ 2014-08-13 15:59 UTC (permalink / raw)
  To: Sergey Organov; +Cc: emacs-devel

>> 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



^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 10:30           ` Sergey Organov
  2014-08-13 12:52             ` Stefan Monnier
@ 2014-08-13 16:17             ` Stephen J. Turnbull
  2014-08-13 16:28               ` John Yates
  2014-08-13 21:09               ` Sergey Organov
  1 sibling, 2 replies; 24+ messages in thread
From: Stephen J. Turnbull @ 2014-08-13 16:17 UTC (permalink / raw)
  To: Sergey Organov; +Cc: emacs-devel

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





^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 16:17             ` Stephen J. Turnbull
@ 2014-08-13 16:28               ` John Yates
  2014-08-13 17:16                 ` Stephen J. Turnbull
  2014-08-13 21:09               ` Sergey Organov
  1 sibling, 1 reply; 24+ messages in thread
From: John Yates @ 2014-08-13 16:28 UTC (permalink / raw)
  To: Stephen J. Turnbull; +Cc: Sergey Organov, Emacs developers

[-- 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 --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 16:28               ` John Yates
@ 2014-08-13 17:16                 ` Stephen J. Turnbull
  2014-08-13 17:20                   ` Achim Gratz
  0 siblings, 1 reply; 24+ messages in thread
From: Stephen J. Turnbull @ 2014-08-13 17:16 UTC (permalink / raw)
  To: John Yates; +Cc: Sergey Organov, Emacs developers

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,




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 17:16                 ` Stephen J. Turnbull
@ 2014-08-13 17:20                   ` Achim Gratz
  2014-08-13 18:34                     ` Stephen J. Turnbull
  0 siblings, 1 reply; 24+ messages in thread
From: Achim Gratz @ 2014-08-13 17:20 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 14:16               ` Sergey Organov
  2014-08-13 15:59                 ` Stefan Monnier
@ 2014-08-13 18:15                 ` David Caldwell
  1 sibling, 0 replies; 24+ messages in thread
From: David Caldwell @ 2014-08-13 18:15 UTC (permalink / raw)
  To: Sergey Organov, emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 17:20                   ` Achim Gratz
@ 2014-08-13 18:34                     ` Stephen J. Turnbull
  0 siblings, 0 replies; 24+ messages in thread
From: Stephen J. Turnbull @ 2014-08-13 18:34 UTC (permalink / raw)
  To: Achim Gratz; +Cc: emacs-devel

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."




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 16:17             ` Stephen J. Turnbull
  2014-08-13 16:28               ` John Yates
@ 2014-08-13 21:09               ` Sergey Organov
  2014-08-14 10:44                 ` Michael Mattie
  1 sibling, 1 reply; 24+ messages in thread
From: Sergey Organov @ 2014-08-13 21:09 UTC (permalink / raw)
  To: emacs-devel

"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.




^ permalink raw reply	[flat|nested] 24+ messages in thread

* Re: Git transition workflow
  2014-08-13 21:09               ` Sergey Organov
@ 2014-08-14 10:44                 ` Michael Mattie
  0 siblings, 0 replies; 24+ messages in thread
From: Michael Mattie @ 2014-08-14 10:44 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 24+ messages in thread

end of thread, other threads:[~2014-08-14 10:44 UTC | newest]

Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-11 11:36 Git transition workflow Paul Michael Reilly
2014-08-12  2:28 ` Stephen J. Turnbull
2014-08-12  2:58   ` Eric S. Raymond
2014-08-12  4:09     ` Paul Michael Reilly
2014-08-12  4:14       ` Eric S. Raymond
2014-08-12  3:16 ` Richard Stallman
2014-08-12  8:07   ` Rüdiger Sonderfeld
2014-08-12  8:33     ` Jan Nieuwenhuizen
2014-08-12 19:13       ` Achim Gratz
2014-08-13  3:59         ` Stephen J. Turnbull
2014-08-13  4:14           ` Ashton Kemerling
2014-08-13 10:30           ` Sergey Organov
2014-08-13 12:52             ` Stefan Monnier
2014-08-13 14:16               ` Sergey Organov
2014-08-13 15:59                 ` Stefan Monnier
2014-08-13 18:15                 ` David Caldwell
2014-08-13 16:17             ` Stephen J. Turnbull
2014-08-13 16:28               ` John Yates
2014-08-13 17:16                 ` Stephen J. Turnbull
2014-08-13 17:20                   ` Achim Gratz
2014-08-13 18:34                     ` Stephen J. Turnbull
2014-08-13 21:09               ` Sergey Organov
2014-08-14 10:44                 ` Michael Mattie
2014-08-13  3:56     ` Richard Stallman

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).