* Re: ident hash usage question
From: Eugene Sajine @ 2009-10-20 18:59 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Eugene Sajine
In-Reply-To: <81b0412b0910201119w7583487ag276cf964d0a85e@mail.gmail.com>
>
> Well, not exactly impossible, but you can end up with multiple paths,
> some of which may not have anything to do the original path.
>
> Just run git log --no-abbrev --raw --all and grep for the SHA-1
>
This is exactly what I was looking for! Thank you!
I understand that in some cases this can give me two paths instead of
one, but it will only demonstrate that I have absolute copy of a file
inside my repo, which is also good to diagnose (because the
probability of having two meaningful files with the same hash, but
different content is way too low).
So, this means that after few little tricks the keyword expansion
problem may be resolved by only using $Id$ keyword.
Because after having this hash one can build up all necessary info from it:
#finding blobs with SHA indicated in $Id$ keword
$ git log --no-abbrev --raw --all | grep SHA-1
# little script or regexp here (don’t have it)
$ pull out path from result
# last commit for the path with all corresponding info
$ git log -1 HEAD path
So, this seems to cover most of the needs of people who would like to
use keywords expansion, if they are not ready to forget about them…
Does it make sense?
Thanks,
Eugene
^ permalink raw reply
* [RFC/PATCH] fsck: default to "git fsck --full"
From: Junio C Hamano @ 2009-10-20 18:46 UTC (permalink / raw)
To: Matthieu Moy
Cc: Johannes Schindelin, Alex Riesen, Johannes Sixt, Sergio Callegari,
git
In-Reply-To: <vpq1vkygtx6.fsf@bauges.imag.fr>
Linus and other git developers from the early days trained their fingers
to type the command, every once in a while even without thinking, to check
the consistency of the repository back when the lower core part of the git
was still being developed. Developers who wanted to make sure that git
correctly dealt with packfiles could deliberately trigger their creation
and checked them after they were created carefully, but loose objects are
the ones that are written by various commands from random codepaths. It
made some technical sense to have a mode that checked only loose objects
from the debugging point of view for that reason.
Even for git developers, there no longer is any reason to type "git fsck"
every five minutes these days, worried that some newly created objects
might be corrupt due to recent change to git.
The reason we did not make "--full" the default is probably we trust our
filesystems a bit too much. At least, we trusted filesystems more than we
trusted the lower core part of git that was under development.
Once a packfile is created and we always use it read-only, there didn't
seem to be much point in suspecting that the underlying filesystems or
disks may corrupt them in such a way that is not caught by the SHA-1
checksum over the entire packfile and per object checksum. That trust in
the filesystems might have been a good tradeoff between fsck performance
and reliability on platforms git was initially developed on and for, but
it may not be true anymore as we run on many more platforms these days.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
>> On Tue, 20 Oct 2009, Alex Riesen wrote:
>> ...
>>> --no-full works
>>
>> It works. Technically. For human users, though, --loose-objects-only
>> (with a shortcut "--loose") would be better.
>
> OTOH, the advantage of "--no-full" is that it's compatible with
> existing Git versions. If I learn Git 1.6.6 with --no-full, and use it
> in a script, then my stript works also with older Gits.
>
> But anyway, I think very few people are actually interested in "git
> --no-full" (or call it whatever you like), so I don't think this is
> very important.
For human users, I think --full vs --no-full is quite a nice suggestion,
given that we already have advertised --full and people know the option.
Also people know that splicing "no-" after the double dash is often the
way to negate a boolean-looking option.
The actual patch to do this is tiny, but that is just a bonus ;-)
Documentation/RelNotes-1.6.6.txt | 10 ++++++++++
Documentation/git-fsck.txt | 5 +++--
builtin-fsck.c | 2 +-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/Documentation/RelNotes-1.6.6.txt b/Documentation/RelNotes-1.6.6.txt
index 5f1fecb..1896e05 100644
--- a/Documentation/RelNotes-1.6.6.txt
+++ b/Documentation/RelNotes-1.6.6.txt
@@ -1,6 +1,13 @@
GIT v1.6.6 Release Notes
========================
+In this release, "git fsck" defaults to "git fsck --full" and checks
+packfiles. If you prefer a quicker check only on loose objects (the
+old default), you can say "git fsck --no-full". This has been
+supported by 1.5.4 and newer versions of git, so it is safe to write
+it in your script if you use slightly older git on some of your
+machines.
+
In git 1.7.0, which is planned to be the release after 1.6.6, "git
push" into a branch that is currently checked out will be refused by
default.
@@ -38,6 +45,9 @@ Updates since v1.6.5
(usability, bells and whistles)
+ * "git fsck" by default checks the packfiles (i.e. "--full" is the
+ default); you can turn it off with "git fsck --no-full".
+
* "git log --decorate" shows the location of HEAD as well.
(developers)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 287c4fc..6fe9484 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--full] [--strict] [--verbose] [--lost-found] [<object>*]
+ [--[no-]full] [--strict] [--verbose] [--lost-found] [<object>*]
DESCRIPTION
-----------
@@ -52,7 +52,8 @@ index file, all SHA1 references in .git/refs/*, and all reflogs (unless
or $GIT_DIR/objects/info/alternates,
and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
- object pools.
+ object pools. This is now default; you can turn it off
+ with --no-full.
--strict::
Enable more strict checking, namely to catch a file mode
diff --git a/builtin-fsck.c b/builtin-fsck.c
index c58b0e3..2d88e45 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -19,7 +19,7 @@ static int show_root;
static int show_tags;
static int show_unreachable;
static int include_reflogs = 1;
-static int check_full;
+static int check_full = 1;
static int check_strict;
static int keep_cache_objects;
static unsigned char head_sha1[20];
^ permalink raw reply related
* Re: [RFC! PATCH] pull: refuse complete src:dst fetchspec arguments
From: Thomas Rast @ 2009-10-20 18:37 UTC (permalink / raw)
To: git
In-Reply-To: <d561e70f0aa802ceb96eba16d3bb2316134d69c8.1256062808.git.trast@student.ethz.ch>
Thomas Rast wrote:
> git-pull has historically accepted full fetchspecs, meaning that you
> could do
>
> git pull $repo A:B
>
> which would simultaneously fetch the remote branch A into the local
> branch B and merge B into HEAD. This got especially confusing if B
> was checked out. New users variously mistook pull for fetch or read
> that command as "merge the remote A into my B", neither of which is
> correct.
>
> Since the above usage should be very rare and can be done with
> separate calls to fetch and merge, we just disallow full fetchspecs in
> git-pull.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Argh. This was actually supposed to be an *RFC* patch.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] pull: refuse complete src:dst fetchspec arguments
From: Thomas Rast @ 2009-10-20 18:23 UTC (permalink / raw)
To: git
git-pull has historically accepted full fetchspecs, meaning that you
could do
git pull $repo A:B
which would simultaneously fetch the remote branch A into the local
branch B and merge B into HEAD. This got especially confusing if B
was checked out. New users variously mistook pull for fetch or read
that command as "merge the remote A into my B", neither of which is
correct.
Since the above usage should be very rare and can be done with
separate calls to fetch and merge, we just disallow full fetchspecs in
git-pull.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
This actually came up on IRC *twice* this week.
git-pull.sh | 19 +++++++++++++++++++
t/t5520-pull.sh | 12 ------------
2 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index fc78592..8f06491 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -131,6 +131,25 @@ error_on_no_merge_candidates () {
exit 1
}
+check_full_fetchspec () {
+ shift # discard remote argument, if any
+ for arg in "$@"
+ do
+ case "$arg" in
+ *:*)
+ echo "$arg"
+ return
+ ;;
+ esac
+ done
+}
+
+full_fetchspec=$(check_full_fetchspec "$@")
+if test -n "$full_fetchspec"
+then
+ die "full fetchspec '$full_fetchspec' not allowed"
+fi
+
test true = "$rebase" && {
if ! git rev-parse -q --verify HEAD >/dev/null
then
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index dd2ee84..a566a99 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -29,18 +29,6 @@ test_expect_success 'checking the results' '
diff file cloned/file
'
-test_expect_success 'pulling into void using master:master' '
- mkdir cloned-uho &&
- (
- cd cloned-uho &&
- git init &&
- git pull .. master:master
- ) &&
- test -f file &&
- test -f cloned-uho/file &&
- test_cmp file cloned-uho/file
-'
-
test_expect_success 'test . as a remote' '
git branch copy master &&
--
1.6.5.1.144.g40216
^ permalink raw reply related
* Re: ident hash usage question
From: Alex Riesen @ 2009-10-20 18:19 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <81b0412b0910201116s694d7877rda872b368f1ae09a@mail.gmail.com>
On Tue, Oct 20, 2009 at 20:16, Alex Riesen <raa.lkml@gmail.com> wrote:
> On Tue, Oct 20, 2009 at 19:24, Eugene Sajine <euguess@gmail.com> wrote:
>> I was able to get the $Id$ keyword to show the SHA-1 hash of the file
>> content, which is done using ident in gitattributes. Now I’m trying to
>> find a way to get more info about the file using only this hash.
>>
>> Could you , please, advise if there is a way to get file name and path
>> inside the repo by having only this Blob hash?
>
> It is not possible.
>
Well, not exactly impossible, but you can end up with multiple paths,
some of which may not have anything to do the original path.
Just run git log --no-abbrev --raw --all and grep for the SHA-1
^ permalink raw reply
* Re: ident hash usage question
From: Alex Riesen @ 2009-10-20 18:16 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910201024x58ffdd3bs6f4cc6932ac31868@mail.gmail.com>
On Tue, Oct 20, 2009 at 19:24, Eugene Sajine <euguess@gmail.com> wrote:
> I was able to get the $Id$ keyword to show the SHA-1 hash of the file
> content, which is done using ident in gitattributes. Now I’m trying to
> find a way to get more info about the file using only this hash.
>
> Could you , please, advise if there is a way to get file name and path
> inside the repo by having only this Blob hash?
It is not possible.
But you can save the commits hash in your blob. Then you'll have everything.
That how git knows it's version.
^ permalink raw reply
* [RFC] pull/fetch rename
From: Thomas Rast @ 2009-10-20 17:47 UTC (permalink / raw)
To: git; +Cc: Björn Steinbrink
Hi all,
While everyone is busy in two other UI threads, I figured I might as
well toss up another (probably) controversial topic.
Especially on IRC, we see many people who are some combination of
misunderstanding, misusing or overusing git-pull. I figure this is
the result of several factors, notably
a) pull/push are not symmetric,
b) guides/tutorials recommend pull for situations where they
shouldn't,
c) people blindly fire commands at git.
While the latter two are probably hopeless, I find (a) rather
annoying. It breaks everyone's intuition of git-pull when they first
see it. (I know that BK has a pull that also merges, but I gather
from the manual [never used it] that you cannot do the equivalent of
git-fetch in BK.)
As you probably guessed by now, here is an idea for a very aggressive
transition plan to address (a) in four phases:
1. git-fetch gets options --merge/-m and --rebase that make it behave
like (current) git-pull, but requiring explicit arguments.
git-pull gets a new option --merge (-m) that only enforces presence
of arguments.
2. git-pull refuses to do any work unless given either --merge or
--rebase. Deprecation warnings for this start at the same time as
(1.).
3. git-pull becomes a synonym for git-fetch.
4. git-fetch gives deprecation warnings that point the user to
git-pull instead.
(1.) is probably harmless and could be put into any particular
release. (2.) obviously breaks everyone's favourite script and needs
to fall on a major release. (3.) should be delayed significantly from
(2.) to allow time to expose such breakage, and similarly (4.) should
be delayed after (3.) (or just ignored, but in any case git-pull would
become the preferred spelling).
As you probably noticed, while 'git pull $remote $ref' only needs to
be changed to 'git pull --merge $remote $ref', this leaves a gap at
the current functionality of 'git pull' without arguments. Björn laid
out a nice suggestion for a git-update in
http://article.gmane.org/gmane.comp.version-control.git/130679
briefly summarised as: git-update would cover what 'git pull' (without
arguments) does right now. However, it could also be restricted to
fast-forward updates by default (with per-branch configurability as
with current git-pull).
Comments? Flames? Improvements?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* ident hash usage question
From: Eugene Sajine @ 2009-10-20 17:24 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
Please correct me if I’m missing something, but:
I was able to get the $Id$ keyword to show the SHA-1 hash of the file
content, which is done using ident in gitattributes. Now I’m trying to
find a way to get more info about the file using only this hash.
Could you , please, advise if there is a way to get file name and path
inside the repo by having only this Blob hash?
Thank you,
Eugene
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Junio C Hamano @ 2009-10-20 17:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andy Isaacson, git, Nicolas Pitre, Alex Riesen
In-Reply-To: <7viqeaovmp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>> We now abort the loop if inflate() returns Z_BUF_ERROR without
>> consuming the entire input buffer it was given, or has filled
>> the entire output buffer but has not yet returned Z_STREAM_END.
>> Either state is a clear indicator that this loop is not working
>> as expected, and should not continue.
>
> When the inflated contents is of size 0, avail_out would be 0 and avail_in
> would still have something because the input stream needs to have the end
> of stream marker that is more than zero byte long.
After thinking about this a bit more, I am reasonably sure that this is
it. The contents does not have to be a 0-length string, but you would hit
this if the pure-data portion of the deflated stream aligns at the end of
your (un)pack window and it happens to require another use_pack() to move
the window to read the end-of-stream signal. In that situation, the
output buffer has already been filled, but you haven't read the input
stream fully. Would't the new check incorrectly trigger in such a case?
>> st = git_inflate(&stream, Z_FINISH);
>> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
>> + break;
We won't see this on 64-bit platforms because we use larger (un)pack
window and the condition is much less likely to be met.
^ permalink raw reply
* Re: [RFC PATCH] git-gui: Allow staging multiple lines at once
From: Dirk Süsserott @ 2009-10-20 17:09 UTC (permalink / raw)
To: Jeff Epler; +Cc: git
In-Reply-To: <20091019195456.GA11121@unpythonic.net>
Am 19.10.2009 21:54 schrieb Jeff Epler:
> When applying less than a full hunk, it's still often desirable to apply
> a number of consecutive lines.
>
> This change makes it possible to sweep out a range of lines in the diff view
> with the left mouse button, then right click and "Stage Lines For Commit".
>
> The selected lines may span multiple hunks.
>
Awesome! I've been waiting for that very feature. Thanks in advance.
-- Dirk
^ permalink raw reply
* Re: [PATCH] Makefile: set PERL_PATH and SHELL_PATH unconditionally
From: Matt Kraai @ 2009-10-20 16:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtyxuox7u.fsf@alter.siamese.dyndns.org>
On Tue, Oct 20, 2009 at 09:18:29AM -0700, Junio C Hamano wrote:
> Matt Kraai <kraai@ftbfs.org> writes:
>
> > Do not check whether PERL_PATH and SHELL_PATH are undefined before
> > setting their default values. This prevents them from being set via
> > environment variables.
>
> Is there an upside of "preventing them from getting set", by the way?
Not that I know of.
I originally thought that the checks were superfluous, but now I just
believe they're inconsistent and confusing to people like me who think
they understand Makefiles but don't. :)
--
Matt Kraai http://ftbfs.org/
^ permalink raw reply
* Re: [PATCH] Use faster byte swapping when compiling with MSVC
From: Junio C Hamano @ 2009-10-20 16:55 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sebastian Schuberth, Junio C Hamano, git, Marius Storm-Olsen,
Johannes Sixt
In-Reply-To: <alpine.DEB.1.00.0910201149020.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Well, in fact I am one of the msysgit poeple, although I mostly worked
>> on the installer until now. In general, I like my patches to be
>> reviewed, but this one is rather uncritical, I guess. So it's up to you,
>> Junio, I'm perfectly OK with waiting for an ACK.
>
> Apart from the fact that I do not have MSVC (and I don't want it, either),
> there is another strong reason why I think Sebastian does not need ACKs or
> SOBs on MSVC patches: he has plenty of experience as a maintainer of a
> rather big (commercial) software that has to compile on Windows, MacOSX
> and several Unix-type OSes (and it is known that Sebastian is a Windows
> guy).
>
> So I would trust Sebastian's patches (at least when it comes to MSVC)
> without even reviewing them.
I very appreciate a strong Ack in a specific area like this. I do skim
msysgit list from time to time, and in retrospect I realize I _could_ have
recognized Sebastian's name but somehow it didn't click.
I guess I should apply both patches to 'master', then. Thanks.
^ permalink raw reply
* Re: [PATCH] blame: make sure that the last line ends in an LF
From: Junio C Hamano @ 2009-10-20 16:55 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Johannes Schindelin
In-Reply-To: <fabb9a1e0910200615x5d487cdk6f50e11c96f2cb6c@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
>> Does the code assign blame
>> correctly around the last line of the original blob?
>
> Yes, it does,...
That is kind of surprising ;-) as I do remember that I never thought about
this issue of dealing with the incomplete lines while writing the blame
algorithm. I actually didn't even think about "well this will not work
because I am ignoring the incomplete lines".
>> Or am I worrying too much?
>
> No, I think your concerns are valid, we should go with (2) and DTRT.
> Does the updated patch address your concerns? If so I can send a new
> version.
Assuming the internal blame algorithm correctly works with such an input,
I'd be happier with an approach to allow users to tell the difference.
The --porcelain output was designed to be extensible, and it might make
sense to show the "this line is incomplete" as a separate bit, though.
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Junio C Hamano @ 2009-10-20 16:52 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Andy Isaacson, git, Nicolas Pitre, Alex Riesen
In-Reply-To: <20091014142351.GI9261@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Z_BUF_ERROR is returned from inflate() if either the input buffer
> needs more input bytes, or the output buffer has run out of space.
> Previously we only considered the former case, as it meant we needed
> to move the stream's input buffer to the next window in the pack.
>
> We now abort the loop if inflate() returns Z_BUF_ERROR without
> consuming the entire input buffer it was given, or has filled
> the entire output buffer but has not yet returned Z_STREAM_END.
> Either state is a clear indicator that this loop is not working
> as expected, and should not continue.
When the inflated contents is of size 0, avail_out would be 0 and avail_in
would still have something because the input stream needs to have the end
of stream marker that is more than zero byte long.
If that is more than one-byte long, and your avail_in originally fed only
the first byte from that sequence, what happens? Wouldn't inflate eat all
what was given (now avail_in is zero), updated its internal state but it
still hasn't produced anything (avail_out is zero)?
I am not saying the end-of-stream is more than one-byte long (I didn't
check), but we had a similar bug arising from confusing "no more output
data" and "fully consumed input stream" (e.g. 456cdf6 (Fix loose object
uncompression check., 2007-03-19).
Something like that may be what is happening to cause problem Alex is
seeing.
I think the corrupt packdata detection needs an output buffer at least
one-byte larger than what is needed to store the correct result. Then
when we get BUF_ERROR:
- We never look at avail to see if it is zero; !avail_out is not the same
as "it stopped because it ran out of output space". It might mean
"there is nothing more to come but the input stream ended before
signalling that fact to the inflate engine fully".
- We do look at avail_out to find how much data we ended up getting. If
inflate has consumed more buffer than we planned to give it, the stream
is corrupt (at least it is not what we expected to see);
> st = git_inflate(&stream, Z_FINISH);
> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
> + break;
> curpos += stream.next_in - in;
> } while ((st == Z_OK || st == Z_BUF_ERROR) &&
> stream.total_out < sizeof(delta_head));
> @@ -1594,6 +1596,8 @@ static void *unpack_compressed_entry(struct packed_git *p,
> in = use_pack(p, w_curs, curpos, &stream.avail_in);
> stream.next_in = in;
> st = git_inflate(&stream, Z_FINISH);
> + if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out))
> + break;
> curpos += stream.next_in - in;
> } while (st == Z_OK || st == Z_BUF_ERROR);
> git_inflate_end(&stream);
> --
> 1.6.5.52.g0ff2e
>
> --
> Shawn.
^ permalink raw reply
* Re: Update working copy on push without touching several files
From: Thomas Rast @ 2009-10-20 16:45 UTC (permalink / raw)
To: Alex Amiryan; +Cc: git
In-Reply-To: <4ADDCC7A.8080607@amiryan.org>
Alex Amiryan wrote:
> Online versions of websites are maintained with git
> too. I need to have working copy of my remote git repository (online
> version of the site) updated by git push (which I do locally). The
> problem is that I have some files there (like database config) that have
> to be different from local ones and they must not be updated on git
> push.
My best results so far were with special config branches that are
auto-merged in post-receive. As a simple example, post-receive might
simply be
#!/bin/sh
git checkout -f master^0
git merge config
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* RE: Moving git
From: Richard @ 2009-10-20 16:37 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <alpine.LNX.2.00.0910201222080.14365@iabervon.org>
Thanks to anyone for the reply, but this issue has been resolved. I
might have submitted this several times, but Nabble keeps on nagging me
about multiple posts. So I'm just going to delete it.
-----Original Message-----
From: Daniel Barkalow [mailto:barkalow@iabervon.org]
Sent: 20 October 2009 17:34
To: Richard
Cc: git@vger.kernel.org
Subject: Re: Moving git
On Tue, 20 Oct 2009, Richard Lee wrote:
>
> Hi Git forum,
>
> I've just started using git yesterday, so I'm very new. So please
excuse if
> I've done something the wrong way.
>
> I cloned a git directory/repository? and then moved it. I'm trying to
prune
> branches and it gives
>
> ]fatal: '/var/www/vhosts/mydomain.co.uk/b2.git': unable to chdir or
not a
> git archive
> fatal: The remote end hung up unexpectedly
> ls-remote --heads /var/www/vhosts/mydomain.co.uk/b2.git: command
returned
> error: 1
>
> b2.git was the cloned bare thing I create following the instruction
here:
>
> http://book.git-scm.com/4_setting_up_a_private_repository.html
>
> Is there someway I can get git to update the git base directory?
The exact problem, I think, is that your clone has saved the original
location of the bare repository as the default upstream repository
location, and now it's not there. (It's a little hard to tell without
the
command that you were running when you got the error.)
If you edit the clone's .git/config, you should see the old location in
a
'[remote "origin"]' section. If you change this to the new location,
everything should work. You can also do it with "git remote" somehow,
but
I personally just edit the config file, so I don't know the details.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-pack-objects gitattributes?
From: Nasser Grainawi @ 2009-10-20 16:34 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Git Mailing List
In-Reply-To: <4ADCBAC7.9010601@drmicha.warpmail.net>
Michael J Gruber wrote:
> Nasser Grainawi venit, vidit, dixit 19.10.2009 20:47:
>> Nasser Grainawi wrote:
>>> Hello,
>>>
>>> I'm trying to avoid doing delta compression on a number of large binary
>>> files. I got a suggestion to use $GIT_DIR/info/attributes and a line
>>> like this:
>>> *.bin -delta
>>>
>>> This doesn't seem to show a big improvement (and honestly I can't find
>>> where in the git-pack-objects source the value of this attribute is used).
>>>
>>> Could someone shed some light on this attribute and any other
>>> improvements I could make for efficiently serving up a repo over
>>> git-daemon with near-weekly revisions of 100MB+ files?
>>>
>>> Thanks,
>>> Nasser
>> ping? any help? anyone?
>
> Well, describing a reproducable test case would help... as well as
> telling us your git version.
1.6.5
>
> builtin-pack-objects.c certainly refers to the delta attribute, see
> no_try_delta() and its callers.
Oops, somehow missed that while looking at the code right above it. Thanks.
>
> Have you checked your attrs with git-check-attr? How do you measure the
> improvements you expect?
I did check, it returns 'unset' like one would expect.
I guess the big problem is that I don't have a good test case. I would have
expected a 'git repack -adf' to spend less time saying "Compressing objects",
but that doesn't seem to be happening...
Oh, wait, never mind.
I was missing some of the binaries I was trying to skip. Adding some more
exceptions to the attributes file dropped the "Compressing objects" time from
20 minutes (or more) to maybe 10 seconds.
Thanks Michael!
Nasser
^ permalink raw reply
* Re: Moving git
From: Daniel Barkalow @ 2009-10-20 16:33 UTC (permalink / raw)
To: Richard Lee; +Cc: git
In-Reply-To: <25926819.post@talk.nabble.com>
On Tue, 20 Oct 2009, Richard Lee wrote:
>
> Hi Git forum,
>
> I've just started using git yesterday, so I'm very new. So please excuse if
> I've done something the wrong way.
>
> I cloned a git directory/repository? and then moved it. I'm trying to prune
> branches and it gives
>
> ]fatal: '/var/www/vhosts/mydomain.co.uk/b2.git': unable to chdir or not a
> git archive
> fatal: The remote end hung up unexpectedly
> ls-remote --heads /var/www/vhosts/mydomain.co.uk/b2.git: command returned
> error: 1
>
> b2.git was the cloned bare thing I create following the instruction here:
>
> http://book.git-scm.com/4_setting_up_a_private_repository.html
>
> Is there someway I can get git to update the git base directory?
The exact problem, I think, is that your clone has saved the original
location of the bare repository as the default upstream repository
location, and now it's not there. (It's a little hard to tell without the
command that you were running when you got the error.)
If you edit the clone's .git/config, you should see the old location in a
'[remote "origin"]' section. If you change this to the new location,
everything should work. You can also do it with "git remote" somehow, but
I personally just edit the config file, so I don't know the details.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2] new --dirty option for git describe
From: Junio C Hamano @ 2009-10-20 16:30 UTC (permalink / raw)
To: Jean Privat; +Cc: git, Shawn O. Pearce
In-Reply-To: <dffdbd190910200727r30e161ffka0b3cf764be26cd8@mail.gmail.com>
Jean Privat <jean@pryen.org> writes:
> +test_expect_success 'describe --dirty HEAD' '
> + git describe --dirty HEAD
> + test $? != 0
> +'
We tend to write this as
test_expect_success '...' '
test_must_fail git describe --dirty HEAD
'
The difference is when the tested command segfaults or dies in an
uncontrolled fashion; test_must_fail diagnoses it as a failure,
while "test $? != 0" at the end will say "ok, the command correctly
failed".
^ permalink raw reply
* Re: git fsck not identifying corrupted packs
From: Wesley J. Landaker @ 2009-10-20 16:20 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200910201741.50764.robin.rosenberg@dewire.com>
On Tuesday 20 October 2009 09:41:50 Robin Rosenberg wrote:
> måndag 19 oktober 2009 21:27:48 skrev Wesley J. Landaker:
> > (Not CCing everyone, since this is mostly curiosa in the "using git as
> > it was never intended" section):
[...]
> > Filesystems are mostly reliable, but only until your crazy users do
> > strange and terrible things. I have a real, non-toy environment where I
> > use this stack as a [horrible] workaround for some issues beyond my
> > control:
> >
> > git -> ext4 -> lvm -> dmcrypt -> loop -> sshfs -> cygwin sshd -> SMB
> > share
My main point was to illustrate that having "git fsck" do a REALLY GOOD
CHECK is still desirable, as we still haven't reached the days of file-
system utopia where nothing ever gets corrupted (even with a smaller,
simpler stack).
The actual application where I use this stack is because of odd requirements
and circumstances like data must be physically stored on a particular
Windows server on the network that uses a weird authentication method that
samba doesn't support, and it has to go over the network encrypted anyway,
there are lots of holes in the data, so I want ext4 for the extent support,
file-size limitations on the target, etc.
It's a really an exotic love-hate mix between an off-by-one-please-no-never-
again kind of situation coupled with a bit of "because I can".
> The obvious follow up question here is: Why?
If you are both nerdy and morbidly curious enough to care, send me a "but,
no ... really, WHY?!" with the git list CC dropped and we can talk about
details and/or other crazy stuff. (I don't want to get wildly off-topic on
this list.)
^ permalink raw reply
* Re: [PATCH] Makefile: set PERL_PATH and SHELL_PATH unconditionally
From: Junio C Hamano @ 2009-10-20 16:18 UTC (permalink / raw)
To: Matt Kraai; +Cc: git
In-Reply-To: <1256029588-24128-1-git-send-email-kraai@ftbfs.org>
Matt Kraai <kraai@ftbfs.org> writes:
> Do not check whether PERL_PATH and SHELL_PATH are undefined before
> setting their default values. This prevents them from being set via
> environment variables.
Is there an upside of "preventing them from getting set", by the way?
^ permalink raw reply
* [PATCH v2.5] new --dirty option for git describe
From: Jean Privat @ 2009-10-20 15:56 UTC (permalink / raw)
To: git, git
With the --dirty option, git describe works on HEAD but append "-dirty"
if the working tree is dirty. If the working tree is clean, nothing
is appended.
$ git describe --dirty
v1.6.5-15-gc274db7
$ echo >> Makefile
$ git describe --dirty
v1.6.5-15-gc274db7-dirty
--dirty can also be used to specify what is append if the working
tree is dirty.
$ git describe --dirty=.mod
v1.6.5-15-gc274db7.mod
Many build scripts use `git describe` to produce a version number based
on the description of HEAD (on which is based the working tree) + saying
that if the working tree is dirty or no.
This patch helps the writing of such scripts since `git describe --dirty`
do directly the intended thing.
Alternatives specifications:
1 Describe the working tree by default and describe HEAD only if "HEAD"
is explicitly specified
Pro: does the right thing by default (both for users and for scripts)
Pro: is coherent with other git commands that works on the working tree
by default
Con: breaks existing scripts (since the world is not ideal)
2 Use --worktree instead of --dirty
Pro: does what it says: "git describe --worktree" will describe the
working three
Con: is incoherent with other commands that do not require a --worktree
option to work on the working tree
Con: unusable with an optional value: "git describe --worktree=.mod"
is quite unintuitive.
3 Use --dirty as in this patch
Pro: make sense to specify an optional value (what the dirty mark is)
Pro: do not have any of the big cons of previous alternatives
* does not break scripts
* is not inconsistent with other git commands
Pro: has an easy fallback to alternative 1 if the world become suddenly
ideal, or at least allows some kind of future transition plan if
people *really* bother:
1- ask that scripts use either "git describe HEAD" or
"git describe --dirty" (no more "git describe")
2- change default
Once the transition is done, the role of the --dirty option will
just be the way to specify an alternative mark (and a noop if alone)
Signed-off-by: Jean Privat <jean@pryen.org>
---
I tried to integrate the points of view of both Junio and Shawn.
However, I am not sure that what I propose is the right solution.
Changes since v2:
No more line breaks (I hope)
Changes since v1:
use --dirty (alternative 3) instead of defaulting on workdir (alternative 1)
-J-
---
Documentation/git-describe.txt | 6 ++++++
builtin-describe.c | 25 ++++++++++++++++++++++++-
t/t6120-describe.sh | 15 +++++++++++++++
3 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index b231dbb..5253d86 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -9,6 +9,7 @@ git-describe - Show the most recent tag that is reachable from a commit
SYNOPSIS
--------
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
DESCRIPTION
-----------
@@ -27,6 +28,11 @@ OPTIONS
<committish>...::
Committish object names to describe.
+--dirty[=<mark>]::
+ Describe the working tree.
+ It means describe HEAD and appends <mark> (`-dirty` by
+ default) if the working tree is dirty.
+
--all::
Instead of using only the annotated tags, use any ref
found in `.git/refs/`. This option enables matching
diff --git a/builtin-describe.c b/builtin-describe.c
index df67a73..84af981 100644
--- a/builtin-describe.c
+++ b/builtin-describe.c
@@ -5,12 +5,14 @@
#include "builtin.h"
#include "exec_cmd.h"
#include "parse-options.h"
+#include "diff.h"
#define SEEN (1u<<0)
#define MAX_TAGS (FLAG_BITS - 1)
static const char * const describe_usage[] = {
"git describe [options] <committish>*",
+ "git describe [options] --dirty",
NULL
};
@@ -23,6 +25,13 @@ static int max_candidates = 10;
static int found_names;
static const char *pattern;
static int always;
+static const char *dirty;
+
+/* diff-index command arguments to check if working tree is dirty. */
+static const char *diff_index_args[] = {
+ "diff-index", "--quiet", "HEAD", "--", NULL
+};
+
struct commit_name {
struct tag *tag;
@@ -208,6 +217,8 @@ static void describe(const char *arg, int last_one)
display_name(n);
if (longformat)
show_suffix(0, n->tag ? n->tag->tagged->sha1 : sha1);
+ if (dirty)
+ printf("%s", dirty);
printf("\n");
return;
}
@@ -265,7 +276,10 @@ static void describe(const char *arg, int last_one)
if (!match_cnt) {
const unsigned char *sha1 = cmit->object.sha1;
if (always) {
- printf("%s\n", find_unique_abbrev(sha1, abbrev));
+ printf("%s", find_unique_abbrev(sha1, abbrev));
+ if (dirty)
+ printf("%s", dirty);
+ printf("\n");
return;
}
die("cannot describe '%s'", sha1_to_hex(sha1));
@@ -300,6 +314,8 @@ static void describe(const char *arg, int last_one)
display_name(all_matches[0].name);
if (abbrev)
show_suffix(all_matches[0].depth, cmit->object.sha1);
+ if (dirty)
+ printf("%s", dirty);
printf("\n");
if (!last_one)
@@ -324,6 +340,9 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
"only consider tags matching <pattern>"),
OPT_BOOLEAN(0, "always", &always,
"show abbreviated commit object as fallback"),
+ {OPTION_STRING, 0, "dirty", &dirty, "mark",
+ "append <mark> on dirty working tree (default: \"-dirty\")",
+ PARSE_OPT_OPTARG, NULL, "-dirty"},
OPT_END(),
};
@@ -360,7 +379,11 @@ int cmd_describe(int argc, const char **argv, const char *prefix)
}
if (argc == 0) {
+ if (dirty && !cmd_diff_index(ARRAY_SIZE(diff_index_args) - 1, diff_index_args, prefix))
+ dirty = NULL;
describe("HEAD", 1);
+ } else if (dirty) {
+ die("--dirty is incompatible with committishes");
} else {
while (argc-- > 0) {
describe(*argv++, argc == 0);
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 8c7e081..ee38f34 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -123,6 +123,21 @@ test_expect_success 'rename tag Q back to A' '
test_expect_success 'pack tag refs' 'git pack-refs'
check_describe A-* HEAD
+check_describe "A-*[0-9a-f]" --dirty
+
+test_expect_success 'set-up dirty working tree' '
+ echo >>file
+'
+
+check_describe "A-*[0-9a-f]-dirty" --dirty
+
+check_describe "A-*[0-9a-f].mod" --dirty=.mod
+
+test_expect_success 'describe --dirty HEAD' '
+ git describe --dirty HEAD
+ test $? != 0
+'
+
test_expect_success 'set-up matching pattern tests' '
git tag -a -m test-annotated test-annotated &&
echo >>file &&
--
1.6.5
^ permalink raw reply related
* Re: git fsck not identifying corrupted packs
From: Robin Rosenberg @ 2009-10-20 15:41 UTC (permalink / raw)
To: Wesley J. Landaker; +Cc: git
In-Reply-To: <200910191327.49092.wjl@icecavern.net>
måndag 19 oktober 2009 21:27:48 skrev Wesley J. Landaker:
> (Not CCing everyone, since this is mostly curiosa in the "using git as it
> was never intended" section):
>
> On Monday 19 October 2009 13:03:42 Junio C Hamano wrote:
> > Once a packfile is created and we always use it read-only, there didn't
> > seem to be much point in suspecting that the underlying filesystems or
> > disks may corrupt them in such a way that is not caught by the SHA-1
> > checksum over the entire packfile and per object checksum. That trust in
> > the filesystems might have been a good tradeoff between fsck performance
> > and reliability on platforms git was initially developed on and for, but
> > it might not be true anymore as we run on more platforms these days.
>
> Filesystems are mostly reliable, but only until your crazy users do strange
> and terrible things. I have a real, non-toy environment where I use this
> stack as a [horrible] workaround for some issues beyond my control:
>
> git -> ext4 -> lvm -> dmcrypt -> loop -> sshfs -> cygwin sshd -> SMB share
The obvious follow up question here is: Why?
-- robin
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Alex Riesen @ 2009-10-20 15:36 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Nicolas Pitre, Shawn O. Pearce, Andy Isaacson,
git
In-Reply-To: <fabb9a1e0910200823h280a875p98c61eb5e5e6018a@mail.gmail.com>
On Tue, Oct 20, 2009 at 17:23, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Tue, Oct 20, 2009 at 10:14, Alex Riesen <raa.lkml@gmail.com> wrote:
>> - buffer = xmalloc(size + 1);
>> + buffer = xmalloc(size + 8);
>
>> - stream.avail_out = size;
>> + stream.avail_out = size + 8;
>
> That seems wrong at first glance, you go from '+1' to '+8' on the
> first part, and then from '+0' to '+8' in the second part, am I
> missing something obvious?
Yes. The "size" (the variable) is never changed. It is just the output
buffer size, not how many data expected or something like that.
IOW, I just wanted the buffer to be obviously (to zlib) more than enough.
^ permalink raw reply
* Re: git hang with corrupted .pack
From: Sverre Rabbelier @ 2009-10-20 15:23 UTC (permalink / raw)
To: Alex Riesen
Cc: Junio C Hamano, Nicolas Pitre, Shawn O. Pearce, Andy Isaacson,
git
In-Reply-To: <81b0412b0910200814v269e91fbkd7841308685e1c54@mail.gmail.com>
Heya,
On Tue, Oct 20, 2009 at 10:14, Alex Riesen <raa.lkml@gmail.com> wrote:
> - buffer = xmalloc(size + 1);
> + buffer = xmalloc(size + 8);
> - stream.avail_out = size;
> + stream.avail_out = size + 8;
That seems wrong at first glance, you go from '+1' to '+8' on the
first part, and then from '+0' to '+8' in the second part, am I
missing something obvious?
--
Cheers,
Sverre Rabbelier
^ 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