git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Kerry, Richard" <richard.kerry@atos.net>
To: Felipe Contreras <felipe.contreras@gmail.com>, Jeff King <peff@peff.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>,
	"Junio C Hamano" <gitster@pobox.com>
Subject: RE: [PATCH] branch: make -v useful
Date: Fri, 25 Jun 2021 15:03:51 +0000	[thread overview]
Message-ID: <AS8PR02MB7302119463FF6E69A58E82799C069@AS8PR02MB7302.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <60c18651e2e78_af4cf2086a@natae.notmuch>


> From: Felipe Contreras <felipe.contreras@gmail.com>
> Sent: 10 June 2021 04:26
> 
> Kerry, Richard wrote:
> > > Do you always push to the same remote branch you pull from?
> 
> > [RK] Yes.  There are two people doing most of the work , me and one
> other.  We each mostly:
> > [RK]  1.  Are not working on the same things.  Ie we don't generate
> > many conflicts [RK]  2.  Pull and push to the same branch.  Ie each of
> > us has a branch that we work on.  He uses "master", I have my own (It
> > is a single very long-lived branch - I know that isn't a recommended
> > workflow but that's where we are for the moment)
> 
> I call this a two-way workflow.
 
Ok, I'm  not sure I've heard of that.
But then I've not looked into options for workflow.  I've just adapted an existing one for Git.

> If I understand correctly each of you have your own branch, but you both pull
> and push to your corresponding branch (he to his branch, you to your
> branch).

Yes.

> > > How about rebasing or merging? Do you use the same remote branch?

See below....

> > [RK] Merges are infrequent, but because we are working in different areas,
> we merge to "our own" branch (few conflicts, usually) and push to its
> remote.
> 
> This is crucial. 

Is it ?

> Is the local and remote branch always the same?

Yes.

> In other words: do you always pull from "origin/topic", and push to "topic"?

Yes.

> Or do you sometimes pull from another branch?

No.  Just the same one each time.
Then occasionally merging to reconcile any areas where we have touched the same files.

> > [RK] I have never yet done a rebase, but need to do so soon as there is
> work in an area that we have both worked on.  Then it will be pushed to the
> usual place - ie the two branches mentioned above.
> 
> When you involve another branch is sounds like you will be in a triangular
> workflow.
> 
> You would be fetching from remote branch B, merging to local branch A, and
> pushing to a remote branch A.
> 
> > [RK] So basically, no, not triangular at all, if I understand the meaning of
> triangular (pull and push to different remotes).
> 
> No, once again: triangular workflow doesn't necessarily involve a different
> remote (although it usually does).
> 
> You can pull from branch B from a central repository, and push to branch A
> from the same repository, and that would be triangular, not two-way.
> 
> 
> It's understandable that users are confused about this--since in fact many
> developers are confused too. It would be nice if git had some documentation
> about the different workflows, alas it doesn't at the moment.
> 
> Basically in my view there are four workflows:
> 
>   1. Central - two-way: push and pull the same branches from the same
>      repo.
>   2. Distributed - two-way: push and pull the same branches, but from
>      different repositories (master <-> origin/master,
>      topic <-> github/topic)
>   3. Central - triangular: push and pull different branches from the
>      same repo.
>   4. Distributed - triangular: push and pull different branches from
>      different repositories.
> 
> It sounds to me you are mostly in #1, but soon dabbling into #3.
 
I think we are just doing #1.
We moved a few years ago from Subversion to Git.  Before that we were on CVS (actually CVSNT).  Those are centralized, with merging and branches allowed, but not different repos.
Originally all the work produced a single final product installer.  Since my work and his turned out to be on different release cycles it was changed so now there are two separate products.
My part has some dependencies on his, so I need occasionally to incorporate his changes into my branch.
I occasionally changes files that will go into his final product, so there is then the occasional merge from my branch to his.

Actually maybe there is some #3.
After merging his to mine, then mine back to his, I will push both.  Does that make it #3?

> Cheers.
> 
> Felipe Contreras

Regards,
Richard.


  reply	other threads:[~2021-06-25 15:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-05  1:13 [PATCH] branch: make -v useful Felipe Contreras
2021-06-05 20:18 ` Ævar Arnfjörð Bjarmason
2021-06-05 22:35   ` Jeff King
2021-06-07 15:57     ` Felipe Contreras
2021-06-08  6:13       ` Jeff King
2021-06-08  7:17         ` Felipe Contreras
2021-06-08  7:27           ` Jeff King
2021-06-08  8:28             ` Felipe Contreras
2021-06-08  9:06           ` Kerry, Richard
2021-06-08  9:22             ` Felipe Contreras
2021-06-08 11:32               ` Kerry, Richard
2021-06-10  3:26                 ` Felipe Contreras
2021-06-25 15:03                   ` Kerry, Richard [this message]
2021-06-25 16:03                     ` Felipe Contreras
2021-06-07 15:28   ` Felipe Contreras
2021-06-07 16:05     ` Ævar Arnfjörð Bjarmason
2021-06-07 18:00       ` Felipe Contreras
2021-06-07 18:37       ` Felipe Contreras

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AS8PR02MB7302119463FF6E69A58E82799C069@AS8PR02MB7302.eurprd02.prod.outlook.com \
    --to=richard.kerry@atos.net \
    --cc=avarab@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.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).