* Re: fetching packs and storing them as packs
From: Petr Baudis @ 2006-10-27 14:38 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Shawn Pearce, Eran Tromer, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0610271022240.11384@xanadu.home>
Dear diary, on Fri, Oct 27, 2006 at 04:27:05PM CEST, I got a letter
where Nicolas Pitre <nico@cam.org> said that...
> On Thu, 26 Oct 2006, Shawn Pearce wrote:
> > OK so the repository won't get corrupted but the repack would be
> > forced to abort.
>
> Maybe this is the best way out? Abort git-repack with "a fetch is in
> progress -- retry later". No one will really suffer if the repack has
> to wait for the next scheduled cron job, especially if the fetch doesn't
> explode packs into loose objects anymore.
I don't really like this that much. Big projects can have 10 commits per
hour on average, and they also take potentially long time to repack, so
you might get to never really repack them.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Nicolas Pitre @ 2006-10-27 14:27 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Eran Tromer, Junio C Hamano, git
In-Reply-To: <20061027030054.GB28407@spearce.org>
On Thu, 26 Oct 2006, Shawn Pearce wrote:
> Unfortunately it does not completely work.
>
> What happens when the incoming pack (steps #2 and #3) takes 15
> minutes to upload (slow ADSL modem, lots of objects) and the
> background repack process sees those temporary refs and starts
> trying to include those objects? It can't walk the DAG that those
> refs point at because the objects aren't in the current repository.
>
> From what I know of that code the pack-objects process will fail to
> find the object pointed at by the ref, rescan the packs directory,
> find no new packs, look for the object again, and abort over the
> "corruption".
>
> OK so the repository won't get corrupted but the repack would be
> forced to abort.
Maybe this is the best way out? Abort git-repack with "a fetch is in
progress -- retry later". No one will really suffer if the repack has
to wait for the next scheduled cron job, especially if the fetch doesn't
explode packs into loose objects anymore.
> Another issue I just thought about tonight is we may need a
> count-packs utility that like count-objects lists the number
> of active packs and their total size. If we start hanging onto
> every pack we receive over the wire the pack directory is going to
> grow pretty fast and we'll need a way to tell us when its time to
> `repack -a -d`.
Sure. Although the pack count is going to grow much less rapidly.
Think of one pack per fetch instead of many many objects per fetch.
^ permalink raw reply
* Re: Question on multi-level git repository heiarchy.
From: Ben Greear @ 2006-10-27 14:05 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20061027052517.GB29057@spearce.org>
Shawn Pearce wrote:
> Ben Greear <greearb@candelatech.com> wrote:
>
>> I want to create an intermediate level..something like:
>>
>> kernel.org git tree
>> |
>> my git master tree
>> / \
>> work-station-1 work-station-2 ....
>>
>
>
>> I then did a git checkout -f master on the
>> pub server and did a pull from the upstream kernel.
>> This seemed to work fine.
>>
>
> Ah, what you really want here is to make your "my git master tree"
> a bare repostiory and use fetch instead of pull. This way you
> don't need to maintain a working directory of files associated
> with that repository. So assuming you have "mygitmastertree"
> as the directory do:
>
> mv mygitmastertree/.git mygitmastertree.git
> rm -rf mygitmastertree
>
> and update your workstation .git/remotes/origin files such
> that the URL line reads ".../mygitmastertree.git" rather than
> ".../mygitmastertree/.git".
>
> Then to update "mygitmastertree" with recent changes you can use
> git fetch rather than git pull:
>
> git --git-dir mygitmastertree.git fetch
>
Ok, I made those changes...
>
>
>> Then, on the work-station, I did a git checkout -f master, and also did
>> a pull.
>> In this case, it seems that it is trying to merge with changes in the
>> lf_v2.6.18 branch
>> instead of the the main 'master' tree (see below).
>>
>
> When you use "git pull" with no additional arguments the first
> branch listed in a Pull: line of .git/remotes/origin will be the
> branch merged into the current branch. I don't know what that
> branch is listed as in your workstation tree but from what you
> described it sounds like it may be that lf_v2.6.18 branch, which
> is why its trying to merge it.
>
That is certainly not intuitive.
I want to synchronize the entire git repo, including all branches. How
would I go
about doing that?
Is there any way to recover my currently mangled tree on the
workstation, or do I need
to start fresh there? If I start fresh, do I re-clone, or is there some
better way to get
the synchronization that I want?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Creating new repos
From: Petr Baudis @ 2006-10-27 12:39 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: git
In-Reply-To: <200610271229.k9RCTARu016773@laptop13.inf.utfsm.cl>
Dear diary, on Fri, Oct 27, 2006 at 02:29:10PM CEST, I got a letter
where "Horst H. von Brand" <vonbrand@inf.utfsm.cl> said that...
> I'm trying to set up git repos for remote access here. I set up git-daemon
> and got it working (some older repositories do work fine), but now:
>
> $ mkdir /var/scm/user/SomeRepo.git
> $ cd /var/scm/user/SomeRepo.git
> $ git --bare init-db
> $ touch git-daemon-export-ok
>
> All OK, but then, from a remote machine:
>
> $ git clone git://git-server/user/SomeRepo.git
> fatal: no matching remote head
> fetch-pack from 'git://git-server/user/Test.git' failed.
>
> The empty repo created by init-db should be cloneable, so as to get the ball
> rolling easily.
Well there's really nothing to clone, so it's tough. :-) What would such
a clone be supposed to do? It has no branches to record as belonging to
origin, and note that Git's git-clone is long-term broken in the sense
that it won't pick new branches as they appear in the remote
repository. So a clone of an empty repository would be useless anyway.
> You can't push into such an empty repository either.
This is supposed to work. What error do you get?
> Any suggestion of how to set up a server into which users can create their
> own repos /without/ giving out full shell accounts?
Sure:
http://repo.or.cz/w/repo.git
But it may be quite an overkill for you. ;-)
If you want them to be able to do it over ssh, you would need to provide
a trusted tool which would manage the repository setup, that means not
only doing init-db, but also managing the export-ok files, description
file, you'd likely want to enable the post-update hook (but probably not
any other hook or let the user edit it since at that point you've given
him full shell access), etc. And the tool would have to be carefully
reviewed since it's security-critical.
> Also, the behaviour of git-daemon is different when using git or ssh+git,
> you need to give the full path for the later but not the former (given
> --base-path=/var/scm):
>
> git://git-server/user/Test.git
> ssh+git://git-server/var/scm/user/Test.git
>
> Is this intentional?
git+ssh has nothing to do with git-daemon, it's executing other git
commands remotely.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Creating new repos
From: Horst H. von Brand @ 2006-10-27 12:29 UTC (permalink / raw)
To: git
I'm trying to set up git repos for remote access here. I set up git-daemon
and got it working (some older repositories do work fine), but now:
$ mkdir /var/scm/user/SomeRepo.git
$ cd /var/scm/user/SomeRepo.git
$ git --bare init-db
$ touch git-daemon-export-ok
All OK, but then, from a remote machine:
$ git clone git://git-server/user/SomeRepo.git
fatal: no matching remote head
fetch-pack from 'git://git-server/user/Test.git' failed.
The empty repo created by init-db should be cloneable, so as to get the ball
rolling easily.
You can't push into such an empty repository either.
Any suggestion of how to set up a server into which users can create their
own repos /without/ giving out full shell accounts?
Also, the behaviour of git-daemon is different when using git or ssh+git,
you need to give the full path for the later but not the former (given
--base-path=/var/scm):
git://git-server/user/Test.git
ssh+git://git-server/var/scm/user/Test.git
Is this intentional?
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-27 11:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Horst H. von Brand, git, bazaar-ng
In-Reply-To: <8fe92b430610270349k36a39250i7173282aa81c04e7@mail.gmail.com>
Jakub Narebski wrote:
> On 10/27/06, Andreas Ericsson <ae@op5.se> wrote:
>> Horst H. von Brand wrote:
>>> Jakub Narebski <jnareb@gmail.com> wrote:
>>>
>>> [...]
>>>
>>>> I'd rather split "Supports Renames" into engine part (does SCM
>>>> remember/detect that rename took place _as_ rename, not remember/detect
>>>> it as copiying+deletion; something other than rename) and user
>>>> interface
>>>> part: can user easily deal with renames (this includes merging and
> viewing file
>>>> history).
>>>
>>> I think that what to tool does in its guts is completely irrelevant,
>>> what
>>> is important is what the user sees. Sadly, it seems hard to describe
>>> exactly what is meant/wanted here.
>>
>> Agreed. I'd rather make the definition "Can users, after a rename has
>> taken place, follow the history of the file-contents across renames?".
>> Mainly because this is clearly unambiguous, doesn't involve
>> implementation details and only weighs what really counts: User-visible
>> capabilities.
>
[...]
> But equally important for user is another question related to
> "Supporting Renames".
> Namely detection of renames during merge and detection of conflict
> during merge
> is what I would consider minimal "Merge Renames Support". Causing
> information
> to be lost is having no "Merge Renames Support". To have "Yes" in this
> column SCM
> have to resolve conflict at least in obvious cases, and "Yes!" if it
> can remember
> resolution of merge conflict involving renames ;-).
>
True.
>> IMNSHO, I'd rather have all the features in the list be along the lines
>> of "Can users/admins/random-boon do X?" and instead of "yes/no" list the
>> number of commands/the amount of time required to achieve the desired
>> effect. This would set a clear limit and put most terminology issues out
>> of the way.
>
> This would make the comparison table less clear, unfortunately.
>
True that. Perhaps just stick with Yes/No and have a timing table to
compare merge times, multi-parent merge times and stuff like that.
>
>>> [...]
>>>
>>>> 19. Ease of Use. Hmmm... I don't know for Git. I personally find it
>>>> very
>>>> easy to use, but I have not much experiences with other SCM. I
>>>> wonder why
>>>> Bazaar has "No" there...
>>>
>>> Extremely subjective. Easy to learn doesn't cut it either.
>>
>> This one just needs to go. Could possibly be replaced with "Has
>> tutorial/documentation online" or some such. No SCM is really intuitive
>> to users that haven't experienced any of them before, so the only thing
>> that really matters is how much documentation one can find online and
>> how up-to-date it is.
>
> For example SCM can be easy to use but at the cost of simplifications
> and limited useness.
>
> On the other side basic concept behind some SCM might be more
> or less understandable...
Yes, but it will always be based on personal opinion and that's why it
can never be measured in an unbiased way. It would be like playing
Trivial Pursuit and getting the question "Which 20'th century author
wrote the best books?". There's actually two problems with that
question, but the important one is that it can't be answered correctly
in this wonderful world we live in where everyone has their own opinion.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-27 10:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Horst H. von Brand, git, bazaar-ng
In-Reply-To: <4541D291.5020205@op5.se>
On 10/27/06, Andreas Ericsson <ae@op5.se> wrote:
> Horst H. von Brand wrote:
>> Jakub Narebski <jnareb@gmail.com> wrote:
>>
>> [...]
>>
>>> I'd rather split "Supports Renames" into engine part (does SCM
>>> remember/detect that rename took place _as_ rename, not remember/detect
>>> it as copiying+deletion; something other than rename) and user interface
>>> part: can user easily deal with renames (this includes merging and
viewing file
>>> history).
>>
>> I think that what to tool does in its guts is completely irrelevant, what
>> is important is what the user sees. Sadly, it seems hard to describe
>> exactly what is meant/wanted here.
>
> Agreed. I'd rather make the definition "Can users, after a rename has
> taken place, follow the history of the file-contents across renames?".
> Mainly because this is clearly unambiguous, doesn't involve
> implementation details and only weighs what really counts: User-visible
> capabilities.
With this definition (with this part) it would be "Somewhat" for Git, because
user can track the history of file-contents across renames, but some additional
steps are required... until --follow=<pathname> would get implemented, that is.
Yet "tracking file-contents across renames" is based on specific workflow used;
for example with Git you usually track [some part of] history of some subpart
of a project, not history of single file. (I'd name it "History Rename Support"
or "Log Rename Support").
But equally important for user is another question related to
"Supporting Renames".
Namely detection of renames during merge and detection of conflict during merge
is what I would consider minimal "Merge Renames Support". Causing information
to be lost is having no "Merge Renames Support". To have "Yes" in this
column SCM
have to resolve conflict at least in obvious cases, and "Yes!" if it
can remember
resolution of merge conflict involving renames ;-).
> IMNSHO, I'd rather have all the features in the list be along the lines
> of "Can users/admins/random-boon do X?" and instead of "yes/no" list the
> number of commands/the amount of time required to achieve the desired
> effect. This would set a clear limit and put most terminology issues out
> of the way.
This would make the comparison table less clear, unfortunately.
>>> 13. Plugins. I would put "Somewhat" here, or "Scriptable" in the "Somewhat"
>>> or "?" background color for Git. And add note that it is easy to script up
>>> porcelanish command, and to add another merge strategy. There also was
>>> example plugin infrastructure for Cogito, so I'd opt for "Someahwt"
>>> marking.
>>
>> Mostly an implementation detail for "extensible"...
>>
>
> Yup. Any fast-growing SCM can clearly be said to be "extensible",
> otherwise it wouldn't be extended ;-)
I'd put "Easily Extensible" here, and put "Plugins (core+UI)" for Bazaar-NG,
and "Scriptable (UI+merge)" for Git, or something like that.
>> [...]
>>
>>> 19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
>>> easy to use, but I have not much experiences with other SCM. I wonder why
>>> Bazaar has "No" there...
>>
>> Extremely subjective. Easy to learn doesn't cut it either.
>
> This one just needs to go. Could possibly be replaced with "Has
> tutorial/documentation online" or some such. No SCM is really intuitive
> to users that haven't experienced any of them before, so the only thing
> that really matters is how much documentation one can find online and
> how up-to-date it is.
For example SCM can be easy to use but at the cost of simplifications
and limited useness.
On the other side basic concept behind some SCM might be more
or less understandable...
--
^ permalink raw reply
* Re: gitweb.cgi and git instaweb
From: Petr Baudis @ 2006-10-27 10:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Aneesh Kumar K.V, git
In-Reply-To: <7v8xj2i6hb.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Oct 27, 2006 at 09:05:20AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Removing the extraneous undef would also be a good idea,
> wouldn't it?
25746 F Oct 26 Petr Baudis ( 0.9K) [PATCH] gitweb: Fix up bogus $stylesheet declarations
?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Junio C Hamano @ 2006-10-27 10:02 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4541D670.6000900@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Alex Riesen wrote:
>>>> >Which leads us to the always interesting, fun and exciting:
>>>> >
>>>> > git ls-tree -r HEAD | git update-index --index-info
>>>> >
>>>> >which will undo everything except 'git add' from the index, as
>>>> >ls-tree -r is listing everything in the last commit.
>>>> >
>>>>
>>>> ... and also shows The Power of the Pipe, which Daniel@google was
>>>> missing in recent versions of git. ;-)
>>>>
>>>> Btw, this is most definitely not a documented thing and requires a bit
>>>> of core git knowledge, so perhaps the "shell-scripts were good for
>>>> hackers to learn what to pipe where" really *is* a very important point.
>>>
>>> Agreed.
>>
>> Still, it is very impressive, it is supported (and will be
>> supported, I assume),
>> and as such - worth mentioning at least in these examples everyone keeps
>> dreaming about. Until that happened, why not mention that the output
>> of "git ls-tree" is compatible with --index-info of "update-index"?
>
> +1. Me likes, although I would amend the command-line that Shawn sent
> and describe what it does. Examples > descriptions everywhere else in
> the git docs, so it would be concise to do so.
I do not like the one that does the whole tree that much. I
would think "git-read-tree -m HEAD" would be simpler and more
efficient if you are reverting the whole tree.
On the other hand, I designed --index-info to be compatible with
ls-tree output (it is not an accident, it was designed). In
git ls-tree HEAD frotz | git update-index --index-info
"frotz" part does not have to be the exact path but can be a
directory name. It means "revert everything in this directory".
This is quite heavy-handed and you would probably want to run
update-index --refresh afterwards.
^ permalink raw reply
* Re: StGit-enabled bash-prompt
From: Ben Clifford @ 2006-10-27 10:01 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200610262317.30209.robin.rosenberg.lists@dewire.com>
On Thu, 26 Oct 2006, Robin Rosenberg wrote:
> Of course you will read and understand this code. I don't know how good an
> idea it is to use the DEBUG trap this way.
I set my prompt without using it, with something approximating this
being defined in my .bash_profile. I think the use of ' instead of "
causes evaluation of __prompt_githead be delayed until the prompt is
displayed.
PS1='$(__prompt_githead) '$PS1
__prompt_githead() {
PS_GIT=$(git-symbolic-ref HEAD 2>/dev/null) || exit
echo -n " $(basename $PS_GIT)"
}
--
^ permalink raw reply
* Re: latest git and git.kernel.org
From: Andreas Ericsson @ 2006-10-27 9:51 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <4541CB5D.1000007@gmail.com>
Aneesh Kumar K.V wrote:
> Andreas Ericsson wrote:
>> Aneesh Kumar K.V wrote:
>>> I am getting lot of errors with git.kernel.org in the last few days.
>>> Is it something to do with the latest git client that i am using or
>>> due to issues with git.kernel.org ?
>>>
>>
>> I'm seeing the same, but only against git.kernel.org. repo.or.cz works
>> fine for my, so I've switched to pulling the git repo from there
>> instead. I guess this is an enforced resource policy on kernel.org. I
>> believe the inetd rules there have limits on how many concurrent
>> connections it allows the git-daemon to handle. For example, I often
>> get to pull the actual objects, but it then fails to fetch the tags
>> because of "Unexpected EOF. Connection closed" thingie.
>>
>
>
> That means i need to find mirrors for kernel and git. Any list available
> some where regarding these repositories.
> For the time being i switched to repo.or.cz
Not that I know of. At work we've set up a local mirror. I'm sure many
other companies have done the same. Those that haven't should probably
do so, as it would save their developers time and relieve kernel.org of
some of its stress.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Andreas Ericsson @ 2006-10-27 9:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: Shawn Pearce, Andy Parkins, git
In-Reply-To: <81b0412b0610270245w6c29b3c3va7967991f53db298@mail.gmail.com>
Alex Riesen wrote:
>>> >Which leads us to the always interesting, fun and exciting:
>>> >
>>> > git ls-tree -r HEAD | git update-index --index-info
>>> >
>>> >which will undo everything except 'git add' from the index, as
>>> >ls-tree -r is listing everything in the last commit.
>>> >
>>>
>>> ... and also shows The Power of the Pipe, which Daniel@google was
>>> missing in recent versions of git. ;-)
>>>
>>> Btw, this is most definitely not a documented thing and requires a bit
>>> of core git knowledge, so perhaps the "shell-scripts were good for
>>> hackers to learn what to pipe where" really *is* a very important point.
>>
>> Agreed.
>
> Still, it is very impressive, it is supported (and will be supported, I
> assume),
> and as such - worth mentioning at least in these examples everyone keeps
> dreaming about. Until that happened, why not mention that the output
> of "git ls-tree" is compatible with --index-info of "update-index"?
>
+1. Me likes, although I would amend the command-line that Shawn sent
and describe what it does. Examples > descriptions everywhere else in
the git docs, so it would be concise to do so.
> diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
> index f283bac..0ab9913 100644
> --- a/Documentation/git-ls-tree.txt
> +++ b/Documentation/git-ls-tree.txt
> @@ -64,6 +64,8 @@ Output Format
>
> When the `-z` option is not used, TAB, LF, and backslash characters
> in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
> +This output format is compatible with what "--index-info --stdin" of
> +git-update-index expects.
>
>
> Author
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Alex Riesen @ 2006-10-27 9:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andreas Ericsson, Andy Parkins, git
In-Reply-To: <20061027081545.GF29057@spearce.org>
>> >Which leads us to the always interesting, fun and exciting:
>> >
>> > git ls-tree -r HEAD | git update-index --index-info
>> >
>> >which will undo everything except 'git add' from the index, as
>> >ls-tree -r is listing everything in the last commit.
>> >
>>
>> ... and also shows The Power of the Pipe, which Daniel@google was
>> missing in recent versions of git. ;-)
>>
>> Btw, this is most definitely not a documented thing and requires a bit
>> of core git knowledge, so perhaps the "shell-scripts were good for
>> hackers to learn what to pipe where" really *is* a very important point.
>
> Agreed.
Still, it is very impressive, it is supported (and will be supported, I assume),
and as such - worth mentioning at least in these examples everyone keeps
dreaming about. Until that happened, why not mention that the output
of "git ls-tree" is compatible with --index-info of "update-index"?
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index f283bac..0ab9913 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -64,6 +64,8 @@ Output Format
When the `-z` option is not used, TAB, LF, and backslash characters
in pathnames are represented as `\t`, `\n`, and `\\`, respectively.
+This output format is compatible with what "--index-info --stdin" of
+git-update-index expects.
^ permalink raw reply related
* [BUG] git-cvsexportcommit doesn't handle added directories
From: Peter Baumann @ 2006-10-27 9:38 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff, Yann Dirson
There is a problem in git-cvsexportcommit if I add a directory with some new
files in git. It dies in safe_pipe_capture().
Analysis:
foreach my $f (@afiles) {
# This should return only one value
my @status = grep(m/^File/, safe_pipe_capture('cvs', '-q', 'status' ,$f));
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# OK. Here it tries to run "cvs -q status src/newdirectory/newfile"
[...]
}
[...]
# An alternative to `command` that allows input to be passed as an array
# to work around shell problems with weird characters in arguments
# if the exec returns non-zero we die
sub safe_pipe_capture {
my @output;
if (my $pid = open my $child, '-|') {
@output = (<$child>);
print "before close\n";
close $child or die join(' ',@_).": x$!x y$?y";
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# I changed it to see which error will be printed
print "after close\n";
} else {
exec(@_) or die "$! $?"; # exec() can fail the executable can't be found
}
return wantarray ? @output : join('',@output);
}
Output:
[...]
siprbaum@faui40a.informatik.uni-erlangen.de's password:
cvs [status aborted]: no such directory `src/newdir'
before close
cvs -q status src/newdir/newfile.java: xx y256y at
/home/peter/src/git-cvsexportcommit.perl line 317.
^^^^^
Don't be confused about the wrong line number. I have some other stuff
(formating
the commit message in a special way) in there but I can confirm that the script
dies at the close of the pipe.
Running from a shell the command manually:
xp:~/project/$ cvs -q status src/newdir/newfile
siprbaum@faui40a.informatik.uni-erlangen.de's password:
cvs [status aborted]: no such directory `src/newdir'
xp:~/project/$ echo $?
1
Excerpt from the "perldoc -f close"
[...]
If the file handle came from a piped open, "close" will additionally
return false if
one of the other system calls involved fails, or if the program
exits with non-zero
status. (If the only problem was that the program exited non-zero, $! will be
set to 0.) Closing a pipe also waits for the process executing on the pipe to
complete, in case you want to look at the output of the pipe afterwards, and
implicitly puts the exit status value of that command into $?.
Prematurely closing the read end of a pipe (i.e. before the process
writing to it
at the other end has closed it) will result in a SIGPIPE being
delivered to the
writer. If the other end can't handle that, be sure to read all the
data before
closing the pipe.
So according to the manpage $! should be set to 0, because
"cvs -q status src/newdir/newfile" exits with errorcode 1 as shown above.
Could this have something todo that I have to use ssh to connect to the repo?
(CVSROOT=:extssh:siprbaum@faui40a.informatik.uni-erlangen.de:/path/to/repo)
Any ideas?
Greetings,
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-27 9:34 UTC (permalink / raw)
To: Horst H. von Brand; +Cc: Jakub Narebski, git, bazaar-ng
In-Reply-To: <200610270202.k9R22Wxf004208@laptop13.inf.utfsm.cl>
Horst H. von Brand wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>
> [...]
>
>> I'd rather split "Supports Renames" into engine part (does SCM
>> remember/detect that rename took place _as_ rename, not remember/detect it
>> as copiying+deletion; something other than rename) and user interface part:
>> can user easily deal with renames (this includes merging and viewing file
>> history).
>
> I think that what to tool does in its guts is completely irrelevant, what
> is important is what the user sees. Sadly, it seems hard to describe
> exactly what is meant/wanted here.
>
Agreed. I'd rather make the definition "Can users, after a rename has
taken place, follow the history of the file-contents across renames?".
Mainly because this is clearly unambiguous, doesn't involve
implementation details and only weighs what really counts: User-visible
capabilities.
IMNSHO, I'd rather have all the features in the list be along the lines
of "Can users/admins/random-boon do X?" and instead of "yes/no" list the
number of commands/the amount of time required to achieve the desired
effect. This would set a clear limit and put most terminology issues out
of the way.
>
>> 13. Plugins. I would put "Somewhat" here, or "Scriptable" in the "Somewhat"
>> or "?" background color for Git. And add note that it is easy to script up
>> porcelanish command, and to add another merge strategy. There also was
>> example plugin infrastructure for Cogito, so I'd opt for "Someahwt"
>> marking.
>
> Mostly an implementation detail for "extensible"...
>
Yup. Any fast-growing SCM can clearly be said to be "extensible",
otherwise it wouldn't be extended ;-)
> [...]
>
>> 19. Ease of Use. Hmmm... I don't know for Git. I personally find it very
>> easy to use, but I have not much experiences with other SCM. I wonder why
>> Bazaar has "No" there...
>
> Extremely subjective. Easy to learn doesn't cut it either.
This one just needs to go. Could possibly be replaced with "Has
tutorial/documentation online" or some such. No SCM is really intuitive
to users that haven't experienced any of them before, so the only thing
that really matters is how much documentation one can find online and
how up-to-date it is.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH] Improve git-prune -n output
From: Junio C Hamano @ 2006-10-27 9:09 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610270920.06064.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> The only problem with that is that the type string is of
> variable width, while the hash is fixed; hence <hash> <type>
> is more visually appealing than <type> <hash>.
>
> Does it really matter anyway?
I would rather question if the alignment really matters. You
could always printf("%10s %s\n", type, hex) if you really cared,
though.
> ... Some sort of processing would have to happen
> before using git-prune output as git-cat-file parameters...
>
> git-prune -n |
> while read hash type
> do
> git-cat-file $type $hash
> done
which is probably not the way in which the command output is
going to be used. I'd expect a sequence more like:
$ git prune -n
blob deadbeefdeadbeef...
commit deadbeefdeadbeef...
...
The user would not just pipe all of the output to cat-file, but
would pick ones that are meaningful to be cat'ed (commit and
perhaps blob but definitely not tree). And the cue to pick
which ones would likely to be the object type not hash, so in
that sense type-then-hash might be easier to read.
Having said that, a potentially useful application would be "a
backup before prune" which can be done more easily if you use
hash-then-type: "git prune -n | git pack-objects backup"
So while I do not think it matters that much, I slightly prefer
hash-then-type better than type-then-hash.
^ permalink raw reply
* Re: latest git and git.kernel.org
From: Aneesh Kumar K.V @ 2006-10-27 9:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4541C123.8000203@op5.se>
Andreas Ericsson wrote:
> Aneesh Kumar K.V wrote:
>> I am getting lot of errors with git.kernel.org in the last few days.
>> Is it something to do with the latest git client that i am using or
>> due to issues with git.kernel.org ?
>>
>
> I'm seeing the same, but only against git.kernel.org. repo.or.cz works
> fine for my, so I've switched to pulling the git repo from there
> instead. I guess this is an enforced resource policy on kernel.org. I
> believe the inetd rules there have limits on how many concurrent
> connections it allows the git-daemon to handle. For example, I often get
> to pull the actual objects, but it then fails to fetch the tags because
> of "Unexpected EOF. Connection closed" thingie.
>
That means i need to find mirrors for kernel and git. Any list available some where regarding these repositories.
For the time being i switched to repo.or.cz
^ permalink raw reply
* [PATCH] Added description for inverting git-update-index using --index-info
From: Andy Parkins @ 2006-10-27 9:03 UTC (permalink / raw)
To: git
In-Reply-To: <200610261641.11239.andyparkins@gmail.com>
I wanted to restore a single file from HEAD back to the index; Shawn Pearce
gave me the answer. git-ls-tree piped to git-update-index --index-info.
This patch adds that answer to the git-update-index documentation.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-update-index.txt | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 41bb7e1..5adf717 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -215,6 +215,24 @@ $ git ls-files -s
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
------------
+One particular use of --index-info is to reverse the effect of
+"git-update-index frotz":
+
+------------
+git ls-tree HEAD frotz | git update-index --index-info
+------------
+
+This makes the index hold the file frotz from HEAD rather than from the
+working copy. Similarly:
+
+------------
+git ls-tree -r HEAD | git update-index --index-info
+------------
+
+Will undo everything except "git add" from the index, as
+"git-ls-tree -r" lists everything in the last commit.
+
+
Using "assume unchanged" bit
----------------------------
--
1.4.3.3.g5bca6
^ permalink raw reply related
* Re: gitweb.cgi and git instaweb
From: Aneesh Kumar K.V @ 2006-10-27 8:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xj2i6hb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Aneesh Kumar K.V" <aneesh.kumar@gmail.com> writes:
>
>> Aneesh Kumar K.V wrote:
>>> I am getting errors as below with git instaweb.
>>>
>>>
>>> kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ git instaweb
>>> 2006-10-27 00:12:56: (log.c.75) server started
>>> kvaneesh@satan:/home/opensource/vanilla/linux-2.6-git$ [Fri Oct 27
>>> 00:12:57 2006] gitweb.cgi: "our" variable $stylesheet masks earlier
>>> declaration in same scope at
>>>
>> The attached patch should fix it.
>>
>> -aneesh
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index ba7a42a..1962c76 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -55,8 +55,6 @@ our $stylesheet;
>> # default is not to define style sheet, but it can be overwritten later
>> undef $stylesheet;
>>
>> -# URI of default stylesheet
>> -our $stylesheet = "++GITWEB_CSS++";
>> # URI of GIT logo (72x27 size)
>> our $logo = "++GITWEB_LOGO++";
>> # URI of GIT favicon, assumed to be image/png type
>
> Removing the extraneous undef would also be a good idea,
> wouldn't it?
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index aceaeb7..7999b1a 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -51,12 +51,10 @@ our $site_footer = "++GITWEB_SITE_FOOTER
>
> # URI of stylesheets
> our @stylesheets = ("++GITWEB_CSS++");
> -our $stylesheet;
> -# default is not to define style sheet, but it can be overwritten later
> -undef $stylesheet;
> -
> # URI of default stylesheet
> -our $stylesheet = "++GITWEB_CSS++";
> +# default is not to define style sheet, but it can be overwritten later.
> +our $stylesheet = undef;
> +
> # URI of GIT logo (72x27 size)
> our $logo = "++GITWEB_LOGO++";
> # URI of GIT favicon, assumed to be image/png type
>
ACK
^ permalink raw reply
* Re: Rationale for the "Never commit to the right side of a Pull line" rule
From: Luben Tuikov @ 2006-10-27 8:56 UTC (permalink / raw)
To: t2a2e9z8ncbs9qg, git
In-Reply-To: <ehqp1u$j4$1@sea.gmane.org>
--- Jerome Lovy <t2a2e9z8ncbs9qg@brefemail.com> wrote:
> Hi,
>
> Could someone please point me to / give me the rationale for the "Never
> commit to the right side of a Pull line" rule ?
>
> I found the rule in the second Note of the git-fetch man-page (eg
> http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html).
>
> It's been taken over in _bold letters_ by X.Org/freedesktop.org in their
> "UsingGit" document (http://freedesktop.org/wiki/UsingGit).
>
> In both places though, I don't see any explanation, but rather a
> commandment ;-) . Am I missing the ovious ?
Yes, you are missing the obvious and yes it is explained.
Read the 2nd "Note" for the documentation of "git-fetch":
http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html
Quoted here for convenience:
[NOTE]
You never do your own development on branches that appear
on the right hand side of a <refspec> colon on `Pull:` lines;
they are to be updated by `git-fetch`. If you intend to do
development derived from a remote branch `B`, have a `Pull:`
line to track it (i.e. `Pull: B:remote-B`), and have a separate
branch `my-B` to do your development on top of it. The latter
is created by `git branch my-B remote-B` (or its equivalent `git
checkout -b my-B remote-B`). Run `git fetch` to keep track of
the progress of the remote side, and when you see something new
on the remote branch, merge it into your development branch with
`git pull . remote-B`, while you are on `my-B` branch.
The common `Pull: master:origin` mapping of a remote `master`
branch to a local `origin` branch, which is then merged to a
local development branch, again typically named `master`, is made
when you run `git clone` for you to follow this pattern.
Luben
>
> My candid thoughts: to me the practice recommended here seems
> subjectively "cleaner" indeed, but is it objectively better or even
> essential? Why?
>
> TIA
> Jérôme
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH] Improve git-prune -n output
From: Andy Parkins @ 2006-10-27 8:37 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkn3kn65.fsf@assigned-by-dhcp.cox.net>
prune_object() in show_only mode would previously just show the path to the
object that would be deleted. The path the object is stored in shouldn't be
shown to users, they only know about sha1 identifiers so show that instead.
Further, the sha1 alone isn't that useful for examining what is going to be
deleted. This patch also adds the object type to the output, which makes it
easy to pick out, say, the commits and use git-show to display them.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Fixes issues from...
Junio C Hamano
Do not leave blank inside () pairs.
Do not enclose a single statement in {}.
No longer uses strcpy()
Petr Baudis
"unknown type" is now simply "unknown"
Andy Parkins
No longer outputs "would prune"
builtin-prune.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-prune.c b/builtin-prune.c
index 7290e6d..b8b2d05 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -16,8 +16,14 @@ static struct rev_info revs;
static int prune_object(char *path, const char *filename, const unsigned char
*sha1)
{
+ char buf[20];
+ const char *type;
+
if (show_only) {
- printf("would prune %s/%s\n", path, filename);
+ type = buf;
+ if (sha1_object_info(sha1, type, NULL))
+ type = "unknown";
+ printf("%s %s\n", sha1_to_hex(sha1), type );
return 0;
}
unlink(mkpath("%s/%s", path, filename));
--
1.4.3.3.g5bca6
^ permalink raw reply related
* Re: [PATCH] Improve git-prune -n output
From: Andy Parkins @ 2006-10-27 8:19 UTC (permalink / raw)
To: git
In-Reply-To: <4540F16F.4060604@shadowen.org>
On Thursday 2006 October 26 18:33, Andy Whitcroft wrote:
> If we are changing the format would it not make more sense to be in the
> same order as the tool that lets you use it?
>
> I thought that was git cat-file <type> <commit-ish>
The only problem with that is that the type string is of variable width, while
the hash is fixed; hence <hash> <type> is more visually appealing than <type>
<hash>.
Does it really matter anyway? Some sort of processing would have to happen
before using git-prune output as git-cat-file parameters...
git-prune -n |
while read hash type
do
git-cat-file $type $hash
done
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: latest git and git.kernel.org
From: Andreas Ericsson @ 2006-10-27 8:19 UTC (permalink / raw)
To: Aneesh Kumar K.V; +Cc: git
In-Reply-To: <ehqvgs$sla$1@sea.gmane.org>
Aneesh Kumar K.V wrote:
> I am getting lot of errors with git.kernel.org in the last few days. Is
> it something to do with the latest git client that i am using or due to
> issues with git.kernel.org ?
>
I'm seeing the same, but only against git.kernel.org. repo.or.cz works
fine for my, so I've switched to pulling the git repo from there
instead. I guess this is an enforced resource policy on kernel.org. I
believe the inetd rules there have limits on how many concurrent
connections it allows the git-daemon to handle. For example, I often get
to pull the actual objects, but it then fails to fetch the tags because
of "Unexpected EOF. Connection closed" thingie.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Shawn Pearce @ 2006-10-27 8:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Andy Parkins, git
In-Reply-To: <4541BE8E.5050605@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Shawn Pearce wrote:
> >Andy Parkins <andyparkins@gmail.com> wrote:
> >>However, it led me to wonder what the inverse of git-update-index is.
> >
> >git-update-index :-)
> >
> >You can use something like:
> >
> > git ls-tree HEAD oops/file1 | git update-index --index-info
> >
> >to restore the index state of oops/file1.
> >
> >
> >Which leads us to the always interesting, fun and exciting:
> >
> > git ls-tree -r HEAD | git update-index --index-info
> >
> >which will undo everything except 'git add' from the index, as
> >ls-tree -r is listing everything in the last commit.
> >
>
> ... and also shows The Power of the Pipe, which Daniel@google was
> missing in recent versions of git. ;-)
>
> Btw, this is most definitely not a documented thing and requires a bit
> of core git knowledge, so perhaps the "shell-scripts were good for
> hackers to learn what to pipe where" really *is* a very important point.
Agreed.
I learned that trick while studying the update-index source code
and tried to wrap my tiny little head around the various formats
--index-info accepts and how that code automatically guesses the
correct format. :-)
Though I have to admit I wipped up a little test repository just
to make sure what I was writing in the email worked properly;
I can't say I've done it myself too many times in the past...
--
^ permalink raw reply
* Re: fetching packs and storing them as packs
From: Shawn Pearce @ 2006-10-27 8:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: Eran Tromer, Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <81b0412b0610270108t7b93d04y2c99be20b7f41387@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> >>>So the receive-pack process becomes:
> >>>
> >>> a. Create temporary pack file in $GIT_DIR/objects/pack_XXXXX.
> >>>b. Create temporary index file in $GIT_DIR/objects/index_XXXXX.
> >>
> >>Why not $GIT_DIR/objects/tmp/pack... and ignore it everywhere?
> >
> >Because there is a race condition.
>
> Oh, right. Incidentally, is there a lockfile for packs?
No, we have never needed them before. And I think we'd like to
avoid adding them now.
We do have the rule that a pack can only be accessed if its .idx
file exists; therefore we generate a pack and its index, then place
the pack into the object directory, then the index. That way the
pack is there before the index but another process won't attempt
to read the pack until the index exists. It also means we should
never put an index into the pack directory before its associated
pack. :-)
If we are pruneing packs or loose objects after the repack we delete
only after the pack and index are in place. Running processes
rescan the existing packs once if they look for an object and
cannot find it in the loose objects directory or in the packs it
already knows about; this lets most running processes automatically
recover should a parallel repack delete the loose objects it needs
(as they were just packed).
--
^ 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