* backup git repo on every commit
From: Israel Garcia @ 2009-10-12 13:41 UTC (permalink / raw)
To: git
Hi list, a simple question.
Which is the simplest way to backup a git repository after every commit?
--
Regards;
Israel Garcia
^ permalink raw reply
* Re: backup git repo on every commit
From: Christian Himpel @ 2009-10-12 14:08 UTC (permalink / raw)
To: Israel Garcia; +Cc: git
In-Reply-To: <194a2c240910120641sccf0e55xef4226269df78864@mail.gmail.com>
On Mon, Oct 12, 2009 at 08:41:15AM -0500, Israel Garcia wrote:
> Which is the simplest way to backup a git repository after every commit?
Using githooks(5) you can put a simple post-commit script in .git/hooks.
Maybe something like:
-->8--
#!/bin/sh
cp -a `pwd` `pwd`.`date +%s`
--8<--
Don't forget to make the script executable.
Regards,
chressie
^ permalink raw reply
* Re: git refuses to work with gvim
From: Shawn O. Pearce @ 2009-10-12 14:13 UTC (permalink / raw)
To: Matthieu Moy; +Cc: sebastian, git
In-Reply-To: <vpq8wfgg4u1.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
> The problem is that gvim returns immediately
...
> (BTW, this is in no way specific to Git, 99% applications calling
> $EDITOR will expect the same behavior)
The sad part is, every gvim user blames Git.
Every single one of my coworkers who uses Linux had gvim as their
default $EDITOR and found git commit working sometimes, and not
working others. Since git was new to them, they blamed git, not
their $EDITOR. They also felt insulted when I told them their
$EDITOR was busted and should be replaced.
Someone needs to whack gvim upside the head and fix that program
to behave correctly.
--
Shawn.
^ permalink raw reply
* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-12 14:15 UTC (permalink / raw)
To: Israel Garcia; +Cc: git
In-Reply-To: <194a2c240910120641sccf0e55xef4226269df78864@mail.gmail.com>
Israel Garcia <igalvarez@gmail.com> wrote:
> Which is the simplest way to backup a git repository after every commit?
Add a commit hook to push to another location, e.g.:
git remote add --mirror backup you@another.host:path/to/backup.git
cat >.git/hooks/post-commit
#!/bin/sh
git push backup
^D
chmod a+x .git/hooks/post-commit
--
Shawn.
^ permalink raw reply
* Supressing sorting of trees
From: Sal Mangano @ 2009-10-12 13:27 UTC (permalink / raw)
To: git
I am using Git in a non-standard way and need to make a few twaeks in my
custom build. I have added a --nosort option to git mktree which will suppress
the qsort of the tree.
Will this break any other git functions? Are there any commands that assume
trees are always sorted?
^ permalink raw reply
* Re: Supressing sorting of trees
From: Shawn O. Pearce @ 2009-10-12 14:20 UTC (permalink / raw)
To: Sal Mangano; +Cc: git
In-Reply-To: <loom.20091012T152113-874@post.gmane.org>
Sal Mangano <smangano@into-technology.com> wrote:
> I am using Git in a non-standard way and need to make a few twaeks in my
> custom build. I have added a --nosort option to git mktree which will suppress
> the qsort of the tree.
>
> Will this break any other git functions? Are there any commands that assume
> trees are always sorted?
_YES IT BREAKS GIT_.
You cannot do this.
A Git repository whose trees are not sorted according to the Git
specific sort ordering is severly broken and most tools will fail
horribly on it.
Almost all code which reads trees assumes the names are sorted in a
specific order. These tools perform sorted merges against other tree
like structures. If the names are out of order the merge will fail.
`git fsck` will complain that the tree is not sorted properly.
Tools like `git log -- foo.c` will fail randomly because they break
out of the entry lookup as soon as they find a name that is after
foo.c, as they assume the tree is sorted.
I could go on. But there is no point.
Oh, and trust me when I say this, the tree sorting matters. Long ago
JGit had a bug where it didn't sort trees correctly all of the time
and we had a devil of a time tracking down that corruption.
--
Shawn.
^ permalink raw reply
* Re: git refuses to work with gvim
From: Felipe Contreras @ 2009-10-12 14:20 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Matthieu Moy, sebastian, git
In-Reply-To: <20091012141334.GE9261@spearce.org>
On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:
>> The problem is that gvim returns immediately
> ...
>> (BTW, this is in no way specific to Git, 99% applications calling
>> $EDITOR will expect the same behavior)
>
> The sad part is, every gvim user blames Git.
>
> Every single one of my coworkers who uses Linux had gvim as their
> default $EDITOR and found git commit working sometimes, and not
> working others. Since git was new to them, they blamed git, not
> their $EDITOR. They also felt insulted when I told them their
> $EDITOR was busted and should be replaced.
>
> Someone needs to whack gvim upside the head and fix that program
> to behave correctly.
Huh? What is wrong about 'gvim --nofork'?
--
Felipe Contreras
^ permalink raw reply
* Re: backup git repo on every commit
From: Israel Garcia @ 2009-10-12 14:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091012141544.GF9261@spearce.org>
Hi Shawn,
That's OK, but I want to backup my git repo locally because I don't
have another remote git server. Can you modify your post-commit code
to backup the repo to /backups/git folder instead of using another
external git repo?
thanks in advance.
regards
Israel.
On 10/12/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> Israel Garcia <igalvarez@gmail.com> wrote:
>> Which is the simplest way to backup a git repository after every commit?
>
> Add a commit hook to push to another location, e.g.:
>
> git remote add --mirror backup you@another.host:path/to/backup.git
>
> cat >.git/hooks/post-commit
> #!/bin/sh
> git push backup
> ^D
>
> chmod a+x .git/hooks/post-commit
>
> --
> Shawn.
>
--
Regards;
Israel Garcia
^ permalink raw reply
* Re: git refuses to work with gvim
From: Shawn O. Pearce @ 2009-10-12 14:25 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Matthieu Moy, sebastian, git
In-Reply-To: <94a0d4530910120720pccaa920n7ab407494473ac7b@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> wrote:
> On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> >
> > Someone needs to whack gvim upside the head and fix that program
> > to behave correctly.
>
> Huh? What is wrong about 'gvim --nofork'?
The fact that its a command line option that isn't the default.
gvim's UI here is as bad as pre 0.99 git.
People do:
export EDITOR=gvim
and things work OK for a while, as they always open a new editor,
work with the file, and then close it, killing the only running gvim
session. Since gvim waits if its the only gvim process running,
things seem fine. But days later when you leave a file open,
suddenly the command calling $EDITOR starts failing.
I've seen it happen to a lot of people. They just start complaining
about how one day "git commit" is fine, and the next day its
not working. But its been weeks since they selected gvim as their
$EDITOR and they can't connect the open editor window as the problem
with that Goddamn Idiotic Truckload of s**t they are forced to use.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash completion: complete refs for git-grep
From: Shawn O. Pearce @ 2009-10-12 14:27 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <9f58ba1e7db9702d1b0594a8016c204e3d50b72f.1255337776.git.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> > So I'll roll a simpler patch that just always (before --) completes
> > refs instead, if that's ok.
Hard to argue with that logic. :-)
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 6fd7e1d..b08cd77 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -1048,7 +1048,8 @@ _git_grep ()
> return
> ;;
> esac
> - COMPREPLY=()
> +
> + __gitcomp "$(__git_refs)"
> }
--
Shawn.
^ permalink raw reply
* Re: backup git repo on every commit
From: Shawn O. Pearce @ 2009-10-12 14:30 UTC (permalink / raw)
To: Israel Garcia; +Cc: git
In-Reply-To: <194a2c240910120725u72cdb588p3c66bc730e6953d@mail.gmail.com>
Israel Garcia <igalvarez@gmail.com> wrote:
> That's OK, but I want to backup my git repo locally
Just change the path of the backup remote (that final argument to
git remote add) to point to the local directory.
Though I guess you would also need to run git init there, e.g.:
git --git-dir=/backup/project.git init
git remote add --mirror backup /backup/project.git
# and create the hook as below
Of course, backup to another folder on the same disk isn't a backup
at all, the disk can still fail and lose both repositories.
> On 10/12/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Israel Garcia <igalvarez@gmail.com> wrote:
> >> Which is the simplest way to backup a git repository after every commit?
> >
> > Add a commit hook to push to another location, e.g.:
> >
> > git remote add --mirror backup you@another.host:path/to/backup.git
> >
> > cat >.git/hooks/post-commit
> > #!/bin/sh
> > git push backup
> > ^D
> >
> > chmod a+x .git/hooks/post-commit
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Fixed _main window_ for screen height equal 600 px
From: Shawn O. Pearce @ 2009-10-12 14:34 UTC (permalink / raw)
To: Vietor Liu; +Cc: Johannes Schindelin, git
In-Reply-To: <1255335812.2326.20.camel@localhost.localdomain>
Vietor Liu <vietor@vxwo.org> wrote:
> On Mon, 2009-10-12 at 09:35 +0200, Johannes Schindelin wrote:
> >
> > So what you _actually_ do is reduce the space for the diff, no?
Dscho, I think what's happening is he is shrinking the minimum height
of the diff pane. By allowing it to be shorter he is trading diff
pane space in order to make room for the fixed height commit message
area below it.
> Yes.
> The _main window_ support auto resize. I was tested some way, only
> modify _diff body_ space could work. The _diff body_ is part of _main
> window_.
>
> Whether modify the commit message?
Yes, please modify the commit message. The message does not clearly
state what is occurring here, which is why Dsco had an issue.
Really you are trying to adjust the minimum height of the diff
pane, which is resizable, so that it can use less vertical height,
allowing the overall window to be shorter and still display the
entire commit pane.
Also, I find your use of underscores around widget names to be
very difficult to read. I don't see a reason for it in the commit
message.
--
Shawn.
^ permalink raw reply
* Re: git refuses to work with gvim
From: Felipe Contreras @ 2009-10-12 14:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Matthieu Moy, sebastian, git
In-Reply-To: <20091012142523.GH9261@spearce.org>
On Mon, Oct 12, 2009 at 5:25 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> On Mon, Oct 12, 2009 at 5:13 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> >
>> > Someone needs to whack gvim upside the head and fix that program
>> > to behave correctly.
>>
>> Huh? What is wrong about 'gvim --nofork'?
>
> The fact that its a command line option that isn't the default.
> gvim's UI here is as bad as pre 0.99 git.
>
> People do:
>
> export EDITOR=gvim
>
> and things work OK for a while, as they always open a new editor,
> work with the file, and then close it, killing the only running gvim
> session. Since gvim waits if its the only gvim process running,
> things seem fine. But days later when you leave a file open,
> suddenly the command calling $EDITOR starts failing.
I've never seen it happening. For me either it aways fails (fork) or
always work (nofork).
> I've seen it happen to a lot of people. They just start complaining
> about how one day "git commit" is fine, and the next day its
> not working. But its been weeks since they selected gvim as their
> $EDITOR and they can't connect the open editor window as the problem
> with that Goddamn Idiotic Truckload of s**t they are forced to use.
Yeah, it happened to me too, but eventually I realized what was
happening. I like gvim's default behavior tough.
I personally don't see any problem... how about other SCMs?
--
Felipe Contreras
^ permalink raw reply
* Re: backup git repo on every commit
From: Israel Garcia @ 2009-10-12 14:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20091012143043.GJ9261@spearce.org>
On 10/12/09, Shawn O. Pearce <spearce@spearce.org> wrote:
> Israel Garcia <igalvarez@gmail.com> wrote:
>> That's OK, but I want to backup my git repo locally
>
> Just change the path of the backup remote (that final argument to
> git remote add) to point to the local directory.
>
> Though I guess you would also need to run git init there, e.g.:
>
> git --git-dir=/backup/project.git init
> git remote add --mirror backup /backup/project.git
>
> # and create the hook as below
Nice..:-)
>
> Of course, backup to another folder on the same disk isn't a backup
> at all, the disk can still fail and lose both repositories.
Yeap, but I use rsync to backup /backup folder on a remote server
every night. /backup folder other apps backups.
thanks Shawn.
regards
Israel.
>
>> On 10/12/09, Shawn O. Pearce <spearce@spearce.org> wrote:
>> > Israel Garcia <igalvarez@gmail.com> wrote:
>> >> Which is the simplest way to backup a git repository after every
>> >> commit?
>> >
>> > Add a commit hook to push to another location, e.g.:
>> >
>> > git remote add --mirror backup you@another.host:path/to/backup.git
>> >
>> > cat >.git/hooks/post-commit
>> > #!/bin/sh
>> > git push backup
>> > ^D
>> >
>> > chmod a+x .git/hooks/post-commit
>
> --
> Shawn.
>
--
Regards;
Israel Garcia
^ permalink raw reply
* Re: [PATCH/RFC 3/4] git check-ref-format --print
From: Shawn O. Pearce @ 2009-10-12 14:39 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, Jens Lehmann, git
In-Reply-To: <20091012053141.GD11106@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> wrote:
> +valid_ref_normalized 'heads/foo' 'heads/foo'
> +valid_ref_normalized 'refs///heads/foo' 'refs/heads/foo'
> +invalid_ref_normalized 'foo'
> +invalid_ref_normalized 'heads/foo/../bar'
> +invalid_ref_normalized 'heads/./foo'
> +invalid_ref_normalized 'heads\foo'
What about '/refs/heads/foo'? Shouldn't that drop the leading /?
I actually had someone enter that into Gerrit Code Review once,
exposing a bug I have yet to fix that permits that as a valid
branch name. *sigh*
FWIW, I think this is heading in the right direction. Rather
than teaching the UIs how clean up a name, give us a tool to
do the normalization and validation, and let us call it when
we get user input.
--
Shawn.
^ permalink raw reply
* Re: [JGit-io-RFC-PATCH v2 2/4] Add JGit IO SPI and default implementation
From: Shawn O. Pearce @ 2009-10-12 14:57 UTC (permalink / raw)
To: imyousuf; +Cc: git, egit-dev, Imran M Yousuf
In-Reply-To: <1255270073-14205-2-git-send-email-imyousuf@gmail.com>
imyousuf@gmail.com wrote:
> The SPI mainly focus's in providing an API to JGit to be able to perform
> similar operations to that of java.io.File. All direct I/O is based on the
> java.io.Input/OutputStream classes.
>
> Different JGit IO SPI provider is designed to be URI scheme based and thus
> the default implementation is that of "file" scheme. SPI provider will be
> integrated by their respective users in a manner similar to that of JDBC
> driver registration. There is a SystemStorageManager that has similar
> registration capabilities and the system storage providers should be
> registered with the manager in one of the provided ways.
I think this may be a bit in the wrong direction for what we are
trying to accomplish.
A number of people really want to map Git onto what is essentially
Google's BigTable schema. Aside from Google's own BigTable product
(which I want to use Git on at work, because it would vastly simplfiy
my system administration duties at $DAYJOB) there is Cassandra and
Hadoop HBase which implement the same schema semantics.
None of those systems implement file streams, they implement cell
storage in a non-transactional system with a semi-dynamic schema.
Some people have built transactional semantics on top of these
storage layers, e.g. Google AppEngine provides multiple row
transactions through some magic sauce layered on top of BigTable.
I'm sure people will build similar tools on top of Cassandra
and HBase.
Where I'm trying to go with this is that things that are stored
in files on the filesystem in traditional Git wouldn't normally be
mapped into "byte streams" in a BigTable-ish system, or even the
JDBC-ish system you were describing.
For .git/config we might want to map config variable names into
keys in the table, with values stored in cells. This makes it
easier to query or edit the data.
Fortunately, "Config" is abstract enough that we could subclass
it with a CassandraConfig and simply use that instance when on a
based Cassandra storage system. No file streams required. Ditto
for a JdbcConfig.
For RefDatabase, we'd want to do the same and avoid the concept of
packed-refs altogether. Each Ref should go into its own row in a
Cassandra storage system, and essentially act as a loose object.
Ditto with JDBC.
We'd probably never need to read-or-write the info/refs or
objects/info/packs listings.
And I think that's everything that a bare repository needs, aside
from ObjectDatabase, which is already mostly abstract anyway.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v5 2/2] gitweb: append short hash ids to snapshot files
From: Mark Rada @ 2009-10-12 15:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git
In-Reply-To: <200910051206.18943.jnareb@gmail.com>
On 09-10-05 6:06 AM, Jakub Narebski wrote:
>> my $o_git_dir = $git_dir;
>> my $retval = undef;
>> $git_dir = "$projectroot/$project";
>> - if (open my $fd, "-|", git_cmd(), "rev-parse", "--verify", "HEAD") {
>> - my $head = <$fd>;
>> + if (open my $fd, '-|', git_cmd(), 'rev-parse', '--verify', $hash) {
>> + $hash = <$fd>;
>> close $fd;
>> - if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
>> + if (defined $hash && $hash =~ /^([0-9a-fA-F]{40})$/) {
>> + $retval = $1;
>> + }
>
> I guess that you use "$retval = $1;" instead of just "$retval = $hash;"
> because of similarities with git_get_short_hash, isn't it? Or it is just
> following earlier code?
Yeah, it is following earlier code, I did not change it, though the diff
seems to think I added it, perhaps this is a bug with diff?
>> + }
>> + if (defined $o_git_dir) {
>> + $git_dir = $o_git_dir;
>> + }
>> + return $retval;
>> +}
>> +
>> +# try and get a shorter hash id
>> +sub git_get_short_hash {
>> + my $project = shift;
>> + my $hash = shift;
>> + my $o_git_dir = $git_dir;
>> + my $retval = undef;
>> + $git_dir = "$projectroot/$project";
>> + if (open my $fd, '-|', git_cmd(), 'rev-parse', '--short=7', $hash) {
>> + $hash = <$fd>;
>> + close $fd;
>> + if (defined $hash && $hash =~ /^([0-9a-fA-F]{7,})$/) {
>> $retval = $1;
>> }
>> }
>
> Note that git_get_full_hash (which additionally does verification) and
> git_get_short_hash share much of code. Perhaps it might be worth to
> avoid code duplication somehow? On the other hand it might be not worth
> to complicate code by trying to extract common parts here...
Hmm, I think it might be a good idea to just write a generic routine
that takes a hash length as an extra parameter. Then the short and full
hash fetching routines can just acts as wrappers.
>> @@ -5203,6 +5228,13 @@ sub git_snapshot {
>> die_error(400, 'Object is not a tree-ish');
>> }
>>
>> +
>> + my $full_hash = git_get_full_hash($project, $hash);
>> + if ($full_hash =~ /^$hash/) {
>> + $hash = git_get_short_hash($project, $hash);
>> + } else {
>> + $hash .= '-' . git_get_short_hash($project, $hash);
>> + }
>
> I think we might want to avoid calling git_get_full_hash (and extra call
> to "git rev-parse" command, which is extra fork) if we know in advance
> that $full_hash =~ /^$hash/ can't be true, i.e. if $hash doesn't match
> /^[0-9a-fA-F]+$/. That would require that we continue to use $hash
> and not $full_hash, see comment for the chunk below.
>
> BTW do you think that having better name (nicer name in the case
> when $hash is full SHA-1, or name which describes exact version as
> in the case when $hash is branch name or just 'HEAD') is worth
> slight extra cost of "git rev-parse --abbrev=7"?
Hmm, yeah, some optimization will have to occur in that block of
code. Though, my reason for that extra call to rev-parse to get the
short hash is so I can get git to find the shortest unique SHA-1,
instead of just assuming that it will always be of length 7. I think
the cost is not too bad considering a snapshot will have to be generated
and probably take way more time. Though, warthog9 has some caching
patches that work, so maybe it isn't worth it. Hmm...
>> my $name = $project;
>> $name =~ s,([^/])/*\.git$,$1,;
>> $name = basename($name);
>> @@ -5213,7 +5245,7 @@ sub git_snapshot {
>> $cmd = quote_command(
>> git_cmd(), 'archive',
>> "--format=$known_snapshot_formats{$format}{'format'}",
>> - "--prefix=$name/", $hash);
>> + "--prefix=$name/", $full_hash);
>
> Why this change?
Since $hash can change by becoming something like 'HEAD-43ab5f2c' due to
the process of creating the better name we need to pass something to
`archive' that will be valid, and $full_hash will be valid.
>> +test_description='gitweb as standalone script (parsing script output).
>> +
>> +This test runs gitweb (git web interface) as a CGI script from the
>> +commandline, and checks that it produces the correct output, either
>> +in the HTTP header or the actual script output.'
>
> Currently all tests here are about 'snapshot' action. They are quite
> specific, and they do require some knowledge about chosen archive format.
> I think it would be better to put snapshot test into separate test,
> i.e. in 't/t9502-gitweb-standalone-snapshot.sh'.
>
Ok.
>> +test_commit \
>> + 'SnapshotFileTests' \
>> + 'i can has snapshot?'
>
> Errr... with filename [cutely] called 'i can has snapshot?' you would
> have, I guess, problems with tests on MS Windows, where IIRC '?' is
> forbidden in filenames.
I was able to confirm `?' as a forbidden file name character in Windows 7,
so I will have to change that...
> In the test below you use "git rev-parse --verify HEAD" and
> "git rev-parse --short HEAD" over and over. I think it would be better
> to calculate them upfront:
>
> +test_expect_success 'calculate full and short ids' '
> + FULLID= $(git rev-parse --verify HEAD) &&
> + SHORTID=$(git rev-parse --short=7 HEAD)
> +'
>
Ok.
>> + ID=`git rev-parse --short HEAD` &&
>> + grep ".git-$ID.tar.gz" gitweb.output
>
> Here had to think a bit that gitweb.output consists both of HTTP headers,
> and of response body, and you are grepping here in the HTTP headers part.
> It would be better solution for gitweb_run to split gitweb.output into
> gitweb.headers and gitweb.body (perhaps if requested by setting some
> variable, e.g. GITWEB_SPLIT_OUTPUT).
>
> It can be done using the following lines:
>
> sed -e '/^\r$/' <gitweb.output >gitweb.headers
> sed -n -e '0,/^\r$/!p' <gitweb.output >gitweb.body
>
> # gitweb.headers is used to parse http headers
> # gitweb.body is response without http headers
>
> But the second one uses GNU sed extension; I don't know how to write
> it in more portable way.
I like this and will try to find a way of setting this up without using
GNU extensions.
> Note that this would mean that t/t9501-gitweb-standalone-http-status.sh
> should also be updated to use gitweb.headers and gitweb.body
Yeah, now I have a few things mentioned by either you or Junio that I
should probably fix in the test cases I have submitted. I will clean
them up in a separate patch once I finish with this patch.
>> + gitweb_run "p=.git;a=snapshot;h=SnapshotFileTests;sf=tgz" &&
>> + ID=`git rev-parse --short SnapshotFileTests` &&
>> + grep ".git-SnapshotFileTests-$ID.tar.gz" gitweb.output
>> +'
>> +test_debug 'cat gitweb.output'
>
> Note that to avoid ambiguities currently gitweb uses refs/heads/master
> and refs/tags/SnapshotFileTests... but dealing with this issue should be
> left, I think, for separate commit.
>
I do not understand what ambiguity exists, can you please explain this?
--
Mark Rada (ferrous26)
marada@uwaterloo.ca
^ permalink raw reply
* Re: Supressing sorting of trees
From: Sal Mangano @ 2009-10-12 15:43 UTC (permalink / raw)
To: git
In-Reply-To: <20091012142032.GG9261@spearce.org>
Shawn O. Pearce <spearce <at> spearce.org> writes:
>
> Sal Mangano <smangano <at> into-technology.com> wrote:
> > I am using Git in a non-standard way and need to make a few twaeks in my
> > custom build. I have added a --nosort option to git mktree which will
suppress
> > the qsort of the tree.
> >
> > Will this break any other git functions? Are there any commands that assume
> > trees are always sorted?
>
> _YES IT BREAKS GIT_.
>
> You cannot do this.
>
> A Git repository whose trees are not sorted according to the Git
> specific sort ordering is severly broken and most tools will fail
> horribly on it.
>
> Almost all code which reads trees assumes the names are sorted in a
> specific order. These tools perform sorted merges against other tree
> like structures. If the names are out of order the merge will fail.
> `git fsck` will complain that the tree is not sorted properly.
> Tools like `git log -- foo.c` will fail randomly because they break
> out of the entry lookup as soon as they find a name that is after
> foo.c, as they assume the tree is sorted.
>
> I could go on. But there is no point.
>
> Oh, and trust me when I say this, the tree sorting matters. Long ago
> JGit had a bug where it didn't sort trees correctly all of the time
> and we had a devil of a time tracking down that corruption.
>
Thanks Shawn. I get the picture.
Now, let's assume I am stubborn, crazy or both :-)
I can modify fsck to ignore unsorted and at the moment I don't care about
merging trees. If I hunt down all usage of base_name_compare will that identify
all code with the sort assumption or is there other places as well? I can go
through the entire source to figure this out myself but I need to get something
hacked up very quickly and would appreciate help even if you think I am nuts!
^ permalink raw reply
* Filesystem has no item: Working copy path [...] does not exist in repository at /usr/bin/git-svn line 3856
From: Daniele Segato @ 2009-10-12 15:48 UTC (permalink / raw)
To: Git Mailing List; +Cc: Eric Wong
Hi,
i'm trying to clone a public SVN repo (user = guest, password is
empty/blank/not neeeded)
this was my steps:
$ git --version
git version 1.5.6.5
$ mkdir plugins
$ cd plugins
$ git svn init http://svn.liferay.com/repos/public/plugins -T trunk -b
branches # doesn't have tags
$ git svn fetch
[...]
# it takes hours.....
[...]
r25355 = ee13a19e656e6f96b1ebb562b10ee7fa688921df (svn/trunk)
Filesystem has no item: Working copy path 'plugins/branches/trunk'
does not exist in repository at /usr/bin/git-svn line 3856
after that revision it give me that error... and then stops.
if I issue again the git svn fetch it keep telling me the error and I
can't complete the cloning.
I've edited my .git/config between git svn init and git svn fetch
adding "svn" to the target branch and url name
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[svn-remote "svn"]
url = http://svn.liferay.com/repos/public
fetch = plugins/trunk:refs/remotes/svn/trunk
branches = plugins/branches/*:refs/remotes/svn/*
you can use
git svn fetch --revision 25255:HEAD
to make it take less time (hours anyway)...
Any help will be appreciated,
thanks,
regards,
Daniele
^ permalink raw reply
* Re: Supressing sorting of trees
From: Johannes Schindelin @ 2009-10-12 16:05 UTC (permalink / raw)
To: Sal Mangano; +Cc: git
In-Reply-To: <loom.20091012T171550-239@post.gmane.org>
Hi,
On Mon, 12 Oct 2009, Sal Mangano wrote:
> Shawn O. Pearce <spearce <at> spearce.org> writes:
>
> >
> > Sal Mangano <smangano <at> into-technology.com> wrote:
> > > I am using Git in a non-standard way and need to make a few twaeks
> > > in my custom build. I have added a --nosort option to git mktree
> > > which will suppress the qsort of the tree.
> > >
> > > Will this break any other git functions? Are there any commands that
> > > assume trees are always sorted?
> >
> > _YES IT BREAKS GIT_.
> >
> > You cannot do this.
> >
> > A Git repository whose trees are not sorted according to the Git
> > specific sort ordering is severly broken and most tools will fail
> > horribly on it.
> >
> > Almost all code which reads trees assumes the names are sorted in a
> > specific order. These tools perform sorted merges against other tree
> > like structures. If the names are out of order the merge will fail.
> > `git fsck` will complain that the tree is not sorted properly. Tools
> > like `git log -- foo.c` will fail randomly because they break out of
> > the entry lookup as soon as they find a name that is after foo.c, as
> > they assume the tree is sorted.
> >
> > I could go on. But there is no point.
> >
> > Oh, and trust me when I say this, the tree sorting matters. Long ago
> > JGit had a bug where it didn't sort trees correctly all of the time
> > and we had a devil of a time tracking down that corruption.
> >
>
> Thanks Shawn. I get the picture.
>
> Now, let's assume I am stubborn, crazy or both :-)
>
> I can modify fsck to ignore unsorted and at the moment I don't care
> about merging trees. If I hunt down all usage of base_name_compare will
> that identify all code with the sort assumption or is there other places
> as well? I can go > through the entire source to figure this out myself
> but I need to get something hacked up very quickly and would appreciate
> help even if you think I am nuts!
Look, one of the most trusted Git contributors just told you that you are
asking for trouble.
It has nothing to do with being stubborn if you insist on doing it now.
But I smell an XY problem. Why don't you just reveil _what_ you want to
do (as opposed to _how_ you think you should do it)?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-12 16:38 UTC (permalink / raw)
To: gister; +Cc: git
‘git bisect reset’ could already checkout an arbitrary commit if you
were on a detached HEAD before starting the bisection. This lets you
specify an arbitrary commit to ‘git bisect reset <commit>’.
This also provides a way to clean the bisection state without moving
HEAD: ‘git bisect reset HEAD’.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---
git-bisect.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 6f6f039..d319b9f 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -311,8 +311,7 @@ bisect_reset() {
}
case "$#" in
0) branch=$(cat "$GIT_DIR/BISECT_START") ;;
- 1) git show-ref --verify --quiet -- "refs/heads/$1" ||
- die "$1 does not seem to be a valid branch"
+ 1) git rev-parse --verify "$1^{commit}" || exit
branch="$1" ;;
*)
usage ;;
--
1.6.5
^ permalink raw reply related
* Re: Supressing sorting of trees
From: Sal Mangano @ 2009-10-12 16:51 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0910121803360.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:
>
> Hi,
>
> On Mon, 12 Oct 2009, Sal Mangano wrote:
>
> > Shawn O. Pearce <spearce <at> spearce.org> writes:
> >
> > >
> > > Sal Mangano <smangano <at> into-technology.com> wrote:
> > > > I am using Git in a non-standard way and need to make a few twaeks
> > > > in my custom build. I have added a --nosort option to git mktree
> > > > which will suppress the qsort of the tree.
> > > >
> > > > Will this break any other git functions? Are there any commands that
> > > > assume trees are always sorted?
> > >
> > > _YES IT BREAKS GIT_.
> > >
> > > You cannot do this.
> > >
> > > A Git repository whose trees are not sorted according to the Git
> > > specific sort ordering is severly broken and most tools will fail
> > > horribly on it.
> > >
> > > Almost all code which reads trees assumes the names are sorted in a
> > > specific order. These tools perform sorted merges against other tree
> > > like structures. If the names are out of order the merge will fail.
> > > `git fsck` will complain that the tree is not sorted properly. Tools
> > > like `git log -- foo.c` will fail randomly because they break out of
> > > the entry lookup as soon as they find a name that is after foo.c, as
> > > they assume the tree is sorted.
> > >
> > > I could go on. But there is no point.
> > >
> > > Oh, and trust me when I say this, the tree sorting matters. Long ago
> > > JGit had a bug where it didn't sort trees correctly all of the time
> > > and we had a devil of a time tracking down that corruption.
> > >
> >
> > Thanks Shawn. I get the picture.
> >
> > Now, let's assume I am stubborn, crazy or both
> >
> > I can modify fsck to ignore unsorted and at the moment I don't care
> > about merging trees. If I hunt down all usage of base_name_compare will
> > that identify all code with the sort assumption or is there other places
> > as well? I can go > through the entire source to figure this out myself
> > but I need to get something hacked up very quickly and would appreciate
> > help even if you think I am nuts!
>
> Look, one of the most trusted Git contributors just told you that you are
> asking for trouble.
>
> It has nothing to do with being stubborn if you insist on doing it now.
>
> But I smell an XY problem. Why don't you just reveil _what_ you want to
> do (as opposed to _how_ you think you should do it)?
>
> Ciao,
> Dscho
>
>
My apologies for being cryptic.
I am working on a project where I need to create a repository consisting of
hierarchical "blobs" of content (sound familiar?). In this repository the
order of the blobs as specified by the end user is definitely important.
However, I have a bunch of other reqs that fit Git perfectly such as the
ability to quickly tell if two trees are the same using their SHA1 and the
ability to version control the repository. My repository has no relationship
to files stored on a file system unlike a typical use of Git. I also don't
care about whether my repository remains compatible with standard Git because
no one will access this repository using standard Git.
Now I can proceed in a few ways:
1) I can write by repository from scratch.
2) I can use Git unchanged but preserve order by storing some information in
each sub tree (e.g. an extra blob) which retains the real order. I can also
store this information once for the whole "chunks" of the repository.
3) I can change Git to suite my needs understanding that it is not Git
anymore.
For me, (1) makes no sense at this time. I started with the hope that (2)
would work but realized it is very awkward and will cause performance problems
because it means most updates where ordering matters will have to update the
Git trees and my private ordering blob(s). So, after a quick look at the
source code it seemed like hacking Git into what I wanted was easier than 1
or 2.
I realized tree merge would probably break and wanted to know what
else. It is good to know fsck breaks. What else will break that I have to
deal with?
^ permalink raw reply
* git stash list with more than 10 items?
From: Jef Driesen @ 2009-10-12 15:47 UTC (permalink / raw)
To: git
Hi,
Is it possible to make "git stash list" show more than 10 items?
Jef
^ permalink raw reply
* Re: Questions about the new
From: Sergio Callegari @ 2009-10-12 17:04 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AD31EBF.6090307@viscovery.net>
Thanks Johannes for all the detailed explanations
Johannes Sixt <j.sixt <at> viscovery.net> writes:
>
> Sergio schrieb:
> > 1) Grafts and replace entries seem to operate on different aspects
of the
> > history graph. Grafts operate on arcs and replace on nodes.
>
> Correct, but see below about tree and blob objects.
OK, the replace mechanism also can replace a blob object or a tree.
My focus was on commit objects only.
>
> > As such, replace entries seem less general to me.
>
> With grafts you can only change parenthood; with replace entries you can
> change parenthood *and* all other aspects of a commit (message, author,
> committer, dates).
>
> Hence, replace entries are more general than grafts.
Limiting the discussion to commit objects, I think there are two
possible scenarios.
1) You create new commits objects as needed
2) You do not.
If you follow 1), I believe grafts and replace entries have exactly the same
flexibility.
If I happen not to like commit B in A---B---C and I want A---B'---C
where B' has
completely different aspects from B I can either replace B by B' or
graft away
B, pretending that the parent of A is B
But there are many things that can be done with grafts merely adding a graft
(e.g. cutting away a part of history, joining history), that cannot be done
with replace entries without creating new commits objects.
I was asking because I was wandering whether replace entries were first
or later
meant to make grafts deprecated. I hope not, because for a few things
working on
arcs seems still nice.
> > Apparently, to simulate a graft with replace entries, you need to
introduce
> > extra commit objects. For instance, if object B has no parents, to
pretend >
> Yes. Use git-cat-file + edit + git-hash-object as explained in this
> message just the other day:
>
http://thread.gmane.org/gmane.comp.version-control.git/129727/focus=129907
Thanks, good pointer. I missed this!
> > Conversely, I guess
> > you can always simulate a replace entry with the graft mechanism,
without the
> > need to add any extra commit object. Am I overlooking something?
>
> You cannot; see above.
Well, I meant for what regards commit objects only.
If I want to replace some commit X by some commit X' I merely need to
modify the
parent information of all the commits that are child of X so that they
pretend
to be child of X', or am I missing something?
> You can even replace tree objects and blob objects
> using replace entries, IIUC, but you cannot do that with grafts.
Definitely right!
> > 2) Is it currently possible to use a replace entry to replace a
commit object
> > with nothing? Namely if B has A as its sole parent, is it possible
to have a
> > replace entry such as A-sha1 becomes null, to pretend that B is a
hierarchy
> > root?
>
> Sure. Just make a commit object that does not have parents.
OK, you need to create a new commit object. At the beginning for some
reason I
thought that you could replace an object
with "nothing" or 00000000000000000000000000000000000000000000
> > 3) If I remember correctly, there was a reason why grafts were not
considered
> > suitable for transferring across repos. Can someone remind me about
it? How
> > does the replace mechanism address this issue?
>
> The problem with grafts was that, for example, git-pack-objects
obeyed the
> graft, and could create a broken repository by removing grafted-away
> objects. And since git-fsck also obeyed the graft, it did not notice the
> breakage.
>
> OTOH, history walkers (upload-pack, send-pack, pack-objects) and fsck
> never obey replace entries in the history. But they do keep track of them
> (and the history that they reference) because they are referenced
from the
> refs/replace namespace.
>
Thanks for the explanation. Can this be made possible for grafts too?
Wouldn't
it be a matter of having history walkers never obey grafts but keep track of
them (i.e. of the history of the parenthood they reference)?
Like we have "annotated" or heavyweight tags living as objects in the
database,
would it be possible or make sense to have annotated grafts or replace
entries,
so that one can express why, by whom and when history was changed?
^ permalink raw reply
* Re: [PATCH 1/2] user-manual: add global config section
From: Felipe Contreras @ 2009-10-12 17:09 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git, Junio C Hamano, J. Bruce Fields, Jonathan Nieder
In-Reply-To: <4AD32024.6020005@drmicha.warpmail.net>
On Mon, Oct 12, 2009 at 3:25 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 11.10.2009 22:43:
>> So that users get to know how to configure git from the get-to with good
>> practical example (color.ui = auto) that most people would probably like
>> anyway.
>>
>> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
>> ---
>> Documentation/user-manual.txt | 27 +++++++++++++++++++++++++++
>> 1 files changed, 27 insertions(+), 0 deletions(-)
>>
>> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
>> index 67ebffa..ff2563a 100644
>> --- a/Documentation/user-manual.txt
>> +++ b/Documentation/user-manual.txt
>> @@ -40,6 +40,33 @@ without any explanation.
>> Finally, see <<todo>> for ways that you can help make this manual more
>> complete.
>>
>> +[[getting-started]]
>> +Getting started
>> +=============
>> +
>> +Git's configuration is distributed among different locations--this manual will
>> +only to deal with 'global' (for the user) and 'repository' variables, where
>> +'repository' variables take precedence over 'global' ones.
>
> Well, you do talk about "system" below, and that's about it. Also, the
> configuration is not really distributed among different locations. Most
> newbies interested in a *D*VCS will misunderstand this (as git having
> distributed configuration).
>
> Alternative:
>
> Git's default configuration can be changed on a system wide, global (per
> user) and local (per repository) level, in the order of increasing
> precedence.
When I read that it's not clear if the local level discards the global
level completely or it's aggregated. If we specify that it's only the
variables that take precedence it might be clearer:
Git's configuration is composed of variables that are stored in
multiple locations: 'system' (all users), 'global' (for the user), and
'repository' -- in decreasing order of precedence.
>> +
>> +You would probably want to start setting up something useful:
>> +------------------------------------------------
>> +$ git config --global color.ui auto
>> +------------------------------------------------
>> +
>> +This will make prettier the output of certain commands such as `git diff`, but
>> +that's not important; what is important here is that `color.ui` has been
>> +stored in the 'global' configuration.
>
> This will make certain commands such as `git diff` use colors in the
> output. What is important here is that the value `auto` for the option
> `color.ui` has been stored in the 'global' configuration. Use `--system`
> for the system wide configuration; specifying neither `--system` nor
> `--global` makes `git config` access the local configuration.
I think we should only mention (once) the system wide configuration,
but not cover it. That's for system administrators, not users.
>> +
>> +View and manually modify the configuration by opening `~/.gitconfig`:
>
> View and manually modify the global configuration by opening
> `~/.gitconfig` in your editor or using `git config --global --edit`:
I have separate patches for 'git config --edit', but Junio suggested
to hold them back because --edit is a relatively new option.
>> +------------------------------------------------
>> +[color]
>> + ui = auto
>> +------------------------------------------------
>> +
>> +Other locations are `/etc/gitconfig` (system), and `.git/config` (repository).
>
> I don't even think we should talk about locations here, "git config -e"
> should be the first user's way to do it.
I disagree. Most useful configurations (color.ui, user.email) should
be global. The complete newbie might think: cool, now I have my git
properly configured (with 'git config -e'), and then when cloning a
new repo (s)he would think: ok, git just forgot what I told him. When
that happens (s)he would have to re-learn and re-configure git.
When users think about configuration, it's usually a 'global'
configuration, so that's what we should teach from the beginning and
make sure they understand the difference between 'global' and
'repository' configurations.
>> +
>> +More git configurations will be covered in the rest of the manual, if you want
>> +to learn more look at linkgit:git-config[1] for details.
>
> "Configurations" is ambiguous, it can be easily (mis)understood as
> "types of configuration" (global, local etc.). Also, the above doesn't
> really cover even one option. How about:
>
> This manual covers many configuration options (such as `color.ui.`). For
> more details on the `git config` command as well as all configuration
> options see linkgit:git-config[1].
Looks better, except s/configuration options/configuration variables/
Cheers.
--
Felipe Contreras
^ 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