* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 17:11 UTC (permalink / raw)
To: Michael J Gruber
Cc: Jonathan Nieder, Ramkumar Ramachandra, Michael Schubert, Git List,
Jeff King
In-Reply-To: <5114D5B0.5080906@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> As for the triangle remote, I really think we should clean up the
> situation regarding push, pushurlinsteadof and the various different and
> inconclusive output formats of "git remote" (with or without "-v", with
> or without a remote name) first, before introducing yet another way to
> twist things around. "git push downstream" does not hurt any kittens
> (while git remote ouput does, somehwat).
As people tend to fetch more often than they push if they are
working on a real project where the others as a whole will be far
more productive than any single individual, I agree that keeping
"git fetch" (or "git pull") lazy by having "origin" point at where
they fetch from and be a bit more explicit in "git push" would
actually make sense.
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 17:16 UTC (permalink / raw)
To: Michael J Gruber
Cc: Jonathan Nieder, Ramkumar Ramachandra, Michael Schubert, Git List,
Jeff King
In-Reply-To: <5114D5B0.5080906@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetched from the remote.
>>
>> It shouldn't have been made to do so unconditionally; instead it
>> should have been designed to give the pushee a way to optionally
>> tell you "I acccept this push, but you may not see it to be updated
>> to that exact value you pushed when you fetched from me right now".
>>
>> The hack is not my design; it was not even something I accepted
>> without complaints, so I can badmouth about it all I want without
>> hesitation ;-)
>>
>> More importantly, we could fix it if we wanted to.
>
> And this seems to be more natural, too. It can keep the internals (the
> auxiliary ref on the server side) hidden from the user.
Fixing that misfeature to always pretend it immediately turned
around and fetched may have a different benefit, too.
A straightforward and simple solution to Ram's original problem may
be to define pushurl to point at his publishing repository after
all, and teach "git push" not to pretend it immediately fetched with
the same "fix".
[remote "origin"]
url = ... where Ram fetches and pulls from ...
pushurl = ... where Ram pushes to ...
fetch = refs/heads/*:refs/remotes/*
updateTrackOnPush = no
Then "git fetch" (or "git pull") will update the remote tracking
branches Ram fetches from, and once his topic is finished, he can
push to his publishing location, which won't touch the remote
tracking branches used to keep track of the place he fetches from.
^ permalink raw reply
* [PATCH 1/2] Makefile: make script-related rules usable from subdirectories
From: Matthieu Moy @ 2013-02-08 17:31 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <vpq4nhmbusp.fsf@grenoble-inp.fr>
Git's Makefile provides a few nice features for script build and
installation (substitute the first line with the right path, hardcode the
path to Git library, ...).
The Makefile already knows how to process files outside the toplevel
directory with e.g.
make SCRIPT_PERL=path/to/file.perl path/to/file
but we can make it simpler for callers by exposing build, install and
clean rules as .PHONY targets.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
The goal of this series is to use perl, but it is as easy to do it
with sh and python too, so I did it for them too. I tested a manual
"make -C ../../" in contrib/subtree and contrib/hg-to-git/ to check that
it actually works.
Makefile | 35 ++++++++++++++++++++++++++++++++---
1 file changed, 32 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 5a2e02d..b4af30d 100644
--- a/Makefile
+++ b/Makefile
@@ -480,9 +480,38 @@ SCRIPT_PERL += git-svn.perl
SCRIPT_PYTHON += git-remote-testpy.py
SCRIPT_PYTHON += git-p4.py
-SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
- $(patsubst %.perl,%,$(SCRIPT_PERL)) \
- $(patsubst %.py,%,$(SCRIPT_PYTHON)) \
+# Generated files for scripts
+SCRIPT_SH_GEN = $(patsubst %.sh,%,$(SCRIPT_SH))
+SCRIPT_PERL_GEN = $(patsubst %.perl,%,$(SCRIPT_PERL))
+SCRIPT_PYTHON_GEN = $(patsubst %.py,%,$(SCRIPT_PYTHON))
+
+# Individual rules to allow e.g.
+# "make -C ../.. SCRIPT_PERL=contrib/foo/bar.perl build-perl-script"
+# from subdirectories like contrib/*/
+.PHONY: build-perl-script build-sh-script build-python-script
+build-perl-script: $(SCRIPT_PERL_GEN)
+build-sh-script: $(SCRIPT_SH_GEN)
+build-python-script: $(SCRIPT_PYTHON_GEN)
+
+.PHONY: install-perl-script install-sh-script install-python-script
+install-sh-script: $(SCRIPT_SH_GEN)
+ $(INSTALL) $(SCRIPT_SH_GEN) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+install-perl-script: $(SCRIPT_PERL_GEN)
+ $(INSTALL) $(SCRIPT_PERL_GEN) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+install-python-script: $(SCRIPT_PYTHON_GEN)
+ $(INSTALL) $(SCRIPT_PYTHON_GEN) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+
+.PHONY: clean-perl-script clean-sh-script clean-python-script
+clean-sh-script:
+ $(RM) $(SCRIPT_SH_GEN)
+clean-perl-script:
+ $(RM) $(SCRIPT_PERL_GEN)
+clean-python-script:
+ $(RM) $(SCRIPT_PYTHON_GEN)
+
+SCRIPTS = $(SCRIPT_SH_GEN) \
+ $(SCRIPT_PERL_GEN) \
+ $(SCRIPT_PYTHON_GEN) \
git-instaweb
ETAGS_TARGET = TAGS
--
1.8.1.2.530.g3cc16e4.dirty
^ permalink raw reply related
* [PATCH 2/2] git-remote-mediawiki: use toplevel's Makefile
From: Matthieu Moy @ 2013-02-08 17:31 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1360344677-5962-1-git-send-email-Matthieu.Moy@imag.fr>
This makes the Makefile simpler, while providing more features, and more
consistency (the exact same rules with the exact same configuration as
Git official commands are applied with the new version).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/.gitignore | 1 +
contrib/mw-to-git/Makefile | 64 ++++++----------------
...-remote-mediawiki => git-remote-mediawiki.perl} | 0
3 files changed, 18 insertions(+), 47 deletions(-)
create mode 100644 contrib/mw-to-git/.gitignore
rewrite contrib/mw-to-git/Makefile (96%)
rename contrib/mw-to-git/{git-remote-mediawiki => git-remote-mediawiki.perl} (100%)
diff --git a/contrib/mw-to-git/.gitignore b/contrib/mw-to-git/.gitignore
new file mode 100644
index 0000000..b919655
--- /dev/null
+++ b/contrib/mw-to-git/.gitignore
@@ -0,0 +1 @@
+git-remote-mediawiki
diff --git a/contrib/mw-to-git/Makefile b/contrib/mw-to-git/Makefile
dissimilarity index 96%
index 3ed728b..f149719 100644
--- a/contrib/mw-to-git/Makefile
+++ b/contrib/mw-to-git/Makefile
@@ -1,47 +1,17 @@
-#
-# Copyright (C) 2012
-# Charles Roussel <charles.roussel@ensimag.imag.fr>
-# Simon Cathebras <simon.cathebras@ensimag.imag.fr>
-# Julien Khayat <julien.khayat@ensimag.imag.fr>
-# Guillaume Sasdy <guillaume.sasdy@ensimag.imag.fr>
-# Simon Perrat <simon.perrat@ensimag.imag.fr>
-#
-## Build git-remote-mediawiki
-
--include ../../config.mak.autogen
--include ../../config.mak
-
-ifndef PERL_PATH
- PERL_PATH = /usr/bin/perl
-endif
-ifndef gitexecdir
- gitexecdir = $(shell git --exec-path)
-endif
-
-PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
-gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
-SCRIPT = git-remote-mediawiki
-
-.PHONY: install help doc test clean
-
-help:
- @echo 'This is the help target of the Makefile. Current configuration:'
- @echo ' gitexecdir = $(gitexecdir_SQ)'
- @echo ' PERL_PATH = $(PERL_PATH_SQ)'
- @echo 'Run "$(MAKE) install" to install $(SCRIPT) in gitexecdir'
- @echo 'Run "$(MAKE) test" to run the testsuite'
-
-install:
- sed -e '1s|#!.*/perl|#!$(PERL_PATH_SQ)|' $(SCRIPT) \
- > '$(gitexecdir_SQ)/$(SCRIPT)'
- chmod +x '$(gitexecdir)/$(SCRIPT)'
-
-doc:
- @echo 'Sorry, "make doc" is not implemented yet for $(SCRIPT)'
-
-test:
- $(MAKE) -C t/ test
-
-clean:
- $(RM) '$(gitexecdir)/$(SCRIPT)'
- $(MAKE) -C t/ clean
+#
+# Copyright (C) 2013
+# Matthieu Moy <Matthieu.Moy@imag.fr>
+#
+## Build git-remote-mediawiki
+
+SCRIPT_PERL=git-remote-mediawiki.perl
+GIT_ROOT_DIR=../..
+HERE=contrib/mw-to-git/
+
+SCRIPT_PERL_FULL=$(patsubst %,$(HERE)/%,$(SCRIPT_PERL))
+
+all: build
+
+build install clean:
+ $(MAKE) -C $(GIT_ROOT_DIR) SCRIPT_PERL=$(SCRIPT_PERL_FULL) \
+ $@-perl-script
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki.perl
similarity index 100%
rename from contrib/mw-to-git/git-remote-mediawiki
rename to contrib/mw-to-git/git-remote-mediawiki.perl
--
1.8.1.2.530.g3cc16e4.dirty
^ permalink raw reply related
* Re: [PATCH] git-mergetool: print filename when it contains %
From: Junio C Hamano @ 2013-02-08 17:32 UTC (permalink / raw)
To: Asheesh Laroia; +Cc: git
In-Reply-To: <1360286184-14278-1-git-send-email-asheesh@asheesh.org>
Asheesh Laroia <asheesh@asheesh.org> writes:
> Before this change, if git-mergetool was invoked with regard to
Drop "before this change,"; it is clear (and it is a recommended
practice) you are first describing what problem you are addressing.
> files with a percent sign (%) in their names, it would print an
> error. For example, if you were calling mergetool on a file called
> "%2F":
>
> printf: %2F: invalid directive
>
> This changes the behavior to pass "%s" to printf as its first argument
> to avoid processing the filename as a format string.
>
> Signed-off-by: Asheesh Laroia <asheesh@asheesh.org>
> ---
Thanks.
As a follow-up to this patch, we may want to perform a systematic
audit of
$ git grep -e 'printf "[^"]*\$[^"]*"'
There is one in git-difftool-helper.sh
printf "\nViewing: '$MERGED'\n"
and mergetools/p4merge:
printf "$empty_file"
> git-mergetool.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index c50e18a..d2b9289 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -440,7 +440,7 @@ then
> fi
>
> printf "Merging:\n"
> -printf "$files\n"
> +printf "%s" "$files\n"
I think
printf "%s\n" "$files"
would be clearer.
>
> IFS='
> '
^ permalink raw reply
* Re: [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script
From: Matthieu Moy @ 2013-02-08 17:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20130208042800.GB4157@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> That seems much cleaner to me. If done right, it could also let people
> put:
>
> CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
Actually, you can already do this:
SCRIPT_PERL += contrib/mw-to-git/git-remote-mediawiki.perl
probably not by design, but it works!
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] user-manual: Rewrite git-gc section for automatic packing
From: Junio C Hamano @ 2013-02-08 17:36 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git
In-Reply-To: <7ac63ea832711ad4bee636163e277a408cbddda4.1360341577.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> From: "W. Trevor King" <wking@tremily.us>
>
> This should have happened back in 2007, when `git gc` learned about
> auto:
>
> commit e9831e83e063844b90cf9e525d0003715dd8b395
> Author: Junio C Hamano <gitster@pobox.com>
> Date: Mon Sep 17 00:39:52 2007 -0700
>
> git-gc --auto: add documentation.
>
> Signed-off-by: W. Trevor King <wking@tremily.us>
> ---
> I'd also be happy just dropping the whole git-gc section ;).
>
> Documentation/user-manual.txt | 16 ++++++----------
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 5077e7c..d14e3c7 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1562,17 +1562,13 @@ Ensuring good performance
> -------------------------
>
> On large repositories, Git depends on compression to keep the history
> -information from taking up too much space on disk or in memory.
> +information from taking up too much space on disk or in memory. Some
> +git commands may automatically run linkgit:git-gc[1], so you don't
> +have to worry about running it manually. However, compressing large
> +repositories may take some time, so you might want to disable
> +automatic comression and run it explicitly when you are not doing
> +other work.
I'd rather phrase it like "... may take long, so you would want to
run it explicitly from time to time to avoid automatic gc kicking in
when it is not convenient for you".
> -This compression is not performed automatically. Therefore you
> -should occasionally run linkgit:git-gc[1]:
> -
> --------------------------------------------------
> -$ git gc
> --------------------------------------------------
> -
> -to recompress the archive. This can be very time-consuming, so
> -you may prefer to run `git gc` when you are not doing other work.
Removal of this is a good change, though.
^ permalink raw reply
* Re: [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script
From: Jeff King @ 2013-02-08 17:43 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqzjzeaevm.fsf@grenoble-inp.fr>
On Fri, Feb 08, 2013 at 06:34:37PM +0100, Matthieu Moy wrote:
> Jeff King <peff@peff.net> writes:
>
> > That seems much cleaner to me. If done right, it could also let people
> > put:
> >
> > CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
>
> Actually, you can already do this:
>
> SCRIPT_PERL += contrib/mw-to-git/git-remote-mediawiki.perl
>
> probably not by design, but it works!
So putting:
ROOT=contrib/mw-to-git
git-remote-mediawiki: FORCE
@make -C ../.. SCRIPT_PERL=$(ROOT)/$@.perl $(ROOT)/$@
in contrib/mw-to-git/Makefile would already work? Neat.
-Peff
^ permalink raw reply
* Re: [PATCH] graph: output padding for merge subsequent parents
From: Matthieu Moy @ 2013-02-08 17:52 UTC (permalink / raw)
To: John Keeping; +Cc: Dale R. Worley, gitster, git
In-Reply-To: <20130206195702.GA1342@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> diff --git a/graph.c b/graph.c
> index 391a712..2a3fc5c 100644
> --- a/graph.c
> +++ b/graph.c
> @@ -1227,6 +1227,16 @@ void graph_show_commit(struct git_graph *graph)
> if (!graph)
> return;
>
> + /*
> + * When showing a diff of a merge against each of its parents, we
> + * are called once for each parent without graph_update having been
> + * called. In this case, simply output a single padding line.
> + */
> + if (graph_is_commit_finished(graph)) {
> + graph_show_padding(graph);
> + shown_commit_line = 1;
> + }
> +
> while (!shown_commit_line && !graph_is_commit_finished(graph)) {
This works, but if we know we're not going to enter the while loop, it
seams even easier to do this:
--- a/graph.c
+++ b/graph.c
@@ -1227,7 +1227,17 @@ void graph_show_commit(struct git_graph *graph)
if (!graph)
return;
- while (!shown_commit_line && !graph_is_commit_finished(graph)) {
+ /*
+ * When showing a diff of a merge against each of its parents, we
+ * are called once for each parent without graph_update having been
+ * called. In this case, simply output a single padding line.
+ */
+ if (graph_is_commit_finished(graph)) {
+ graph_show_padding(graph);
+ return;
+ }
+
+ while (!shown_commit_line) {
shown_commit_line = graph_next_line(graph, &msgbuf);
fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
if (!shown_commit_line)
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Ramkumar Ramachandra @ 2013-02-08 18:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Git List
In-Reply-To: <7vwqui3fcc.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> We have the problem now that new users do not necessarily understand the
>> matching strategy, or why it is useful, and get confused. When we move
>> to "simple", we may be switching to a world where the early part of the
>> learning curve is more gentle for those users, but they eventually run
>> across the steeper part when they want to adjust their workflow (i.e.,
>> they will eventually learn about non-symmetric repo topologies because
>> those are part of many useful workflows).
>>
>> But I think it's a good thing to push that part of the learning curve
>> out, because:
>>
>> 1. Some people may stay in the centralized view their whole lives and
>> never care.
>>
>> 2. It will make more sense to them, because they'll understand how it
>> fits into what they're trying to do, rather than viewing it as an
>> arcane and senseless default.
>>
>> There may be some confusion as people hit that learning point. I won't
>> be surprised if we end up adding more advice.* messages in certain cases
>> to guide people to adjusting their push.default. But I'm just as happy
>> to wait until people start hitting the confusion point in practice, and
>> we can see more clearly when that advice should trigger, and what it
>> should say.
>
> Oh, I agree with you that adding new support for triangular workflow
> will not hurt the centralized folks. I was more interested about
> helping the "fetch from here, push to there" people.
In Git, there will always be a combination of switches which allows
you to go the centralized workflow mode. We're focusing on expanding
this list of switches, to free up distributed workflows into more
possibilities. We're currently targeting problems that affect us
everyday; the ones we've failed to notice.
> Centralized people do not have to configure anything for each branch
> for "git push" to push their current branch to where they fetch from
> and to the same name (you start building on their 'master', your
> result go to their 'master', because as a centralized person, you
> are part of 'them'). They have branch.$name.merge that names what
> their $name branch merges with, and that is sufficient to decide to
> which branch the result is to be pushed back.
What about the branch.$name.pushRef, which was proposed earlier? They
should be able to say, at a per-branch level, which branches to send
for review (in Gerrit).
> With the "push.defaultTo = peff" to name what remote the "git push"
> will push to, or even with the "branch.master.remotepush = peff" to
> decide that per branch, would "fetch from here, push to there"
> people have a way similar to what branch.$name.merge gives to the
> centralized people to decide what branch is updated?
Ah.
> It almost seems to me that we may want to extend the semantics given
> to the remote.$name.push refspecs. They are primarily for "perfect
> all branches you are going to push out, and push them in one go with
> 'git push'" workflow, but if it is clear that you are not following
> that (e.g. you are doing an equivalent of what the centralized folks
> would do with "push.default = simple/upstream/current") and pushing
> only the current branch, perhaps we should look at these refspecs to
> see where the current branch goes?
I'd actually just go with the current syntax + per-branch overrides.
Simple and serves the purpose: I don't think there'll be real usecases
outside this.
> In your case, 'refs/heads/master' would likely to go to
> 'refs/heads/master', and we could treat a missing remote.peff.push
> an equivalent to having remote.peff.push = refs/heads/*:refs/heads/*
I'll get to work on a patch that deems the configuration variable as
not "necessary".
^ permalink raw reply
* [PATCH] user-manual: Update for receive.denyCurrentBranch=refuse
From: W. Trevor King @ 2013-02-08 17:04 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
From: "W. Trevor King" <wking@tremily.us>
acd2a45 (Refuse updating the current branch in a non-bare repository
via push, 2009-02-11) changed the default to refuse such a push, but
it forgot to update the docs.
7d182f5 (Documentation: receive.denyCurrentBranch defaults to
'refuse', 2010-03-17) updated Documentation/config.txt, but forgot to
update the user manual.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5077e7c..8e55794 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1994,8 +1994,10 @@ handling this case.
Note that the target of a "push" is normally a
<<def_bare_repository,bare>> repository. You can also push to a
repository that has a checked-out working tree, but the working tree
-will not be updated by the push. This may lead to unexpected results if
-the branch you push to is the currently checked-out branch!
+will not be updated by the push. To protect against this, pushes to
+the currently checked-out branch of a repository are denied by
+default. See the description of the receive.denyCurrentBranch option
+in linkgit:git-config[1] for details.
As with `git fetch`, you may also set up configuration options to
save typing; so, for example, after
--
1.8.1.336.g94702dd
^ permalink raw reply related
* Re: [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script
From: Junio C Hamano @ 2013-02-08 18:13 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20130208174350.GA28266@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Feb 08, 2013 at 06:34:37PM +0100, Matthieu Moy wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > That seems much cleaner to me. If done right, it could also let people
>> > put:
>> >
>> > CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
>>
>> Actually, you can already do this:
>>
>> SCRIPT_PERL += contrib/mw-to-git/git-remote-mediawiki.perl
>>
>> probably not by design, but it works!
>
> So putting:
>
> ROOT=contrib/mw-to-git
> git-remote-mediawiki: FORCE
> @make -C ../.. SCRIPT_PERL=$(ROOT)/$@.perl $(ROOT)/$@
>
> in contrib/mw-to-git/Makefile would already work? Neat.
That essentially is what [v2 2/2] does, no?
^ permalink raw reply
* Re: [PATCH 4/4] git-remote-mediawiki: use Git's Makefile to build the script
From: Jeff King @ 2013-02-08 18:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7v62223c8s.fsf@alter.siamese.dyndns.org>
On Fri, Feb 08, 2013 at 10:13:23AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Fri, Feb 08, 2013 at 06:34:37PM +0100, Matthieu Moy wrote:
> >
> >> Jeff King <peff@peff.net> writes:
> >>
> >> > That seems much cleaner to me. If done right, it could also let people
> >> > put:
> >> >
> >> > CONTRIB_PERL += contrib/mw-to-git/git-remote-mediawiki
> >>
> >> Actually, you can already do this:
> >>
> >> SCRIPT_PERL += contrib/mw-to-git/git-remote-mediawiki.perl
> >>
> >> probably not by design, but it works!
> >
> > So putting:
> >
> > ROOT=contrib/mw-to-git
> > git-remote-mediawiki: FORCE
> > @make -C ../.. SCRIPT_PERL=$(ROOT)/$@.perl $(ROOT)/$@
> >
> > in contrib/mw-to-git/Makefile would already work? Neat.
>
> That essentially is what [v2 2/2] does, no?
Yes (this one was cc'd to me, but the others were not, so I read it in
isolation). I think Matthieu's series is nicer than just that, though,
because it handles the single-file case installation, too, which
requires more support from the parent Makefile.
-Peff
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Ramkumar Ramachandra @ 2013-02-08 18:29 UTC (permalink / raw)
To: Junio C Hamano
Cc: Michael J Gruber, Jonathan Nieder, Michael Schubert, Git List,
Jeff King
In-Reply-To: <7vobfu3ev3.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> [remote "origin"]
> url = ... where Ram fetches and pulls from ...
> pushurl = ... where Ram pushes to ...
> fetch = refs/heads/*:refs/remotes/*
> updateTrackOnPush = no
>
> Then "git fetch" (or "git pull") will update the remote tracking
> branches Ram fetches from, and once his topic is finished, he can
> push to his publishing location, which won't touch the remote
> tracking branches used to keep track of the place he fetches from.
A "push" should never touch remote/refs/origin/* if there is a pushurl
configured. Otherwise, it should. I want my push to affect my
status. The configuration variable makes no sense and should not
exist.
Unfortunately, pushurl doesn't get the same privileges as url even
though they're equal remotes. How is my fork "inferior" to the
upstream project in any way? A lot of us might be working on this
fork, and we will need something corresponding to refs/remotes/* to
inspect its state. Like I said earlier, I think pushurl has a very
limited usecase: when the two URLs are actually mirrors (there is
really no fork; we're back in a centralized environment). In fact, I
think it should be deprecated, because it interferes with my more
general approach.
Let's see what happens if we have two actual remotes.
remote/refs/origin/* will be updated when I fetch from, and push to,
origin. remote/refs/ram/* will be updated when I fetch from, and
push to, ram. It's very simple, and I don't need this complex rule of
when to update refs. We should have a way to pair remotes together as
upstream/ downstream in the future. Maybe even have a hierarchy of
remotes.
^ permalink raw reply
* Re: [PATCH v3] branch: show rebase/bisect info when possible instead of "(no branch)"
From: Junio C Hamano @ 2013-02-08 18:35 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Matthieu Moy, Jonathan Niedier
In-Reply-To: <1360318171-17614-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> This prints more helpful info when HEAD is detached: is it detached
> because of bisect or rebase? What is the original branch name in those
> cases?
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Keep "no branch" in all cases. Just append "rebasing/bisecting [%s]"
> when applicable.
>
> builtin/branch.c | 44 +++++++++++++++++++++++++++++++++++++++++++-
> t/t6030-bisect-porcelain.sh | 2 +-
> 2 files changed, 44 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 6371bf9..26c0c3d 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -550,6 +550,48 @@ static int calc_maxwidth(struct ref_list *refs)
> return w;
> }
>
> +static char *get_head_description()
> +{
> + struct stat st;
> + struct strbuf sb = STRBUF_INIT;
> + struct strbuf result = STRBUF_INIT;
> + int bisect = 0;
> + int ret;
> + if (!stat(git_path("rebase-merge"), &st) && S_ISDIR(st.st_mode))
> + ret = strbuf_read_file(&sb, git_path("rebase-merge/head-name"), 0);
> + else if (!access(git_path("rebase-apply/rebasing"), F_OK))
> + ret = strbuf_read_file(&sb, git_path("rebase-apply/head-name"), 0);
> + else if (!access(git_path("BISECT_LOG"), F_OK)) {
> + ret = strbuf_read_file(&sb, git_path("BISECT_START"), 0);
> + bisect = 1;
> + } else
> + return xstrdup(_("(no branch)"));
> +
> + if (ret <= 0) {
Doesn't the general "negative signals an error" apply here?
The end result may be the same, as the later part of this function
that uses sb with len==0 ends up showing the same "bisecting" (or
"rebasing") without any other information, but the logic to reach
that outcome looks wrong.
> + if (bisect)
> + return xstrdup(_("(no branch, bisecting)"));
> + else
> + return xstrdup(_("_(no branch, rebasing)"));
> + }
> +
> + while (sb.len && sb.buf[sb.len - 1] == '\n')
> + strbuf_setlen(&sb, sb.len - 1);
> +
> + if (bisect) {
> + unsigned char sha1[20];
> + if (!get_sha1_hex(sb.buf, sha1))
> + strbuf_addstr(&result, _("(no branch, bisecting)"));
> + else
> + strbuf_addf(&result, _("(no branch, bisecting %s)"), sb.buf);
> + } else {
> + if (!prefixcmp(sb.buf, "refs/heads/"))
> + strbuf_addf(&result, _("(no branch, rebasing %s)"), sb.buf + 11);
> + else
> + strbuf_addstr(&result, _("(no branch, rebasing)"));
> + }
> + strbuf_release(&sb);
> + return strbuf_detach(&result, NULL);
> +}
We may want to refactor wt_status_print_state() and its callee a bit
so that it and this part can share the logic without duplication and
risk implementing subtly different decision. wt_status used to have
clean separation between collection phase and presentation phase,
but the wall between the phases seems deteriorated over time as more
"in progress" crufts have been piled on top.
Such a refactoring may look larger than necessary, but on the other
hand, I do not see this feature very useful if it can over time
drift away from what we will see in "git status", so...
>
> static void show_detached(struct ref_list *ref_list)
> {
> @@ -557,7 +599,7 @@ static void show_detached(struct ref_list *ref_list)
>
> if (head_commit && is_descendant_of(head_commit, ref_list->with_commit)) {
> struct ref_item item;
> - item.name = xstrdup(_("(no branch)"));
> + item.name = get_head_description();
> item.width = utf8_strwidth(item.name);
> item.kind = REF_LOCAL_BRANCH;
> item.dest = NULL;
> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> index 3e0e15f..9b6f0d0 100755
> --- a/t/t6030-bisect-porcelain.sh
> +++ b/t/t6030-bisect-porcelain.sh
> @@ -164,7 +164,7 @@ test_expect_success 'bisect start: existing ".git/BISECT_START" not modified if
> cp .git/BISECT_START saved &&
> test_must_fail git bisect start $HASH4 foo -- &&
> git branch > branch.output &&
> - test_i18ngrep "* (no branch)" branch.output > /dev/null &&
> + test_i18ngrep "* (no branch, bisecting other)" branch.output > /dev/null &&
> test_cmp saved .git/BISECT_START
> '
> test_expect_success 'bisect start: no ".git/BISECT_START" if mistaken rev' '
^ permalink raw reply
* Re: [PATCH] user-manual: Rewrite git-gc section for automatic packing
From: W. Trevor King @ 2013-02-08 18:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git
In-Reply-To: <7vd2wa3dxm.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
On Fri, Feb 08, 2013 at 09:36:53AM -0800, Junio C Hamano wrote:
> I'd rather phrase it like "... may take long, so you would want to
> run it explicitly from time to time to avoid automatic gc kicking in
> when it is not convenient for you".
Works for me.
> Removal of this is a good change, though.
I just read through the manual cover to cover, so I have a number of
other fixes in the pipe (from which I've already submitted the
receive.denyCurrentBranch patch). Should I bundle them all into a
single series to reduce clutter on the list, or will that just lead to
resending boring fixes while we hash out the right handling for more
involved ones?
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Jonathan Nieder @ 2013-02-08 18:36 UTC (permalink / raw)
To: Michael J Gruber
Cc: Junio C Hamano, Ramkumar Ramachandra, Michael Schubert, Git List,
Jeff King
In-Reply-To: <5114D5B0.5080906@drmicha.warpmail.net>
Michael J Gruber wrote:
> Junio C Hamano venit, vidit, dixit 08.02.2013 09:16:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>> "Wait, why did the remote rewind?"
>>
>> Oh, I am very well aware of that glitch.
>>
>> "git push" has this hack to pretend as if the pusher immediately
>> turned around and fetched from the remote.
>>
>> It shouldn't have been made to do so unconditionally; instead it
>> should have been designed to give the pushee a way to optionally
>> tell you "I acccept this push, but you may not see it to be updated
>> to that exact value you pushed when you fetched from me right now".
Yes, I agree with this.
The "git push" hack does seem to be useful in practice for helping
people just starting to use git. If they have a separate "gitk --all"
window open, they can refresh it and see the remote-tracking branch
corresponding to the branch that has been pushed advancing. It matches
a model in which remote-tracking refs represent "git's idea of where
these branches are in the remote repository".
And in that model, a remote being able to respond to a push with
"ref update queued, but please keep in mind that it may take me a
while to chew through that queue" should be perfectly reasonable.
[...]
> And this seems to be more natural, too. It can keep the internals (the
> auxiliary ref on the server side) hidden from the user.
Just to clarify: this is not an internal ref being exposed. No
auxiliary refs/for/master ref actually exists. The ref Gerrit users
push to is a UI fiction.
That's important because otherwise two developers could not propose
changes for the same branch at the same time.
Jonathan
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Ramkumar Ramachandra @ 2013-02-08 18:42 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Michael Schubert, Git List, Junio C Hamano
In-Reply-To: <20130207233017.GD19397@google.com>
Jonathan Nieder wrote:
> Ramkumar Ramachandra wrote:
>
>> And yes, a regular `git push origin refs/for/master` is just retarded.
>
> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
> the code review creation push that uses a different branchname from
> the branch the integrator pulls what seems backward, or is it the need
> to specify a refname at all on the command line?
How else would you design a system to differentiate between a
push-for-review, and push-to-update-ref?
On a slightly unrelated note, it would be nice if we could streamline
the git-format-patch, git-send-email process. Let's say we make it a
push', which has a pre-hook that fires up the $EDITOR for a cover
letter. Wouldn't you love it if this push' would update refs on your
private fork and fire off emails to the Git List? Bonus for contrib/:
fetch the Google address book, and allow me to auto-complete names
when sending emails.
> I agree that a "[branch "master"] pushremote" configuration would be
> handy. pushremote instead of remotepush to be less surprising to
> people who have already seen pushurl.
Thanks for that, by the way (used in RFC patch). My taste in variable
names is a little sour.
^ permalink raw reply
* Re: [PATCH v2 2/3] count-objects: report garbage files in pack directory too
From: Junio C Hamano @ 2013-02-08 18:44 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1360295307-5469-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> prepare_packed_git_one() is modified to allow count-objects to hook a
> report function to so we don't need to duplicate the pack searching
> logic in count-objects.c. When report_pack_garbage is NULL, the
> overhead is insignificant.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> Documentation/git-count-objects.txt | 4 +-
> builtin/count-objects.c | 18 ++++++++-
> sha1_file.c | 81 +++++++++++++++++++++++++++++++++++--
> 3 files changed, 97 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
> index e816823..1611d7c 100644
> --- a/Documentation/git-count-objects.txt
> +++ b/Documentation/git-count-objects.txt
> @@ -33,8 +33,8 @@ size-pack: disk space consumed by the packs, in KiB
> prune-packable: the number of loose objects that are also present in
> the packs. These objects could be pruned using `git prune-packed`.
> +
> -garbage: the number of files in loose object database that are not
> -valid loose objects
> +garbage: the number of files in object database that are not valid
> +loose objects nor valid packs
>
> GIT
> ---
> diff --git a/builtin/count-objects.c b/builtin/count-objects.c
> index 9afaa88..118b2ae 100644
> --- a/builtin/count-objects.c
> +++ b/builtin/count-objects.c
> @@ -9,6 +9,20 @@
> #include "builtin.h"
> #include "parse-options.h"
>
> +static unsigned long garbage;
> +
> +extern void (*report_pack_garbage)(const char *path, int len, const char *name);
> +static void real_report_pack_garbage(const char *path, int len, const char *name)
> +{
Don't some callers call this on paths outside objects/pack/
directory? Is it still report-pack-garbage?
> + if (len && name)
> + error("garbage found: %.*s/%s", len, path, name);
> + else if (!len && name)
> + error("garbage found: %s%s", path, name);
> + else
> + error("garbage found: %s", path);
> + garbage++;
> +}
> +
> static void count_objects(DIR *d, char *path, int len, int verbose,
> unsigned long *loose,
> off_t *loose_size,
> @@ -76,7 +90,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
> const char *objdir = get_object_directory();
> int len = strlen(objdir);
> char *path = xmalloc(len + 50);
> - unsigned long loose = 0, packed = 0, packed_loose = 0, garbage = 0;
> + unsigned long loose = 0, packed = 0, packed_loose = 0;
> off_t loose_size = 0;
> struct option opts[] = {
> OPT__VERBOSE(&verbose, N_("be verbose")),
> @@ -87,6 +101,8 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
> /* we do not take arguments other than flags for now */
> if (argc)
> usage_with_options(count_objects_usage, opts);
> + if (verbose)
> + report_pack_garbage = real_report_pack_garbage;
> memcpy(path, objdir, len);
> if (len && objdir[len-1] != '/')
> path[len++] = '/';
> diff --git a/sha1_file.c b/sha1_file.c
> index 40b2329..cc6ef03 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -21,6 +21,7 @@
> #include "sha1-lookup.h"
> #include "bulk-checkin.h"
> #include "streaming.h"
> +#include "dir.h"
>
> #ifndef O_NOATIME
> #if defined(__linux__) && (defined(__i386__) || defined(__PPC__))
> @@ -1000,6 +1001,54 @@ void install_packed_git(struct packed_git *pack)
> packed_git = pack;
> }
>
> +/* A hook for count-objects to report invalid files in pack directory */
> +void (*report_pack_garbage)(const char *path, int len, const char *name);
> +
> +static const char *known_pack_extensions[] = { ".pack", ".keep", NULL };
This sounds wrong. Isn't ".idx" also known?
> +static void report_garbage(struct string_list *list)
> +{
> + struct strbuf sb = STRBUF_INIT;
> + struct packed_git *p;
> + int i;
> +
> + if (!report_pack_garbage)
> + return;
> +
> + sort_string_list(list);
> +
> + for (p = packed_git; p; p = p->next) {
> + struct string_list_item *item;
> + if (!p->pack_local)
> + continue;
> + strbuf_reset(&sb);
> + strbuf_add(&sb, p->pack_name,
> + strlen(p->pack_name) - strlen(".pack"));
> + item = string_list_lookup(list, sb.buf);
> + if (!item)
> + continue;
> + /*
> + * string_list_lookup does not guarantee to return the
> + * first matched string if it's duplicated.
> + */
> + while (item - list->items &&
> + !strcmp(item[-1].string, item->string))
> + item--;
> + while (item - list->items < list->nr &&
> + !strcmp(item->string, sb.buf)) {
> + item->util = NULL; /* non-garbage mark */
> + item++;
> + }
> + }
> + for (i = 0; i < list->nr; i++) {
> + struct string_list_item *item = list->items + i;
> + if (!item->util)
> + continue;
> + report_pack_garbage(item->string, 0, item->util);
> + }
> + strbuf_release(&sb);
> +}
> +
> static void prepare_packed_git_one(char *objdir, int local)
> {
> /* Ensure that this buffer is large enough so that we can
> @@ -1009,6 +1058,7 @@ static void prepare_packed_git_one(char *objdir, int local)
> int len;
> DIR *dir;
> struct dirent *de;
> + struct string_list garbage = STRING_LIST_INIT_DUP;
>
> sprintf(path, "%s/pack", objdir);
> len = strlen(path);
> @@ -1024,14 +1074,37 @@ static void prepare_packed_git_one(char *objdir, int local)
> int namelen = strlen(de->d_name);
> struct packed_git *p;
>
> - if (!has_extension(de->d_name, ".idx"))
> + if (len + namelen + 1 > sizeof(path)) {
> + if (report_pack_garbage)
> + report_pack_garbage(path, len - 1, de->d_name);
A pack/in/a/very/long/path/pack-0000000000000000000000000000000000000000.pack
may pass when fed to "git verify-pack", but this will report it as "garbage",
without reporting what is wrong with it. Wouldn't that confuse users?
> continue;
> + }
> +
> + strcpy(path + len, de->d_name);
>
> - if (len + namelen + 1 > sizeof(path))
> + if (!has_extension(de->d_name, ".idx")) {
> + struct string_list_item *item;
> + int i, n;
> + if (!report_pack_garbage)
> + continue;
> + if (is_dot_or_dotdot(de->d_name))
> + continue;
> + for (i = 0; known_pack_extensions[i]; i++)
> + if (has_extension(de->d_name,
> + known_pack_extensions[i]))
> + break;
> + if (!known_pack_extensions[i]) {
> + report_pack_garbage(path, 0, NULL);
> + continue;
> + }
> + n = strlen(path) - strlen(known_pack_extensions[i]);
> + item = string_list_append_nodup(&garbage,
> + xstrndup(path, n));
> + item->util = (void*)known_pack_extensions[i];
> continue;
> + }
Why isn't this part more like this?
if (dot-or-dotdot) {
continue;
} else if (has_extension(de->d_name, ".idx")) {
do things for the .idx file;
} else if (has_extension(de->d_name, ".pack") {
do things for the .pack file, including
queuing the name if we haven't seen
corresponding .idx for later examination;
} else if (has_extension(de->d_name, ".keep") {
nothing special for now but we may
want to add some other checks later
} else {
everything else is a garbage
report_pack_garbage();
}
>
> /* Don't reopen a pack we already have. */
> - strcpy(path + len, de->d_name);
> for (p = packed_git; p; p = p->next) {
> if (!memcmp(path, p->pack_name, len + namelen - 4))
> break;
> @@ -1047,6 +1120,8 @@ static void prepare_packed_git_one(char *objdir, int local)
> install_packed_git(p);
> }
> closedir(dir);
> + report_garbage(&garbage);
> + string_list_clear(&garbage, 0);
> }
>
> static int sort_pack(const void *a_, const void *b_)
^ permalink raw reply
* Re: [PATCH v2 3/3] count-objects: report how much disk space taken by garbage files
From: Junio C Hamano @ 2013-02-08 18:47 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1360295307-5469-4-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> We may do some redundant stat() here, but I don't think it can slow
> count-objects down much to worry about.
I don't either. Looks like a good change to me.
It appears that the sb.buf refactoring is better done to the
previous patch, but that is minor.
> Documentation/git-count-objects.txt | 2 ++
> builtin/count-objects.c | 29 ++++++++++++++++++-----------
> 2 files changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/git-count-objects.txt b/Documentation/git-count-objects.txt
> index 1611d7c..da6e72e 100644
> --- a/Documentation/git-count-objects.txt
> +++ b/Documentation/git-count-objects.txt
> @@ -35,6 +35,8 @@ the packs. These objects could be pruned using `git prune-packed`.
> +
> garbage: the number of files in object database that are not valid
> loose objects nor valid packs
> ++
> +size-garbage: disk space consumed by garbage files, in KiB
>
> GIT
> ---
> diff --git a/builtin/count-objects.c b/builtin/count-objects.c
> index 118b2ae..90d476d 100644
> --- a/builtin/count-objects.c
> +++ b/builtin/count-objects.c
> @@ -10,24 +10,33 @@
> #include "parse-options.h"
>
> static unsigned long garbage;
> +static off_t size_garbage;
>
> extern void (*report_pack_garbage)(const char *path, int len, const char *name);
> static void real_report_pack_garbage(const char *path, int len, const char *name)
> {
> + struct strbuf sb = STRBUF_INIT;
> + struct stat st;
> +
> if (len && name)
> - error("garbage found: %.*s/%s", len, path, name);
> + strbuf_addf(&sb, "%.*s/%s", len, path, name);
> else if (!len && name)
> - error("garbage found: %s%s", path, name);
> + strbuf_addf(&sb, "%s%s", path, name);
> else
> - error("garbage found: %s", path);
> + strbuf_addf(&sb, "%s", path);
> + error(_("garbage found: %s"), sb.buf);
> +
> + if (!stat(sb.buf, &st))
> + size_garbage += st.st_size;
> +
> garbage++;
> + strbuf_release(&sb);
> }
>
> static void count_objects(DIR *d, char *path, int len, int verbose,
> unsigned long *loose,
> off_t *loose_size,
> - unsigned long *packed_loose,
> - unsigned long *garbage)
> + unsigned long *packed_loose)
> {
> struct dirent *ent;
> while ((ent = readdir(d)) != NULL) {
> @@ -59,11 +68,8 @@ static void count_objects(DIR *d, char *path, int len, int verbose,
> (*loose_size) += xsize_t(on_disk_bytes(st));
> }
> if (bad) {
> - if (verbose) {
> - error("garbage found: %.*s/%s",
> - len + 2, path, ent->d_name);
> - (*garbage)++;
> - }
> + if (verbose)
> + report_pack_garbage(path, len + 2, ent->d_name);
> continue;
> }
> (*loose)++;
> @@ -113,7 +119,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
> if (!d)
> continue;
> count_objects(d, path, len, verbose,
> - &loose, &loose_size, &packed_loose, &garbage);
> + &loose, &loose_size, &packed_loose);
> closedir(d);
> }
> if (verbose) {
> @@ -138,6 +144,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
> printf("size-pack: %lu\n", (unsigned long) (size_pack / 1024));
> printf("prune-packable: %lu\n", packed_loose);
> printf("garbage: %lu\n", garbage);
> + printf("size-garbage: %lu\n", (unsigned long) (size_garbage / 1024));
> }
> else
> printf("%lu objects, %lu kilobytes\n",
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 19:13 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Michael J Gruber, Jonathan Nieder, Michael Schubert, Git List,
Jeff King
In-Reply-To: <CALkWK0nYRiPLnBXFarp8UzZgGvA5Y6motvr5HMFy56ANr161HA@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Junio C Hamano wrote:
>> [remote "origin"]
>> url = ... where Ram fetches and pulls from ...
>> pushurl = ... where Ram pushes to ...
>> fetch = refs/heads/*:refs/remotes/*
>> updateTrackOnPush = no
>>
>> Then "git fetch" (or "git pull") will update the remote tracking
>> branches Ram fetches from, and once his topic is finished, he can
>> push to his publishing location, which won't touch the remote
>> tracking branches used to keep track of the place he fetches from.
>
> A "push" should never touch remote/refs/origin/* if there is a pushurl
> configured. Otherwise, it should.
That is a horrible design, no?
Because one of the main use case for pushurl is to use url = git://
for less overhead and pushurl = ssh+git:// for authentication but
otherwise going to the same place. So if "git push" is allowed to
pretend you immediately turned around and fetched, push to that
pushurl will pretend it was followed by a fetch from the
corresponding url.
You need a way to tell if the pushurl/url pair is used for that
purpose to let Git know if that is the case.
^ permalink raw reply
* Re: Proposal: branch.<name>.remotepush
From: Junio C Hamano @ 2013-02-08 19:18 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Jonathan Nieder, Michael Schubert, Git List
In-Reply-To: <CALkWK0kR-KWJbG_kWSf7+JMJEQc7vO0Emx=_yogCB0jMBfccAg@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>
>>> And yes, a regular `git push origin refs/for/master` is just retarded.
>>
>> The usual incantation is "git push gerrit HEAD:refs/for/master". Is
>> the code review creation push that uses a different branchname from
>> the branch the integrator pulls what seems backward, or is it the need
>> to specify a refname at all on the command line?
>
> How else would you design a system to differentiate between a
> push-for-review, and push-to-update-ref?
You don't have to.
If the reviewed result is merged on the server side and appear on
'master', nobody has to push to update refs/heads/master.
^ permalink raw reply
* Re: [PATCH 1/6] graph: output padding for merge subsequent parents
From: John Keeping @ 2013-02-08 19:31 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Jeff King, Dale R. Worley, git
In-Reply-To: <b98eb2bfe2b022ddf1afbe9f7123accfe068e8c9.1360267849.git.john@keeping.me.uk>
[Moved from the thread where this was initially posted to reply to the
series.]
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> This works, but if we know we're not going to enter the while loop, it
> seams even easier to do this:
>
> --- a/graph.c
> +++ b/graph.c
> @@ -1227,7 +1227,17 @@ void graph_show_commit(struct git_graph *graph)
> if (!graph)
> return;
>
> - while (!shown_commit_line && !graph_is_commit_finished(graph)) {
> + /*
> + * When showing a diff of a merge against each of its parents, we
> + * are called once for each parent without graph_update having been
> + * called. In this case, simply output a single padding line.
> + */
> + if (graph_is_commit_finished(graph)) {
> + graph_show_padding(graph);
> + return;
> + }
> +
> + while (!shown_commit_line) {
This looks good to me. I'll amend locally and re-send in a few days
after giving others a chance to comment.
John
^ permalink raw reply
* Re: [PATCH] graph: output padding for merge subsequent parents
From: Junio C Hamano @ 2013-02-08 19:40 UTC (permalink / raw)
To: Matthieu Moy; +Cc: John Keeping, Dale R. Worley, git
In-Reply-To: <vpqtxpmae1p.fsf@grenoble-inp.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> John Keeping <john@keeping.me.uk> writes:
>
>> diff --git a/graph.c b/graph.c
>> index 391a712..2a3fc5c 100644
>> --- a/graph.c
>> +++ b/graph.c
>> @@ -1227,6 +1227,16 @@ void graph_show_commit(struct git_graph *graph)
>> if (!graph)
>> return;
>>
>> + /*
>> + * When showing a diff of a merge against each of its parents, we
>> + * are called once for each parent without graph_update having been
>> + * called. In this case, simply output a single padding line.
>> + */
>> + if (graph_is_commit_finished(graph)) {
>> + graph_show_padding(graph);
>> + shown_commit_line = 1;
>> + }
>> +
>> while (!shown_commit_line && !graph_is_commit_finished(graph)) {
>
> This works, but if we know we're not going to enter the while loop, it
> seams even easier to do this:
>
> --- a/graph.c
> +++ b/graph.c
> @@ -1227,7 +1227,17 @@ void graph_show_commit(struct git_graph *graph)
> if (!graph)
> return;
>
> - while (!shown_commit_line && !graph_is_commit_finished(graph)) {
> + /*
> + * When showing a diff of a merge against each of its parents, we
> + * are called once for each parent without graph_update having been
> + * called. In this case, simply output a single padding line.
> + */
> + if (graph_is_commit_finished(graph)) {
> + graph_show_padding(graph);
> + return;
> + }
> +
> + while (!shown_commit_line) {
> shown_commit_line = graph_next_line(graph, &msgbuf);
> fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
> if (!shown_commit_line)
In this particular case, with the current state of this function, it
is probably OK, but an early return like this tend to be a source of
future bugs in the longer term, to make the codeflow skip whatever
necessary clean-up that needs to be done after the loop exits.
^ permalink raw reply
* `git checkout --orpan` leaves a dirty worktree
From: Ramkumar Ramachandra @ 2013-02-08 19:50 UTC (permalink / raw)
To: Git List
Hi,
Why should I have to `git rm -rf .` after a `git checkout --orphan`?
What sort of misfeature/ incomplete feature is this?
Ram
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox