git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* git branch --edit-description a custom file
@ 2019-10-30 18:39 Denton Liu
  2019-10-30 20:28 ` Jeff King
  0 siblings, 1 reply; 21+ messages in thread
From: Denton Liu @ 2019-10-30 18:39 UTC (permalink / raw)
  To: Git Mailing List

Hi all,

It seems like everyone working on git.git has their own patch management
system. Currently, I keep all of my branch-specific configurations
(including CC lists) and patches in a worktree within the repo so that I
can keep my configs synced around on different computers.

One thing that's missing about this setup is that I would like to
version my branch descriptions as well since I use those to generate
cover letters. Unfortunately, `git branch --edit-description` only
operates on .git/config.

As a workaround, I rewrote `git branch --edit-description` as a
shell-script that can operate on any config file but I feel like a more
general solution should be warranted.

Would changing the option to `git branch --edit-description[=<config>]`
make sense, where the `<config>` is optional but if it's specified,
it'll operate on that file instead of the .git/config.

Alternately, would it make sense to support a $GIT_CONFIG environment
variable globally? That is, when $GIT_CONFIG is specified, git will
read/write from $GIT_CONFIG instead of .git/config? It'd be a little
heavy-handed for me to make the change just for this one use-case but
perhaps people may find other uses for it?

Thoughts?

-Denton

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-30 18:39 git branch --edit-description a custom file Denton Liu
@ 2019-10-30 20:28 ` Jeff King
  2019-10-30 22:43   ` Denton Liu
  0 siblings, 1 reply; 21+ messages in thread
From: Jeff King @ 2019-10-30 20:28 UTC (permalink / raw)
  To: Denton Liu; +Cc: Git Mailing List

On Wed, Oct 30, 2019 at 11:39:50AM -0700, Denton Liu wrote:

> It seems like everyone working on git.git has their own patch management
> system. Currently, I keep all of my branch-specific configurations
> (including CC lists) and patches in a worktree within the repo so that I
> can keep my configs synced around on different computers.
> 
> One thing that's missing about this setup is that I would like to
> version my branch descriptions as well since I use those to generate
> cover letters. Unfortunately, `git branch --edit-description` only
> operates on .git/config.
> 
> As a workaround, I rewrote `git branch --edit-description` as a
> shell-script that can operate on any config file but I feel like a more
> general solution should be warranted.
> 
> Would changing the option to `git branch --edit-description[=<config>]`
> make sense, where the `<config>` is optional but if it's specified,
> it'll operate on that file instead of the .git/config.

That makes sense to me (though I don't use branch descriptions myself).
I actually wish a lot of auto-written config (like branch.*.merge) was
written to a file besides .git/config, and then just included. It would
make it easier to keep your actual config file cleaner (I usually take
the opposite route and version-control my own config in a separate file
that I include from .git/config).

> Alternately, would it make sense to support a $GIT_CONFIG environment
> variable globally? That is, when $GIT_CONFIG is specified, git will
> read/write from $GIT_CONFIG instead of .git/config? It'd be a little
> heavy-handed for me to make the change just for this one use-case but
> perhaps people may find other uses for it?

We used to have such a thing, and it opened a lot of weird corner cases.
Just thinking about the case you mentioned: would people be confused if
"GIT_CONFIG=foo git branch --edit-description" doesn't respect
core.editor specified in .git/config?

-Peff

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-30 20:28 ` Jeff King
@ 2019-10-30 22:43   ` Denton Liu
  2019-10-31  6:18     ` Jeff King
  0 siblings, 1 reply; 21+ messages in thread
From: Denton Liu @ 2019-10-30 22:43 UTC (permalink / raw)
  To: Jeff King; +Cc: Git Mailing List

Hi Peff,

On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:
> On Wed, Oct 30, 2019 at 11:39:50AM -0700, Denton Liu wrote:
> 
> > It seems like everyone working on git.git has their own patch management
> > system. Currently, I keep all of my branch-specific configurations
> > (including CC lists) and patches in a worktree within the repo so that I
> > can keep my configs synced around on different computers.
> > 
> > One thing that's missing about this setup is that I would like to
> > version my branch descriptions as well since I use those to generate
> > cover letters. Unfortunately, `git branch --edit-description` only
> > operates on .git/config.

Dscho brought up in the GGG thread[1] that perhaps we want to treat
branch descriptions like notes and have them all under something like
`refs/notes/branches`. This would certainly solve my problem of
having versioned descriptions and it would probably do it in a much more
general way than having a versioned included config.

Anyone see any potential problems with this approach?

