All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Roskin <proski@gnu.org>
To: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Cc: Petr Baudis <pasky@suse.cz>, git@vger.kernel.org
Subject: Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
Date: Fri, 11 Nov 2005 10:26:31 -0500	[thread overview]
Message-ID: <1131722791.1284.20.camel@dv> (raw)
In-Reply-To: <200511111522.37979.Josef.Weidendorfer@gmx.de>

On Fri, 2005-11-11 at 15:22 +0100, Josef Weidendorfer wrote:
> On Friday 11 November 2005 05:53, Pavel Roskin wrote:
> > I'm not sure if we understand each other, but "recorded" refers to
> > automatically determined branch name.  If cg-clone can determine the
> > branch name, that name should be saved and used for updates.
> > 
> > Whether the branch name is saved in .git/branches/ using hash notation
> > (old style) or in .git/remotes/ (new style) is irrelevant.
> 
> Yes.
> But for the conrete implementation it is relevant.
> 
> AFAIK, there is not really a "new" and "old" style, but more the
> git way (attributes for remote repositories in .git/remotes) and the
> Cogito way (attributes for a remote branch).

Switching to the "git way" is long overdue, since hashes can be used in
the actual path.

> "Recording" talks about storing the name of the remote branch that
> maps to the local "origin" branch, so I would vote for storing this
> in .git/branches/origin.

Yes, cg-clone should do its best to determine the branch name and to
save it for future use by cg-fetch.

> For cg-clone, this is no problem because cg-clone writes this file itself.
> Another thing is if you add later on a remote branch with cg-branch-add
> without specifying a concrete remote branch name. Do we want the
> record the branch name at the first cg-fetch for the future?

Good that you noticed that.

cg-fetch could do that, but maybe cg-branch-add would be an even better
place for that?  I mean, cg-branch-add could actually check the
repository and prompt the user which branch to use if there is no
obvious default.  I think, there should be a way to run cg-branch-add
without having it connect the repository or prompt the user, but the
default should be user-friendly.

-- 
Regards,
Pavel Roskin

  reply	other threads:[~2005-11-11 15:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-23 21:33 [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD Pavel Roskin
2005-11-10 19:24 ` Petr Baudis
2005-11-10 20:11   ` Pavel Roskin
2005-11-10 23:26 ` Josef Weidendorfer
2005-11-10 23:40   ` Petr Baudis
2005-11-10 23:56     ` Josef Weidendorfer
2005-11-11  0:09       ` Petr Baudis
2005-11-11  0:14     ` Pavel Roskin
2005-11-11  1:13       ` Josef Weidendorfer
2005-11-11  4:53         ` Pavel Roskin
2005-11-11 14:22           ` Josef Weidendorfer
2005-11-11 15:26             ` Pavel Roskin [this message]
2005-11-11 16:10               ` Josef Weidendorfer

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=1131722791.1284.20.camel@dv \
    --to=proski@gnu.org \
    --cc=Josef.Weidendorfer@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.