* Re: [PATCH] Interpret :/<pattern> as a regular expression
From: Johannes Schindelin @ 2007-06-13 13:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wggir80.fsf@assigned-by-dhcp.pobox.com>
Hi,
On Tue, 12 Jun 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Earlier, Git interpreted the pattern as a strict prefix, which made
> > the operator unsuited in many cases.
> >
> > Now, the pattern is interpreted as a regular expression (which does not
> > change the behaviour too much, since few onelines contain special regex
> > characters), so that you can say
> >
> > git diff :/.*^Signed-off-by:.Zack.Brown
> >
> > to see the diff against the most recent reachable commit which was
> > signed off by Zack, whose Kernel Cousin I miss very much.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> While this perhaps is an improvement and people who are not
> interested in paying the price have a choice of not using this
> silly syntax, I am moderately annoyed that the syntax does not
> define "the most recent reachable" very well. It is more like
> "the first one we happened to pick by diffing from reachable
> refs". It would be more useful if it took "$commit:/$pattern"
> form to limit the search among reachable ones from named commit.
"Unfortunately", $commit:/$pattern is not a good syntax, since it suggests
that you want to search _in_ $commit, not _from $commit.
How about ':/!commit=$commit:$pattern'?
Ciao,
Dscho
^ permalink raw reply
* Re: unexpected git-cherry-pick conflict
From: Gerrit Pape @ 2007-06-13 13:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, 417885
In-Reply-To: <Pine.LNX.4.64.0706131354250.4059@racer.site>
On Wed, Jun 13, 2007 at 01:58:51PM +0100, Johannes Schindelin wrote:
> On Wed, 13 Jun 2007, Gerrit Pape wrote:
> > $ git checkout master
> > Switched to branch "master"
> > $ git cherry-pick 8ddc4d5
> > CONFLICT (file/directory): There is a directory with name link in
> > 8ddc4d5... file. Added link as link~HEAD
>
> Here you _still_ have the file in master. So that conflict is really
> expected, since a cherry-pick will only do a three-way merge.
git-cherry-pick(1) states
Given one existing commit, apply the change the patch introduces, and
record a new commit that records it. This requires your working tree to
be clean (no modifications from the HEAD commit).
The patch introduced by the commit that's cherry-pick'ed has nothing to
do with the link or new directory, it just changes 'file'
$ git show 8ddc4d5
commit 8ddc4d59444a362261e10a3b22324818f5dd2fa7
Author: Gerrit Pape <pape@smarden.org>
Date: Wed Jun 13 09:10:30 2007 +0000
file
diff --git a/file b/file
index 257cc56..3bd1f0e 100644
--- a/file
+++ b/file
@@ -1 +1,2 @@
foo
+bar
$
The patch applies to master just fine. Where's my thinking wrong?
Thanks, Gerrit.
^ permalink raw reply
* [PATCH] Add a guilt-export(1) command to export a guilt series to quilt.
From: Pierre Habouzit @ 2007-06-13 14:01 UTC (permalink / raw)
To: Josef Jeff Sipek; +Cc: git, Pierre Habouzit
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Documentation/guilt-export.txt | 30 ++++++++++++++++++++++++++++++
guilt-export | 26 ++++++++++++++++++++++++++
2 files changed, 56 insertions(+), 0 deletions(-)
create mode 100644 Documentation/guilt-export.txt
create mode 100755 guilt-export
diff --git a/Documentation/guilt-export.txt b/Documentation/guilt-export.txt
new file mode 100644
index 0000000..b7b0a4b
--- /dev/null
+++ b/Documentation/guilt-export.txt
@@ -0,0 +1,30 @@
+guilt-export(1)
+===============
+
+NAME
+----
+guilt-export - Export a patch series (to be used by quilt)
+
+SYNOPSIS
+--------
+include::usage-guilt-export.txt[]
+
+DESCRIPTION
+-----------
+Export a guilt series to be used by quilt.
+
+OPTIONS
+-------
+<target_dir>::
+ Name of the directory to export the patch series to.
+ (defaults to patches).
+
+Author
+------
+Written by Pierre Habouzit <madcoder@debian.org>
+
+Documentation
+-------------
+Documentation by Pierre Habouzit <madcoder@debian.org>
+
+include::footer.txt[]
diff --git a/guilt-export b/guilt-export
new file mode 100755
index 0000000..9ff9924
--- /dev/null
+++ b/guilt-export
@@ -0,0 +1,26 @@
+#!/bin/bash
+#
+# Copyright (c) Pierre Habouzit, 2007
+#
+
+USAGE="[<target_dir>]"
+. guilt
+
+if [ $# -gt 1 ]; then
+ usage
+fi
+target_dir=${1:-"patches"}
+
+if [ -e "$target_dir" ]; then
+ die "Specified directory already exists"
+fi
+
+trap "rm -rf \"$target_dir\"" 0
+mkdir -p "$target_dir"
+
+get_series | tee "$target_dir/series" | while read p; do
+ cp "$GUILT_DIR/$branch/$p" "$target_dir/$p"
+done
+
+trap - 0
+echo "Series exported to \"$target_dir\" sucessfully."
--
1.5.2.1
^ permalink raw reply related
* Re: That improved git-gui blame viewer..
From: Marco Costalba @ 2007-06-13 14:08 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Shawn O. Pearce, Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0706131344430.4059@racer.site>
On 6/13/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > then running: git log --pretty=raw -z --parents --boundary HEAD > tmp.txt
>
> Isn't that a bit unfair? You should have passed "--pretty=raw" to
> rev-list, too.
>
> Since you already have that tree, could you try rev-list _with_
> "--pretty=raw", just for comparison?
>
Of course, here we are
running: git rev-list --pretty=raw --parents --boundary HEAD > tmp.txt
times are: 1,16s - 1,11s - 1,13s
BTW this performance gap seems to exsist only under Windows, under
Linux if I remember correctly (cannot test now) the difference is
smaller.
Marco
^ permalink raw reply
* pull into dirty working tree
From: Bill Lear @ 2007-06-13 14:14 UTC (permalink / raw)
To: git
We have some CVS users who complain that they cannot do a pull
into a dirty working tree, as they could under CVS. Here is
their scenario: they make a few changes to their code and want
to test it out; someone else pushes changes to the central repo
that they then want to add to their working tree to test also;
they then want to pull in these changes and test everything, as
if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.
They would like an option (perhaps a config option) to do a "dirty
pull".
The git-merge documentation states:
You may have local modifications in the working tree files. In other
words, git-diff is allowed to report changes. However, the merge uses
your working tree as the working area, and in order to prevent the
merge operation from losing such changes, it makes sure that they do
not interfere with the merge. Those complex tables in read-tree
documentation define what it means for a path to "interfere with the
merge". And if your local modifications interfere with the merge,
again, it stops before touching anything.
But my colleagues are still wondering: why can't git just do it as
CVS does?
I know there are workarounds: I myself documented a set of commands
to "put things on a shelf", but they still are whining.
I need a convincing argument: not a technical one, but one that is
practical (e.g. where CVS would do harm that git is preventing).
So, any explanation that I can give them why we can't have a 'git pull
--dirty' that moves things out of the way, then does the merge, then
moves thing back, aside from that it is stupid?
Bill
^ permalink raw reply
* Re: pull into dirty working tree
From: Pierre Habouzit @ 2007-06-13 14:38 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18031.64456.948230.375333@lisa.zopyra.com>
[-- Attachment #1: Type: text/plain, Size: 2697 bytes --]
On Wed, Jun 13, 2007 at 09:14:32AM -0500, Bill Lear wrote:
> We have some CVS users who complain that they cannot do a pull
> into a dirty working tree, as they could under CVS. Here is
> their scenario: they make a few changes to their code and want
> to test it out; someone else pushes changes to the central repo
> that they then want to add to their working tree to test also;
> they then want to pull in these changes and test everything, as
> if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.
>
> They would like an option (perhaps a config option) to do a "dirty
> pull".
>
> The git-merge documentation states:
>
> You may have local modifications in the working tree files. In other
> words, git-diff is allowed to report changes. However, the merge uses
> your working tree as the working area, and in order to prevent the
> merge operation from losing such changes, it makes sure that they do
> not interfere with the merge. Those complex tables in read-tree
> documentation define what it means for a path to "interfere with the
> merge". And if your local modifications interfere with the merge,
> again, it stops before touching anything.
>
> But my colleagues are still wondering: why can't git just do it as
> CVS does?
>
> I know there are workarounds: I myself documented a set of commands
> to "put things on a shelf", but they still are whining.
>
> I need a convincing argument: not a technical one, but one that is
> practical (e.g. where CVS would do harm that git is preventing).
>
> So, any explanation that I can give them why we can't have a 'git pull
> --dirty' that moves things out of the way, then does the merge, then
> moves thing back, aside from that it is stupid?
I suppose the following way would work:
$ git commit -a -m "temporary commit" # save current work
$ git branch -f dirty # ..in a separate branch
$ git reset --hard HEAD~1 # unwind this commit
$ git pull # perform a clean pull
$ git rebase master dirty # rewrite the work
<you may have to fix some conficts here>
$ git reset master # "undo" the commit
So that's definitely doable.
Though, in git, if you really work in a "pure" git environment, you
never pull until your work in your topic branch is ready for a merge.
It's a very bad habit to do otherwise: you don't _need_ to pull until
you have a clean slate.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pull into dirty working tree
From: Pierre Habouzit @ 2007-06-13 14:43 UTC (permalink / raw)
To: Bill Lear, git
In-Reply-To: <20070613143845.GD5311@artemis.intersec.eu>
[-- Attachment #1: Type: text/plain, Size: 2752 bytes --]
On Wed, Jun 13, 2007 at 04:38:45PM +0200, Pierre Habouzit wrote:
> On Wed, Jun 13, 2007 at 09:14:32AM -0500, Bill Lear wrote:
> > We have some CVS users who complain that they cannot do a pull
> > into a dirty working tree, as they could under CVS. Here is
> > their scenario: they make a few changes to their code and want
> > to test it out; someone else pushes changes to the central repo
> > that they then want to add to their working tree to test also;
> > they then want to pull in these changes and test everything, as
> > if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.
> >
> > They would like an option (perhaps a config option) to do a "dirty
> > pull".
> >
> > The git-merge documentation states:
> >
> > You may have local modifications in the working tree files. In other
> > words, git-diff is allowed to report changes. However, the merge uses
> > your working tree as the working area, and in order to prevent the
> > merge operation from losing such changes, it makes sure that they do
> > not interfere with the merge. Those complex tables in read-tree
> > documentation define what it means for a path to "interfere with the
> > merge". And if your local modifications interfere with the merge,
> > again, it stops before touching anything.
> >
> > But my colleagues are still wondering: why can't git just do it as
> > CVS does?
> >
> > I know there are workarounds: I myself documented a set of commands
> > to "put things on a shelf", but they still are whining.
> >
> > I need a convincing argument: not a technical one, but one that is
> > practical (e.g. where CVS would do harm that git is preventing).
> >
> > So, any explanation that I can give them why we can't have a 'git pull
> > --dirty' that moves things out of the way, then does the merge, then
> > moves thing back, aside from that it is stupid?
>
> I suppose the following way would work:
>
> $ git commit -a -m "temporary commit" # save current work
> $ git branch -f dirty # ..in a separate branch
> $ git reset --hard HEAD~1 # unwind this commit
> $ git pull # perform a clean pull
> $ git rebase master dirty # rewrite the work
> <you may have to fix some conficts here>
> $ git reset master # "undo" the commit
okay this is wrong because you would then "live" in the `dirty`
branch. So you'd have to do sth like:
git checkout master
git diff master..dirty | git apply
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pull into dirty working tree
From: Bill Lear @ 2007-06-13 14:45 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070613143845.GD5311@artemis.intersec.eu>
[Pierre writes:]
> I suppose the following way would work:
>
> $ git commit -a -m "temporary commit" # save current work
> $ git branch -f dirty # ..in a separate branch
> $ git reset --hard HEAD~1 # unwind this commit
> $ git pull # perform a clean pull
> $ git rebase master dirty # rewrite the work
> <you may have to fix some conficts here>
> $ git reset master # "undo" the commit
>
> So that's definitely doable.
>
> Though, in git, if you really work in a "pure" git environment, you
>never pull until your work in your topic branch is ready for a merge.
>It's a very bad habit to do otherwise: you don't _need_ to pull until
>you have a clean slate.
I know, but I can't throw git purity at them as an explanation, they
won't understand. And they would disagree about the "need" to pull.
That's for them to say: they WANT to pull without having to move aside
the makefile that they modified to add the '-wingit' option to the
compile line and just get on with their work without having to run 14
different git commands.
I'm not trying to justify their habits, but to try to see if there is
any clinching reason why this habit is not only "bad", but positively
harmful.
Bill
^ permalink raw reply
* Re: unexpected git-cherry-pick conflict
From: Johannes Schindelin @ 2007-06-13 14:43 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, 417885
In-Reply-To: <20070613134336.13661.qmail@c61f4fed932273.315fe32.mid.smarden.org>
Hi,
On Wed, 13 Jun 2007, Gerrit Pape wrote:
> On Wed, Jun 13, 2007 at 01:58:51PM +0100, Johannes Schindelin wrote:
> > On Wed, 13 Jun 2007, Gerrit Pape wrote:
> > > $ git checkout master
> > > Switched to branch "master"
> > > $ git cherry-pick 8ddc4d5
> > > CONFLICT (file/directory): There is a directory with name link in
> > > 8ddc4d5... file. Added link as link~HEAD
> >
> > Here you _still_ have the file in master. So that conflict is really
> > expected, since a cherry-pick will only do a three-way merge.
>
> git-cherry-pick(1) states
> Given one existing commit, apply the change the patch introduces, and
> record a new commit that records it. This requires your working tree to
> be clean (no modifications from the HEAD commit).
>
> The patch introduced by the commit that's cherry-pick'ed has nothing to
> do with the link or new directory, it just changes 'file'
>
> $ git show 8ddc4d5
> commit 8ddc4d59444a362261e10a3b22324818f5dd2fa7
> Author: Gerrit Pape <pape@smarden.org>
> Date: Wed Jun 13 09:10:30 2007 +0000
>
> file
>
> diff --git a/file b/file
> index 257cc56..3bd1f0e 100644
> --- a/file
> +++ b/file
> @@ -1 +1,2 @@
> foo
> +bar
> $
>
> The patch applies to master just fine. Where's my thinking wrong?
Hmm. Indeed. Thanks for clearing that up. Will work on it later.
Ciao,
Dscho
^ permalink raw reply
* Re: pull into dirty working tree
From: Pierre Habouzit @ 2007-06-13 14:47 UTC (permalink / raw)
To: Bill Lear, git
In-Reply-To: <20070613144311.GE5311@artemis.intersec.eu>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On Wed, Jun 13, 2007 at 04:43:11PM +0200, Pierre Habouzit wrote:
> On Wed, Jun 13, 2007 at 04:38:45PM +0200, Pierre Habouzit wrote:
> > I suppose the following way would work:
> >
> > $ git commit -a -m "temporary commit" # save current work
> > $ git branch -f dirty # ..in a separate branch
> > $ git reset --hard HEAD~1 # unwind this commit
> > $ git pull # perform a clean pull
> > $ git rebase master dirty # rewrite the work
> > <you may have to fix some conficts here>
>
> > $ git reset master # "undo" the commit
>
> okay this is wrong because you would then "live" in the `dirty`
> branch. So you'd have to do sth like:
>
> git checkout master
> git diff master..dirty | git apply
Alternatively and definitely shorter:
$ git commit -a -m "temporary commit" # save the current work
$ git checkout -f -b dirty HEAD~1 # have a dirty branch for the pull
$ git pull # perform the pull
$ git rebase dirty master # rewrite the work
<you may have to fix some conficts here>
$ git reset HEAD~1 # then unwind the commit
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Mail after commit
From: Jan-Benedict Glaw @ 2007-06-13 14:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Claudio Scordino, git
In-Reply-To: <46a038f90706121335i79dc5967l782101bc743dc8e2@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 736 bytes --]
On Wed, 2007-06-13 08:35:57 +1200, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 6/13/07, Claudio Scordino <cloud.of.andor@gmail.com> wrote:
> > Doesn't exist any way to make it simpler ?
>
> I think most people setup gitweb, and follow its rss feed. Not exacty
> the same, I know, but quite useful.
Erm, no, not really. Emailing the patches is *quite* useful when
there's a dedicated review team.
MfG, JBG
--
Jan-Benedict Glaw jbglaw@lug-owl.de +49-172-7608481
Signature of: The real problem with C++ for kernel modules is:
the second : the language just sucks.
-- Linus Torvalds
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: pull into dirty working tree
From: Pierre Habouzit @ 2007-06-13 14:53 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18032.776.784080.321044@lisa.zopyra.com>
[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]
On Wed, Jun 13, 2007 at 09:45:28AM -0500, Bill Lear wrote:
> [Pierre writes:]
> > I suppose the following way would work:
> >
> > $ git commit -a -m "temporary commit" # save current work
> > $ git branch -f dirty # ..in a separate branch
> > $ git reset --hard HEAD~1 # unwind this commit
> > $ git pull # perform a clean pull
> > $ git rebase master dirty # rewrite the work
> > <you may have to fix some conficts here>
> > $ git reset master # "undo" the commit
> >
> > So that's definitely doable.
> >
> > Though, in git, if you really work in a "pure" git environment, you
> >never pull until your work in your topic branch is ready for a merge.
> >It's a very bad habit to do otherwise: you don't _need_ to pull until
> >you have a clean slate.
>
> I know, but I can't throw git purity at them as an explanation, they
> won't understand. And they would disagree about the "need" to pull.
> That's for them to say: they WANT to pull without having to move aside
> the makefile that they modified to add the '-wingit' option to the
> compile line and just get on with their work without having to run 14
> different git commands.
>
> I'm not trying to justify their habits, but to try to see if there is
> any clinching reason why this habit is not only "bad", but positively
> harmful.
If it's because they have local modifications that match their use and
are not meant to be commited then I'd say that leaving it as "unclean"
work is a bad idea, because one day or the other they will have to
modify this Makefile to add a thing to commit for real. and then, 99
times over 100 they will commit their local modification too. _that_ is
harmful. And usually there is very soon a new commit to remove the local
change.
I have a project where we had .htaccess that people had to customize
to have their local checkout work in the devel web server setup. It was
always commited (wrongly). We weren't using git.
To solve those issues, there is many ways, not all are very handy, but
it works. The simplest way is to use a repository with a tool like
guilt, and each time you commit, you:
guilt pop -a (remove your changes)
... do the stuff ...
guilt push -a (push your changes again).
Maybe you can also have a local branch where you store those local
changes. But that's still a bit awkward to use. Maybe someone will come
with a better workflow for this.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [survey] Pair Programming in Free and Open Source Projects
From: Sandor Szücs @ 2007-06-13 14:35 UTC (permalink / raw)
To: git
Hello fellow hackers,
as part of our course at the Software Engineering class at the Free
University of Berlin/Germany we are holding a survey and looking for
developers to participate.
Our research context is Free and Open Source Software with a focus on
(Distributed) Pair Programming[1]. We try to explore how familiar you
are with Pair Programming in itself, if you have tried to use Pair
Programming in one of your projects, which tools you are familiar with
for communication and (Distributed) Pair Programming and how well they
worked.
Please visit [2] to particpate in the survey. It will roughly take 10
minutes to complete it. The survey will be online for the next two weeks
and be closed on the 25th of June. By participating you will be able to
receive the raw data and the result of our survey.
Sorry for disturbing, we sincerly hope you will participate and
happy hacking
Jordi, Sandor, Holger
[1] On Pair Programming two people constantly interact with each other.
One developer is playing the role of the driver who is repsonsible for
typing and the other developery is the observer responsible for
obersving
the driver, spotting issues and looking ahead. The two roles can and
should be changed. On Distributed Pair Programming the two mates don't
sit at the same work place but have technical means to collaborate.
[2]
http://survey.mi.fu-berlin.de/public/survey.php?name=dpp_2007
^ permalink raw reply
* Re: pull into dirty working tree
From: Randal L. Schwartz @ 2007-06-13 15:01 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18031.64456.948230.375333@lisa.zopyra.com>
>>>>> "Bill" == Bill Lear <rael@zopyra.com> writes:
Bill> We have some CVS users who complain that they cannot do a pull
Bill> into a dirty working tree, as they could under CVS. Here is
Bill> their scenario: they make a few changes to their code and want
Bill> to test it out; someone else pushes changes to the central repo
Bill> that they then want to add to their working tree to test also;
Bill> they then want to pull in these changes and test everything, as
Bill> if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.
Bill> They would like an option (perhaps a config option) to do a "dirty
Bill> pull".
Maybe this will do it, presuming they haven't published any of their local
work, and they're on a topic branch "topic"
git-tag WIP # mark HEAD so we can come back
git-commit -a -m WIP # commit current work so we can replay it
git-fetch origin # grabs the upstream
git-rebase origin # rebase current work-in-progress onto new upstream
# might need to resolve and commit conflicts repeatedly
git-reset --soft WIP # next commit will be on top of commit prior to rebase
git-reset # mark all files as uncommitted as yet
git-tag -d WIP # no more need for this tag
This effectively puts the upstream changes "under" (or "prior to") the current
topic branch.
--
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
* Re: That improved git-gui blame viewer..
From: Johannes Schindelin @ 2007-06-13 14:58 UTC (permalink / raw)
To: Marco Costalba
Cc: Junio C Hamano, Shawn O. Pearce, Linus Torvalds, Git Mailing List
In-Reply-To: <e5bfff550706130708k601514c9o1ba2747582027699@mail.gmail.com>
Hi,
On Wed, 13 Jun 2007, Marco Costalba wrote:
> On 6/13/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > then running: git log --pretty=raw -z --parents --boundary HEAD > tmp.txt
> >
> > Isn't that a bit unfair? You should have passed "--pretty=raw" to
> > rev-list, too.
> >
> > Since you already have that tree, could you try rev-list _with_
> > "--pretty=raw", just for comparison?
> >
>
> Of course, here we are
>
> running: git rev-list --pretty=raw --parents --boundary HEAD > tmp.txt
>
> times are: 1,16s - 1,11s - 1,13s
I just tested on cygwin. The funny thing is, I never get anything like 8
seconds (this is on git.git itself).
For me it is
~1.0s rev-list _without_ --pretty=raw
~1.6s rev-list _with_ --pretty=raw
~1.4s log _with_ --pretty=raw
~3.5s log _with_ --pretty=raw _and_ -z (!)
So, your delay could stem from -z doing weird things.
For fun, I also did it with the MinGW port:
~0.7s rev-list _without_ --pretty=raw
~1.0s rev-list _with_ --pretty=raw
~0.8s log _with_ --pretty=raw
~1.9s log _with_ --pretty=raw _and_ -z (!)
Draw your conclusions, gentlemen.
Ciao,
Dscho
^ permalink raw reply
* Re: pull into dirty working tree
From: MichaelTiloDressel @ 2007-06-13 15:03 UTC (permalink / raw)
To: git
Hi,
why don't they just do a simple
git commit -a
of their work before pulling?
That's different to cvs! Committing only affects the cloned repository.
I think one of the biggest advantages of git is the concept of everyone
working on a clone. So developers are not prevented from actually using
revision control just because they are afraid of disturbing others. They
don't until they e.g. push!
Cheers,
Michael
^ permalink raw reply
* Re: pull into dirty working tree
From: Johannes Schindelin @ 2007-06-13 15:01 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18031.64456.948230.375333@lisa.zopyra.com>
Hi,
On Wed, 13 Jun 2007, Bill Lear wrote:
> We have some CVS users who complain that they cannot do a pull
> into a dirty working tree, as they could under CVS.
Two things you can do. First thing is: teach them to commit first. If they
decide later that they did not want that change, they still can go back
with "git reset HEAD@{2}".
The other thing, if you have to, is to put all dirty changes into the
index before pull. Something like "git add $(git ls-files --modified)".
You can even make that a global alias for your users. Although IIRC it
does not work if the merge changes the same files as your dirty work tree
touches, but I could very well be wrong there.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Add a guilt-export(1) command to export a guilt series to quilt.
From: Benjamin Sergeant @ 2007-06-13 15:10 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Josef Jeff Sipek, git
In-Reply-To: <1181743313509-git-send-email-madcoder@debian.org>
For the shebang:
#!/usr/bin/env bash
should works well and should work on non-linux boxes that did not
added a link in /bin/bash.
My 2 cents.
On 6/13/07, Pierre Habouzit <madcoder@debian.org> wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> Documentation/guilt-export.txt | 30 ++++++++++++++++++++++++++++++
> guilt-export | 26 ++++++++++++++++++++++++++
> 2 files changed, 56 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/guilt-export.txt
> create mode 100755 guilt-export
>
> diff --git a/Documentation/guilt-export.txt b/Documentation/guilt-export.txt
> new file mode 100644
> index 0000000..b7b0a4b
> --- /dev/null
> +++ b/Documentation/guilt-export.txt
> @@ -0,0 +1,30 @@
> +guilt-export(1)
> +===============
> +
> +NAME
> +----
> +guilt-export - Export a patch series (to be used by quilt)
> +
> +SYNOPSIS
> +--------
> +include::usage-guilt-export.txt[]
> +
> +DESCRIPTION
> +-----------
> +Export a guilt series to be used by quilt.
> +
> +OPTIONS
> +-------
> +<target_dir>::
> + Name of the directory to export the patch series to.
> + (defaults to patches).
> +
> +Author
> +------
> +Written by Pierre Habouzit <madcoder@debian.org>
> +
> +Documentation
> +-------------
> +Documentation by Pierre Habouzit <madcoder@debian.org>
> +
> +include::footer.txt[]
> diff --git a/guilt-export b/guilt-export
> new file mode 100755
> index 0000000..9ff9924
> --- /dev/null
> +++ b/guilt-export
> @@ -0,0 +1,26 @@
> +#!/bin/bash
> +#
> +# Copyright (c) Pierre Habouzit, 2007
> +#
> +
> +USAGE="[<target_dir>]"
> +. guilt
> +
> +if [ $# -gt 1 ]; then
> + usage
> +fi
> +target_dir=${1:-"patches"}
> +
> +if [ -e "$target_dir" ]; then
> + die "Specified directory already exists"
> +fi
> +
> +trap "rm -rf \"$target_dir\"" 0
> +mkdir -p "$target_dir"
> +
> +get_series | tee "$target_dir/series" | while read p; do
> + cp "$GUILT_DIR/$branch/$p" "$target_dir/$p"
> +done
> +
> +trap - 0
> +echo "Series exported to \"$target_dir\" sucessfully."
> --
> 1.5.2.1
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Mail after commit
From: Andy Parkins @ 2007-06-13 15:10 UTC (permalink / raw)
To: git; +Cc: Jan-Benedict Glaw, Martin Langhoff, Claudio Scordino
In-Reply-To: <20070613142516.GE22027@lug-owl.de>
On Wednesday 2007 June 13, Jan-Benedict Glaw wrote:
> > I think most people setup gitweb, and follow its rss feed. Not exacty
> > the same, I know, but quite useful.
>
> Erm, no, not really. Emailing the patches is *quite* useful when
> there's a dedicated review team.
As an aside - I find it better to send announce emails on git-push rather than
git-commit. If you send an email on git-commit, then your working repository
becomes a whole lot less useful.
For example I often do:
git commit -a -m "Shelve what I'm doing right now"
git checkout -b temporary-branch HEAD^^^
vim fix-bug-that-I-never-want-anyone-to-see
git checkout master
git rebase temporary-branch
git branch -d temporary-branch
git reset HEAD^
Obviously this only works for commits I haven't pushed yet, but it's very
useful to be able to do - usually I need it because I missed a git-add of a
file out of a commit and didn't notice for a while.
Once I'm happy with my local history, then I git-push to the shared repository
and an email is generated to let other members of the team know I've done
something - they can then git-fetch and review if they feel like it.
To me, sending an email every commit would be like sending an email every time
I pressed "save" in the editor.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Add a guilt-export(1) command to export a guilt series to quilt.
From: Pierre Habouzit @ 2007-06-13 15:16 UTC (permalink / raw)
To: Benjamin Sergeant; +Cc: Josef Jeff Sipek, git
In-Reply-To: <1621f9fa0706130810n17bc3f67h1c539d75b3aed4ed@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 685 bytes --]
On Wed, Jun 13, 2007 at 08:10:36AM -0700, Benjamin Sergeant wrote:
> For the shebang:
> #!/usr/bin/env bash
> should works well and should work on non-linux boxes that did not
> added a link in /bin/bash.
FWIW it would spawn a process for nothin, and every other guilt
command uses that. People using it on non linux box would have to run a
sed on every shebang at install time, that's not _that_ hard anyways,
and is common practice with python or perl scripts e.g. IMHO it's not a
problem.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] Add gitmodules(5)
From: Matthias Lederhofer @ 2007-06-13 15:36 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <11814251322779-git-send-email-hjemli@gmail.com>
Lars Hjemli <hjemli@gmail.com> wrote:
> +SYNOPSIS
> +--------
> +.gitmodules
My asciidoc (7.1.2 and 8.2.1) generates an empty refsynopsisdiv from
this. xmlto refuses to convert this into anything else:
xmlto -m callouts.xsl man gitmodules.xml
xmlto: input does not validate (status 3)
/path/to/git/Documentation/gitmodules.xml:15: element refsynopsisdiv: validity error : Element refsynopsisdiv content does not follow the DTD, expecting (refsynopsisdivinfo? , (title , subtitle? , titleabbrev?)? , (((calloutlist | glosslist | itemizedlist | orderedlist | segmentedlist | simplelist | variablelist | caution | important | note | tip | warning | literallayout | programlisting | programlistingco | screen | screenco | screenshot | synopsis | cmdsynopsis | funcsynopsis | classsynopsis | fieldsynopsis | constructorsynopsis | destructorsynopsis | methodsynopsis | formalpara | para | simpara | address | blockquote | graphic | graphicco | mediaobject | mediaobjectco | informalequation | informalexample | informalfigure | informaltable | equation | example | figure | table | msgset | procedure | sidebar | qandaset | anchor | bridgehead | remark | highlights | abstract | authorblurb
| epigraph | indexterm | beginpage)+ , refsect2*) | refsect2+)), got ()
Document /path/to/git/Documentation/gitmodules.xml does not validate
This breaks the build process for the documentation. I could not find
out how to fix this. Probably just needs the right quoting for the
dot at the beginning of the line.
^ permalink raw reply
* Re: pull into dirty working tree
From: Bill Lear @ 2007-06-13 15:36 UTC (permalink / raw)
To: MichaelTiloDressel@t-online.de; +Cc: git
In-Reply-To: <1HyUO6-04z4yG0@fwd28.aul.t-online.de>
On Wednesday, June 13, 2007 at 17:03:58 (+0200) MichaelTiloDressel@t-online.de writes:
>Hi,
>
>why don't they just do a simple
>git commit -a
>of their work before pulling?
Because they are basically playing with some code and don't want to
commit it.
>That's different to cvs! Committing only affects the cloned repository.
Yup, we realize that.
>I think one of the biggest advantages of git is the concept of everyone
>working on a clone. So developers are not prevented from actually using
>revision control just because they are afraid of disturbing others. They
>don't until they e.g. push!
Right, but they just want updates to their working tree, as they could
do under CVS, without issuing five (or even one) other commands.
Bill
^ permalink raw reply
* Re: pull into dirty working tree
From: Andy Parkins @ 2007-06-13 15:40 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Bill Lear
In-Reply-To: <Pine.LNX.4.64.0706131559210.4059@racer.site>
On Wednesday 2007 June 13, Johannes Schindelin wrote:
> The other thing, if you have to, is to put all dirty changes into the
> index before pull. Something like "git add $(git ls-files --modified)".
Or the shiny new
git add -u
which works a treat :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Add a guilt-export(1) command to export a guilt series to quilt.
From: Josef Sipek @ 2007-06-13 15:51 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <1181743313509-git-send-email-madcoder@debian.org>
On Wed, Jun 13, 2007 at 04:01:53PM +0200, Pierre Habouzit wrote:
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
> Documentation/guilt-export.txt | 30 ++++++++++++++++++++++++++++++
> guilt-export | 26 ++++++++++++++++++++++++++
> 2 files changed, 56 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/guilt-export.txt
> create mode 100755 guilt-export
Applied.
Thanks.
Josef "Jeff" Sipek.
--
Computer Science is no more about computers than astronomy is about
telescopes.
- Edsger Dijkstra
^ permalink raw reply
* Re: [PATCH] Add a guilt-export(1) command to export a guilt series to quilt.
From: Josef Sipek @ 2007-06-13 15:54 UTC (permalink / raw)
To: Benjamin Sergeant; +Cc: Pierre Habouzit, git
In-Reply-To: <1621f9fa0706130810n17bc3f67h1c539d75b3aed4ed@mail.gmail.com>
On Wed, Jun 13, 2007 at 08:10:36AM -0700, Benjamin Sergeant wrote:
> For the shebang:
> #!/usr/bin/env bash
> should works well and should work on non-linux boxes that did not
> added a link in /bin/bash.
Ideally, the best thing to do is to change guilt to use /bin/sh. Right now,
there are a number of bash-isms that are used. And if a system doesn't have
/bin/sh, it doesn't deserve to run any useful software ;)
Patches are welcomed ;)
Josef "Jeff" Sipek.
--
Reality is merely an illusion, albeit a very persistent one.
- Albert Einstein
^ 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