git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Tracking of local branches

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Mar 20, 2009, 14:22 UTC
Message-ID
<49C3A6AE.7020104@drmicha.warpmail.net>
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

Next: Michael J Gruber
Message 1 of 15 in “Tracking of local branches”
  1. Michael J GruberMar 20, 2009
  2. Michael J GruberMar 20, 2009
  3. Junio C HamanoMar 20, 2009
  4. Daniel BarkalowMar 20, 2009
  5. 0/2 Make local branches behave like remote branches when --trackedMichael J Gruber, Mar 26, 2009
  6. 1/2 Test for local branches being followed with --trackMichael J Gruber, Mar 26, 2009
  7. 2/2 Make local branches behave like remote branches when --trackedMichael J Gruber, Mar 26, 2009
  8. Junio C HamanoMar 27, 2009
  9. Michael J GruberMar 27, 2009
  10. Junio C HamanoMar 27, 2009
  11. Michael J GruberMar 27, 2009
  12. 0/2 Make local branches behave like remote branches when --trackedMichael J Gruber, Apr 1, 2009
  13. 1/2 Test for local branches being followed with --trackMichael J Gruber, Apr 1, 2009
  14. 2/2 Make local branches behave like remote branches when --trackedMichael J Gruber, Apr 1, 2009
  15. Michael J GruberMar 26, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.