git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Salikh Zakirov <Salikh.Zakirov@Intel.com>
To: git@vger.kernel.org
Subject: Re: Did anyone have trouble learning the idea of local vs. remote branches?
Date: Tue, 07 Nov 2006 21:08:47 +0300	[thread overview]
Message-ID: <eiqi3f$ouq$1@sea.gmane.org> (raw)
In-Reply-To: <20061107172450.GA26591@spearce.org>

Shawn Pearce wrote:
> Clearly there is a gap in communicating these ideas in a way that
> they can be understood by users.  Of course in at least one case
> the users just isn't reading any Git documentation and plows ahead
> as though it were CVS ('cause everything's "just like CVS") *sigh*.

I've went through persuading my colleagues (~30 engineers) to use Git and tutoring on it
through the three summer months, and my experience is very similar to Shawn's.
(i.e. confusing local and remote branches, not reading documentation,
and "just like CVS" attitude)

Below is the one git feature that I think was stumbled upon most often:

* people were often anaware of *multiple* branches created by git-clone,
  as the operation they wanted was analog of "cvs checkout". 

* git-fetch / git-pull tries to download all of the branches that were
  preset at git-clone time, and subsequently gives errors if some topic
  branches were rewound or dropped, while most of the time my colleagues
  were interested in just one "mainline" branch.

I think that the particular issue with the workflow in my organization
could have been solved by the git-checkout and git-clone hybrid

    git-checkout ssh://path.to/repo.git#branch [work_dir]

which would clone repository with just one branch and setup the remotes
file accordingly (The syntax is completely made up, of course)

P.S. a few words on the workflow we use:
- there is a "mainline" branch of development, kept as ssh-shared git repository
- mainline commits require some pre-commit testing, which takes ~1.5 hours,
  so people tend not to commit to mainline too often. On average, a given
  person commits to mainline once or twice a week.
- mainlines commits also require a fellow developer review, that's where
  topic branches come in handy. Topic branches are also useful for testing,
  as pre-commit testing should be run on several different platforms, thus
  on a different machines. Topic branches are kept on the same shared server.

  reply	other threads:[~2006-11-07 18:09 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-07 17:24 Did anyone have trouble learning the idea of local vs. remote branches? Shawn Pearce
2006-11-07 18:08 ` Salikh Zakirov [this message]
2006-11-08  6:10   ` Shawn Pearce
2006-11-08  5:19 ` Matthieu Moy
2006-11-08 12:17   ` Andreas Ericsson
2006-11-08  5:23 ` Wink Saville
2006-11-08  7:29   ` Jakub Narebski
2006-11-08 16:40     ` Wink Saville
2006-11-08 17:36       ` Jakub Narebski

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

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

  git send-email \
    --in-reply-to='eiqi3f$ouq$1@sea.gmane.org' \
    --to=salikh.zakirov@intel.com \
    --cc=git@vger.kernel.org \
    /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.
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 NNTP newsgroup(s).