* Re: [PATCH v5 15/15] fast-export: don't handle uninteresting refs
From: Junio C Hamano @ 2012-11-26 22:22 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Schindelin, Felipe Contreras, Jeff King, Jonathan Nieder,
git, Max Horn, Brandon Casey, Brandon Casey, Ilari Liusvaara,
Pete Wyckoff, Ben Walton, Matthieu Moy, Julian Phillips
In-Reply-To: <CAGdFq_iLYHs_tUDRsT9X1J12vSp3TUoMJQVbjw4ZgxONL6tMCA@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> On Mon, Nov 26, 2012 at 11:26 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>>> We added rev_cmdline_info since then so that we can tell what refs
>>> were given from the command line in what way, and I thought that we
>>> applied a patch from Sverre that uses it instead of the object
>>> flags. Am I misremembering things?
>>
>> It does sound so familiar that I am intended to claim that you remember
>> things correctly.
>
> FWIW, I implemented that in
> http://thread.gmane.org/gmane.comp.version-control.git/184874 but
> didn't do the work to get it merged.
Ah, OK. Should I expect an updated series then? How would it
interact with the recent work by Felipe?
^ permalink raw reply
* Re: Interesting git-format-patch bug
From: Junio C Hamano @ 2012-11-26 22:56 UTC (permalink / raw)
To: Olsen, Alan R; +Cc: git@vger.kernel.org
In-Reply-To: <4B2793BF110AAB47AB0EE7B9089703854CA7BA61@fmsmsx110.amr.corp.intel.com>
"Olsen, Alan R" <alan.r.olsen@intel.com> writes:
> I found an interesting bug in git-format-patch.
>
> Say you have a branch A. You create branch B and add a patch to
> it. You then merge that patch into branch A. After the merge, some
> other process (we will call it 'gerrit') uses annotate and changes
> the comment on the patch that exists on branch B.
>
> Now someone runs git-format-patch for the last n patches on branch
> A. You should just get the original patch that was merged over to
> branch A. What you get is the patch that was merged to branch A
> *and* the patch with the modified commit comment on branch
> B. (Double the patches, double the clean-up...)
As you literally have patches that do essentially the same or
similar things on two branches that was merged, you cannot expect to
export each individual commit into a patch and not have conflicts
among them. So I do not think there is no answer than "don't do
that".
I think you could make your "some other process" that rewrites
commits to cull the duplicates out of the format-patch output,
though. Each output file identifies what commit object the patch
came from, and your "some other process" that rewrote the commits
ought to know which commit updated which other commit did, which is
the piece of information needed to remove duplicates that format-patch
does not have.
^ permalink raw reply
* Re: Multiple threads of compression
From: Sebastian Leske @ 2012-11-26 7:23 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20121125T171702-64@post.gmane.org>
Hi,
[Thorsten Glaser <tg@debian.org>, 2012-11-25 17:27]:
> On a multi-core machine, the garbage collection of git, as well
> as pack compression on the server side when someone clones a
> repository remotely, the compression is normally done automatically
> using multiple threads of execution.
>
> That may be fine for your typical setups, but in my cases, I have
> two scenarios where it isn’t:
>
> ⓐ The machine where I want it to use only, say, 2 of my 4 or 8 cores
> as I’m also running some VMs on the box which eat up a lot of CPU
> and which I don’t want to slow down.
> ⓑ The server VM which has been given 2 or 3 VCPUs to cope with all
> the load done by clients, but which is RAM-constrained to only
> 512 or, when lucky, 768 MiB. It previously served only http/https
> and *yuk* Subversion, but now, git comes into the play, and I’ve
> seen the one server box I think about go down *HARD* because git
> ate up all RAM *and* swap when someone wanted to update their clone
> of a repository after someone else committed… well, an ~100 MiB large
> binary file they shouldn’t.
unfortunately I can't really speak to the git side of things, but both
of these cases just sound like standard resource starvation. So why
don't you address them using the usual OS mechanisms?
If you want to prevent git from sucking up CPU, nice(1) it, and if it
eats too much RAM, use the parent shell's ulimit mechanism.
Granted, this might also require some changes to git, but wouldn't that
be a simpler and more general approach to solving starvation problems?
^ permalink raw reply
* Re: [PATCH 5/5] git-send-email: allow edit invalid email address
From: Junio C Hamano @ 2012-11-26 22:58 UTC (permalink / raw)
To: Krzysztof Mazur
Cc: git, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen
In-Reply-To: <20121126173318.GA12101@shrek.podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
>> Not having this new code inside "elsif (/^e/) { }" feels somewhat
>> sloppy, even though it is not *too* bad. Also do we know this
>
> ok, I will fix that.
>
>> function will never be used for addresses other than recipients' (I
>> gave a cursory look to see what is done to the $sender and it does
>> not seem to go through this function, tho)?
>
> Yes, this function is called only from validate_address_just()
> to filter @initial_to, @initial_cc, @bcc_list as early as possible,
> and filter @to and @cc added in each email.
Thanks; when merged to 'pu', this series seems to break t9001. I'll
push the result out with breakages but could you take a look?
Test Summary Report
-------------------
t9001-send-email.sh (Wstat: 256 Tests: 102 Failed: 77)
Failed tests: 4-7, 9-10, 12-13, 15, 17-21, 23-29, 31-33
35, 37, 39, 41, 43, 45, 47, 49, 51-58, 61-88
91, 93-95, 98-102
Non-zero exit status: 1
^ permalink raw reply
* Re: [PATCH v6 p1.1 00/14] fast-export and remote-testgit improvements
From: Junio C Hamano @ 2012-11-26 23:04 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Jeff King, Johannes Sixt, Johannes Schindelin, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <1353727034-24698-1-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> I'm rerolling this series with the changes fron Junio, plus a bit more cleanups.
>
> I dropped the last patch, because I found an issue and a separate patch series
> would take care of that. Other than that the main changes remain the same.
>
> The old remote-testgit is now remote-testpy (as it's testing the python
> framework, not really remote helpers). The tests are simplified, and exercise
> more features of transport-helper, and unsuprisingly, find more bugs.
Thanks.
I've queued [v6 p1.1] but not later parts (yet). The result merged
to 'pu' however seems to break t5800. It could be a stupid and
trivial merge error or something, but I didn't look into the
details.
Could interested parties take a look?
$ cd t && sh ./t5800-remote-testpy.sh
ok 1 - setup repository
ok 2 - cloning from local repo
ok 3 - cloning from remote repo
ok 4 - create new commit on remote
ok 5 - pulling from local repo
ok 6 - pulling from remote remote
ok 7 - pushing to local repo
not ok 8 - synch with changes from localclone
#
# (cd clone &&
# git pull)
#
not ok 9 - pushing remote local repo
#
# (cd clone &&
# echo content >>file &&
# git commit -a -m four &&
# git push) &&
# compare_refs clone HEAD server HEAD
#
ok 10 - fetch new branch
not ok 11 - fetch multiple branches
#
# (cd localclone &&
# git fetch
# ) &&
# compare_refs server master localclone refs/remotes/origin/master &&
# compare_refs server new localclone refs/remotes/origin/new
#
not ok 12 - push when remote has extra refs
#
# (cd clone &&
# echo content >>file &&
# git commit -a -m six &&
# git push
# ) &&
# compare_refs clone master server master
#
ok 13 - push new branch by name
not ok 14 - push new branch with old:new refspec # TODO known breakage
ok 15 - proper failure checks for fetching
not ok 16 - proper failure checks for pushing # TODO known breakage
# still have 2 known breakage(s)
# failed 4 among remaining 14 test(s)
1..16
^ permalink raw reply
* Re: git bundle format
From: Andrew Ardill @ 2012-11-26 23:08 UTC (permalink / raw)
To: Stephen Bash; +Cc: Jason J CTR Pyeron (US), git@vger.kernel.org
In-Reply-To: <1745253724.103630.1353963384110.JavaMail.root@genarts.com>
On 27 November 2012 07:56, Stephen Bash <bash@genarts.com> wrote:
> ----- Original Message -----
>> From: "Jason J CTR Pyeron (US)" <jason.j.pyeron.ctr@mail.mil>
>> Sent: Monday, November 26, 2012 2:24:54 PM
>> Subject: git bundle format
>>
>> I am facing a situation where I would like to use git bundle but at
>> the same time inspect the contents to prevent a spillage[1].
>
> As someone who faced a similar situation in a previous life, I'll offer my $0.02, but I'm certainly not the technical expert here.
>
>> Given we have a public repository which was cloned on to a secret
>> development repository. Now the developers do some work which should
>> not be sensitive in any way and commit and push it to the secret
>> repository.
>>
>> Now they want to release it out to the public. The current process is
>> to review the text files to ensure that there is no "secret" sauce
>> in there and then approve its release. This current process ignores
>> the change tracking and all non-content is lost.
>>
>> In this situation we should assume that the bundle does not have any
>> content which is already in the public repository, that is it has
>> the minimum data to make it pass a git bundle verify from the public
>> repositories point of view. We would then take the bundle and pipe
>> it though the "git-bundle2text" program which would result in a
>> "human" inspectable format as opposed to the packed format[2]. The
>> security reviewer would then see all the information being released
>> and with the help of the public repository see how the data changes
>> the repository.
>>
>> Am I barking up the right tree?
>
> First, a shot out of left field: how about a patch based workflow? (similar to the mailing list, just replace email with sneakernet) Patches are plain text and simple to review (preferable to an "opaque" binary format?).
I would propose a slightly different workflow as well, which might
make this process lightly easier. Maybe you are already doing
something like this, but I'll lay it out just in case.
The first step would be to create a 'to-be-publicly-released' branch
within the secret repository, starting from the head of the original
public repository. Rebase all non-secret work to this branch, and
organise it in whatever fashion necessary. This could be, for example,
one single commit representing the sum of all non-secret changes, or
it could be an approximation of the actual history of these changes.
Once this branch has been prepared, you can verify that it branched
from the public repository and that it contains no secret information
using standard git tools or even a patch view of the entire branch.
You can even add a signed tag to the branch once verified to record
who is verifying these changes, and ensuring nothing else gets added
by someone else.
Then you can use 'git bundle fromVerifiedTag.bundle
verifiedTag..public/master' to create a bundle containing just those
commits on the release branch and their associated objects. You can
verify what was included using 'git bundle list-heads
fromVerifiedTag.bundle' to verify what was included.
Perhaps there is a further need to look into the packed objects to
verify nothing else is included, but this workflow should provide more
confidence in the bundled objects in the first place. As for actually
verifying the bundled data after the bundle, I don't know so you would
have to look to the other answers.
Regards,
Andrew Ardill
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Felipe Contreras @ 2012-11-26 23:14 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121126220108.GB1713@thyrsus.com>
On Mon, Nov 26, 2012 at 11:01 PM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> 1) I tried it, and it doesn't seem to import (pack?) are repository
>> with sub-directories in it
>
> I'll make sure my regression test checks this case. The options to git
> ls-files are a bit confusing and it's possible my invocation of it
> needs to change.
Might be easier to just call 'git ls-files --with-three foo', but I
don't see the point of those calls:
% git --work-tree=unpacked/1 checkout master
% git --work-tree=unpacked/1 add -A
Should work just fine.
>> 2) Using 'git fast-import' is probably simpler, and more efficient
>
> That might well be. I'm not worried about "efficiency" in this context
> but reducing the code size is significant and I'm willing to re-code
> to do that.
I don't see how the code-size would increase dramatically.
>> Here is a proof of concept I wrote in ruby that is half the size, and
>> seems to implement the same functionality.
>
> Not anywhere near the same. It only handles commits, not tags.
The attached code doesn't handle tags either.
> It doesn't issue delete ops.
What do you mean?
out.puts 'deleteall' <- All current files are removed
And then added.
> And it doesn't rebuild branch heads.
What do you mean? Your code only exports a single branch, the branch
that is currently checked out. And then:
git reset --hard >/dev/null; git checkout master >/dev/null 2>&1
It's resuming to 'master', which might not be the branch the user had
checkout out, and might not even exist.
> If I were willing to omit those features, I'm sure I could halve
> the size of my implementation, too. Of course, it would then be
> almost completely useless...
That's what the code currently does.
Do you want me to show you step by step how they do *exactly the
same*? Of course, I would need to fix your version first so that it
doesn't crash with sub-directories.
>> The format is exactly the
>> same, but I think it should be modified to be more efficient.
>
> I'm not wedded to the log format as it is, so I'll cheerfully
> take suggestions about it.
>
> Be aware, however, that I consider easy editability by human beings
> much more important than squeezing the last microsecond out of the
> processing time. So, for example, I won't use data byte counts rather
> than end delimiters, the way import streams do.
Well, if there's a line with a single dot in the commit message ('.'),
things would go very bad.
Personally I would prefer something like this:
tag v0.1 gst-av-0.1.tar "Release 0.1"
tag v0.2 gst-av-0.2.tar "Release 0.2"
tag v0.3 gst-av-0.3.tar "Release 0.3"
And the script in bash would be very simple:
#!/bin/sh
tag() {
d=`mktemp -d` &&
(
cd $d &&
tar -xf "$orig/$2" &&
cd * &&
git add --all &&
git commit -q -m "$3" &&
git tag $1) || error=1
rm -rf $d
test -n "$error" && exit -1
}
orig="$PWD"
repo="$1"
git init -q $repo
export GIT_DIR="$orig/$repo/.git"
source "$orig/$2"
cd "$orig/$repo" && git reset -q --hard
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH v6 p1.1 00/14] fast-export and remote-testgit improvements
From: Felipe Contreras @ 2012-11-26 23:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Johannes Sixt, Johannes Schindelin, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <7vd2z0otie.fsf@alter.siamese.dyndns.org>
On Tue, Nov 27, 2012 at 12:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
>
>> I'm rerolling this series with the changes fron Junio, plus a bit more cleanups.
>>
>> I dropped the last patch, because I found an issue and a separate patch series
>> would take care of that. Other than that the main changes remain the same.
>>
>> The old remote-testgit is now remote-testpy (as it's testing the python
>> framework, not really remote helpers). The tests are simplified, and exercise
>> more features of transport-helper, and unsuprisingly, find more bugs.
>
> Thanks.
>
> I've queued [v6 p1.1] but not later parts (yet). The result merged
> to 'pu' however seems to break t5800. It could be a stupid and
> trivial merge error or something, but I didn't look into the
> details.
Yeah, the last patch triggers that. It should be moved to part2. The
patch "fast-export: don't handle uninteresting refs" should fix that,
which is why I believe it should be applied first. Didn't I already
say that?
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC/PATCH] Option to revert order of parents in merge commit
From: Aaron Schrab @ 2012-11-26 23:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kacper Kornet, git
In-Reply-To: <7v8v9otfdy.fsf@alter.siamese.dyndns.org>
At 09:58 -0800 26 Nov 2012, Junio C Hamano <gitster@pobox.com> wrote:
>Kacper Kornet <draenog@pld-linux.org> writes:
>> The change of order of parents happens at the very last moment, so
>> "ours" in merge options is local version and "theirs" upstream.
>
>That may be something that wants to go to the proposed commit log
>message. I am neutral on the "feature" (i.e. not against it but not
>extremely enthusiastic about it either).
That should also be included in the (currently nonexistent)
documentation of the proposed option.
^ permalink raw reply
* Re: [PATCH] emacs: make 'git-status' work with separate git dirs
From: Junio C Hamano @ 2012-11-26 23:30 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git, Enrico Scholz
In-Reply-To: <87ehjit5ke.fsf@wine.dyndns.org>
Alexandre Julliard <julliard@winehq.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Enrico Scholz <enrico.scholz@sigma-chemnitz.de> writes:
>>
>>> when trying 'M-x git-status' in a submodule created with recent (1.7.5+)
>>> git, the command fails with
>>>
>>> | ... is not a git working tree
>>>
>>> This is caused by creating submodules with '--separate-git-dir' but
>>> still checking for a working tree by testing for a '.git' directory.
>>>
>>> The patch fixes this by relaxing the existing detection a little bit.
>>>
>>> Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de>
>>> ---
>>
>> This script already relies on the assumption that nobody sane would
>> create a directory named ".git" that is not a git repository, and
>> this loosens the assumption that nobody would create a file named
>> ".git", either. So I would think it is a sane thing to do, but just
>> in case if the area expert has better ideas, I am forwarding it.
>>
>> Ack?
>
> Sure, that's fine.
Thanks, both. Applied.
^ permalink raw reply
* Re: [PATCH 5/5] git-send-email: allow edit invalid email address
From: Krzysztof Mazur @ 2012-11-26 23:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen
In-Reply-To: <7vhaocotsd.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>
> >> Not having this new code inside "elsif (/^e/) { }" feels somewhat
> >> sloppy, even though it is not *too* bad. Also do we know this
> >
> > ok, I will fix that.
> >
> >> function will never be used for addresses other than recipients' (I
> >> gave a cursory look to see what is done to the $sender and it does
> >> not seem to go through this function, tho)?
> >
> > Yes, this function is called only from validate_address_just()
> > to filter @initial_to, @initial_cc, @bcc_list as early as possible,
> > and filter @to and @cc added in each email.
>
> Thanks; when merged to 'pu', this series seems to break t9001. I'll
> push the result out with breakages but could you take a look?
>
Sorry, I tested final version only on an ancient perl 5.8.8 and it really
worked there. The third patch is broken:
diff --git a/git-send-email.perl b/git-send-email.perl
index 9996735..f3bbc16 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1472,7 +1472,7 @@ sub unique_email_list {
my @emails;
foreach my $entry (@_) {
- my $clean = extract_valid_address_or_die($entry))
+ my $clean = extract_valid_address_or_die($entry);
$seen{$clean} ||= 0;
next if $seen{$clean}++;
push @emails, $entry;
Krzysiek
^ permalink raw reply related
* Re: gitpacker progress report and a question
From: Eric S. Raymond @ 2012-11-26 23:43 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <CAMP44s2+NDyL2Vf=iKR09f-YUnp=G2BCiYj-+qKuP7JA-+YkmQ@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com>:
> Might be easier to just call 'git ls-files --with-three foo', but I
> don't see the point of those calls:
Ah, much is now explained. You were looking at an old version. I had
in fact already fixed the subdirectories bug (I've updated my
regression test to check) and have full support for branchy repos,
preserving tags and branch heads.
> > It doesn't issue delete ops.
>
> What do you mean?
>
> out.puts 'deleteall' <- All current files are removed
Yours emits no D ops for files removed after a particular snapshot.
> > Be aware, however, that I consider easy editability by human beings
> > much more important than squeezing the last microsecond out of the
> > processing time. So, for example, I won't use data byte counts rather
> > than end delimiters, the way import streams do.
>
> Well, if there's a line with a single dot in the commit message ('.'),
> things would go very bad.
Apparently you missed the part where I byte-stuffed the message content.
It's a technique used in a lot of old-school Internet protocols, notably
in SMTP.
> Personally I would prefer something like this:
There's a certain elegance to that, but it would be hard to generate by hand.
Remember that a major use case for this tool is making repositories
from projects whose back history exists only as tarballs. So, let's
say you have the following:
foo-1.1.tar.gz
foo-1.2.tar.gz
foo-1.3.tar.gz
What you're going to do before weaving is drop the untarred file trees
in a 'foo' scratch directory, then hand-craft a log file that might
look a bit like this:
-----------------------------------
commit 1
directory foo-1.1
Release 1.1 of project foo
.
commit 2
directory foo-1.2
..This is an example of a byte-stuffed line.
Release 1.2 of project foo
.
commit 3
directory foo-1.3
Release 1.3 of project foo
.
-----------------------------------
The main objective of the logfile design is to make hand-crafting
these easy.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [PATCH 5/5] git-send-email: allow edit invalid email address
From: Junio C Hamano @ 2012-11-26 23:50 UTC (permalink / raw)
To: Krzysztof Mazur
Cc: git, Felipe Contreras, Andreas Schwab, Felipe Balbi,
Tomi Valkeinen
In-Reply-To: <20121126233337.GA31100@shrek.podlesie.net>
Krzysztof Mazur <krzysiek@podlesie.net> writes:
> On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
>> Krzysztof Mazur <krzysiek@podlesie.net> writes:
>>
>> >> Not having this new code inside "elsif (/^e/) { }" feels somewhat
>> >> sloppy, even though it is not *too* bad. Also do we know this
>> >
>> > ok, I will fix that.
>> >
>> >> function will never be used for addresses other than recipients' (I
>> >> gave a cursory look to see what is done to the $sender and it does
>> >> not seem to go through this function, tho)?
>> >
>> > Yes, this function is called only from validate_address_just()
>> > to filter @initial_to, @initial_cc, @bcc_list as early as possible,
>> > and filter @to and @cc added in each email.
>>
>> Thanks; when merged to 'pu', this series seems to break t9001. I'll
>> push the result out with breakages but could you take a look?
>>
>
> Sorry, I tested final version only on an ancient perl 5.8.8 and it really
> worked there. The third patch is broken:
>
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 9996735..f3bbc16 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -1472,7 +1472,7 @@ sub unique_email_list {
> my @emails;
>
> foreach my $entry (@_) {
> - my $clean = extract_valid_address_or_die($entry))
> + my $clean = extract_valid_address_or_die($entry);
Ah, ok, I wasn't looking closely enough. Thanks for a quick
turnaround. Will requeue and push out.
> $seen{$clean} ||= 0;
> next if $seen{$clean}++;
> push @emails, $entry;
>
> Krzysiek
^ permalink raw reply
* Re: [PATCH v6 p1.1 00/14] fast-export and remote-testgit improvements
From: Junio C Hamano @ 2012-11-26 23:52 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Jeff King, Johannes Sixt, Johannes Schindelin, Max Horn,
Sverre Rabbelier, Brandon Casey, Brandon Casey, Jonathan Nieder,
Ilari Liusvaara, Pete Wyckoff, Ben Walton, Matthieu Moy,
Julian Phillips
In-Reply-To: <CAMP44s3LR6T6H8z0LPJr7DHXde-JUoN9X4mWhju-5ECvG7wDpg@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> On Tue, Nov 27, 2012 at 12:04 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>> I'm rerolling this series with the changes fron Junio, plus a bit more cleanups.
>>>
>>> I dropped the last patch, because I found an issue and a separate patch series
>>> would take care of that. Other than that the main changes remain the same.
>>>
>>> The old remote-testgit is now remote-testpy (as it's testing the python
>>> framework, not really remote helpers). The tests are simplified, and exercise
>>> more features of transport-helper, and unsuprisingly, find more bugs.
>>
>> Thanks.
>>
>> I've queued [v6 p1.1] but not later parts (yet). The result merged
>> to 'pu' however seems to break t5800. It could be a stupid and
>> trivial merge error or something, but I didn't look into the
>> details.
>
> Yeah, the last patch triggers that. It should be moved to part2. The
> patch "fast-export: don't handle uninteresting refs" should fix that,
> which is why I believe it should be applied first. Didn't I already
> say that?
You may have, but I am leaky ;-) as I am not 100% focused on this
series alone.
In the meantime, I'll drop the last one, push out the 'pu' branch
after rebuilding, and then revisit it when I queue the part 2.
Thanks.
^ permalink raw reply
* [PATCH] Documentation/git-push.txt: fix typo in remote tracking branch path
From: Brandon Casey @ 2012-11-27 0:55 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
This example in the documentation seems to be trying to describe the likely
remote tracking branch that will be updated by a push to the "origin" remote
with the destination branch 'satellite/master', but it forgot to specify
the remote name in the path specification.
So,
refs/remotes/satellite/master
should be spelled like
refs/remotes/origin/satellite/master
Signed-off-by: Brandon Casey <bcasey@nvidia.com>
---
Documentation/git-push.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fe46c42..a18f929 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -387,8 +387,8 @@ the ones in the examples below) can be configured as the default for
`git push origin master:satellite/master dev:satellite/dev`::
Use the source ref that matches `master` (e.g. `refs/heads/master`)
to update the ref that matches `satellite/master` (most probably
- `refs/remotes/satellite/master`) in the `origin` repository, then
- do the same for `dev` and `satellite/dev`.
+ `refs/remotes/origin/satellite/master`) in the `origin` repository,
+ then do the same for `dev` and `satellite/dev`.
`git push origin HEAD:master`::
Push the current branch to the remote ref matching `master` in the
--
1.7.8.4
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply related
* Re: gitpacker progress report and a question
From: Felipe Contreras @ 2012-11-27 1:29 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <20121126234359.GA8042@thyrsus.com>
[-- Attachment #1: Type: text/plain, Size: 5609 bytes --]
On Tue, Nov 27, 2012 at 12:43 AM, Eric S. Raymond <esr@thyrsus.com> wrote:
> Felipe Contreras <felipe.contreras@gmail.com>:
>> Might be easier to just call 'git ls-files --with-three foo', but I
>> don't see the point of those calls:
>
> Ah, much is now explained. You were looking at an old version. I had
> in fact already fixed the subdirectories bug (I've updated my
> regression test to check) and have full support for branchy repos,
> preserving tags and branch heads.
So you are criticizing my code saying "it would then be almost
completely useless...", when this is in fact what you sent to the
list.
For the record, here is the output of a test with your script vs.
mine: the output is *exactly the same*:
---
== log ==
* afcbedc (tag: v0.2, master) bump
| * cbd2dce (devel) dev
|/
* 46f1813 (HEAD, test) remove
* df95e41 dot .
* ede0876 with
* d6f10fc extra
* e6362b1 (tag: v0.1) one
== files ==
file
== spaces ==
with
spaces
== dot ==
dot
.
== orig ref ==
refs/heads/test
== script ==
bc9a7d99132f97adeb5d2ca266bd3d8bc64ccb21 /home/felipec/Downloads/gitpacker.txt
Unpacking......(0.13 sec) done.
Packing......(0.28 sec) done.
== log ==
* 5d0b634 (HEAD, master) bump
* 2fe4a6d remove
* 0c27d3b dot .
* 5e36d3f with spaces
* d6f10fc extra
* e6362b1 one
== files ==
file
== spaces ==
with
spaces
== dot ==
dot
.
== orig ref ==
refs/heads/master
== script ==
33edcb28667b683fbb5f8782383f782f73c5e9e1 /home/felipec/bin/git-weave
== log ==
* afcbedc (HEAD, master) bump
* 46f1813 remove
* df95e41 dot .
* ede0876 with
* d6f10fc extra
* e6362b1 one
== files ==
file
== spaces ==
with
spaces
== dot ==
dot
.
== orig ref ==
refs/heads/test
---
Unfortunately, when I enable some testing stuff, this is what your
script throws:
---
== script ==
bc9a7d99132f97adeb5d2ca266bd3d8bc64ccb21 /home/felipec/Downloads/gitpacker.txt
Unpacking......(0.17 sec) done.
Packing......(0.02 sec) done.
Traceback (most recent call last):
File "/home/felipec/Downloads/gitpacker.txt", line 308, in <module>
git_pack(indir, outdir, quiet=quiet)
File "/home/felipec/Downloads/gitpacker.txt", line 171, in git_pack
command += " ".join(map(lambda p: "-p " + commit_id[int(p)],parents))
File "/home/felipec/Downloads/gitpacker.txt", line 171, in <lambda>
command += " ".join(map(lambda p: "-p " + commit_id[int(p)],parents))
IndexError: list index out of range
== log ==
fatal: bad default revision 'HEAD'
== files ==
fatal: tree-ish master not found.
== spaces ==
fatal: ambiguous argument ':/with': unknown revision or path not in
the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
== dot ==
fatal: ambiguous argument ':/dot': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
== orig ref ==
refs/heads/master
---
I'm attaching it in case you are interested.
Anyway, I can add support for branches and tags in no time, but I
wonder what's the point. Who will take so much time and effort to
generate all the branches and tags, and the log file?
If the goal is as you say "importing older projects that are available
only as sequences of release tarballs", then that code is overkill,
and it's not even making it easier to import the tarballs.
For that case my proposed format:
tag v0.1 gst-av-0.1.tar "Release 0.1"
tag v0.2 gst-av-0.2.tar "Release 0.2"
tag v0.3 gst-av-0.3.tar "Release 0.3"
Would be much more suitable.
>> > It doesn't issue delete ops.
>>
>> What do you mean?
>>
>> out.puts 'deleteall' <- All current files are removed
>
> Yours emits no D ops for files removed after a particular snapshot.
man git fast-import
---
This command is extremely useful if the frontend does not know (or
does not care to know) what files are currently on the branch, and
therefore cannot generate the proper filedelete commands to update the
content.
---
Why would I want to emit D operations, again, deleteall takes care of that.
>> > Be aware, however, that I consider easy editability by human beings
>> > much more important than squeezing the last microsecond out of the
>> > processing time. So, for example, I won't use data byte counts rather
>> > than end delimiters, the way import streams do.
>>
>> Well, if there's a line with a single dot in the commit message ('.'),
>> things would go very bad.
>
> Apparently you missed the part where I byte-stuffed the message content.
> It's a technique used in a lot of old-school Internet protocols, notably
> in SMTP.
You might have done that, but the user that generated the log file
might have not.
>> Personally I would prefer something like this:
>
> There's a certain elegance to that, but it would be hard to generate by hand.
You think this is hard to generate by hand:
---
tag v0.1 gst-av-0.1.tar "Release 0.1"
tag v0.2 gst-av-0.2.tar "Release 0.2"
tag v0.3 gst-av-0.3.tar "Release 0.3"
---
Than this?
---
commit 1
directory gst-av-0.1
Release 0.1
.
commit 2
directory gst-av-0.2
Release 0.2
.
commit 3
directory gst-av-0.3
Release 0.3
.
---
After of course, extracting the tarballs, which my script already does
automatically.
> Remember that a major use case for this tool is making repositories
> from projects whose back history exists only as tarballs.
Which is exactly what my script does, except even easier, because it
extracts the tarballs automatically.
> The main objective of the logfile design is to make hand-crafting
> these easy.
What does the above log file achieve, that my log file doesn't?
--
Felipe Contreras
[-- Attachment #2: test-gitpacker --]
[-- Type: application/octet-stream, Size: 2534 bytes --]
#!/bin/sh
rm -rf test test-unpacked* test-new*
test_date=1
test_subdir=1
test_tick () {
if test -z "${test_tick+set}"
then
test_tick=1112911993
else
test "$test_date" -eq 1 || \
test_tick=$(($test_tick + 60))
fi
GIT_COMMITTER_DATE="$test_tick -0700"
GIT_AUTHOR_DATE="$test_tick -0700"
export GIT_COMMITTER_DATE GIT_AUTHOR_DATE
}
(
git init -q test
cd test
echo one > file
git add file
test_tick
git commit -q -m one
git tag v0.1
echo extra > extra
git add extra
test_tick
git commit -q -m extra
echo spaces >> file
test_tick
git commit -q -a -m "$(echo -e "with\n\nspaces")"
echo dot >> file
test_tick
git commit -q -a -m "$(echo -e "dot\n.\n")"
if test "$test_subdir" -eq 1
then
mkdir subdir
echo subdir > subdir/file
git add subdir/file
test_tick
git commit -q -m dir
echo subdir2 >> file
test_tick
git commit -q -a -m subdir2
fi
git rm -q extra
test_tick
git commit -q -m remove
git checkout -q -b devel
echo dev >> file
test_tick
git commit -q -a -m dev
git checkout -q master
echo bump >> file
test_tick
git commit -q -a -m bump
git tag v0.2
git checkout -q -b test master^
echo "== log =="
git log --oneline --graph --decorate --all
echo "== files =="
git ls-files --with-tree master
echo "== spaces =="
git show --quiet --format='%B' :/with
echo "== dot =="
git show --quiet --format='%B' :/dot
)
echo "== orig ref =="
git --git-dir=test/.git symbolic-ref HEAD
git --git-dir=test/.git symbolic-ref HEAD refs/heads/test
script="/home/felipec/Downloads/gitpacker.txt"
echo
echo "== script =="
sha1sum $script
$PYTHON_PATH $script -x -i test -o test-unpacked-1
$PYTHON_PATH $script -c -i test-unpacked-1 -o test-new-1
(
cd test-new-1
echo "== log =="
git log --oneline --graph --decorate --all
echo "== files =="
git ls-files --with-tree master
echo "== spaces =="
git show --quiet --format='%B' :/with
echo "== dot =="
git show --quiet --format='%B' :/dot
)
echo "== orig ref =="
git --git-dir=test/.git symbolic-ref HEAD
git --git-dir=test/.git symbolic-ref HEAD refs/heads/test
script="$HOME/bin/git-weave"
echo
echo "== script =="
sha1sum $script
$script -x -i test -o test-unpacked-2
$script -c -i test-unpacked-2 -o test-new-2
(
cd test-new-2
echo "== log =="
git log --oneline --graph --decorate --all
echo "== files =="
git ls-files --with-tree master
echo "== spaces =="
git show --quiet --format='%B' :/with
echo "== dot =="
git show --quiet --format='%B' :/dot
)
echo "== orig ref =="
git --git-dir=test/.git symbolic-ref HEAD
git --git-dir=test/.git symbolic-ref HEAD refs/heads/test
^ permalink raw reply
* Re: [PATCH] Documentation/git-push.txt: fix typo in remote tracking branch path
From: Junio C Hamano @ 2012-11-27 1:30 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Brandon Casey
In-Reply-To: <1353977748-17110-1-git-send-email-bcasey@nvidia.com>
Brandon Casey <bcasey@nvidia.com> writes:
> From: Brandon Casey <drafnel@gmail.com>
>
> This example in the documentation seems to be trying to describe the likely
> remote tracking branch that will be updated by a push to the "origin" remote
> with the destination branch 'satellite/master', but it forgot to specify
> the remote name in the path specification.
>
> So,
>
> refs/remotes/satellite/master
>
> should be spelled like
>
> refs/remotes/origin/satellite/master
I might make sense to rename 'origin' to 'mothership' in that
example and explain that this is emulating 'git fetch' run on the
mothership to integrate the work done on 'satellite' using 'git
push' in the opposite direction, which is often necessary when you
can only make connection in one way (i.e. satellite can ssh into
mothership but mothership cannot initiate connection to satellite
because the latter is behind a firewall or does not run sshd).
If you were to run 'git fetch' on the mothership to intgrate the
work on the 'satellite', it would have a remote called 'satellite',
and would keep remote-tracking branches for the branches local to
'satellite' in the 'refs/remotes/satellite/' hierarchy. You would
push your local 'master' to their 'refs/remotes/satellite/master',
to emulate 'git fetch' done on the mothership in the reverse
direction.
So refs are correct. The context is not sufficiently explained.
>
> Signed-off-by: Brandon Casey <bcasey@nvidia.com>
> ---
> Documentation/git-push.txt | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index fe46c42..a18f929 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -387,8 +387,8 @@ the ones in the examples below) can be configured as the default for
> `git push origin master:satellite/master dev:satellite/dev`::
> Use the source ref that matches `master` (e.g. `refs/heads/master`)
> to update the ref that matches `satellite/master` (most probably
> - `refs/remotes/satellite/master`) in the `origin` repository, then
> - do the same for `dev` and `satellite/dev`.
> + `refs/remotes/origin/satellite/master`) in the `origin` repository,
> + then do the same for `dev` and `satellite/dev`.
>
> `git push origin HEAD:master`::
> Push the current branch to the remote ref matching `master` in the
^ permalink raw reply
* Re: gitpacker progress report and a question
From: Felipe Contreras @ 2012-11-27 1:38 UTC (permalink / raw)
To: esr; +Cc: git
In-Reply-To: <CAMP44s3HAzSPsrGwcpQpx_3n2aHK5wm++_7_Cbk3qRWMkxDh6g@mail.gmail.com>
On Tue, Nov 27, 2012 at 2:29 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
Actually no, they are not exactly the same, your version has a bug
when dealing with spaces in a commit message (which pretty much all
proper multi-line commit messages have).
> == spaces ==
> with
> spaces
>
Mine doesn't:
> == spaces ==
> with
>
> spaces
>
--
Felipe Contreras
^ permalink raw reply
* [PATCH] Documentation: improve phrasing in git-push.txt
From: Mark Szepieniec @ 2012-11-27 1:37 UTC (permalink / raw)
To: git; +Cc: Mark Szepieniec
The current version contains the sentence:
Further suppose that the other person already pushed changes leading to
A back to the original repository you two obtained the original commit
X.
which doesn't parse for me; I've changed it to
Further suppose that the other person already pushed changes leading to
A back to the original repository from which you two obtained the
original commit X.
Signed-off-by: Mark Szepieniec <mszepien@gmail.com>
---
Documentation/git-push.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index fe46c42..6d19d59 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -286,7 +286,8 @@ leading to commit A. The history looks like this:
----------------
Further suppose that the other person already pushed changes leading to A
-back to the original repository you two obtained the original commit X.
+back to the original repository from which you two obtained the original
+commit X.
The push done by the other person updated the branch that used to point at
commit X to point at commit A. It is a fast-forward.
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] Documentation/git-push.txt: fix typo in remote tracking branch path
From: Brandon Casey @ 2012-11-27 1:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git@vger.kernel.org, Brandon Casey
In-Reply-To: <7vy5hnomsl.fsf@alter.siamese.dyndns.org>
On 11/26/2012 5:30 PM, Junio C Hamano wrote:
> Brandon Casey <bcasey@nvidia.com> writes:
>
>> From: Brandon Casey <drafnel@gmail.com>
>>
>> This example in the documentation seems to be trying to describe the likely
>> remote tracking branch that will be updated by a push to the "origin" remote
>> with the destination branch 'satellite/master', but it forgot to specify
>> the remote name in the path specification.
>>
>> So,
>>
>> refs/remotes/satellite/master
>>
>> should be spelled like
>>
>> refs/remotes/origin/satellite/master
>
> I might make sense to rename 'origin' to 'mothership' in that
> example and explain that this is emulating 'git fetch' run on the
> mothership to integrate the work done on 'satellite' using 'git
> push' in the opposite direction, which is often necessary when you
> can only make connection in one way (i.e. satellite can ssh into
> mothership but mothership cannot initiate connection to satellite
> because the latter is behind a firewall or does not run sshd).
>
> If you were to run 'git fetch' on the mothership to intgrate the
> work on the 'satellite', it would have a remote called 'satellite',
> and would keep remote-tracking branches for the branches local to
> 'satellite' in the 'refs/remotes/satellite/' hierarchy. You would
> push your local 'master' to their 'refs/remotes/satellite/master',
> to emulate 'git fetch' done on the mothership in the reverse
> direction.
>
> So refs are correct. The context is not sufficiently explained.
Ah, I see. Yeah, I think that is complex enough to merit an
extended explanation.
-Brandon
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
^ permalink raw reply
* Re: [PATCH 1/7] push: return reject reasons via a mask
From: Chris Rorvick @ 2012-11-27 3:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <7vobikryrc.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 12:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>
>> Pass all rejection reasons back from transport_push(). The logic is
>> simpler and more flexible with regard to providing useful feedback.
>>
>> Signed-off-by: Chris Rorvick <chris@rorvick.com>
>> ---
>
> In any case, naming it as "reject_mask" is like calling a counter as
> "counter_int". It is more important to name it after its purpose
> than after its type
Agreed.
> and because this is to record the reasons why
> the push was rejected, "rejection_reason" might be a better name for
> it.
Yes, that is better for all the reasons you mention. I will fix this up.
^ permalink raw reply
* Re: [PATCH 7/7] push: clarify rejection of update to non-commit-ish
From: Chris Rorvick @ 2012-11-27 3:52 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <7vk3t8ryap.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 12:53 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>
>> Pushes must already (by default) update to a commit-ish due the fast-
>> forward check in set_ref_status_for_push(). But rejecting for not being
>> a fast-forward suggests the situation can be resolved with a merge.
>> Flag these updates (i.e., to a blob or a tree) as not forwardable so the
>> user is presented with more appropriate advice.
>>
>> Signed-off-by: Chris Rorvick <chris@rorvick.com>
>> ---
>> remote.c | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/remote.c b/remote.c
>> index f5bc4e7..ee0c1e5 100644
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -1291,6 +1291,11 @@ static inline int is_forwardable(struct ref* ref)
>> if (!o || o->type != OBJ_COMMIT)
>> return 0;
>>
>> + /* new object must be commit-ish */
>> + o = deref_tag(parse_object(ref->new_sha1), NULL, 0);
>> + if (!o || o->type != OBJ_COMMIT)
>> + return 0;
>> +
>
> I think the original code used ref_newer() which took commit-ish on
> both sides.
That is still called later in set_ref_status_for_push() to calculate
the nonfastforward flag. The only reason for even checking the new
here is to exclude trees and blobs now so they are flagged as
already-existing and thus avoid nonsensical fetch-and-merge advice.
Otherwise the behavior is unchanged by this last patch.
ref_newer() does end up redoing computation now done in the new
is_forwardable() function. I could probably factor this out of
ref_newer() into a commit_newer() function that could be reused in
set_ref_status_for_push() to avoid this overhead, but it didn't seem
like a big deal. Thoughts?
> With this code, the old must be a commit but new can be a tag that
> points at a commit? Why?
The old must not be a tag because fast-forwarding from it is
potentially destructive; a tag would likely be left dangling in this
case. This is not true for the new, though. I'm not sure
fast-forwarding from a commit to a tag is useful, but I didn't see a
reason to prevent it either. The refs/tags/ hierarchy is excluded
from fast-forwarding before this check, and refs/heads/ is already
protected against anything but commits. So it seems very unlikely
that someone would accidentally make use of this behavior.
So, fast-forwarding to a tag seemed fairly benign and unlikely to
cause confusion, so I leaned towards allowing it in case someone found
a use case for it.
^ permalink raw reply
* [PATCH] Support for git aliasing for tcsh completion
From: Marc Khouzam @ 2012-11-27 4:13 UTC (permalink / raw)
To: git, Felipe Contreras, SZEDER Gábor; +Cc: Tuncer Ayaz
In-Reply-To: <1353989472-4142-1-git-send-email-marc.khouzam@gmail.com>
tcsh users sometimes alias the 'git' command to another name. In
this case, the user expects to only have to issue a new 'complete'
command using the alias name.
However, the tcsh script currently uses the command typed by the
user to call the appropriate function in git-completion.bash, either
_git() or _gitk(). When using an alias, this technique no longer
works.
This change specifies the real name of the command (either 'git' or
'gitk') as a parameter to the script handling tcsh completion. This
allows the user to use any alias for the 'git' or 'gitk' commands,
while still getting completion to work.
A check for the presence of ${HOME}/.git-completion.bash is also
added to help the user make use of the script properly.
Signed-off-by: Marc Khouzam <marc.khouzam@gmail.com>
---
This issue was reported by someone already making use of the tcsh
completion script.
Thanks for considering this fix.
Marc
contrib/completion/git-completion.tcsh | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-completion.tcsh
b/contrib/completion/git-completion.tcsh
index dc5678c..44bd544 100644
--- a/contrib/completion/git-completion.tcsh
+++ b/contrib/completion/git-completion.tcsh
@@ -23,6 +23,12 @@
set __git_tcsh_completion_original_script = ${HOME}/.git-completion.bash
set __git_tcsh_completion_script = ${HOME}/.git-completion.tcsh.bash
+# Check that the user put the script in the right place
+if ( ! -e ${__git_tcsh_completion_original_script} ) then
+ echo "git-completion.tcsh: Cannot find:
${__git_tcsh_completion_original_script}. Git completion will not work."
+ exit
+endif
+
cat << EOF > ${__git_tcsh_completion_script}
#!bash
#
@@ -34,13 +40,13 @@ cat << EOF > ${__git_tcsh_completion_script}
source ${__git_tcsh_completion_original_script}
# Set COMP_WORDS in a way that can be handled by the bash script.
-COMP_WORDS=(\$1)
+COMP_WORDS=(\$2)
# The cursor is at the end of parameter #1.
# We must check for a space as the last character which will
# tell us that the previous word is complete and the cursor
# is on the next word.
-if [ "\${1: -1}" == " " ]; then
+if [ "\${2: -1}" == " " ]; then
# The last character is a space, so our location is at the end
# of the command-line array
COMP_CWORD=\${#COMP_WORDS[@]}
@@ -51,13 +57,12 @@ else
COMP_CWORD=\$((\${#COMP_WORDS[@]}-1))
fi
-# Call _git() or _gitk() of the bash script, based on the first
-# element of the command-line
-_\${COMP_WORDS[0]}
+# Call _git() or _gitk() of the bash script, based on the first argument
+_\${1}
IFS=\$'\n'
echo "\${COMPREPLY[*]}" | sort | uniq
EOF
-complete git 'p/*/`bash ${__git_tcsh_completion_script}
"${COMMAND_LINE}"`/'
-complete gitk 'p/*/`bash ${__git_tcsh_completion_script}
"${COMMAND_LINE}"`/'
+complete git 'p/*/`bash ${__git_tcsh_completion_script} git
"${COMMAND_LINE}"`/'
+complete gitk 'p/*/`bash ${__git_tcsh_completion_script} gitk
"${COMMAND_LINE}"`/'
--
1.8.0.1.g9fe2839
^ permalink raw reply related
* Re: [PATCH 5/7] push: require force for refs under refs/tags/
From: Chris Rorvick @ 2012-11-27 4:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Angelo Borsotti, Drew Northup, Michael Haggerty,
Philip Oakley, Johannes Sixt, Kacper Kornet, Jeff King,
Felipe Contreras
In-Reply-To: <7vfw3wry4d.fsf@alter.siamese.dyndns.org>
On Mon, Nov 26, 2012 at 12:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Chris Rorvick <chris@rorvick.com> writes:
>
>> diff --git a/remote.c b/remote.c
>> index 4a6f822..012b52f 100644
>> --- a/remote.c
>> +++ b/remote.c
>> @@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror,
>> *
>> * (1) if the old thing does not exist, it is OK.
>> *
>> - * (2) if you do not have the old thing, you are not allowed
>> + * (2) if the destination is under refs/tags/ you are
>> + * not allowed to overwrite it; tags are expected
>> + * to be static once created
>> + *
>> + * (3) if you do not have the old thing, you are not allowed
>> * to overwrite it; you would not know what you are losing
>> * otherwise.
>> *
>> - * (3) if both new and old are commit-ish, and new is a
>> + * (4) if both new and old are commit-ish, and new is a
>> * descendant of old, it is OK.
>> *
>> - * (4) regardless of all of the above, removing :B is
>> + * (5) regardless of all of the above, removing :B is
>> * always allowed.
>> */
>
> We may want to reword (0) to make it clear that --force
> (and +A:B) can be used to defeat all the other rules.
On that note, having (5) be "regardless of all of the above ..." seems
a little awkward. That would seem to fit better towards the top.
^ permalink raw reply
* Re: Interesting git-format-patch bug
From: Perry Hutchison @ 2012-11-27 4:15 UTC (permalink / raw)
To: gitster; +Cc: git, alan.r.olsen
In-Reply-To: <7vobikotwd.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Olsen, Alan R" <alan.r.olsen@intel.com> writes:
> > I found an interesting bug in git-format-patch.
> >
> > Say you have a branch A. You create branch B and add a patch to
> > it. You then merge that patch into branch A. After the merge,
> > some other process (we will call it 'gerrit') uses annotate and
> > changes the comment on the patch that exists on branch B.
> >
> > Now someone runs git-format-patch for the last n patches on
> > branch A. You should just get the original patch that was
> > merged over to branch A. What you get is the patch that was
> > merged to branch A *and* the patch with the modified commit
> > comment on branch B. (Double the patches, double the
> > clean-up...)
>
> As you literally have patches that do essentially the same or
> similar things on two branches that was merged, you cannot
> expect to export each individual commit into a patch and not
> have conflicts among them. So I do not think there is no
> answer than "don't do that".
To me, this seems to miss Alan's point: only one patch was merged
to branch A, so git-format-patch applied to branch A should find
only one patch. It can be argued either way whether that one-patch
report should include the gerrit annotations, but surely the
application of gerrit on branch B, _after the merge to branch A
has already been performed_, should not cause an additional patch
to magically appear on branch A.
^ 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