* Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@<rev>' syntax
From: John Szakmeister @ 2011-09-13 9:15 UTC (permalink / raw)
To: Eric Wong
Cc: Ramsay Jones, Sam Vilain, Michael J Gruber, Junio C Hamano,
GIT Mailing-list, mhagger
In-Reply-To: <20110913075726.GA15066@dcvr.yhbt.net>
On Tue, Sep 13, 2011 at 3:57 AM, Eric Wong <normalperson@yhbt.net> wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>> Hmm, I was hoping that someone would say something like:
>>
>> "This test does not depend on the difference between the peg revision
>> and the operative revision, because the history represented in the test
>> repo is so simple that there *is* no difference, so Acked By: ... "
>
> Unfortunately, I remain perpetually confused w.r.t peg revisions vs "-r"
> and how it's handled differently between different SVN versions.
I haven't followed this conversation, but I can explain what peg
revisions are. It used to be the only way to talk about a version of
a file or path was to use '-r REVNUM'. IIRC, what would happen is
that the url you provided would refer to the now current name of the
file, and Subversion would walk back in history to look up the
specified version of the file. However, that becomes a problem when
the file no longer exists, or has been renamed. It's compounded if
there is a new file with the same name in HEAD, because it would look
up the wrong history. So peg revisions were introduced to say "start
looking here @PEGREV and search forward or backwards for the version
in REVNUM." So the difference is that old clients always looked at
HEAD to start the search, whereas new clients will use PEGREV if
specified, and HEAD otherwise.
There is a pretty thorough discussion of it in the SVN book:
<http://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html>
Hope that helps!
-John
^ permalink raw reply
* Re: git credential helper design [was: What's cooking in git.git (Aug 2011, #07; Wed, 24)]
From: John Szakmeister @ 2011-09-13 8:29 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Lukas Sandström, Ted Zlatanov, git
In-Reply-To: <20110910065332.GA10935@sigill.intra.peff.net>
On Sat, Sep 10, 2011 at 2:53 AM, Jeff King <peff@peff.net> wrote:
> On Fri, Sep 09, 2011 at 05:55:38AM -0400, John Szakmeister wrote:
>
>> A little feedback here: I do look into my keychain on Mac OS X. I
>> tend to keep most of my credentials in a separate keychain that gets
>> whenever my computer sleeps or the screen saver kicks on. So that
>> blob ends up being user-visible to some degree. Could I munge it into
>> something else? Sure. But I do wonder if it might be better to make
>> it something closer to what the user expects to see.
>
> Sure, I agree. I guess my question is: what does the user expect to see?
Originally I was going to use SecKeychainFindGenericPassword(), and
the token would have been the "serviceName". However,
SecKeychainFindInternetPassword() is clearly the better fit, which
means busting out the individual bits.
[snip]
> Perhaps it's worth providing the information in two forms: parsed and
> broken out by individual pieces, and as a more opaque blob. Then systems
> which care can use the pieces, and systems which are trying to be as
> simple as possible can use the blob.
That would be useful. Right now, it looks like I'll be parsing the token.
> That still leaves the question of how the user specifies policy about
> which parts of the blob are relevant. That is, how do they say that only
> the "domain" portion of the hostname is relevant? Or that the path is or
> is not relevant?
>
> I was really hoping for the user to be able to specify this at the git
> level, to give each storage helper roughly the same feature set.
Ooh... yeah, I'm not sure. :-(
> Maybe it would be enough to do something like:
>
> 1. Assemble all of the parts (protocol, username (if any), hostname,
> path) into a canonicalized URL representing the authentication
> context.
>
> 2. Look for git config matching the context URL, and allow
> transformations (e.g., match and replace the whole thing, or even
> regexp-style substitution).
That seems burdensome. There is a method in HTTP/HTTPS for saying
"use this set of credentials". You'd do that via the security domain.
That doesn't necessarily apply to other urls (ssh, for example), but
it would allow a storage backend to cache it for a specific path, but
fallback to looking up the credential using the security domain.
[snip]
> I think this is somewhat outside the boundaries of what git can provide.
> We don't know whether we are interactive or not; we can only make
> guesses based on things like whether there is a terminal available. The
> helper should be able to make an even better guess, because it can ask
> for system-specific things (e.g., a Linux one might check whether
> $DISPLAY is set before trying to pop up a dialog). And helpers are free
> to simply return nothing. Even though most people will only configure a
> single helper, there is actually a stack, and git will try the next one,
> and so on until it gets an answer (or if it hits the end without an
> answer, will complain).
Okay, I won't worry about it then. Thanks Jeff!
-John
^ permalink raw reply
* Re: [PATCH v2] git-svn: teach git-svn to populate svn:mergeinfo
From: Eric Wong @ 2011-09-13 8:18 UTC (permalink / raw)
To: Bryan Jacobs; +Cc: git, Sam Vilain
In-Reply-To: <20110912102422.21aa6570@robyn.woti.com>
Bryan Jacobs <bjacobs@woti.com> wrote:
> Thanks for the help and review. I'll let you do the cleanup and push
> the resulting patch when you feel it's ready (as you suggested), rather
> than iterating again for these small changes.
OK, it's pushed to "master" on git://bogomips.org/git-svn.git
as commit 1e5814f3def08452aef4caa703f074ba7d167867.
On a side note, if you have more changes you want to make (and have free
time :) git-svn.perl would really benefit from being split into
separate .pm files for ease-of-maintenance.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: John Szakmeister @ 2011-09-13 7:51 UTC (permalink / raw)
To: Eric Sunshine
Cc: Junio C Hamano, Jeff King, git, Boaz Harrosh, Brandon Casey,
Thomas Rast, Alexey Shumkin
In-Reply-To: <4E6E928A.6080003@sunshineco.com>
On Mon, Sep 12, 2011 at 7:15 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
[snip]
> Shouldn't the last entry be?
>
> "*.m diff=objc",
Or maybe not there at all? We tend to do quite a bit with Matlab, and
Matlab scripts also end in ".m". Unfortunately, it bears little
resemblance to Objective-C.
-John
^ permalink raw reply
* Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@<rev>' syntax
From: Eric Wong @ 2011-09-13 7:57 UTC (permalink / raw)
To: Ramsay Jones
Cc: Sam Vilain, Michael J Gruber, Junio C Hamano, GIT Mailing-list,
mhagger
In-Reply-To: <4E6BA0FA.9070103@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
> Hmm, I was hoping that someone would say something like:
>
> "This test does not depend on the difference between the peg revision
> and the operative revision, because the history represented in the test
> repo is so simple that there *is* no difference, so Acked By: ... "
Unfortunately, I remain perpetually confused w.r.t peg revisions vs "-r"
and how it's handled differently between different SVN versions.
> But, since that didn't happen, maybe the patch given below would be more
> acceptable? (I personally prefer the original patch ...)
I'm much more comfortable with your below patch as it won't break
on newer (and increasingly more widely-used) versions.
> Given that I didn't quite follow Sam's explanation, I still don't know
> if t9104-git-svn-follow-parent.sh needs to be changed (again, this test
> *passes* for me), so ... :-P
> Subject: [PATCH] t9159-*.sh: Add an svn version check
How about something along the lines of:
Subject: [PATCH] t9159-*.sh: skip for mergeinfo test for svn <= 1.4
t9159 relies on the command-line syntax of svn >= 1.5.
Given the declining install base of older svn versions,
it is not worth our time to support older svn syntax.
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
?
> diff --git a/t/t9159-git-svn-no-parent-mergeinfo.sh b/t/t9159-git-svn-no-parent-mergeinfo.sh
> index 85120b7..69e4815 100755
> --- a/t/t9159-git-svn-no-parent-mergeinfo.sh
> +++ b/t/t9159-git-svn-no-parent-mergeinfo.sh
> @@ -2,6 +2,14 @@
> test_description='git svn handling of root commits in merge ranges'
> . ./lib-git-svn.sh
>
> +svn_ver="$(svn --version --quiet)"
> +case $svn_ver in
> +0.* | 1.[0-4].*)
> + skip_all="skipping git-svn test - SVN too old ($svn_ver)"
> + test_done
> + ;;
> +esac
> +
> test_expect_success 'test handling of root commits in merge ranges' '
> mkdir -p init/trunk init/branches init/tags &&
> echo "r1" > init/trunk/file.txt &&
> --
^ permalink raw reply
* Re: Status of git-remote-hg
From: Sverre Rabbelier @ 2011-09-13 7:40 UTC (permalink / raw)
To: Andrew Ardill; +Cc: git
In-Reply-To: <CAH5451=aYft1QoTdKA=iiLxw+OLqE8bGvd5j_UoP0Jmufc49eA@mail.gmail.com>
Heya,
On Tue, Sep 13, 2011 at 09:35, Andrew Ardill <andrew.ardill@gmail.com> wrote:
> Hi there, I can't seem to find many references to git-remote-hg lying
> around. There were some commits by Sverre Rabbelier
> (http://thread.gmane.org/gmane.comp.version-control.git/154669)
> preparing for it, but I couldn't find much else.
You can try my git-remote-hg branch on github [0]. It's currently a
bit buggy (in particular, I don't think it works with the latest
version of hg without a few patches), and won't be included in git.git
until I reroll the fe-fixes series, which I haven't had time for.
[0] https://github.com/SRabbelier/git/tree/remote-hg
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Status of git-remote-hg
From: Andrew Ardill @ 2011-09-13 7:35 UTC (permalink / raw)
To: git; +Cc: srabbelier
Hi there, I can't seem to find many references to git-remote-hg lying
around. There were some commits by Sverre Rabbelier
(http://thread.gmane.org/gmane.comp.version-control.git/154669)
preparing for it, but I couldn't find much else.
I have been looking for a way to use git to directly interact with
remote mercurial repositories, however I can only find examples using
hg-git and hg-fast-export. These feel clumsy, and I hoped the
git-remote-hg work would make them unnecessary.
Any news on that, or tips in general would be appreciated.
Regards,
Andrew Ardill
^ permalink raw reply
* [PATCH v2] Documentation: basic configuration of notes.rewriteRef
From: Thomas Rast @ 2011-09-13 7:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King
In-Reply-To: <7vzki92wdc.fsf@alter.siamese.dyndns.org>
Users had problems finding a working setting for notes.rewriteRef.
Document how to enable rewriting for notes/commits, which should be a
safe setting.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Junio C Hamano wrote:
> Should we drop this post 1.7.7, or (preferrably) replace it with better
> instructions?
I'd replace it with this bit. Users who have trouble setting the
variable to something useful will likely not know how to edit
non-default notes trees, either.
Documentation/config.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0ecef9d..0813812 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1464,7 +1464,8 @@ notes.rewriteRef::
You may also specify this configuration several times.
+
Does not have a default value; you must configure this variable to
-enable note rewriting.
+enable note rewriting. Set it to `refs/notes/commits` to enable
+rewriting for the default commit notes.
+
This setting can be overridden with the `GIT_NOTES_REWRITE_REF`
environment variable, which must be a colon separated list of refs or
--
1.7.7.rc0.487.g1b75
^ permalink raw reply related
* Re: [PATCH v2 0/7] Improved infrastructure for refname normalization
From: Michael Haggerty @ 2011-09-13 4:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, cmn, A Large Angry SCM
In-Reply-To: <7vwrdd90df.fsf@alter.siamese.dyndns.org>
On 09/12/2011 06:44 PM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
>> OTOH I am again having serious doubts that trying to support
>> unnormalized refnames is a good idea.
>
> Sorry, I am confused. I thought the way you are planning forward is to
> leave unnormalized ones unchecked as the current code does (and mark the
> places that do so with _unsafe()), with the eventual goal of fixing the
> caller to pass only normalized ones to make call to the "safe" version?
That was the plan, but after my experience trying to fix this problem I
have come to doubt that it is doable within a reasonable amount of work
or even that support for unnormalized refnames is desirable. The
problem is that the API provided by refs.{c,h} is far from waterproof,
and I keep finding more code elsewhere that manipulates and parses
refnames and makes implicit assumptions (sometimes spread over many
functions) about their form.
Consistency of the UI should be the goal. Supporting unnormalized
refnames some places, but not others, will just confuse and frustrate
users. The only two consistent alternatives are
1. Unnormalized refnames are supported everywhere in the UI that
refnames are accepted, including clients like gitweb, gitk, egit, etc.
2. Only normalized refnames are supported; unnormalized refnames are
errors that we report on a best-effort basis.
Option (1) has a number of problems:
* Claiming to support unnormalized refnames is far from the current
situation; therefore lots of current code would have to be considered
broken.
* Fixing the code requires many new unit tests and fixes to many areas
of the code, including clients outside of the main git project. I have
tried fixing a couple of examples ("git branch", "git rev-parse", and
the first argument of "git update-ref") and it is pretty messy.
* Some of the needed changes seem like they might conflict with other
forms of DWIM; for example, the ambiguous_path() kludge.
* The extra copying needed for normalization has a runtime cost and
complicates memory management.
* Unnormalized refnames are *themselves* a form of UI inconsistency and
therefore not a very noble goal. It is better that people learn that
each reference has a single name, and unlearn that references were once
1:1 with files under .git/refs.
What is the benefit of (2) that justifies all of this work? To enable
sloppy script writers to throw slashes around carelessly?
Option (1) would be far easier. Then code only needs to treat
unnormalized refnames like any other kind of invalid refname rather than
making sure that unnormalized refnames work properly in combination with
all other features.
So I propose the following:
* Institute a policy that refnames in the UI must always be normalized
* On a best-effort basis, emit errors whenever unnormalized refnames are
encountered
* Continue to support "git check-ref-format --print", which script
writers can use to normalize refnames if they need to.
The only disadvantage of a stricter policy is that some of today's
sloppy scripts, which today might sometimes work (but not reliably),
break in a pretty obvious way that can be fixed with a single call to
"git check-ref-format --print".
I'd rather get beyond this swamp and start working on the hierarchical
reference cache, which will bring some real benefits. (The hierarchical
reference cache requires some sanity in refname handling, which is why I
got into this mess in the first place.)
What do people think?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* Re: Okay to invoke merge-recursive with an empty workdir?
From: Jeff King @ 2011-09-13 3:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, git
In-Reply-To: <7v4o0h14gv.fsf@alter.siamese.dyndns.org>
On Mon, Sep 12, 2011 at 08:55:12PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > I'm not sure if we were ever using merge-recursive like that. Especially
> > with Elijah's latest patches to handle worktree dirtiness better, I
> > wouldn't be surprised if it has issues.
>
> I am parsing the above as "seeing the need for such an extensive fix-up,
> it is not surprising if the base code is broken", and I have to agree.
Well, both. I assume that merge-recursive now cares more than ever about
what is in the working tree, because I seem to recall Elijah handling
some cases with untracked files. And also, his patches have given me no
faith whatsoever in the quality of the underlying code. :)
> In principle, "git merge" should be usable in an empty working tree in the
> sense that with correctly populated index the absense of the working tree
> file is _meant_ to be treated the same as having the file unchanged from
> the index and the HEAD version, but I suspect that "merge-recursive" is
> pretty much broken with that regard.
>
> I have much more faith in "git merge -s resolve" performing correctly.
Agreed, though I haven't tried it.
-Peff
^ permalink raw reply
* Re: [PATCH] t3200: test branch creation with -v
From: Jeff King @ 2011-09-13 3:57 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano
In-Reply-To: <4E6B6647.7090802@drmicha.warpmail.net>
On Sat, Sep 10, 2011 at 03:29:43PM +0200, Michael J Gruber wrote:
> Jeff King venit, vidit, dixit 09.09.2011 21:43:
> > On Fri, Sep 09, 2011 at 09:40:59PM +0200, Michael J Gruber wrote:
> >
> >> +test_expect_success 'git branch -v t should work' ' + git branch
> >> -v t && + test .git/refs/heads/t &&
> >
> > test -f ?
> >
> > Also, don't we have test_path_is_file which yields slightly prettier
> > output (and maybe some portability benefits; I don't remember)?
> >
> >> + git branch -d t && + test ! -f .git/refs/heads/t
> >
> > Ditto for 'test_path_is_missing' here.
> >
> > -Peff
>
> Well, I tried to follow the surrounding style. That t3200 could benefit
> from some attention, though, which I did not want to mix in with the
> issue at hand.
The "test_path_is_file" thing is style. But not using "test -f" is just
wrong; you are testing "is .git/refs/heads/t an empty string?" which is
useless.
You want this on top of what's in mg/branch-list:
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index c466b20..b513115 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -100,14 +100,14 @@ test_expect_success 'git branch -m q r/q should fail when r exists' '
test_expect_success 'git branch -v -d t should work' '
git branch t &&
- test .git/refs/heads/t &&
+ test -f .git/refs/heads/t &&
git branch -v -d t &&
test ! -f .git/refs/heads/t
'
test_expect_success 'git branch -v -m t s should work' '
git branch t &&
- test .git/refs/heads/t &&
+ test -f .git/refs/heads/t &&
git branch -v -m t s &&
test ! -f .git/refs/heads/t &&
test -f .git/refs/heads/s &&
@@ -116,7 +116,7 @@ test_expect_success 'git branch -v -m t s should work' '
test_expect_success 'git branch -m -d t s should fail' '
git branch t &&
- test .git/refs/heads/t &&
+ test -f .git/refs/heads/t &&
test_must_fail git branch -m -d t s &&
git branch -d t &&
test ! -f .git/refs/heads/t
@@ -124,7 +124,7 @@ test_expect_success 'git branch -m -d t s should fail' '
test_expect_success 'git branch --list -d t should fail' '
git branch t &&
- test .git/refs/heads/t &&
+ test -f .git/refs/heads/t &&
test_must_fail git branch --list -d t &&
git branch -d t &&
test ! -f .git/refs/heads/t
I suspect you didn't notice the bogosity before because those are just
confirming the precondition that "git branch" actually created the file.
-Peff
^ permalink raw reply related
* Re: Okay to invoke merge-recursive with an empty workdir?
From: Junio C Hamano @ 2011-09-13 3:55 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, git
In-Reply-To: <20110913032900.GA3296@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I'm not sure if we were ever using merge-recursive like that. Especially
> with Elijah's latest patches to handle worktree dirtiness better, I
> wouldn't be surprised if it has issues.
I am parsing the above as "seeing the need for such an extensive fix-up,
it is not surprising if the base code is broken", and I have to agree.
In principle, "git merge" should be usable in an empty working tree in the
sense that with correctly populated index the absense of the working tree
file is _meant_ to be treated the same as having the file unchanged from
the index and the HEAD version, but I suspect that "merge-recursive" is
pretty much broken with that regard.
I have much more faith in "git merge -s resolve" performing correctly.
^ permalink raw reply
* Re: Okay to invoke merge-recursive with an empty workdir?
From: Jeff King @ 2011-09-13 3:29 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <CAG+J_Dyz-aeLYn43ARTG4GJz0+zRw_RyDr80bmPCayd9BjzCwg@mail.gmail.com>
On Mon, Sep 12, 2011 at 11:13:37PM -0400, Jay Soffian wrote:
> So my approach is to create a temporary, empty, workdir, using
> symlinks to point to the parent repo per git new-workdir.
>
> I then invoke merge-recursive directly inside the temporary workdir.
>
> The question is whether this is safe to do, or whether merge-recursive
> expects a fully populated working tree that matches the index. My easy
> test cases seem to work correctly, but I'm concerned that I sometimes
> get:
I'm not sure if we were ever using merge-recursive like that. Especially
with Elijah's latest patches to handle worktree dirtiness better, I
wouldn't be surprised if it has issues.
What we do now at GitHub is something like:
export GIT_WORK_TREE=/some/tmpdir
export GIT_INDEX_FILE=/some/tmpfile
git read-tree -i -m --aggressive $merge_base $us $them
git merge-index git-merge-one-file -a
I also have a patch to do the content-level merge in read-tree without
touching the filesystem at all. But we're not using it yet, and I should
probably write more tests for it. You can see it at:
git://github.com/peff/git.git jk/read-tree-content-merge
It should produce the same results as the snippet above, but faster.
Both of those will obviously not handle renames or do recursive merges
like merge-recursive, of course.
-Peff
^ permalink raw reply
* Okay to invoke merge-recursive with an empty workdir?
From: Jay Soffian @ 2011-09-13 3:13 UTC (permalink / raw)
To: git, Jeff King
I have an unattended script which performs automated merges into
several destination branches.
As the repo is fairly large, I'd like not to have to checkout each
destination branch, nor have multiple workdirs.
So my approach is to create a temporary, empty, workdir, using
symlinks to point to the parent repo per git new-workdir.
I then invoke merge-recursive directly inside the temporary workdir.
The question is whether this is safe to do, or whether merge-recursive
expects a fully populated working tree that matches the index. My easy
test cases seem to work correctly, but I'm concerned that I sometimes
get:
Skipped /some/file (merged same as existing)
error: addinfo_cache failed for path '/some/file'
Skipped some/other_file (merged same as existing)
error: addinfo_cache failed for path 'some/other_file'
Which seems to be from this code in merge-recursive.cc:
if (mfi.clean && !df_conflict_remains &&
sha_eq(mfi.sha, a_sha) && mfi.mode == a_mode) {
int path_renamed_outside_HEAD;
output(o, 3, "Skipped %s (merged same as existing)", path);
/*
* The content merge resulted in the same file contents we
* already had. We can return early if those file contents
* are recorded at the correct path (which may not be true
* if the merge involves a rename).
*/
path_renamed_outside_HEAD = !path2 || !strcmp(path, path2);
if (!path_renamed_outside_HEAD) {
add_cacheinfo(mfi.mode, mfi.sha, path,
0 /*stage*/, 1 /*refresh*/, 0 /*options*/);
return mfi.clean;
}
(Peff, hope you don't mind me cc'ing you directly. I seem to recall
you're saying github is doing something like this but I couldn't find
that email.)
j.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Junio C Hamano @ 2011-09-13 0:09 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20110912232756.GD28994@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... I
> suspect until then, you could just drop them.
That's a lot simpler than having to worry about it. Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Jeff King @ 2011-09-12 23:53 UTC (permalink / raw)
To: Junio C Hamano
Cc: Eric Sunshine, git, Boaz Harrosh, Brandon Casey, Thomas Rast,
Alexey Shumkin
In-Reply-To: <20110912233348.GE28994@sigill.intra.peff.net>
On Mon, Sep 12, 2011 at 07:33:48PM -0400, Jeff King wrote:
> > Thanks for spotting. I'll locally amend only this part and hope somebody
> > would volunteer to submit an agreed version as the final one ;-)
>
> I think we're missing Brandon's note that ".F" is used (as distinct from
> ".f", even on case-sensitive filesystems, as it has some magic meaning).
> And the pascal ones somebody mentioned.
I'm keeping my local version of the topic up-to-date. I'll collect any
more comments, and send the final version in a day or two.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Junio C Hamano @ 2011-09-12 23:35 UTC (permalink / raw)
To: git
Cc: Jeff King, Eric Sunshine, Boaz Harrosh, Brandon Casey,
Thomas Rast, Alexey Shumkin
In-Reply-To: <7vk49d5t8u.fsf@alter.siamese.dyndns.org>
[resending to the list as I screwed-up the To/Cc: header in the original]
Junio C Hamano <gitster@pobox.com> writes:
> [Stalled]
>
> * jk/default-attr (2011-08-26) 1 commit
> - attr: map builtin userdiff drivers to well-known extensions
>
> Not urgent; I fixed up the test breakage just for fun.
Could people who participated in the discussion make sure what is queued
includes their favorite extensions they proposed?
Thanks.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Jeff King @ 2011-09-12 23:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Eric Sunshine, git, Boaz Harrosh, Brandon Casey, Thomas Rast,
Alexey Shumkin
In-Reply-To: <7vwrdd1gyc.fsf@alter.siamese.dyndns.org>
On Mon, Sep 12, 2011 at 04:25:31PM -0700, Junio C Hamano wrote:
> > Peff also asked if uppercase extensions are common on Windows. They
> > are, so one often sees .HTM, .HTML, etc. Should this issue be handled
> > by jk/default-attr?
>
> I do not think we would mind adding .HTM but would people limit themselves
> to uppercase while not limiting themselves to three letters and use .HTML?
I wonder if they should all be in the style of:
[Hh][Tt][Mm][Ll]
[Jj][Aa][Vv][Aa]
for case-challenged systems. That feels like the wrong solution, though.
If you're on a case-insensitive system, shouldn't we perhaps be
comparing some kind of canonical version of the filename that is
lowercased? That would help these built-in attributes, as well as ones
that people write.
Or maybe that is too large a can of worms to open. I sort of assume we
have those canonicalization routines somewhere already, though.
> > Shouldn't the last entry be?
> >
> > "*.m diff=objc",
>
> Thanks for spotting. I'll locally amend only this part and hope somebody
> would volunteer to submit an agreed version as the final one ;-)
I think we're missing Brandon's note that ".F" is used (as distinct from
".f", even on case-sensitive filesystems, as it has some magic meaning).
And the pascal ones somebody mentioned.
-Peff
^ permalink raw reply
* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Junio C Hamano @ 2011-09-12 23:33 UTC (permalink / raw)
To: Jeff King; +Cc: Jens Lehmann, git, git-dev
In-Reply-To: <20110912224934.GA28994@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> To be honest, the whole submodule recursion thing seems a bit confusing
> to me....
> So since we must accept that we can't necessarily get every intermediate
> step, I wonder if we are simply better off diffing the "before" and
> "after" state of a particular ref, rather than traversing.
Yes, exactly my thought.
It would be far cheaper to look at a single final tree and enumerate all
the submodules, which would give you pessimistically the maximum set that
could possibly be relevant, than running millions of pairwise diff trees.
By the way, I think the submodule traversal won't hurt the correctness of
the primary traversal because that happens _after_ we fetch the object
stream.
The submodule traversal _may_ be getting an incorrect result, though, for
the same reason.
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Jeff King @ 2011-09-12 23:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vty8h2wda.fsf@alter.siamese.dyndns.org>
On Mon, Sep 12, 2011 at 02:51:48PM -0700, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > [Stalled]
> >
> > * jk/add-i-hunk-filter (2011-07-27) 5 commits
> > (merged to 'next' on 2011-08-11 at 8ff9a56)
> > + add--interactive: add option to autosplit hunks
> > + add--interactive: allow negatation of hunk filters
Hmph. After seeing this in WC for weeks, I just now noticed the typo
in the patch subject.
> > + add--interactive: allow hunk filtering on command line
> > + add--interactive: factor out regex error handling
> > + add--interactive: refactor patch mode argument processing
>
> Could you start thinking about completing this series, or posting a "where
> to go next" summary to guide others with lessor git clout to finish with
> help from people who know "add -i" codepath better (I could help), once
> 1.7.7 ships?
I was really just doing this to help scratch Duy's itch. Do other people
actually find it useful? I sort of imagined he would pick up the patches
and post them as part of a series once he had something working. I
suspect until then, you could just drop them.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Junio C Hamano @ 2011-09-12 23:25 UTC (permalink / raw)
To: Eric Sunshine
Cc: Jeff King, git, Boaz Harrosh, Brandon Casey, Thomas Rast,
Alexey Shumkin
In-Reply-To: <4E6E928A.6080003@sunshineco.com>
Eric Sunshine <sunshine@sunshineco.com> writes:
> The following extensions I mentioned are missing from jk/default-attr:
>
> "*.htm diff=html",
> "*.cpp diff=cpp",
> "*.mm diff=objc",
>
> On Windows, .htm is common, and .cpp is required by several Windows
> C++ compilers. On Mac OS X, .mm is used for Objective-C++. The other
> extensions I mentioned (.cs, .hpp, .m) are present in jk/default-attr.
>
> Peff also asked if uppercase extensions are common on Windows. They
> are, so one often sees .HTM, .HTML, etc. Should this issue be handled
> by jk/default-attr?
I do not think we would mind adding .HTM but would people limit themselves
to uppercase while not limiting themselves to three letters and use .HTML?
> By the way, there appears to be an error in 1ff2bcf79b (attr: map
> builtin userdiff drivers to well-known extensions, 2011-08-25):
>
>> static const char *builtin_attr[] = {
>> "[attr]binary -diff -text",
>> + "*.html diff=html",
>> ...omitted...
>> + "*.f[0-9][0-9] diff=fortran",
>> + "*.m objc",
>> NULL,
>
> Shouldn't the last entry be?
>
> "*.m diff=objc",
Thanks for spotting. I'll locally amend only this part and hope somebody
would volunteer to submit an agreed version as the final one ;-)
^ permalink raw reply
* Re: [PATCH] fetch: avoid quadratic loop checking for updated submodules
From: Jeff King @ 2011-09-12 23:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jens Lehmann, git, git-dev
In-Reply-To: <7vboup4azh.fsf@alter.siamese.dyndns.org>
On Mon, Sep 12, 2011 at 04:06:10PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > Also also. I was a little turned off by the fact that every fetch is
> > going to do the equivalent of "git log --raw -m $new --not $old",
> > whether you have submodules or not.
>
> Notice I called your patch solving "the other half"?
> See http://thread.gmane.org/gmane.comp.version-control.git/181101
Oh, heh. I totally missed that thread. I don't usually pay attention to
submodule patches, and came at this completely from the "why is git
fetch so slow" angle. Glad to see Jens and I are meeting in the middle.
:)
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Sverre Rabbelier @ 2011-09-12 23:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd3f52wd5.fsf@alter.siamese.dyndns.org>
Heya,
On Tue, Sep 13, 2011 at 00:02, Junio C Hamano <gitster@pobox.com> wrote:
> I vaguely recall that one of my unrelated topics fixed the issue you were
> trying to work around with this topic, or something? Can we see a re-roll
> after 1.7.7 ships?
Correct, one of your topics added a framework that would fix part of
what I was trying to fix, IIRC. I'm not sure if I'm quite up to the
task of doing that reroll, but I'll give it a shot at least :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Eric Sunshine @ 2011-09-12 23:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, git, Boaz Harrosh, Brandon Casey, Thomas Rast,
Alexey Shumkin
In-Reply-To: <7vk49d5t8u.fsf@alter.siamese.dyndns.org>
On 9/12/2011 5:46 PM, Junio C Hamano wrote:
> Junio C Hamano<gitster@pobox.com> writes:
>
>> [Stalled]
>>
>> * jk/default-attr (2011-08-26) 1 commit
>> - attr: map builtin userdiff drivers to well-known extensions
>>
>> Not urgent; I fixed up the test breakage just for fun.
>
> Could people who participated in the discussion make sure what is queued
> includes their favorite extensions they proposed?
The following extensions I mentioned are missing from jk/default-attr:
"*.htm diff=html",
"*.cpp diff=cpp",
"*.mm diff=objc",
On Windows, .htm is common, and .cpp is required by several Windows C++
compilers. On Mac OS X, .mm is used for Objective-C++. The other
extensions I mentioned (.cs, .hpp, .m) are present in jk/default-attr.
Peff also asked if uppercase extensions are common on Windows. They are,
so one often sees .HTM, .HTML, etc. Should this issue be handled by
jk/default-attr?
By the way, there appears to be an error in 1ff2bcf79b (attr: map
builtin userdiff drivers to well-known extensions, 2011-08-25):
> static const char *builtin_attr[] = {
> "[attr]binary -diff -text",
> + "*.html diff=html",
> ...omitted...
> + "*.f[0-9][0-9] diff=fortran",
> + "*.m objc",
> NULL,
Shouldn't the last entry be?
"*.m diff=objc",
(note the missing 'diff=')
-- ES
^ permalink raw reply
* Re: What's cooking in git.git (Sep 2011, #04; Mon, 12)
From: Junio C Hamano @ 2011-09-12 22:56 UTC (permalink / raw)
To: Pascal Obry, Ramsay Jones, Johannes Sixt, Erik Faye-Lund; +Cc: git
In-Reply-To: <7v4o0h7byd.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> [Stalled]
>
> * po/cygwin-backslash (2011-08-05) 2 commits
> - On Cygwin support both UNIX and DOS style path-names
> - git-compat-util: add generic find_last_dir_sep that respects is_dir_sep
Honestly I lost track of this one. How would we want to proceed on this
topic after 1.7.7?
Asking help from Windows folks.
^ 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