> > 
> > As a workaround, I rewrote `git branch --edit-description` as a
> > shell-script that can operate on any config file but I feel like a more
> > general solution should be warranted.
> > 
> > Would changing the option to `git branch --edit-description[=<config>]`
> > make sense, where the `<config>` is optional but if it's specified,
> > it'll operate on that file instead of the .git/config.
> 
> That makes sense to me (though I don't use branch descriptions myself).
> I actually wish a lot of auto-written config (like branch.*.merge) was
> written to a file besides .git/config, and then just included. It would
> make it easier to keep your actual config file cleaner (I usually take
> the opposite route and version-control my own config in a separate file
> that I include from .git/config).

Yeah, I've also wanted the same... I've thought about just symlinking
.git/config away but I think that causes other problems that I don't
want to deal with.

> 
> > Alternately, would it make sense to support a $GIT_CONFIG environment
> > variable globally? That is, when $GIT_CONFIG is specified, git will
> > read/write from $GIT_CONFIG instead of .git/config? It'd be a little
> > heavy-handed for me to make the change just for this one use-case but
> > perhaps people may find other uses for it?
> 
> We used to have such a thing, and it opened a lot of weird corner cases.
> Just thinking about the case you mentioned: would people be confused if
> "GIT_CONFIG=foo git branch --edit-description" doesn't respect
> core.editor specified in .git/config?

I found the original thread that removed the functionality[2]. I'm
probably not going to go with this approach since the notes approach
seems more promising but going back to your question, I think that would
make sense since by specifying GIT_CONFIG, a user is explicitly
overriding .git/config so they should also be aware of the consequences.

Thanks for your thoughts,

Denton

[1]: https://github.com/gitgitgadget/git/issues/438
[2]: https://public-inbox.org/git/alpine.LNX.1.00.0806300328380.19665@iabervon.org/

> 
> -Peff

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-30 22:43   ` Denton Liu
@ 2019-10-31  6:18     ` Jeff King
  2019-10-31 10:22       ` Johannes Schindelin
  2019-10-31 17:35       ` Denton Liu
  0 siblings, 2 replies; 21+ messages in thread
From: Jeff King @ 2019-10-31  6:18 UTC (permalink / raw)
  To: Denton Liu; +Cc: Git Mailing List

On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:

> On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:
> Dscho brought up in the GGG thread[1] that perhaps we want to treat
> branch descriptions like notes and have them all under something like
> `refs/notes/branches`. This would certainly solve my problem of
> having versioned descriptions and it would probably do it in a much more
> general way than having a versioned included config.
> 
> Anyone see any potential problems with this approach?

I don't think it would be `refs/notes/`, as that is assumed to contain
mappings of object ids (and if I understand correctly, this would be a
mapping of branch names to data.

You could just have "refs/meta/descriptions/foo" pointing to a blob
which contains the description of "refs/heads/foo". That makes it easy
to edit descriptions, even if you don't like using "git branch
--edit-description".

You could also have "refs/meta/descriptions" to point to a _single_ blob
with all of the descriptions. It could even be in the existing config
format. And then you could include it with "[include] blob = ...". That
doesn't exist yet, but it would be easy to add (it was something I had
always considered when writing the config-include code, but there was
never really a good use; and you do have to be careful about pointing to
untrusted blobs). That's a convoluted way to get where you want, but I
wonder if integrating to the existing config system would have any
benefits. I haven't really thought it through.

(Of course that's also only one step away from having a versioned config
file in your .git directory, but it might possibly be a bit easier to
manage, since it would always be committed).

That's mostly off-the-top-of-my-head rambling, so please disregard
anything that seems totally off-base. :)

-Peff

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31  6:18     ` Jeff King
@ 2019-10-31 10:22       ` Johannes Schindelin
  2019-10-31 11:00         ` Phillip Wood
  2019-10-31 18:19         ` Denton Liu
  2019-10-31 17:35       ` Denton Liu
  1 sibling, 2 replies; 21+ messages in thread
From: Johannes Schindelin @ 2019-10-31 10:22 UTC (permalink / raw)
  To: Jeff King; +Cc: Denton Liu, Git Mailing List

Hi Peff,

On Thu, 31 Oct 2019, Jeff King wrote:

> On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:
>
> > On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:
> > Dscho brought up in the GGG thread[1] that perhaps we want to treat
> > branch descriptions like notes and have them all under something like
> > `refs/notes/branches`. This would certainly solve my problem of
> > having versioned descriptions and it would probably do it in a much more
> > general way than having a versioned included config.
> >
> > Anyone see any potential problems with this approach?
>
> I don't think it would be `refs/notes/`, as that is assumed to contain
> mappings of object ids (and if I understand correctly, this would be a
> mapping of branch names to data.
>
> You could just have "refs/meta/descriptions/foo" pointing to a blob
> which contains the description of "refs/heads/foo". That makes it easy
> to edit descriptions, even if you don't like using "git branch
> --edit-description".

The only problem with this is that it's not really versioned, as it
would be hard to go back to previous versions and/or share the history
via pushing to a remote repository.

But I guess that a very simple pseudo branch would do it, where
`refs/meta/<branch-name>` would point to a commit that has a tree
with a single file in it: `description.txt`.

I now like that idea a lot better than my original notes idea.

Ciao,
Dscho

>
> You could also have "refs/meta/descriptions" to point to a _single_ blob
> with all of the descriptions. It could even be in the existing config
> format. And then you could include it with "[include] blob = ...". That
> doesn't exist yet, but it would be easy to add (it was something I had
> always considered when writing the config-include code, but there was
> never really a good use; and you do have to be careful about pointing to
> untrusted blobs). That's a convoluted way to get where you want, but I
> wonder if integrating to the existing config system would have any
> benefits. I haven't really thought it through.
>
> (Of course that's also only one step away from having a versioned config
> file in your .git directory, but it might possibly be a bit easier to
> manage, since it would always be committed).
>
> That's mostly off-the-top-of-my-head rambling, so please disregard
> anything that seems totally off-base. :)
>
> -Peff
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 10:22       ` Johannes Schindelin
@ 2019-10-31 11:00         ` Phillip Wood
  2019-10-31 11:30           ` Johannes Schindelin
  2019-10-31 18:19         ` Denton Liu
  1 sibling, 1 reply; 21+ messages in thread
From: Phillip Wood @ 2019-10-31 11:00 UTC (permalink / raw)
  To: Johannes Schindelin, Jeff King; +Cc: Denton Liu, Git Mailing List

Hi

On 31/10/2019 10:22, Johannes Schindelin wrote:
> Hi Peff,
> 
> On Thu, 31 Oct 2019, Jeff King wrote:
> 
>> On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:
>>
>>> On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:
>>> Dscho brought up in the GGG thread[1] that perhaps we want to treat
>>> branch descriptions like notes and have them all under something like
>>> `refs/notes/branches`. This would certainly solve my problem of
>>> having versioned descriptions and it would probably do it in a much more
>>> general way than having a versioned included config.
>>>
>>> Anyone see any potential problems with this approach?
>>
>> I don't think it would be `refs/notes/`, as that is assumed to contain
>> mappings of object ids (and if I understand correctly, this would be a
>> mapping of branch names to data.
>>
>> You could just have "refs/meta/descriptions/foo" pointing to a blob
>> which contains the description of "refs/heads/foo". That makes it easy
>> to edit descriptions, even if you don't like using "git branch
>> --edit-description".
> 
> The only problem with this is that it's not really versioned, as it
> would be hard to go back to previous versions and/or share the history
> via pushing to a remote repository.
> 
> But I guess that a very simple pseudo branch would do it, where
> `refs/meta/<branch-name>` would point to a commit that has a tree
> with a single file in it: `description.txt`.

Having some way to share branch metadata would be nice. I like the idea 
of using commits so we can merge changes and revert to a previous 
version. There is some previous discussion here [1]. I'd really like to 
be able to share the upstream for a branch between two computers as 
well. I also use a commit containing a tree with a single file stored at 
refs/todo/<branch> (and fetched to refs/remote/<remote>/todo/<branch>) 
to share todo lists with notes and ideas for future commits on branches 
that I'm working on on more than one machine. Having them version 
controlled so they can be merged has been useful.

Best Wishes

Phillip

[1] 
https://public-inbox.org/git/1519324188.6391.156.camel@mad-scientist.net/


> I now like that idea a lot better than my original notes idea.
> 
> Ciao,
> Dscho
> 
>>
>> You could also have "refs/meta/descriptions" to point to a _single_ blob
>> with all of the descriptions. It could even be in the existing config
>> format. And then you could include it with "[include] blob = ...". That
>> doesn't exist yet, but it would be easy to add (it was something I had
>> always considered when writing the config-include code, but there was
>> never really a good use; and you do have to be careful about pointing to
>> untrusted blobs). That's a convoluted way to get where you want, but I
>> wonder if integrating to the existing config system would have any
>> benefits. I haven't really thought it through.
>>
>> (Of course that's also only one step away from having a versioned config
>> file in your .git directory, but it might possibly be a bit easier to
>> manage, since it would always be committed).
>>
>> That's mostly off-the-top-of-my-head rambling, so please disregard
>> anything that seems totally off-base. :)
>>
>> -Peff
>>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 11:00         ` Phillip Wood
@ 2019-10-31 11:30           ` Johannes Schindelin
  2019-10-31 13:45             ` Philip Oakley
  0 siblings, 1 reply; 21+ messages in thread
