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

Re: git branch --edit-description a custom file

From
Jeff King <peff@peff.net>
Date
Nov 4, 2019, 19:50 UTC
Message-ID
<20191104195053.GA20900@sigill.intra.peff.net>
In-Reply-To
<49625b39-61dc-f702-eeba-9bdec60a42d1@iee.email>
On Sun, Nov 03, 2019 at 05:56:04PM +0000, Philip Oakley wrote:
Show 14 quoted lines
> > Then upstream comparisons, "git rebase" etc without arguments, do what I
> > want: compare against master. And "git push" without arguments does what
> > I want: push this branch to my fork. And if I need to refer to the
> > pushed version for some reason (e.g., comparing what I just changed to
> > what I last sent out, "git range-diff @{u} @{push} HEAD" does the right
> > thing.
> 
> I am trying to write myself some 'user' based notes covering the
> publish-backup-collaborate-upstream viewpoints of the different repo
> settings as the config pages rarely give that viewpoint (hence my bad
> setup).
> 
> There's also still the 'triangle' workflow to clarify - does it refer to
> patch based flow, or to a three-way repo config?

I think it's solely about the three-way repo config. The key thing is that "somehow" the commits I push to my fork end up in the upstream repository. In git.git, that happens via the mailing list workflow. But in projects based on GitHub, it's cross-fork pull requests. I guess in a project like linux.git, it could even via real "git pull" commands.

But in any of those cases, the config I showed would be what you want. (I forgot to show that I also set push.default to "current", since the default "simple" wouldn't make much sense).

> I suspect there are more configs that need setting up for a proper stable
> user experience (e.g. the merge setting of '--ff-only' when the local branch
> "--follow"s the upstream but should never have local changes).

Possibly. I don't actually keep a regular "master" branch in my local clone. I use "origin/master" as the upstream base for my branches, and for when I need to test the current vanilla behavior to reproduce a bug (I just "git checkout origin/master" and work on a detached HEAD).

If you did keep such a branch, though, then yeah, I think you'd want to use --ff-only, because it's just tracking upstream.

-Peff
Previous: Philip OakleyNext: Junio C Hamano
Message 11 of 21 in “git branch --edit-description a custom file”
  1. Denton LiuOct 30, 2019
  2. Jeff KingOct 30, 2019
  3. Denton LiuOct 30, 2019
  4. Jeff KingOct 31, 2019
  5. Johannes SchindelinOct 31, 2019
  6. Phillip WoodOct 31, 2019
  7. Johannes SchindelinOct 31, 2019
  8. Philip OakleyOct 31, 2019
  9. Jeff KingOct 31, 2019
  10. Philip OakleyNov 3, 2019
  11. Jeff KingNov 4, 2019
  12. Junio C HamanoNov 4, 2019
  13. Denton LiuOct 31, 2019
  14. Phillip WoodOct 31, 2019
  15. Jeff KingOct 31, 2019
  16. Phillip WoodNov 1, 2019
  17. Jeff KingNov 1, 2019
  18. Phillip WoodNov 1, 2019
  19. Junio C HamanoNov 2, 2019
  20. Denton LiuOct 31, 2019
  21. Jeff KingOct 31, 2019

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.