* Re: [RFC/PATCH] Option to revert order of parents in merge commit
From: Aaron Schrab @ 2012-11-26 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kacper Kornet, git
In-Reply-To: <7v8v9otfdy.fsf@alter.siamese.dyndns.org>
At 09:58 -0800 26 Nov 2012, Junio C Hamano <gitster@pobox.com> wrote:
>Kacper Kornet <draenog@pld-linux.org> writes:
>> The change of order of parents happens at the very last moment, so
>> "ours" in merge options is local version and "theirs" upstream.
>
>That may be something that wants to go to the proposed commit log
>message. I am neutral on the "feature" (i.e. not against it but not
>extremely enthusiastic about it either).
That should also be included in the (currently nonexistent)
documentation of the proposed option.
^ permalink raw reply
* Re: [PATCH v6 p1.1 00/14] fast-export and remote-testgit improvements
From: Felipe Contreras @ 2012-11-26 23:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Johannes Sixt, Johannes Schindelin, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <7vd2z0otie.fsf@alter.siamese.dyndns.org>
On Tue, Nov 27, 2012 at 12:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I'm rerolling this series with the changes fron Junio, plus a bit more cleanups.
>>
>> I dropped the last patch, because I found an issue and a separate patch series
>> would take care of that. Other than that the main changes remain the same.
>>
>> The old remote-testgit is now remote-testpy (as it's testing the python
>> framework, not really remote helpers). The tests are simplified, and exercise
>> more features of transport-helper, and unsuprisingly, find more bugs.
>
> Thanks.
>
> I've queued [v6 p1.1] but not later parts (yet). The result merged
> to 'pu' however seems to break t5800. It could be a stupid and
> trivial merge error or something, but I didn't look into the
> details.
Yeah, the last patch triggers that. It should be moved to part2. The
patch "fast-export: don't handle uninteresting refs" should fix that,
which is why I believe it should be applied first. Didn't I already
say that?
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Felipe Contreras @ 2012-11-26 23:14 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121126220108.GB1713@thyrsus.com>
On Mon, Nov 26, 2012 at 11:01 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> 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.
Might be easier to just call 'git ls-files --with-three foo', but I
don't see the point of those calls:
% git --work-tree=unpacked/1 checkout master
% git --work-tree=unpacked/1 add -A
Should work just fine.
>> 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.
I don't see how the code-size would increase dramatically.
>> 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.
The attached code doesn't handle tags either.
> It doesn't issue delete ops.
What do you mean?
out.puts 'deleteall' <- All current files are removed
And then added.
> And it doesn't rebuild branch heads.
What do you mean? Your code only exports a single branch, the branch
that is currently checked out. And then:
git reset --hard >/dev/null; git checkout master >/dev/null 2>&1
It's resuming to 'master', which might not be the branch the user had
checkout out, and might not even exist.
> 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...
That's what the code currently does.
Do you want me to show you step by step how they do *exactly the
same*? Of course, I would need to fix your version first so that it
doesn't crash with sub-directories.
>> 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.
Well, if there's a line with a single dot in the commit message ('.'),
things would go very bad.
Personally I would prefer something like this:
tag v0.1 gst-av-0.1.tar "Release 0.1"
tag v0.2 gst-av-0.2.tar "Release 0.2"
tag v0.3 gst-av-0.3.tar "Release 0.3"
And the script in bash would be very simple:
#!/bin/sh
tag() {
d=`mktemp -d` &&
(
cd $d &&
tar -xf "$orig/$2" &&
cd * &&
git add --all &&
git commit -q -m "$3" &&
git tag $1) || error=1
rm -rf $d
test -n "$error" && exit -1
}
orig="$PWD"
repo="$1"
git init -q $repo
export GIT_DIR="$orig/$repo/.git"
source "$orig/$2"
cd "$orig/$repo" && git reset -q --hard
--
Felipe Contreras
^ permalink raw reply
* Re: git bundle format
From: Andrew Ardill @ 2012-11-26 23:08 UTC (permalink / raw)
To: Stephen Bash; +Cc: Jason J CTR Pyeron (US), git@vger.kernel.org
In-Reply-To: <1745253724.103630.1353963384110.JavaMail.root@genarts.com>
On 27 November 2012 07:56, Stephen Bash <bash@genarts.com> wrote:
> ----- 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?).
I would propose a slightly different workflow as well, which might
make this process lightly easier. Maybe you are already doing
something like this, but I'll lay it out just in case.
The first step would be to create a 'to-be-publicly-released' branch
within the secret repository, starting from the head of the original
public repository. Rebase all non-secret work to this branch, and
organise it in whatever fashion necessary. This could be, for example,
one single commit representing the sum of all non-secret changes, or
it could be an approximation of the actual history of these changes.
Once this branch has been prepared, you can verify that it branched
from the public repository and that it contains no secret information
using standard git tools or even a patch view of the entire branch.
You can even add a signed tag to the branch once verified to record
who is verifying these changes, and ensuring nothing else gets added
by someone else.
Then you can use 'git bundle fromVerifiedTag.bundle
verifiedTag..public/master' to create a bundle containing just those
commits on the release branch and their associated objects. You can
verify what was included using 'git bundle list-heads
fromVerifiedTag.bundle' to verify what was included.
Perhaps there is a further need to look into the packed objects to
verify nothing else is included, but this workflow should provide more
confidence in the bundled objects in the first place. As for actually
verifying the bundled data after the bundle, I don't know so you would
have to look to the other answers.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: [PATCH v6 p1.1 00/14] fast-export and remote-testgit improvements
From: Junio C Hamano @ 2012-11-26 23:04 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Jeff King, Johannes Sixt, Johannes Schindelin, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <1353727034-24698-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> I'm rerolling this series with the changes fron Junio, plus a bit more cleanups.
>
> I dropped the last patch, because I found an issue and a separate patch series
> would take care of that. Other than that the main changes remain the same.
>
> The old remote-testgit is now remote-testpy (as it's testing the python
> framework, not really remote helpers). The tests are simplified, and exercise
> more features of transport-helper, and unsuprisingly, find more bugs.
Thanks.
I've queued [v6 p1.1] but not later parts (yet). The result merged
to 'pu' however seems to break t5800. It could be a stupid and
trivial merge error or something, but I didn't look into the
details.
Could interested parties take a look?
$ cd t && sh ./t5800-remote-testpy.sh
ok 1 - setup repository
ok 2 - cloning from local repo
ok 3 - cloning from remote repo
ok 4 - create new commit on remote
ok 5 - pulling from local repo
ok 6 - pulling from remote remote
ok 7 - pushing to local repo
not ok 8 - synch with changes from localclone
#
# (cd clone &&
# git pull)
#
not ok 9 - pushing remote local repo
#
# (cd clone &&
# echo content >>file &&
# git commit -a -m four &&
# git push) &&
# compare_refs clone HEAD server HEAD
#
ok 10 - fetch new branch
not ok 11 - fetch multiple branches
#
# (cd localclone &&
# git fetch
# ) &&
# compare_refs server master localclone refs/remotes/origin/master &&
# compare_refs server new localclone refs/remotes/origin/new
#
not ok 12 - push when remote has extra refs
#
# (cd clone &&
# echo content >>file &&
# git commit -a -m six &&
# git push
# ) &&
# compare_refs clone master server master
#
ok 13 - push new branch by name
not ok 14 - push new branch with old:new refspec # TODO known breakage
ok 15 - proper failure checks for fetching
not ok 16 - proper failure checks for pushing # TODO known breakage
# still have 2 known breakage(s)
# failed 4 among remaining 14 test(s)
1..16
^ permalink raw reply
* Re: [PATCH 5/5] git-send-email: allow edit invalid email address
From: Junio C Hamano @ 2012-11-26 22:58 UTC (permalink / raw)
To: Krzysztof Mazur
Cc: git, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen
In-Reply-To: <20121126173318.GA12101@shrek.podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
>> Not having this new code inside "elsif (/^e/) { }" feels somewhat
>> sloppy, even though it is not *too* bad. Also do we know this
>
> ok, I will fix that.
>
>> function will never be used for addresses other than recipients' (I
>> gave a cursory look to see what is done to the $sender and it does
>> not seem to go through this function, tho)?
>
> Yes, this function is called only from validate_address_just()
> to filter @initial_to, @initial_cc, @bcc_list as early as possible,
> and filter @to and @cc added in each email.
Thanks; when merged to 'pu', this series seems to break t9001. I'll
push the result out with breakages but could you take a look?
Test Summary Report
-------------------
t9001-send-email.sh (Wstat: 256 Tests: 102 Failed: 77)
Failed tests: 4-7, 9-10, 12-13, 15, 17-21, 23-29, 31-33
35, 37, 39, 41, 43, 45, 47, 49, 51-58, 61-88
91, 93-95, 98-102
Non-zero exit status: 1
^ permalink raw reply
* Re: Multiple threads of compression
From: Sebastian Leske @ 2012-11-26 7:23 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20121125T171702-64@post.gmane.org>
Hi,
[Thorsten Glaser <tg@debian.org>, 2012-11-25 17:27]:
> On a multi-core machine, the garbage collection of git, as well
> as pack compression on the server side when someone clones a
> repository remotely, the compression is normally done automatically
> using multiple threads of execution.
>
> That may be fine for your typical setups, but in my cases, I have
> two scenarios where it isn’t:
>
> ⓐ The machine where I want it to use only, say, 2 of my 4 or 8 cores
> as I’m also running some VMs on the box which eat up a lot of CPU
> and which I don’t want to slow down.
> ⓑ The server VM which has been given 2 or 3 VCPUs to cope with all
> the load done by clients, but which is RAM-constrained to only
> 512 or, when lucky, 768 MiB. It previously served only http/https
> and *yuk* Subversion, but now, git comes into the play, and I’ve
> seen the one server box I think about go down *HARD* because git
> ate up all RAM *and* swap when someone wanted to update their clone
> of a repository after someone else committed… well, an ~100 MiB large
> binary file they shouldn’t.
unfortunately I can't really speak to the git side of things, but both
of these cases just sound like standard resource starvation. So why
don't you address them using the usual OS mechanisms?
If you want to prevent git from sucking up CPU, nice(1) it, and if it
eats too much RAM, use the parent shell's ulimit mechanism.
Granted, this might also require some changes to git, but wouldn't that
be a simpler and more general approach to solving starvation problems?
^ permalink raw reply
* Re: Interesting git-format-patch bug
From: Junio C Hamano @ 2012-11-26 22:56 UTC (permalink / raw)
To: Olsen, Alan R; +Cc: git@vger.kernel.org
In-Reply-To: <4B2793BF110AAB47AB0EE7B9089703854CA7BA61@fmsmsx110.amr.corp.intel.com>
"Olsen, Alan R" <alan.r.olsen@intel.com> writes:
> 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...)
As you literally have patches that do essentially the same or
similar things on two branches that was merged, you cannot expect to
export each individual commit into a patch and not have conflicts
among them. So I do not think there is no answer than "don't do
that".
I think you could make your "some other process" that rewrites
commits to cull the duplicates out of the format-patch output,
though. Each output file identifies what commit object the patch
came from, and your "some other process" that rewrote the commits
ought to know which commit updated which other commit did, which is
the piece of information needed to remove duplicates that format-patch
does not have.
^ permalink raw reply
* 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
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