git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: unlisted-recipients:; (no To-header on input)
Cc: Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: Tracking of local branches
Date: Fri, 20 Mar 2009 17:13:35 +0100	[thread overview]
Message-ID: <49C3C0AF.6090806@drmicha.warpmail.net> (raw)
In-Reply-To: <49C3A6AE.7020104@drmicha.warpmail.net>

Michael J Gruber venit, vidit, dixit 20.03.2009 15:22:
> Hi there,
> 
> me again. In connection with Dscho's recent patch which rang the bell on
> tracked branches I noticed that local branches are treated somewhat
> inconsistently by git. There are 2 ways to fix it, and I ask you for
> your input on which one to choose.
> 
> First of all:
> The documentation seems to imply that it's okay to follow local
> branches, i.e. to have tracked local branches. Specifically, the option
> --track allows setting up tracking info (branch.foo.merge) in cases
> where it's not set up automatically (it is when you branch off a remote
> tracking branch).
> 
> If it's not OK to say "git checkout -b newbranch --track local" when
> local is a local branch you can stop reading here and tell me to stop
> writing...
> 
> Now, assuming it's okay to have a local branch being tracked, the
> current situation is:
> 
> git fetch/pull is okay (respects the setting)
> git status/checkout/rev-parse BEL is not (acts as if there is no
> tracking info)
> 
> I think I have tracked it down (pun intended) to the fact that one sort
> of commands looks at the struct member branch->merge, the other at
> branch->merge_name. The latter is set for branches which follow
> something, the former only for followers of remote branches.
> 
> I semi-successfully messed around in remote.c (format_tracking_info(),
> stat_tracking_info()) to make it use branch->merge_name rather than
> branch->merge. This makes "git status" work as expected ("Your branch
> is... severely screwed.") for tracked local branches. (It's messed up
> for remote ones but hey it was a first shot; merge[0]->dst is really
> needed here I guess.)
> 
> Now I could go after sha1_name.c and do the same,
> 
> OR
> 
> make it so that all branches have their merge member set up, uhm. Any
> possible side effects?
> 
> What do you think?
> Michael

OK, I think I got this working with approach 2 above. All existing tests
pass. Now I'll cook up tests which only my new code passes ;) But that
may take a few days.

Michael

  reply	other threads:[~2009-03-20 16:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-20 14:22 Tracking of local branches Michael J Gruber
2009-03-20 16:13 ` Michael J Gruber [this message]
2009-03-20 16:46 ` Junio C Hamano
2009-03-20 18:10   ` Daniel Barkalow
2009-03-26 20:53     ` [PATCH 0/2] Make local branches behave like remote branches when --tracked Michael J Gruber
2009-03-26 20:53       ` [PATCH 1/2] Test for local branches being followed with --track Michael J Gruber
2009-03-26 20:53         ` [PATCH 2/2] Make local branches behave like remote branches when --tracked Michael J Gruber
2009-03-27  8:08           ` Junio C Hamano
2009-03-27  8:47             ` Michael J Gruber
2009-03-27 16:20               ` Junio C Hamano
2009-03-27 16:52                 ` Michael J Gruber
2009-04-01 21:42                   ` [PATCHv2 0/2] " Michael J Gruber
2009-04-01 21:42                     ` [PATCHv2 1/2] Test for local branches being followed with --track Michael J Gruber
2009-04-01 21:42                       ` [PATCHv2 2/2] Make local branches behave like remote branches when --tracked Michael J Gruber
2009-03-26 20:57       ` [PATCH 0/2] " Michael J Gruber

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=49C3C0AF.6090806@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).