* Re: inexplicable failure to merge recursively across cherry-picks
From: Sam Vilain @ 2007-10-11 21:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: martin f krafft, git discussion list
In-Reply-To: <alpine.LFD.0.999.0710100808150.3838@woody.linux-foundation.org>
Linus Torvalds wrote:
> So git doesn't try to avoid conflicts per se: the merge strategies are
> fundamentally pretty simple (rename detection and the whole "recursive
> merge" thing may not be simple code, but the concepts are pretty
> straightforward), and they handle all the really *obvious* cases, but at
> the same time, I feel strongly that anything even half-way subtle should
> not be left to the SCM - the SCM should show it and make it really easy
> for the user to then fix it up.
This is true. However I think there are some obvious places for
improvement that does look at the file history, when the regular
algorithm fails;
1. do a --cherry-pick rev-list on just the file being merged and see if
all the changes on one side disappear, in which case just take the result.
2. see if the files were identical at some point, in which case use a
new merge base for that file based on the changes since that revision.
I actually thought #2 was already the way recursive worked!
Sam.
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Sam Vilain @ 2007-10-11 21:40 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Eivind LM, git
In-Reply-To: <27DDC599-C7A0-4660-B5C6-7DFCEB137C14@steelskies.com>
Jonathan del Strother wrote:
>> For example, I want to convert one subversion repository which
>> contains the folders:
>> trunk/projectA
>> trunk/projectB
>>
>> into two git repositories:
>> projectA.git
>> projectB.git
>
> I have a slightly different layout to you -
>
> projectA/trunk
> projectA/branches
> projectA/tags
> projectB/trunk
> projectB/branches
> projectB/tags
> etc
>
> - but I've been creating separate git repos from that with (for
> example) :
>
> git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA
> git-svn fetch
>
>
> Or will git-svn not work with your sort of layout?
It does work. Use:
git-svn init -t projectA/tags -b projectA/branches \
-T trunk/projectA http://svn.host.com/
git fetch
Also you can expect the import results of each branch to be the same
regardless of whether you import all at once using a command like the
above, or import a single path without passing -t / -b / -T to git svn init.
If you have a lot of projects to mine from a single repository, use
svnsync or SVN::Mirror/svk and then import from the local repository
with --use-svm-props.
Sam.
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: David Kastrup @ 2007-10-11 21:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jonathan del Strother, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710112227000.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 11 Oct 2007, Jonathan del Strother wrote:
>
>> 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.
>
> We do not have _extensive_ tests. We want to do some coding in
> addition to waiting for our machines to finish the test. D'oh.
A good reason for not requiring special tests just for spaces.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: RCS keyword expansion
From: Sam Vilain @ 2007-10-11 21:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Oliver Kullmann, git
In-Reply-To: <Pine.LNX.4.64.0710112144380.4174@racer.site>
Johannes Schindelin wrote:
> 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.
Well, that's not entirely true. SVN for one doesn't change the keywords
on files that haven't changed. You can't have a keyword that expands to
the current head revision, for instance.
SVN's answer to the problem of how this works with merging is largely
arbitrary; if you are merging changes in, the $Id$ becomes expanded to
the merge that affected that path, not the change that introduced this
version of the file.
Sam.
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Johannes Schindelin @ 2007-10-11 21:31 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <63D5CE5B-51DD-4017-B2E2-2ADC5DCBE849@steelskies.com>
Hi,
On Thu, 11 Oct 2007, Jonathan del Strother wrote:
> 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.
We do not have _extensive_ tests. We want to do some coding in addition
to waiting for our machines to finish the test. D'oh.
> 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.
That might very well be the case, and your goal is laudable. However, I
have to agree that most devs (indeed, since you are the first to try to
fix it, _all_ except for you) do not care that deeply about spaces in the
path, and having a _single_ test for this would be the logical solution.
I mean, we do not force our main developers to run the most obscure setups
all the time just to make sure that it runs fine. Otherwise none of us
could run Linux, but a couple would be coerced into running Windows, for
example.
Ciao,
Dscho
^ permalink raw reply
* 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
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