* Re: [PATCH v3 1/3] git-submodule add: Add -r/--record option
From: W. Trevor King @ 2012-11-10 18:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git, Jeff King, Phil Hord, Shawn Pearce, Jens Lehmann, Nahor
In-Reply-To: <7v390jqlep.fsf@alter.siamese.dyndns.org>
On Thu, Nov 08, 2012 at 11:34:54PM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
>
> > By remaining agnostic on the variable usage, this patch makes
> > submodule setup more convenient for all parties.
>
> I personally do not think "remaining agnostic on the usage" is a
> good thing, at least for any option to commands at the higher level
> on the stack, such as "git submodule". I am afraid that giving an
> easier way to set up a variable with undefined semantics may make
> setup more confusing for all parties. One party gives one specific
> meaning to the field, while another party uses it for something
> slightly different.
>
> I would not object to "git config submodule.$name.branch $value", on
> the other hand. "git config" can be used to set a piece of data
> that has specific meaning, but as a low-level tool, it is not
> _limited_ to variables that have defined meaning.
This is what I'm doing now:
$ git submodule add -b <branch> <repo> <path>
$ git config --file .gitmodules submodule.<path>.branch <branch>
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With my second patch (Phil's config export), that becomes
$ git submodule add -b <branch> <repo> <path>
$ git config --file .gitmodules submodule.<path>.branch <branch>
$ git submodule foreach 'git checkout $submodule_branch && git pull'
With my first patch, that becomes
$ git submodule add -rb <branch> <repo> <path>
$ git submodule foreach 'git checkout $submodule_branch && git pull'
This seems pretty useful to me, but I'm still using
submodule.<name>.branch explicitly as a user, and Git is not
interpreting the option directly. Users are free to store whatever
they like in that option, and use it however they wish:
$ git submodule foreach 'do-crazy-stuff.sh $submodule_branch'
If we need a semantic interpretation to justify -r/--record, everyone
that's chimed in so far has agreed on the same interpretation. I
wouldn't be averse to
$ git submodule add -rb <branch> <repo> <path>
$ git submodule pull-branch
which makes the foreach pull logic internal. However, there has been
a reasonable amount of resistance to this workflow in the past, so I
thought that a patch series that avoided a semantic interpretation
would be more acceptable.
If neither an agnostic -r/--record or a semantic pull-branch command
are acceptable, I suppose we'll have to drop my first and third
patches and only keep the second.
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
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Felipe Contreras @ 2012-11-10 18:43 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jeff King, Git Mailing List
In-Reply-To: <509E8EB2.7040509@drmicha.warpmail.net>
On Sat, Nov 10, 2012 at 6:28 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 09.11.2012 15:34:
>> On Fri, Nov 9, 2012 at 10:28 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>
>>> Hg seems to store just anything in the author field ("committer"). The
>>> various interfaces that are floating around do some behind-the-back
>>> conversion to git format. The more conversions they do, the better they
>>> seem to work (no erroring out) but I'm wondering whether it's really a
>>> good thing, or whether we should encourage a more diligent approach
>>> which requires a user to map non-conforming author names wilfully.
>>
>> So you propose that when somebody does 'git clone hg::hg hg-git' the
>> thing should fail. I hope you don't think it's too unbecoming for me
>> to say that I disagree.
>
> There is no need to disagree with a proposal I haven't made. I would
> disagree with the proposal that I haven't made, too.
All right, we shouldn't encourage a more diligent approach which
requires a user to map author names then.
>> IMO it should be git fast-import the one that converts these bad
>> authors, not every single tool out there. Maybe throw a warning, but
>> that's all. Or maybe generate a list of bad authors ready to be filled
>> out. That way when a project is doing a real conversion, say, when
>> moving to git, they can run the conversion once and see which authors
>> are bad and not multiple times, each try taking longer than the next.
>
> As Jeff pointed out, git-fast-import expects output conforming to a
> certain standard, and that's not going to change. import is agnostic to
> where its import stream is coming from. Only the producer of that stream
> can have additional information about the provenience of the stream's
> data which may aid (possibly together with user input or choices) in
> transforming that into something conforming.
We already know where the import of those streams come from:
mercurial, bazaar, etc. There's absolutely nothing the tools exporting
data from those repositories can do, except try to convert all kind of
weird names--and many tools do it poorly.
So, the options are:
a) Leave the name conversion to the export tools, and when they miss
some weird corner case, like 'Author <email', let the user face the
consequences, perhaps after an hour of the process.
We know there are sources of data that don't have git-formatted author
names, so we know every tool out there must do this checking.
In addition to that, let the export tool decide what to do when one of
these bad names appear, which in many cases probably means do nothing,
so the user would not even see that such a bad name was there, which
might not be what they want.
b) Do the name conversion in fast-import itself, perhaps optionally,
so if a tool missed some weird corner case, the user does not have to
face the consequences.
The tool writers don't have to worry about this, so we would not have
tools out there doing a half-assed job of this.
And what happens when such bad names end up being consistent: warning,
a scaffold mapping of bad names, etc.
One is bad for the users, and the tools writers, only disadvantages,
the other is good for the users and the tools writers, only
advantages.
--
Felipe Contreras
^ permalink raw reply
* Re: What's cooking in git.git (Oct 2012, #09; Mon, 29)
From: Ramsay Jones @ 2012-11-10 18:33 UTC (permalink / raw)
To: Jeff King; +Cc: Chris Rorvick, git
In-Reply-To: <20121104122926.GD336@sigill.intra.peff.net>
Jeff King wrote:
> On Fri, Nov 02, 2012 at 09:33:14PM +0000, Ramsay Jones wrote:
>
>> (Linux is my main platform, but I like to keep cygwin working because it has
>> kept me sane on Windows ever since (about) 1995 ...)
>> "Stranger in a strange land" ;-)
>
> I used a different trick around the same time to keep me sane from
> Windows, but I think it involved "dd" and "/dev/zero"...
;-) That's a solution I would have been keen to try, but my employer
at the time would not have liked that idea ...
>>
>> This patch fixes the test for me.
>
> Great. I was guessing blindly when I wrote it, but having seen the perl
> bug above, it all makes sense.
>
> We should probably wrap it. I'm planning to queue this on top of Chris's
> patch:
Unfortunately, I haven't had time yet to test this patch. (Early this week, I
went into hospital for a "minor" surgical procedure - I have not yet fully
recovered). The patch looks good and I don't anticipate any problems. I will
hopefully test it soon (I see it's in pu now) and let you know.
[snip patch]
ATB,
Ramsay Jones
^ permalink raw reply
* [PATCH] remote-curl.c: Fix a gcc warning
From: Ramsay Jones @ 2012-11-10 18:34 UTC (permalink / raw)
To: Jeff King; +Cc: GIT Mailing-list
In particular, gcc complains as follows:
CC remote-curl.o
remote-curl.c: In function `rpc_service':
remote-curl.c:403: warning: 'gzip_size' might be used uninitialized \
in this function
The 'gzip_size' variable would not, in fact, be used uninitialized.
However, in order to suppress the warning, we simply initialize the
variable to zero in it's declaration.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Jeff,
Could you please squash this into commit df126e108 ("remote-curl: hoist
gzip buffer size to top of post_rpc", 31-10-2012), which is part of
your 'jk/maint-http-half-auth-fetch' branch.
Thanks!
ATB,
Ramsay Jones
remote-curl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/remote-curl.c b/remote-curl.c
index d8b3600..9a8b123 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -400,7 +400,7 @@ static int post_rpc(struct rpc_state *rpc)
struct curl_slist *headers = NULL;
int use_gzip = rpc->gzip_request;
char *gzip_body = NULL;
- size_t gzip_size;
+ size_t gzip_size = 0;
int err, large_request = 0;
/* Try to load the entire request, if we can fit it into the
--
1.8.0
^ permalink raw reply related
* Re: old folders returning
From: Andy Hawkins @ 2012-11-10 17:41 UTC (permalink / raw)
To: git
In-Reply-To: <CAN4PrMavggqn3ZM1atde5CADjszzLOvPoQasjRZfUvRKrqS-uA@mail.gmail.com>
Hi,
In article <CAN4PrMavggqn3ZM1atde5CADjszzLOvPoQasjRZfUvRKrqS-uA@mail.gmail.com>,
David Coombes<webeire@gmail.com> wrote:
> The only suggestion I can think of is that the name wasn't cleared
> after the "git add *" and then git went looking for an earlier copy.
> But seems the issue is with the git client as well because of the
> modified time. If it were pulled then the modified time would've
> changed, so it must have been taken from an earlier commit on my local
> branch.
Did you git rm the 'old' name of the folder?
Andy
^ permalink raw reply
* old folders returning
From: David Coombes @ 2012-11-10 17:30 UTC (permalink / raw)
To: git
Issue:
--------
I renamed a deprecated folder that i needed the code for, added ".old"
to name. I then pushed to the repository and the original folder and
the newly renamed are now in the repository and on my local branch.
I renamed 'autoflow' to 'autoflow.old' and worked away ok. But after
the push I now have both of the folders with duplicate files.
The 'autoflow' folder that has appeared is also from an earlier push
this morning 1038 its now 1727
Re-Create:
----------------
No idea how to as its the first time I've seen this. But the output
from the push is:
git push origin autoflow
Counting objects: 267, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (132/132), done.
Writing objects: 100% (146/146), 140.69 KiB, done.
Total 146 (delta 76), reused 1 (delta 0)
To git@github.com:cityindex/labs.cityindex.com.git
8ea3cd9..7e6ff4f autoflow -> autoflow
Cause:
----------
The only suggestion I can think of is that the name wasn't cleared
after the "git add *" and then git went looking for an earlier copy.
But seems the issue is with the git client as well because of the
modified time. If it were pulled then the modified time would've
changed, so it must have been taken from an earlier commit on my local
branch.
System:
------------
$ git --version
git version 1.7.9.5
$ cat /etc/*release*
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.1 LTS"
$ uname -a
Linux daithi-laptop 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26
21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
--
"Any society that would give up a little liberty to gain a little security,
will deserve neither and lose both." - Benjamin Franklin
^ permalink raw reply
* Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
From: Michael J Gruber @ 2012-11-10 17:28 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, Git Mailing List
In-Reply-To: <CAMP44s3Lhxzcj93=e8TXwqAVvGJBKhZEVX33G8Q=n2+8+UfCww@mail.gmail.com>
Felipe Contreras venit, vidit, dixit 09.11.2012 15:34:
> On Fri, Nov 9, 2012 at 10:28 AM, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>
>> Hg seems to store just anything in the author field ("committer"). The
>> various interfaces that are floating around do some behind-the-back
>> conversion to git format. The more conversions they do, the better they
>> seem to work (no erroring out) but I'm wondering whether it's really a
>> good thing, or whether we should encourage a more diligent approach
>> which requires a user to map non-conforming author names wilfully.
>
> So you propose that when somebody does 'git clone hg::hg hg-git' the
> thing should fail. I hope you don't think it's too unbecoming for me
> to say that I disagree.
There is no need to disagree with a proposal I haven't made. I would
disagree with the proposal that I haven't made, too.
> IMO it should be git fast-import the one that converts these bad
> authors, not every single tool out there. Maybe throw a warning, but
> that's all. Or maybe generate a list of bad authors ready to be filled
> out. That way when a project is doing a real conversion, say, when
> moving to git, they can run the conversion once and see which authors
> are bad and not multiple times, each try taking longer than the next.
As Jeff pointed out, git-fast-import expects output conforming to a
certain standard, and that's not going to change. import is agnostic to
where its import stream is coming from. Only the producer of that stream
can have additional information about the provenience of the stream's
data which may aid (possibly together with user input or choices) in
transforming that into something conforming.
Michael
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Junio C Hamano @ 2012-11-10 17:14 UTC (permalink / raw)
To: Jeff King; +Cc: Ralf Thielow, git
In-Reply-To: <20121110003850.GB12567@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 09, 2012 at 12:27:35PM -0800, Junio C Hamano wrote:
>
>> What we should have arranged was to have https://github.com/git/git
>> (which is not even owned by me, but I asked somebody at GitHub to
>> assign me a write privilege) writable by the interim maintainer, so
>> that normal people would keep pulling from there, while the interim
>> maintainer can choose to publish broken-out branches to his
>> repository.
>
> Yes, I have write access to that repository, too, but I intentionally
> held off from updating it out of a sense of nervousness. I figured if I
> screwed up anything too badly, people who were clued-in enough to switch
> to pulling from my repository would be clued-in enough to rebase across
> any too-horrible mistake I made. ;)
That "nervousness" reminds me of myself when I took over. Before I
could ask for a few weeks of practice period, Linus arranged to have
folks at k.org to chown the authoritative location to me, declaring
"no practice period; it's already done and it's all yours".
And I made at least one mistake pushing 'master' with one commit
rewound too much (corrected by pushing an extra merge). Luckily,
the world did not end ;-).
> I think if we do this again, I will make the same split you do (git/git
> for integration branches, peff/git as a mirror of my private repo).
I am fairly sure I'll have to ask you (or somebody else) again next
year around late September.
>> And it is not too late to do so; from the look of your "What's
>> cooking", you are doing pretty well ;-).
>
> Any fool can merge topics to master. The real test will be how many
> regressions people report in the next two weeks. :)
I agree that the actual merging to 'master' is mechanical with the
procedure built around Meta/Reintegrate. Important decisions are
made before you merge a topic to 'next' and mark topics as "Will
merge to 'master'." My comment was about that, and your responses
to the list messages.
> By the way, I did not touch 'maint' at all while you were gone. I don't
> know what your usual method is for keeping track of maint-worthy topics
> after they have gone to master. The usual "what's cooking" workflow
> keeps track of things going to master, but no more; I'd guess you
> probably just merge to maint when you delete them from last cycle's
> "graduated to master" list.
That is done by eyeballing output from Meta/GRADUATED (which spits
out something that could be fed to shell, but I do not fully trust
its logic, and always eyeball them before I prepare the temporary
file to feed Meta/Reintegrate to update 'maint').
^ permalink raw reply
* Re: Help requested - trying to build a tool doing whole-tree commits
From: Junio C Hamano @ 2012-11-10 16:57 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121109182024.81074BC66D4@golux>
Unknown <unknown@unknown.invalid> writes:
> (Apologies if this arrives twice. I'm on the road, with somewhat flaky email.)
>
> Because of my work on reposurgeon, I am sometimes asked to produce git
> repositories for very old projects that not only are still using CVS
> but have ancient releases not in the CVS repository, preserved only
> as tarballs.
Perhaps not exactly what you are looking for, but don't we have
import-tar somewhere in contrib/fast-import hierarchy (sorry, not on
a machine yet, and I cannot give more details).
^ permalink raw reply
* Re: git-reset man page
From: Krzysztof Mazur @ 2012-11-10 15:57 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git, peff
In-Reply-To: <CAB9Jk9AdTBJotrB0fndZawMWH6hS4PW_5bHwecwY5Vz7=TnYAA@mail.gmail.com>
On Sat, Nov 10, 2012 at 10:55:13AM +0100, Angelo Borsotti wrote:
> Hi
>
> the man page of git-reset, synopsys, does not allow for an
> argumentless call, and the description does not tell either what is
> the meaning of it.
This issue was already reported by Bojan Petrović:
http://thread.gmane.org/gmane.comp.version-control.git/208505
and fixed in commit d505865be5c7d72abb74318940e8c4c52aa0db5f
(doc: git-reset: make "<mode>" optional) in master branch.
"git reset" is equivalent to "git reset --mixed".
> Suggested changes:
>
> first line of synopsis:
>
> gitt reset [-q] [<commit>] [ [--] <pathspec> ...]
>
> Description: append to the end of the first paragraph:
>
> "If no <pathspecs> are specified, all the index entries are reset."
>
> I would suggest to change <paths> with <pathspec> in all the man page
> because paths in the glossary are called pathspecs.
>
The <paths> issue seems to be bigger - "<path>", "<paths>" and "<pathspec>"
are mixed in whole manual:
$ cat Documentation/*.txt | grep -o '<path[^>]*>' | sort | uniq -c |
sort -n -r
125 <path>
17 <paths>
10 <pathspec>
2 <pathtemplate>
2 <path-pattern>
1 <path_to>
1 <path_from>
In commands it's even worse:
$ cat builtin/*.c | grep -o '<path[^>]*>' | sort | uniq -c | sort -n -r
14 <path>
15 <paths>
Note: <path> is not always used for pathspec.
In git-checkout manual in synopsis "<paths>" is used, but in description
"<pathspec>".
Maybe we should just add that <paths> is an shortcut for <pathspec>
and fix places where paths and pathspec are mixed or <path> is used as
<pathspec>.
Thanks,
Krzysiek
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: Paul Fox @ 2012-11-10 15:52 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: git
In-Reply-To: <87a9uq5tql.fsf@Niukka.kon.iki.fi>
kalle olavi niemitalo wrote:
> Jeff King <peff@peff.net> writes:
>
> > Comments welcome from people using unusual editors (e.g., a script that
> > starts an editor in another window then blocks, waiting for the user to
> > finish).
>
> I often run a shell in Emacs in X, then start git commit in that
> shell. $EDITOR is emacsclient --current-frame, which asks the
> existing Emacs instance to load the file and waits until I press
> C-x # in Emacs to mark the file done. If I want to abort the
> commit, it is most intuitive to return to the *Shell* buffer in
> Emacs and press C-c C-c (comint-interrupt-subjob) to send SIGINT
> to git from there. (I see that "an empty message aborts the
> commit", and indeed it does, but well, I prefer not to trust such
> a feature if I can instead just interrupt the thing.)
>
> With pf/editor-ignore-sigint, C-c C-c in the *Shell* buffer kills
> neither git nor the emacsclient started by git. This is not good.
> SIGQUIT from C-c C-\ (comint-quit-subjob) still works though.
when i implemented the change, i wondered if some twisted emacs
workflow would be an issue. ;-) and i almost blocked SIGQUIT as
well -- the two programs i looked at for precedent (CVS and MH) both
block both SIGQUIT and SIGINT when spawning an editor.
but since emacs users must have dealt with CVS for a long time before
dealing with git, how might they have done so?
the existing git behavior is bad for non-emacs users, and git itself
provides an abort-the-operation mechanism (i.e., writing an empty
message), so i'm not convinced your use case invalidates the new
behavior. (though it might spotlight a need for this being prominent
in release notes.)
paul
=---------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 40.6 degrees)
^ permalink raw reply
* http-backend GIT_COMMITTER_NAME & -EMAIL documentation bug
From: gima @ 2012-11-10 15:26 UTC (permalink / raw)
To: git
Documentation says that envvars GIT_COMMITTER_NAME and
GIT_COMMITTER_EMAIL formed from REMOTE_USER and REMOTE_ADDR, but doesn't
mention that they are left alone if they have been set already.
Referring to:
https://github.com/git/git/blob/master/Documentation/git-http-backend.txt#L178
Source code says that they are set conditionally (referring to this part
of the source):
https://github.com/git/git/blob/master/http-backend.c#L335
And the (most recent) commit pertaining to this behavior explains the
change:
https://github.com/git/git/commit/e32a4581bcbf1cf43cd5069a0d19df07542d612a
I'm also for the possibility of custom implementations assigning those
envvars, so could the documentation be changed to reflect that?
^ permalink raw reply
* Re: Bizarre problem cloning repo from Codeplex
From: Andreas Schwab @ 2012-11-10 15:23 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Jeremy Morton, git
In-Reply-To: <6c843260-6190-469a-aa53-243ac440b0fd@zcs>
Enrico Weigelt <enrico.weigelt@vnc.biz> writes:
> Their webserver seems to be configured quite restrictively
> (eg. cannot access files like 'packed-refs').
Probably it just doesn't exist.
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
* overriding/removing inherited credential.helper
From: 乙酸鋰 @ 2012-11-10 15:12 UTC (permalink / raw)
To: git
In credential.c, line 67:
if (!strcmp(key, "helper"))
string_list_append(&c->helpers, value);
In global config, I add one credential helper.
But I do not want to use any credential helper in a specific repository.
Currently there is no way in local config to override and remove
inherited credential helper.
Of course, I do not want to change global config.
Could you suggest a patch?
^ permalink raw reply
* Do not add an empty value from config credential.helper
From: 乙酸鋰 @ 2012-11-10 15:08 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
Below is current git message when a local config credential.helper has
an empty value. Please skip an empty value.
$ git push --force origin master
git: 'credential-' is not a git command. See 'git --help'.
Did you mean this?
credential
Total 0 (delta 0), reused 0 (delta 0)
To https://user@github.com/user/myrepo.git
+ d23aa6a...3405990 master -> master (forced update)
[-- Attachment #2: 0001-credential-do-not-recognize-a-credential-helper-if-c.patch --]
[-- Type: application/octet-stream, Size: 781 bytes --]
From 0b3ec07ed893a0d595cf48c55d884ff844f1108f Mon Sep 17 00:00:00 2001
From: Sup Yut Sum <ch3cooli@gmail.com>
Date: Sat, 10 Nov 2012 22:24:30 +0800
Subject: [PATCH] credential: do not recognize a credential helper if config
value is empty
Signed-off-by: Sup Yut Sum <ch3cooli@gmail.com>
---
credential.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/credential.c b/credential.c
index e54753c..1489e7a 100644
--- a/credential.c
+++ b/credential.c
@@ -64,7 +64,7 @@ static int credential_config_callback(const char *var, const char *value,
key = dot + 1;
}
- if (!strcmp(key, "helper"))
+ if (!strcmp(key, "helper") && *value)
string_list_append(&c->helpers, value);
else if (!strcmp(key, "username")) {
if (!c->username)
--
1.8.0.msysgit.0
^ permalink raw reply related
* t9350-fast-export.sh broken on peff/pu under Mac OS X
From: Torsten Bögershausen @ 2012-11-10 14:37 UTC (permalink / raw)
To: felipe.contreras, Git Mailing List; +Cc: Torsten Bögershausen
The short version:
echo -n doesn't seem to be portable.
The following works for me:
(And is this a typo: test_expect_success 'test biridectionality' ')
/Torsten
diff ../../git.peff/t/t9350-fast-export.sh t9350-fast-export.sh
444,445c444,445
< echo -n > marks-cur &&
< echo -n > marks-new &&
---
> > marks-cur &&
> > marks-new &&
464c464
< echo -n > tmp-marks &&
---
> > tmp-marks &&
474c474
< echo -n > expected &&
---
> > expected &&
^ permalink raw reply
* t5801-remote-helpers.sh fails
From: Torsten Bögershausen @ 2012-11-10 13:48 UTC (permalink / raw)
To: felipe.contreras, Git Mailing List; +Cc: Torsten Bögershausen
Hej,
on peff/pu t5801 fails, the error is in git-remote-testgit, please see below.
That's on my Mac OS X box.
I haven't digged further into the test case, but it looks as if
"[-+]A make NAMEs associative arrays"
is not supported on this version of bash.
/Torsten
/Users/tb/projects/git/git.peff/git-remote-testgit: line 64: declare: -A: invalid option
declare: usage: declare [-afFirtx] [-p] [name[=value] ...]
/Users/tb/projects/git/git.peff/git-remote-testgit: line 66: refs/heads/master: division by 0 (error token is "/master")
error: fast-export died of signal 13
fatal: Error while running fast-export
^ permalink raw reply
* Re: Workflow for templates?
From: Philip Oakley @ 2012-11-10 13:44 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Git List, Josef Wolf
In-Reply-To: <7f1bbe94-b3f6-4728-960d-19e89e8e4166@zcs>
From: "Enrico Weigelt" <enrico.weigelt@vnc.biz> Sent: Saturday, November
10, 2012 10:29 AM
>> This is often the key point that requires the 'new mindset'. Most
>> folk
>> use/used the directory heirarchy (subtle distinction with the .git
>> 'repo' directory heirarchy to be noted) as a way of separating
>> ownership
>> between groups. They find it very hard to undo the old mindset and
>> use
>> branches _instead of_ directories for the different group
>> configurations.
>
> hmm, is this really a psychological issue ?
Oh absolutely. It is very very hard to unlearn stuff, especially bad
habits that have had to become ingrained to make them work adequately!
It's like re-learning an alternative to a well loved mnemonic. "CLAP".
>
> well, many years ago, i've seen a talk about git (maybe by linus
> himself),
> which started with something like "forget everything you know abozt
> scm" ...
Most folk don't know why the old way used to be right, and is now so
wrong, so they can't rationalize the change. Hence find the change very
difficult.
[Other than git..] Current SCM methods were established before the
Titanic sank and are based on drawing office practice, and were
transfered and applied to code printouts (which are simply machining
instructions to a compiler). The modern zero cost replication of
"Master" drawings/code printouts has destroyed the original reasons for
the old practices (protect the aluable unique master). Similarly the new
paradigm of "how can I verify that this is a proper copy of the master"
isn't understood.
Definately a psychological issue when your whole world is being turned
upside down ;-)
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2012, #02; Fri, 9)
From: SZEDER Gábor @ 2012-11-10 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: Felipe Contreras, git, Sverre Rabbelier
In-Reply-To: <20121110003331.GA12567@sigill.intra.peff.net>
Hi,
On Fri, Nov 09, 2012 at 07:33:31PM -0500, Jeff King wrote:
> On Sat, Nov 10, 2012 at 12:21:48AM +0100, Felipe Contreras wrote:
> > > * fc/completion-test-simplification (2012-10-29) 2 commits
> > > - completion: simplify __gitcomp test helper
> > > - completion: refactor __gitcomp related tests
> > >
> > > Clean up completion tests.
> > >
> > > There were some comments on the list.
> > >
> > > Expecting a re-roll.
> >
> > The second patch I can re-roll, but the first patch needs some
> > external input. My preference is that tests should also be simple and
> > maintainable, SZEDER's preference is that tests are better being
> > explicit and verbose (even if harder to maintain) to minimize possible
> > issues in the tests.
>
> I think it is better to keep the tests simple and maintainable.
Maintainable? There is nothing to maintain here. Users' completion
scripts depend on __gitcomp(), so its behavior shouldn't be changed.
It can only be extended by a fifth parameter or by quoting words when
necessary, but these future changes must not alter the current
behavior checked by these tests, therefore even then these tests must
be left intact.
Simple? Currently you only need to look at __gitcomp() and the test
itself to understand what's going on. With this series you'll also
need to look at test_gitcomp(), figure out what its parameters are
supposed to mean, and possibly get puzzled on the way why __gitcomp()
is now seemingly called with only one parameter.
So, I don't see much benefit in this series (except the part to use
print_comp instead of "change IFS && echo", but that's already done in
this patch:
http://article.gmane.org/gmane.comp.version-control.git/207927).
OTOH, this series has some serious drawbacks.
It makes debugging more difficult. While working on the quoting
issues I managed to break completion tests many-many times lately. In
normal tests I could add a few debugging instructions to the failed
test to find out where the breakage lies, without affecting other
tests. However, if the failed test uses the test_completion() helper,
then I have to add debugging instructions to test_completion() itself,
too. This is bad, because many tests use this helper function and are
therefore affected by the debugging instructions, producing truckloads
of output making it difficult to dig out the relevant parts, or, worse
yet, causing breakages in other tests. With this series the same
difficulties will come to __gitcomp() tests, too.
It can also encourage writing bad tests, similar to those that managed
to cram many test_completion() lines into a single tests, giving me
headaches to figure out what went wrong this time.
Best,
Gábor
^ permalink raw reply
* Re: Bizarre problem cloning repo from Codeplex
From: John Szakmeister @ 2012-11-10 12:15 UTC (permalink / raw)
To: Enrico Weigelt; +Cc: Jeremy Morton, git
In-Reply-To: <6c843260-6190-469a-aa53-243ac440b0fd@zcs>
On Sat, Nov 10, 2012 at 2:49 AM, Enrico Weigelt <enrico.weigelt@vnc.biz> wrote:
[snip]
> Their webserver seems to be configured quite restrictively
> (eg. cannot access files like 'packed-refs').
>
> Is there a way to trace the actual HTTP calls ?
Try GIT_CURL_VERBOSE=1. GIT_TRACE_PACKET=1 can be helpful too.
-John
PS Sorry for the duplicate. I meant to respond to the list as well.
^ permalink raw reply
* git-status: Use "-sb" options by default?
From: Jason Timrod @ 2012-11-10 11:04 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I've been rooting around the "git-config" man page as well as the "git-status" man page, but couldn't find the following, which suggests it's not (yet) possible.
I'm looking for a way to make the "-sb" options to git-status the default somehow. That is, I would like the short form of git-status to be the default when typing in "git status". I appreciate I am able to do this in an indirect way using aliases, but this is slightly suboptimal for me.
If this isn't possible directly, would someone mind considering this a feature request?
Out of interest, would this be done via the git-config system, most likely?
Thanks kindly,
Jason
^ permalink raw reply
* Re: [PATCH] cache-tree: invalidate i-t-a paths after writing trees
From: Nguyen Thai Ngoc Duy @ 2012-11-10 11:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Jonathon Mah
In-Reply-To: <7vy5ibouo4.fsf@alter.siamese.dyndns.org>
On Fri, Nov 9, 2012 at 6:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> diff --git a/cache-tree.c b/cache-tree.c
>> index 28ed657..30a8018 100644
>> --- a/cache-tree.c
>> +++ b/cache-tree.c
>> @@ -381,6 +381,9 @@ int cache_tree_update(struct cache_tree *it,
>> i = update_one(it, cache, entries, "", 0, flags);
>> if (i < 0)
>> return i;
>> + for (i = 0; i < entries; i++)
>> + if (cache[i]->ce_flags & CE_INTENT_TO_ADD)
>> + cache_tree_invalidate_path(it, cache[i]->name);
>> return 0;
>> }
>
> I notice there is another special case for CE_REMOVE but there is
> nothing that adjusts the cache-tree for these entries in the current
> codebase.
>
> I suspect the original code before we (perhaps incorrectly) updated
> the code not to error out upon I-T-A entries was fine only because
> we do not attempt to fully populate the cache-tree during a merge in
> the unpack-trees codepath, which will mark the index entries that
> are to be removed with CE_REMOVE in the resulting index.
>
> The solution implemented with this patch will break if we start
> updating the cache tree after a successful merge in unpack-trees, I
> suspect.
I don't understand. I thought we handled CE_REMOVE correctly (i.e. no
CE_REMOVE entries in cache tree even after a successful merge). Or
should we keep CE_REMOVE in cache tree after a successful merge?
> An alternative might be to add a "phoney" bit next to "used" in the
> cache_tree structure, mark the cache tree as phoney when we skip an
> entry marked as CE_REMOVE or CE_ITA, and make the postprocessing
> loop this patch adds aware of that bit, instead of iterating over
> the index entries; instead, it would recurse the resulting cache
> tree and invalidate parts of the tree that have subtrees with the
> "phoney" bit set, or something.
Yeah, that sounds better.
--
Duy
^ permalink raw reply
* Re: bare vs non-bare <1.7 then >=1.7 ?
From: Philip Oakley @ 2012-11-10 10:37 UTC (permalink / raw)
To: Enrico Weigelt, Mihamina Rakotomandimby; +Cc: Git Issues
In-Reply-To: <e4dc73e8-69f9-4695-b8f7-cbc0f04e8197@zcs>
From: "Enrico Weigelt" <enrico.weigelt@vnc.biz> Sent: Saturday, November
10, 2012 8:23 AM
> Wait, there *is* an usecase for such things, deploying trees (eg.
> webapps)
> some server:
>
> * application is developed in git
> * the final production-system tree is maintained in certian branch
> * a post-update hook acts on a specific production branch and does
> something like git checkout --detach <treeish>
>
I have an alternative use-case for un-trained collegues :
The network shared drive has master checked out, and the .git directory
is hidden. Untrained colleagues don't know I have it as a git remote.
Even if they show hidden directories they will tend to ignore it as
being just another spurious directory.
I develop on my own box (local directory) on my own branch 'Philip' and
features therefrom. I push my development history back to the network
remote to act as a backup. Because I don't touch master I can normally
push to it quite happily.
When I have some finished work I can change to 'working' on the network
drive, and merge or rebase my 'Philip' branch into master, and update
the network's working tree. The untrained folk now see the new updated
files as if I'd simply worked on / copied into the network share and
they are non the wiser (yet) that I do have proper (micro managed)
history.
I can also capture any changes they made to the network share so can go
back to a point in history when required. It's in matlab and is not a
big code base.
Philip
^ permalink raw reply
* Re: Workflow for templates?
From: Enrico Weigelt @ 2012-11-10 10:29 UTC (permalink / raw)
To: Philip Oakley; +Cc: Git List, Josef Wolf
In-Reply-To: <F9FF8107FA8F4CBD8C3D87B907BAE9E3@PhilipOakley>
> This is often the key point that requires the 'new mindset'. Most
> folk
> use/used the directory heirarchy (subtle distinction with the .git
> 'repo' directory heirarchy to be noted) as a way of separating
> ownership
> between groups. They find it very hard to undo the old mindset and
> use
> branches _instead of_ directories for the different group
> configurations.
hmm, is this really a psychological issue ?
well, many years ago, i've seen a talk about git (maybe by linus himself),
which started with something like "forget everything you know abozt scm" ...
> > By the way: you really should use non-conflicting tag names (eg.
> > adding some <site>+"/" or <site>+"-" prefix), otherwise you'll
> > easiy run into conflicts, because per default retrieved and local
> > tags will all be in some namespace
> > Better consider tag names to be really global.
>
> Definitely.
Well, you *could* setup special fetch rules, which put tags from separate
repos to separate namespaces, but i'd really advice against that, as it's
too easy to forget something and again mess it up.
--
Mit freundlichen Grüßen / Kind regards
Enrico Weigelt
VNC - Virtual Network Consult GmbH
Head Of Development
Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59
enrico.weigelt@vnc.biz; www.vnc.de
^ permalink raw reply
* Re: Workflow for templates?
From: Philip Oakley @ 2012-11-10 9:56 UTC (permalink / raw)
To: Enrico Weigelt, Josef Wolf; +Cc: Git List
In-Reply-To: <bbc40624-f95d-48c9-83ed-fd70430226a4@zcs>
From: "Enrico Weigelt" <enrico.weigelt@vnc.biz> Sent: Saturday, November
10, 2012 7:13 AM
I've picked out Enrico's key points.
>> Maybe I should try to explain the problem in terms of repository
>> hierarchy. Let's assume, there is this hierarchy of repositories:
>
> Let's talk about branches instead - repos are just containers for
> branches (and tags, etc).
This is often the key point that requires the 'new mindset'. Most folk
use/used the directory heirarchy (subtle distinction with the .git
'repo' directory heirarchy to be noted) as a way of separating ownership
between groups. They find it very hard to undo the old mindset and use
branches _instead of_ directories for the different group
configurations.
Teaching git is easy. Undoing the old mindset is hard hard hard. [it's
still hard]
> By the way: you really should use non-conflicting tag names (eg.
> adding some <site>+"/" or <site>+"-" prefix), otherwise you'll
> easiy run into conflicts, because per default retrieved and local
> tags will all be in some namespace
> Better consider tag names to be really global.
Definitely.
Apologies if it's a bit of bike-shedding.
Philip
^ 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