* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 5:50 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jonathan Nieder, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAGdFq_gg3gPvCADje9ibz8xHgPOLF+=79EqksVzG2JeTOfHocw@mail.gmail.com>
On Thu, Oct 25, 2012 at 7:39 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>> The testcase is imho correct and does not need changing. So yes, I
>> don't want your help changing it. I don't suspect you will be using
>> "git fast-export $(git rev-parse master)..master". It is safe and
>> good to add additional testcases documenting the syntax that you do
>> use, as an independent topic.
>
> To re-iterate Dscho's point, the reason for this testcase is that if
> you do this:
> $ git checkout master
> $ git branch next
> $ git push hg://example.com master
> $ git push hg://example.com next
>
> With the current design, next will not be present on the remote. This
> is caused by the fact that git looks at "fast-export ^master next",
> sees that it's empty, and decides not to export anything. This patch
> series solves that, by having "fast-export ^master next" emit a "from
> :42\nreset next" (or something like that, assuming :42 is where master
> is currently at).
Only if the remote helper is using marks, and this particular patch is
adding a test-case without any use of marks at all.
IOW; this test is testing something completely different, which
happens to fix the original issue, but this is not the only way to
fix, and in IMO certainly not the best.
As I showed in my script above:
$ git checkout master
$ git branch next
$ git push hg://example.com master
$ git push hg://example.com next
This works just fine. Go ahead, apply my patch, and run it, the second
branch gets updated.
It will fail this test, but that's because the test is not testing
what it should: that *when using marks* the second branch exported is
ignored.
This test does that:
---
cat > expected << EOF
reset refs/heads/master
from ##mark##
EOF
test_expect_failure 'refs are updated even if no commits need to be exported' '
cp tmp-marks /tmp
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks master | true &&
git fast-export --import-marks=tmp-marks \
--export-marks=tmp-marks master > actual &&
mark=$(grep $(git rev-parse master) tmp-marks | cut -f 1 -d " ")
sed -i -e "s/##mark##/$mark/" expected &&
test_cmp expected actual
'
---
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 5:40 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121025052823.GB11243@elie.Belkin>
On Thu, Oct 25, 2012 at 7:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> I don't need help, I am helping you, I was asked to take a look at
>> this patch series. If you don't want my help, then by all means, keep
>> this series rotting, it has being doing so for the past year without
>> anybody complaining.
>
> Ah, so _that_ (namely getting Sverre's remote helper to work) is the
> work you were trying to do. Thanks for explaining.
No, that's not what I'm doing. I haven't even seen a remote-hg branch
from either Sverre, or Johannes. IIRC the msysgit wiki mentions that
there were some patches not quite accepted in upstream that prevented
the remote-hg from getting upstream. But I don't know which patches
are those, I don't know why they are needed, and I haven't even been
able to run this stuff.
I was told this might be an issue for all remote helpers, and it seems
to be the case (albeit a small issue IMO).
> If I understand correctly, it is possible to get Sverre's remote
> helper to work without affecting this particular testcase. From that
> point of view I think you were on the right track.
That makes sense. So are there any other patches?
> The testcase is imho correct and does not need changing. So yes, I
> don't want your help changing it. I don't suspect you will be using
> "git fast-export $(git rev-parse master)..master". It is safe and
> good to add additional testcases documenting the syntax that you do
> use, as an independent topic.
All right, so I run this and get this:
% git fast-export master..master
reset refs/heads/master
from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
As an user of fast-export, what do I do with that now?
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Sverre Rabbelier @ 2012-10-25 5:39 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Felipe Contreras, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121025052823.GB11243@elie.Belkin>
On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> The testcase is imho correct and does not need changing. So yes, I
> don't want your help changing it. I don't suspect you will be using
> "git fast-export $(git rev-parse master)..master". It is safe and
> good to add additional testcases documenting the syntax that you do
> use, as an independent topic.
To re-iterate Dscho's point, the reason for this testcase is that if
you do this:
$ git checkout master
$ git branch next
$ git push hg://example.com master
$ git push hg://example.com next
With the current design, next will not be present on the remote. This
is caused by the fact that git looks at "fast-export ^master next",
sees that it's empty, and decides not to export anything. This patch
series solves that, by having "fast-export ^master next" emit a "from
:42\nreset next" (or something like that, assuming :42 is where master
is currently at).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-25 5:28 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s1Pe8Ef6-GRbmSs7rY7gWyaPCN+jWGysyttZp3drSDoZg@mail.gmail.com>
Felipe Contreras wrote:
> I don't need help, I am helping you, I was asked to take a look at
> this patch series. If you don't want my help, then by all means, keep
> this series rotting, it has being doing so for the past year without
> anybody complaining.
Ah, so _that_ (namely getting Sverre's remote helper to work) is the
work you were trying to do. Thanks for explaining.
If I understand correctly, it is possible to get Sverre's remote
helper to work without affecting this particular testcase. From that
point of view I think you were on the right track.
The testcase is imho correct and does not need changing. So yes, I
don't want your help changing it. I don't suspect you will be using
"git fast-export $(git rev-parse master)..master". It is safe and
good to add additional testcases documenting the syntax that you do
use, as an independent topic.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 5:18 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121025042731.GA11243@elie.Belkin>
On Thu, Oct 25, 2012 at 6:27 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> Again, if you don't have marks, I don't see what you expect to be
>> exported with 'master..master', even with marks, I don't see what you
>> expect.
>
> And that's fine. Unless you were trying to do some work and this lack
> of understanding got in the way.
What is fine? What lack of understanding?
You still haven't said what you expect the output to be.
Consider this repo:
---
git init test
cd test
echo one >> file
git add --all
git commit -m 'one'
echo two >> file
git commit -m 'one'
---
What *exactly* should the output of 'git fast-export master..master'
be? I say nothing, what do you say?
> In that case, with a calmer and more humble approach you might find
> people willing to help you. Maybe they will learn something from you,
> too.
I don't need help, I am helping you, I was asked to take a look at
this patch series. If you don't want my help, then by all means, keep
this series rotting, it has being doing so for the past year without
anybody complaining.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 5:13 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sverre Rabbelier, Junio C Hamano, Jonathan Nieder, Jeff King,
Git List, Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Ævar Arnfjörð Bjarmason, Eric Herman,
Fernando Vezzosi
In-Reply-To: <alpine.DEB.1.00.1210242333550.5980@bonsai2>
On Wed, Oct 24, 2012 at 11:41 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 24 Oct 2012, Felipe Contreras wrote:
>
>> 2) master..master shouldn't export anything
>
> The underlying issue -- as explained in the thread -- is when you want to
> update master to a commit that another ref already points to. In that case
> no commits need to exported, but the ref needs to be updated nevertheless.
>
> We just wrote the test in the most convenient way, no need to complicate
> things more than necessary.
That test cannot work, and it shouldn't work.
You say you want to 'update master to a commit that another ref
already points to'. What other ref? If you want to update master, this
is what you do:
% git fast-export master
What do you expect 'git fast-export master..master' to export? This?
---
reset refs/heads/master
from $(git rev-parse master)
---
What is a remote helper supposed to do with a SHA-1? Nothing, a git
SHA-1 is useless to say, a mercurial remote helper. To make sense of
it you would need to access the git repository and get the commit
object, and that's defeating the purpose of a fast exporter.
No, that's not what you want.
But at this point there's only one ref in the picture, you said
'update master to a commit that another ref already points to', but
there's only one ref, where is the other ref?
Maybe your test should do this:
% git fast-export foo master
But wait, that actually works, except that the output will be nothing
close what you expected before, we would get all the commits and files
that constitute 'foo', which is actually useful, and what we expect
from fast-export, and in addition, master will be updated to the right
ref.
No, the problem is not only 'update master to a commit that another
ref already points to', but that this happens in two different
commands, and that can only be done with marks, just like the test I
proposed.
The original test doesn't expose the problem we are trying to solve,
and it shouldn't work anyway.
Moreover, what we eventually want to do is support the transport
helpers, so how about you run this:
---
#!/bin/sh
cat > git-remote-foo <<-\EOF
#!/bin/sh
read l
echo $l 1>&2
echo export
echo refspec refs/heads/*:refs/foo/origin/*
test -e /tmp/marks-git && echo *import-marks /tmp/marks-git
echo *export-marks /tmp/marks-git
echo
read l
echo $l 1>&2
echo ? refs/heads/master
echo
read l
echo $l 1>&2
while read l; do
echo $l 1>&2
test "$l" == 'done' && exit
done
EOF
chmod +x git-remote-foo
export PATH=$PWD:$PATH
rm -f /tmp/marks-git
(
git init test
cd test
echo Test >> Test
git add --all
git commit -m 'Initial commit'
git branch foo
echo "== master =="
git push foo::test master
echo "== foo =="
git push foo::test foo
)
---
I get this output with my patch:
---
[master (root-commit) b159eff] Initial commit
1 file changed, 1 insertion(+)
create mode 100644 Test
== master ==
capabilities
list
export
feature done
blob
mark :1
data 5
Test
reset refs/heads/master
commit refs/heads/master
mark :2
author Felipe Contreras <felipe.contreras@gmail.com> 1351140987 +0200
committer Felipe Contreras <felipe.contreras@gmail.com> 1351140987 +0200
data 15
Initial commit
M 100644 :1 Test
done
== foo ==
capabilities
list
export
feature done
reset refs/heads/foo
from :2
done
---
Hey, did you see that? 'foo' is updated, both 'master' and 'foo' point
to the same object.
What is the problem?
--
Felipe Contreras
^ permalink raw reply
* Re: t9401 fails with OS X sed
From: Geert Bosch @ 2012-10-25 5:04 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <609AC6E7-45CD-4472-B1DC-FBB785D6B815@gernhardtsoftware.com>
On Oct 24, 2012, at 23:54, Brian Gernhardt <brian@gernhardtsoftware.com> wrote:
> It works if I change \s to [[:space:]], but I don't know how portable that is.
As \s is shorthand for the POSIX character class [:space:], I'd say the latter
should be more portable: anything accepting the shorthand should also accept
the full character class. If not, you probably only care about horizontal tab
and space, for which you could just use a simple regular expression. Just a
literal space and tab character between square brackets is probably going to be
most portable, though not most readable.
-Geert
^ permalink raw reply
* Re: Git push slowly under 1000M/s network
From: Joey Jiao @ 2012-10-25 5:04 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <CAJo=hJuGksy7pzzy7-7eTUxNmtT9qR2xCPxSfYO58_8SohFjxQ@mail.gmail.com>
Yes, I believe it's gerrit problem and will discuss there.
During first minutes of restarting gerrit, the pushing becomes quite
faster 13s instead.
2012/10/24 Shawn Pearce <spearce@spearce.org>:
> On Mon, Oct 22, 2012 at 11:27 PM, Joey Jiao <joey.jiaojg@gmail.com> wrote:
>> It looks like the client is waiting the pushing result status from
>> server although by checking server side, the real object has already
>> been upload succeed.
>>
>> Below is the log after adding time info.
>> $ time git push -v ssh://git.qrd.qualcomm.com:29418/kernel/msm.git
>> HEAD:refs/changes/33599 2>&1|tee -a log.txt
> ...
>> remote: Resolving deltas: 0% (0/2)
>> remote: (W) afafdad: no files changed, message updated
> ...
>> real 9m56.928s
>> user 0m0.364s
>> sys 0m0.160s
>
> What version of Gerrit are you using?
> How many changes already exist in this project?
>
> I am fairly certain this is an issue with Gerrit. Which may be better
> discussed at http://groups.google.com/group/repo-discuss
--
-Joey Jiao
^ permalink raw reply
* [PATCH] Fixes handling of --reference argument.
From: szager @ 2012-10-25 4:52 UTC (permalink / raw)
To: git
Signed-off-by: Stefan Zager <szager@google.com>
---
git-submodule.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..dcceb43 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -270,7 +270,6 @@ cmd_add()
;;
--reference=*)
reference="$1"
- shift
;;
--)
shift
--
1.7.7.3
^ permalink raw reply related
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Jonathan Nieder @ 2012-10-25 4:27 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s2kjv9fHbruXv7NyVm9m+FjFnYDryuPZQ-RQXN9Nj6MAw@mail.gmail.com>
Felipe Contreras wrote:
> Again, if you don't have marks, I don't see what you expect to be
> exported with 'master..master', even with marks, I don't see what you
> expect.
And that's fine. Unless you were trying to do some work and this lack
of understanding got in the way.
In that case, with a calmer and more humble approach you might find
people willing to help you. Maybe they will learn something from you,
too.
Ciao,
Jonathan
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Felipe Contreras @ 2012-10-25 4:19 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Sverre Rabbelier, Junio C Hamano, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð, Eric Herman,
Fernando Vezzosi
In-Reply-To: <20121024191149.GA3120@elie.Belkin>
On Wed, Oct 24, 2012 at 9:11 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Felipe Contreras wrote:
>
>> Does it mean that? I don't think so, but let's assume that's the case.
>>
>> We don't have all those commits; without the marks we have nothing. Or
>> what exactly do you mean by 'we'?
>
> Not everyone uses marks.
When you don't have marks you have to export *everything* that you are
interested. If you want all the history from the root to master, then
that's what you will get (and you specify 'master'), if you want only
the commit pointed to master and nothing else that's what you will get
(with 'master^..master'), but when you do 'master..master', you get
nothing, because that's what you asked for.
Again, if you don't have marks, I don't see what you expect to be
exported with 'master..master', even with marks, I don't see what you
expect.
--
Felipe Contreras
^ permalink raw reply
* t9401 fails with OS X sed
From: Brian Gernhardt @ 2012-10-25 3:54 UTC (permalink / raw)
To: Git List
I seem to write these kinds of e-mails fairly regularly...
When running t9401-git-cvsserver-crlf:
expecting success:
check_status_options cvswork2 textfile.c "" &&
check_status_options cvswork2 binfile.bin -kb &&
check_status_options cvswork2 .gitattributes "" &&
check_status_options cvswork2 mixedUp.c -kb &&
check_status_options cvswork2 multiline.c -kb &&
check_status_options cvswork2 multilineTxt.c "" &&
check_status_options cvswork2/subdir withCr.bin -kb &&
check_status_options cvswork2 subdir/withCr.bin -kb &&
check_status_options cvswork2/subdir file.h "" &&
check_status_options cvswork2 subdir/file.h "" &&
check_status_options cvswork2/subdir unspecified.other "" &&
check_status_options cvswork2/subdir newfile.bin "" &&
check_status_options cvswork2/subdir newfile.c ""
not ok - 12 cvs status - sticky options
I have tracked it down to a sed expression that is parsing the output of cvs status:
49: got="$(sed -n -e 's/^\s*Sticky Options:\s*//p' "${WORKDIR}/status.out")"
The problem is that cvs outputs "Sticky Options:\t\t(none)\n", but OS X's sed doesn't recognize the \s shortcut. (According to re_format(5), \s is part of the "enhanced" regex format, which sed doesn't use.)
It works if I change \s to [[:space:]], but I don't know how portable that is.
~~ Brian Gernhardt
^ permalink raw reply
* Re: [PATCH] Fix git p4 sync errors
From: Matt Arsenault @ 2012-10-25 2:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pete Wyckoff, Luke Diamand
In-Reply-To: <7vwqyjfxwd.fsf@alter.siamese.dyndns.org>
On Oct 21, 2012, at 12:06 , Junio C Hamano <gitster@pobox.com> wrote:
>
>>
>> This solves errors in some cases when syncing renamed files.
>
> Can you be a bit more descriptive? What are "errors in some case"?
>
It might just be when files are renamed. I ran into this after months of using it, and I'm skeptical that in that time no files were ever renamed. I'm not sure what was special about the file that was renamed. (There also might have been deleted files in the same commit, not sure if that matters)
> In short, what I am getting at are:
>
> - What breaks by not passing "-s"? What are the user visible
> symptoms?
There's a key error on the line
line 2198: epoch = details["time"]
The details object is an error different fields set (I don't remember what it is exactly, I'm not at work right now)
>
> - Why is it a bug not to pass "-s"? How does the bug happen?
I encountered this one time after using it for months. One day I couldn't git p4 rebase with the key error. I searched for the error and found some version of git-p4 that fixed a similar error by adding the -s to describe. Adding the -s fixed the error and everything seemed to be working correctly.
^ permalink raw reply
* Re: Where should git-prompt.sh be installed?
From: Drew Northup @ 2012-10-25 1:59 UTC (permalink / raw)
To: Jonathan Nieder
Cc: git, Anders Kaseorg, Danny Yates, Felipe Contreras, Ted Pavlic,
SZEDER Gábor, Dan McGee
In-Reply-To: <20121025005106.GA9112@elie.Belkin>
On Wed, Oct 24, 2012 at 8:51 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Now the sysadmin should copy
> contrib/completion/git-completion.sh to
>
> /usr/share/bash-completion/completions/git
>
> and contrib/completion/git-prompt.sh to
>
> /usr/share/git-core/contrib/?? (somewhere?)
>
> Mortals source /etc/bash_completion in their ~/.bashrc (possibly
> shared among multiple machines) and expect bash completion to work.
> For __git_ps1, users should source that ?? path.
>
> Questions:
>
> 1) what path is appropriate for ?? above?
> 2) is this documented anywhere?
>
> Possible answers:
>
> 1) Fedora uses /etc/profile.d/git-prompt.sh. Gentoo uses
> /usr/share/bash-completion/git-prompt. Maybe others use
> some other path.
>
> 2) The scripts themselves suggest copying to ~/.git-completion.sh
> and ~/.git-prompt.sh.
>
> Proposal:
>
> 1) /usr/lib/git-core/git-sh-prompt
> 2) git-sh-prompt(1)
>
> Sensible?
Does the LSB provide any guidance? If not, or if such guidance isn't
helpful, I say that looks reasonable.
What I'd like to know is why we are saying "copy" when symlinking is
likely to be more easily maintainable? (Less chance to screw up.)
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH] git-submodule add: Record branch name in .gitmodules
From: W. Trevor King @ 2012-10-25 1:12 UTC (permalink / raw)
To: Phil Hord; +Cc: git
In-Reply-To: <CABURp0rpPqeTJMYXmgMG2CmU=SzzvCMeX46rnMVB0EeB_LXPiA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 623 bytes --]
On Wed, Oct 24, 2012 at 02:12:18PM -0400, Phil Hord wrote:
> + VAR_NAME=$(printf '%s'
> "$VAR_NAME" | tr A-Z a-z | sed -e 's/^[^a-z]/_/' -e 's/[^a-z0-9]/_/g')
Is there a reason why you use printf instead of echo?
Also, this sort of name cleaning should probably live in a new
function:
clean_environment_variable()
or some such. Is there a git-utility-functions.sh library hiding
somewhere in the source? ;)
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] git-submodule add: Record branch name in .gitmodules
From: W. Trevor King @ 2012-10-22 22:55 UTC (permalink / raw)
To: Phil Hord
In-Reply-To: <CABURp0pqg7XC6makK2OcundMabV9AtcBNGNK6Q0TMZfJbt3anw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2912 bytes --]
On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote:
> Some projects now use the 'branch' config value to record the tracking
> branch for the submodule. Some ascribe different meaning to the
> configuration if the value is given vs. undefined. For example, see
> the Gerrit submodule-subscription mechanism. This change will cause
> those workflows to behave differently than they do now.
For those to lazy to hunt down a reference, Gerrit uses
submodule.$name.branch to
“indicate the branch of a submodule project that when updated will
trigger automatic update of its registered gitlink.” [1]
They also have some extra sauce:
“The branch value could be '.' if the submodule project branch has
the same name as the destination branch of the commit having
gitlinks/.gitmodules file.
…
Any git submodules which are added and not have the branch field
available in the .gitmodules file will not be subscribed by Gerrit
to automatically update the superproject.”
> I do like the idea, but I wish it had a different name for the
> recording. Maybe --record-branch=${BRANCH} as an extra switch so the
> action is explicitly requested.
>
> git submodule add --branch=master --record-branch=master foo bar
Ugh, I don't want to retype the branch name whenever I do this.
<brainstorming>
How about -r/--record, with the recorded name being optional?
--record-branch[=<recorded_name>]
This would satisfy Gerrit users that wanted to use '.', but also
satisfy me with:
git submodule add -rb=master foo bar
However, there is a change that people would see that, and then use
git submodule add -r -b=master foo bar
which would checkout the HEAD from foo and store `-b=master` in
submodule.$name.branch.
A more verbose, but less dangerous, option would be a boolean
-r/--record that enables the recording of whatever was passed to
-b/--branch. This looses the flexibility of running something like
git submodule add --branch=master --record-branch=. foo bar
but the Gerrit folks have gotten along OK without any branch recording
so far ;). They can keep setting '.' the same way they always have.
</brainstorming>
On a tangentially related note, it would be nice to set environment
variables for each of the settings in submodule.$name during a foreach
call. Then you could use
git submodule foreach 'git checkout $branch && git pull'
Perhaps you'd want to blacklist/whitelist or downcase settings names
to avoid things like
[submodule "foo"]
PATH = /my/rootkit/
but the update line is much cleaner.
Cheers,
Trevor
[1]: https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Is git mktag supposed to accept git cat-file input?
From: Anand Kumria @ 2012-10-25 0:58 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <CA+sFfMdaaTwc82-J6a=wdjDzAFq6z8PS2rjSZ=tuyweOzuf4Kg@mail.gmail.com>
Ahh, unix time. Of course.
Thanks Brandon.
On 25 October 2012 01:18, Brandon Casey <drafnel@gmail.com> wrote:
> On Wed, Oct 24, 2012 at 4:39 PM, Anand Kumria <akumria@acm.org> wrote:
>> Hi,
>>
>> I am doing some experimenting with git-mktag, and was looking into the
>> format it expects on input.
>>
>> Should this sequence of commands work?
>
> Yes, with a slight tweak...
>
>> kalki:[/tmp/gittest]% git tag -m "tag-test" tag-test
>> kalki:[/tmp/gittest]% git cat-file -p e619
>
> '-p' means pretty-print, i.e. produce a human-readable format. mktag
> supports the raw format. So you should invoke it like this:
>
> $ git cat-file tag e619
>
> which should produce something like:
>
> object c0ae36fee730f7034b1f76c1490fe6f46f7ecad5
> type commit
> tag tag-test
> tagger Anand Kumria <akumria@acm.org> 1351121552 +0100
>
> tag-test
>
> and is the format expected by mktag.
>
> -Brandon
>
--
“Don’t be sad because it’s over. Smile because it happened.” – Dr. Seuss
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King @ 2012-10-25 0:53 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git, Nahor, Phil Hord
In-Reply-To: <50883E54.4080507@web.de>
[-- Attachment #1: Type: text/plain, Size: 901 bytes --]
On Wed, Oct 24, 2012 at 09:15:32PM +0200, Jens Lehmann wrote:
> I still fail to see what adding that functionality to the submodule
> command buys us (unless we also add code which really uses the branch
> setting). What's wrong with doing a simple:
>
> git config -f .gitmodules submodule.<path>.branch <record_branch>
>
> on the command line when you want to use the branch setting for your
> own purposes? You could easily wrap that into a helper script, no?
Sure. But why maintain my own helper script if I can edit
git-submodules.sh? It seems like a number of people are using this
config option, and they generally store the same name in it that they
use to create the submodule. This way I can save them time too.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Where should git-prompt.sh be installed?
From: Jonathan Nieder @ 2012-10-25 0:51 UTC (permalink / raw)
To: git
Cc: Anders Kaseorg, Danny Yates, Felipe Contreras, Ted Pavlic,
SZEDER Gábor, Dan McGee
In-Reply-To: <1337719600-7361-3-git-send-email-felipe.contreras@gmail.com>
Hi,
In olden days the admin would copy contrib/completion/git-completion.sh
to
/etc/bash_completion.d/git
and mortals could source /etc/bash_completion or
/etc/bash_completion.d/git in their ~/.bashrc (possibly shared among
multiple machines) so that the bash completion and __git_ps1 helpers
could work.
With Git 1.7.12 __git_ps1 has been split into a separate file, to help
users who only want __git_ps1 to avoid the overhead of loading the
entire completion script (and allow the completion script to be loaded
by bash-completion magic on the fly!). Now the sysadmin should copy
contrib/completion/git-completion.sh to
/usr/share/bash-completion/completions/git
and contrib/completion/git-prompt.sh to
/usr/share/git-core/contrib/?? (somewhere?)
Mortals source /etc/bash_completion in their ~/.bashrc (possibly
shared among multiple machines) and expect bash completion to work.
For __git_ps1, users should source that ?? path.
Questions:
1) what path is appropriate for ?? above?
2) is this documented anywhere?
Possible answers:
1) Fedora uses /etc/profile.d/git-prompt.sh. Gentoo uses
/usr/share/bash-completion/git-prompt. Maybe others use
some other path.
2) The scripts themselves suggest copying to ~/.git-completion.sh
and ~/.git-prompt.sh.
Proposal:
1) /usr/lib/git-core/git-sh-prompt
2) git-sh-prompt(1)
Sensible?
Thanks,
Jonathan
^ permalink raw reply
* Re: Is git mktag supposed to accept git cat-file input?
From: Brandon Casey @ 2012-10-25 0:18 UTC (permalink / raw)
To: Anand Kumria; +Cc: git
In-Reply-To: <CAM1C4GneOnyBQyJRbhtuYNDsc4NxXgFcfHrQpziLpp_AY0TjbA@mail.gmail.com>
On Wed, Oct 24, 2012 at 4:39 PM, Anand Kumria <akumria@acm.org> wrote:
> Hi,
>
> I am doing some experimenting with git-mktag, and was looking into the
> format it expects on input.
>
> Should this sequence of commands work?
Yes, with a slight tweak...
> kalki:[/tmp/gittest]% git tag -m "tag-test" tag-test
> kalki:[/tmp/gittest]% git cat-file -p e619
'-p' means pretty-print, i.e. produce a human-readable format. mktag
supports the raw format. So you should invoke it like this:
$ git cat-file tag e619
which should produce something like:
object c0ae36fee730f7034b1f76c1490fe6f46f7ecad5
type commit
tag tag-test
tagger Anand Kumria <akumria@acm.org> 1351121552 +0100
tag-test
and is the format expected by mktag.
-Brandon
^ permalink raw reply
* Is git mktag supposed to accept git cat-file input?
From: Anand Kumria @ 2012-10-24 23:39 UTC (permalink / raw)
To: git
Hi,
I am doing some experimenting with git-mktag, and was looking into the
format it expects on input.
Should this sequence of commands work?
kalki:[~]% mkdir /tmp/gittest; cd /tmp/gittest
kalki:[/tmp/gittest]% git init
Initialized empty Git repository in /tmp/gittest/.git/
kalki:[/tmp/gittest]% echo "test" > test
kalki:[/tmp/gittest]% git add test
kalki:[/tmp/gittest]% git commit -m "commit-test"
[master (root-commit) c0ae36f] commit-test
1 file changed, 1 insertion(+)
create mode 100644 test
kalki:[/tmp/gittest]% git tag -m "tag-test" tag-test
kalki:[/tmp/gittest]% git cat-file -p e619
object c0ae36fee730f7034b1f76c1490fe6f46f7ecad5
type commit
tag tag-test
tagger Anand Kumria <akumria@acm.org> Thu Oct 25 00:32:32 2012 +0100
tag-test
kalki:[/tmp/gittest]% git cat-file -p e619 | sed
-e's/tag-test/tag-test2/' > tag-test2
kalki:[/tmp/gittest]% cat tag-test2
object c0ae36fee730f7034b1f76c1490fe6f46f7ecad5
type commit
tag tag-test2
tagger Anand Kumria <akumria@acm.org> Thu Oct 25 00:32:32 2012 +0100
tag-test2
kalki:[/tmp/gittest]% git mktag < tag-test2
error: char112: missing tag timestamp
fatal: invalid tag signature file
kalki:[/tmp/gittest]% git --version
git version 1.7.9.5
The error message related to the timezone / timestamp being incorrect
but I can't see what the problem is.
Any advice appreciated.
Please CC me as I may miss your reply.
Thanks,
Anand
--
“Don’t be sad because it’s over. Smile because it happened.” – Dr. Seuss
^ permalink raw reply
* Re: [PATCH 1/3] t9350: point out that refs are not updated correctly
From: Johannes Schindelin @ 2012-10-24 21:41 UTC (permalink / raw)
To: Felipe Contreras
Cc: Sverre Rabbelier, Junio C Hamano, Jonathan Nieder, Jeff King,
Git List, Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Ævar Arnfjörð Bjarmason, Eric Herman,
Fernando Vezzosi
In-Reply-To: <CAMP44s1hdZb_7Lv8SEe+MsfC_q-nXsnjJobABFq6eFR_er4TaA@mail.gmail.com>
Hi,
On Wed, 24 Oct 2012, Felipe Contreras wrote:
> 2) master..master shouldn't export anything
The underlying issue -- as explained in the thread -- is when you want to
update master to a commit that another ref already points to. In that case
no commits need to exported, but the ref needs to be updated nevertheless.
We just wrote the test in the most convenient way, no need to complicate
things more than necessary.
Hth,
Johannes
^ permalink raw reply
* [PATCH] git-send-email: add rfc2047 quoting for "=?"
From: Krzysztof Mazur @ 2012-10-24 21:28 UTC (permalink / raw)
To: peff; +Cc: gitster, git, Krzysztof Mazur
In-Reply-To: <20121024210826.GA23562@shrek.podlesie.net>
For raw subjects rfc2047 quoting is needed not only for non-ASCII characters,
but also for any possible rfc2047 in it.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
Oops, this ugly Subject was generated by git format-patch (both 1.8.0
and km/send-email-compose-encoding).
git-send-email.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index eb1b876..cfd20fa 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -908,7 +908,7 @@ sub is_rfc2047_quoted {
sub subject_needs_rfc2047_quoting {
my $s = shift;
- return ($s =~ /[^[:ascii:]]/);
+ return ($s =~ /[^[:ascii:]]/) || ($s =~ /=\?/);
}
sub quote_subject {
--
1.8.0.rc0.30.g72615bf
^ permalink raw reply related
* Re: [PATCH] git-send-email: skip RFC2047 quoting for ASCII subjects
From: Krzysztof Mazur @ 2012-10-24 21:08 UTC (permalink / raw)
To: Jeff King; +Cc: gitster, git
In-Reply-To: <20121024192530.GA26477@sigill.intra.peff.net>
On Wed, Oct 24, 2012 at 03:25:30PM -0400, Jeff King wrote:
> Right, but I was specifically worried about raw "=?", which is only an
> issue due to rfc2047 itself.
>
> However, reading the patch again, we are already checking for that with
> is_rfc2047_quoted. It might miss the case where we have =? but not the
> rest of a valid encoded word, but any compliant parser should recognize
> that and leave it be.
>
> So I think your original patch is actually correct.
>
> [...]
> We have a possibly already-encoded header, and we would want to avoid
> double-encoding it.
>
> In the first case, the "wants quoting" logic should be:
>
> is_rfc2047_quoted($subject) || /[^[:ascii:]]/
>
> and in the latter case it would be:
>
> !is_rfc2047_quoted($subject) && /^[:ascii:]]/
>
ok, I'm sending a version that just adds quote_subject() without
changing any logic, so now we still have in first case:
/[^[:ascii:]]/
and in the latter case:
!is_rfc2047_quoted($subject) && /^[:ascii:]]/
In the next patch I will just add matching for "=?" in
subject_needs_rfc2047_quoting() and we will have:
/=?/ || /[^[:ascii:]]/
and in the latter case:
!is_rfc2047_quoted($subject) && (/=\?/ || /^[:ascii:]]/)
This will also add quoting for any rfc2047 quoted subject or any
other rfc2047-like subject, as you suggested.
Krzysiek
--
From a70c5385f9b4da69a8ce00a1448f87f63bbd500d Mon Sep 17 00:00:00 2001
From: Krzysztof Mazur <krzysiek@podlesie.net>
Date: Wed, 24 Oct 2012 22:46:00 +0200
Subject: [PATCH] git-send-email: introduce quote_subject()
The quote_rfc2047() always adds RFC2047 quoting and to avoid quoting ASCII
subjects, before calling quote_rfc2047() subject must be tested for non-ASCII
characters. To avoid this new quote_subject() function is introduced.
The quote_subject() performs this test and calls quote_rfc2047() only if
necessary.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
git-send-email.perl | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index efeae4c..eb1b876 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -657,9 +657,7 @@ EOT
$initial_subject = $1;
my $subject = $initial_subject;
$_ = "Subject: " .
- ($subject =~ /[^[:ascii:]]/ ?
- quote_rfc2047($subject, $compose_encoding) :
- $subject) .
+ quote_subject($subject, $compose_encoding) .
"\n";
} elsif (/^In-Reply-To:\s*(.+)\s*$/i) {
$initial_reply_to = $1;
@@ -907,6 +905,22 @@ sub is_rfc2047_quoted {
$s =~ m/^(?:"[[:ascii:]]*"|=\?$token\?$token\?$encoded_text\?=)$/o;
}
+sub subject_needs_rfc2047_quoting {
+ my $s = shift;
+
+ return ($s =~ /[^[:ascii:]]/);
+}
+
+sub quote_subject {
+ local $subject = shift;
+ my $encoding = shift || 'UTF-8';
+
+ if (subject_needs_rfc2047_quoting($subject)) {
+ return quote_rfc2047($subject, $encoding);
+ }
+ return $subject;
+}
+
# use the simplest quoting being able to handle the recipient
sub sanitize_address {
my ($recipient) = @_;
@@ -1327,9 +1341,8 @@ foreach my $t (@files) {
$body_encoding = $auto_8bit_encoding;
}
- if ($broken_encoding{$t} && !is_rfc2047_quoted($subject) &&
- ($subject =~ /[^[:ascii:]]/)) {
- $subject = quote_rfc2047($subject, $auto_8bit_encoding);
+ if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
+ $subject = quote_subject($subject, $auto_8bit_encoding);
}
if (defined $author and $author ne $sender) {
--
1.8.0.4.ge8ddce6
^ permalink raw reply related
* strange problems applying --no-prefix patch with -p0 and added files
From: Sergey Shelukhin @ 2012-10-24 20:54 UTC (permalink / raw)
To: git
Hello.
I am trying to apply a patch made via {git diff somehash^ somehash >
....} before (same version of Git, same machine). I have no-prefix
enabled by default.
If I try to apply the patch with -p0, it fails.
If I go to a directory where all the changed files are ("src/" below)
to "simulate" the prefix for -p1, it silently does nothing.
Only if I make it a -p1 patch, it actually tries to do apply (and
applies the new files that cause problems in -p0 alright too, if used
with --reject).
I am relatively new to git, so while researching I realized I might be
using wrong ways to do things (e.g. not using cherry-pick), but this
seems like a bug regardless.
Here's the log of my interactions with git:
reznor-mbp:git-hbase-089 sergey$ git version
git version 1.7.10.2 (Apple Git-33)
reznor-mbp:git-hbase-089 sergey$ git status
# On branch 0.94
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# HBASE-6371.patch
nothing added to commit but untracked files present (use "git add" to track)
reznor-mbp:git-hbase-089 sergey$ git apply -p0 HBASE-6371.patch
fatal: git apply: bad git-diff - inconsistent new filename on line 128
reznor-mbp:git-hbase-089 sergey$ sed -n 125,129p HBASE-6371.patch
diff --git src/main/java/org/apache/
hadoop/hbase/regionserver/CompactSelection.java
src/main/java/org/apache/hadoop/hbase/regionserver/CompactSelection.java
new file mode 100644
index 0000000..a9ee0d4
--- /dev/null
+++ src/main/java/org/apache/hadoop/hbase/regionserver/CompactSelection.java
reznor-mbp:git-hbase-089 sergey$ cd src
reznor-mbp:src sergey$ git apply -p1 -v --whitespace=nowarn ../HBASE-6371.patch
[ there's nothing here, e.g. no output ]
reznor-mbp:src sergey$ git status
# On branch 0.94
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# ../HBASE-6371.patch
nothing added to commit but untracked files present (use "git add" to track)
reznor-mbp:src sergey$ cd ..
reznor-mbp:git-hbase-089 sergey$ sed -E "s/(--git|---) src/\1 a\/src/"
HBASE-6371.patch | sed -E "s/ src\// b\/src\//" >
HBASE-6371-prefix.patch
reznor-mbp:git-hbase-089 sergey$ git apply HBASE-6371-prefix.patch
HBASE-6371-prefix.patch:169: trailing whitespace.
...
error: patch failed:
src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java:64
error: src/main/java/org/apache/hadoop/hbase/HBaseConfiguration.java:
patch does not apply
....
^ 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