From: Johannes Schindelin @ 2019-10-31 11:30 UTC (permalink / raw)
  To: phillip.wood; +Cc: Jeff King, Denton Liu, Git Mailing List

Hi Phillip,

On Thu, 31 Oct 2019, Phillip Wood wrote:

> On 31/10/2019 10:22, Johannes Schindelin wrote:
> >
> > On Thu, 31 Oct 2019, Jeff King wrote:
> >
> > > On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:
> > >
> > > > On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:
> > > > Dscho brought up in the GGG thread[1] that perhaps we want to treat
> > > > branch descriptions like notes and have them all under something like
> > > > `refs/notes/branches`. This would certainly solve my problem of
> > > > having versioned descriptions and it would probably do it in a much more
> > > > general way than having a versioned included config.
> > > >
> > > > Anyone see any potential problems with this approach?
> > >
> > > I don't think it would be `refs/notes/`, as that is assumed to contain
> > > mappings of object ids (and if I understand correctly, this would be a
> > > mapping of branch names to data.
> > >
> > > You could just have "refs/meta/descriptions/foo" pointing to a blob
> > > which contains the description of "refs/heads/foo". That makes it easy
> > > to edit descriptions, even if you don't like using "git branch
> > > --edit-description".
> >
> > The only problem with this is that it's not really versioned, as it
> > would be hard to go back to previous versions and/or share the history
> > via pushing to a remote repository.
> >
> > But I guess that a very simple pseudo branch would do it, where
> > `refs/meta/<branch-name>` would point to a commit that has a tree
> > with a single file in it: `description.txt`.
>
> Having some way to share branch metadata would be nice. I like the idea of
> using commits so we can merge changes and revert to a previous version. There
> is some previous discussion here [1]. I'd really like to be able to share the
> upstream for a branch between two computers as well. I also use a commit
> containing a tree with a single file stored at refs/todo/<branch> (and fetched
> to refs/remote/<remote>/todo/<branch>) to share todo lists with notes and
> ideas for future commits on branches that I'm working on on more than one
> machine. Having them version controlled so they can be merged has been useful.

And while we're dreaming: it would be nice to discern between "push
upstreams" and "base upstreams". Example: when I work on the
`fix-t5516-flakiness` branch, I target `upstream/master`, but I push to
`dscho`, i.e. my "push upstream" is `dscho/fix-t5516-flakiness`.

Ciao,
Dscho

> Best Wishes
>
> Phillip
>
> [1] https://public-inbox.org/git/1519324188.6391.156.camel@mad-scientist.net/
>
>
> > I now like that idea a lot better than my original notes idea.
> >
> > Ciao,
> > Dscho
> >
> > >
> > > You could also have "refs/meta/descriptions" to point to a _single_ blob
> > > with all of the descriptions. It could even be in the existing config
> > > format. And then you could include it with "[include] blob = ...". That
> > > doesn't exist yet, but it would be easy to add (it was something I had
> > > always considered when writing the config-include code, but there was
> > > never really a good use; and you do have to be careful about pointing to
> > > untrusted blobs). That's a convoluted way to get where you want, but I
> > > wonder if integrating to the existing config system would have any
> > > benefits. I haven't really thought it through.
> > >
> > > (Of course that's also only one step away from having a versioned config
> > > file in your .git directory, but it might possibly be a bit easier to
> > > manage, since it would always be committed).
> > >
> > > That's mostly off-the-top-of-my-head rambling, so please disregard
> > > anything that seems totally off-base. :)
> > >
> > > -Peff
> > >
>
>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 11:30           ` Johannes Schindelin
@ 2019-10-31 13:45             ` Philip Oakley
  2019-10-31 15:42               ` Jeff King
  0 siblings, 1 reply; 21+ messages in thread
From: Philip Oakley @ 2019-10-31 13:45 UTC (permalink / raw)
  To: Johannes Schindelin, phillip.wood; +Cc: Jeff King, Denton Liu, Git Mailing List

Hi,
On 31/10/2019 11:30, Johannes Schindelin wrote:
> And while we're dreaming: it would be nice to discern between "push
> upstreams" and "base upstreams". Example: when I work on the
> `fix-t5516-flakiness` branch, I target `upstream/master`, but I push to
> `dscho`, i.e. my "push upstream" is `dscho/fix-t5516-flakiness`.
>
> Ciao,
> Dscho
Yep, the triangular workflow of 'publish' v 'upstream' v 'local' is 
quite tricky. There is little user facing docs for that.

Many of my branches have the wrong "upstream" in the sense that it's the 
push-publish remote that holds copies of my work (i.e. I manually select 
the push-remote every time;-), even though the branches are set to track 
the original start point's upstream.

Philip

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 13:45             ` Philip Oakley
@ 2019-10-31 15:42               ` Jeff King
  2019-11-03 17:56                 ` Philip Oakley
  2019-11-04  3:21                 ` Junio C Hamano
  0 siblings, 2 replies; 21+ messages in thread
From: Jeff King @ 2019-10-31 15:42 UTC (permalink / raw)
  To: Philip Oakley
  Cc: Johannes Schindelin, phillip.wood, Denton Liu, Git Mailing List

On Thu, Oct 31, 2019 at 01:45:31PM +0000, Philip Oakley wrote:

> Hi,
> On 31/10/2019 11:30, Johannes Schindelin wrote:
> > And while we're dreaming: it would be nice to discern between "push
> > upstreams" and "base upstreams". Example: when I work on the
> > `fix-t5516-flakiness` branch, I target `upstream/master`, but I push to
> > `dscho`, i.e. my "push upstream" is `dscho/fix-t5516-flakiness`.
> > 
> > Ciao,
> > Dscho
> Yep, the triangular workflow of 'publish' v 'upstream' v 'local' is quite
> tricky. There is little user facing docs for that.
> 
> Many of my branches have the wrong "upstream" in the sense that it's the
> push-publish remote that holds copies of my work (i.e. I manually select the
> push-remote every time;-), even though the branches are set to track the
> original start point's upstream.

Do either of you use remote.pushDefault, branch.*.pushRemote, or
@{push}?

My triangular config for git.git looks like:

  [remote "origin"]
	url = https://github.com/gitster/git.git
  [remote "github"]
	url = https://github.com/peff/git.git
  [remote]
	pushDefault = github
  [branch "jk/foo"]
	remote = origin
	merge = refs/heads/master

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.

-Peff

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31  6:18     ` Jeff King
  2019-10-31 10:22       ` Johannes Schindelin
@ 2019-10-31 17:35       ` Denton Liu
  2019-10-31 18:06         ` Jeff King
  1 sibling, 1 reply; 21+ messages in thread
From: Denton Liu @ 2019-10-31 17:35 UTC (permalink / raw)
  To: Jeff King; +Cc: Git Mailing List

On Thu, Oct 31, 2019 at 02:18:32AM -0400, Jeff King wrote:
> On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:
> 
> > On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:
> > Dscho brought up in the GGG thread[1] that perhaps we want to treat
> > branch descriptions like notes and have them all under something like
> > `refs/notes/branches`. This would certainly solve my problem of
> > having versioned descriptions and it would probably do it in a much more
> > general way than having a versioned included config.
> > 
> > Anyone see any potential problems with this approach?
> 
> I don't think it would be `refs/notes/`, as that is assumed to contain
> mappings of object ids (and if I understand correctly, this would be a
> mapping of branch names to data.
> 
> You could just have "refs/meta/descriptions/foo" pointing to a blob
> which contains the description of "refs/heads/foo". That makes it easy
> to edit descriptions, even if you don't like using "git branch
> --edit-description".
> 
> You could also have "refs/meta/descriptions" to point to a _single_ blob
> with all of the descriptions. It could even be in the existing config
> format. And then you could include it with "[include] blob = ...". That
> doesn't exist yet, but it would be easy to add (it was something I had
> always considered when writing the config-include code, but there was
> never really a good use; and you do have to be careful about pointing to
> untrusted blobs). That's a convoluted way to get where you want, but I
> wonder if integrating to the existing config system would have any
> benefits. I haven't really thought it through.

I like the ability to include blobs for several reasons:

Main one is that it handles the versioned branch description problem.
But it goes further than that, there are a lot of config properties that
teams might want to share amongst each other. For example, whenever a
project has a custom smudge filter, usually they include some sort of
config in the project's README or some sort of setup script. With some
way to include a shared version of some config, this might be simpler.

> 
> (Of course that's also only one step away from having a versioned config
> file in your .git directory, but it might possibly be a bit easier to
> manage, since it would always be committed).
> 
> That's mostly off-the-top-of-my-head rambling, so please disregard
> anything that seems totally off-base. :)

Thanks for the discussion on this, I probably won't be implementing the
blob config stuff for the purpose of branch descriptions but I think
it's a good thing to think about.

> 
> -Peff

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 17:35       ` Denton Liu
@ 2019-10-31 18:06         ` Jeff King
  0 siblings, 0 replies; 21+ messages in thread
From: Jeff King @ 2019-10-31 18:06 UTC (permalink / raw)
  To: Denton Liu; +Cc: Git Mailing List

On Thu, Oct 31, 2019 at 10:35:07AM -0700, Denton Liu wrote:

> > You could also have "refs/meta/descriptions" to point to a _single_ blob
> > with all of the descriptions. It could even be in the existing config
> > format. And then you could include it with "[include] blob = ...". That
> > doesn't exist yet, but it would be easy to add (it was something I had
> > always considered when writing the config-include code, but there was
> > never really a good use; and you do have to be careful about pointing to
> > untrusted blobs). That's a convoluted way to get where you want, but I
> > wonder if integrating to the existing config system would have any
> > benefits. I haven't really thought it through.
> 
> I like the ability to include blobs for several reasons:
> 
> Main one is that it handles the versioned branch description problem.
> But it goes further than that, there are a lot of config properties that
> teams might want to share amongst each other. For example, whenever a
> project has a custom smudge filter, usually they include some sort of
> config in the project's README or some sort of setup script. With some
> way to include a shared version of some config, this might be simpler.

There are some past discussions on sharing config, and the security
issues around it. The crux of it is that you probably ought to be
vetting config you get from elsewhere (because it can execute arbitrary
code). At which point being able to refer to a blob isn't all _that_
useful, because these two processes are not all that different:

  git show origin/meta:shared-config
  # ok, looks good; _don't_ just include it by that name, though,
  # because it may be updated by a fetch
  git branch -f meta origin/meta
  git config include.blob meta:shared-config

  git show origin/meta:shared-config
  # ok, looks good
  git cat-file blob origin/meta:shared-config >.git/shared-config
  git config include.path shared-config

There's a specific discussion I'm thinking of which goes into this line
of thinking, but I'm having trouble finding it in the archive. But IIRC,
the conclusion was negative towards directly including the blob because
it doesn't make life better for careful users, and it makes it very easy
to be unsafe for non-careful users.

There's also some (negative) discussion in this much older subthread:

  https://public-inbox.org/git/20120126074208.GD30474@sigill.intra.peff.net/

-Peff

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 10:22       ` Johannes Schindelin
  2019-10-31 11:00         ` Phillip Wood
@ 2019-10-31 18:19         ` Denton Liu
  2019-10-31 19:53           ` Phillip Wood
  1 sibling, 1 reply; 21+ messages in thread
From: Denton Liu @ 2019-10-31 18:19 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Jeff King, Git Mailing List

Hi Dscho,

On Thu, Oct 31, 2019 at 11:22:16AM +0100, Johannes Schindelin wrote:
> Hi Peff,
> 
> On Thu, 31 Oct 2019, Jeff King wrote:
> 
> > On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:
> >
> > > On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:
> > > Dscho brought up in the GGG thread[1] that perhaps we want to treat
> > > branch descriptions like notes and have them all under something like
> > > `refs/notes/branches`. This would certainly solve my problem of
> > > having versioned descriptions and it would probably do it in a much more
> > > general way than having a versioned included config.
> > >
> > > Anyone see any potential problems with this approach?
> >
> > I don't think it would be `refs/notes/`, as that is assumed to contain
> > mappings of object ids (and if I understand correctly, this would be a
> > mapping of branch names to data.
> >
> > You could just have "refs/meta/descriptions/foo" pointing to a blob
> > which contains the description of "refs/heads/foo". That makes it easy
> > to edit descriptions, even if you don't like using "git branch
> > --edit-description".
> 
> The only problem with this is that it's not really versioned, as it
> would be hard to go back to previous versions and/or share the history
> via pushing to a remote repository.
> 
> But I guess that a very simple pseudo branch would do it, where
> `refs/meta/<branch-name>` would point to a commit that has a tree
> with a single file in it: `description.txt`.

So how would you envision the workflow for this? Would it be something
like,

	$ git checkout feature-1

	$ git branch --edit-description=ref # instead of =config
	# editor opens up, :wq

	# is it find to have an autogenerated commit message?
	$ git show refs/meta/feature-1
	commit 80dfea1dc4492aaabc80d23fbaffe86da55ee098 (refs/meta/feature-1)
	Author: Denton Liu <liu.denton@gmail.com>
	Date:   42 seconds ago

	    Update ref description

	diff --git a/description.txt b/description.txt
	new file mode 100644
	index 0000000..ed03a4b
	--- /dev/null
	+++ b/description.txt
	@@ -0,0 +1 @@
	+this is a description

I have some open questions about this, though:

* Since we're planning on sharing these descriptions with the outside
  world, how would the ref layout look like? If we're not using the
  refs/remotes namespace will it make fetching and merging notes harder?
  I know that collaborating with notes is a pain so how do we avoid
  making the same mistake?

* On the above point, what if local descriptions are at
  refs/meta/heads/feature-1 while remote descriptions are at
  refs/meta/remotes/*/feature-1?

* What would a merge workflow look like? Would we have wrapper commands
  for it or do users just have to checkout the description branch
  themselves?

Thanks,

Denton

> 
> I now like that idea a lot better than my original notes idea.
> 
> Ciao,
> Dscho

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 18:19         ` Denton Liu
@ 2019-10-31 19:53           ` Phillip Wood
  2019-10-31 20:07             ` Jeff King
  0 siblings, 1 reply; 21+ messages in thread
