* [PATCH v4 1/4] git-submodule add: Add --local-branch option
From: W. Trevor King @ 2012-11-26 21:00 UTC (permalink / raw)
To: Git
Cc: Heiko Voigt, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor, W. Trevor King
In-Reply-To: <cover.1353962698.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This option allows you to record a submodule.<name>.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 consumers:
Ævar uses this setting to designate the local branch to checkout when
pulling submodule updates:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
as he describes in
commit f030c96d8643fa0a1a9b2bd9c2f36a77721fb61f
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Earlier version of this patch remained agnostic on the variable usage,
but this was deemed potentially confusing. Future patches in this
series will extend the submodule command to use the stored value
internally.
[1] https://gerrit.googlesource.com/gerrit/+/master/Documentation/user-submodules.txt
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 12 ++++++++++--
Documentation/gitmodules.txt | 5 +++++
git-submodule.sh | 19 ++++++++++++++++++-
t/t7400-submodule-basic.sh | 25 +++++++++++++++++++++++++
4 files changed, 58 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index b4683bb..d0b4436 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,8 +9,8 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b branch] [-f|--force]
- [--reference <repository>] [--] <repository> [<path>]
+'git submodule' [--quiet] add [-b branch] [--local-branch[=<branch>]]
+ [-f|--force] [--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
@@ -209,6 +209,14 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+--local-branch::
+ Record a branch name used as `submodule.<path>.branch` in
+ `.gitmodules` for future reference. If you do not list an explicit
+ name here, the name given with `--branch` will be recorded. If that
+ is not set either, `HEAD` will be recorded. Because the branch name
+ is optional, you must use the equal-sign form
+ (`--local-branch=<branch>`), not `--local-branch <branch>`.
+
-f::
--force::
This option is only valid for add and update commands.
diff --git a/Documentation/gitmodules.txt b/Documentation/gitmodules.txt
index 4effd78..840ccfe 100644
--- a/Documentation/gitmodules.txt
+++ b/Documentation/gitmodules.txt
@@ -47,6 +47,11 @@ submodule.<name>.update::
This config option is overridden if 'git submodule update' is given
the '--merge', '--rebase' or '--checkout' options.
+submodule.<name>.branch::
+ A local branch name for the submodule (to avoid headless operation).
+ Set with the "--local-branch" option to "git submodule add", or
+ directly using "git config".
+
submodule.<name>.fetchRecurseSubmodules::
This option can be used to control recursive fetching of this
submodule. If this option is also present in the submodules entry in
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..6eed008 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
+USAGE="[--quiet] add [-b branch] [--local-branch[=<branch>]] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
@@ -20,6 +20,8 @@ require_work_tree
command=
branch=
+local_branch=
+local_branch_empty=
force=
reference=
cached=
@@ -257,6 +259,12 @@ cmd_add()
branch=$2
shift
;;
+ --local-branch)
+ local_branch_empty=true
+ ;;
+ --local-branch=*)
+ local_branch="${1#*=}"
+ ;;
-f | --force)
force=$1
;;
@@ -328,6 +336,11 @@ cmd_add()
git ls-files --error-unmatch "$sm_path" > /dev/null 2>&1 &&
die "$(eval_gettext "'\$sm_path' already exists in the index")"
+ if test -z "$local_branch" && test "$local_branch_empty" = "true"
+ then
+ local_branch="${branch:=HEAD}"
+ fi
+
if test -z "$force" && ! git add --dry-run --ignore-missing "$sm_path" > /dev/null 2>&1
then
eval_gettextln "The following path is ignored by one of your .gitignore files:
@@ -366,6 +379,10 @@ Use -f if you really want to add it." >&2
git config -f .gitmodules submodule."$sm_path".path "$sm_path" &&
git config -f .gitmodules submodule."$sm_path".url "$repo" &&
+ if test -n "$local_branch"
+ then
+ git config -f .gitmodules submodule."$sm_path".branch "$local_branch"
+ fi &&
git add --force .gitmodules ||
die "$(eval_gettext "Failed to register submodule '\$sm_path'")"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 5397037..fc08647 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -133,6 +133,7 @@ test_expect_success 'submodule add --branch' '
(
cd addtest &&
git submodule add -b initial "$submodurl" submod-branch &&
+ test -z "$(git config -f .gitmodules submodule.submod-branch.branch)" &&
git submodule init
) &&
@@ -211,6 +212,30 @@ test_expect_success 'submodule add with ./, /.. and // in path' '
test_cmp empty untracked
'
+test_expect_success 'submodule add --local-branch' '
+ (
+ cd addtest &&
+ git submodule add --local-branch "$submodurl" submod-follow-head &&
+ test "$(git config -f .gitmodules submodule.submod-follow-head.branch)" = "HEAD"
+ )
+'
+
+test_expect_success 'submodule add --local-branch --branch' '
+ (
+ cd addtest &&
+ git submodule add --local-branch -b initial "$submodurl" submod-auto-follow &&
+ test "$(git config -f .gitmodules submodule.submod-auto-follow.branch)" = "initial"
+ )
+'
+
+test_expect_success 'submodule add --local-branch=<name> --branch' '
+ (
+ cd addtest &&
+ git submodule add --local-branch=final -b initial "$submodurl" submod-follow &&
+ test "$(git config -f .gitmodules submodule.submod-follow.branch)" = "final"
+ )
+'
+
test_expect_success 'setup - add an example entry to .gitmodules' '
GIT_CONFIG=.gitmodules \
git config submodule.example.url git://example.com/init.git
--
1.8.0.3.g95edff1.dirty
^ permalink raw reply related
* Re: git bundle format
From: Stephen Bash @ 2012-11-26 20:56 UTC (permalink / raw)
To: Jason J CTR Pyeron (US); +Cc: git
In-Reply-To: <871B6C10EBEFE342A772D1159D13208537ABF5AB@umechphj.easf.csd.disa.mil>
----- Original Message -----
> From: "Jason J CTR Pyeron (US)" <jason.j.pyeron.ctr@mail.mil>
> Sent: Monday, November 26, 2012 2:24:54 PM
> Subject: git bundle format
>
> I am facing a situation where I would like to use git bundle but at
> the same time inspect the contents to prevent a spillage[1].
As someone who faced a similar situation in a previous life, I'll offer my $0.02, but I'm certainly not the technical expert here.
> Given we have a public repository which was cloned on to a secret
> development repository. Now the developers do some work which should
> not be sensitive in any way and commit and push it to the secret
> repository.
>
> Now they want to release it out to the public. The current process is
> to review the text files to ensure that there is no "secret" sauce
> in there and then approve its release. This current process ignores
> the change tracking and all non-content is lost.
>
> In this situation we should assume that the bundle does not have any
> content which is already in the public repository, that is it has
> the minimum data to make it pass a git bundle verify from the public
> repositories point of view. We would then take the bundle and pipe
> it though the "git-bundle2text" program which would result in a
> "human" inspectable format as opposed to the packed format[2]. The
> security reviewer would then see all the information being released
> and with the help of the public repository see how the data changes
> the repository.
>
> Am I barking up the right tree?
First, a shot out of left field: how about a patch based workflow? (similar to the mailing list, just replace email with sneakernet) Patches are plain text and simple to review (preferable to an "opaque" binary format?).
Second, thinking about your proposed bundle-based workflow I have two questions I'd have to answer to be comfortable with the solution:
1) Does the binary bundle contain any sensitive information?
2) Do the diffs applied to public repo contain any sensitive data?
Question 1 seems tricky to someone who knows *nothing* about the bundle format (e.g. me). Maybe some form of bundle2text can be vetted enough that everyone involved believes that there is no other information traveling with the bundle (if so, you're golden). Here I have to trust other experts. On the flip side, even if the bundle itself is polluted (or considered to be lacking proof to the contrary), if (2) is considered safe, the patching of the public repo could potentially be done on a sacrificial hard drive before pushing.
Question 2 is relatively straight forward and lead me to the patch idea. I would:
- Bundle the public repository
- Init a new repo in the secure space from the public bundle
- Fetch from the to-be-sanitized bundle into the new repo
- Examine commits (diffs) introduced by branches in the to-be-sanitized bundle
- Perhaps get a list of all the objects in the to-be-sanitized bundle and do a git-cat-file on each of them (if the bundle is assembled correctly it shouldn't have any unreachable objects...). This step may be extraneous after the previous.
HTH,
Stephen
^ permalink raw reply
* Re: git bundle format
From: Felipe Contreras @ 2012-11-26 20:56 UTC (permalink / raw)
To: Pyeron, Jason J CTR (US); +Cc: git@vger.kernel.org
In-Reply-To: <871B6C10EBEFE342A772D1159D13208537ABF676@umechphj.easf.csd.disa.mil>
On Mon, Nov 26, 2012 at 9:50 PM, Pyeron, Jason J CTR (US)
<jason.j.pyeron.ctr@mail.mil> wrote:
>> -----Original Message-----
>> From: Felipe Contreras
>> Sent: Monday, November 26, 2012 3:20 PM
>>
>> On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)
>> <jason.j.pyeron.ctr@mail.mil> wrote:
>> > I may need to be nudged in a better direction, but please try to
>> understand my intentions.
>> >
>> > I am facing a situation where I would like to use git bundle but at
>> the same time inspect the contents to prevent a spillage[1].
>> >
> <snip/>
>> >
>> > Am I barking up the right tree?
>>
>> Have you tried 'git fast-export'? The output is definitely not human
>> inspectable, but should be relatively easy to parse to generate such a
>> format. And instead of 'git bundle unbundle' you could use 'git
>> fast-import'. or simply do the conversion in your script.
>
> No. But I am going to read up on it today. It clearly says "You can use it as a human-readable bundle replacement"[4].
Ah, didn't notice that.
> My initial question is does it ever use deltas?
No.
> The repositories I just tested it on only seem to output full blobs (which is really nice from this use case point of view).
In my experience it's nice for most use-cases. Since git only deals
with full file contents, that makes sense.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: git-gui: textconv not used on unstaged files
From: Junio C Hamano @ 2012-11-26 20:54 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: git
In-Reply-To: <50B3D0D2.6060308@arcor.de>
Peter Oberndorfer <kumbayo84@arcor.de> writes:
> Does anybody have a idea which git command would output the diff
> of a untracked file against /dev/null?
The "--no-index" option is meant as a bolt-on to let you use various
features of "git diff" that is missing from other people's "diff" in
a context where git does not know anything about that file. It
should be usable even outside a git repository.
$ git diff --no-index /dev/null new-file.txt
I do not know offhand (and didn't bother to check) if textconv
applies, though. It does need access to a git repository as it
reads from the $GIT_DIR/config to learn what to do.
^ permalink raw reply
* RE: git bundle format
From: Pyeron, Jason J CTR (US) @ 2012-11-26 20:53 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <7vvccsqeva.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]
> -----Original Message-----
> From: Junio C Hamano
> Sent: Monday, November 26, 2012 3:38 PM
>
> "Pyeron, Jason J CTR (US)" writes:
>
> > In this situation we should assume that the bundle does not have
> > any content which is already in the public repository, that is it
> > has the minimum data to make it pass a git bundle verify from the
> > public repositories point of view. We would then take the bundle
> > and pipe it though the "git-bundle2text" program which would
> > result in a "human" inspectable format as opposed to the packed
> > format[2]. The security reviewer would then see all the
> > information being released and with the
*** Assumed that the inspector had a copy of the original public repo
> > help of the public
> > repository see how the data changes the repository.
>
> The bundle file is a thinly wrapped packfile, with extra information
> that tells what objects in the bundle are the tips of histories and
> what objects the repository the bundle gets unbundled has to have.
> So your "git-bundle2text" would likely to involve fetching from the
> bundle and inspecting the resulting history and the working tree
> files.
Yea, I knew the inspection tool was going to get messy.
-Jason
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* RE: git bundle format
From: Pyeron, Jason J CTR (US) @ 2012-11-26 20:50 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <CAMP44s03QiO15jODBD4JO_JF8tCOT9OJG1tb4+r+L4dgPUOLFg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
> -----Original Message-----
> From: Felipe Contreras
> Sent: Monday, November 26, 2012 3:20 PM
>
> On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)
> <jason.j.pyeron.ctr@mail.mil> wrote:
> > I may need to be nudged in a better direction, but please try to
> understand my intentions.
> >
> > I am facing a situation where I would like to use git bundle but at
> the same time inspect the contents to prevent a spillage[1].
> >
<snip/>
> >
> > Am I barking up the right tree?
>
> Have you tried 'git fast-export'? The output is definitely not human
> inspectable, but should be relatively easy to parse to generate such a
> format. And instead of 'git bundle unbundle' you could use 'git
> fast-import'. or simply do the conversion in your script.
No. But I am going to read up on it today. It clearly says "You can use it as a human-readable bundle replacement"[4]. My initial question is does it ever use deltas? The repositories I just tested it on only seem to output full blobs (which is really nice from this use case point of view).
-Jason
4: http://www.kernel.org/pub/software/scm/git/docs/git-fast-export.html
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Junio C Hamano @ 2012-11-26 20:44 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Felipe Contreras, git
In-Reply-To: <CALWbr2x4aia4DcdnmfEEBsZwCYasTEp2Jc0jwJgvsUqWSDaWTQ@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
>> I am not sure I follow the above, but anyway, I think the patch does
>> is safe because (1) future "fast-export" will not refer to these
>> pruned objects in its output (we have decided that these pruned
>> objects are not used anywhere in the history so nobody will refer to
>> them) and (2) we still need to increment the id number so that later
>> objects in the marks file get assigned the same id number as they
>> were assigned originally (otherwise we will not name these objects
>> consistently when we later talk about them).
>
> I fully agree on (1), not so much on (2) though.
> ...
> Both "commit mark :2" and "commit mark :3" end up being marked :2.
> Any tool like git-remote-hg that is using a mapping from mark <-> hg changeset
> could then fail.
Yeah, I think I agree that you would need to make sure that the
other side does not use the revision marked with :2, once you retire
the object you originally marked with :2 by pruning. Shouldn't the
second export show :1 and :3 but not :2? It feels like a bug in the
exporter to me that the mark number is reused in such a case.
^ permalink raw reply
* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Felipe Contreras @ 2012-11-26 20:39 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Junio C Hamano, git
In-Reply-To: <CALWbr2x4aia4DcdnmfEEBsZwCYasTEp2Jc0jwJgvsUqWSDaWTQ@mail.gmail.com>
On Mon, Nov 26, 2012 at 9:04 PM, Antoine Pelisse <apelisse@gmail.com> wrote:
>> I am not sure I follow the above, but anyway, I think the patch does
>> is safe because (1) future "fast-export" will not refer to these
>> pruned objects in its output (we have decided that these pruned
>> objects are not used anywhere in the history so nobody will refer to
>> them) and (2) we still need to increment the id number so that later
>> objects in the marks file get assigned the same id number as they
>> were assigned originally (otherwise we will not name these objects
>> consistently when we later talk about them).
>
> I fully agree on (1), not so much on (2) though.
>
> I have the following behavior using my patch and running that script
> that doesn't look correct.
>
> echo "Working scenario"
> git init test &&
> (cd test &&
> git commit --allow-empty -m "Commit mark :1" &&
> git commit --allow-empty -m "Commit mark :2" &&
> git fast-export --export-marks=MARKS master > /dev/null &&
> cat MARKS &&
> git reset HEAD~1 &&
> sleep 1 &&
> git reflog expire --all --expire=now &&
> git prune --expire=now &&
> git commit --allow-empty -m "Commit mark :3" &&
> git fast-export --import-marks=MARKS \
> --export-marks=MARKS master > /dev/null &&
> cat MARKS) &&
> rm -rf test
>
> echo "Non-working scenario"
> git init test &&
> (cd test &&
> git commit --allow-empty -m "Commit mark :1" &&
> git commit --allow-empty -m "Commit mark :2" &&
> git fast-export --export-marks=MARKS master > /dev/null &&
> cat MARKS &&
> git reset HEAD~1 &&
> sleep 1 &&
> git reflog expire --all --expire=now &&
> git prune --expire=now &&
> git fast-export --import-marks=MARKS \
> --export-marks=MARKS master > /dev/null &&
> git commit --allow-empty -m "Commit mark :3" &&
> git fast-export --import-marks=MARKS \
> --export-marks=MARKS master > /dev/null &&
> cat MARKS) &&
> rm -rf test
>
> outputs something like this:
> Working scenario
> Initialized empty Git repository in /home/antoine/test/.git/
> [master (root-commit) 6cf350d] Commit mark :1
> [master 8f97f85] Commit mark :2
> :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966
> :2 8f97f85e1e7badf6a3daf411cf8d1133b00d522e
> [master 21cadfd] Commit mark :3
> warning: Could not read blob 8f97f85e1e7badf6a3daf411cf8d1133b00d522e
> :1 6cf350d7ecb3dc6573b00f839a6a51625ed28966
> :3 21cadfd87d90c05ce8770c968e5ed3d072ead4ae
> Non-working scenario
> Initialized empty Git repository in /home/antoine/test/.git/
> [master (root-commit) 5b5f7ec] Commit mark :1
> [master b224390] Commit mark :2
> :2 b224390daee199644495c15503882eb84df07df5
> :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678
> warning: Could not read blob b224390daee199644495c15503882eb84df07df5
> [master 181a774] Commit mark :3
> :1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678
> :2 181a7744c6d3428edb01a1adc9df247e9620be5f
>
> Both "commit mark :2" and "commit mark :3" end up being marked :2.
> Any tool like git-remote-hg that is using a mapping from mark <-> hg changeset
> could then fail.
I don't understand. "commit mark :2" 'git fast-export' would never
point to that object again, the new commit would override that mark:
commit refs/heads/master
mark :2
...
commit mark :3
Then 'git remote-hg' should override that mark as well.
But it doesn't matter, because that would be the case only for the
last object, as soon as you find another valid object, that object's
mark will be considered the last one.
And what Junio said is consistent with what you want: last_idnum
should be updated even if the object is not valid.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: git bundle format
From: Junio C Hamano @ 2012-11-26 20:38 UTC (permalink / raw)
To: Pyeron, Jason J CTR (US); +Cc: git@vger.kernel.org
In-Reply-To: <871B6C10EBEFE342A772D1159D13208537ABF5AB@umechphj.easf.csd.disa.mil>
"Pyeron, Jason J CTR (US)" <jason.j.pyeron.ctr@mail.mil> writes:
> In this situation we should assume that the bundle does not have
> any content which is already in the public repository, that is it
> has the minimum data to make it pass a git bundle verify from the
> public repositories point of view. We would then take the bundle
> and pipe it though the "git-bundle2text" program which would
> result in a "human" inspectable format as opposed to the packed
> format[2]. The security reviewer would then see all the
> information being released and with the help of the public
> repository see how the data changes the repository.
The bundle file is a thinly wrapped packfile, with extra information
that tells what objects in the bundle are the tips of histories and
what objects the repository the bundle gets unbundled has to have.
So your "git-bundle2text" would likely to involve fetching from the
bundle and inspecting the resulting history and the working tree
files.
^ permalink raw reply
* Re: Ignoring boring lines(that do not contain information) in git diff
From: Peter Oberndorfer @ 2012-11-26 20:35 UTC (permalink / raw)
To: git
In-Reply-To: <507302DC.4030207@arcor.de>
On 2012-10-08 18:44, Peter Oberndorfer wrote:
> Hi,
>
> is there a way to tell git diff about lines that are uninteresting?
> I mean lines which do not contain a lot of information and
> appear several times in pre and post image.
>
> For example whitespace or language dependent stuff like.
> {
> }
> END_IF;
> END_FOR;
> end sub
>
> I have seen diffs that containing 2 interesting hunks splitted by such boring lines.
> (I have attached a anonymized version of a real world example where this happens)
>
> I think the diff would be clearer when this boring line was added to the surrounding hunks.
> I already tried patience diff but in my test case it changed nothing.
> I am using git 1.7.10.
>
Hi,
does anybody have a idea if this is possible?
Or some comments if they would find such a feature useful?
Greetings Peter
example_diff_boring_split.diff
diff --git a/Source/Frobble/Blabber.txt b/Source/Frobble/Blabber.txt
index 87ccddb..627bc3e 100644
--- a/Source/Frobble/Blabber.txt
+++ b/Source/Frobble/Blabber.txt
@@ -138,73 +138,74 @@ END_VAR
- //frobble immediately if immediately flag is set
- IF bImmediately AND NOT Array[i].bDisabled THEN
- aFrobble(i, Entry);
+ IF Entry.bBlah THEN
+ Alarm.Alarm := SomeAlarm;
+ ELSE
+ Alarm := Entry;
END_IF;
- // signal if frobble count has changed
- iChanged := iChanged + 1;
- EXIT;
+ IF Array[i].Alarm = Alarm THEN
+ //do not brabble if alarm is gobbled
+ EXIT;
+ END_IF;
END_IF;
- END_FOR;
-ELSE
- aExample(Name := 'aaa',
- ID1 := 1);
-END_IF;
+ ELSE
+ //entry not found, adding
^ permalink raw reply related
* Re: git-gui: textconv not used on unstaged files
From: Peter Oberndorfer @ 2012-11-26 20:28 UTC (permalink / raw)
To: git
In-Reply-To: <5088347F.50503@arcor.de>
On 2012-10-24 20:33, Peter Oberndorfer wrote:
> Hi,
>
> i am using a textconv filter to display .doc files as plain text.
> It seems git gui does not use this textconv filter for displaying new unstaged files
> (other files? = _O)
> It seems diff.tcl start_show_diff calls show_other_diff because of this.
> This manually loads the file and does not care about textconv filters.
>
> Is this manual loading really necessary or can't we just ask git?
> If it is can it be modified to use the textconv filter?
>
Does anybody have a idea which git command
would output the diff of a untracked file against /dev/null?
So I can show the textconved version of the file in git gui.
(and not reinvent the code to apply textconv already in git)
Thanks,
Greetings Peter
>
> .gitattributes:
> *.doc diff=astextplain
>
> gitconfig:
> [diff "astextplain"]
> textconv = astextplain
^ permalink raw reply
* difftool -d symlinks, under what conditions
From: Matt McClure @ 2012-11-26 20:23 UTC (permalink / raw)
To: git
I'm finding the behavior of `git difftool -d` surprising. It seems that it
only uses symlinks to the working copy for files that are modified in the
working copy since the most recent commit. I would have expected it to use
symlinks for all files whose version under comparison is the working copy
version, regardless of whether the working copy differs from the HEAD.
I'm using
$ git --version
git version 1.8.0
on a Mac from Homebrew.
--
Matt McClure
http://www.matthewlmcclure.com
http://www.mapmyfitness.com/profile/matthewlmcclure
^ permalink raw reply
* Re: git bundle format
From: Felipe Contreras @ 2012-11-26 20:20 UTC (permalink / raw)
To: Pyeron, Jason J CTR (US); +Cc: git@vger.kernel.org
In-Reply-To: <871B6C10EBEFE342A772D1159D13208537ABF5AB@umechphj.easf.csd.disa.mil>
On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)
<jason.j.pyeron.ctr@mail.mil> wrote:
> I may need to be nudged in a better direction, but please try to understand my intentions.
>
> I am facing a situation where I would like to use git bundle but at the same time inspect the contents to prevent a spillage[1].
>
> Given we have a public repository which was cloned on to a secret development repository. Now the developers do some work which should not be sensitive in any way and commit and push it to the secret repository.
>
> Now they want to release it out to the public. The current process is to review the text files to ensure that there is no "secret" sauce in there and then approve its release. This current process ignores the change tracking and all non-content is lost.
>
>
> In this situation we should assume that the bundle does not have any content which is already in the public repository, that is it has the minimum data to make it pass a git bundle verify from the public repositories point of view. We would then take the bundle and pipe it though the "git-bundle2text" program which would result in a "human" inspectable format as opposed to the packed format[2]. The security reviewer would then see all the information being released and with the help of the public repository see how the data changes the repository.
>
> Am I barking up the right tree?
Have you tried 'git fast-export'? The output is definitely not human
inspectable, but should be relatively easy to parse to generate such a
format. And instead of 'git bundle unbundle' you could use 'git
fast-import'. or simply do the conversion in your script.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Felipe Contreras @ 2012-11-26 20:07 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121115212818.GA21558@thyrsus.com>
On Thu, Nov 15, 2012 at 10:28 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Some days ago I reported that I was attempting to write a tool that could
> (a) take a git repo and unpack it into a tarball sequence plus a metadata log,
> (b) reverse that operation, packing a tarball and log sequence into a repo.
>
> Thanks in part to advice by Andreas Schwab and in part to looking at the
> text of the p4 import script, this effort has succeeded. A proof of
> concept is enclosed. It isn't documented yet, and has not been tested
> on a repository with branches or merges in the history, but I am confident
> that the distance from here to a finished and tested tool is short.
>
> The immediate intended use is for importing older projects that are
> available only as sequences of release tarballs, but there are other
> sorts of repository surgery that would become easier using it.
>
> I'm still looking for a better name for it and would welcome suggestions.
>
> Before I do much further work, I need to determine how this will be shipped.
> I see two possibilities: either I ship it as a small standalone project,
> or it becomes a git subcommand shipped with the git suite. How I document
> it and set up its tests would differ between these two cases.
Please look at Documentation/SubmittingPatches, you should send
patches in inline format, preferably with 'git format-patch -M', and
preferably with 'git send-email' (in which case you don't need
format-patch), otherwise people will have trouble reviewing, or miss
it completely (as it was the case for me).
I have many comments, but I'll wait until you send the patch inlined,
I'll just address these:
1) I tried it, and it doesn't seem to import (pack?) are repository
with sub-directories in it
2) Using 'git fast-import' is probably simpler, and more efficient
Here is a proof of concept I wrote in ruby that is half the size, and
seems to implement the same functionality. The format is exactly the
same, but I think it should be modified to be more efficient.
Cheers.
>From eb3c34699d7f5d4eec4f088344659b8d9b6a07ea Mon Sep 17 00:00:00 2001
From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Mon, 26 Nov 2012 20:48:38 +0100
Subject: [PATCH] Add new git-weave tool
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
contrib/weave/git-weave | 166 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 166 insertions(+)
create mode 100755 contrib/weave/git-weave
diff --git a/contrib/weave/git-weave b/contrib/weave/git-weave
new file mode 100755
index 0000000..3106121
--- /dev/null
+++ b/contrib/weave/git-weave
@@ -0,0 +1,166 @@
+#!/usr/bin/env ruby
+
+require 'optparse'
+require 'find'
+require 'fileutils'
+
+def export(indir = '.', out = STDOUT)
+ open(File.join(indir, 'log')).each("\n.\n") do |data|
+
+ @msg = nil
+ @parents = []
+
+ data.chomp(".\n").each_line do |l|
+ if not @msg
+ case l
+ when /^commit (.+)$/
+ @id = $1
+ when /^author (.+)$/
+ @author = $1
+ when /^committer (.+)$/
+ @committer = $1
+ when /^parent (.+)$/
+ @parents << $1
+ when /^$/
+ @msg = ""
+ end
+ else
+ @msg << l
+ end
+ end
+
+ out.puts "commit refs/heads/master"
+ out.puts "mark :#{@id}"
+ out.puts "author #{@author}"
+ out.puts "committer #{@committer}"
+ out.puts "data #{@msg.bytesize}"
+ out.puts @msg
+
+ @parents.each_with_index do |p, i|
+ if i == 0
+ out.puts "from :%u" % p
+ else
+ out.puts "merge :%u" % p
+ end
+ end
+
+ # files
+ out.puts 'deleteall'
+ FileUtils.cd(File.join(indir, @id)) do
+ Find.find('.') do |e|
+ next unless File.file?(e)
+ content = File.read(e)
+ filename = e.split(File::SEPARATOR).slice(1..-1).join(File::SEPARATOR)
+ mode = File.executable?(e) ? '100755' : '100644'
+ if File.symlink?(e)
+ mode = '120000'
+ content = File.readlink(e)
+ end
+ out.puts 'M %s inline %s' % [mode, filename]
+ out.puts "data #{content.bytesize}"
+ out.puts content
+ end
+ end
+
+ end
+end
+
+def import(outdir, out)
+ format = 'format:commit %H%nauthor %an <%ae> %ad%ncommitter %cn
<%ce> %cd%nparents %P%n%n%B'
+ cmd = ['git', 'log', '-z', '-s', '--date=raw', '--format=%s' %
format, '--all', '--reverse']
+ commits = {}
+
+ IO.popen(cmd).each_with_index("\0") do |data, i|
+ @msg = nil
+ @parents = []
+ data.chomp("\0").each_line do |l|
+ if not @msg
+ case l
+ when /^commit (.+)$/
+ @id = $1
+ when /^author (.+)$/
+ @author = $1
+ when /^committer (.+)$/
+ @committer = $1
+ when /^parents (.+)$/
+ @parents = $1.split(" ")
+ when /^$/
+ @msg = ""
+ end
+ else
+ @msg << l
+ end
+ end
+
+ num = i + 1
+ commits[@id] = num
+
+ out.puts "commit #{num}"
+ @parents.each do |p|
+ out.puts "parent #{commits[p]}"
+ end
+ out.puts "author #{@author}"
+ out.puts "committer #{@committer}"
+ out.puts
+ out.puts @msg.gsub(/\n\n+/, "\n") # why?
+ out.puts "."
+
+ wd = File.join(outdir, num.to_s)
+ FileUtils.mkdir_p(wd)
+ system('git', '--work-tree', wd, 'checkout', '-f', '-q', @id)
+ end
+end
+
+def git_pack(indir, outdir)
+ indir = File.absolute_path(indir)
+ system('git', 'init', outdir)
+ FileUtils.cd(outdir) do
+ IO.popen(['git', 'fast-import'], 'w') do |io|
+ export(indir, io)
+ end
+ system('git', 'reset', '--hard')
+ end
+end
+
+def git_unpack(indir, outdir)
+ begin
+ FileUtils.mkdir_p(outdir)
+ log = File.open(File.join(outdir, 'log'), 'w')
+ ENV['GIT_DIR'] = File.join(indir, '.git')
+ import(outdir, log)
+ ensure
+ system('git', 'symbolic-ref', 'HEAD', 'refs/heads/master')
+ ENV.delete('GIT_DIR')
+ log.close if log
+ end
+end
+
+$indir = '.'
+
+begin
+ OptionParser.new do |opts|
+ opts.on('-x') do
+ $mode = 'unpack'
+ end
+ opts.on('-c') do
+ $mode = 'pack'
+ end
+ opts.on('-o', '--outdir DIR') do |v|
+ $outdir = v
+ end
+ opts.on('-i', '--indir DIR') do |v|
+ $indir = v
+ end
+ end.parse!
+rescue OptionParser::InvalidOption
+end
+
+$mode = File.exists?(File.join($indir, '.git')) ? 'unpack' : 'pack'
unless $mode
+$outdir = File.join($indir, $mode == 'pack' ? 'packed' : 'unpacked2')
unless $outdir
+
+case $mode
+when 'pack'
+ git_pack($indir, $outdir)
+when 'unpack'
+ git_unpack($indir, $outdir)
+end
--
1.8.0
--
Felipe Contreras
^ permalink raw reply related
* Re: [PATCH] fast-export: Allow pruned-references in mark file
From: Antoine Pelisse @ 2012-11-26 20:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Felipe Contreras, git
In-Reply-To: <7vhaoctg6i.fsf@alter.siamese.dyndns.org>
> I am not sure I follow the above, but anyway, I think the patch does
> is safe because (1) future "fast-export" will not refer to these
> pruned objects in its output (we have decided that these pruned
> objects are not used anywhere in the history so nobody will refer to
> them) and (2) we still need to increment the id number so that later
> objects in the marks file get assigned the same id number as they
> were assigned originally (otherwise we will not name these objects
> consistently when we later talk about them).
I fully agree on (1), not so much on (2) though.
I have the following behavior using my patch and running that script
that doesn't look correct.
echo "Working scenario"
git init test &&
(cd test &&
git commit --allow-empty -m "Commit mark :1" &&
git commit --allow-empty -m "Commit mark :2" &&
git fast-export --export-marks=MARKS master > /dev/null &&
cat MARKS &&
git reset HEAD~1 &&
sleep 1 &&
git reflog expire --all --expire=now &&
git prune --expire=now &&
git commit --allow-empty -m "Commit mark :3" &&
git fast-export --import-marks=MARKS \
--export-marks=MARKS master > /dev/null &&
cat MARKS) &&
rm -rf test
echo "Non-working scenario"
git init test &&
(cd test &&
git commit --allow-empty -m "Commit mark :1" &&
git commit --allow-empty -m "Commit mark :2" &&
git fast-export --export-marks=MARKS master > /dev/null &&
cat MARKS &&
git reset HEAD~1 &&
sleep 1 &&
git reflog expire --all --expire=now &&
git prune --expire=now &&
git fast-export --import-marks=MARKS \
--export-marks=MARKS master > /dev/null &&
git commit --allow-empty -m "Commit mark :3" &&
git fast-export --import-marks=MARKS \
--export-marks=MARKS master > /dev/null &&
cat MARKS) &&
rm -rf test
outputs something like this:
Working scenario
Initialized empty Git repository in /home/antoine/test/.git/
[master (root-commit) 6cf350d] Commit mark :1
[master 8f97f85] Commit mark :2
:1 6cf350d7ecb3dc6573b00f839a6a51625ed28966
:2 8f97f85e1e7badf6a3daf411cf8d1133b00d522e
[master 21cadfd] Commit mark :3
warning: Could not read blob 8f97f85e1e7badf6a3daf411cf8d1133b00d522e
:1 6cf350d7ecb3dc6573b00f839a6a51625ed28966
:3 21cadfd87d90c05ce8770c968e5ed3d072ead4ae
Non-working scenario
Initialized empty Git repository in /home/antoine/test/.git/
[master (root-commit) 5b5f7ec] Commit mark :1
[master b224390] Commit mark :2
:2 b224390daee199644495c15503882eb84df07df5
:1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678
warning: Could not read blob b224390daee199644495c15503882eb84df07df5
[master 181a774] Commit mark :3
:1 5b5f7ec77768393aab2a0c2c11b4b8f7773f8678
:2 181a7744c6d3428edb01a1adc9df247e9620be5f
Both "commit mark :2" and "commit mark :3" end up being marked :2.
Any tool like git-remote-hg that is using a mapping from mark <-> hg changeset
could then fail.
^ permalink raw reply
* Re: [PATCH] Third try at documenting command integration requirements.
From: Junio C Hamano @ 2012-11-26 20:01 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121126053557.E56434065F@snark.thyrsus.com>
esr@thyrsus.com (Eric S. Raymond) writes:
> This document contains no new policies or proposals; it attempts
> to document established practices and interface requirements.
>
> Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
I'll reword the title (readers of "git log" output 6 months down the
road will not care if this is the third try or the first one) and
tweak things here and there before queuing.
> diff --git a/Documentation/technical/api-command.txt b/Documentation/technical/api-command.txt
> new file mode 100644
> index 0000000..c1c1afb
> --- /dev/null
> +++ b/Documentation/technical/api-command.txt
> @@ -0,0 +1,91 @@
> += Integrating new subcommands =
> +
> +This is how-to documentation for people who want to add extension
> +commands to git. It should be read alongside api-builtin.txt.
> +
> +== Runtime environment ==
> +
> +git subcommands are standalone executables that live in the git
> +execution directory, normally /usr/lib/git-core. The git executable itself
> +is a thin wrapper that sets GIT_DIR and passes command-line arguments
> +to the subcommand.
$ echo >$HOME/bin/git-showenv '#!/bin/sh
exec env'
$ chmod +x $HOME/bin/git-showenv
$ git showenv | grep GIT_
gives me emptyness. I rewrote the above to:
git subcommands are standalone executables that live in the git exec
path, normally /usr/lib/git-core. The git executable itself is a
thin wrapper that knows where the subcommands live, and runs them by
passing command-line arguments to them.
FYI, a builtin command _can_ ask the git wrapper to set up the
execution environment by setting RUN_SETUP bit in its cmd_struct
entry, but it is not done by default.
> +== Implementation languages ==
> +
> +Most subcommands are written in C or shell. A few are written in
> +Perl. A tiny minority are written in Python.
> +
> +While we strongly encourage coding in portable C for portability, these
> +specific scripting languages are also acceptable. We won't accept more
> +without a very strong technical case, as we don't want to broaden the
> +git suite's required dependencies.
> +
> +Python is fine for import utilities, surgical tools, remote helpers
> +and other code at the edges of the git suite - but it should not yet
> +be used for core functions. This may change in the future; the problem
> +is that we need better Python integration in the git Windows installer
> +before we can be confident people in that environment won't
> +experience an unacceptably large loss of capability.
As Felipe and others said in the discussion, Python is not *that*
special over other languages (and I think we have a Go in contrib/).
I rewrote the above to:
Most subcommands are written in C or shell. A few are written in
Perl.
While we strongly encourage coding in portable C for portability,
these specific scripting languages are also acceptable. We won't
accept more without a very strong technical case, as we don't want
to broaden the git suite's required dependencies. Import utilities,
surgical tools, remote helpers and other code at the edges of the
git suite are more lenient and we allow Python (and even Tcl/tk),
but they should not be used for core functions.
This may change in the future. Especially Python is not allowed in
core because we need better Python integration in the git Windows
installer before we can be confident people in that environment
won't experience an unacceptably large loss of capability.
> +C commands are normally written as single modules, named after the
> +command, that link a collection of functions called libgit. Thus,
> +your command 'git-foo' would normally be implemented as a single
> +"git-foo.c"; this organization makes it easy for people reading the
"git-foo.c" (or "builtin/foo.c" if it is to be linked to the main
binary);
> +4. If your command has any dependency on a a particular version of
> +your language, document it in the INSTALL file.
s/a a/a/;
> +6. When your patch is merged, remind the maintainer to add something
> +about it in the RelNotes file.
6. Give the maintainer a one paragraph to include in the RelNotes
file to describe the new feature; a good place to do so is in the
cover letter [PATCH 0/n].
Thanks.
^ permalink raw reply
* Re: [PATCH v3] send-email: avoid questions when user has an ident
From: Junio C Hamano @ 2012-11-26 19:35 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Jeff King, Thomas Rast, Christian Couder, Stephen Boyd,
Ævar Arnfjörð Bjarmason
In-Reply-To: <1353755779-32548-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> 3) Full name + fqdm
>
> Who should the emails appear to be from?
> [Felipe Contreras <felipec@nysa.felipec.org>]
> ...
> This is bad, because we will try with an address such as
> 'felipec@nysa.felipec.org', which is most likely not what the user
> wants, but the user will get warned by default (confirm=auto), and
> if not, most likely the sending won't work, which the user would
> readily note and fix.
OK, sounds sensible.
> Changes since v2:
>
> * Merge the relevant tests by Jeff King (the rest of the tests might be
> useful, but they belong in a separate patch series)
Thanks. Queued.
^ permalink raw reply
* RE: git bundle format
From: Pyeron, Jason J CTR (US) @ 2012-11-26 19:31 UTC (permalink / raw)
To: Pyeron, Jason J CTR (US), git@vger.kernel.org
In-Reply-To: <871B6C10EBEFE342A772D1159D13208537ABF5AB@umechphj.easf.csd.disa.mil>
[-- Attachment #1: Type: text/plain, Size: 1715 bytes --]
Left off a citation to an old thread.
> -----Original Message-----
> From: Pyeron, Jason J CTR (US)
> Sent: Monday, November 26, 2012 2:25 PM
>
> I may need to be nudged in a better direction, but please try to
> understand my intentions.
>
> I am facing a situation where I would like to use git bundle but at the
> same time inspect the contents to prevent a spillage[1].
>
> Given we have a public repository which was cloned on to a secret
> development repository. Now the developers do some work which should
> not be sensitive in any way and commit and push it to the secret
> repository.
>
> Now they want to release it out to the public. The current process is
> to review the text files to ensure that there is no "secret" sauce in
> there and then approve its release. This current process ignores the
> change tracking and all non-content is lost.
>
>
> In this situation we should assume that the bundle does not have any
> content which is already in the public repository, that is it has the
> minimum data to make it pass a git bundle verify from the public
> repositories point of view. We would then take the bundle and pipe it
> though the "git-bundle2text" program which would result in a "human"
> inspectable format
[3]
> as opposed to the packed format[2]. The security
> reviewer would then see all the information being released and with the
> help of the public repository see how the data changes the repository.
>
> Am I barking up the right tree?
>
>
> 1: http://en.wikipedia.org/wiki/Spillage_of_Classified_Information
> 2: http://git-scm.com/book/ch9-4.html
3: http://git.661346.n2.nabble.com/How-to-extract-files-out-of-a-quot-git-bundle-quot-no-matter-what-td1679188.html
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* git bundle format
From: Pyeron, Jason J CTR (US) @ 2012-11-26 19:24 UTC (permalink / raw)
To: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]
I may need to be nudged in a better direction, but please try to understand my intentions.
I am facing a situation where I would like to use git bundle but at the same time inspect the contents to prevent a spillage[1].
Given we have a public repository which was cloned on to a secret development repository. Now the developers do some work which should not be sensitive in any way and commit and push it to the secret repository.
Now they want to release it out to the public. The current process is to review the text files to ensure that there is no "secret" sauce in there and then approve its release. This current process ignores the change tracking and all non-content is lost.
In this situation we should assume that the bundle does not have any content which is already in the public repository, that is it has the minimum data to make it pass a git bundle verify from the public repositories point of view. We would then take the bundle and pipe it though the "git-bundle2text" program which would result in a "human" inspectable format as opposed to the packed format[2]. The security reviewer would then see all the information being released and with the help of the public repository see how the data changes the repository.
Am I barking up the right tree?
1: http://en.wikipedia.org/wiki/Spillage_of_Classified_Information
2: http://git-scm.com/book/ch9-4.html
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* [PATCH] Fix typo in remote set-head usage
From: Antoine Pelisse @ 2012-11-26 19:21 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Jiang Xin, Antoine Pelisse
In-Reply-To: <7vwqx8rzzf.fsf@alter.siamese.dyndns.org>
parenthesis are not matching in `builtin_remote_sethead_usage`
as a square bracket is closing something never opened.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
builtin/remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index a5a4b23..937484d 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -39,7 +39,7 @@ static const char * const builtin_remote_rm_usage[] = {
};
static const char * const builtin_remote_sethead_usage[] = {
- N_("git remote set-head <name> (-a | -d | <branch>])"),
+ N_("git remote set-head <name> (-a | -d | <branch>)"),
NULL
};
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Felipe Contreras @ 2012-11-26 19:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, Jonathan Nieder, git, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <7vd2z0tfhz.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 6:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> If you changed your stance on the patch Sverre and I sent to fix this, we
>> could get a non-partial fix for this.
>
> This is long time ago so I may be misremembering the details, but I
> thought the original patch was (ab)using object flags to mark "this
> was explicitly asked for, even though some other range operation may
> have marked it uninteresting". Because it predated the introduction
> of the rev_cmdline_info mechanism to record what was mentioned on
> the command line separately from what objects are uninteresting
> (i.e. object flags), it may have been one convenient way to record
> this information, but it still looked unnecessarily ugly hack to me,
> in that it allocated scarce object flag bits to represent a narrow
> special case (iirc, only a freestanding "A" on the command line but
> not "A" spelled in "B..A", or something), making it more expensive
> to record other kinds of command line information in a way
> consistent with the approach chosen (we do not want to waste object
> flag bits in order to record "this was right hand side tip of the
> symmetric difference range" and such).
>
> If you are calling "do not waste object flags to represent one
> special case among endless number of possibilities, as it will make
> it impossible to extend it" my stance, that hasn't changed.
The problem with those patches is that they were doing many things at
the same time.
You are correct that one of the problems being solved was the fact
that we wanted to differentiate B from A in B..A independently of the
object, because it might have been referenced by ^C. My latest patch
series deals with that by using rev cmdline_info.
But there's another problem that series tried to fix: weather or not A
was exported by fast-export, which is not strictly the same as SHOWN.
This becomes a non-issue if my patch series is applied because it
properly identifies when an object has been marked or not. But it's
not when marks are not used.
For example:
% git branch A v1
% git branch B v0
% git branch C v0
% git branch D v1
% git fast-export B..A ^C D
A would be updated through a 'commit refs/heads/A' command, D would be
updated through 'reset refs/heads/D'.
But what if C points to v1? The code will assume A will be exported,
and it will be skipped, and there will be only one reset: 'reset
refs/heads/D'. Either way it doesn't matter, because the reset would
be to mark :0, so even if there was a 'reset refs/heads/A' (because A
was never exported), a mark :0 would be useless.
When marks are used my patch fixes the problem because it doesn't care
if A was exporeted or not; by knowing it was marked, it knows it was
never intended to be exported, so we get resets for both A and D, with
real marks.
> We added rev_cmdline_info since then so that we can tell what refs
> were given from the command line in what way, and I thought that we
> applied a patch from Sverre that uses it instead of the object
> flags. Am I misremembering things?
No, the patch from Sverre was never merged.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 5/7] push: require force for refs under refs/tags/
From: Junio C Hamano @ 2012-11-26 18:57 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <1353644515-17349-6-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> diff --git a/remote.c b/remote.c
> index 4a6f822..012b52f 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
> *
> * (1) if the old thing does not exist, it is OK.
> *
> - * (2) if you do not have the old thing, you are not allowed
> + * (2) if the destination is under refs/tags/ you are
> + * not allowed to overwrite it; tags are expected
> + * to be static once created
> + *
> + * (3) if you do not have the old thing, you are not allowed
> * to overwrite it; you would not know what you are losing
> * otherwise.
> *
> - * (3) if both new and old are commit-ish, and new is a
> + * (4) if both new and old are commit-ish, and new is a
> * descendant of old, it is OK.
> *
> - * (4) regardless of all of the above, removing :B is
> + * (5) regardless of all of the above, removing :B is
> * always allowed.
> */
We may want to reword (0) to make it clear that --force
(and +A:B) can be used to defeat all the other rules.
The updated logic in the patch looks sensible. Thanks.
> ...
> +test_expect_success 'push requires --force to update lightweight tag' '
> + mk_test heads/master &&
> + mk_child child1 &&
> + mk_child child2 &&
> + (
> + cd child1 &&
> + git tag Tag &&
> + git push ../child2 Tag &&
> + git push ../child2 Tag &&
> + >file1 &&
> + git add file1 &&
> + git commit -m "file1" &&
> + git tag -f Tag &&
> + test_must_fail git push ../child2 Tag &&
> + git push --force ../child2 Tag &&
> + git tag -f Tag &&
> + test_must_fail git push ../child2 Tag HEAD~ &&
> + git push --force ../child2 Tag
> + )
> +'
> +
^ permalink raw reply
* Re: [PATCH 7/7] push: clarify rejection of update to non-commit-ish
From: Junio C Hamano @ 2012-11-26 18:53 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <1353644515-17349-8-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> Pushes must already (by default) update to a commit-ish due the fast-
> forward check in set_ref_status_for_push(). But rejecting for not being
> a fast-forward suggests the situation can be resolved with a merge.
> Flag these updates (i.e., to a blob or a tree) as not forwardable so the
> user is presented with more appropriate advice.
>
> Signed-off-by: Chris Rorvick <chris@rorvick.com>
> ---
> remote.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/remote.c b/remote.c
> index f5bc4e7..ee0c1e5 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref* ref)
> if (!o || o->type != OBJ_COMMIT)
> return 0;
>
> + /* new object must be commit-ish */
> + o = deref_tag(parse_object(ref->new_sha1), NULL, 0);
> + if (!o || o->type != OBJ_COMMIT)
> + return 0;
> +
I think the original code used ref_newer() which took commit-ish on
both sides.
With this code, the old must be a commit but new can be a tag that
points at a commit? Why?
^ permalink raw reply
* Re: [PATCH 1/7] push: return reject reasons via a mask
From: Junio C Hamano @ 2012-11-26 18:43 UTC (permalink / raw)
To: Chris Rorvick
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <1353644515-17349-2-git-send-email-chris@rorvick.com>
Chris Rorvick <chris@rorvick.com> writes:
> Pass all rejection reasons back from transport_push(). The logic is
> simpler and more flexible with regard to providing useful feedback.
>
> Signed-off-by: Chris Rorvick <chris@rorvick.com>
> ---
Thanks for a reroll.
I do not think they are "masks", by the way. They are set of flags
(i.e. a bitset).
A bitset is often called "a mask" when it is used to "mask" a subset
of bits in another bitset that has the real information, either to
ignore irrelevant bits or to pick only the relevant bits from the
latter. And your "reject_mask" is never used as a mask in this
patch---it is the bitset that has the real information and it gets
masked by constant masks like REJECT_NON_FF_HEAD.
In any case, naming it as "reject_mask" is like calling a counter as
"counter_int". It is more important to name it after its purpose
than after its type, and because this is to record the reasons why
the push was rejected, "rejection_reason" might be a better name for
it.
^ permalink raw reply
* Re: [PATCH] makefile: hide stderr of curl-config test
From: Junio C Hamano @ 2012-11-26 18:30 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: git
In-Reply-To: <1353554397-27162-1-git-send-email-paul.gortmaker@windriver.com>
Paul Gortmaker <paul.gortmaker@windriver.com> writes:
> Currently, if you don't have curl installed, you will get
>
> $ make distclean 2>&1 | grep curl
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> /bin/sh: curl-config: not found
> $
>
> The intent is not to alarm the user, but just to test if there is
> a new enough curl installed. However, if you look at search engine
> suggested completions, the above "error" messages are confusing
> people into thinking curl is a hard requirement.
Good observation and identification of an issue to tackle. But why
isn't the patch like this?
PROGRAMS += $(REMOTE_CURL_NAMES)
- curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
+ curl_check := $(shell (echo 070908; curl-config --vernum) 2>/dev/null | sort -r | sed -ne 2p)
ifeq "$(curl_check)" "070908"
Removal of the "reject old libcURL" is logically a separate thing
regardless of the "alarming output from make", and it probably is
better done as a separate step in a two-patch series. Doing things
that way, when somebody objects to this:
> It wants to ensure curl is newer than 070908. The oldest
> machine I could find (RHEL 4.6) is 2007 vintage according
> to /proc/version data, and it has curl 070C01.
saying that their installation still cares about older libcURL, we
can still keep the "remove alarming output from make" bit.
>
> The failure here is to mask stderr in the test. However, since
> the chance of curl being installed, but too old is essentially
> nil, lets just check for existence and drop the ancient version
> threshold check, if for no other reason, than to simplifly the
> parsing of what the makefile is trying to do by humans.
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> diff --git a/Makefile b/Makefile
> index 9bc5e40..56f55f6 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1573,8 +1573,8 @@ else
> REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
> PROGRAM_OBJS += http-fetch.o
> PROGRAMS += $(REMOTE_CURL_NAMES)
> - curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
> - ifeq "$(curl_check)" "070908"
> + curl_check := $(shell curl-config --vernum 2>/dev/null)
> + ifneq "$(curl_check)" ""
> ifndef NO_EXPAT
> PROGRAM_OBJS += http-push.o
> endif
^ 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