* Re: [PATCH] Fixing path quoting issues
From: Jonathan del Strother @ 2007-10-11 21:22 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <85k5pts796.fsf@lola.goethe.zz>
On 11 Oct 2007, at 21:53, David Kastrup wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Jonathan del Strother schrieb:
>>> How are you going to test that git works on paths with spaces if the
>>> test suite doesn't run there?
>>
>> By writing a specific test?
>
> This is going to be much less thorough. And it does no harm if the
> test scripts demonstrate defensive programming.
I would also point out that most tests have already been written to
handle this case - ones that don't quote their paths are in the
minority.
^ permalink raw reply
* Re: RCS keyword expansion
From: Sam Vilain @ 2007-10-11 21:20 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0710111953460.7441@perkele.intern.softwolves.pp.se>
Peter Karlsson wrote:
> 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.
The problem is that asking for the "last commit that changed a file" is
one of those features which comes out of the wash with proper merge
support. There is often no clear answer to that question.
Here's an example. Say two people apply a patch on their own branches,
which are subsequently merged. The file was the same on both branches;
the commits may have exactly the same date, but different committers.
Now, consider what happens as you are switching branches. Instead of
just being able to check the file identity in the tree, the system has
to somehow know that the (derived) ancestry of the file is different,
and now the content has to change. That makes something that was
extremely fast, slow.
It's the sort of thing that's possible to arrange to work using hooks
(with whatever arbitrary decisions you choose to make for the areas
where it would be ambiguous), but no-one bothered because people
realised that it probably means you're trying to encapsulate the
information in the wrong place.
Sam.
^ permalink raw reply
* Re: [PATCH] cvsserver: added support for update -p
From: Frank Lichtenheld @ 2007-10-11 21:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano, Jan Wielemaker
In-Reply-To: <Pine.LNX.4.64.0710112158330.4174@racer.site>
On Thu, Oct 11, 2007 at 09:59:28PM +0100, Johannes Schindelin wrote:
> On Thu, 11 Oct 2007, Frank Lichtenheld wrote:
>
> > + if ( exists ( $state->{opt}{p} ) )
>
> I see you kept the coding style, which is not in agreement with the rest
> of git... Intention or oversight?
It is in agreement with the rest of git-cvsserver. I really like the
style of the other perl stuff in git better, but I wasn't sure what
style takes precedence...
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] cvsserver: added support for update -p
From: Johannes Schindelin @ 2007-10-11 20:59 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>
Hi,
On Thu, 11 Oct 2007, Frank Lichtenheld wrote:
> + if ( exists ( $state->{opt}{p} ) )
I see you kept the coding style, which is not in agreement with the rest
of git... Intention or oversight?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: David Kastrup @ 2007-10-11 20:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <470DD3B8.1080809@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Jonathan del Strother schrieb:
>> How are you going to test that git works on paths with spaces if the
>> test suite doesn't run there?
>
> By writing a specific test?
This is going to be much less thorough. And it does no harm if the
test scripts demonstrate defensive programming.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: RCS keyword expansion
From: Johannes Schindelin @ 2007-10-11 20:47 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20071011155956.GC11693@cs-wsok.swansea.ac.uk>
Hi,
On Thu, 11 Oct 2007, Oliver Kullmann wrote:
> 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.
It does not matter if it is a date or a version number.
The problem is this: for efficiency, git does not change files which have
not changes between the last version checked out (whatever that is) and
the current version.
This seems counterintuitive to people coming from SVN/CVS: they expect
_every_ file to be touched when checking out.
So there is not much we will do to accomodate in git; touching files which
have not changed at all (even if containing a $Id$ or a $Date$) is not the
way we want it...
As Randal already suggested: if you need something like this, you better
have a build procedure which replaced $Date$ _at a given time_ (make
install) with the current date.
Ciao,
Dscho
^ permalink raw reply
* Re: [StGit PATCH 09/13] Clear up the semantics of Series.new_patch
From: Catalin Marinas @ 2007-10-11 20:42 UTC (permalink / raw)
To: David Kågedal; +Cc: Karl Hasselström, git
In-Reply-To: <87prznxvmq.fsf@lysator.liu.se>
On 10/10/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> > On 08/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> >> Couldn't "stg pick --reverse" create a new commit and use that? That
> >> is, given that we want to revert commit C, create a new commit C* with
> >
> > Series.new_patch already creates a commit, why should we move the
> > functionality to 'pick'? The only call to new_patch with commit=False
> > seems to be from 'uncommit' (and it makes sense indeed).
>
> It might be true that the assertion could be amended so that if
> commit=True, then it is allowed to have top/bottom that doesn't
> correspond to a commit and its parent.
I'll fix this and add a test for pick --reverse.
--
Catalin
^ permalink raw reply
* Re: yet another workflow question...
From: Jing Xue @ 2007-10-11 20:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Patrick Doyle
In-Reply-To: <200710111610.55364.andyparkins@gmail.com>
Quoting Andy Parkins <andyparkins@gmail.com>:
> - 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.
To extend on this point, after picking up the randomly checked-in save
point on another computer, the save point itself can be easily
git-reset'ed. So there won't be commits like "it's utter broken but i
got to go home" polluting the history. I find that extremely handy.
Cheers.
--
Jing Xue
^ permalink raw reply
* 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
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