From: Phillip Wood @ 2019-10-31 19:53 UTC (permalink / raw)
  To: Denton Liu, Johannes Schindelin; +Cc: Jeff King, Git Mailing List

Hi Denton & Dscho

On 31/10/2019 18:19, Denton Liu wrote:
> Hi Dscho,
> 
> On Thu, Oct 31, 2019 at 11:22:16AM +0100, Johannes Schindelin wrote:
>> Hi Peff,
>>
>> On Thu, 31 Oct 2019, Jeff King wrote:
>>
>>> On Wed, Oct 30, 2019 at 03:43:28PM -0700, Denton Liu wrote:
>>>
>>>> On Wed, Oct 30, 2019 at 04:28:35PM -0400, Jeff King wrote:
>>>> Dscho brought up in the GGG thread[1] that perhaps we want to treat
>>>> branch descriptions like notes and have them all under something like
>>>> `refs/notes/branches`. This would certainly solve my problem of
>>>> having versioned descriptions and it would probably do it in a much more
>>>> general way than having a versioned included config.
>>>>
>>>> Anyone see any potential problems with this approach?
>>>
>>> I don't think it would be `refs/notes/`, as that is assumed to contain
>>> mappings of object ids (and if I understand correctly, this would be a
>>> mapping of branch names to data.
>>>
>>> You could just have "refs/meta/descriptions/foo" pointing to a blob
>>> which contains the description of "refs/heads/foo". That makes it easy
>>> to edit descriptions, even if you don't like using "git branch
>>> --edit-description".
>>
>> The only problem with this is that it's not really versioned, as it
>> would be hard to go back to previous versions and/or share the history
>> via pushing to a remote repository.
>>
>> But I guess that a very simple pseudo branch would do it, where
>> `refs/meta/<branch-name>` would point to a commit that has a tree
>> with a single file in it: `description.txt`.
> 
> So how would you envision the workflow for this? Would it be something
> like,
> 
> 	$ git checkout feature-1
> 
> 	$ git branch --edit-description=ref # instead of =config

Personally I'd prefer a config setting that meant --edit-description 
stored the description in a ref instead of the current config key (or 
perhaps as well as so format-patch can just get the latest branch 
description from the config key)

> 	# editor opens up, :wq
> 
> 	# is it find to have an autogenerated commit message?
> 	$ git show refs/meta/feature-1
> 	commit 80dfea1dc4492aaabc80d23fbaffe86da55ee098 (refs/meta/feature-1)
> 	Author: Denton Liu <liu.denton@gmail.com>
> 	Date:   42 seconds ago
> 
> 	    Update ref description
> 
> 	diff --git a/description.txt b/description.txt
> 	new file mode 100644
> 	index 0000000..ed03a4b
> 	--- /dev/null
> 	+++ b/description.txt
> 	@@ -0,0 +1 @@
> 	+this is a description
> 
> I have some open questions about this, though:
> 
> * Since we're planning on sharing these descriptions with the outside
>    world, how would the ref layout look like? If we're not using the
>    refs/remotes namespace will it make fetching and merging notes harder?
>    I know that collaborating with notes is a pain so how do we avoid
>    making the same mistake?

I'd love to see a consensus around putting remote versions of refs/foo 
under refs/remote/<remote-name>/foo. To share notes I add a refspec that 
fetches to refs/remote/<remote-name>/notes. It is a pain that 'git pull' 
wont merge them for me though.

> * On the above point, what if local descriptions are at
>    refs/meta/heads/feature-1 while remote descriptions are at
>    refs/meta/remotes/*/feature-1?
> 
> * What would a merge workflow look like? Would we have wrapper commands
>    for it or do users just have to checkout the description branch
>    themselves?

Teaching 'git pull' to (configurably) merge things under 
refs/remote/<remote-name>/foo to refs/foo would be a useful addition, 
then it could merge notes and any other refs people are sharing.

Best Wishes

Phillip


> Thanks,
> 
> Denton
> 
>>
>> I now like that idea a lot better than my original notes idea.
>>
>> Ciao,
>> Dscho

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 19:53           ` Phillip Wood
@ 2019-10-31 20:07             ` Jeff King
  2019-11-01 12:29               ` Phillip Wood
  2019-11-02  4:53               ` Junio C Hamano
  0 siblings, 2 replies; 21+ messages in thread
From: Jeff King @ 2019-10-31 20:07 UTC (permalink / raw)
  To: phillip.wood; +Cc: Denton Liu, Johannes Schindelin, Git Mailing List

On Thu, Oct 31, 2019 at 07:53:18PM +0000, Phillip Wood wrote:

> > So how would you envision the workflow for this? Would it be something
> > like,
> > 
> > 	$ git checkout feature-1
> > 
> > 	$ git branch --edit-description=ref # instead of =config
> 
> Personally I'd prefer a config setting that meant --edit-description stored
> the description in a ref instead of the current config key (or perhaps as
> well as so format-patch can just get the latest branch description from the
> config key)

Yes, a config option makes much more sense to me. Both the writers and
readers will need to know where to find the data.

> > * Since we're planning on sharing these descriptions with the outside
> >    world, how would the ref layout look like? If we're not using the
> >    refs/remotes namespace will it make fetching and merging notes harder?
> >    I know that collaborating with notes is a pain so how do we avoid
> >    making the same mistake?
> 
> I'd love to see a consensus around putting remote versions of refs/foo under
> refs/remote/<remote-name>/foo. To share notes I add a refspec that fetches
> to refs/remote/<remote-name>/notes. It is a pain that 'git pull' wont merge
> them for me though.

The trouble with that sort of scheme is that it conflicts with the
current namespace scheme, which puts the remote "notes" branch in
"refs/remotes/<remote-name>/notes". And it's not just a problem if you
want to have a branch called "notes". Think about what "git fetch
--prune" would do.

I do think the world would be a better place if we mapped (all or a
subset of) the remote "refs/" into "refs/remotes/<remote-name>/". I.e.,
really creating "refs/remotes/origin/heads" and even
"refs/remotes/origin/tags". But we'd need to re-adjust the way that some
ref lookups work (e.g., looking in refs/remotes/*/tags for tags).

