* Re: [PATCH v7 0/7] coloring test output after traffic signal
From: Jeff King @ 2012-12-21 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adam Spiers
In-Reply-To: <1356059558-23479-1-git-send-email-gitster@pobox.com>
On Thu, Dec 20, 2012 at 07:12:31PM -0800, Junio C Hamano wrote:
> To conclude the bikeshedding discussion we had today, here is what I
> queued by squashing stuff into relevant patches, so that people can
> eyeball the result for the last time.
Thanks, this looks OK to me.
And thank you, Adam, for your patience. Seven iterations of color
bikeshedding is more than should be asked of anyone. :)
-Peff
^ permalink raw reply
* Re: [PATCH v8 0/3] submodule update: add --remote for submodule's upstream changes
From: Heiko Voigt @ 2012-12-21 8:18 UTC (permalink / raw)
To: wking
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <cover.1355932282.git.wking@tremily.us>
Hi,
On Wed, Dec 19, 2012 at 11:03:30AM -0500, wking@tremily.us wrote:
> From: "W. Trevor King" <wking@tremily.us>
>
> Comments on v7 seem to have petered out, so here's v8. Changes since
> v7:
>
> * Series based on gitster/master instead of v1.8.0.
> * In Documentation/config.txt, restored trailing line of
> submodule.<name>.update documentation, which I had accidentally
> removed in v7.
> * In Documentation/git-submodule.txt, make --no-fetch example in the
> --remote description more general, following Phil's suggestion.
> * In git-submodule.sh:
> * Remove accidental "ges" line.
> * Use the submodule's default remote to determine which tracking
> branch to fetch. In v7 I'd been using the superproject's default
> remote.
> * In cmd_add(), use sm_name instead of sm_path to store the --branch
> option (catching up with 73b0898).
Sorry, I was not able to follow the discussion that closely lately but I
like the outcome. For me there is nothing to change or add functionality
wise. Thanks.
Cheers Heiko
^ permalink raw reply
* Re: [PATCH v8 1/3] submodule: add get_submodule_config helper funtion
From: Heiko Voigt @ 2012-12-21 8:20 UTC (permalink / raw)
To: wking
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <3377beb925bc209d90058493b74d174db1b7aa50.1355932282.git.wking@tremily.us>
On Wed, Dec 19, 2012 at 11:03:31AM -0500, wking@tremily.us wrote:
> diff --git a/git-submodule.sh b/git-submodule.sh
> index 2365149..263a60c 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -153,6 +153,32 @@ die_if_unmatched ()
[...]
> +get_submodule_config () {
> + name="$1"
> + option="$2"
> + default="$3"
> + value=$(git config submodule."$name"."$option")
> + if test -z "$value"
> + then
> + value=$(git config -f .gitmodules submodule."$name"."$option")
> + fi
> + printf '%s' "${value:-$default}"
> +}
> +
> +
> +#
Minor nit: For all other functions we only have one newline as
separator.
Cheers Heiko
^ permalink raw reply
* Re: [PATCH v7 2/7] tests: paint known breakages in yellow
From: Stefano Lattarini @ 2012-12-21 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Adam Spiers, Jeff King
In-Reply-To: <1356059558-23479-3-git-send-email-gitster@pobox.com>
On 12/21/2012 04:12 AM, Junio C Hamano wrote:
> From: Adam Spiers <git@adamspiers.org>
>
> Yellow seems a more appropriate color than bold green when
> considering the universal traffic lights coloring scheme, where
> green conveys the impression that everything's OK, and amber that
> something's not quite right.
>
Here are few more details about the behaviour of other testing
tools, in case you want to squash them in the commit message for
future references:
1. Automake (at least up to 1.13) and Autotest (at least up to the
2.69 Autoconf release) use "bold" green for reporting expected
failures.
2. On the other hand, the 'prove' utility (as of TAP::Harness v3.23
and Perl v5.14.2) use yellow (not bold) for the same purpose.
Regards,
Stefano
^ permalink raw reply
* Re: [PATCH v7 0/7] coloring test output after traffic signal
From: Adam Spiers @ 2012-12-21 10:00 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20121221081521.GA22193@sigill.intra.peff.net>
On Fri, Dec 21, 2012 at 8:15 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Dec 20, 2012 at 07:12:31PM -0800, Junio C Hamano wrote:
>> To conclude the bikeshedding discussion we had today, here is what I
>> queued by squashing stuff into relevant patches, so that people can
>> eyeball the result for the last time.
Great, thanks a lot Junio.
> Thanks, this looks OK to me.
To me too.
> And thank you, Adam, for your patience. Seven iterations of color
> bikeshedding is more than should be asked of anyone. :)
;-)
^ permalink raw reply
* Re: Change in cvsps maintainership, abd a --fast-export option
From: Eric S. Raymond @ 2012-12-21 10:44 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git
In-Reply-To: <50D4199C.6000002@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu>:
> In 2009 I added tests demonstrating some of the erroneous behavior of
> git-cvsimport. The failing tests in t9601-t9603 are concrete examples
> of the problems mentioned in the manpage.
Thanks, that will be extremely useful. One of the things I'm putting effort
into is building a good test suite for the tool; I may well be able to adapt
your tests directly.
>
> If you haven't yet seen it, there is a writeup of the algorithm used by
> cvs2git to infer the history of a CVS repository [1]. If your goal is
> to make cvsps more robust, you might want to consider the ideas
> described there.
I shall do so. Their design ideas may well be interesting, even though I
don't trust their code. I've seem cvs2svn drop far too many weird artifacts
and just plain broken commits in the back history of Subversion repositories.
I don't know if this is due to design problems, implementation bugs, or both.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH v8 1/3] submodule: add get_submodule_config helper funtion
From: W. Trevor King @ 2012-12-21 11:04 UTC (permalink / raw)
To: Heiko Voigt
Cc: Git, Junio C Hamano, Jeff King, Phil Hord, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121221082033.GB560@book.hvoigt.net>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
On Fri, Dec 21, 2012 at 09:20:33AM +0100, Heiko Voigt wrote:
> On Wed, Dec 19, 2012 at 11:03:31AM -0500, wking@tremily.us wrote:
> > diff --git a/git-submodule.sh b/git-submodule.sh
> > index 2365149..263a60c 100755
> > --- a/git-submodule.sh
> > +++ b/git-submodule.sh
> > @@ -153,6 +153,32 @@ die_if_unmatched ()
> [...]
> > +get_submodule_config () {
> > + name="$1"
> > + option="$2"
> > + default="$3"
> > + value=$(git config submodule."$name"."$option")
> > + if test -z "$value"
> > + then
> > + value=$(git config -f .gitmodules submodule."$name"."$option")
> > + fi
> > + printf '%s' "${value:-$default}"
> > +}
> > +
> > +
> > +#
>
> Minor nit: For all other functions we only have one newline as
> separator.
I'm fine rerolling this, or Junio can make the change on my behalf, or
it can be left as is ;).
Cheers,
Trevor
--
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: Opera release Git-splitter, a sub-modularizing tool for Git
From: Michael J Gruber @ 2012-12-21 12:23 UTC (permalink / raw)
To: Yngve N. Pettersen (Developer Opera Software ASA); +Cc: git
In-Reply-To: <op.wpiovoj5qrq7tp@acorna.invalid.invalid>
Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
18.12.2012 15:51:
> Hello all,
>
> Today Opera Software released the "Git-splitter", a small tool for
> sub-modularizing code in a git repo, with complete commit history, under
> the Apache 2.0 license.
>
> It's functionality is similar to "git-subtree", but also include a command
> for reversing the process.
Is there something keeping you technically from adding a join command to
git-subtree?
> The code is hosted on GitHub:
> <https://github.com/operasoftware/git-splitter>
>
> We have announced the release as part of another announcement of released
> code at the Opera Security Group home page:
> <http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
>
^ permalink raw reply
* Re: [PATCH] builtin/clean.c: Fix some sparse warnings
From: Zoltan Klinger @ 2012-12-21 12:31 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <50D35A13.9080605@ramsay1.demon.co.uk>
Thanks, Ramsay. I am rewriting the whole patch to do things a better
way (as kindly suggested by Junio). So the print_filtered() function
is going to disappear, but thanks for pointing out the problems with
the existing code.
Cheers,
Zoltan
On 21 December 2012 05:33, Ramsay Jones <ramsay@ramsay1.demon.co.uk> wrote:
>
> Sparse issues two "Using plain integer as NULL pointer" warnings
> (lines 41 and 47).
>
> The first warning relates to the initializer expression in the
> declaration for the 'char *dir' variable. In order to suppress
> the warning, we simply replace the zero initializer with NULL.
>
> The second warning relates to an expression, as part of an if
> conditional, using the equality operator to compare the 'dir'
> variable to zero. In order to suppress the warning, we replace
> the 'dir == 0' expression with the more idiomatic '!dir'.
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
>
> Hi Zoltan,
>
> If you have already updated your patch and made this redundant
> (it's been a few days since I read the list or fetched git.git),
> please ignore this. Otherwise, could you please squash this into
> the new version of commit 16e4033e6 ("git-clean: Display more
> accurate delete messages", 17-12-2012).
>
> [BTW, in the same conditional expression you have an strncmp()
> call which doesn't quite follow the style/conventions of the
> existing code.]
>
> Thanks!
>
> ATB,
> Ramsay Jones
>
> builtin/clean.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/clean.c b/builtin/clean.c
> index 1c25a75..0c603c8 100644
> --- a/builtin/clean.c
> +++ b/builtin/clean.c
> @@ -38,13 +38,13 @@ static void print_filtered(const char *msg, struct string_list *lst)
> {
> int i;
> char *name;
> - char *dir = 0;
> + char *dir = NULL;
>
> sort_string_list(lst);
>
> for (i = 0; i < lst->nr; i++) {
> name = lst->items[i].string;
> - if (dir == 0 || strncmp(name, dir, strlen(dir)) != 0)
> + if (!dir || strncmp(name, dir, strlen(dir)) != 0)
> printf("%s %s\n", msg, name);
> if (name[strlen(name) - 1] == '/')
> dir = name;
> --
> 1.8.0
>
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Yngve Nysaeter Pettersen @ 2012-12-21 12:43 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <50D454D2.5030403@drmicha.warpmail.net>
Hi,
On Fri, 21 Dec 2012 13:23:46 +0100, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
> 18.12.2012 15:51:
>> Hello all,
>>
>> Today Opera Software released the "Git-splitter", a small tool for
>> sub-modularizing code in a git repo, with complete commit history, under
>> the Apache 2.0 license.
>>
>> It's functionality is similar to "git-subtree", but also include a
>> command
>> for reversing the process.
>
> Is there something keeping you technically from adding a join command to
> git-subtree?
Probably not, but within the process I was working I did not want to merge
the branch with the recreated history for that path into the existing
codebase (I don't like duplicate histories) so I used rebasing to move the
new commits over, instead, and therefore did not need a join command.
Feel free to add a join command, if you want one.
>> The code is hosted on GitHub:
>> <https://github.com/operasoftware/git-splitter>
>>
>> We have announced the release as part of another announcement of
>> released
>> code at the Opera Security Group home page:
>> <http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
>>
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 96 90 41 51 Fax: +47 23 69 24 01
********************************************************************
^ permalink raw reply
* Re: [BUG] Cannot push some grafted branches
From: Michael J Gruber @ 2012-12-21 12:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Yann Dirson, Andreas Schwab, Christian Couder,
git list, Jeff King
In-Reply-To: <7vvcbx956f.fsf@alter.siamese.dyndns.org>
While replace refs are much more general than grafts, it seems the two
main uses are:
- grafts (change the recorded parents for a commit)
- svn cleanup (convert tagging commits into tag objects)
The latter one being quite a special case already.
The script below has helped me move from grafts to replace objects.
While not being super clean, something like it may be fit for contrib.
I think we ought to help John Doe get along with parents, while we can
safely leave most more advanced operations to people who know how to
edit a raw object file. Putting that facility into "git-commit" seems to
be too encouraging, though - people would use replace when they should
use amend or rebase-i. I'd prefer a special git-replace mode (be it
"--graft" or "--graft-commit") which does just what my script does. We
could add things like "--commit-tag" later, a full blown
"object-factory" seems like overkill.
Michael
--->%---
#!/bin/sh
die () {
echo "$@"
rm -f "$commitfile"
exit 1
}
warn () {
echo "$@"
}
test $# -gt 0 || die "Usage: $0 <commit> [<parent>]*"
for commit
do
git rev-parse --verify -q "$commit" >/dev/null || die "Cannot parse
$commit."
test x$(git cat-file -t $commit) == "xcommit" || die "$commit is no
commit."
done
commit="$1"
shift
commitfile=$(mktemp)
git cat-file commit "$commit" | while read a b
do
if test "$a" != "parent"
then
echo $a $b
fi
if test "$a" == "tree"
then
for parent
do
echo "parent $(git rev-parse $parent)"
done
fi
done >$commitfile
hash=$(git hash-object -t commit -w "$commitfile") || die "Cannot create
commit object."
git replace "$commit" $hash
rm -f $commitfile
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Michael J Gruber @ 2012-12-21 13:49 UTC (permalink / raw)
To: Yngve Nysaeter Pettersen; +Cc: git
In-Reply-To: <op.wpn2xz07vqd7e2@damia.oslo.osa>
Yngve Nysaeter Pettersen venit, vidit, dixit 21.12.2012 13:43:
> Hi,
>
> On Fri, 21 Dec 2012 13:23:46 +0100, Michael J Gruber
> <git@drmicha.warpmail.net> wrote:
>
>> Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
>> 18.12.2012 15:51:
>>> Hello all,
>>>
>>> Today Opera Software released the "Git-splitter", a small tool for
>>> sub-modularizing code in a git repo, with complete commit history, under
>>> the Apache 2.0 license.
>>>
>>> It's functionality is similar to "git-subtree", but also include a
>>> command
>>> for reversing the process.
>>
>> Is there something keeping you technically from adding a join command to
>> git-subtree?
>
> Probably not, but within the process I was working I did not want to merge
> the branch with the recreated history for that path into the existing
> codebase (I don't like duplicate histories) so I used rebasing to move the
> new commits over, instead, and therefore did not need a join command.
>
> Feel free to add a join command, if you want one.
Im sorry, but that was a total misunderstanding. You said git-splitter
is like git-subtree but adds a command for reversing the process. My
question was: What kept you from adding that to git-subtree (rather than
redoing stiff that git-subtree does)?
I just assumed that reversing the process of splitting must be joining.
It may very well be that git-splitter does things differently, i.e. that
there are more differences than just added functionality (compared to
git-subtree), but that is not clear from the announcement.
>>> The code is hosted on GitHub:
>>> <https://github.com/operasoftware/git-splitter>
>>>
>>> We have announced the release as part of another announcement of
>>> released
>>> code at the Opera Security Group home page:
>>> <http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
>>>
>
>
^ permalink raw reply
* Re: Noob Question
From: W T Riker @ 2012-12-21 13:27 UTC (permalink / raw)
To: git@vger.kernel.org
In-Reply-To: <CAH5451kq8XwPTez0Jhst+rVCo=EteW7OMH4wr2a1rCXTW_f0jQ@mail.gmail.com>
Hi Andrew,
Thank you for a great explanation. It clears up a number of things but
also creates some new questions. However, armed with this I am going to
run through the documentation again and perhaps it will make more sense
to me. One basic question, since I don't make changes from the Linux
side, only builds, do I need to install anything git related on that
machine?
On 12/20/2012 8:43 PM, Andrew Ardill wrote:
> Hi!
>
> On 21 December 2012 12:07, awingnut <wtriker.ffe@gmail.com> wrote:
>> My main questions center around the git repository and accessing it.
> The main thing you need to know is that you can work on your code base
> in the *exact* same way while using git. You don't *have* to change
> anything about how you work, as git's primary purpose is to store
> snapshots of your work so that you have a history of what has changed.
>
> That being said, you can (and maybe should) change how you work to
> take into account the power of git. Most of what you do will stay the
> same, however.
>
>> 1) Should I install git on Linux or Windows or does it matter?
> Install git wherever you need to access the code. From the sounds of
> it you will want git on both machines, as you are working on windows
> and but keeping the code on the linux shared drive. When working on
> the windows machine you will use a windows copy of git to manipulate
> the workspace, though I'm not sure if there are any gotchas with the
> interaction with a linux shared drive.
>
> If you want to manipulate the repository from the linux machine you
> will need git on it as well.
>
> Unless you're using a git server, manipulating the repository is a
> local action and so is performed by the client. That is, when working
> on windows use the windows client, if you also work on the linux
> machine then you will need a client there as well.
>
>> 2) How will my build scripts access the source? Will it be the same as
>> now (my scripts 'cd' to the Eclipse project directory and run there) or
>> do I need to add a wrapper to my script to check out the entire source
>> for the builds?
> It's the same as now. Git uses the concept of a 'work tree' to talk
> about the actual files you are working on now. The work tree
> corresponds exactly to your current project files. When you create a
> git repository you gain the ability to store snapshots of this working
> tree into the 'object store', as well as metadata about the snapshots,
> so that you can restore that snapshot later.
>
> Your actual files keep their current layout and format, until you change them.
>
>> 3) How do I move my current Eclipse project into git after I create the
>> empty repository? I can only find info on how to import git into Eclipse
>> not the other way around.
> You have two options. Create the git repository in the same location
> as your Eclipse project. Navigate to the project folder using git bash
> and do a 'git init' inside it; voila! you now have a git repository.
> You can choose to create a 'remote' repository somewhere to store a
> backup of your code as well, but this _still_ requires you to init a
> local repository to backup.
>
> The other option is to create a blank repository somewhere (anywhere)
> and then tell that repository to use your Eclipse project as its
> working tree. The benefit to doing this is being able to keep your
> snapshots and metadata in a different location to your working
> directory (say keep the snapshots on a local windows drive while your
> working directory is on the linux share). Unless you shouldn't or
> aren't able to create the repository within the Eclipse project, I
> would recommend against this.
>
>> 4) Do I need to checkout the entire project from Eclipse to modify and
>> test it or only the classes I want to change? Does the plugin get the
>> others as needed when I run the app within Eclipse for testing?
> Not sure exactly what you are asking here, but in general people will
> 'clone' an entire repository including all its history. If you want to
> update only certain files that is fine, but the commit object stores
> the state of the entire tree of files. Note that a commit object does
> _not_ store the difference between two snapshots, but stores the
> entire state of the files. You can grab a file from a given snapshot
> and test that along side files from a second snapshot, but if you
> wanted to commit the resulting tree to the repository it would store a
> third snapshot containing the exact state of all files.
>
> Hopefully that clears it up for you?
>
> Regards,
>
> Andrew Ardill
>
^ permalink raw reply
* recommendation for patch maintenance
From: Manlio Perillo @ 2012-12-21 14:45 UTC (permalink / raw)
To: git
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
I would like to have advices about some possible workflows to use when
maintaining a patch, that can evolve over the time (fixing bugs, and
applying advices from reviewers).
In my case I have a single commit to maintain.
The workflow I use now is this:
1) create a topic branch, e.g. mp/complete-path
2) write code
3) commit
4) format-patch --output=mp/complete-patch master
5) review the patch
6) send-email
when I need to update the patch:
1) modify code
2) commit --amend
3) format-patch --subject-prefix="PATCH v<n>" \
--output=mp/complete-patch master
4) edit patch to add a list of what was changed
5) review the patch
6) send-email
This is far from ideal, since all my local changes are lost.
Another problem is that when I found some trivial error in 5), I need to
call format-patch again, loosing the "what's changed list".
A possible solution is to:
1) create a "public" topic branch, e.g. mp/complete-patch
2) create the associated "private" topic branch, e.g.
mp/complete-patch/private
...
Changes are committed to the private branch.
When I need to update the patch:
1) update code
2) commit new changes; the commit message will contain the
"what's changed" list to be used for the new version of the patch
3) checkout <public branch>
4) merge --squash <private branch>
Now I have my full history, and the "what's changed list" is saved in
the private commits.
(not tested)
What is the workflow you usually use?
Thanks Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDUde4ACgkQscQJ24LbaUSqOwCfZON5f9mdAYkvACim802JGFhP
5W8An1Y7WXgsH/Q/p1/0jVMo1dJ3HwwO
=Xydn
-----END PGP SIGNATURE-----
^ permalink raw reply
* Installation Plan
From: Dennis Putnam @ 2012-12-21 14:43 UTC (permalink / raw)
To: git@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1543 bytes --]
After re-reading the git documentation and with Andrew's input I have
changed my thinking on how to set this up and want a central
repository. If I understand correctly, I am doing builds while I am
developing new code so I need to clone my repository for Eclipse (I'm
assuming the git plugin supports all this). Before I go to the trouble
of setting it up please correct where my thinking is flawed or where I
may run into gotchas.
1) Install git on Linux.
2) Copy existing Eclipse project to a new directory to become the
central repository.
3) git init in that new directory (I think I then do a git add and git
commit).
4) Modify build scripts to build from that directory (I am guessing I
need to git ignore the javac generated binary directory).
5) Install git plugin on Windows version of Eclipse. (Do I need git on
Windows or is the plugin sufficient?)
6) Configure plugin for remote git, if necessary?
7) Clone new repository for development and testing on Windows. (Do I
need the shared drive any more?)
8) When a new version is ready for release, push commit to remote
repository after which builds will use new code (I'm assuming the file
copies happen automagically).
Am I over simplifying things? I also think that this will open the door
for collaborators in the event I need them with no changes to the way I
work. I should note that builds are done on demand so is there a way to
detect when a push is occurring and have the build script wait for
completion and I suppose vise-versa? Thanks.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Yngve Nysaeter Pettersen @ 2012-12-21 15:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <50D468E6.2090900@drmicha.warpmail.net>
On Fri, 21 Dec 2012 14:49:26 +0100, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Yngve Nysaeter Pettersen venit, vidit, dixit 21.12.2012 13:43:
>> Hi,
>>
>> On Fri, 21 Dec 2012 13:23:46 +0100, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>
>>> Yngve N. Pettersen (Developer Opera Software ASA) venit, vidit, dixit
>>> 18.12.2012 15:51:
>>>> Hello all,
>>>>
>>>> Today Opera Software released the "Git-splitter", a small tool for
>>>> sub-modularizing code in a git repo, with complete commit history,
>>>> under
>>>> the Apache 2.0 license.
>>>>
>>>> It's functionality is similar to "git-subtree", but also include a
>>>> command
>>>> for reversing the process.
>>>
>>> Is there something keeping you technically from adding a join command
>>> to
>>> git-subtree?
>>
>> Probably not, but within the process I was working I did not want to
>> merge
>> the branch with the recreated history for that path into the existing
>> codebase (I don't like duplicate histories) so I used rebasing to move
>> the
>> new commits over, instead, and therefore did not need a join command.
>>
>> Feel free to add a join command, if you want one.
>
> Im sorry, but that was a total misunderstanding. You said git-splitter
> is like git-subtree but adds a command for reversing the process. My
> question was: What kept you from adding that to git-subtree (rather than
> redoing stiff that git-subtree does)?
>
> I just assumed that reversing the process of splitting must be joining.
>
> It may very well be that git-splitter does things differently, i.e. that
> there are more differences than just added functionality (compared to
> git-subtree), but that is not clear from the announcement.
The split command will create a new repository for all files foo in a
folder (path/foo) and their commit history.
The replant command reverses that process, re-adding the path prefix for
each file. It may be possible to extend that process into one that
automatically reintegrates the new commits in the original history, but I
never had time to complete that work.
I did originally add the "replant" functionality into my version of the
git-subtree script, but given the number of commits in the original
repository, git-subtree turned out to be inefficient, due to the use of
temporary files (tens of thousands of files IIRC).
Those problems led to my development of git-splitter in Python (bypassing
the problem of temporary files), but just including the functionality I
needed, join was not one of those functions.
>>>> The code is hosted on GitHub:
>>>> <https://github.com/operasoftware/git-splitter>
>>>>
>>>> We have announced the release as part of another announcement of
>>>> released
>>>> code at the Opera Security Group home page:
>>>> <http://my.opera.com/securitygroup/blog/2012/12/18/tls-prober-source-released-under-apache-2-0-license>
>>>>
>>
>>
--
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer Email: yngve@opera.com
Opera Software ASA http://www.opera.com/
Phone: +47 96 90 41 51 Fax: +47 23 69 24 01
********************************************************************
^ permalink raw reply
* git diff --ignore-space-at-eol issue
From: John Moon @ 2012-12-21 15:04 UTC (permalink / raw)
To: git
Hi all,
The --ignore-space-at-eol option is ignored when used in conjunction
with --name-status.
It works fine otherwise.
$ git init
Initialized empty Git repository in /tmp/test/.git/
$ printf "hello\r\n" > test.txt
$git -c core.autocrlf=false add test.txt
$git commit -m.
[master (root-commit) 5c4ce92] .
1 file changed, 1 insertion(+)
create mode 100644 test.txt
$ printf "hello" > test.txt
$ git diff --ignore-space-at-eol test.txt
$ git diff --stat --ignore-space-at-eol test.txt
0 files changed
$ git diff --name-status --ignore-space-at-eol test.txt
M test.txt
Thanks.
^ permalink raw reply
* Re: [PATCH v7 2/7] tests: paint known breakages in yellow
From: Junio C Hamano @ 2012-12-21 15:46 UTC (permalink / raw)
To: Stefano Lattarini; +Cc: git, Adam Spiers, Jeff King
In-Reply-To: <50D4230F.9080502@gmail.com>
Stefano Lattarini <stefano.lattarini@gmail.com> writes:
> On 12/21/2012 04:12 AM, Junio C Hamano wrote:
>> From: Adam Spiers <git@adamspiers.org>
>>
>> Yellow seems a more appropriate color than bold green when
>> considering the universal traffic lights coloring scheme, where
>> green conveys the impression that everything's OK, and amber that
>> something's not quite right.
>>
> Here are few more details about the behaviour of other testing
> tools, in case you want to squash them in the commit message for
> future references:
>
> 1. Automake (at least up to 1.13) and Autotest (at least up to the
> 2.69 Autoconf release) use "bold" green for reporting expected
> failures.
>
> 2. On the other hand, the 'prove' utility (as of TAP::Harness v3.23
> and Perl v5.14.2) use yellow (not bold) for the same purpose.
Nice to know, thanks.
I re-read the above three times, trying to see how to add it to the
log message, but having hard time phrasing it.
The only thing the additional knowledge adds seems to be to give
rationale for the old choice of "bold green"---it was not chosen
from thin-air but can be viewed as following the automake/autotest
scheme, and other systems cannot agree on what color to pick for
this purpose.
I do not see a need to justify why we chose differently from
automake/autotest; we could say something like:
Yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where
green conveys the impression that everything's OK, and amber that
something's not quite right. This is in line with what 'prove'
uses, but different from 'automake/autotest' do.
but we are not in the business of choosing which is more correct
between prove and automake/autotest, and I do not see how it adds
much value to tell readers that color choices are not universally
agreed upon across various test software suites---that's kind of
known, isn't it?
So...
^ permalink raw reply
* Re: Opera release Git-splitter, a sub-modularizing tool for Git
From: Matthieu Moy @ 2012-12-21 15:49 UTC (permalink / raw)
To: Yngve Nysaeter Pettersen; +Cc: Michael J Gruber, git
In-Reply-To: <op.wpn9d6xuvqd7e2@damia.oslo.osa>
"Yngve Nysaeter Pettersen" <yngve@opera.com> writes:
> The split command will create a new repository for all files foo in a
> folder (path/foo) and their commit history.
>
> The replant command reverses that process, re-adding the path prefix
> for each file. It may be possible to extend that process into one that
> automatically reintegrates the new commits in the original history,
> but I never had time to complete that work.
>
> I did originally add the "replant" functionality into my version of
> the git-subtree script, but given the number of commits in the
> original repository, git-subtree turned out to be inefficient, due to
> the use of temporary files (tens of thousands of files IIRC).
>
> Those problems led to my development of git-splitter in Python
> (bypassing the problem of temporary files), but just including the
> functionality I needed, join was not one of those functions.
That still doesn't answer the question: why did you need to write a new
tool instead of extending git-subtree?
If one doesn't use "replant", is your tool different from git-subtree?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Junio C Hamano @ 2012-12-21 15:58 UTC (permalink / raw)
To: git
When you want to redo a branch forked from another branch (say
'master'), a handy way to work is to first detach HEAD at the
previous fork point:
$ git checkout master...branch
and build an updated history on top of this state. Once you are
done, you can verify your results with commands like:
$ git show-branch branch HEAD
$ git diff branch HEAD
and then finish it off with:
$ git checkout -B branch
This way, you can keep the history of the previous round on 'branch'
until you are done with the new history you build on the detached
HEAD state, and if you do not like updated history, you can reset
back to branch@{1} easily.
But you may not even need to have such an easy access to the old
history and just want to restart, with:
$ git checkout -B branch <old fork point>
Unfortunately, master...branch syntax does not seem to work for
specifying the "old fork point" for this purpose, even though we
have special case to support the syntax in the "detach at that
commit" case (the first command line example in this message).
Perhaps we should teach the <start-point> parser this syntax as
well?
^ permalink raw reply
* Re: [PATCH] Python scripts audited for minimum compatible version and checks added.
From: Manlio Perillo @ 2012-12-21 15:58 UTC (permalink / raw)
To: Eric S. Raymond; +Cc: git
In-Reply-To: <20121220141855.05DAA44105@snark.thyrsus.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Il 20/12/2012 15:13, Eric S. Raymond ha scritto:
> Signed-off-by: Eric S. Raymond <esr@thyrsus.com>
> ---
Just my two cents.
Isn't it better to have some core Python support inside a "python/"
directory in the git source tree (e.g. e simple python/git.py), and have
*all* python code import that module?
Then you can impose a reasonable version limitation (e.g. Python >= 2.5)
inside that module (and/or inside its setup.py file).
Another advantage is that the python/git.py module can contain some very
base support for interfacing git plumbing commands, instead of having
all internal (and external) modules reinventing the wheel.
I'm writing an external command for Git, and I do plan to write such a
package, so that I don't have to reimplement all the base support in my
command source code.
Regards Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlDUhzoACgkQscQJ24LbaUQFuQCfb6QgkJHdxQSEB7nLXMN8TSmI
6/IAn3svylllaIBQfZKf0lEzNBtZJQMK
=Ar20
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v2] mergetools/p4merge: Honor $TMPDIR for the /dev/null placeholder
From: Junio C Hamano @ 2012-12-21 16:08 UTC (permalink / raw)
To: David Aguilar; +Cc: Jeremy Morton, git
In-Reply-To: <1356073023-15376-1-git-send-email-davvid@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Use $TMPDIR when creating the /dev/null placeholder for p4merge.
> This keeps it out of the current directory.
The usual $REMOTE "this is theirs" and $LOCAL "this is ours" are
still created in the current directory, no? It is unclear why this
"this side does not exist" case wants to be outside of the current
directory in the first place.
In other words, "This keeps it out of the current directory" only
explains what this patch changes, without explaining why it is a
good thing to do in the first place.
> +create_empty_file () {
> + empty_file="${TMPDIR:-/tmp}/git-difftool-p4merge-empty-file.$$"
> + >"$empty_file"
> +
> + printf "$empty_file"
> +}
Assuming that it makes sense to create only the "this side doe not
exist, and here is a placeholder empty file" in $TMPDIR, I think
this is probably sufficient.
By the way, who is going to remove this temporary file once the
command is done?
^ permalink raw reply
* Right way to import a repo
From: Florian Lindner @ 2012-12-21 16:11 UTC (permalink / raw)
To: git
Hello,
I have two repositories. tools and flof. I want to merge flof into tools (and
flof will be deleted after that) while keeping history intact. Of course I've
googled that and found a number of different solution which all seem to be
pretty komplex, so I just tried it myself. It seems to work.... are there any
problems with my approach?
~/software/tools.test (git)-[master] % git remote add fl ~/flof
~/software/tools.test (git)-[master] % git fetch fl
warning: no common commits
remote: Counting objects: 475, done.
remote: Compressing objects: 100% (460/460), done.
remote: Total 475 (delta 251), reused 0 (delta 0)
Receiving objects: 100% (475/475), 190.40 KiB, done.
Resolving deltas: 100% (251/251), done.
From /home/florian/flof
* [new branch] master -> fl/master
* [new branch] v2-rewrite -> fl/v2-rewrite
/software/tools.test (git)-[master] % git checkout -b import fl/master
Branch import set up to track remote branch master from fl.
Switched to a new branch 'import'
Doing some mkdir und git mv for reorganisation.
~/software/tools.test/flof (git)-[import] % git commit -m "Reorganize flof."
[import a00ab54] Reorganize flof.
152 files changed, 0 insertions(+), 0 deletions(-)
rename {doc => flof/doc}/common.rst (100%)
rename {doc => flof/doc}/conf.py (100%)
[...]
~/software/tools.test/flof (git)-[import] % git checkout master
Switched to branch 'master'
~/software/tools.test (git)-[master] % git merge import
Auto-merging .gitignore
CONFLICT (add/add): Merge conflict in .gitignore
Automatic merge failed; fix conflicts and then commit the result.
Resolving the conflict.
~/software/tools.test (git)-[master|merge] % git add .gitignore
~/software/tools.test (git)-[master|merge] % git commit -m "Merged flof."
[master b8c85be] Merged flof.
~/software/tools.test (git)-[master] % git remote rm fl
Are thery any problems with this procedure? The history seems to intact. I'm
quite unsure since still being a git beginner.
Thanks,
Florian
^ permalink raw reply
* [PATCH v4] git-completion.bash: add support for path completion
From: Manlio Perillo @ 2012-12-21 16:54 UTC (permalink / raw)
To: git; +Cc: szeder, felipe.contreras, Manlio Perillo
The git-completion.bash script did not implemented full, git aware,
support to complete paths, for git commands that operate on files within
the current working directory or the index.
As an example:
git add <TAB>
will suggest all files in the current working directory, including
ignored files and files that have not been modified.
Support path completion, for git commands where the non-option arguments
always refer to paths within the current working directory or the index,
as the follow:
* the path completion for the "git rm" and "git ls-files"
commands will suggest all cached files.
* the path completion for the "git add" command will suggest all
untracked and modified files. Ignored files are excluded.
* the path completion for the "git clean" command will suggest all
untracked files. Ignored files are excluded.
* the path completion for the "git mv" command will suggest all cached
files when expanding the first argument, and all untracked and cached
files for subsequent arguments. In the latter case, empty directories
are included and ignored files are excluded.
* the path completion for the "git commit" command will suggest all
files that have been modified from the HEAD, if HEAD exists, otherwise
it will suggest all cached files.
For all affected commands, completion will always stop at directory
boundary. Only standard ignored files are excluded, using the
--exclude-standard option of the ls-files command.
Signed-off-by: Manlio Perillo <manlio.perillo@gmail.com>
---
Changes from version 3:
* Fixed quoting issues
* Fixed default parameters handling
* Fixed a typo in the commit message: the affected command was ls-files,
not ls-tree.
* Fixed incorrect behavior when expanding a path in "git commit"
command, for a newly created repository (when HEAD does not
exists).
* Make sure to always execute git commands with stderr redirected to
/dev/null.
* Improved path completion for the git mv command.
This required a small refactorization of the __git_index_files
function, in order to support multiple options for ls-files.
contrib/completion/git-completion.bash | 140 +++++++++++++++++++++++++++++----
1 file changed, 124 insertions(+), 16 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 0b77eb1..c8c6464 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
# *) .git/remotes file names
# *) git 'subcommands'
# *) tree paths within 'ref:path/to/file' expressions
+# *) file paths within current working directory and index
# *) common --long-options
#
# To use these routines:
@@ -233,6 +234,62 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P "${2-}" -S "${4- }" -W "$1" -- "${3-$cur}"))
}
+# Process path list returned by "ls-files" and "diff-index --name-only"
+# commands, in order to list only file names relative to a specified
+# directory, and append a slash to directory names.
+# It accepts 1 optional argument: a directory path. The path must have
+# a trailing slash.
+__git_index_file_list_filter ()
+{
+ local pfx="${1-}" offset=${#pfx} path
+
+ while read -r path; do
+ path="${path:$offset}"
+
+ case "$path" in
+ ?*/*) echo "${path%%/*}/" ;;
+ *) echo $path ;;
+ esac
+ done
+}
+
+# __git_index_files accepts 1 or 2 arguments:
+# 1: Options to pass to ls-files (required).
+# Supported options are --cached, --modified, --deleted, --others,
+# and --directory.
+# 2: A directory path (optional).
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed. Path must have a trailing
+# slash.
+__git_index_files ()
+{
+ local dir="$(__gitdir)"
+
+ if [ -d "$dir" ]; then
+ # NOTE: $1 is not quoted in order to support multiple options
+ git --git-dir="$dir" ls-files --exclude-standard $1 ${2+"$2"} 2>/dev/null |
+ __git_index_file_list_filter ${2+"$2"} |
+ uniq
+ fi
+}
+
+# __git_diff_index_files accepts 1 or 2 arguments:
+# 1) The id of a tree object.
+# 2) A directory path (optional).
+# If provided, only files within the specified directory are listed.
+# Sub directories are never recursed. Path must have a trailing
+# slash.
+__git_diff_index_files ()
+{
+ local dir="$(__gitdir)"
+
+ if [ -d "$dir" ]; then
+ git --git-dir="$dir" diff-index --name-only "$1" 2>/dev/null |
+ __git_index_file_list_filter ${2+"$2"} |
+ uniq
+ fi
+}
+
__git_heads ()
{
local dir="$(__gitdir)"
@@ -430,6 +487,46 @@ __git_complete_revlist_file ()
}
+# __git_complete_index_file requires 1 argument: the options to pass to
+# ls-file
+__git_complete_index_file ()
+{
+ local pfx cur_="$cur"
+
+ case "$cur_" in
+ ?*/*)
+ pfx="${cur_%/*}"
+ cur_="${cur_##*/}"
+ pfx="${pfx}/"
+
+ __gitcomp_nl "$(__git_index_files "$1" "$pfx")" "$pfx" "$cur_" ""
+ ;;
+ *)
+ __gitcomp_nl "$(__git_index_files "$1")" "" "$cur_" ""
+ ;;
+ esac
+}
+
+# __git_complete_diff_index_file requires 1 argument: the id of a tree
+# object
+__git_complete_diff_index_file ()
+{
+ local pfx cur_="$cur"
+
+ case "$cur_" in
+ ?*/*)
+ pfx="${cur_%/*}"
+ cur_="${cur_##*/}"
+ pfx="${pfx}/"
+
+ __gitcomp_nl "$(__git_diff_index_files "$1" "$pfx")" "$pfx" "$cur_" ""
+ ;;
+ *)
+ __gitcomp_nl "$(__git_diff_index_files "$1")" "" "$cur_" ""
+ ;;
+ esac
+}
+
__git_complete_file ()
{
__git_complete_revlist_file
@@ -770,8 +867,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "
@@ -780,7 +875,9 @@ _git_add ()
"
return
esac
- COMPREPLY=()
+
+ # XXX should we check for --update and --all options ?
+ __git_complete_index_file "--others --modified"
}
_git_archive ()
@@ -930,15 +1027,15 @@ _git_cherry_pick ()
_git_clean ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--dry-run --quiet"
return
;;
esac
- COMPREPLY=()
+
+ # XXX should we check for -x option ?
+ __git_complete_index_file "--others"
}
_git_clone ()
@@ -969,8 +1066,6 @@ _git_clone ()
_git_commit ()
{
- __git_has_doubledash && return
-
case "$cur" in
--cleanup=*)
__gitcomp "default strip verbatim whitespace
@@ -998,7 +1093,13 @@ _git_commit ()
"
return
esac
- COMPREPLY=()
+
+ if git rev-parse --verify --quiet HEAD 1>/dev/null; then
+ __git_complete_diff_index_file "HEAD"
+ else
+ # This is the first commit
+ __git_complete_index_file "--cached"
+ fi
}
_git_describe ()
@@ -1216,8 +1317,6 @@ _git_init ()
_git_ls_files ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --deleted --modified --others --ignored
@@ -1230,7 +1329,10 @@ _git_ls_files ()
return
;;
esac
- COMPREPLY=()
+
+ # XXX ignore options like --modified and always suggest all cached
+ # files.
+ __git_complete_index_file "--cached"
}
_git_ls_remote ()
@@ -1362,7 +1464,14 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+
+ if [ $cword -gt 2 ]; then
+ # We need to show both cached and untracked files (including
+ # empty directories) since this may not be the last argument.
+ __git_complete_index_file "--cached --others --directory"
+ else
+ __git_complete_index_file "--cached"
+ fi
}
_git_name_rev ()
@@ -2068,15 +2177,14 @@ _git_revert ()
_git_rm ()
{
- __git_has_doubledash && return
-
case "$cur" in
--*)
__gitcomp "--cached --dry-run --ignore-unmatch --quiet"
return
;;
esac
- COMPREPLY=()
+
+ __git_complete_index_file "--cached"
}
_git_shortlog ()
--
1.8.1.rc1.18.g9db0d25
^ permalink raw reply related
* Fwd: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
From: Martin von Zweigbergk @ 2012-12-21 16:55 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <CANiSa6jP_JN+DpDgYpWA9Aky9REJvFq3aR3Yj0vF3+axWvtmsw@mail.gmail.com>
Oops, meant for all of you.
---------- Forwarded message ----------
From: Martin von Zweigbergk <martinvonz@gmail.com>
Date: Fri, Dec 21, 2012 at 8:45 AM
Subject: Re: [RFC/FR] Should "git checkout (-B|-b) branch master...branch" work?
To: Junio C Hamano <gitster@pobox.com>
On Fri, Dec 21, 2012 at 7:58 AM, Junio C Hamano <gitster@pobox.com> wrote:
> $ git checkout -B branch <old fork point>
>
> Unfortunately, master...branch syntax does not seem to work for
> specifying the "old fork point" for this purpose
I have personally always found it confusing to use the same syntax for
specifying ranges/sets and single revisions. I keep forgetting what
"git diff A..B" does. I know it doesn't do what I expect (i.e. "git
diff $(git merge-base A B) B"), but I don't know what it does (maybe
same as "git diff A B" (?), but that's besides the point). Having
worked a bit on rebase, I know that $onto can also take the "A...B"
form. So there is clearly some precedence for the "..." syntax to
refer to a revision in some contexts. I would have much preferred if
it was possible to make the revision parser generally interpret e.g.
"A.^.B" as "the merge base of A and B" (failing if not exactly one).
It seems like something that must have come up before. Is there a
particular reason this would not be a good idea?
^ 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