[PATCH] gitk: use right colour for remote refs in the "Tags and heads" dialog

[Paul Wise]

Makes it easier to see which refs are local and which refs are remote.
Adds consistency with the remote background colour in the graph display.

Signed-off-by: Paul Wise <pa...@bonedaddy.net>
---
 gitk-git/gitk | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index a14d7a16b..14aebc23e 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -3404,6 +3404,8 @@ set rectmask {
 }
 image create bitmap reficon-H -background black -foreground "#00ff00" \
 -data $rectdata -maskdata $rectmask
+image create bitmap reficon-R -background black -foreground "#ffddaa" \
+-data $rectdata -maskdata $rectmask
 image create bitmap reficon-o -background black -foreground "#ff" \
 -data $rectdata -maskdata $rectmask
 
@@ -10022,6 +10024,7 @@ proc sel_reflist {w x y} {
 set n [lindex $ref 0]
 switch -- [lindex $ref 1] {
"H" {selbyid $headids($n)}
+   "R" {selbyid $headids($n)}
"T" {selbyid $tagids($n)}
"o" {selbyid $otherrefids($n)}
 }
@@ -10051,7 +10054,11 @@ proc refill_reflist {} {
 foreach n [array names headids] {
if {[string match $reflistfilter $n]} {
if {[commitinview $headids($n) $curview]} {
-   lappend refs [list $n H]
+   if {[string match "remotes/*" $n]} {
+   lappend refs [list $n R]
+   } else {
+   lappend refs [list $n H]
+   }
} else {
interestedin $headids($n) {run refill_reflist}
}
-- 
2.11.0

Re: idea: light-weight pull requests

[Paul Wise]

On Tue, 2017-02-07 at 03:11 +, Eric Wong wrote:

> How would discussion and review happen?  People seem to use
> either mail, or centralized messaging (and the latter often
> involves non-Free systems like GitHub or Slack).

It would depend on the setup for the particular repo. Information about
where that happens could be part of the output of the git push.

> This is a big one.  Maybe CRM114 or another generic/trainable
> option can be made usable; but I think there'll always be cases
> where hardcoded rules need to be written (for SpamAssassin,
> at least) and real-time blacklists need to be checked.

TBH, I doubt spam would become a problem at all.

> Anyways, I ultimately decided it would be better to continue
> supporting and improving email (which is at least entrenched in
> a few communities, like this one), rather than trying to get
> people to adopt something new.

Email is great for people used to the old ways but it is gradually
being replaced by APIs and web interfaces :(

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part

Re: idea: light-weight pull requests

[Paul Wise]

On Mon, 2017-02-06 at 19:57 -0500, Santiago Torres wrote:

> IMHO, the notion of a PR/MR is more specific to Git repository
> management tools (e.g., GitHub, GitLab). They all have specific
> concepts/ways to manage the way how their hosted repositories behave ---
> and I believe this flexibility is one of the beauties in Git . I could
> see how this could be implemented by tools like this rather easily
> (e.g., using symlinks + inotify or something less hacky).

Right, but I would like to see this everywhere (including kernel.org),
so support in git-daemon and the http/ssh equivalents is needed too.
git already has support for anonymous push but this idea is more complex.

> I'm wondering if standardizing this would be more interesting to those
> communities?

I've pitched this to github.com/contact but couldn't find any feature
request address for GitLab.

> I would like to see what becomes of this.

Likewise :)

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part

idea: light-weight pull requests

[Paul Wise]

Hi all,

I had an idea that might be interesting to git folks:

light-weight pull requests:

Anonymous and ssh/http-identified users should be able to push just
using git, within the refs/pull/ namespace, to any non-existent branch
name or to a branch they created when previously identified, without
forking off a new repository.

Advantages:

Removes the need to look up who to send the pull request notification
to since configuring that is up to the project itself.

Removes the annoying scenario of having lots of remotes that have been
removed after the corresponding pull request was closed.

Moves popular git hosting services from primarily a model of forests of
forks to one of contributions to well maintained ongoing projects.

Allows users to use their preferred git clients to issue pull requests
instead of using web interfaces of popular git hosting services.

Creates a new standard for contributing to repositories on all git
repository hosting services.

Contributions from people without an account on those services are
possible.

Contributions from people without any git repository hosting of their
own are possible.

Contributions from people who don't use or dislike MUAs are possible.

Disadvantages:

Pull request spam, could be mitigated with configuration options.

Extra configuration and complexity on the server side. This is once
only and means less complexity on the pull requester side.

Will not work with typical setups where the git/http/ssh user does not
have write access to the repositories. A workaround could be some sort
of hybrid-repository setup with the new refs and objects in a second
repository which would be shared by all pull requesters.

-- 
bye,
pabs

http://bonedaddy.net/pabs3/

signature.asc
Description: This is a digitally signed message part

[PATCH] gitk: use right colour for remote refs in the "Tags and heads" dialog

[Paul Wise]

Makes it easier to see which refs are local and which refs are remote.
Adds consistency with the remote background colour in the graph display.

Signed-off-by: Paul Wise <pa...@bonedaddy.net>
---
 gitk-git/gitk | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index a14d7a16b..14aebc23e 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -3404,6 +3404,8 @@ set rectmask {
 }
 image create bitmap reficon-H -background black -foreground "#00ff00" \
 -data $rectdata -maskdata $rectmask
+image create bitmap reficon-R -background black -foreground "#ffddaa" \
+-data $rectdata -maskdata $rectmask
 image create bitmap reficon-o -background black -foreground "#ff" \
 -data $rectdata -maskdata $rectmask
 
@@ -10022,6 +10024,7 @@ proc sel_reflist {w x y} {
 set n [lindex $ref 0]
 switch -- [lindex $ref 1] {
"H" {selbyid $headids($n)}
+   "R" {selbyid $headids($n)}
"T" {selbyid $tagids($n)}
"o" {selbyid $otherrefids($n)}
 }
@@ -10051,7 +10054,11 @@ proc refill_reflist {} {
 foreach n [array names headids] {
if {[string match $reflistfilter $n]} {
if {[commitinview $headids($n) $curview]} {
-   lappend refs [list $n H]
+   if {[string match "remotes/*" $n]} {
+   lappend refs [list $n R]
+   } else {
+   lappend refs [list $n H]
+   }
} else {
interestedin $headids($n) {run refill_reflist}
}
-- 
2.11.0

[PATCH] gitk: use right colour for remote refs in the "Tags and heads" dialog

[Paul Wise]

Makes it easier to see which refs are local and which refs are remote.
Adds consistency with the remote background colour in the graph display.

Signed-off-by: Paul Wise <pa...@bonedaddy.net>
---
 gitk-git/gitk | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/gitk-git/gitk b/gitk-git/gitk
index 805a1c703..8d2868148 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -3399,6 +3399,8 @@ set rectmask {
 }
 image create bitmap reficon-H -background black -foreground lime \
 -data $rectdata -maskdata $rectmask
+image create bitmap reficon-R -background black -foreground "#ffddaa" \
+-data $rectdata -maskdata $rectmask
 image create bitmap reficon-o -background black -foreground "#ff" \
 -data $rectdata -maskdata $rectmask
 
@@ -9908,6 +9910,7 @@ proc sel_reflist {w x y} {
 set n [lindex $ref 0]
 switch -- [lindex $ref 1] {
"H" {selbyid $headids($n)}
+   "R" {selbyid $headids($n)}
"T" {selbyid $tagids($n)}
"o" {selbyid $otherrefids($n)}
 }
@@ -9937,7 +9940,11 @@ proc refill_reflist {} {
 foreach n [array names headids] {
if {[string match $reflistfilter $n]} {
if {[commitinview $headids($n) $curview]} {
-   lappend refs [list $n H]
+   if {[string match "remotes/*" $n]} {
+   lappend refs [list $n R]
+   } else {
+   lappend refs [list $n H]
+   }
} else {
interestedin $headids($n) {run refill_reflist}
}
-- 
2.11.0

Re: [PATCH] fetch: only show "Fetching remote" when verbose mode is enabled

[Paul Wise]

On Sun, 2015-10-25 at 11:34 -0700, Junio C Hamano wrote:

> I ignored your patch when you sent it the first time the last week,
> due to the same issues I had with this round (see below) and forgot
> about it.

Thanks for the feedback this round.


> I cannot tell if you are trying to say if that is problematic, or if
> you are trying to say if it is a good thing.

It is just a description of the current behaviour when fetching a
single remote and is used as a justification for changing the behaviour
when fetching multiple remotes to match the behaviour when fetching a
single remote, because that suits my myrepos use-case better.

> I cannot tell what "This" refers to.

Replace "This" with "This patch".

> Your earlier sentence was about the behaviour of fetching from one
> remote, e.g. "git fetch this".  And this second sentence makes it
> sound as if that behaviour has some influence on how verbosely "git
> fetch group" (where 'this' and 'that' are members of 'remotes.group')
> to fetch from multiple remotes behaves.

There is no correlation between the verbosity of fetching one remote
and fetching multiple remotes but I would like them to have the same
verbosity level by default. I would like the default verbosity level to
be to not print anything when nothing was fetched. This is the default
verbosity level for fetching a single remote but not multiple remotes.

> Also (and this is the more important part of my complaint), I cannot
> tell if you are saying that it is *bad* for fetching multiple to be
> just as verbose, or if it is *good*, or what.

I think it is good, as long as they both default to printing nothing
when no commits/tags/etc were fetched.

> If you are fetching from two places, and only one of them has
> something new, you would see

I am not interested in that case, only in the case where multiple
remotes are being fetched and no commits/tags/etc were fetched,
essentially I want to turn this output:

$ git fetch --all
Fetching origin
Fetching mirror

Into this output:

$ git fetch --all

> That does not sound like a valid excuse to change the behaviour of
> the command everybody, not just "myrepos tool" (whatever it is),
> uses.  Your explanation does not seem to give us enough information
> to answer this question intelligently: shouldn't you be fixing
> myrepos instead, perhaps by making it run 'git fetch' with more
> verbose mode, if it wants to see more information, or running 'git
> fetch' and parsing different parts of its output?

myrepos is a tool for managing multiple repos of different types:

https://myrepos.branchable.com/

It definitely wouldn't be appropriate to add screen scraping and
parsing of different version control systems to myrepos.

myrepos doesn't care about the output of repository tools beyond
whether there was any output or not. myrepos will pass --verbose and
other flags on to git fetch if the user passes --verbose to it.

> Having said all that, this time I read the change and the change
> itself feels 40% sensible, even for those who do not care about
> "myrepos" at all.
All I want is for "Fetching remote" to not be printed when there are no
changes fetched and I haven't used the --verbose option.

I realise now that my patch is actually incorrect in that it also
suppresses "Fetching remote" messages when some changes were fetched.

I will come back with a correct patch that is better explained.

> I'd sell it like the attached, if I were doing this patch.  The last
> paragraph is where the remaining 60% went ;-)

Thanks, I will try to re-use that for the next patch.

> Note that the current output was deliberately designed like this to
> give an easy reminder for the user what the components of 'group'
> are.  With this change, we are selfishly and unilaterally breaking a
> feature that was designed to help them, but if they strongly care,
> they can complain and revert this change.

To be honest I didn't know this group feature existed and I am
surprised that anyone would want anything other than --all.

I am not sure what the solution here is but perhaps the behaviour
demonstrated below is acceptable to users of this feature:

# When no changes were fetched
$ git fetch group

# When some changes were fetched
$ git fetch group
Fetched origin
From
git://one.of.the.places.xz/
   aadb70a..74301d6  master ->
this/master
No changes from someone someoneelse otherperson

# When no changes were fetched in verbose mode
$ git fetch --verbose group
Fetching origin
Fetching someone
Fetching someoneelse
Fetching otherperson

# When some changes were fetched in verbose mode
$ git fetch --verbose group
Fetching origin
From git://one.of.the.places.xz/
   aadb70a..74301d6  master -> this/master
Fetching someone
Fetching someoneelse
Fetching otherperson

-- 
bye,
pabs

http://bonedaddy.net/pabs3/



signature.asc
Description: This is a digitally signed message part

[PATCH] fetch: only show "Fetching remote" when verbose mode is enabled

[Paul Wise]

By default when fetching one remote nothing is printed unless there
are changes that need fetching. This makes fetching multiple remotes
be just as verbose as fetching a single remote.

This is needed when fetching multiple repositories using the myrepos
tool in minimal output mode, where myrepos only prints the repository
names when git fetch prints some output. For example in the output below
the cgit and git-remote-* lines would be hidden if git fetch were
silent by default when fetching multiple remotes, since the default
for myrepos is to fetch all remotes for git repositories.

pabs@chianamo ~ $ mr -m fetch
mr fetch: /home/pabs/cgit
Fetching origin

mr fetch: /home/pabs/git
Fetching origin
>From https://github.com/git/git
 - [tag update]  junio-gpg-pub -> junio-gpg-pub
Fetching hg
>From https://github.com/SRabbelier/git
 - [tag update]  junio-gpg-pub -> junio-gpg-pub

mr fetch: /home/pabs/git-remote-bzr
Fetching origin

mr fetch: /home/pabs/git-remote-hg
Fetching origin

Signed-off-by: Paul Wise <pa...@bonedaddy.net>
---
 builtin/fetch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/fetch.c b/builtin/fetch.c
index 9a3869f..fc33667 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1067,7 +1067,7 @@ static int fetch_multiple(struct string_list *list)
for (i = 0; i < list->nr; i++) {
const char *name = list->items[i].string;
argv_array_push(, name);
-   if (verbosity >= 0)
+   if (verbosity >= 1)
printf(_("Fetching %s\n"), name);
if (run_command_v_opt(argv.argv, RUN_GIT_CMD)) {
error(_("Could not fetch %s"), name);
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] fetch: only show "Fetching remote" when verbose mode is enabled

[Paul Wise]

By default when fetching one remote nothing is printed unless there
are changes that need fetching. This makes fetching multiple remotes
be just as verbose as fetching a single remote.

This is needed when fetching multiple repositories using the myrepos
tool in minimal output mode, where myrepos only prints the repository
names when git fetch prints some output. For example in the output below
the cgit and git-remote-* lines would be hidden if git fetch were
silent by default when fetching multiple remotes, since the default
for myrepos is to fetch all remotes for git repositories.

pabs@chianamo ~ $ mr -m fetch
mr fetch: /home/pabs/cgit
Fetching origin

mr fetch: /home/pabs/git
Fetching origin
>From https://github.com/git/git
 - [tag update]  junio-gpg-pub -> junio-gpg-pub
Fetching hg
>From https://github.com/SRabbelier/git
 - [tag update]  junio-gpg-pub -> junio-gpg-pub

mr fetch: /home/pabs/git-remote-bzr
Fetching origin

mr fetch: /home/pabs/git-remote-hg
Fetching origin

Signed-off-by: Paul Wise <pa...@bonedaddy.net>
---
 builtin/fetch.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/builtin/fetch.c b/builtin/fetch.c
index 9a3869f..fc33667 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1067,7 +1067,7 @@ static int fetch_multiple(struct string_list *list)
for (i = 0; i < list->nr; i++) {
const char *name = list->items[i].string;
argv_array_push(, name);
-   if (verbosity >= 0)
+   if (verbosity >= 1)
printf(_("Fetching %s\n"), name);
if (run_command_v_opt(argv.argv, RUN_GIT_CMD)) {
error(_("Could not fetch %s"), name);
-- 
2.6.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

status of git interop with other VCS

[Paul Wise]

Hi all,

I thought I would summarise current status of interop between git and
other remote VCSen. In particular I am interested in good git remote
helpers for cvs, svn, hg, darcs and bzr. git-svn and the like are useful
but git remote helpers are better because they map everything onto the
git model better.

cvs: there seems to have been a project but it was never merged:

http://marc.info/?l=gitm=127279549623477w=2
http://thread.gmane.org/gmane.comp.version-control.git/131620/focus=131632

svn: there was a gsoc project for this but it was never merged:

http://git.wiki.kernel.org/index.php/SoC2011Projects#Remote_helper_for_Subversion_and_git-svn

hg: there are a few projects for this, none are merged:

git://github.com/SRabbelier/git.git
http://marc.info/?l=gitm=134153749521450w=2

darcs: can't find any project to add this, please let me know of one

bzr: git-remote-bzr is part of bzr-git but it is quite buggy, hopefully
this will improve over time though.

-- 
bye,
pabs

http://bonedaddy.net/pabs3/


signature.asc
Description: This is a digitally signed message part