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