There was some work by Johan Herland around the v1.8 time-frame, but it
stalled:

  https://public-inbox.org/git/AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com/

And here's some later discussion:

  https://public-inbox.org/git/CA+P7+xpj+8DZ=K0pna299Mu3nsQ4+JV_JUK=WFzzAFnJN+Bkbg@mail.gmail.com/

So in short, I agree very much with the direction you're discussing, but
I think there's some fundamental work that needs done first.

-Peff

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 20:07             ` Jeff King
@ 2019-11-01 12:29               ` Phillip Wood
  2019-11-01 16:49                 ` Jeff King
  2019-11-02  4:53               ` Junio C Hamano
  1 sibling, 1 reply; 21+ messages in thread
From: Phillip Wood @ 2019-11-01 12:29 UTC (permalink / raw)
  To: Jeff King, phillip.wood; +Cc: Denton Liu, Johannes Schindelin, Git Mailing List

Hi Peff

On 31/10/2019 20:07, Jeff King wrote:
> On Thu, Oct 31, 2019 at 07:53:18PM +0000, Phillip Wood wrote:
> [...]
>>
>> I'd love to see a consensus around putting remote versions of refs/foo under
>> refs/remote/<remote-name>/foo. To share notes I add a refspec that fetches
>> to refs/remote/<remote-name>/notes. It is a pain that 'git pull' wont merge
>> them for me though.
> 
> The trouble with that sort of scheme is that it conflicts with the
> current namespace scheme, which puts the remote "notes" branch in
> "refs/remotes/<remote-name>/notes". And it's not just a problem if you
> want to have a branch called "notes". Think about what "git fetch
> --prune" would do.

