"W. Trevor King" 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 "
Please excuse one inaccuracy: I did a 'git pull' not a clone. So it could be an
old .idx file at my end possibly.
Thanks,
bruce
-Original Message-
From: Robertson, Bruce E
Sent: Thursday, November 08, 2012 4:25 PM
To: git@vger.kernel.org
Subject: orphan blob or what?
In today's and old
From: "W. Trevor King"
This makes it easy to access per-submodule variables. For example,
git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules
submodule.$name.branch) && git pull'
can now be reduced to
git submodule foreach 'git checkout $submodule_branch && git
Phil Pennock writes:
> @@ -2702,6 +2702,7 @@ sub git_get_project_config {
> $key = lc($key);
> }
> $key =~ s/^gitweb\.//;
> + $key =~ s/_//g;
> return if ($key =~ m/\W/);
>
> # type sanity check
The idea to strip "_" from "remote_heads" to create "remo
From: "W. Trevor King"
Here's my revised patch. Changes from v2:
* Revised Ævar-vs-Gerrit usage to show agreement, following Shawn's
comments.
* Added a cleaned up version of Phil's $submodule_* export patch, with
docs and tests.
* Added a caveat to the -r/--record documentation to make it
From: "W. Trevor King"
Signed-off-by: W. Trevor King
---
Documentation/git-submodule.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 9a99826..d4e993f 100644
--- a/Documentation/git-submodule.txt
+++ b/Docume
From: "W. Trevor King"
This option allows you to record a submodule..branch option in
.gitmodules. Git does not currently use this configuration option for
anything, but users have used it for several things, so it makes sense
to add some syntactic sugar for initializing the value.
Current cons
On Fri, Nov 9, 2012 at 3:09 AM, Jeff King wrote:
> On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote:
>
>> > So, then the question is: What do you know/have? Is your patch the
>> > output of "git format-patch", "git diff", or just some sort of diff
>> > without any git information?
>>
>> T
On Thu, 08 Nov 2012 16:24:36 -0800, bruce wrote:
> In today's and older clones of https://github.com/mirrors/linux.git I
> find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't
> figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it
> in 'git fsck', 'git gc --a
In today's and older clones of https://github.com/mirrors/linux.git I
find this object, 6fa98ea0ae40f9a38256f11e5dc270363f785aee, that I can't
figure out how to eliminate^h^h^h^h^h^h^h^h^hget rid of. I don't see it
in 'git fsck', 'git gc --aggressive --prune' doesn't seem to prune it,
can't see it
I tried on the local disk as well and it didn't help. I managed to
find a SUSE11 machine and tried it there but no luck so I think we can
eliminate NFS and OS as significant factors now.
I ran with perf and here's the report:
ESC[31m69.07%ESC[m git /lib64/libc-2.11.1.so
On Thu, Nov 08, 2012 at 04:16:59PM -0600, Uri Moszkowicz wrote:
> I ran "git cat-file commit some-tag" for every tag. They seem to be
> roughly uniformly distributed between 0s and 2s and about 2/3 of the
> time seems to be system. My disk is mounted over NFS so I tried on the
> local disk and it
I ran "git cat-file commit some-tag" for every tag. They seem to be
roughly uniformly distributed between 0s and 2s and about 2/3 of the
time seems to be system. My disk is mounted over NFS so I tried on the
local disk and it didn't make a difference.
I have only one 1.97GB pack. I ran "git gc --a
On Thu, Nov 08, 2012 at 03:49:32PM -0600, Uri Moszkowicz wrote:
> I'm using RHEL4. Looks like perf is only available with RHEL6.
Yeah, RHEL4 is pretty ancient; I think it predates the invention of
"perf".
> heads: 308
> tags: 9614
>
> Looking up the tags that way took a very long time by the wa
I'm using RHEL4. Looks like perf is only available with RHEL6.
heads: 308
tags: 9614
Looking up the tags that way took a very long time by the way. "git
tag | wc -l" was much quicker. I've already pruned a lot of tags to
get to this number as well. The original repository had ~37k tags
since we u
On Thu, Nov 01, 2012 at 04:13:49PM +0530, Ramkumar Ramachandra wrote:
> diff --git a/builtin/diff.c b/builtin/diff.c
> index 9650be2..6d00311 100644
> --- a/builtin/diff.c
> +++ b/builtin/diff.c
> @@ -297,6 +297,10 @@ int cmd_diff(int argc, const char **argv, const char
> *prefix)
> DIFF_OP
On Sun, Nov 04, 2012 at 11:28:17PM +0530, Ramkumar Ramachandra wrote:
> Jens Lehmann wrote:
> > Am 01.11.2012 11:43, schrieb Ramkumar Ramachandra:
> >> Hi,
> >>
> >> v1 is here:
> >> http://mid.gmane.org/1349196670-2844-1-git-send-email-artag...@gmail.com
> >>
> >> I've fixed the issues pointed ou
On Thu, Nov 08, 2012 at 11:20:29AM -0600, Uri Moszkowicz wrote:
> I tried the patch but it doesn't appear to have helped :( Clone time
> with it was ~32m.
That sounds ridiculously long.
> Do you all by any chance have a tool to obfuscate a repository?
> Probably I still wouldn't be permitted to
An off-list discussion made me wonder if something like this would be
useful:
git log -p --submodule=log:' %m %an <%ae>: %s'
where the format could be whatever you find useful.
I do not use submodules myself, so writing the patch below was just a
fun exercise. I'm not planning on polishing it
On Fri, Nov 02, 2012 at 03:43:24PM +0100, Michael J Gruber wrote:
> It seems that our fast-import is super picky with regards to author
> names. I've encountered author names like
>
> Foo Bar
> Foo Bar foo@dev.null
>
> in the self-hosting repo of some other dvcs, and the question is how to
On Fri, Nov 09, 2012 at 08:42:33AM +1300, Nathan Broadbent wrote:
> It sounds like we want a tool that combines the functionality of 'git add
> --patch', 'git checkout --patch', and other features, so that we can
> perform various actions on 'hunks' without switching context. What do you
> think a
On Tue, Nov 06, 2012 at 08:58:35AM +0800, Eric Miao wrote:
> > So, then the question is: What do you know/have? Is your patch the
> > output of "git format-patch", "git diff", or just some sort of diff
> > without any git information?
>
> That doesn't matter, all the info can be obtained from the
On Sun, Nov 04, 2012 at 12:50:58PM -0700, Jeffrey S. Haemer wrote:
> I got bitten by what follows. Yes, it's an edge case. Yes I now understand
> why it does what it does. Yes the right answer is "Don't do that, Jeff." :-)
>
> Still, it took me a little time to figure out what I'd done wrong beca
On Thu, Nov 08, 2012 at 01:30:38PM -0500, Eric wrote:
> > Looks reasonable. Sign-off?
> >
>
> Ah, right. Shall resend with signoff. Probably Tuesday - I'm on the
> road, and the git instance on my laptop is prone to library-load issues.
>
> Or you can just add
>
> Signed-off-by: Eric S. Raym
On Sun, Nov 04, 2012 at 09:31:17PM +0100, Joern Huxhorn wrote:
> git svn failed on me with the following error while cloning an SVN repository:
> r1216 = fcf69d5102378ee41217d60384b96549bf2173cb (refs/remotes/svn/trunk)
> Found possible branch point: svn+ssh://@/trunk =>
> svn+ssh://@/tags/_2
On Sun, Nov 04, 2012 at 10:07:54PM +0100, Johannes Sixt wrote:
> The value of $global_excludes is sometimes part of the output
> that is tested for. Since git on Windows only sees DOS style paths,
> we have to ensure that the "expected" values are constructed in
> the same manner. To account for t
On Sun, Nov 04, 2012 at 09:45:55AM -0800, rh wrote:
> The previous change created a dictionary of one-to-one elements when
> the intent was to map mutliple related types to one main type.
> e.g. bash, ksh, zsh, sh all map to sh since they share similar syntax
> This makes the mapping as the origin
On Sun, Nov 04, 2012 at 05:04:02PM -0500, Pete Wyckoff wrote:
> This bug was introduced in cb585a9 (git-p4: keyword
> flattening fixes, 2011-10-16). The newline character
> is indeed special, and $File$ expansions should not try
> to match across multiple lines.
>
> Based-on-patch-by: Chris Goar
On Sun, Nov 04, 2012 at 11:31:01PM -0500, Eric S. Raymond wrote:
>
> ---
> Documentation/git-fast-import.txt |8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
Looks reasonable. Sign-off?
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a m
On Mon, Nov 05, 2012 at 09:41:21AM +0100, Michael Haggerty wrote:
> Nothing really earthshattering here. But it's funny how every time I
> look closely at a site where I think string_lists could be used, I
> find problems with the old code. In this case is_absolute_path() is
> called with an arg
I tried the patch but it doesn't appear to have helped :( Clone time
with it was ~32m.
Do you all by any chance have a tool to obfuscate a repository?
Probably I still wouldn't be permitted to distribute it but might make
the option slightly more palatable. Anything else that I can do to
help debu
On Mon, Nov 05, 2012 at 06:50:47PM -0500, Phil Pennock wrote:
> Git configuration items can not contain underscores in their name; the
> 'remote_heads' feature can not be enabled on a per-repository basis with
> that name.
>
> This changes the git-config option to be `gitweb.remoteheads` but does
On 12-11-08 11:37 AM, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 8, 2012 at 5:24 PM, Marc Branchaud wrote:
>> I'd like there to be one list that always gets everything, and the other
>> lists should get subsets of the everything list.
>
> Since it supports multiple mailing lists per category yo
On Tue, Nov 06, 2012 at 10:17:21AM +1100, Michael Naumov wrote:
> As per discussion on msysgit user group:
> https://groups.google.com/forum/?fromgroups=#!topic/msysgit/U_a982_a3rc/discussion
> we found the following patch is required to get rid of weird terminal
> characters for other tools such
On Tue, Nov 06, 2012 at 08:54:07AM +0100, Michael Haggerty wrote:
> > I suspect this was not used originally because ALLOC_GROW relies on
> > alloc_nr, which does fast growth early on. At (x+16)*3/2, we end up with
> > 24 slots for the first allocation. We are typically splitting 1 or 2
> > values
On Thu, Nov 8, 2012 at 5:24 PM, Marc Branchaud wrote:
> I'd like there to be one list that always gets everything, and the other
> lists should get subsets of the everything list.
Since it supports multiple mailing lists per category you can always
do (I can't remember the specific config keys, b
On 12-11-08 07:17 AM, Michael Haggerty wrote:
> On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote:
>> [...]
>
> I'm glad it's getting some use. Thanks for the feedback.
>
>> I'll test it out some more, the issues I've had with it so far in
>> migrating from the existing script + some custom
On 12-11-08 04:42 AM, Michael Haggerty wrote:
> On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty
>> wrote:
>>> On 07/14/2012 08:59 AM, mhag...@alum.mit.edu wrote:
Add a new Python script, contrib/hooks/post-receive-multimail.py
On Wed, Nov 07, 2012 at 11:32:37AM -0600, Uri Moszkowicz wrote:
> #4 parse_object (sha1=0xb0ee98
> "\017C\205Wj\001`\254\356\307Z\332\367\353\233.\375P}D") at
> object.c:212
> #5 0x004ae9ec in handle_one_ref (path=0xb0eec0
> "refs/tags/", sha1=0xb0ee98
> "\017C\205Wj\001`\254\356\307
On Thu, Nov 8, 2012 at 1:17 PM, Michael Haggerty wrote:
> On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote:
>> [...]
>
> I'm glad it's getting some use. Thanks for the feedback.
>
>> I'll test it out some more, the issues I've had with it so far in
>> migrating from the existing script + som
On Wed, Nov 07, 2012 at 06:35:15PM -0500, Paul Fox wrote:
> the user's editor likely catches SIGINT (ctrl-C). but if the user
> spawns a command from the editor and uses ctrl-C to kill that command,
> the SIGINT will likely also kill git itself. (depending on the
> editor, this can leave the ter
On Thu, Nov 08, 2012 at 12:57:19AM -0800, Jonathon Mah wrote:
> I find myself performing similar actions to you: using git add -p to
> stage hunks, sometimes editing the staged patch; and keeping mental
> notes of things I wanted to revert, sometimes changing them in the
> editor in another window
On Thu, Nov 08, 2012 at 02:26:40PM +0100, Carlos Martín Nieto wrote:
> > When experimenting in order to train some colleagues, I saw that If I
> > clone a repository, I couldn't push to it because it was a non-bare
> > one.
> > Searchin for some explanations, I found this ressource:
> > http://www
Hi,
In article ,
McKown, John wrote:
> 1) is this the proper forum for asking general git usage questions, such
> as "how to"? If not, what is?
I'd say that here is fine. #git on freenode is also a good source of advice.
> 2) I am unsure that I did things the "proper" way. I have a
On Thu, 8 Nov 2012 08:26:22 -0600
"McKown, John" wrote:
> 1) is this the proper forum for asking general git usage questions,
> such as "how to"? If not, what is?
This list is okay for the general usage questions.
But since it's the place where the development questions are discussed
as well, an
Well, a message I read after posting seems to have answered question #3. I'll
look at "git checkout", which ignorant me thought was only used to change
branches.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76
1) is this the proper forum for asking general git usage questions, such as
"how to"? If not, what is?
2) I am unsure that I did things the "proper" way. I have a git maintained
subdirectory. I made some changes and saved them in the working directory, but
did not "git add" or "git commit" them
My company has a fairly large SVN repository, and I'm running into a
bug with git-svn where some revisions aren't being fetched.
The repository has a standard trunk/tags/branches layout, but there are
some top-level directories under trunk/ that clearly don't belong in Git, and
Mihamina Rakotomandimby writes:
> Hi all,
>
> We're on the way to have our first project using Git.
> We're currently mostly using Hg (90%) & SVN (10%).
>
> When experimenting in order to train some colleagues, I saw that If I
> clone a repository, I couldn't push to it because it was a non-bare
Jonathan Nieder wrote:
Different installers put the git-prompt.sh shell library at different
places on the installed system, so there is no shared location users
can count on:
Fedora - /etc/profile.d/git-prompt.sh
FWIW, we moved it to /usr/share/git-core/contrib/completion/ -- it was
only
On 11/08/2012 12:39 PM, Ævar Arnfjörð Bjarmason wrote:
> [...]
I'm glad it's getting some use. Thanks for the feedback.
> I'll test it out some more, the issues I've had with it so far in
> migrating from the existing script + some custom hacks we have to it
> have been:
>
> * Overly verbose d
On Thu, Nov 8, 2012 at 3:57 PM, Jonathon Mah wrote:
> Nathan,
>
> I find myself performing similar actions to you: using git add -p to stage
> hunks, sometimes editing the staged patch; and keeping mental notes of things
> I wanted to revert, sometimes changing them in the editor in another wind
On Thu, Nov 8, 2012 at 10:42 AM, Michael Haggerty wrote:
> On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote:
>> I'm curious as to whether you got around to this? I'd be interested in
>> updates on this script.
>
> Thanks for asking. I have made many of the changes that were requested
> and/o
Hi all,
We're on the way to have our first project using Git.
We're currently mostly using Hg (90%) & SVN (10%).
When experimenting in order to train some colleagues, I saw that If I
clone a repository, I couldn't push to it because it was a non-bare one.
Searchin for some explanations, I foun
On 11/07/2012 10:47 PM, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jul 20, 2012 at 12:01 PM, Michael Haggerty
> wrote:
>> On 07/14/2012 08:59 AM, mhag...@alum.mit.edu wrote:
>>>
>>> Add a new Python script, contrib/hooks/post-receive-multimail.py, that
>>> can be used to send notification emails de
Nathan,
I find myself performing similar actions to you: using git add -p to stage
hunks, sometimes editing the staged patch; and keeping mental notes of things I
wanted to revert, sometimes changing them in the editor in another window, and
sometimes reverting them after the add session with g
Nathan Broadbent gmail.com> writes:
> I would like to propose a revert option for 'git add --patch', that
> reverts the hunk. I often use `git add -p` to skip whitespace changes
> when preparing a patch, and a 'revert' option would save me from
> running 'git checkout ' after I've staged the desi
57 matches
Mail list logo
