* Re: [PATCH] Move try_merge_command and checkout_fast_forward to libgit.a
From: Jeff King @ 2012-10-26 12:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8D1_c9NP_nwvp6uJyKikG+_jqnm1hVEs_t_wnsYTLZ4Yg@mail.gmail.com>
On Thu, Oct 25, 2012 at 07:50:26PM +0700, Nguyen Thai Ngoc Duy wrote:
> On Thu, Oct 25, 2012 at 4:45 PM, Jeff King <peff@peff.net> wrote:
> > On Tue, Oct 23, 2012 at 09:24:51AM +0700, Nguyen Thai Ngoc Duy wrote:
> >
> >> These functions are called in sequencer.c, which is part of
> >> libgit.a. This makes libgit.a potentially require builtin/merge.c for
> >> external git commands.
> >>
> >> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> >> ---
> >> I made some unrelated changes in sequencer.c and this problem shown
> >> up. merge-recursive.c is probably not the best place for these
> >> functions. I just don't want to create merge.c for them.
> >
> > I'm fine with this conceptually, but merge-recursive really is the wrong
> > place. I'd much rather see a new merge.c to collect merge-related helper
> > functions that are not strategy-specific.
>
> OK. I checked around for similar issues and found these used by
> libgit.a but stay in builtin/ instead:
Yeah, we have traditionally been kind of lazy about the distinction,
because it doesn't really matter for our build system (i.e., libgit.a is
not _really_ a library, but just a convenience in the build process). So
one option is just not caring about these. I'm also fine with fixing.
> estimate_bisect_steps: bisect.c and builtin/rev-list.c
> print_commit_list: bisect.c and builtin/rev-list.c
>
> -> move them to bisect.c? another candidate is revision.c.
I'd probably say bisect.c for the first, and commit.c for the latter
(that is where commit_list functions are defined, and it is really about
that).
> fetch_pack: transport.c and builtin/fetch-pack.c
> send_pack: transport.c and builtin/send-pack.c
>
> -> move them to transport.c? or new files fetch-pack.c and
> send-pack.c? I haven't check how many functions they may pull
> together.
I think I'd rather have fetch-pack.c and send-pack.c than putting them
into transport.c (which is getting kind of bloated already).
> setup_diff_pager: diff-no-index.c and builtin/diff.c
>
> -> to diff-lib.c?
I'm not sure (to be honest, I am not even sure of the intended
difference between diff.c and diff-lib.c). That function is really not
for general diffing, but for diff-like commands. Probably it would be OK
in diff.c.
-Peff
^ permalink raw reply
* Re: Unexpected behaviour after removing submodule
From: Nicolas Morey-Chaisemartin @ 2012-10-26 10:05 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <5089C192.2050903@web.de>
On 26/10/12 00:47, Jens Lehmann wrote:
> Am 25.10.2012 17:06, schrieb Nicolas Morey-Chaisemartin:
>> At work, we use a lot of submodules (several levels of submodules actually).
>> As we also work with development branches, we use scripts to resync the whole checked-out tree (mainly in automated integration)
>>
>> We recently run across an issue where a branch (dev) contained a submodule while it had been removed in master and the files were imported in a subdirectory with the same name (probably using git-subtree).
>>
>> Basically:
>>
>> On dev:
>> * top/refs(submodule)/file1
>> On master:
>> * top/refs(dir)/file1
>>
>> Outside the fact that it is quite hard to move from one branch to the other while having a perfectly clean tree checked out underneath, we manage to end up into a weird (invalid) state
>> that was neither clearly described nor "easy" to cleanup (using standard git clean/checkout/reset commands).
> <snipped example without submodules>
>
>> The issue is, there is no way from folder2 to see that something "wrong" is going on inside your tree!
>> As we manage to reach this state using only standard git commands (I'll try to reproduce it) with submodules, and this being part of an automated flow, it is quite worrying.
>> We may actually be committing in the wrong repo and pushing the wrong things around.
>>
>> Is there or should there be a way to look for such issues? And is this an expected behaviour?
> Unfortunately this is how things work at the moment. If you remove a
> submodule its work tree will currently stay around nonetheless. And
> when you replace it with a directory containing files tracked by git,
> things start to get really weird when you do checkouts crossing that
> conversion.
>
> But the solution to that problem is coming closer. The first step was
> to move the .git directory out of the submodule's work tree, so that
> we are able to remove it without loosing any history. The next step
> will be to enable git to remove and re-add submodules on checkout. The
> "remove a submodule" part already works in my - still experimental -
> recursive_submodule_checkout branch at my github repo. The thing that
> is still missing - apart from tests ;) - is that checkout has to learn
> to look into the to-be-checked-out .gitmodules to be able to populate
> a re-appearing submodule. I plan to add that for git fetch first (so
> it can fetch submodules the user showed interest in but which aren't
> currently checked out) and after that I'll reuse it for checkout.
>
> But that's still some work to do and will take some time ...
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
That's what I figured. I just wished there was at least a way to see that there's a .git directory that does not really belong.
To check that now we'd have to do a git-ls tree and look for .git that shouldn't be here but with the amount of file we have, a shell script doing that would take ages !
We'll wait for a more submodule aware version of checkout then !
Thanks
Nicolas
^ permalink raw reply
* How to get submodule information for a specific commit
From: Francis Moreau @ 2012-10-26 10:05 UTC (permalink / raw)
To: git
Hi,
I'd like to get information about the submodule commits used by a
given super project commit.
The information I'm looking for is quite similar than the one you can
get with "git submodule status" but for any revs not only the current
head of the super project.
Someone on #git kindly suggested me to use git-ls-tree, but I'm
wondering if an option or a new command to git-submodule could be
added to achieve that.
Thanks
--
Francis
^ permalink raw reply
* Re: [PATCH] Document git-svn fetch --log-window-size parameter
From: Eric Wong @ 2012-10-26 9:46 UTC (permalink / raw)
To: Gunnlaugur Þór Briem; +Cc: Jeff King, git
In-Reply-To: <20121025095202.GK8390@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Tue, Oct 23, 2012 at 10:33:26AM +0000, Gunnlaugur Þór Briem wrote:
>
> > The --log-window-size parameter to git-svn fetch is undocumented.
> >
> > Minimally describe what it does and why the user might change it.
>
> Thanks. Your description makes sense to me, but I do not have enough
> git-svn knowledge to know if it covers all intended uses of the flag.
> Eric?
>
> > +--log-window-size=<n>;;
> > + Fetch <n> log entries per request when scanning Subversion history.
> > + The default is 100. For very large Subversion repositories, larger
> > + values may be needed for 'clone'/'fetch' to complete in reasonable
> > + time. But overly large values may lead to request timeouts.
Overly large values also lead to excessive memory usage. I may have
only had 256M in my dev machine at the time I added this parameter:
commit 6af1db447b10c03db4c04a55000efaa9aad38caa
Author: Eric Wong <normalperson@yhbt.net>
Date: Wed Feb 14 16:04:10 2007 -0800
git-svn: allow --log-window-size to be specified, default to 100
The newer default value should should lower memory usage for
large fetches and also help with fetching from less reliable
servers. Previously the value was 1000 and memory usage
got a bit high on some repositories and fetching became
less reliable in some cases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
^ permalink raw reply
* Re: [PATCH] Add new git-remote-hd helper
From: Felipe Contreras @ 2012-10-26 9:02 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Jeff King, git, Junio C Hamano, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow
In-Reply-To: <CAGdFq_hsCjL5uunwg=N-y+FkFt-ZxORtrEcxAAHt-rDfA04cZw@mail.gmail.com>
On Thu, Oct 18, 2012 at 8:12 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Wed, Oct 17, 2012 at 10:18 PM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
>> Right now I've just added an error when using remote repositories. But
>> it seems there's no way around it; if we want to have support for
>> remote repos, we need to make a local clone.
>
> My git-remote-hg does the local clone into .git/ using a hash of the
> url (although you could just as well use urlencode, basically any way
> to safely use a url as a directory name). Have a look if you want.
I can't find that code.
--
Felipe Contreras
^ permalink raw reply
* Re: git push tags
From: Angelo Borsotti @ 2012-10-26 6:42 UTC (permalink / raw)
To: Drew Northup; +Cc: git
In-Reply-To: <CAM9Z-nkosbe1NXYnu7x6v4seLqCnMBWg-jrdH2eJ9RetaZBTyQ@mail.gmail.com>
Hi Drew,
>
> Changing the tag in the local repository is a tag modification
> operation. Pushing that change to a remote repository DOES NOT execute
> "git tag...." in the remote. Plain and simple the two are different
> operations.
>
They are different for what concerns the implementation. They are not
necessarily so for what concerns their semantics, and the most
straightforward is to apply to the remote repository the changes done
on the local one -- the changes that can legally done on it -- and
changing a tag is not one allowed (unless forced).
Obviously, the semantics of git-push is different, and then needs to
be described clearly.
Note that some (probably most) of the operations that are disallowed
on the local repo are also disallowed by git-push, like, e.g. deleting
the current branch. But the user cannot tell what is disallowed and
what not if the man page does not state it.
> So here we come to the core argument. Is sounds to me like you want
> changes to remote tags to work differently from push updates to ALL
> other references. The required change, if I'm not mistaken, would be
> for tags to not permit fast-forward updates while all other references
> would be pushed normally. From my brief and un-enlightened look at the
> push code I can't see that being as easy as it sounds.
>
No, I was hoping that git-push refused to change tags at all, unless
forced (e.g. prefixing them with +), as it is on a local repository.
-Angelo
^ permalink raw reply
* git rebase -i and final newline
From: Steven Penny @ 2012-10-26 2:09 UTC (permalink / raw)
To: git
Sorry if I am drumming up and old issue here. I have noticed that with
"git rebase -i", if your final line contains a commit and no newline, git
interprets that as "remove this commit please".
I feel that a commit should be removed only if the entire line is removed, that
is the commit hash and title as well as the newline.
I have noticed that the behavior is "correct" with "git commit". Even if you
omit the final newline after the commit message body, all text lines will be
included.
^ permalink raw reply
* Re: [PATCH] Fixes handling of --reference argument.
From: Jeff King @ 2012-10-26 0:39 UTC (permalink / raw)
To: Jens Lehmann; +Cc: W. Trevor King, szager, git
In-Reply-To: <5089AFED.7060404@web.de>
On Thu, Oct 25, 2012 at 11:32:29PM +0200, Jens Lehmann wrote:
> >>> @@ -270,7 +270,6 @@ cmd_add()
> >>> ;;
> >>> --reference=*)
> >>> reference="$1"
> >>> - shift
> >>> ;;
> >>
> >> Is that right? We'll unconditionally do a "shift" at the end of the
> >> loop. If it were a two-part argument like "--reference foo", the extra
> >> shift would make sense, but for "--reference=*", no extra shift should
> >> be neccessary. Am I missing something?
> >
> > Both the patch and Jeff's analysis are right. You only need an
> > in-case shift if you consume "$2", or you're on ‘--’ and you're
> > breaking before the end-of-case shift.
>
> Right you are. The shift there is wrong, as there is no extra argument
> to consume for "--reference=<repo>" (opposed to "--reference <repo>",
> also see cmd_update() where this is done right).
Oh, the problem is that I'm an idiot, and for some reason read it as
_adding_ the bogus shift, not removing it. Patch is clearly correct.
> So tested and Acked-By me, but me thinks the subject should read:
>
> [PATCH] submodule add: Fix handling of the --reference=<repo> option
>
> and the commit message should begin with:
>
> Doing a shift there is wrong because there is no extra argument
> to consume when "--reference=<repo>" is used (note the '=' instead
> of a space).
Yeah, I think it makes sense to explain why it is wrong in the commit
message (I'll blame that for my lack of common sense above :) ).
> Peff, is it ok for you to squash that in or do you want Stefan to resend?
I can squash it in. Thanks all.
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King @ 2012-10-25 22:14 UTC (permalink / raw)
To: Git, Nahor, Phil Hord
In-Reply-To: <1f6ee2966ffe0f58f4b96ae0efb2ffb13e2fa2d8.1351029479.git.wking@tremily.us>
[-- Attachment #1: Type: text/plain, Size: 431 bytes --]
Should I rebase this so it lands cleanly atop 38ae92e4 in next?
commit 38ae92e4d027063b9b87e51a9bf12809d10066f6
Author: W. Trevor King <wking@tremily.us>
Date: Tue Oct 23 17:00:21 2012 -0400
git-submodule: wrap branch option with "<>" in usage strings.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: Who is the 'git' vendor?
From: PROHASKA, Thor @ 2012-10-25 23:10 UTC (permalink / raw)
To: 'Jeff King'
Cc: Andreas Ericsson, 'git@vger.kernel.org',
'Thor Home (thorlp@hotkey.net.au)'
In-Reply-To: <20121025091017.GE8390@sigill.intra.peff.net>
Thanks Andreas & Jeff. Your advice is much appreciated. Cheers, Thor
-----Original Message-----
From: Jeff King [mailto:peff@peff.net]
Sent: Thursday, 25 October 2012 7:10 PM
To: PROHASKA, Thor
Cc: Andreas Ericsson; 'git@vger.kernel.org'; 'Thor Home (thorlp@hotkey.net.au)'
Subject: Re: Who is the 'git' vendor?
On Thu, Oct 25, 2012 at 10:52:44AM +0200, Andreas Ericsson wrote:
> On 10/25/2012 08:43 AM, PROHASKA, Thor wrote:
> > Hi,
> >
> > The organisation I am currently working for uses 'git'.
> >
> > In order to manage all the software used in the organisation we have
> > been compiling a list of software that includes the software
> > Vendor's name.
> >
> > My colleague has listed the vendor of git as being the 'Software
> > Freedom Conservancy'. Can you please advise me if this is correct?
> > If not, who should the vendor be identified as?
> >
>
> Most likely, you'll want to put "git@vger.kernel.org" as vendor for
> git, as the whole vendor concept doesn't really fly with FOSS. There's
> noone to go to if it breaks your systems, and unless you purchase a
> support contract from somewhere there's noone to turn to except the
> (excellent) git community in case you have issues with it.
Yeah. Depending on the purpose of the list, I would probably _not_ put the SFC. They help manage the legal and financial aspects of the git project, but they have nothing at all to do with the code itself. I would hate for them to get a phone call about support. :)
Probably "The Git Community" or "git@vger.kernel.org" is the best thing to fill in if you need to write something in a form. If there ends up being some specific reason for a vendor to be contacted, folks on the list will be able to point an inquiry in the right direction (which might even end up being the SFC).
-Peff
________________________________
This e-mail is sent by Suncorp Group Limited ABN 66 145 290 124 or one of its related entities "Suncorp".
Suncorp may be contacted at Level 18, 36 Wickham Terrace, Brisbane or on 13 11 55 or at suncorp.com.au.
The content of this e-mail is the view of the sender or stated author and does not necessarily reflect the view of Suncorp. The content, including attachments, is a confidential communication between Suncorp and the intended recipient. If you are not the intended recipient, any use, interference with, disclosure or copying of this e-mail, including attachments, is unauthorised and expressly prohibited. If you have received this e-mail in error please contact the sender immediately and delete the e-mail and any attachments from your system.
^ permalink raw reply
* Re: [PATCH] Doc format-patch: clarify --notes use case
From: Philip Oakley @ 2012-10-25 22:48 UTC (permalink / raw)
To: Jeff King; +Cc: GitList, Junio C Hamano, Eric Blake
In-Reply-To: <20121025102527.GO8390@sigill.intra.peff.net>
From: "Jeff King" <peff@peff.net> Sent: Thursday, October 25, 2012 11:25
AM
> On Sun, Oct 21, 2012 at 10:34:10PM +0100, Philip Oakley wrote:
>
>> The expected use case of this is to write supporting explanation for
>> -the commit that does not belong to the commit log message proper
>> -when (or after) you create the commit, and include it in your patch
>> -submission. But if you can plan ahead and write it down, there may
>> -not be a good reason not to write it in your commit message, and if
>> -you can't, you can always edit the output of format-patch before
>> -sending it out, so the practical value of this option is somewhat
>> -dubious, unless your workflow is broken.
>> +the commit, that does not belong to the commit log message proper,
>> +and include it with the patch submission. The notes can be
>> maintained
>> +between versions of the patch series. You can also edit the output
>> of
>> +format-patch before sending.
>
> I found the "you can also" slightly awkward here, as it was not clear
> why it was mentioned.
I was trying to catch what I think Junio was trying to say about
'writing it down' and 'can always edit the output' but wasn't exactly
sure how to read it.
>I think the intent is "this is an alternative that
> does not involve the notes workflow", but it is not clear from the
> text
> why you would prefer the notes workflow. Here is what I queued
> instead,
> which tires to clarify that, and also mentions that this workflow
> needs
> additional setup to track rewritten commits:
Your version below captures the intent. <Ack>
>
> diff --git a/Documentation/git-format-patch.txt
> b/Documentation/git-format-patch.txt
> index 066dc8b..750b3fa 100644
> --- a/Documentation/git-format-patch.txt
> +++ b/Documentation/git-format-patch.txt
> @@ -196,13 +196,12 @@ The expected use case of this is to write
> supporting explanation for
> after the three-dash line.
> +
> The expected use case of this is to write supporting explanation for
> -the commit that does not belong to the commit log message proper
> -when (or after) you create the commit, and include it in your patch
> -submission. But if you can plan ahead and write it down, there may
> -not be a good reason not to write it in your commit message, and if
> -you can't, you can always edit the output of format-patch before
> -sending it out, so the practical value of this option is somewhat
> -dubious, unless your workflow is broken.
> +the commit that does not belong to the commit log message proper,
> +and include it with the patch submission. While one can simply write
> +these explanations after `format-patch` has run but before sending,
> +keeping them as git notes allows them to be maintained between
> versions
> +of the patch series (but see the discussion of the `notes.rewrite.*`
> +configuration in linkgit:git-notes[1] to use this workflow).
Should the notes.rewriteRef also be mentioned (not part of .*), which is
at the end of the notes configuration and that it must be set may be
missed by readers? Perhaps "the 'notes.rewrite' configurations",
dropping the .* and making it plural?
> a signature to each message produced. Per RFC 3676 the signature
>
>
> I've queued that and your other patches on top of
> jc/prettier-pretty-note.
>
> -Peff
>
>
> -----
Philip
^ permalink raw reply
* Re: Unexpected behaviour after removing submodule
From: Jens Lehmann @ 2012-10-25 22:47 UTC (permalink / raw)
To: devel-git; +Cc: git
In-Reply-To: <50895580.9080408@morey-chaisemartin.com>
Am 25.10.2012 17:06, schrieb Nicolas Morey-Chaisemartin:
> At work, we use a lot of submodules (several levels of submodules actually).
> As we also work with development branches, we use scripts to resync the whole checked-out tree (mainly in automated integration)
>
> We recently run across an issue where a branch (dev) contained a submodule while it had been removed in master and the files were imported in a subdirectory with the same name (probably using git-subtree).
>
> Basically:
>
> On dev:
> * top/refs(submodule)/file1
> On master:
> * top/refs(dir)/file1
>
> Outside the fact that it is quite hard to move from one branch to the other while having a perfectly clean tree checked out underneath, we manage to end up into a weird (invalid) state
> that was neither clearly described nor "easy" to cleanup (using standard git clean/checkout/reset commands).
<snipped example without submodules>
> The issue is, there is no way from folder2 to see that something "wrong" is going on inside your tree!
> As we manage to reach this state using only standard git commands (I'll try to reproduce it) with submodules, and this being part of an automated flow, it is quite worrying.
> We may actually be committing in the wrong repo and pushing the wrong things around.
>
> Is there or should there be a way to look for such issues? And is this an expected behaviour?
Unfortunately this is how things work at the moment. If you remove a
submodule its work tree will currently stay around nonetheless. And
when you replace it with a directory containing files tracked by git,
things start to get really weird when you do checkouts crossing that
conversion.
But the solution to that problem is coming closer. The first step was
to move the .git directory out of the submodule's work tree, so that
we are able to remove it without loosing any history. The next step
will be to enable git to remove and re-add submodules on checkout. The
"remove a submodule" part already works in my - still experimental -
recursive_submodule_checkout branch at my github repo. The thing that
is still missing - apart from tests ;) - is that checkout has to learn
to look into the to-be-checked-out .gitmodules to be able to populate
a re-appearing submodule. I plan to add that for git fetch first (so
it can fetch submodules the user showed interest in but which aren't
currently checked out) and after that I'll reuse it for checkout.
But that's still some work to do and will take some time ...
^ permalink raw reply
* Re: [PATCH] Doc User-Manual: Patch cover letter, three dashes, and --notes
From: Philip Oakley @ 2012-10-25 22:45 UTC (permalink / raw)
To: Jeff King; +Cc: GitList, Junio C Hamano, Eric Blake
In-Reply-To: <20121025102638.GP8390@sigill.intra.peff.net>
From: "Jeff King" <peff@peff.net> Sent: Thursday, October 25, 2012 11:26
AM
> On Sun, Oct 21, 2012 at 10:34:08PM +0100, Philip Oakley wrote:
>
>> diff --git a/Documentation/user-manual.txt
>> b/Documentation/user-manual.txt
>> index 85651b5..d918c53 100644
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -1787,6 +1787,11 @@ $ git format-patch origin
>> will produce a numbered series of files in the current directory,
>> one
>> for each patch in the current branch but not in origin/HEAD.
>>
>> +`git format-patch` can include an initial "cover letter". You can
>> insert
>> +a commentary on individual patches using a three dash line after the
>> +commit message, and before the patch itself. `git
>> format-patch --notes`
>> +(v1.8.1) will include the commit's notes in the similar manner.
>
> I'd rather not mention a version number here, as we do not yet know
> which version (if any) will contain the feature. Besides, we write our
> documentation to match the current version, so as long as this is
> queued
> on top of the new code, I do not see any reason to mention a version
> at
> all.
I'd included it because of the manual's title caveat "(for version 1.5.3
or newer)", which I'd somehow thought was the matching date for the
majority of text, hence my inclusion of the version. Begs the question
what happened back then ;-)
>
> I'll tweak it while queueing.
Thank you.
>
> -Peff
> --
^ permalink raw reply
* Re: [PATCH 1/2] Teach --recursive to submodule sync
From: Jens Lehmann @ 2012-10-25 22:23 UTC (permalink / raw)
To: Phil Hord; +Cc: git, phil.hord, Jeff King
In-Reply-To: <1351034141-2641-2-git-send-email-hordp@cisco.com>
Am 24.10.2012 01:15, schrieb Phil Hord:
> The submodule sync command was somehow left out when
> --recursive was added to the other submodule commands.
>
> Teach sync to handle the --recursive switch by recursing
> when we're in a submodule we are sync'ing.
>
> Change the report during sync to show submodule-path
> instead of submodule-name to be consistent with the other
> submodule commands and to help recursed paths make sense.
>
> Signed-off-by: Phil Hord <hordp@cisco.com>
This makes perfect sense to me. Two things though:
First it would be nice to initialize orig_flags like all the other
call sites do:
@@ -1003,6 +1003,7 @@ cmd_status()
#
cmd_sync()
{
+ orig_flags=
while test $# -ne 0
do
case "$1" in
> ---
> git-submodule.sh | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/git-submodule.sh b/git-submodule.sh
> index ab6b110..6dd2338 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -11,7 +11,7 @@ USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <r
> or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--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>...]"
> + or: $dashless [--quiet] sync [--recursive] [--] [<path>...]"
> OPTIONS_SPEC=
> . git-sh-setup
> . git-sh-i18n
> @@ -1008,7 +1008,9 @@ cmd_sync()
> case "$1" in
> -q|--quiet)
> GIT_QUIET=1
> - shift
> + ;;
> + --recursive)
> + recursive=1
> ;;
> --)
> shift
> @@ -1021,6 +1023,8 @@ cmd_sync()
> break
> ;;
> esac
> + orig_flags="$orig_flags $(git rev-parse --sq-quote "$1")"
> + shift
> done
> cd_to_toplevel
> module_list "$@" |
> @@ -1051,7 +1055,7 @@ cmd_sync()
>
> if git config "submodule.$name.url" >/dev/null 2>/dev/null
> then
> - say "$(eval_gettext "Synchronizing submodule url for '\$name'")"
> + say "$(eval_gettext "Synchronizing submodule url for '\$prefix\$sm_path'")"
> git config submodule."$name".url "$super_config_url"
>
> if test -e "$sm_path"/.git
> @@ -1061,6 +1065,14 @@ cmd_sync()
> cd "$sm_path"
> remote=$(get_default_remote)
> git config remote."$remote".url "$sub_origin_url"
> +
> + if test -n "$recursive"
> + then
> + (
> + prefix="$prefix$sm_path/"
> + eval cmd_sync "$orig_args"
This should read 'eval cmd_sync "$orig_flags"'. I think you copied that
from cmd_status(), where this is also incorrect, I just sent a patch to
correct that one.
> + )
> + fi
> )
> fi
> fi
>
^ permalink raw reply
* [PATCH] submodule status: properly pass options with --recursive
From: Jens Lehmann @ 2012-10-25 22:20 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Jeff King
When renaming orig_args to orig_flags in 98dbe63d (submodule: only
preserve flags across recursive status/update invocations) the call site
of the recursive cmd_status was forgotten. At that place orig_args is
still passed into the recursion, which is always empty now. This clears
all options when recursing, as that variable is never set.
Fix that by renaming orig_args to orig_flags there too and add a test to
catch that bug.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
I noticed that when reviewing Phil's "Teach --recursive to submodule
sync" patch.
git-submodule.sh | 2 +-
t/t7407-submodule-foreach.sh | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ab6b110..c089d48 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -990,7 +990,7 @@ cmd_status()
prefix="$displaypath/"
clear_local_git_env
cd "$sm_path" &&
- eval cmd_status "$orig_args"
+ eval cmd_status "$orig_flags"
) ||
die "$(eval_gettext "Failed to recurse into submodule path '\$sm_path'")"
fi
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 9b69fe2..eca36b5 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -245,6 +245,14 @@ test_expect_success 'ensure "status --cached --recursive" preserves the --cached
test_cmp expect actual
'
+test_expect_success 'ensure "status --quiet --recursive" preserves the --quiet flag' '
+ (
+ cd clone3 &&
+ git submodule status --quiet --recursive -- nested1 > ../actual
+ ) &&
+ ! test -s actual
+'
+
test_expect_success 'use "git clone --recursive" to checkout all submodules' '
git clone --recursive super clone4 &&
(
--
1.8.0.dirty
^ permalink raw reply related
* Workflow for templates?
From: Josef Wolf @ 2012-10-25 21:15 UTC (permalink / raw)
To: git
Hello everybody,
I am looking for a setup where teplates can be handled easily.
For a better explanation of what I'm trying to achieve, I use the apache
httpd project as an example.
Apache httpd provides an extensively commented httpd.conf template, which
users can use as a starting point for their own customization.
Tha's fine so far. But I'd like this to work in both directions:
Downstream: When the upstream template has new changes, I can merge them into
my local branch. Conflicts will remind me that I have to review my
customization.
Upstream: Within the customized working copy, I implement a new module or
change an existing one (e.g. mod_ssl). While implementing the new feature, I
add/modify my _customized_ template. When I'm happy with the new feature, I'd
like to rewrite the localized customization into something generic and send it
along with the implementation of the new feature to the upstream generic
template. My localized customization should not get lost during the
process, of course.
One more important aspect: since the customized template might contain
confidential information, those bits should have a hard time to propagate to
the upstream repository.
I guess the downstream part can be done by a vendor branch. But I have a hard
time to find a proper workflow for the upstream part.
Any ideas?
^ permalink raw reply
* Re: [PATCH] Fixes handling of --reference argument.
From: Jens Lehmann @ 2012-10-25 21:32 UTC (permalink / raw)
To: W. Trevor King; +Cc: Jeff King, szager, git
In-Reply-To: <20121025104519.GA3816@odin.tremily.us>
Am 25.10.2012 12:45, schrieb W. Trevor King:
> On Thu, Oct 25, 2012 at 04:36:26AM -0400, Jeff King wrote:
>> On Wed, Oct 24, 2012 at 09:52:52PM -0700, szager@google.com wrote:
>>> diff --git a/git-submodule.sh b/git-submodule.sh
>>> index ab6b110..dcceb43 100755
>>> --- a/git-submodule.sh
>>> +++ b/git-submodule.sh
>>> @@ -270,7 +270,6 @@ cmd_add()
>>> ;;
>>> --reference=*)
>>> reference="$1"
>>> - shift
>>> ;;
>>
>> Is that right? We'll unconditionally do a "shift" at the end of the
>> loop. If it were a two-part argument like "--reference foo", the extra
>> shift would make sense, but for "--reference=*", no extra shift should
>> be neccessary. Am I missing something?
>
> Both the patch and Jeff's analysis are right. You only need an
> in-case shift if you consume "$2", or you're on ‘--’ and you're
> breaking before the end-of-case shift.
Right you are. The shift there is wrong, as there is no extra argument
to consume for "--reference=<repo>" (opposed to "--reference <repo>",
also see cmd_update() where this is done right).
So tested and Acked-By me, but me thinks the subject should read:
[PATCH] submodule add: Fix handling of the --reference=<repo> option
and the commit message should begin with:
Doing a shift there is wrong because there is no extra argument
to consume when "--reference=<repo>" is used (note the '=' instead
of a space).
Peff, is it ok for you to squash that in or do you want Stefan to resend?
^ permalink raw reply
* Re: git push tags
From: Drew Northup @ 2012-10-25 21:16 UTC (permalink / raw)
To: Angelo Borsotti; +Cc: git
In-Reply-To: <CAB9Jk9A95YrrtH8ue-CJ6Mqe9Z+3nfo=tjurLZjmecfiMFijvg@mail.gmail.com>
On Thu, Oct 25, 2012 at 3:05 PM, Angelo Borsotti
<angelo.borsotti@gmail.com> wrote:
---At 13:19 on Oct 25, 2012, Drew Northup wrote: [added for clarity]
>>Tags have many uses. Some of those uses are harmed when tags change
> and some aren't. That's a philosophical argument
>
> I agree, but in this case the computer does not provide any means to
> implement the same strategy on tags as it does instead on local
> repositories. Why I must force a change on a tag in the local
> repository and instead I can change it without any forcing in a remote
> one?
Changing the tag in the local repository is a tag modification
operation. Pushing that change to a remote repository DOES NOT execute
"git tag...." in the remote. Plain and simple the two are different
operations.
> Are remote repositories less protected than the local ones? I
> think that to be consistent, the same strategy should be used on all
> repositories, i.e. rejecting changes on tags by default, unless they
> are forced.
So here we come to the core argument. Is sounds to me like you want
changes to remote tags to work differently from push updates to ALL
other references. The required change, if I'm not mistaken, would be
for tags to not permit fast-forward updates while all other references
would be pushed normally. From my brief and un-enlightened look at the
push code I can't see that being as easy as it sounds.
In any case, I think your complaint stems from thinking that "git tag"
is the operation being performed on the remote when in fact it is not.
Given the mayhem that changing this may involve I'm not going to claim
it to be a good idea.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH] Use character class for sed expression instead of \s
From: Torsten Bögershausen @ 2012-10-25 20:09 UTC (permalink / raw)
To: Ben Walton; +Cc: Torsten Bögershausen, Brian Gernhardt, peff, bosch, git
In-Reply-To: <CAP30j15n1hVn6zptDpAfM+Aqc3LnRR4PN6jHTHpTkcjYLgPnjw@mail.gmail.com>
On 10/25/2012 08:08 PM, Ben Walton wrote:
> Hi Torsten,
>
> On Thu, Oct 25, 2012 at 5:28 PM, Torsten Bögershausen <tboegi@web.de> wrote:
>
>> BTW: While we are talking CVS: (I installed a fresh version)
>> cvs --version
>> Concurrent Versions System (CVS) 1.11.23 (client/server)
>
> I have 1.12.13-MirDebian-8 here.
>
>> And t9200 fails:
>> git checkout t9200-git-cvsexportcommit.sh
>> tb@birne:~/projects/git/git.pu/t> ./t9200-git-cvsexportcommit.sh
>> cvs [init aborted]: Cannot initialize repository under existing CVSROOT: `/Users/tb/projects/git/git.pu/t/trash directory.t9200-git-cvsexportcommit'
>> FATAL: Unexpected exit with code 1
>
> I'm not able to reproduce this manually...are you able to make it fail
> this way outside of the test harness?
>
> $ CVSROOT=$PWD/bw
> $ export CVSROOT
> $ mkdir $CVSROOT && cvs init && echo ok
> ok
> $ rm -rf $CVSROOT
> $ cvs init && echo ok
> ok
>
>>> (cvs init || mkdir "$CVSROOT" && cvs init ) &&
>
> If your version of cvs fails the checks above in manual testing, we
> could see if there is a flag that works in all (old and new) versions
> to override the failure if CVSROOT exists. Otherwise, this isn't a
> bad fix, I don't think.
>
> If your version does fail the manual checks, I think it's likely a
> regression that was introduced and later reverted. I don't see those
> strings inside my cvs binary at all...?
>
> HTH.
>
> Thanks
> -Ben
>
Hej Ben,
thanks for looking into that - here some short answers:
a) The manual test (as you describe it) succeeds
b) The test case 9200 failes, and now I know why:
diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh
index b59be9a..d2c3c37 100755
--- a/t/t9200-git-cvsexportcommit.sh
+++ b/t/t9200-git-cvsexportcommit.sh
@@ -19,7 +19,7 @@ then
test_done
fi
-CVSROOT=$PWD/cvsroot
+CVSROOT=$PWD/xx
CVSWORK=$PWD/cvswork
GIT_DIR=$PWD/.git
export CVSROOT CVSWORK GIT_DIR
c) I need to send a patch tomorrow
d) FYI: I compiled cvs from scratch, from a file called cvs-1.11.23.tar.gz
and the code is in cvs-1.11.23/src/mkmodules.c:942
if (root_dir && strcmp (root_dir, current_parsed_root->directory))
error (1, 0,
"Cannot initialize repository under existing CVSROOT: `%s'",
root_dir);
free (root_dir);
/Torsten
^ permalink raw reply related
* Re: git push tags
From: Angelo Borsotti @ 2012-10-25 19:05 UTC (permalink / raw)
To: Drew Northup; +Cc: git
In-Reply-To: <CAM9Z-nkxCOyrtJ8vCF=00vrA_1eFr2-Fk7PXjYEx0HbVt0GPkQ@mail.gmail.com>
Hi Drew,
>
> You specified "-f" (force) and it did exactly what you asked. That is
> fully documented (git help tag).
>
Yes, it is, and I used it to show that there is a need to specify
explicitly the intent to change a tag, that without such an indication
would not be changed.
>Tags have many uses. Some of those uses are harmed when tags change
and some aren't. That's a philosophical argument
I agree, but in this case the computer does not provide any means to
implement the same strategy on tags as it does instead on local
repositories. Why I must force a change on a tag in the local
repository and instead I can change it without any forcing in a remote
one? Are remote repositories less protected than the local ones? I
think that to be consistent, the same strategy should be used on all
repositories, i.e. rejecting changes on tags by default, unless they
are forced.
-Angelo
> --
> -Drew Northup
> --------------------------------------------------------------
> "As opposed to vegetable or mineral error?"
> -John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCHv2] git-pull: Avoid merge-base on detached head
From: Phil Hord @ 2012-10-25 18:50 UTC (permalink / raw)
To: Jeff King; +Cc: git, phil.hord, Junio C Hamano
In-Reply-To: <20121025093441.GH8390@sigill.intra.peff.net>
Jeff King wrote:
> On Tue, Oct 23, 2012 at 04:39:56PM -0400, Phil Hord wrote:
>
>> git pull --rebase does some clever tricks to find the base
>> for $upstream , but it forgets that we may not have any
>> branch at all. When this happens, git merge-base reports its
>> "usage" help in the middle of an otherwise successful
>> rebase operation, because git-merge is called with one too
>> few parameters.
>>
>> Since we do not need the merge-base trick in the case of a
>> detached HEAD, detect this condition and bypass the clever
>> trick and the usage noise.
> Makes sense. I notice there is no test with your patch. It sounds from
> the description like the operation still may succeed, but we just get
> cruft on stderr?
>
Yes, that's correct.
P
^ permalink raw reply
* Re: [PATCH] Use character class for sed expression instead of \s
From: Ben Walton @ 2012-10-25 18:08 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: Brian Gernhardt, peff, bosch, git
In-Reply-To: <5089689A.9070301@web.de>
Hi Torsten,
On Thu, Oct 25, 2012 at 5:28 PM, Torsten Bögershausen <tboegi@web.de> wrote:
> BTW: While we are talking CVS: (I installed a fresh version)
> cvs --version
> Concurrent Versions System (CVS) 1.11.23 (client/server)
I have 1.12.13-MirDebian-8 here.
> And t9200 fails:
> git checkout t9200-git-cvsexportcommit.sh
> tb@birne:~/projects/git/git.pu/t> ./t9200-git-cvsexportcommit.sh
> cvs [init aborted]: Cannot initialize repository under existing CVSROOT: `/Users/tb/projects/git/git.pu/t/trash directory.t9200-git-cvsexportcommit'
> FATAL: Unexpected exit with code 1
I'm not able to reproduce this manually...are you able to make it fail
this way outside of the test harness?
$ CVSROOT=$PWD/bw
$ export CVSROOT
$ mkdir $CVSROOT && cvs init && echo ok
ok
$ rm -rf $CVSROOT
$ cvs init && echo ok
ok
>> (cvs init || mkdir "$CVSROOT" && cvs init ) &&
If your version of cvs fails the checks above in manual testing, we
could see if there is a flag that works in all (old and new) versions
to override the failure if CVSROOT exists. Otherwise, this isn't a
bad fix, I don't think.
If your version does fail the manual checks, I think it's likely a
regression that was introduced and later reverted. I don't see those
strings inside my cvs binary at all...?
HTH.
Thanks
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Take the risk of thinking for yourself. Much more happiness,
truth, beauty and wisdom will come to you that way.
-Christopher Hitchens
---------------------------------------------------------------------------------------------------------------------------
^ permalink raw reply
* [PATCH 2/2] gitk: handle --full-diff correctly
From: Felipe Contreras @ 2012-10-25 17:23 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Paul Mackerras, Felipe Contreras
In-Reply-To: <1351185801-18543-1-git-send-email-felipe.contreras@gmail.com>
Otherwise the files are missing from the diff, and the list of files.
We do this by creating a limitdiffs variable specific for the view which
can be turned of by using --full-diff.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
gitk-git/gitk | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index b79dfdf..4ffabdf 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -155,11 +155,12 @@ proc unmerged_files {files} {
}
proc parseviewargs {n arglist} {
- global vdatemode vmergeonly vflags vdflags vrevs vfiltered vorigargs env
- global worddiff git_version
+ global vdatemode vmergeonly vlimitdiffs vflags vdflags vrevs vfiltered vorigargs env
+ global limitdiffs worddiff git_version
set vdatemode($n) 0
set vmergeonly($n) 0
+ set vlimitdiffs($n) $limitdiffs
set glflags {}
set diffargs {}
set nextisval 0
@@ -187,7 +188,7 @@ proc parseviewargs {n arglist} {
"--no-renames" - "--full-index" - "--binary" - "--abbrev=*" -
"--find-copies-harder" - "-l*" - "--ext-diff" - "--no-ext-diff" -
"--src-prefix=*" - "--dst-prefix=*" - "--no-prefix" -
- "-O*" - "--text" - "--full-diff" - "--ignore-space-at-eol" -
+ "-O*" - "--text" - "--ignore-space-at-eol" -
"--ignore-space-change" - "-U*" - "--unified=*" {
# These request or affect diff output, which we don't want.
# Some could be used to set our defaults for diff display.
@@ -251,6 +252,9 @@ proc parseviewargs {n arglist} {
"--no-replace-objects" {
set env(GIT_NO_REPLACE_OBJECTS) "1"
}
+ "--full-diff" {
+ set vlimitdiffs($n) 0
+ }
"-*" {
# Other flag arguments including -<n>
if {[string is digit -strict [string range $arg 1 end]]} {
@@ -7519,10 +7523,10 @@ proc diffcmd {ids flags} {
}
proc gettreediffs {ids} {
- global treediff treepending limitdiffs vfilelimit curview
+ global treediff treepending vlimitdiffs vfilelimit curview
set cmd [diffcmd $ids {--no-commit-id}]
- if {$limitdiffs && $vfilelimit($curview) ne {}} {
+ if {$vlimitdiffs($curview) && $vfilelimit($curview) ne {}} {
set cmd [concat $cmd -- $vfilelimit($curview)]
}
if {[catch {set gdtf [open $cmd r]}]} return
@@ -7535,7 +7539,7 @@ proc gettreediffs {ids} {
proc gettreediffline {gdtf ids} {
global treediff treediffs treepending diffids diffmergeid
- global cmitmode vfilelimit curview limitdiffs perfile_attrs
+ global cmitmode vfilelimit curview perfile_attrs
set nr 0
set sublist {}
@@ -7613,7 +7617,7 @@ proc getblobdiffs {ids} {
global diffcontext
global ignorespace
global worddiff
- global limitdiffs vfilelimit curview
+ global vlimitdiffs vfilelimit curview
global diffencoding targetline diffnparents
global git_version currdiffsubmod
@@ -7632,7 +7636,7 @@ proc getblobdiffs {ids} {
if {$worddiff ne [mc "Line diff"]} {
append cmd " --word-diff=porcelain"
}
- if {$limitdiffs && $vfilelimit($curview) ne {}} {
+ if {$vlimitdiffs($curview) && $vfilelimit($curview) ne {}} {
set cmd [concat $cmd -- $vfilelimit($curview)]
}
if {[catch {set bdf [open $cmd r]} err]} {
--
1.8.0
^ permalink raw reply related
* [PATCH 1/2] gitk: simplify file filtering
From: Felipe Contreras @ 2012-10-25 17:23 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Paul Mackerras, Felipe Contreras
In-Reply-To: <1351185801-18543-1-git-send-email-felipe.contreras@gmail.com>
git diff is perfectly able to do this with '-- files', no need for
manual filtering.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
gitk-git/gitk | 20 +++++++-------------
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index d93bd99..b79dfdf 100755
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -7519,9 +7519,13 @@ proc diffcmd {ids flags} {
}
proc gettreediffs {ids} {
- global treediff treepending
+ global treediff treepending limitdiffs vfilelimit curview
- if {[catch {set gdtf [open [diffcmd $ids {--no-commit-id}] r]}]} return
+ set cmd [diffcmd $ids {--no-commit-id}]
+ if {$limitdiffs && $vfilelimit($curview) ne {}} {
+ set cmd [concat $cmd -- $vfilelimit($curview)]
+ }
+ if {[catch {set gdtf [open $cmd r]}]} return
set treepending $ids
set treediff {}
@@ -7565,17 +7569,7 @@ proc gettreediffline {gdtf ids} {
return [expr {$nr >= $max? 2: 1}]
}
close $gdtf
- if {$limitdiffs && $vfilelimit($curview) ne {}} {
- set flist {}
- foreach f $treediff {
- if {[path_filter $vfilelimit($curview) $f]} {
- lappend flist $f
- }
- }
- set treediffs($ids) $flist
- } else {
- set treediffs($ids) $treediff
- }
+ set treediffs($ids) $treediff
unset treepending
if {$cmitmode eq "tree" && [llength $diffids] == 1} {
gettree $diffids
--
1.8.0
^ permalink raw reply related
* [PATCH 0/2] gitk: handle --full-diff corectly
From: Felipe Contreras @ 2012-10-25 17:23 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Paul Mackerras, Felipe Contreras
Basically $SUBJECT. See details in the 2nd patch.
Felipe Contreras (2):
gitk: simplify file filtering
gitk: handle --full-diff correctly
gitk-git/gitk | 36 +++++++++++++++++-------------------
1 file changed, 17 insertions(+), 19 deletions(-)
--
1.8.0
^ 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