I was suggesting a convention of using refs/remote/ not refs/remotes/ 
for tracking remote refs that are not branches to avoid that problem. 
It's not ideal to have remote branches under a different namespace to 
all the other remote refs but it does avoid breaking current setups. I 
haven't thought it through but perhaps in the long run we could migrate 
remote branches to refs/remote/<remote-name>/heads/ and treat 
refs/remotes/<remote-name>/ as an alias for 
refs/remote/<remote-name>/heads/. As you say below we'd need to think 
about how to use remote tags as well.

> I do think the world would be a better place if we mapped (all or a
> subset of) the remote "refs/" into "refs/remotes/<remote-name>/". I.e.,
> really creating "refs/remotes/origin/heads" and even
> "refs/remotes/origin/tags". But we'd need to re-adjust the way that some
> ref lookups work (e.g., looking in refs/remotes/*/tags for tags).
> 
> There was some work by Johan Herland around the v1.8 time-frame, but it
> stalled:
> 
>    https://public-inbox.org/git/AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com/
> 
> And here's some later discussion:
> 
>    https://public-inbox.org/git/CA+P7+xpj+8DZ=K0pna299Mu3nsQ4+JV_JUK=WFzzAFnJN+Bkbg@mail.gmail.com/
> 
> So in short, I agree very much with the direction you're discussing, but
> I think there's some fundamental work that needs done first.

Thanks for the links, I'll have a read through them.

Best Wishes

Phillip

> -Peff
> 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-11-01 12:29               ` Phillip Wood
@ 2019-11-01 16:49                 ` Jeff King
  2019-11-01 20:35                   ` Phillip Wood
  0 siblings, 1 reply; 21+ messages in thread
From: Jeff King @ 2019-11-01 16:49 UTC (permalink / raw)
  To: phillip.wood; +Cc: Denton Liu, Johannes Schindelin, Git Mailing List

On Fri, Nov 01, 2019 at 12:29:43PM +0000, Phillip Wood wrote:

> > > I'd love to see a consensus around putting remote versions of refs/foo under
> > > refs/remote/<remote-name>/foo. To share notes I add a refspec that fetches
> > > to refs/remote/<remote-name>/notes. It is a pain that 'git pull' wont merge
> > > them for me though.
> > 
> > The trouble with that sort of scheme is that it conflicts with the
> > current namespace scheme, which puts the remote "notes" branch in
> > "refs/remotes/<remote-name>/notes". And it's not just a problem if you
> > want to have a branch called "notes". Think about what "git fetch
> > --prune" would do.
> 
> I was suggesting a convention of using refs/remote/ not refs/remotes/ for
> tracking remote refs that are not branches to avoid that problem. It's not
> ideal to have remote branches under a different namespace to all the other
> remote refs but it does avoid breaking current setups. I haven't thought it
> through but perhaps in the long run we could migrate remote branches to
> refs/remote/<remote-name>/heads/ and treat refs/remotes/<remote-name>/ as an
> alias for refs/remote/<remote-name>/heads/. As you say below we'd need to
> think about how to use remote tags as well.

Oh indeed, I totally missed that subtlety. Sorry.

> Thanks for the links, I'll have a read through them.

Maybe I've managed to trick you into working on the greater refs/remotes
organization problem, though. ;)

-Peff

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-11-01 16:49                 ` Jeff King
@ 2019-11-01 20:35                   ` Phillip Wood
  0 siblings, 0 replies; 21+ messages in thread
From: Phillip Wood @ 2019-11-01 20:35 UTC (permalink / raw)
  To: Jeff King, phillip.wood; +Cc: Denton Liu, Johannes Schindelin, Git Mailing List

Hi Peff

On 01/11/2019 16:49, Jeff King wrote:
> On Fri, Nov 01, 2019 at 12:29:43PM +0000, Phillip Wood wrote:
> 
>>>> I'd love to see a consensus around putting remote versions of refs/foo under
>>>> refs/remote/<remote-name>/foo. To share notes I add a refspec that fetches
>>>> to refs/remote/<remote-name>/notes. It is a pain that 'git pull' wont merge
>>>> them for me though.
>>>
>>> The trouble with that sort of scheme is that it conflicts with the
>>> current namespace scheme, which puts the remote "notes" branch in
>>> "refs/remotes/<remote-name>/notes". And it's not just a problem if you
>>> want to have a branch called "notes". Think about what "git fetch
>>> --prune" would do.
>>
>> I was suggesting a convention of using refs/remote/ not refs/remotes/ for
>> tracking remote refs that are not branches to avoid that problem. It's not
>> ideal to have remote branches under a different namespace to all the other
>> remote refs but it does avoid breaking current setups. I haven't thought it
>> through but perhaps in the long run we could migrate remote branches to
>> refs/remote/<remote-name>/heads/ and treat refs/remotes/<remote-name>/ as an
>> alias for refs/remote/<remote-name>/heads/. As you say below we'd need to
>> think about how to use remote tags as well.
> 
> Oh indeed, I totally missed that subtlety. Sorry.

I should have made the difference clearer, it's easy to miss the missing 
's'

>> Thanks for the links, I'll have a read through them.
> 
> Maybe I've managed to trick you into working on the greater refs/remotes
> organization problem, though. ;)

Maybe we'll see once I've read those threads next week!

Phillip
> -Peff
> 

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 20:07             ` Jeff King
  2019-11-01 12:29               ` Phillip Wood
@ 2019-11-02  4:53               ` Junio C Hamano
  1 sibling, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2019-11-02  4:53 UTC (permalink / raw)
  To: Jeff King; +Cc: phillip.wood, Denton Liu, Johannes Schindelin, Git Mailing List

Jeff King <peff@peff.net> writes:

> There was some work by Johan Herland around the v1.8 time-frame, but it
> stalled:
>
>   https://public-inbox.org/git/AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com/
>
> And here's some later discussion:
>
>   https://public-inbox.org/git/CA+P7+xpj+8DZ=K0pna299Mu3nsQ4+JV_JUK=WFzzAFnJN+Bkbg@mail.gmail.com/
>
> So in short, I agree very much with the direction you're discussing, but
> I think there's some fundamental work that needs done first.

Yes, I think this comes up from time to time in different guise.  I
thik the latest iteration is in the thread:

https://public-inbox.org/git/CA+P7+xpdYMA8L-_Y+W5q7_zbj9RNcH1erY=dVbDG-EDOiHhTwA@mail.gmail.com/

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 15:42               ` Jeff King
@ 2019-11-03 17:56                 ` Philip Oakley
  2019-11-04 19:50                   ` Jeff King
  2019-11-04  3:21                 ` Junio C Hamano
  1 sibling, 1 reply; 21+ messages in thread
From: Philip Oakley @ 2019-11-03 17:56 UTC (permalink / raw)
  To: Jeff King; +Cc: Johannes Schindelin, phillip.wood, Denton Liu, Git Mailing List

Hi Peff,

On 31/10/2019 15:42, Jeff King wrote:
> On Thu, Oct 31, 2019 at 01:45:31PM +0000, Philip Oakley wrote:
>
>> Hi,
>> On 31/10/2019 11:30, Johannes Schindelin wrote:
>>> And while we're dreaming: it would be nice to discern between "push
>>> upstreams" and "base upstreams". Example: when I work on the
>>> `fix-t5516-flakiness` branch, I target `upstream/master`, but I push to
>>> `dscho`, i.e. my "push upstream" is `dscho/fix-t5516-flakiness`.
>>>
>>> Ciao,
>>> Dscho
>> Yep, the triangular workflow of 'publish' v 'upstream' v 'local' is quite
>> tricky. There is little user facing docs for that.
>>
>> Many of my branches have the wrong "upstream" in the sense that it's the
>> push-publish remote that holds copies of my work (i.e. I manually select the
>> push-remote every time;-), even though the branches are set to track the
>> original start point's upstream.
> Do either of you use remote.pushDefault, branch.*.pushRemote, or
> @{push}?
I haven't been using those configs, and was only vaguely aware of them 
and what, if anything, they did (inc how to set them up _systematically_)

>
> My triangular config for git.git looks like:
>
>    [remote "origin"]
> 	url = https://github.com/gitster/git.git
>    [remote "github"]
> 	url = https://github.com/peff/git.git
>    [remote]
> 	pushDefault = github
>    [branch "jk/foo"]
> 	remote = origin
> 	merge = refs/heads/master

I had recently seen your <20190731055832.GA18039@sigill.intra.peff.net> 
(Wed, 31 Jul 2019 01:58:33 -0400) which mentioned your setting.
>
> 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 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).

-- 
Philip

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-10-31 15:42               ` Jeff King
  2019-11-03 17:56                 ` Philip Oakley
@ 2019-11-04  3:21                 ` Junio C Hamano
  1 sibling, 0 replies; 21+ messages in thread
From: Junio C Hamano @ 2019-11-04  3:21 UTC (permalink / raw)
  To: Jeff King
  Cc: Philip Oakley, Johannes Schindelin, phillip.wood, Denton Liu,
	Git Mailing List

Jeff King <peff@peff.net> writes:

> Do either of you use remote.pushDefault, branch.*.pushRemote, or
> @{push}?
>
> My triangular config for git.git looks like:
>
>   [remote "origin"]
> 	url = https://github.com/gitster/git.git
>   [remote "github"]
> 	url = https://github.com/peff/git.git
>   [remote]
> 	pushDefault = github
>   [branch "jk/foo"]
> 	remote = origin
> 	merge = refs/heads/master
>
> 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.

Yeah, I do recall we had quite a lot of design discussions around
"triangular" workflow when we introduced these facilities, and if I
am not mistaken, the above is the way they are designed to be used.

Thanks for an example.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: git branch --edit-description a custom file
  2019-11-03 17:56                 ` Philip Oakley
@ 2019-11-04 19:50                   ` Jeff King
  0 siblings, 0 replies; 21+ messages in thread
From: Jeff King @ 2019-11-04 19:50 UTC (permalink / raw)
  To: Philip Oakley
  Cc: Johannes Schindelin, phillip.wood, Denton Liu, Git Mailing List

On Sun, Nov 03, 2019 at 05:56:04PM +0000, Philip Oakley wrote:

> > 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

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2019-11-04 19:50 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-30 18:39 git branch --edit-description a custom file Denton Liu
2019-10-30 20:28 ` Jeff King
2019-10-30 22:43   ` Denton Liu
2019-10-31  6:18     ` Jeff King
2019-10-31 10:22       ` Johannes Schindelin
2019-10-31 11:00         ` Phillip Wood
2019-10-31 11:30           ` Johannes Schindelin
2019-10-31 13:45             ` Philip Oakley
2019-10-31 15:42               ` Jeff King
2019-11-03 17:56                 ` Philip Oakley
2019-11-04 19:50                   ` Jeff King
2019-11-04  3:21                 ` Junio C Hamano
2019-10-31 18:19         ` Denton Liu
2019-10-31 19:53           ` Phillip Wood
2019-10-31 20:07             ` Jeff King
2019-11-01 12:29               ` Phillip Wood
2019-11-01 16:49                 ` Jeff King
2019-11-01 20:35                   ` Phillip Wood
2019-11-02  4:53               ` Junio C Hamano
2019-10-31 17:35       ` Denton Liu
2019-10-31 18:06         ` Jeff King

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).