* Re: [PATCH] git-mergetool: check return value from read
From: Junio C Hamano @ 2011-09-20 0:41 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, David Aguilar
In-Reply-To: <1316475652-35188-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
>> I suspect that it would be more consistent with 6b44577 (mergetool: check
>> return value from read, 2011-07-01), which this patch is a follow-up to,
>> to do:
>>
>> read answer || return 1
>>
>> here.
>
> Thanks, sorry I missed that.
Thank _you_ for spotting these unchecked "read"s. Will queue.
^ permalink raw reply
* Re: how to remove unreachable objects?
From: Junio C Hamano @ 2011-09-20 0:40 UTC (permalink / raw)
To: Jeff King; +Cc: dieter, git
In-Reply-To: <20110919225219.GD4056@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> One possible use case might be when your repository is corrupt, and does
>> not pass "git fsck" (without any argument). In such a case, if you are
>> lucky and your disk corrupted objects only reachable from a recent topic
>> branch, you might find that this command:
>>
>> $ git fsck master next ...list other topics here...
>>
>> still succeeds, so that you can figure out which topic makes such a
>> limited fsck fail when it is listed on the command line, judge its
>> importance and resurrect what you can from there, before nuking it to
>> bring the repository back in health so that you can recreate the topic.
>
> Does that work? I had the impression from the documentation that the
> arguments are purely about the reachability analysis, and that the
> actual corruption/correctness checks actually look through the object db
> directly, making sure each object is well-formed. Skimming cmd_fsck
> seems to confirm that.
You are right that you may see "corrupt object" for unreachable from the
tips in the object store, but I was talking more about verifying
everything that is needed for reachability analysis from the given tips
can be read, iow, "missing object" errors, lack of which would mean you
can salvage everything reachable from the refs involved in the traversal.
^ permalink raw reply
* Re: Branching strategies
From: Andrew Ardill @ 2011-09-20 0:12 UTC (permalink / raw)
To: gitlist; +Cc: git
In-Reply-To: <4E778F15.9050705@myword.co.uk>
On 20 September 2011 04:51, gitlist <gitlist@myword.co.uk> wrote:
>> A very interesting read is
>> http://nvie.com/posts/a-successful-git-branching-model/
>>
>> It may not be perfect for you, however it does discuss some very
>> interesting issues, particularly how workflow is just as important as
>> the branching model.
>
>
> I came across the nvie post some time and it was very useful, but it doesn't
> address handling of feature branches, especially where there is overlap.
>
> I have a website where people can register. They can also buy things. If
> they haven't registered when they come to checkout, the checkout process
> includes registration. Users can also create "sponsorship" pages where they
> ask friends to sponsor them in a marathon etc. If someone setting up a
> sponsorship page is not already registered, it's included in the process.
>
> So there are three strands (to avoid using the word "branch") -
> registration, buying, and sponsorship - which end up affecting the same bits
> of code. Registration was done a year ago but recently needed updating;
> buying was started some months ago but got held up; sponsorship started
> recently, has been completed, and has "overtaken" buying.
>
> How should I use branches in this scenario? Or if I've got the concept
> wrong, how should I change my workflow?
>
> Thanks
>
> Roddie Grant
The concept of 'feature branches' apply primarily to development.They
allow you to build individual features for your system independently
of one another, and concurrently. Further, they provide a history of
commits that detail the effort that went in to creating that feature.
Once the feature is completed however, typically it will get merged
with a given release of the system. If further work is to be done on
that feature, either a new feature branch is created for the
'improvement', or a similar hot-fix/bug-fix branch is created. When
that work is done it gets merged either back on to the same release or
into a future release.
These feature branches do not host the separate functionality of the
system, but instead reveal the history of their development. I have
not heard of any intelligent way to use just an SCM to partition and
keep separate the different functional aspects of a system; developing
modules is generally achieved by writing modular code.
If you do have a number of modules you can track each of them
individually. Write version-dependencies into the modules, and you can
develop on them individually, updating them to depend on the latest
version as appropriate.
If you are not using well separated modules, and the development of
each 'thread' affects the same 'core' files, you need to migrate
changes to these core files between threads when appropriate. For
example, if you are working on the sponsorship thread, and develop a
paypal integration that you now want to include in the buying thread
(and can't continue developing it until you do), you should identify
the commits that entail that change and merge them into the buying
thread branch. Better than retrospectively trying to dig out features
and bug-fixes, however, is ensuring a clean separation of thread code
and core code. Thankfully, since git has such good merging ability,
you can often merge a feature branch which is miles behind the latest
release and it will slot in flawlessly.
There are many different aspects to this sort of work, but the best
thing to do is to keep the future in mind, and try to do things that
will make life easier down the track. The great thing about git is
that it offers many tools that make things easier later on even when
you didn't plan for them - but that is no excuse for poor planning!
Hope that helps somewhat,
Andrew
^ permalink raw reply
* Re: [PATCH/RFCv4 1/4] Documentation: Preparation for gitweb manpages
From: Jakub Narebski @ 2011-09-20 0:10 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Drew Northup, John 'Warthog9' Hawley, admin
In-Reply-To: <20110919233703.GF6343@elie>
Thanks a lot for all language fixes.
Nb. I'll respond to other comments separately.
On Tue, 20 Sep 2011, Jonathan Nieder wrote:
> Jakub Narebski wrote:
> > This way to build gitweb documentation one can use
> >
> > make -C gitweb doc
> >
> > or
> >
> > cd gitweb; make doc
Actually it should read "to build only gitweb documentation"...
> Does "make -CDocumentation man html" build the gitweb documentation,
> too (and "make install-doc" install it)?
>
> [...]
> > --- a/Documentation/Makefile
> > +++ b/Documentation/Makefile
> > @@ -170,6 +170,9 @@ info: git.info gitman.info
> >
> > pdf: user-manual.pdf
> >
> > +GITWEB_DOC = $(filter gitweb.%,$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7))
> > +gitweb-doc: $(GITWEB_DOC)
>
> Looks like no, alas.
... because of the fact that gitweb.txt is in DOC_MAN1, and gitweb.conf.txt
is in DOC_MAN5, then 'make doc' would among others build gitweb
documentation. 'make -C Documentation gitweb-doc' / 'make -C gitweb doc'
just builds a _subset_ of said documentation.
>
> Except for that detail, this looks good.
Nb. what is also missing is having links to gitweb(1) and gitweb.conf(5)
in git(1) manpages together with the rest.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] git-mergetool: check return value from read
From: Jay Soffian @ 2011-09-19 23:40 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, David Aguilar, Junio C Hamano
In-Reply-To: <7vaaa09skn.fsf@alter.siamese.dyndns.org>
Mostly fixed already by 6b44577 (mergetool: check return value
from read, 2011-07-01). Catch two uses it missed.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
On Mon, Sep 19, 2011 at 4:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> We still seem to miss one "read" unchecked in resolve_symlink_merge(),
> even with this patch.
> [...]
> I suspect that it would be more consistent with 6b44577 (mergetool: check
> return value from read, 2011-07-01), which this patch is a follow-up to,
> to do:
>
> read answer || return 1
>
> here.
Thanks, sorry I missed that.
git-mergetool--lib.sh | 2 +-
git-mergetool.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 8fc65d0400..ed630b208a 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -21,7 +21,7 @@ check_unchanged () {
do
echo "$MERGED seems unchanged."
printf "Was the merge successful? [y/n] "
- read answer
+ read answer || return 1
case "$answer" in
y*|Y*) status=0; break ;;
n*|N*) status=1; break ;;
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 3c157bcd26..b6d463f0d0 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -72,7 +72,7 @@ describe_file () {
resolve_symlink_merge () {
while true; do
printf "Use (l)ocal or (r)emote, or (a)bort? "
- read ans
+ read ans || return 1
case "$ans" in
[lL]*)
git checkout-index -f --stage=2 -- "$MERGED"
--
1.7.7.rc2.2.gdf97720
^ permalink raw reply related
* Re: [PATCH/RFCv4 1/4] Documentation: Preparation for gitweb manpages
From: Jonathan Nieder @ 2011-09-19 23:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Drew Northup, John 'Warthog9' Hawley, admin
In-Reply-To: <1316352884-26193-2-git-send-email-jnareb@gmail.com>
Jakub Narebski wrote:
> Gitweb documentation currently consist of gitweb/README, gitweb/INSTALL
> and comments in gitweb source code. This is harder to find, use and
> browse that manpages ("man gitweb" or "git help gitweb") and HTML
> documentation ("git help --web gitweb").
Language nits: s/consist/consists/; s/that manpages/than manpages/. I
completely agree.
> The goal is to move documentation out of gitweb/README to gitweb.txt and
> gitweb.conf.txt manpages, reducing its size 10x from around 500 to
> around 50 lines (two pages), and move information not related drectly to
> building and installing gitweb out of gitweb/INSTALL there.
I guess you mean this patch prepares for or is part of a larger
project or series with that goal? Wording nits: s/and move
information/and to move information/; s/drectly/directly/; s/ there//.
> The idea is to have gitweb manpage sources reside in AsciiDoc format
> in Documentation/ directory, like for gitk and git-gui. Alternate
> solution would be to have gitweb documentation in gitweb/ directory,
> perhaps in POD format (see perlpod(1)).
Language nits: missing "the" before "Documentation/ directory" and
"gitweb manpage sources"; missing "An" before "Alternate solution".
I guess this is the most controversial aspect of the patch; your idea
seems sane enough to me.
> This patch adds infrastructure for easy generating gitweb-related
> manpages. It adds currently empty 'gitweb-doc' target to
> Documentation/Makefile, and 'doc' proxy target to gitweb's Makefile.
Language nits: s/easy/easily/; missing "a" before "currently empty
'gitweb-doc' target" and "'doc' proxy target".
> This way to build gitweb documentation one can use
>
> make -C gitweb doc
>
> or
>
> cd gitweb; make doc
Language nit: a comma after "This way" would disambiguate.
Does "make -CDocumentation man html" build the gitweb documentation,
too (and "make install-doc" install it)?
[...]
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -170,6 +170,9 @@ info: git.info gitman.info
>
> pdf: user-manual.pdf
>
> +GITWEB_DOC = $(filter gitweb.%,$(DOC_HTML) $(DOC_MAN1) $(DOC_MAN5) $(DOC_MAN7))
> +gitweb-doc: $(GITWEB_DOC)
Looks like no, alas.
Except for that detail, this looks good.
Thanks,
Jonathan
^ permalink raw reply
* Re: how to remove unreachable objects?
From: Jeff King @ 2011-09-19 22:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: dieter, git
In-Reply-To: <7vsjns8b6m.fsf@alter.siamese.dyndns.org>
On Mon, Sep 19, 2011 at 02:38:41PM -0700, Junio C Hamano wrote:
> Yeah, I've been thinking about making it an error to give refs to fsck, as
> I do not think the use cases for feature justifies the possible confusion
> it may cause.
>
> One possible use case might be when your repository is corrupt, and does
> not pass "git fsck" (without any argument). In such a case, if you are
> lucky and your disk corrupted objects only reachable from a recent topic
> branch, you might find that this command:
>
> $ git fsck master next ...list other topics here...
>
> still succeeds, so that you can figure out which topic makes such a
> limited fsck fail when it is listed on the command line, judge its
> importance and resurrect what you can from there, before nuking it to
> bring the repository back in health so that you can recreate the topic.
Does that work? I had the impression from the documentation that the
arguments are purely about the reachability analysis, and that the
actual corruption/correctness checks actually look through the object db
directly, making sure each object is well-formed. Skimming cmd_fsck
seems to confirm that.
-Peff
^ permalink raw reply
* Re: gitk: 'j' and 'k' keyboard shortcuts backward
From: Klaus Robert Suetterlin @ 2011-09-19 22:05 UTC (permalink / raw)
To: Clemens Buchacher
Cc: Jonathan Nieder, Josh Triplett, Pat Thoyts, Paul Mackerras,
git@vger.kernel.org
In-Reply-To: <20110919180449.GA2677@ecki>
Fine with me, too.
--Robert S.
Am 19.09.2011 um 20:04 schrieb Clemens Buchacher <drizzd@aon.at>:
> On Mon, Sep 19, 2011 at 11:49:50AM -0500, Jonathan Nieder wrote:
>>
>> How about this patch?
>>
>> -- >8 --
>> Subject: gitk: Make vi-style keybindings more vi-like
>
> Fine by me.
>
> Clemens
^ permalink raw reply
* Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.
From: Jeff King @ 2011-09-19 22:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Mikaël, git
In-Reply-To: <7vwrd48bq8.fsf@alter.siamese.dyndns.org>
On Mon, Sep 19, 2011 at 02:26:55PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > [2] I suspect a similar thing happened with turning on packed refs
> > (around the v1.4.4 era?), but I didn't dig around for details.
>
> Also when bisecting down to really ancient versions of git, you may get
> complaints from the configuration reader. E.g.
>
> $ rungit v1.0.0 ls-files
> fatal: bad config file line 78 in .git/config
> $ sed -n 78p .git/config
> [remote "git-gui"]
Ugh, yeah. There are similar problems with some specific config options
(one I run into a lot these days is that "pager.foo" used to complain if
the value was non-boolean, but now you can put in an arbitrary command).
But those only bite you if you start using the new config options (which
you obviously are not doing until after you upgrade).
But your example will bite anyone because git generates remote config
like that by default.
Anyway, most of that is only applicable if you are crossing several
major version boundaries, or are using ancient versions of git. I'm
pretty sure that v1.7.0.x -> v1.7.6.x is pretty safe.
-Peff
^ permalink raw reply
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Junio C Hamano @ 2011-09-19 22:28 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Schwab, Chris Packham, git, chriscool, jepler
In-Reply-To: <20110919222325.GA4056@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Yeah. Doing:
>
> eval '$browser_cmd'
>
> will do the whitespace-breaking we want, but it won't interpret actual
> shell magic characters, which we need in order to be compatible with
> other parts of git (which typically use "sh -c ..."). E.g.:
>
> foo=worked
> browser_cmd='echo $foo'
Yikes, I forgot that we do that. You are right.
^ permalink raw reply
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Jeff King @ 2011-09-19 22:23 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Junio C Hamano, Chris Packham, git, chriscool, jepler
In-Reply-To: <m2bougtdc2.fsf@igel.home>
On Mon, Sep 19, 2011 at 11:46:37PM +0200, Andreas Schwab wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Thinking about it a bit more, I suspect that we should just let the 'eval'
> > grab value out of the $browser_cmd variable, i.e.
> >
> > eval '$browser_cmd "$@"'
> >
> > no?
>
> That's a Useless Use of Eval and 100% equivalent to this:
>
> $browser_cmd "$@"
Yeah. Doing:
eval '$browser_cmd'
will do the whitespace-breaking we want, but it won't interpret actual
shell magic characters, which we need in order to be compatible with
other parts of git (which typically use "sh -c ..."). E.g.:
foo=worked
browser_cmd='echo $foo'
# fail
$browser_cmd
# fail
eval '$browser_cmd'
# works
eval "$browser_cmd"
-Peff
^ permalink raw reply
* Re: Where is information of "git read-tree" stored?
From: Junio C Hamano @ 2011-09-19 22:09 UTC (permalink / raw)
To: Manuel Reimer; +Cc: git
In-Reply-To: <j586pb$emh$1@dough.gmane.org>
Manuel Reimer <Manuel.Spam@nurfuerspam.de> writes:
>> That "how to" may be badly written and this may have been unclear to you
>> but the first four steps are to be done _only once_ to set things up, and
>> after that you need to run only the fifth step whenever you want to update
>> from the Bproject. Could you suggest a better wording to update the doc?
>
> As long as I don't understand what's going on here, I can't suggest
> how to improve the documentation.
>
>> The very first "subtree merge" (the one that is recorded with the commit
>> after the read-tree) records all paths from Bproject renamed to elsewhere
>> in the merge result (you can view it with "git show -M
>> $that_merge_commit")
>
> Tried that, but the stuff, I saw on screen, doesn't make clear how GIT
> knew about what to do here.
To a certain degree, the point of a tool is that the user does not need to
know about the details, but if you are interested...
Suppose you have this tree structure in your "original" project:
Documentation/README.txt
hello.c
Makefile
and then somebody else has this structure in his project (in your case, it
may happen to be stored in SVN but once it is slurped in a git repository,
it does not matter):
goodbye.c
Makefile
Further suppose that you would want to end up with this tree structure:
Documentation/README.txt
Makefile
hello.c
imported/Makefile
imported/goodbye.c
i.e. you would want to move stuff that came from the other project in imported/
hierarchy. There may be many other files, and even subdirectories, in the
other project, but they all are shifted one level down and placed in imported/
hierarchy.
The first four steps of the howto is to create such a final tree structure
and make a merge commit out of that tree.
After you update your project (which now has both the original files such
as hello.c etc., may have added new files, and may even have updated stuff
inside imported/ hierarchy) and the other side updated their project (e.g.
it may have updated goodbye.c whose change you would want to carry over to
your imported/goodbye.c, or it may have added a new file welcome.c, which
you would want to import as imported/welcome.c), you would invoke "pull -s
subtree", which in turn runs "merge -s subtree".
The subtree strategy first compares the shapes of two trees being merged,
and tries to find how much they have to be shifted to match. Your tree
may now have:
Documentation/README.txt
Makefile
hello.h (added)
hello.c
imported/Makefile
imported/goodbye.c
while the other side may now have:
goodbye.c
Makefile
welcome.c
The subtree strategy notices that by prefixing "imported/" in front of the
paths, the tree from the other side will match the shape of the subtree
you have under "imported/". Thus it can pair:
their "goodbye.c" with your "imported/goodbye.c"
their "Makefile" with your "imported/Makefile"
their "welcome.c" with your "imported/welcome.c"
and merge the changes. The common ancestor commit of this merge will be
the initial merge you made with the first 4-step, so the three-way merge
logic would notice that there wasn't "welcome.c" in the beginning, they
added that path, while you did not do anything to the path that
corresponds to it (namely, "imported/welcome.c"), so the new "welcome.c"
file from the other project would simply be copied as "imported/welcome.c"
to your tree, and the change they made to "goodbye.c" and your changes you
made to your "imported/goodbye.c" will be merged and result is recorded in
your "imported/goodbye.c".
If "compares the shape and figures out how much to shift" makes you feel
uneasy (and it probably should), you can give an explicit directory prefix
as the backend option "subtree" (see "git merge help" for details).
^ permalink raw reply
* Git 1.7.6: Sparse checkouts do not work with directory exclusions
From: Joshua Jensen @ 2011-09-19 22:03 UTC (permalink / raw)
To: git@vger.kernel.org
Sometime after Git 1.7.3.2, sparse checkouts stopped working for me. My
sparse-checkout file looks something like:
*
!DirA/
!DirB/
DirC/
I have restored some lines of code that were removed in November 2010.
This resolves the sparse checkout issue for me, but my guess is the
solution is not implemented properly.
Can anyone confirm the issue and describe why those lines were removed?
Thanks.
Josh
---
dir.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/dir.c b/dir.c
index 6e4494e..3f057b6 100644
--- a/dir.c
+++ b/dir.c
@@ -507,7 +507,10 @@ int excluded_from_list(const char *pathname,
int to_exclude = x->to_exclude;
if (x->flags & EXC_FLAG_MUSTBEDIR) {
- if (*dtype == DT_UNKNOWN)
+ if (!prefixcmp(pathname, exclude) &&
+ pathname[x->patternlen] == '/')
+ return to_exclude;
+ else if (*dtype == DT_UNKNOWN)
*dtype = get_dtype(NULL, pathname, pathlen);
if (*dtype != DT_DIR)
continue;
--
1.7.6.msysgit.1
^ permalink raw reply related
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Andreas Schwab @ 2011-09-19 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Chris Packham, git, chriscool, jepler
In-Reply-To: <7v1uvc9qhz.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Thinking about it a bit more, I suspect that we should just let the 'eval'
> grab value out of the $browser_cmd variable, i.e.
>
> eval '$browser_cmd "$@"'
>
> no?
That's a Useless Use of Eval and 100% equivalent to this:
$browser_cmd "$@"
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: how to remove unreachable objects?
From: Junio C Hamano @ 2011-09-19 21:38 UTC (permalink / raw)
To: Jeff King; +Cc: dieter, git
In-Reply-To: <20110919201804.GB31930@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I was tempted to just drop this section entirely. It's mostly redundant
> with the DESCRIPTION section, and any extra details could be folded in
> there. The most useful bit is the "what do you do when there is
> corruption". But that should perhaps get its own section, if somebody
> feels like writing something more detailed (I thought we had a guide
> somewhere, but I couldn't find it).
Yeah, I've been thinking about making it an error to give refs to fsck, as
I do not think the use cases for feature justifies the possible confusion
it may cause.
One possible use case might be when your repository is corrupt, and does
not pass "git fsck" (without any argument). In such a case, if you are
lucky and your disk corrupted objects only reachable from a recent topic
branch, you might find that this command:
$ git fsck master next ...list other topics here...
still succeeds, so that you can figure out which topic makes such a
limited fsck fail when it is listed on the command line, judge its
importance and resurrect what you can from there, before nuking it to
bring the repository back in health so that you can recreate the topic.
^ permalink raw reply
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Jakub Narebski @ 2011-09-19 21:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Chris Packham, git, chriscool, jepler
In-Reply-To: <7vvcso9zzi.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
> > If you want to make a test, I think you would do better with something
> > like:
> >
> > echo someurl_with_&_in_it >expect &&
> > git config browser.custom.cmd echo &&
> > git web--browse --browser=custom someurl_with_&_in_it >actual &&
> > test_cmp expect actual
> >
> > That won't test that we are invoking kfmclient correctly, obviously, but
> > you can confirm at least that URLs are making it through to the browser
> > script intact.
>
> Hmm, isn't '&' somewhat an unusual in URL? ...ah, not really, if it is in
> the query parameter part it is quite common.
In newstyle URLs the name=value pairs in CGI parameter query string
are separated with semicolons ';' rather than ampersands '&', because
of problem with & <-> &.
Just FYI.
--
Jakub Narębski
^ permalink raw reply
* Re: upgrading GIT from version 1.7.0.4 to 1.7.6.1.
From: Junio C Hamano @ 2011-09-19 21:26 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, Mikaël, git
In-Reply-To: <20110919190023.GC26115@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> [2] I suspect a similar thing happened with turning on packed refs
> (around the v1.4.4 era?), but I didn't dig around for details.
Also when bisecting down to really ancient versions of git, you may get
complaints from the configuration reader. E.g.
$ rungit v1.0.0 ls-files
fatal: bad config file line 78 in .git/config
$ sed -n 78p .git/config
[remote "git-gui"]
^ permalink raw reply
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Junio C Hamano @ 2011-09-19 21:22 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Chris Packham, git, chriscool, jepler
In-Reply-To: <20110919204448.GA3562@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Sep 19, 2011 at 01:42:23PM -0700, Junio C Hamano wrote:
>
>> >> Yeah, I agree, and the dq around $browser_cmd is kind of important, too,
>> >> for that to work and be readable.
>> >
>> > Oops, good catch. Probably the most readable version would be:
>> >
>> > eval "\"$browser_cmd\"" '"$@"'
>>
>> Actually I didn't mean that double dq.
>>
>> In fact, if browser_cmd is meant to be split as a shell snippet, I do not
>> think you want the string seen by eval to have dq around the expanded
>> version of $browser_cmd. And I tend to prefer feeding a single string to
>> eval, so the version in your message I quoted originally looks good to me.
>>
>> Unless I am missing something here...?
>
> Oh right. Sorry, I read your comment, thought that's what you meant, and
> that I had overlooked something. Forgetting that it was intentional to
> leave off the quotes inside.
>
> So yeah, my original is right. I just got turned around in all of the
> discussion.
Thinking about it a bit more, I suspect that we should just let the 'eval'
grab value out of the $browser_cmd variable, i.e.
eval '$browser_cmd "$@"'
no?
^ permalink raw reply
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Jeff King @ 2011-09-19 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Packham, git, chriscool, jepler
In-Reply-To: <7v62ko9scw.fsf@alter.siamese.dyndns.org>
On Mon, Sep 19, 2011 at 01:42:23PM -0700, Junio C Hamano wrote:
> >> Yeah, I agree, and the dq around $browser_cmd is kind of important, too,
> >> for that to work and be readable.
> >
> > Oops, good catch. Probably the most readable version would be:
> >
> > eval "\"$browser_cmd\"" '"$@"'
>
> Actually I didn't mean that double dq.
>
> In fact, if browser_cmd is meant to be split as a shell snippet, I do not
> think you want the string seen by eval to have dq around the expanded
> version of $browser_cmd. And I tend to prefer feeding a single string to
> eval, so the version in your message I quoted originally looks good to me.
>
> Unless I am missing something here...?
Oh right. Sorry, I read your comment, thought that's what you meant, and
that I had overlooked something. Forgetting that it was intentional to
leave off the quotes inside.
So yeah, my original is right. I just got turned around in all of the
discussion.
Sorry for the noise.
-Peff
^ permalink raw reply
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Andreas Schwab @ 2011-09-19 20:44 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Chris Packham, git, chriscool, jepler
In-Reply-To: <20110919182049.GA26115@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Sep 19, 2011 at 10:57:37AM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > Hmm. Actually, the one for custom browser commands might need it,
>> > because that one is expected to be a shell snippet. I suspect the
>> > simplest thing is to do something like:
>> >
>> > eval "$browser_cmd \"\$@\""
>>
>> Yeah, I agree, and the dq around $browser_cmd is kind of important, too,
>> for that to work and be readable.
>
> Oops, good catch. Probably the most readable version would be:
>
> eval "\"$browser_cmd\"" '"$@"'
This make the use of eval even more questionable. If $browser_cmd is
supposed to be whitespace splitted then this won't do it (unless it
contains embedded double quotes).
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] git-web--browse: invoke kfmclient directly
From: Junio C Hamano @ 2011-09-19 20:42 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Packham, git, chriscool, jepler
In-Reply-To: <20110919182049.GA26115@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Sep 19, 2011 at 10:57:37AM -0700, Junio C Hamano wrote:
>
>> Jeff King <peff@peff.net> writes:
>>
>> > Hmm. Actually, the one for custom browser commands might need it,
>> > because that one is expected to be a shell snippet. I suspect the
>> > simplest thing is to do something like:
>> >
>> > eval "$browser_cmd \"\$@\""
>>
>> Yeah, I agree, and the dq around $browser_cmd is kind of important, too,
>> for that to work and be readable.
>
> Oops, good catch. Probably the most readable version would be:
>
> eval "\"$browser_cmd\"" '"$@"'
Actually I didn't mean that double dq.
In fact, if browser_cmd is meant to be split as a shell snippet, I do not
think you want the string seen by eval to have dq around the expanded
version of $browser_cmd. And I tend to prefer feeding a single string to
eval, so the version in your message I quoted originally looks good to me.
Unless I am missing something here...?
^ permalink raw reply
* Re: [PATCH] git-mergetool--lib.sh: make check_unchanged return 1 on invalid read
From: Junio C Hamano @ 2011-09-19 20:37 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, David Aguilar
In-Reply-To: <1316462592-27255-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Else when the user hits ctrl-c at the "Was the merge successful?
> [y/n]" prompt, mergetool goes into an infinite loop asking
> for input.
>
> Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
We still seem to miss one "read" unchecked in resolve_symlink_merge(),
even with this patch.
> git-mergetool--lib.sh | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index 8fc65d0400..0eb424484c 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -21,7 +21,11 @@ check_unchanged () {
> do
> echo "$MERGED seems unchanged."
> printf "Was the merge successful? [y/n] "
> - read answer
> + if ! read answer
> + then
> + status=1
> + break
> + fi
I suspect that it would be more consistent with 6b44577 (mergetool: check
return value from read, 2011-07-01), which this patch is a follow-up to,
to do:
read answer || return 1
here.
Thanks.
^ permalink raw reply
* Re: how to remove unreachable objects?
From: Andreas Schwab @ 2011-09-19 20:36 UTC (permalink / raw)
To: dieter; +Cc: git
In-Reply-To: <20110919110831.ewq03vnqos4w8cs8@webmail.edis.at>
dieter@schoen.or.at writes:
> if you look at the output of this script then you see that git knows
> that there
> are unreachable/dangling objects, but they remain.
You also need to prune the reflog of HEAD.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: how to remove unreachable objects?
From: Jeff King @ 2011-09-19 20:18 UTC (permalink / raw)
To: dieter; +Cc: Junio C Hamano, git
In-Reply-To: <20110919195335.GA31930@sigill.intra.peff.net>
On Mon, Sep 19, 2011 at 03:53:36PM -0400, Jeff King wrote:
> > git fsck --unreachable HEAD \
> > $(git for-each-ref --format="%(objectname)" refs/heads)
>
> And this shows it as unreachable, because you are asking git to only
> look at the branch tips and HEAD (by default, it looks at all refs and
> reflogs).
>
> I suspect you copied this straight from the git-fsck manpage. That
> advice is a bit outdated, I think. It blames (in some form) all the way
> back to the original documentation added in c64b9b8 (2005-05-05, only a
> few weeks after git was born). A few weeks later, fsck learned to
> default to looking at all refs (1024932, 2005-05-18). And then other
> sane defaults like reflogs got tacked on later (reflogs came around the
> 1.4.x era, in 2006).
So we should probably do something like this:
-- >8 --
Subject: [PATCH] docs: brush up obsolete bits of git-fsck manpage
After the description and options, the fsck manpage contains
some discussion about what it does. Over time, this
discussion has become somewhat obsolete, both in content and
formatting. In particular:
1. There are many options now, so starting the discussion
with "It tests..." makes it unclear whether we are
talking about the last option, or about the tool in
general. Let's start a new "discussion" section and
make our antecedent more clear.
2. It gave an example for --unreachable using for-each-ref
to mention all of the heads, saying that it will do "a
_lot_ of verification". This is hopelessly out-of-date,
as giving no arguments will check much more (reflogs,
the index, non-head refs).
3. It goes on to mention tests "to be added" (like tree
object sorting). We now have these tests.
Signed-off-by: Jeff King <peff@peff.net>
---
I was tempted to just drop this section entirely. It's mostly redundant
with the DESCRIPTION section, and any extra details could be folded in
there. The most useful bit is the "what do you do when there is
corruption". But that should perhaps get its own section, if somebody
feels like writing something more detailed (I thought we had a guide
somewhere, but I couldn't find it).
Documentation/git-fsck.txt | 26 ++++++++------------------
1 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index a2a508d..55b33d7 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -72,30 +72,20 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
a blob, the contents are written into the file, rather than
its object name.
-It tests SHA1 and general object sanity, and it does full tracking of
-the resulting reachability and everything else. It prints out any
-corruption it finds (missing or bad objects), and if you use the
-'--unreachable' flag it will also print out objects that exist but
-that aren't reachable from any of the specified head nodes.
-
-So for example
-
- git fsck --unreachable HEAD \
- $(git for-each-ref --format="%(objectname)" refs/heads)
+DISCUSSION
+----------
-will do quite a _lot_ of verification on the tree. There are a few
-extra validity tests to be added (make sure that tree objects are
-sorted properly etc), but on the whole if 'git fsck' is happy, you
-do have a valid tree.
+git-fsck tests SHA1 and general object sanity, and it does full tracking
+of the resulting reachability and everything else. It prints out any
+corruption it finds (missing or bad objects), and if you use the
+'--unreachable' flag it will also print out objects that exist but that
+aren't reachable from any of the specified head nodes (or the default
+set, as mentioned above).
Any corrupt objects you will have to find in backups or other archives
(i.e., you can just remove them and do an 'rsync' with some other site in
the hopes that somebody else has the object you have corrupted).
-Of course, "valid tree" doesn't mean that it wasn't generated by some
-evil person, and the end result might be crap. git is a revision
-tracking system, not a quality assurance system ;)
-
Extracted Diagnostics
---------------------
--
1.7.7.rc1.3.gb95be
^ permalink raw reply related
* Re: [PATCH] t4014: remove Message-Id/timestamp before comparing patches
From: Junio C Hamano @ 2011-09-19 20:15 UTC (permalink / raw)
To: Jeff King; +Cc: Thomas Rast, Pang Yan Han, git
In-Reply-To: <20110919191545.GD26115@sigill.intra.peff.net>
Thanks, your fix makes a lot more sense.
^ 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