* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Junio C Hamano @ 2012-11-26 22:22 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Schindelin, Felipe Contreras, Jeff King, Jonathan Nieder,
git, Max Horn, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <CAGdFq_iLYHs_tUDRsT9X1J12vSp3TUoMJQVbjw4ZgxONL6tMCA@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>>> 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?
>>
>> It does sound so familiar that I am intended to claim that you remember
>> things correctly.
>
> FWIW, I implemented that in
> http://thread.gmane.org/gmane.comp.version-control.git/184874 but
> didn't do the work to get it merged.
Ah, OK. Should I expect an updated series then? How would it
interact with the recent work by Felipe?
^ permalink raw reply
* Re: [PATCH] Third try at documenting command integration requirements.
From: Eric S. Raymond @ 2012-11-26 22:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v624sqbxo.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> Even though "={n} title ={n}" is a valid AsciiDoc heading, all other
> files use (older) underscored titles; please refrain from being
> original.
>
> Especially, this interferes with the way the api-index.txt file in
> the same directory is autogenerated.
Noted for the future, thank you.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Eric S. Raymond @ 2012-11-26 22:01 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s30px2FgieC9VcGji7T+yWFo7gMSwQhtuztHrqto8B7Aw@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> 1) I tried it, and it doesn't seem to import (pack?) are repository
> with sub-directories in it
I'll make sure my regression test checks this case. The options to git
ls-files are a bit confusing and it's possible my invocation of it
needs to change.
> 2) Using 'git fast-import' is probably simpler, and more efficient
That might well be. I'm not worried about "efficiency" in this context
but reducing the code size is significant and I'm willing to re-code
to do that.
> Here is a proof of concept I wrote in ruby that is half the size, and
> seems to implement the same functionality.
Not anywhere near the same. It only handles commits, not tags. It
doesn't issue delete ops. And it doesn't rebuild branch heads.
If I were willing to omit those features, I'm sure I could halve
the size of my implementation, too. Of course, it would then be
almost completely useless...
> The format is exactly the
> same, but I think it should be modified to be more efficient.
I'm not wedded to the log format as it is, so I'll cheerfully
take suggestions about it.
Be aware, however, that I consider easy editability by human beings
much more important than squeezing the last microsecond out of the
processing time. So, for example, I won't use data byte counts rather
than end delimiters, the way import streams do.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH 00/11] alternative unify appending of sob
From: Junio C Hamano @ 2012-11-26 22:00 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, pclouds, Brandon Casey
In-Reply-To: <1353894359-6733-1-git-send-email-drafnel@gmail.com>
Brandon Casey <drafnel@gmail.com> writes:
> So, this series should result in s-o-b and "(cherry picked from...)" being
> appended to commit messages in a more consistent and deterministic way. For
> example, the decision about whether to insert a blank line before appending
> a s-o-b. As discussed, cherry-pick and commit will only refrain from
> appending a s-o-b if the committer's s-o-b appears as the last one in a
> conforming footer, while format-patch will refrain from appending it if it
> appears anywhere within the footer.
Sounds sensible; we may want to fix format-patch later, but with
something like this series, it is just the matter of flipping one
bit.
Will queue. Thanks.
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Sverre Rabbelier @ 2012-11-26 21:46 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Felipe Contreras, Jeff King, Jonathan Nieder, git,
Max Horn, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <alpine.DEB.1.00.1211262024520.7256@s15462909.onlinehome-server.info>
On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> 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?
>
> It does sound so familiar that I am intended to claim that you remember
> things correctly.
FWIW, I implemented that in
http://thread.gmane.org/gmane.comp.version-control.git/184874 but
didn't do the work to get it merged.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] Third try at documenting command integration requirements.
From: Junio C Hamano @ 2012-11-26 21:41 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121126053557.E56434065F@snark.thyrsus.com>
esr@thyrsus.com (Eric S. Raymond) writes:
> @@ -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
Even though "={n} title ={n}" is a valid AsciiDoc heading, all other
files use (older) underscored titles; please refrain from being
original.
Especially, this interferes with the way the api-index.txt file in
the same directory is autogenerated.
^ permalink raw reply
* Re: [PATCH] Third try at documenting command integration requirements.
From: Eric S. Raymond @ 2012-11-26 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzk24qgjx.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.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.
Result looks good from here.
The next things on my git to-do list are
1. Audit the in-tree Python for version dependencies. Add floor-version checks.
2. Submit a doc patch containing guidelines that (a) Python scripts should
check for their floor version and error out gracefully if they won't
run with the host's interpreter, and (b) Python scripts sbould be
2.6-compatible.
3. Submit the git-weave integration patch. I could do that now, but while my
regression test speaks TAP it doesn't presently use the test library. I plan
to re-work it to do that.
Do you have any other pending tasks for which you think my expertise would
be useful? I refer specifically to the facts that (a) I find writing and
editing documentation easy and can do it rapidly, (b) I'm a Python expert,
and (c) I am very interested in, and know a lot about, tools for repository
surgery and import/export.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Interesting git-format-patch bug
From: Olsen, Alan R @ 2012-11-26 21:33 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Olsen, Alan R
I found an interesting bug in git-format-patch.
Say you have a branch A. You create branch B and add a patch to it. You then merge that patch into branch A. After the merge, some other process (we will call it 'gerrit') uses annotate and changes the comment on the patch that exists on branch B.
Now someone runs git-format-patch for the last n patches on branch A. You should just get the original patch that was merged over to branch A. What you get is the patch that was merged to branch A *and* the patch with the modified commit comment on branch B. (Double the patches, double the clean-up...)
This is should be one of those rare corner case "don't do that" occurrences. Unfortunately it does happen once in a while on our branches and it screws up some of the automated processes we rely on.
Is there a way around that (other than "don't") or can this be fixed?
^ permalink raw reply
* Re: git bundle format [OT]
From: Stephen Bash @ 2012-11-26 21:31 UTC (permalink / raw)
To: Jason J CTR Pyeron (US); +Cc: git
In-Reply-To: <871B6C10EBEFE342A772D1159D13208537ABF6D3@umechphj.easf.csd.disa.mil>
----- Original Message -----
> From: "Jason J CTR Pyeron (US)" <jason.j.pyeron.ctr@mail.mil>
> Sent: Monday, November 26, 2012 4:06:59 PM
> Subject: RE: git bundle format [OT]
>
> > 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?).
>
> This is to only address the accidental development on a high side.
> Using this or any process should come with shame or punishment for
> wasting resources/time by not developing on a low side to start
> with.
Ah, if only more of those I (previously) worked with thought as you do :)
> But accepting reality there will be times where code and its
> metadata (commit logs, etc) will be created on a high side and
> should be brought back to the low side.
Using git format-patch and git am it's possible to retain the commit messages (and other associated metadata). But again, I'm not the expert on this :) I've made it work a few times to test patches from this list, but so far I've avoided serious integration into the mailing list workflow.
> > 2) Do the diffs applied to public repo contain any sensitive
> > data?
>
> That is a great question. Can the change of code while neither the
> original or the resultant be secret while the change imply or
> demonstrate the secret. I think the answer is yes.
In actual fact I was thinking about the simple case where the result included an "Eek! 3.1415926 cannot show up in this code!" (sometimes that's easier to see in a diff than a full text blob). Obviously the first line of defense should catch such mistakes. But yes, your point is also a good one. I'd be hard pressed to argue that a particular series of commits leaks information on their own, but they can certainly corroborate other available information.
> > 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.
>
> Here we would be missing the metadata that goes along with the
> commit. Especially the SHA sums.
Ah sorry, I guess I wasn't complete. Once that process has been done on the high side one has to go back to question 1 and see if it's safe to move the bundle out to repeat the process on the low side.
Stephen
^ permalink raw reply
* Re: [PATCH] Fix typo in remote set-head usage
From: Junio C Hamano @ 2012-11-26 21:28 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git, Jiang Xin
In-Reply-To: <1353957714-7330-1-git-send-email-apelisse@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Johannes Schindelin @ 2012-11-26 19:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, 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>
Hi Junio,
On Mon, 26 Nov 2012, Junio C Hamano 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).
Good to know. I will find some time to look at rev_cmdline_info and patch
my patch.
> 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.
>
> 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?
It does sound so familiar that I am intended to claim that you remember
things correctly.
Ciao,
Johannes
^ permalink raw reply
* RE: git bundle format [OT]
From: Pyeron, Jason J CTR (US) @ 2012-11-26 21:06 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <1745253724.103630.1353963384110.JavaMail.root@genarts.com>
[-- Attachment #1: Type: text/plain, Size: 4294 bytes --]
> -----Original Message-----
> From: Stephen Bash
> Sent: Monday, November 26, 2012 3:56 PM
>
> ----- Original Message -----
> > From: "Jason J CTR Pyeron (US)"
> > 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.
Kind of what I am looking for as a side effect.
>
> > 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?).
This is to only address the accidental development on a high side. Using this or any process should come with shame or punishment for wasting resources/time by not developing on a low side to start with. But accepting reality there will be times where code and its metadata (commit logs, etc) will be created on a high side and should be brought back to the low side.
> 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?
Potentially, hence the review. If the reviewer cannot prove the data he is looking at then the presumption is yes.
> 2) Do the diffs applied to public repo contain any sensitive data?
That is a great question. Can the change of code while neither the original or the resultant be secret while the change imply or demonstrate the secret. I think the answer is yes.
>
> 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.
The logistics are well established and here and now is not a place to go in to that. But the above is the crux of what I am trying to get at.
>
> 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.
Here we would be missing the metadata that goes along with the commit. Especially the SHA sums.
Thanks.
-Jason
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5615 bytes --]
^ permalink raw reply
* [PATCH v4 3/4] git-submodule update: Add --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 allows users to checkout the current
superproject-recorded-submodule-sha as a branch, avoiding the detached
head state that the standard submodule update creates. This may be
useful for the existing --rebase/--merge workflows which already avoid
detached heads.
It is also useful if you want easy tracking of upstream branches. The
particular upstream branch to be tracked is configured locally with
.git/modules/<name>/config. With the new option Ævar's suggested
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitm
odules submodule.$name.branch) && git pull'
reduces to a
$ git submodule update --branch
after each supermodule .gitmodules edit, and a
$ git submodule foreach 'git pull'
whenever you feel like updating the submodules. Your still on you're
own to commit (or not) the updated submodule hashes in the
superproject's .gitmodules.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/git-submodule.txt | 20 +++++++++++------
git-submodule.sh | 48 +++++++++++++++++++++++++++++----------
t/t7406-submodule-update.sh | 50 ++++++++++++++++++++++++++++++++++++++++-
3 files changed, 98 insertions(+), 20 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index d0b4436..34392a1 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[-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]
+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--branch] [--rebase]
[--reference <repository>] [--merge] [--recursive] [--] [<path>...]
'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) <n>]
[commit] [--] [<path>...]
@@ -136,11 +136,11 @@ init::
update::
Update the registered submodules, i.e. clone missing submodules and
- checkout the commit specified in the index of the containing repository.
- This will make the submodules HEAD be detached unless `--rebase` or
- `--merge` is specified or the key `submodule.$name.update` is set to
- `rebase`, `merge` or `none`. `none` can be overridden by specifying
- `--checkout`.
+ checkout the commit specified in the index of the containing
+ repository. This will make the submodules HEAD be detached unless
+ `--branch`, `--rebase`, `--merge` is specified or the key
+ `submodule.$name.update` is set to `branch`, `rebase`, `merge` or
+ `none`. `none` can be overridden by specifying `--checkout`.
+
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
@@ -207,7 +207,13 @@ OPTIONS
-b::
--branch::
- Branch of repository to add as submodule.
+ When used with the add command, gives the branch of repository to
+ add as submodule.
++
+When used with the update command, checks out a branch named
+`submodule.<name>.branch` (as set by `--local-branch`) pointing at the
+current HEAD SHA-1. This is useful for commands like `update
+--rebase` that do not work on detached heads.
--local-branch::
Record a branch name used as `submodule.<path>.branch` in
diff --git a/git-submodule.sh b/git-submodule.sh
index c51b6ae..28eb4b1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -8,7 +8,7 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
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>...]
+ or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--branch] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
or: $dashless [--quiet] summary [--cached|--files] [--summary-limit <n>] [commit] [--] [<path>...]
or: $dashless [--quiet] foreach [--recursive] <command>
or: $dashless [--quiet] sync [--] [<path>...]"
@@ -539,6 +539,9 @@ cmd_update()
-f|--force)
force=$1
;;
+ -b|--branch)
+ update="branch"
+ ;;
-r|--rebase)
update="rebase"
;;
@@ -593,6 +596,7 @@ cmd_update()
fi
name=$(module_name "$sm_path") || exit
url=$(git config submodule."$name".url)
+ branch=$(git config submodule."$name".branch)
if ! test -z "$update"
then
update_module=$update
@@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?")"
die "$(eval_gettext "Unable to find current revision in submodule path '\$sm_path'")"
fi
- if test "$subsha1" != "$sha1" -o -n "$force"
+ if test "$subsha1" != "$sha1" -o -n "$force" -o "$update_module" = "branch"
then
subforce=$force
# If we don't already have a -f flag and the submodule has never been checked out
@@ -650,16 +654,21 @@ Maybe you want to use 'update --init'?")"
case ";$cloned_modules;" in
*";$name;"*)
# then there is no local change to integrate
- update_module= ;;
+ case "$update_module" in
+ rebase|merge)
+ update_module=
+ ;;
+ esac
+ ;;
esac
must_die_on_failure=
case "$update_module" in
rebase)
command="git rebase"
- die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$sm_path'")"
+ die_msg="$(eval_gettext "Unable to rebase '\$sha1' in submodule path '\$sm_path'")"
say_msg="$(eval_gettext "Submodule path '\$sm_path': rebased into '\$sha1'")"
- must_die_on_failure=yes
+ must_die_on_failure=yes
;;
merge)
command="git merge"
@@ -674,15 +683,30 @@ Maybe you want to use 'update --init'?")"
;;
esac
- if (clear_local_git_env; cd "$sm_path" && $command "$sha1")
+ if test "$subsha1" != "$sha1" -o -n "$force"
then
- say "$say_msg"
- elif test -n "$must_die_on_failure"
+ if (clear_local_git_env; cd "$sm_path" && $command "$sha1")
+ then
+ say "$say_msg"
+ elif test -n "$must_die_on_failure"
+ then
+ die_with_status 2 "$die_msg"
+ else
+ err="${err};$die_msg"
+ continue
+ fi
+ fi
+
+ if test "$update_module" = "branch" -a -n "$branch"
then
- die_with_status 2 "$die_msg"
- else
- err="${err};$die_msg"
- continue
+ if (clear_local_git_env; cd "$sm_path" &&
+ git branch -f "$branch" "$sha1" &&
+ git checkout "$branch")
+ then
+ say "$(eval_gettext "Submodule path '\$sm_path': checked out branch '\$branch'")"
+ else
+ err="${err};$(eval_gettext "Unable to checkout branch '\$branch' in submodule path '\$sm_path'")"
+ fi
fi
fi
diff --git a/t/t7406-submodule-update.sh b/t/t7406-submodule-update.sh
index 1542653..c876a8b 100755
--- a/t/t7406-submodule-update.sh
+++ b/t/t7406-submodule-update.sh
@@ -6,7 +6,8 @@
test_description='Test updating submodules
This test verifies that "git submodule update" detaches the HEAD of the
-submodule and "git submodule update --rebase/--merge" does not detach the HEAD.
+submodule and "git submodule update --branch/--rebase/--merge" does not
+detach the HEAD.
'
. ./test-lib.sh
@@ -135,6 +136,53 @@ test_expect_success 'submodule update --force forcibly checks out submodules' '
)
'
+test_expect_success 'submodule update --branch detaches without submodule.<name>.branch' '
+ (cd super/submodule &&
+ git checkout master
+ ) &&
+ (cd super &&
+ (cd submodule &&
+ compare_head
+ ) &&
+ git submodule update --branch submodule &&
+ (cd submodule &&
+ test "$(git status -s file)" = ""
+ )
+ )
+'
+
+test_expect_success 'submodule update --branch staying on master' '
+ (cd super/submodule &&
+ git checkout master
+ ) &&
+ (cd super &&
+ (cd submodule &&
+ compare_head
+ ) &&
+ git config submodule.submodule.branch master
+ git submodule update --branch submodule &&
+ cd submodule &&
+ test "refs/heads/master" = "$(git symbolic-ref -q HEAD)" &&
+ compare_head
+ )
+'
+
+test_expect_success 'submodule update --branch creating a new branch' '
+ (cd super/submodule &&
+ git checkout master
+ ) &&
+ (cd super &&
+ (cd submodule &&
+ compare_head
+ ) &&
+ git config submodule.submodule.branch new-branch
+ git submodule update --branch submodule &&
+ cd submodule &&
+ test "refs/heads/new-branch" = "$(git symbolic-ref -q HEAD)" &&
+ compare_head
+ )
+'
+
test_expect_success 'submodule update --rebase staying on master' '
(cd super/submodule &&
git checkout master
--
1.8.0.3.g95edff1.dirty
^ permalink raw reply related
* [PATCH v4 4/4] Hack fix for 'submodule update does not fetch already present commits'
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>
---
git-submodule.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 28eb4b1..f4a681c 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -640,7 +640,7 @@ Maybe you want to use 'update --init'?")"
subforce="-f"
fi
- if test -z "$nofetch"
+ if test -z "$nofetch" -a "$subsha1" != "$sha1"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
--
1.8.0.3.g95edff1.dirty
^ permalink raw reply related
* [PATCH v4 2/4] git-submodule init: Record submodule.<name>.branch in repository config.
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 allows users to override the .gitmodules value with a
per-repository value.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/config.txt | 9 +++++----
git-submodule.sh | 7 +++++++
t/t7400-submodule-basic.sh | 18 ++++++++++++++++++
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 11f320b..1304499 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1994,10 +1994,11 @@ status.submodulesummary::
submodule.<name>.path::
submodule.<name>.url::
submodule.<name>.update::
- The path within this project, URL, and the updating strategy
- for a submodule. These variables are initially populated
- by 'git submodule init'; edit them to override the
- URL and other values found in the `.gitmodules` file. See
+submodule.<name>.branch::
+ The path within this project, URL, the updating strategy, and the
+ local branch name for a submodule. These variables are initially
+ populated by 'git submodule init'; edit them to override the URL and
+ other values found in the `.gitmodules` file. See
linkgit:git-submodule[1] and linkgit:gitmodules[5] for details.
submodule.<name>.fetchRecurseSubmodules::
diff --git a/git-submodule.sh b/git-submodule.sh
index 6eed008..c51b6ae 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -505,6 +505,13 @@ cmd_init()
test -n "$(git config submodule."$name".update)" ||
git config submodule."$name".update "$upd" ||
die "$(eval_gettext "Failed to register update mode for submodule path '\$sm_path'")"
+
+ # Copy "branch" setting when it is not set yet
+ branch="$(git config -f .gitmodules submodule."$name".branch)"
+ test -z "$branch" ||
+ test -n "$(git config submodule."$name".branch)" ||
+ git config submodule."$name".branch "$branch" ||
+ die "$(eval_gettext "Failed to register branch for submodule path '\$sm_path'")"
done
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index fc08647..3dc8237 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -236,6 +236,24 @@ test_expect_success 'submodule add --local-branch=<name> --branch' '
)
'
+test_expect_success 'init should register submodule branch in .git/config' '
+ (
+ cd addtest &&
+ git submodule init &&
+ test "$(git config submodule.submod-follow.branch)" = "final"
+ )
+'
+
+test_expect_success 'local config should override .gitmodules branch' '
+ (
+ cd addtest &&
+ rm -fr submod-follow &&
+ git config submodule.submod-follow.branch initial
+ git submodule init &&
+ test "$(git config submodule.submod-follow.branch)" = "initial"
+ )
+'
+
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
* [PATCH v4 0/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: <20121123175402.GH2806@odin.tremily.us>
From: "W. Trevor King" <wking@tremily.us>
On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote:
> We could add
>
> $ git submodule update --branch
>
> to checkout the gitlinked SHA1 as submodule.<name>.branch in each of
> the submodules, leaving the submodules on the .gitmodules-configured
> branch. Effectively (for each submodule):
>
> $ git branch -f $branch $sha1
> $ git checkout $branch
I haven't gotten any feedback on this as an idea, but perhaps someone
will comment on it as a patch series ;).
Changes since v3:
* --record=… is now --local-branch=…
* Dropped patches 2 ($submodule_ export) and 3 (motivating documentation)
* Added local git-config overrides of .gitmodules' submodule.<name>.branch
* Added `submodule update --branch`
Because you need to recurse through submodules for `update --branch`
even if "$subsha1" == "$sha1", I had to amend the conditional
controlling that block. This broke one of the existing tests, which I
"fixed" in patch 4. I think a proper fix would involve rewriting
(clear_local_git_env; cd "$sm_path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
but I'm not familiar enough with rev-list to want to dig into that
yet. If feedback for the earlier three patches is positive, I'll work
up a clean fix and resubmit.
W. Trevor King (4):
git-submodule add: Add --local-branch option
git-submodule init: Record submodule.<name>.branch in repository
config.
git-submodule update: Add --branch option
Hack fix for 'submodule update does not fetch already present
commits'
Documentation/config.txt | 9 ++---
Documentation/git-submodule.txt | 32 ++++++++++++-----
Documentation/gitmodules.txt | 5 +++
git-submodule.sh | 76 +++++++++++++++++++++++++++++++++--------
t/t7400-submodule-basic.sh | 43 +++++++++++++++++++++++
t/t7406-submodule-update.sh | 50 ++++++++++++++++++++++++++-
6 files changed, 187 insertions(+), 28 deletions(-)
--
1.8.0.3.g95edff1.dirty
^ permalink raw reply
* [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
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