* Re: Status of kha/experimental
From: Catalin Marinas @ 2007-10-11 20:38 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <20071010082602.GF12970@diana.vm.bytemark.co.uk>
On 10/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-09 23:46:13 +0200, Yann Dirson wrote:
> > The best situation would be that there would be a code freeze at
> > some time, during which I could update those patches without too
> > much perturbations, but that may be asking a lot :)
>
> There aren't that many of us working on StGit. If you can give a
> reasonably accurate start date and duration of the freeze,
This would mean that I have to be more organised :-).
> I don't
> think it would be a problem.Others would simply have to be aware that
> any patches not merged before the freeze would have to be rebased on
> top of your work once the freeze is over.
I'll try - let's say we freeze it starting with the coming Monday
(what's currently in kha/safe will be merged anyway) and aim to
release 0.14 in about 3 weeks (or as soon as we fix the major bugs).
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 1/2] Add a --dry-run option to git-send-pack.
From: Lars Hjemli @ 2007-10-11 20:18 UTC (permalink / raw)
To: Brian Ewins; +Cc: git, gitster
In-Reply-To: <119213114734-git-send-email-Brian.Ewins@gmail.com>
Thanks
--
larsh
^ permalink raw reply
* Re: How to have multiple working copy directories use the same repository?
From: Sergio @ 2007-10-11 19:21 UTC (permalink / raw)
To: git
In-Reply-To: <744844.82514.qm@web55015.mail.re4.yahoo.com>
One possibility can be to use the "git-new-workdir"
script that is distributed in the contrib directory
of git source. It allows to have many work dirs insisting
on the same repo (yet possibly operating on different branches!)
I believe that you might need to be careful with that,
though:
1) There is no check about the possibility of messing things
up by working on the same branch from two points.
2) There should be a basic infrastructure to avoid nasty
things from happening but I do not know if it is complete.
3) Implementation is based on symlinks in the git directory,
so it is only for architectures supporting symlinks and, since
there are many symlinks, if something gets changed by mistake and
some symlink looses consistency with the others bad things may
happen.
Sergio
^ permalink raw reply
* [PATCH v2 2/2] Add a --dry-run option to git-push.
From: Brian Ewins @ 2007-10-11 19:32 UTC (permalink / raw)
To: git; +Cc: hjemli, gitster, Brian Ewins, Brian Ewins
In-Reply-To: <16913589bee1374245d8b8f7333ab3984b56ffcb.1192130892.git.Brian.Ewins@gmail.com>
The default behaviour of git-push is potentially confusing
for new users, since it will push changes that are not on
the current branch. Publishing patches that were still
cooking on a development branch is hard to undo.
It would also be nice to be able to verify the expansion
of refspecs if you've edited them, so that you know
what branches matched on the server.
Adding a --dry-run flag allows the user to experiment
safely and learn how to use git-push properly. Originally
suggested by Steffen Prohaska.
Signed-off-by: Brian Ewins <brian.ewins@gmail.com>
---
Documentation/git-push.txt | 5 ++++-
builtin-push.c | 10 ++++++++--
t/t5516-fetch-push.sh | 10 ++++++++++
3 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6bc559d..e5dd4c1 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -9,7 +9,7 @@ git-push - Update remote refs along with associated objects
SYNOPSIS
--------
[verse]
-'git-push' [--all] [--tags] [--receive-pack=<git-receive-pack>]
+'git-push' [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>]
[--repo=all] [-f | --force] [-v] [<repository> <refspec>...]
DESCRIPTION
@@ -63,6 +63,9 @@ the remote repository.
Instead of naming each ref to push, specifies that all
refs under `$GIT_DIR/refs/heads/` be pushed.
+\--dry-run::
+ Do everything except actually send the updates.
+
\--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
addition to refspecs explicitly listed on the command
diff --git a/builtin-push.c b/builtin-push.c
index 88c5024..141380b 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -7,9 +7,9 @@
#include "builtin.h"
#include "remote.h"
-static const char push_usage[] = "git-push [--all] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]";
+static const char push_usage[] = "git-push [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]";
-static int all, force, thin, verbose;
+static int all, dry_run, force, thin, verbose;
static const char *receivepack;
static const char **refspec;
@@ -69,6 +69,8 @@ static int do_push(const char *repo)
argc = 1;
if (all)
argv[argc++] = "--all";
+ if (dry_run)
+ argv[argc++] = "--dry-run";
if (force)
argv[argc++] = "--force";
if (receivepack)
@@ -147,6 +149,10 @@ int cmd_push(int argc, const char **argv, const char *prefix)
all = 1;
continue;
}
+ if (!strcmp(arg, "--dry-run")) {
+ dry_run = 1;
+ continue;
+ }
if (!strcmp(arg, "--tags")) {
add_refspec("refs/tags/*");
continue;
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index ca46aaf..4fbd5b1 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -244,4 +244,14 @@ test_expect_success 'push with colon-less refspec (4)' '
'
+test_expect_success 'push with dry-run' '
+
+ mk_test heads/master &&
+ cd testrepo &&
+ old_commit=$(git show-ref -s --verify refs/heads/master) &&
+ cd .. &&
+ git push --dry-run testrepo &&
+ check_push_result $old_commit heads/master
+'
+
test_done
--
1.5.2.5
^ permalink raw reply related
* [PATCH v2 1/2] Add a --dry-run option to git-send-pack.
From: Brian Ewins @ 2007-10-11 19:32 UTC (permalink / raw)
To: git; +Cc: hjemli, gitster, Brian Ewins, Brian Ewins
In-Reply-To: <8c5c35580710110057r29c1fe0w7f9e2825fa33@mail.gmail.com>
Implement support for --dry-run, so that it can be used
in calls from git-push. With this flag set, git-send-pack
will not send any updates to the server.
Signed-off-by: Brian Ewins <brian.ewins@gmail.com>
---
Documentation/git-send-pack.txt | 5 ++++-
send-pack.c | 31 +++++++++++++++++++------------
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 3271e88..2fa01d4 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -8,7 +8,7 @@ git-send-pack - Push objects over git protocol to another repository
SYNOPSIS
--------
-'git-send-pack' [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
+'git-send-pack' [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]
DESCRIPTION
-----------
@@ -34,6 +34,9 @@ OPTIONS
Instead of explicitly specifying which refs to update,
update all heads that locally exist.
+\--dry-run::
+ Do everything except actually send the updates.
+
\--force::
Usually, the command refuses to update a remote ref that
is not an ancestor of the local ref used to overwrite it.
diff --git a/send-pack.c b/send-pack.c
index f74e66a..16ed51f 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -7,13 +7,14 @@
#include "remote.h"
static const char send_pack_usage[] =
-"git-send-pack [--all] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
+"git-send-pack [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
" --all and explicit <ref> specification are mutually exclusive.";
static const char *receivepack = "git-receive-pack";
static int verbose;
static int send_all;
static int force_update;
static int use_thin_pack;
+static int dry_run;
/*
* Make a pack stream and spit it out into file descriptor fd
@@ -282,16 +283,18 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
strcpy(old_hex, sha1_to_hex(ref->old_sha1));
new_hex = sha1_to_hex(ref->new_sha1);
- if (ask_for_status_report) {
- packet_write(out, "%s %s %s%c%s",
- old_hex, new_hex, ref->name, 0,
- "report-status");
- ask_for_status_report = 0;
- expect_status_report = 1;
+ if (!dry_run) {
+ if (ask_for_status_report) {
+ packet_write(out, "%s %s %s%c%s",
+ old_hex, new_hex, ref->name, 0,
+ "report-status");
+ ask_for_status_report = 0;
+ expect_status_report = 1;
+ }
+ else
+ packet_write(out, "%s %s %s",
+ old_hex, new_hex, ref->name);
}
- else
- packet_write(out, "%s %s %s",
- old_hex, new_hex, ref->name);
if (will_delete_ref)
fprintf(stderr, "deleting '%s'\n", ref->name);
else {
@@ -302,7 +305,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
fprintf(stderr, "\n from %s\n to %s\n",
old_hex, new_hex);
}
- if (remote) {
+ if (remote && !dry_run) {
struct refspec rs;
rs.src = ref->name;
rs.dst = NULL;
@@ -321,7 +324,7 @@ static int send_pack(int in, int out, struct remote *remote, int nr_refspec, cha
}
packet_flush(out);
- if (new_refs)
+ if (new_refs && !dry_run)
ret = pack_objects(out, remote_refs);
close(out);
@@ -390,6 +393,10 @@ int main(int argc, char **argv)
send_all = 1;
continue;
}
+ if (!strcmp(arg, "--dry-run")) {
+ dry_run = 1;
+ continue;
+ }
if (!strcmp(arg, "--force")) {
force_update = 1;
continue;
--
1.5.2.5
^ permalink raw reply related
* Re: RCS keyword expansion
From: Alex Riesen @ 2007-10-11 19:21 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0710111953460.7441@perkele.intern.softwolves.pp.se>
Peter Karlsson, Thu, Oct 11, 2007 19:55:05 +0200:
> >That's not a job for a source code manager to do. It's a job for your
> >build/install tool.
>
> Since there is no build step involved (my web site is just a CVS checkout
> at the moment), it's a job for the checkout step. I'd really want to avoid
> having a separate copy of the web site just so that I can do a "make
> install".
That's confusing. If your web site is just a checkout, what is the
"make install" for? If it is a repo, you have the version information
anyway, and at all times.
And if this extra step is indeed present, why can't the "make install"
just save the HEAD somewhere for later reference?
> That would sort of negate the savings in disk space I hope seeing
> by moving from CVS to Git.
You'll find you have plenty of savings for anything.
^ permalink raw reply
* Re: RCS keyword expansion
From: Lars Hjemli @ 2007-10-11 19:16 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710111542420.23849@ds9.cixit.se>
On 10/11/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
> I've looked and looked, but cannot figure out how to do RCS/CVS style
> keyword expansion with Git.
If you look at 'man gitattributes' you'll find a description of the
'ident' attribute which is expanded to the SHA1 of the containing file
during checkout.
There is also a description of the 'export-subst' attribute which can
be used to expand keywords when generating tar/zip files with
'git-archive'. It supports commit SHA1 and date, among others.
Btw: using git-archive means that you don't need a local repository on
the webserver, you only need a proper git installation. Essentially,
you can update your webserver 'checkout' with something like this:
$ git archive --remote=<url> --prefix=somepath/ master | tar -x
--
larsh
^ permalink raw reply
* Re: How to have multiple working copy directories use the same repository?
From: Alex Riesen @ 2007-10-11 19:00 UTC (permalink / raw)
To: Bill Priest; +Cc: git
In-Reply-To: <744844.82514.qm@web55015.mail.re4.yahoo.com>
Bill Priest, Thu, Oct 11, 2007 20:10:50 +0200:
> I've looked at the "git for CVS users" section in
> the docs and this appears to create two repositories.
> Is there a way to have two working directories that
> utilize the same repository?
Look for "alternates" in git's documentation. But read all the
warnings regarding git-gc and git-prune. Make a note of ".keep" files.
> I'm betting that I'm just trying to push my workflow
> style onto git instead of adapting to the git way of
> doing things; but thought I would ask.
Git is flexible enough to accomodate almost any existing workflow.
Just some of them work better.
^ permalink raw reply
* Re: RCS keyword expansion
From: Peter Karlsson @ 2007-10-11 17:55 UTC (permalink / raw)
Cc: git
In-Reply-To: <86fy0hvgbh.fsf@blue.stonehenge.com>
Randal L. Schwartz:
> That's not a job for a source code manager to do. It's a job for your
> build/install tool.
Since there is no build step involved (my web site is just a CVS checkout at
the moment), it's a job for the checkout step. I'd really want to avoid
having a separate copy of the web site just so that I can do a "make
install". That would sort of negate the savings in disk space I hope seeing
by moving from CVS to Git.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* How to have multiple working copy directories use the same repository?
From: Bill Priest @ 2007-10-11 18:10 UTC (permalink / raw)
To: git
All,
My current business requirements make it
advantageous to have two concurrent working
directories (that have similar file structure; but not
exactly the same); I need to maintain two separate
builds that are always up to date. Each working
directory would be associated with a particular
branch/line of branches (think of two different
hardware platforms that have considerable overlap). A
complication to this is that I need to use git-svn as
the remainder of the team uses svn (I just changed
from cvs to svn last Jan so it is a hard sell to
management to change again). I'm using git for the
merge capabilities.
I've looked at the "git for CVS users" section in
the docs and this appears to create two repositories.
Is there a way to have two working directories that
utilize the same repository?
I'm betting that I'm just trying to push my workflow
style onto git instead of adapting to the git way of
doing things; but thought I would ask.
TIA,
Bill
PS. I'm trying to avoid the push in the commit, push,
merge, dcommit cycle.
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
^ permalink raw reply
* Re: Is it possible for git to support binary differencing for binary files?
From: Alex Riesen @ 2007-10-11 18:15 UTC (permalink / raw)
To: 银平; +Cc: git
In-Reply-To: <20071011163746.DEB147E6F@mail.kooxoo.com>
银平, Thu, Oct 11, 2007 18:37:43 +0200:
> Hi.
> Storing binary files as deltas is helpful to keep source and binary files
> together and in sync So is it possible for git to do that as svn. This is
> my only pain when using git.
Why? Git works perfectly with binary files. In fact, some of my repos
have more binaries than text.
^ permalink raw reply
* Re: RCS keyword expansion
From: Alex Riesen @ 2007-10-11 18:09 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20071011155956.GC11693@cs-wsok.swansea.ac.uk>
Oliver Kullmann, Thu, Oct 11, 2007 17:59:56 +0200:
> Better than just the date, it would be greatest to be able to put also
> the SHA1-ID of the commit into the file, alas this is a bit complicated,
actually, it is quite simple: just (re)generate a file which you can
compile and link to your executable. That is how gits version work:
$ git version
git version 1.5.3.4.229.ga321c1
this ga321c1 is the commit (no one knows what the "g" stands for, but
the rest is plain value of HEAD at the moment of compilation).
Put the generated string in your image in a greppable/identable form
and you are set: the commit identifies uniquely the whole build tree
(assuming your build tree _can_ be identified. It not given for most
commercial projects I am familiar with).
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Steven Grimm @ 2007-10-11 18:00 UTC (permalink / raw)
To: Thomas Harning Jr.; +Cc: git
In-Reply-To: <e47324780710110857s472bf099u3e350d17a2c29f78@mail.gmail.com>
Thomas Harning Jr. wrote:
> Perhaps we should have a separate mailing list for patches vs discussion.
>
This list is somewhat unusual in that the two are not really distinct.
Most of the discussion (or at least a huge percentage of it) is in
response to patches or results in patches somewhere along the line, with
updated versions of those patches intermingled with feedback. Having to
bounce back and forth between two mailing lists for all that would
seriously impair the flow of ideas / improvements here.
-Steve
^ permalink raw reply
* Re: Is it possible for git to support binary differencing for binary files?
From: Jean-Luc Herren @ 2007-10-11 17:54 UTC (permalink / raw)
To: 银平; +Cc: git
In-Reply-To: <20071011163746.DEB147E6F@mail.kooxoo.com>
银平 wrote:
> Hi.
> Storing binary files as deltas is helpful [...] So is it
> possible for git to do that as svn. This is my only pain when
> using git.
Yes, and git does this already in pack files. Maybe you're not
seeing it because you haven't packed anything yet. Try to run
'git gc'.
jlh
^ permalink raw reply
* Re: [PATCH] cvsserver: added support for update -p
From: Frank Lichtenheld @ 2007-10-11 17:29 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Git Mailing List, Jan Wielemaker
In-Reply-To: <200710111852.32740.wielemak@science.uva.nl>
On Thu, Oct 11, 2007 at 06:52:32PM +0200, Jan Wielemaker wrote:
> On Thursday 11 October 2007 18:36, Frank Lichtenheld wrote:
> > Based on a patch by Jan Wielemaker <jan@swi-prolog.org>.
> >
> > Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
>
> Thanks. You are a bigger Perl programmer than I :-) Are you also
> interested in one that makes "cvs diff -c" work? It works, but it
> does not handle things like "cvs diff -C 5" and I'm a bit lost in
> Perl-space ... If someone knowing more about the server wants to
> have a look, I'm happy to post the part I have.
Hmm, the more half-patches you submit the more I'd rather prefer you
learning Perl ;) Or at least write your own testcases.
diff -c doesn't really interest me at all. So I'd really prefer you
doing the bulk of the work...
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: yet another workflow question...
From: Andreas Ericsson @ 2007-10-11 17:28 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Patrick Doyle
In-Reply-To: <200710111610.55364.andyparkins@gmail.com>
Andy Parkins wrote:
> On Thursday 2007 October 11, Patrick Doyle wrote:
>
>> burning question, "What can git do for me?" (So far, I have come to
>> the conclusion that, for my simple, single developer, branchless,
>> linear projects, there's not much that git can do for me that any
>> other SCM could do for me. It appears to have been designed to solve
>
> Here's a few things that are relevant to a simple, single, branchless, linear
> developer:
>
> - Fast. Git wipes the floor with everything else, so much so that the SCM
> becomes a tool in itself, not just a recorder of history. I keep my own
> simple projects in git just as much as my complicated, branchy, team-based
> projects just to get the following tools fast:
> git-diff
> git-status
> git-commit
> git-log
>
> - Small. In every project I've converted from SVN to git, the diskspace
> usage has gone down. SVN peppers the working tree with .svn directories,
> each of which contains a pristine copy of the last checked in version of
> all the working files. On top of that is the repository disk space itself.
>
> Git on the other hand keeps one .git directory at the top of the tree and
> that stores the _entire_ repository. It is, in my experience, smaller than
> the working tree. That means that git uses less diskspace than svn does
> for a single checkout to store everything it needs.
>
> - Useful. The following are so good, that even if you weren't doing any
> revision tracking you'd still want to use them:
> git-grep
> git-diff
>
> - Backup. Backing up subversion repositories requires that you write
> yourself a script that uses svnadmin dump. With git I just write a couple
> of lines in my .git/config and then git-push produces a highly compact
> backup whenever I want. Even better, if a disaster happens it's easy to
> pull stuff out of that backup without any additional operations.
>
> - Mobility. This one is a bit distributed, but I hope you'll let me have it.
> I often do work on my desktop at home, my desktop at work and my laptop.
> By setting my remotes up correctly in git it's really easy to walk to
> another system and pick up exactly where I left off from the other
> computer. More importantly though, when you accidentally make changes in
> two places, there is no danger of data loss.
>
> Even if you aren't doing complicated stuff, git is the way to go. I can't
> count the number of ways it's made me more productive and enhanced the code I
> write and the documentation of its development. If I never worked on another
> group project again I would still use git all day every day.
>
I'm amazed nobody has mentioned git-bisect yet. Recently, I had an enormous amount
of benefit from it, so I'll just add it here as a success-story in case any OSS
support company comes along and wants to peddle git.
As it happens, I have a daemon that does some fairly clever scheduling. Somewhere
in a recent change, I had introduced a very subtle bug that made the latency times
for when the actions were actually happening diverge from 0s. I know I get a
latency spike just when I fire the daemon up, but it's supposed to normalize after
10 or so minutes and converge on zero-latency. Instead it was slowly increasing,
but the effects weren't really visible until after about 2 hours.
git bisect to the rescue. Since I didn't feel terribly inclined to walk over to
my computer every two hours to recompile, wipe logs and start the daemon all over
again, I hacked up a script to do it for me. The script also checked the latency
figures and re-ran git-bisect as necessary.
22 hours (or 7 bisects) later, git had, with a little help from my script, shown
me exactly the commit that introduced the latency issue. During the time, I was
enjoying a walk in the sun, dinner with my girlfriend and a good nights sleep.
Life is good when you have the proper tools.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Is it possible for git to support binary differencing for binary files?
From: 银平 @ 2007-10-11 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0710111704570.4174@racer.site>
Hi.
Storing binary files as deltas is helpful to keep source and binary files
together and in sync So is it possible for git to do that as svn. This is
my only pain when using git.
^ permalink raw reply
* Re: RCS keyword expansion
From: Oliver Kullmann @ 2007-10-11 15:59 UTC (permalink / raw)
To: git
In-Reply-To: <86fy0hvgbh.fsf@blue.stonehenge.com>
On Thu, Oct 11, 2007 at 08:09:22AM -0700, Randal L. Schwartz wrote:
> >>>>> "Peter" == Peter Karlsson <peter@softwolves.pp.se> writes:
>
> Peter> I mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the
> Peter> file was last changed. Possibly even have an $Id$ that gives me
> Peter> something useful (name and commit hash, perhaps?). Is it possible to do
> Peter> this? Can it be done through git-cvsserver?
>
> That's not a job for a source code manager to do. It's a job for your
> build/install tool. See how "git --version" gets created in the core distro,
> and follow that example.
>
This looks like a misunderstanding of what $Date$ is used for:
It has not much to do with a version number (such things are decisions
by the developers), but it is an identification stamp, typically
used to identify exactly which piece of code is involved in a
given executable.
Our group also needs a replacement for the keyword-expansion mechanism
(we are using a nice little system, which allows for each executable produced
to query it about the source-code-files involved in it, which is especially
useful for testing and development, where many versions of many files
float around (and perhaps some shouldn't)).
The principle solution seems quite clear to me: Adapt the pre-commit hook,
so that files are scanned for the keyword, and apply the keyword expansion
then before the actual commit.
Better than just the date, it would be greatest to be able to put also
the SHA1-ID of the commit into the file, alas this is a bit complicated,
since it's a pre-commit hook; However it seems necessary to have in
the repository really the actual file content, not "modulo some modification",
due to the distributed character of Git repositories (everybody should have
the same file-timestamp), and so a post-commit hook shouldn't be used.
So well, using the previous SHA1-ID should be a reasonable approximation.
Oliver
^ permalink raw reply
* Re: [PATCH] cvsserver: added support for update -p
From: Jan Wielemaker @ 2007-10-11 16:52 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Junio C Hamano, Jan Wielemaker
In-Reply-To: <1192120573-16765-1-git-send-email-frank@lichtenheld.de>
On Thursday 11 October 2007 18:36, Frank Lichtenheld wrote:
> Based on a patch by Jan Wielemaker <jan@swi-prolog.org>.
>
> Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Thanks. You are a bigger Perl programmer than I :-) Are you also
interested in one that makes "cvs diff -c" work? It works, but it
does not handle things like "cvs diff -C 5" and I'm a bit lost in
Perl-space ... If someone knowing more about the server wants to
have a look, I'm happy to post the part I have.
Cheers --- Jan
^ permalink raw reply
* [PATCH] cvsserver: added support for update -p
From: Frank Lichtenheld @ 2007-10-11 16:36 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Jan Wielemaker, Frank Lichtenheld
In-Reply-To: <200710101316.03633.jan@swi-prolog.org>
Based on a patch by Jan Wielemaker <jan@swi-prolog.org>.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
git-cvsserver.perl | 23 +++++++++++++++++++++++
t/t9400-git-cvsserver-server.sh | 32 ++++++++++++++++++++++++++++++++
2 files changed, 55 insertions(+), 0 deletions(-)
Test cases added and fixed behaviour for non-existant files.
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 2e112fa..7374875 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -973,6 +973,29 @@ sub req_update
$meta = $updater->getmeta($filename);
}
+ # if we have a -p we should just send the file
+ if ( exists ( $state->{opt}{p} ) )
+ {
+ if (! defined $meta)
+ {
+ # non-existant files are ignored
+ print "E cvs update: nothing known about `$filename'\n";
+ next;
+ }
+ if ( open my $fh, '-|', "git-cat-file", "blob", $meta->{filehash} )
+ {
+ while ( <$fh> )
+ {
+ print "M $_";
+ }
+ close $fh or die ("Couldn't close filehandle: $!");
+ } else {
+ die("Couldn't execute git-cat-file");
+ }
+
+ next;
+ }
+
if ( ! defined $meta )
{
$meta = {
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index ee58c0f..4f45578 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -446,6 +446,38 @@ test_expect_success 'cvs update (merge no-op)' \
diff -q merge ../merge'
cd "$WORKDIR"
+test_expect_success 'cvs update (-p)' \
+ 'cd cvswork &&
+ GIT_CONFIG="$git_config" cvs -Q update -p merge non-existant testfile1 empty >log &&
+ cat merge testfile1 empty >../expected &&
+ diff -q log ../expected'
+
+cd "$WORKDIR"
+test_expect_success 'cvs update (-p -r)' \
+ 'echo testfile1 >expected &&
+ for i in 1 2 3 4 5 6 7
+ do
+ echo Line $i >>expected
+ done &&
+ echo >>expected &&
+ cd cvswork &&
+ GIT_CONFIG="$git_config" cvs -Q update -p -r1.1 testfile1 merge empty >log &&
+ diff -q log ../expected'
+
+cd "$WORKDIR"
+test_expect_success 'cvs update (-p unclean and out-of-date)' \
+ 'echo testfile2 >testfile2 &&
+ echo Line 10 >>merge &&
+ git add testfile2 merge &&
+ git commit -q -m "update -p" &&
+ git push gitcvs.git >/dev/null &&
+ cat testfile2 merge >expected &&
+ cd cvswork &&
+ echo "Line 10 workdir" >>merge
+ GIT_CONFIG="$git_config" cvs -Q update -p testfile2 merge >log &&
+ diff -q log ../expected'
+
+cd "$WORKDIR"
cat <<EOF >list-modules-cmd
Root $SERVERDIR
Valid-responses ok error Valid-requests Force-gzip Referrer Redirect Checked-in New-entry Checksum Copy-file Updated Created Update-existing Merged Patched Rcs-diff Mode Mod-time Removed Remove-entry Set-static-directory Clear-static-directory Set-sticky Clear-sticky Edit-file Template Clear-template Notified Module-expansion Wrapper-rcsOption M Mbinary E F MT
--
1.5.3.4
^ permalink raw reply related
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Johannes Schindelin @ 2007-10-11 16:07 UTC (permalink / raw)
To: Thomas Harning Jr.; +Cc: git
In-Reply-To: <e47324780710110857s472bf099u3e350d17a2c29f78@mail.gmail.com>
Hi,
On Thu, 11 Oct 2007, Thomas Harning Jr. wrote:
> I use gmail as my mail client and it doesn't grok 'PATCH' filters
> (primarily the case of the word).
That's just another bug in gmail.
> Are there any of you using Gmail that has managed to get around this
> issue....?
We did not even find a way to post patches via gmail's web interface, not
without severely damaging the patches. So I guess no, most of us avoid
the web interface (unless absolutely necessary, in which case we resort to
the less than brilliant solution to attach the patches).
> Perhaps we should have a separate mailing list for patches vs
> discussion.
I, for one, am totally opposed to this split. All too often valuable
_user_ discussions turn into _technical_ discussions, and thence into a
throwing back and forth patches.
Ciao,
Dscho
^ permalink raw reply
* Suggestion for mailing lists... split [PATCH]-es into own list
From: Thomas Harning Jr. @ 2007-10-11 15:57 UTC (permalink / raw)
To: git
I use gmail as my mail client and it doesn't grok 'PATCH' filters
(primarily the case of the word).
Are there any of you using Gmail that has managed to get around this issue....?
Perhaps we should have a separate mailing list for patches vs discussion.
--
Thomas Harning Jr.
^ permalink raw reply
* Re: git branch performance problem?
From: Linus Torvalds @ 2007-10-11 15:16 UTC (permalink / raw)
To: hanwen; +Cc: Lars Hjemli, git
In-Reply-To: <f329bf540710101926vedf8b19p52e3eeb193203d03@mail.gmail.com>
On Wed, 10 Oct 2007, Han-Wen Nienhuys wrote:
>
> I recall reading a few months ago that it was "clone -l" that gave you
> the jeebies, rather than "clone -s".
Yes, "clone -l" gives me the jeebies, because I'm a totally anal person
when it comes to disk corruption and a worry-wart. I've just had it happen
too many times (usually because a disk simply goes bad), and "git clone
-l" basically means that if one repository gets corrupted, then so does
the other one.
But clone -s gives me even *more* jeebies, although I think it's in some
respect also more useful. The alternates thing is really useful for
servers in particular, where you basically want to have multiple
"branches" maintained by lots of people, but all based on some expected
base version.
So if you think of alternates as a "kernel.org" or "repo.or.cz" thing,
where you might have a hundred different repositories all based on the
same "standard" version, then I think you basically have the right model.
In that situation, "git clone -l" doesn't work that well, since the
repositories just start out sharing data, but don't do it long term.
So "git clone -l" (which is the default now - my jeebies really are my
personal psychological problem) is really useful for latency reasons for a
local clone, and has basically no real downsides. It's not useful for
*backups*, but it's useful for development.
> > So the rule really is: never *ever* do anything but fast-forward in a repo
> >[..]
>
> Methinks this is all too difficult. I will use clone -l henceforth. Is
> there any reason to prefer -s over -l?
Good. And no, for actual *development* there is no reason to prefer -s
over -l (and as mentioned, '-l' is the default in modern versions).
For a git *server* setup, -s is better, since it's more long-term. But in
that situation, it also requires that the server maintainer have some
rules (ie only use "-s" for stable base trees and/or use extra care when
repacking the base).
> Given your lengthy exposition on the dangers of alternates, I would say
> this is a features that deserves to be buried or at least deemphasized
> in the documentation.
I do agree. We should make the dangers very clear.
> For cherrypicking convenience, I would still appreciate it if there
> was a mechanism similar to alternates that would allow me to view
> objects from an alternate repo; objects found through this mechanism
> should never be assumed to be present in the database, of course.
Well, the way that really should work is that you "git fetch remote" and
work on the end result in a "remote branch".
That *will* make the objects present in the database, but not in your
actual branches (until you cherry-pick), but there really are no real
downsides. If the remote is truly related to your local tree, it all
delta's so well that the disk space issues should basically be none.
Linus
^ permalink raw reply
* Re: yet another workflow question...
From: Andy Parkins @ 2007-10-11 15:10 UTC (permalink / raw)
To: git; +Cc: Patrick Doyle
In-Reply-To: <e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com>
On Thursday 2007 October 11, Patrick Doyle wrote:
> burning question, "What can git do for me?" (So far, I have come to
> the conclusion that, for my simple, single developer, branchless,
> linear projects, there's not much that git can do for me that any
> other SCM could do for me. It appears to have been designed to solve
Here's a few things that are relevant to a simple, single, branchless, linear
developer:
- Fast. Git wipes the floor with everything else, so much so that the SCM
becomes a tool in itself, not just a recorder of history. I keep my own
simple projects in git just as much as my complicated, branchy, team-based
projects just to get the following tools fast:
git-diff
git-status
git-commit
git-log
- Small. In every project I've converted from SVN to git, the diskspace
usage has gone down. SVN peppers the working tree with .svn directories,
each of which contains a pristine copy of the last checked in version of
all the working files. On top of that is the repository disk space itself.
Git on the other hand keeps one .git directory at the top of the tree and
that stores the _entire_ repository. It is, in my experience, smaller than
the working tree. That means that git uses less diskspace than svn does
for a single checkout to store everything it needs.
- Useful. The following are so good, that even if you weren't doing any
revision tracking you'd still want to use them:
git-grep
git-diff
- Backup. Backing up subversion repositories requires that you write
yourself a script that uses svnadmin dump. With git I just write a couple
of lines in my .git/config and then git-push produces a highly compact
backup whenever I want. Even better, if a disaster happens it's easy to
pull stuff out of that backup without any additional operations.
- Mobility. This one is a bit distributed, but I hope you'll let me have it.
I often do work on my desktop at home, my desktop at work and my laptop.
By setting my remotes up correctly in git it's really easy to walk to
another system and pick up exactly where I left off from the other
computer. More importantly though, when you accidentally make changes in
two places, there is no danger of data loss.
Even if you aren't doing complicated stuff, git is the way to go. I can't
count the number of ways it's made me more productive and enhanced the code I
write and the documentation of its development. If I never worked on another
group project again I would still use git all day every day.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: RCS keyword expansion
From: Randal L. Schwartz @ 2007-10-11 15:09 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710111542420.23849@ds9.cixit.se>
>>>>> "Peter" == Peter Karlsson <peter@softwolves.pp.se> writes:
Peter> I mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the
Peter> file was last changed. Possibly even have an $Id$ that gives me
Peter> something useful (name and commit hash, perhaps?). Is it possible to do
Peter> this? Can it be done through git-cvsserver?
That's not a job for a source code manager to do. It's a job for your
build/install tool. See how "git --version" gets created in the core distro,
and follow that example.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ 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