* Re: [PATCH] Fix rebase interactive to allow specifying branch to rebase along with the base
From: Johannes Schindelin @ 2007-08-01 22:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20070801223241.GB2911@steel.home>
Hi,
On Thu, 2 Aug 2007, Alex Riesen wrote:
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 061cd0a..b42dee8 100755
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -404,6 +404,7 @@ do
> esac
>
> require_clean_work_tree
> + mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
>
> if test ! -z "$2"
> then
> @@ -418,7 +419,6 @@ do
>
> test -z "$ONTO" && ONTO=$UPSTREAM
>
> - mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
> : > "$DOTEST"/interactive || die "Could not mark as interactive"
> git symbolic-ref HEAD > "$DOTEST"/head-name ||
> die "Could not get HEAD"
Heh. I take that as an ACK from you to my patch? Mine has a test case,
too ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: multiple checked out branches
From: Alex Riesen @ 2007-08-01 22:34 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20070801220435.GA19226@raptus.dandreoli.com>
Domenico Andreoli, Thu, Aug 02, 2007 00:04:35 +0200:
> Hi again,
>
> I would like to contemporaneously work with multiple branches out of
> the same git repository. This does not work out of the box.
>
> So I prepare multiple copies of the same repository, every one will have
> its own checked out branch but I want to share most of their .git subdir.
>
> I surely want to share the object db, the local and remote refs.
> This way it is enough to make a round of fetches/merges/pushes to have
> all the shared-repositories up to date.
>
> I expect to do the trick with some symlinks but I am not an expert of
> git internals. Which traps are waiting me? Any hint? Thank you.
>
No traps. Supported. See for "git clone -s" and "git clone -l"
^ permalink raw reply
* [PATCH] Fix rebase interactive to allow specifying branch to rebase along with the base
From: Alex Riesen @ 2007-08-01 22:32 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Junio C Hamano
In-Reply-To: <20070801214556.GA2911@steel.home>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Alex Riesen, Wed, Aug 01, 2007 23:45:56 +0200:
> $ git rebase -i base branch
> /usr/local/bin/git-rebase--interactive: 482: cannot create /home/user/projects/tmp/.git/.dotest-merge/output: Directory nonexistent
> cat: /home/user/projects/tmp/.git/.dotest-merge/output: No such file or directory
> Invalid branchname: branch
Oh... Sometimes I can *very* slow. I believe it is as simple as that
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 061cd0a..b42dee8 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -404,6 +404,7 @@ do
esac
require_clean_work_tree
+ mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
if test ! -z "$2"
then
@@ -418,7 +419,6 @@ do
test -z "$ONTO" && ONTO=$UPSTREAM
- mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
: > "$DOTEST"/interactive || die "Could not mark as interactive"
git symbolic-ref HEAD > "$DOTEST"/head-name ||
die "Could not get HEAD"
--
1.5.3.rc3.123.ge9877
^ permalink raw reply related
* [PATCH] rebase -i: fix for optional [branch] parameter
From: Johannes Schindelin @ 2007-08-01 22:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, gitster
In-Reply-To: <20070801214556.GA2911@steel.home>
When calling "git rebase -i <upstream> <branch>", git should switch
to <branch> first. This worked before, but I broke it by my
"Shut git rebase -i up" patch.
Fix that, and add a test to make sure that it does not break again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 1 Aug 2007, Alex Riesen wrote:
> Johannes Schindelin, Wed, Aug 01, 2007 17:57:25 +0200:
> > On Fri, 13 Jul 2007, Alex Riesen wrote:
> >
> > > Could we also have "git rebase <base> <branch>"?
> >
> > Don't we do that already? AFAICT it is already in the
> > synopsis, ever since rebase -i was introduced into the "next"
> > branch, on June 25...
> >
>
> Err... "git rebase -i <base> <branch>"
>
> Does not work, just checked:
>
> $ git rebase -i base branch
> /usr/local/bin/git-rebase--interactive: 482: cannot create /home/user/projects/tmp/.git/.dotest-merge/output: Directory nonexistent
> cat: /home/user/projects/tmp/.git/.dotest-merge/output: No such file or directory
> Invalid branchname: branch
Sorry...
git-rebase--interactive.sh | 2 +-
t/t3404-rebase-interactive.sh | 8 ++++++++
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index d3addd4..bdec462 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -405,6 +405,7 @@ do
require_clean_work_tree
+ mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
if test ! -z "$2"
then
output git show-ref --verify --quiet "refs/heads/$2" ||
@@ -418,7 +419,6 @@ do
test -z "$ONTO" && ONTO=$UPSTREAM
- mkdir "$DOTEST" || die "Could not create temporary $DOTEST"
: > "$DOTEST"/interactive || die "Could not mark as interactive"
git symbolic-ref HEAD > "$DOTEST"/head-name ||
die "Could not get HEAD"
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index dc436d7..a9b552f 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -98,6 +98,14 @@ test_expect_success 'no changes are a nop' '
test $(git rev-parse I) = $(git rev-parse HEAD)
'
+test_expect_success 'test the [branch] option' '
+ git checkout -b dead-end &&
+ git rm file6 &&
+ git commit -m "stop here" &&
+ git rebase -i F branch2 &&
+ test $(git rev-parse I) = $(git rev-parse HEAD)
+'
+
test_expect_success 'rebase on top of a non-conflicting commit' '
git checkout branch1 &&
git tag original-branch1 &&
--
1.5.3.rc3.112.gf60b6
^ permalink raw reply related
* Re: multiple checked out branches
From: Julian Phillips @ 2007-08-01 22:19 UTC (permalink / raw)
To: Domenico Andreoli; +Cc: git
In-Reply-To: <20070801220435.GA19226@raptus.dandreoli.com>
On Thu, 2 Aug 2007, Domenico Andreoli wrote:
> Hi again,
>
> I would like to contemporaneously work with multiple branches out of
> the same git repository. This does not work out of the box.
Depends on how you define "the box" ...
There is a script to do this in contrib called git-new-workdir. It allows
you to have multiple working directories from the same repository for
exactly this purpose.
> So I prepare multiple copies of the same repository, every one will have
> its own checked out branch but I want to share most of their .git subdir.
>
> I surely want to share the object db, the local and remote refs.
> This way it is enough to make a round of fetches/merges/pushes to have
> all the shared-repositories up to date.
>
> I expect to do the trick with some symlinks but I am not an expert of
> git internals. Which traps are waiting me? Any hint? Thank you.
Symlinks are exactly what is used by new-workdir to link the workdirs back
to the original repository.
The biggest issue with doing this is that you have no protection against
making changes on the same branch in more than one place - something you
really don't want to be dealing with. Basically you need to be careful
about updating refs that you have checkedout in workdirs.
--
Julian
---
...when fits of creativity run strong, more than one programmer or writer has
been known to abandon the desktop for the more spacious floor.
- Fred Brooks, Jr.
^ permalink raw reply
* Re: MinGW build environment for Git
From: Dmitry Kakurin @ 2007-08-01 22:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marius Storm-Olsen, git
In-Reply-To: <Pine.LNX.4.64.0708011143180.14781@racer.site>
On 8/1/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 1 Aug 2007, Dmitry Kakurin wrote:
>
> > On 7/31/07, Marius Storm-Olsen <marius@trolltech.com> wrote:
> > > Dmitry Kakurin said the following on 30.07.2007 01:14:
> > > > I want to be able to build MinGW port of Git on Windows. I've tried
> > > > to follow steps in README.MinGW to setup this environment myself
> > > > (install MinGW, MSys, ZLib etc.) but after wasting a lot of time
> > > > with no result I give up. So, could somebody please just pkzip
> > > > their environment (everything required) and share the zip file with
> > > > me (privately or publicly)? I also think that an even better idea
> > > > is to create a new Git repository with MinGW build environment.
> > > > This will make contributing to MinGW port of Git MUCH easier.
> > >
> > > Aaron has done this, and you can find the link on his blog, here:
> > > http://www.ekips.org/cgi-bin/aaron.cgi/2007/02/27
> >
> > I've downloaded and installed it. But I could not make it work :-(.
> > First I had this problem:
> > $ make
> > GIT_VERSION = 1.5.3.GIT
> > * new build flags or prefix
> > CC convert-objects.o
> > gcc.exe: installation problem, cannot exec `cc1': No such file or directory
> > make: *** [convert-objects.o] Error 1
> >
> > Then I've copied cc1.exe and some others from
> > C:\mingw4git\libexec\gcc\mingw32 into /bin.
> >
> > $ make
> > CC convert-objects.o
> > In file included from cache.h:4,
> > from convert-objects.c:1:
> > git-compat-util.h:51:22: sys/wait.h: No such file or directory
> >
> > Searching entire (downloaded) tree for wait.h gives nothing.
> >
> > 'make configure' does not work:
> > $ make configure
> > GEN configure
> > configure.ac+:4: error: Autoconf version 2.59 or higher is required
> > configure.ac+:4: the top level
> > autom4te: /bin/m4 failed with exit status: 1
> > make: *** [configure] Error 1
> >
> > What do I do now?
>
> This looks like you downloaded git.git. Official releases do not have
> MinGW support yet! You have to get the MinGW port from repo.or.cz:
>
> http://repo.or.cz/w/git/mingw.git
You were right. I was downloading Git under Cygwin and then copied it
to MSys. Somewhere along the way I got confused and copied the wrong
directory.
It works now!
Thank you!
- Dmitry
^ permalink raw reply
* Re: [PATCH] git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
From: David Kastrup @ 2007-08-01 22:17 UTC (permalink / raw)
To: git
In-Reply-To: <S1752294AbXHAWCj/20070801220239Z+281@vger.kernel.org>
David Kastrup <dak@gnu.org> writes:
> The previous code only allowed specifying a single executable rather
> than a complete command like "emacsclient --alternate-editor vi" in
Oops, won't apply cleanly. I found that I had already made a
different (trivial) patch previously. Let me try again and fold that
patch in manually.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Jakub Narebski @ 2007-08-01 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, Linus Torvalds, Git Mailing List
In-Reply-To: <7vr6mn5znm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Perhaps if the destination is local,
>
> - if -s is given, just set up alternates, do nothing else;
> - by default, do "always copy never hardlink";
> - with -l, do "hardlink if possible";
>
> Hmmmm...
That I think it is the best solution, together with support for
file:///path/to/repo.git scheme which would turn on old repacking
behavior. I'm all for it.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: cvs2svn conversion directly to git ready for experimentation
From: Jakub Narebski @ 2007-08-01 22:09 UTC (permalink / raw)
To: git; +Cc: users
In-Reply-To: <46AFCF3E.5010805@alum.mit.edu>
Michael Haggerty wrote:
> I am the maintainer of cvs2svn[1], which is a program for one-time
> conversions from CVS to Subversion. cvs2svn is very robust against the
> many peculiarities of CVS and can convert just about every CVS
> repository we have ever seen.
>
> I've been working on a cvs2svn output pass that writes the converted CVS
> repository directly into git rather than Subversion. The code runs now
> with at least one repository from our test suite of nasty CVS repositories.
Have you contacted Jon Smirl about his unpublished work on cvs2git,
cvs2svn based CVS to Git converter?
Quote from InterfacesFrontendsAndTools page on GIT wiki[1]:
cvs2git is the unofficial name of Jon Smirl's modifications to cvs2svn.
These modifications allow cvs2svn to generate a data stream which is
consumed by Shawn Pearce's git-fast-import (now included in git.git).
git-fast-import converts its input stream directly into a Git .pack file,
minimizing the amount of IO required on large imports.
Jon Smirl stopped working on cvs2git[2] because first, Mozilla (which was
main target of his work) decided that to not to move to git, and second
because of troubles with cvs2svn architecture[*] (which it is based on).
Jon Smirl has posted his impressions on working on CVS importer in
"Some tips for doing a CVS importer" thread[3].
References:
-----------
[1] http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-23858c2cde0cef60443d8e73e6829a95f8e191ef
[2] http://msgid.gmane.org/9e4733910611190940y147992b8mbdfac5a51f42e0fe@mail.gmail.com
[3] http://marc.theaimsgroup.com/?t=116405956000001&r=1&w=2
Footnotes:
----------
[*] If I remember correctly authors of cvs2svn were talking about separating
the code dealing with disentangling CVS repository structure from the part
translating it into Subversion repository (with its quirks), and the part
generating Subversion repository.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC/PATCH 2/2] gitweb: Add an option to show size of blobs in the tree view
From: Jakub Narebski @ 2007-08-01 13:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4y8fcjw.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Aug 2007, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> It allows to play with 'tree' view with blob size. Currently you
>> have to start browsing by adding ";opt=-l" to the gitweb URL by
>> hand. There is not link which will change view from ordinary 'tree'
>> view to 'tree' view with blob sizes.
>>
>> The 'tree' with blob size view is slightly more costly than the
>> ordinary, old 'tree' view, but not much more (0.018s vs 0.012s
>> in the hot cache case), so I don't think we need to control it
>> as a enabled (or disabled) feature, overrideable or not. It
>> probably should not be default.
>
> I do not think there is any reason to forbid its use, as the
> "-l" to ls-tree was introduced for exactly this purpose,
> However, it might make sense to make the use of -l optional via
> the %feature mechanism. 50% increase even on hot cache case is
> not a price people who run busy sites would want to pay.
It's 0.014s vs 0.009s - 0.010s on root dir of repacked git.git
repository. It is I think caused by the fact that "git ls-tree -l
<tree-ish>" has to look up each blob in the tree, and read its
header. IIRC header is uncompressed, so it doesn't need deflating;
if it is compressed, then we have to add deflating to that. The
blob size (object size) is not present in the tree object structure.
Perhaps it is something to have in mind when designing and implementing
new packv4 with its creating tree objects on demand.
But I agree that this should be protected by the %feature mechanism.
Two questions:
1. Should we make '-l' default when turned on? Or make 'showsizes'
%feature tristate: off, on, by default on?
2. If it is turned off, should we silently (or not so silently)
ignore this option, or return "Permission denied" or perhaps
"Invalid extra options parameter"?
And how we should name this feature (key in %feature hash)?
P.S. I have received no comments on
[RFC/PATCH] gitweb: Enable transparent compression for HTTP output
(trade CPU load for lower bandwidth usage).
--
Jakub Narebski
Poland
^ permalink raw reply
* multiple checked out branches
From: Domenico Andreoli @ 2007-08-01 22:04 UTC (permalink / raw)
To: git
Hi again,
I would like to contemporaneously work with multiple branches out of
the same git repository. This does not work out of the box.
So I prepare multiple copies of the same repository, every one will have
its own checked out branch but I want to share most of their .git subdir.
I surely want to share the object db, the local and remote refs.
This way it is enough to make a round of fetches/merges/pushes to have
all the shared-repositories up to date.
I expect to do the trick with some symlinks but I am not an expert of
git internals. Which traps are waiting me? Any hint? Thank you.
Regards,
Domenico
-----[ Domenico Andreoli, aka cavok
--[ http://www.dandreoli.com/gpgkey.asc
---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
^ permalink raw reply
* Re: Git benchmark - comparison with Bazaar, Darcs, Git and Mercurial
From: Theodore Tso @ 2007-08-01 22:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <7vr6mn5znm.fsf@assigned-by-dhcp.cox.net>
On Wed, Aug 01, 2007 at 03:15:25AM -0700, Junio C Hamano wrote:
> > So would you accept a patch which adds a git-config variable which
> > specifies whether or not local clones should use hard links by default
> > (defaulting to yes), and which adds a --no-hard-links option to
> > git-clone to override the config option?
>
> Are you suggesting to make -l the default for local, in other
> words? I personally do not make local clone often enough that I
> am not disturbed having to type extra " -l" on the command line.
Yeah, essentially, with a git-config option (and comand-line option)
to override the default for those people who are "squeamish" about git
clone -l. Linus's suggestion of using file:// as a way to indicate
non-local also makes a lot of sense to me.
> Perhaps if the destination is local,
>
> - if -s is given, just set up alternates, do nothing else;
As I understand it, the main objection with making -s the default is
surprising result that could happen if you do a git-prune in the base
repository which causes objects which are borrowed from the base
repository via .git/objects/info/alternates, right?
What if git clone -s appended the repository which is borrowing
objects via alternates to a file located in the base repository,
.git/objects/info/shared-repos?
Then git-prune could also use the refs marked in each of the
downstream repositories that are sharing objects with base repository
and not make those objects go away. That way, git-gc --prune won't do
anything surprising to any shared repositories, since it will scan
those shared repositories automatically. Would that be considered
acceptable? That way you can get instant clones even on filesystems
that don't support hard links, such as Windows systems.
The way I would suggest doing it is once we implement support for
.git/objects/info/shared-repos is to do the following with git-clone
by default:
* If the source repo is specified via a file:// URL, per Linus's
suggestion, do the clone via copying.
* If the source repo is specified via a local pathname, and
.git/objects/info/shared-repos in the source repository is
writeable by the user who is doing the clone, then do a
clone -s.
* If the above fails, try clone -l
* If the above fails, do a clone via copying over a new pack
Would this be acceptable? Patches to do the following should be
fairly easy to whip up. Obviously this wouldn't be for 1.5.3. :-)
- Ted
^ permalink raw reply
* [PATCH] git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
From: David Kastrup @ 2007-08-01 21:47 UTC (permalink / raw)
To: git
In-Reply-To: <7v7iof3uc5.fsf@assigned-by-dhcp.cox.net>
The previous code only allowed specifying a single executable rather
than a complete command like "emacsclient --alternate-editor vi" in
those variables. Since VISUAL/EDITOR appear to be traditionally
passed to a shell for interpretation (as corroborated with "less",
"mail" and "mailx", while the really ancient "more" indeed allows only
an executable name), the shell function git_editor has been amended
appropriately.
"eval" is employed to have quotes and similar interpreted _after_
expansion, so that specifying
EDITOR='"/home/dak/My Commands/notepad.exe"'
can be used for actually using commands with blanks.
Instead of passing just the first argument of git_editor on, we pass
all of them (so that +lineno might be employed at a later point of
time, or so that multiple files may be edited when appropriate).
Strictly speaking, there is a change in behavior: when
git config core.editor
returns a valid but empty string, the fallbacks are still searched.
This is more consistent, and the old code was problematic with regard
to multiple blanks. Putting in additional quotes might have worked,
but quotes inside of command substitution inside of quotes is nasty
enough to not reliably work the same across "Bourne shells".
Signed-off-by: David Kastrup <dak@gnu.org>
---
git-sh-setup.sh | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 3c0367d..3c50bc1 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -29,7 +29,8 @@ set_reflog_action() {
}
git_editor() {
- GIT_EDITOR=${GIT_EDITOR:-$(git config core.editor || echo ${VISUAL:-${EDITOR}})}
+ : "${GIT_EDITOR:=$(git config core.editor)}"
+ : "${GIT_EDITOR:=${VISUAL:-${EDITOR}}}"
case "$GIT_EDITOR,$TERM" in
,dumb)
echo >&2 "No editor specified in GIT_EDITOR, core.editor, VISUAL,"
@@ -40,7 +41,7 @@ git_editor() {
exit 1
;;
esac
- ${GIT_EDITOR:-vi} "$1"
+ eval "${GIT_EDITOR:=vi}" '"$@"'
}
is_bare_repository () {
--
1.5.3.rc2.86.gdc7ba
^ permalink raw reply related
* Re: [PATCH 1/3] rebase -i: handle --continue more like non-interactive rebase
From: Alex Riesen @ 2007-08-01 21:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0708011654510.14781@racer.site>
Johannes Schindelin, Wed, Aug 01, 2007 17:57:25 +0200:
> On Fri, 13 Jul 2007, Alex Riesen wrote:
> > Johannes Schindelin, Sun, Jul 08, 2007 04:01:29 +0200:
> > > Non-interactive rebase requires the working tree to be clean, but
> > > applies what is in the index without requiring the user to do it
> > > herself. Imitate that, but (since we are interactive, after all)
> > > fire up an editor with the commit message.
> >
> > Could we also have "git rebase <base> <branch>"?
>
> Don't we do that already? AFAICT it is already in the synopsis, ever
> since rebase -i was introduced into the "next" branch, on June 25...
>
Err... "git rebase -i <base> <branch>"
Does not work, just checked:
$ git rebase -i base branch
/usr/local/bin/git-rebase--interactive: 482: cannot create /home/user/projects/tmp/.git/.dotest-merge/output: Directory nonexistent
cat: /home/user/projects/tmp/.git/.dotest-merge/output: No such file or directory
Invalid branchname: branch
^ permalink raw reply
* Why does git-svn dcommit rewrite the log messages?
From: Patrick Doyle @ 2007-08-01 21:19 UTC (permalink / raw)
To: git
I see that it appends text to the log messages with the SVN repository
revision and ID. Does it do that because:
1) That's the _only_ way to keep git & svn in sync
If so, then I guess I'm out of luck. But it seems (to my
inexperienced eye) to make branching impossible in git -- as soon as I
do a "git-svn dcommit", I lose the commit on which my branch was
originally based. Or, am I missing something?
2) That was the simplest way to keep them in sync at the time git-svn
was written and it hasn't bothered anybody enough to go back and fix
it.
If so, I'd be glad to see what I could do to fix it. I would also
appreciate any pointers folks might care to give to get me started.
--wpd
^ permalink raw reply
* Re: Git clone error
From: Johannes Schindelin @ 2007-08-01 21:12 UTC (permalink / raw)
To: Denis Bueno; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <C2D647C0.2B60%denbuen@sandia.gov>
Hi,
On Wed, 1 Aug 2007, Denis Bueno wrote:
> On 08/01/2007 11:17, "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
> wrote:
> > But this is what I would do if I had the problem: I would try to create
> > a state which is as close to the corrupt revision as possible,
> > use a graft to replace the initial commit with that revision, and
> > rewrite the branch. I'd probably start by doing something like this:
> >
> > $ git symbolic-ref HEAD refs/heads/recreate-first && rm .git/index
> > $ git ls-tree -r --name-only <initial-commit> |
> > grep -v "^condor/condor-uninstall.sh$" |
> > xargs git checkout <initial-commit>
> > $ git checkout <second-commit> condor/condor-uninstall.sh
> > [possibly some minor hacking on the latter file to make it work]
> > $ git commit -c <initial-commit>
>
> Wow. `commit' and `checkout' are the only two commands that I have ever
> heard of in that sequence.
>
> How difficult would it be to create a new git repo which is exactly the same
> minus the initial condor-uninstall.sh commit? That is, just to pretend the
> initial import of condor-uninstall.sh never existed, and use the second
> commit of the old repo the first commit of the new, and preserve the rest of
> the history of the entire repo?
That would be even easier. Just graft "nothingness" as parent of the
second commit:
$ git rev-parse <second-commit> >> .git/info/grafts
But of course, you should use filter-branch nevertheless, since you would
have to do the same hack in _every_ repository.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-commit.sh: Permit the --amend message to be given with -m/-c/-C/-F.
From: David Kastrup @ 2007-08-01 20:33 UTC (permalink / raw)
To: git
In-Reply-To: <857iofrnkj.fsf@lola.goethe.zz>
Signed-off-by: David Kastrup <dak@gnu.org>
---
git-commit.sh | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 4290ae2..d7e7028 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -190,7 +190,6 @@ $1"
;;
--a|--am|--ame|--amen|--amend)
amend=t
- log_given=t$log_given
use_commit=HEAD
shift
;;
@@ -298,9 +297,9 @@ esac
case "$log_given" in
tt*)
- die "Only one of -c/-C/-F/--amend can be used." ;;
+ die "Only one of -c/-C/-F can be used." ;;
*tm*|*mt*)
- die "Option -m cannot be combined with -c/-C/-F/--amend." ;;
+ die "Option -m cannot be combined with -c/-C/-F." ;;
esac
case "$#,$also,$only,$amend" in
--
1.5.3.rc2.84.gd0bef-dirty
^ permalink raw reply related
* Re: git-commit --amend -m "..." complains?!?
From: David Kastrup @ 2007-08-01 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5sf3uct.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>> ...
>>> You can do:
>>>
>>> $ git reset HEAD^
>>> $ git commit -m "blah"
>>>
>>> if you do not want to reuse the commit message.
>>
>> You can pretty much _always_ avoid --amend in a similar manner, but
>> why would you? It is convenient.
>
> No need to be upset about what I said. I really do not want to
> change the minor detail this late in the 1.5.3 release cycle, and
> wanted to unblock you by giving an workaround in case you were
> stuck.
Well, there is always
VISUAL='echo "mycommit" >"$1"' git commit --amend
Uh, no wait, it isn't. Different thread.
> It should be a straightforward change to git-commit.sh. Instead of
> "Oops, -m and --amend are incompatible so we will whine" around line
> 300, you can treat --amend somewhat specially by (1) making it first
> not set log_given, which would still keep the combination of
> -m/-c/-C/-F incompatible, (2) when $log_given is false and we are
> amending, honor $use_commit to prime the message.
I actually can't find anything about (2) to be done in the code.
> Then you can keep the current bahaviour for amending starting from
> the existing message, while allowing -m/-c/-C/-F to supply different
> message for the replacing commit.
In a somewhat different vein: it appears strange that -m is treated
completely different from the other commit message specifiers: you can
specify -m multiple times.
I have not changed this in the slightly tested patch posted
separately: while the --amend fix was quite straightforward and
confined (and indeed, not even the documentation appears to warrant
any modification), the m/t mess is something I really don't want to
mess with right now.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Git clone error
From: Denis Bueno @ 2007-08-01 20:22 UTC (permalink / raw)
To: Johannes Schindelin, Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0708011802020.14781@racer.site>
On 08/01/2007 11:17, "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
wrote:
> But this is what I would do if I had the problem: I would try to create
> a state which is as close to the corrupt revision as possible,
> use a graft to replace the initial commit with that revision, and
> rewrite the branch. I'd probably start by doing something like this:
>
> $ git symbolic-ref HEAD refs/heads/recreate-first && rm .git/index
> $ git ls-tree -r --name-only <initial-commit> |
> grep -v "^condor/condor-uninstall.sh$" |
> xargs git checkout <initial-commit>
> $ git checkout <second-commit> condor/condor-uninstall.sh
> [possibly some minor hacking on the latter file to make it work]
> $ git commit -c <initial-commit>
Wow. `commit' and `checkout' are the only two commands that I have ever
heard of in that sequence.
How difficult would it be to create a new git repo which is exactly the same
minus the initial condor-uninstall.sh commit? That is, just to pretend the
initial import of condor-uninstall.sh never existed, and use the second
commit of the old repo the first commit of the new, and preserve the rest of
the history of the entire repo? Or, to remove both condor-uninstall.sh
commits from the history -- deleting that history altogether -- and add it
back as a completely new file?
If I get enough courage, I'll attempt to understand exactly what it is
you're doing in the commands above and try it out on (a copy of) the repo.
My willingness to part with the current history and just reinitialise the
repo with its current contents increases with time, though.
The real problem is that I'm sure I have no idea exactly what the first
version of the file looked like, and how it differed from the next one.
Denis
--
"If we wish to count lines of code, we should not regard them as lines
produced but as lines spent." -- Edsger Dijkstra
^ permalink raw reply
* Re: Interpreting EDITOR/VISUAL environment variables.
From: Junio C Hamano @ 2007-08-01 19:53 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85r6mnrs1z.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Well, I just checked the behavior with "less", "more", "mail" and
> "mailx", quite traditional commands that would not have a reason to
> complicate things by using "system" and quoting instead of exec.
> ...
> It turns out all three contestants still in the race apparently do a).
> If nobody has a sensible idea how to shell-quote generally enough...
> Under Unix, one has the option of using "..." and quoting the three of
> "$\ with \ or using '...' and replacing every contained ' with '\''.
Our scripts and C-level both tend to prefer using '\'' for its
simplicity (this also applies to rare case the user wants to
unquote it by hand). Because it now is all in git-sh-setup, it
should be reasonably straightforward to implement the quoting of
the temporary file name and drop dq around ${EDITOR-VISUAL}.
Please make it so.
^ permalink raw reply
* Re: git-commit --amend -m "..." complains?!?
From: Junio C Hamano @ 2007-08-01 19:52 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85myxbrrdl.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> You can do:
>>
>> $ git reset HEAD^
>> $ git commit -m "blah"
>>
>> if you do not want to reuse the commit message.
>
> You can pretty much _always_ avoid --amend in a similar manner, but
> why would you? It is convenient.
No need to be upset about what I said. I really do not want to
change the minor detail this late in the 1.5.3 release cycle,
and wanted to unblock you by giving an workaround in case you
were stuck.
It should be a straightforward change to git-commit.sh. Instead
of "Oops, -m and --amend are incompatible so we will whine"
around line 300, you can treat --amend somewhat specially by (1)
making it first not set log_given, which would still keep the
combination of -m/-c/-C/-F incompatible, (2) when $log_given is
false and we are amending, honor $use_commit to prime the
message. Then you can keep the current bahaviour for amending
starting from the existing message, while allowing -m/-c/-C/-F
to supply different message for the replacing commit.
^ permalink raw reply
* [ANNOUNCE] Guilt v0.27
From: Josef Sipek @ 2007-08-01 19:36 UTC (permalink / raw)
To: guilt; +Cc: git, linux-kernel, brandon
Guilt v0.27 is available for download (once it mirrors out on kernel.org).
Guilt (Git Quilt) is a series of bash scripts which add a Mercurial
queues-like functionality and interface to git.
Tarballs:
http://www.kernel.org/pub/linux/kernel/people/jsipek/guilt/
Git repo:
git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/guilt.git
Alright, I'm trying to get back to the 2-week release schedule, so here's
v0.27!
There has been a number of changes in those two weeks, Out of the 20
commits, about half of them are bug fixes of all sorts - mostly preventive
(does anyone actually use whitespace in their branch names?).
The major changes include some performance speedups. Little bit thought
(there's more to come!) went into making guilt-push faster, 0.27 is about 8%
faster than 0.26 on push. The other major thing is the infrastructure (which
turned out to be really simple) for hooks. Currently, only one hook is
supported (guilt-delete) but that'll change sooner or later.
And the last major change under the hood: guilt now checks and expects git
1.5.
Other new features:
guilt-series -e to edit the series file by hand
guilt-header -e to edit a patch's header
guilt-refresh --diffstat to include a diffstat in the patch file
As always, patches, and other feedback is welcome.
Josef "Jeff" Sipek.
------------
Changes since v0.26:
Dmitry Monakhov (2):
Fix guilt-import patch naming
Add series editor support
Eric Lesh (4):
Handles slashes in branch names
Makefile: don't install *~ files
guilt-rebase: Make fast-forward work
guilt-header: Add -e option for editing
Josef 'Jeff' Sipek (14):
refresh: Added --diffstat option
init: Be careful with whitespace in branch names
guilt: check git version and bail if version is not supported
guilt: Create infrastructure for guilt hooks
delete: Added delete-patch hook
pop: Check if no patches are applied
guilt: Do not scan entire patch file when not necessary
guilt: git-apply --index can be used to update the index
guilt: Remove unnecessary reading of the status file
push_patch: propagate return code to caller
rebase: warn the user that rebase is experimental
Documentation: document series -e option
header: rewrite option parsing and patch searching
Guilt v0.27
Michael Halcrow (1):
import-commit: Retry with a different patch name if necessary
^ permalink raw reply
* Re: Interpreting EDITOR/VISUAL environment variables.
From: David Kastrup @ 2007-08-01 19:30 UTC (permalink / raw)
To: Yann Dirson; +Cc: Junio C Hamano, git
In-Reply-To: <20070801185042.GB30277@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> On Wed, Aug 01, 2007 at 10:12:13AM -0700, Junio C Hamano wrote:
>> We recently normalized the script callers not to splice at all
>> (the scripts were hand-rolling "the VISUAL or EDITOR or vi" and
>> slightly differently). It obviously has negative (i.e. setting
>> EDITOR to "emacsclient --alternate-editor vi" does not work) as
>> well as positive side (i.e. "/home/dak/My Programs/editor" would
>> work).
>
> And, indeed, --alternate-editor could be supplemented by another
> envvar to be able to work in our situation.
It is already. But if git is pretty much alone in breaking a setup
that is working everywhere else, is having a workaround available
really a good excuse for not doing the right thing?
> Maybe the various emacsen vendors would be willing to integrate such
> a patch ?
Actually, it is a nuisance because nobody remembers this variable. It
is called (looking in the Emacs manual, using the index to find
emacsclient, following a link after two pages to the invocation, going
down two pages again) ALTERNATE_EDITOR. It does not even _mention_
Emacs or emacsclient in its name. The "-a" option is easier to
remember.
So yes, emacsclient has an environment hook making it possible to work
around git's idiosyncratic behavior here. But should it really be
necessary?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-commit --amend -m "..." complains?!?
From: David Kastrup @ 2007-08-01 19:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x8v5g2z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> I get
>>
>> Option -m cannot be combined with -c/-C/-F/--amend.
>>
>> but that makes no sense: of course there is ample reason for providing
>> an amended commit message on the command line. -c, -C and -F indeed
>> all provide an alternative commit message, but --amend doesn't.
>
> The option --amend is about "reusing the original commit message
> and make amending edit on top".
Uh no. From the man page:
--amend
Used to amend the tip of the current branch. Prepare the
tree object you would want to replace the latest commit
as usual (this includes the usual -i/-o and explicit
paths), and the commit log editor is seeded with the
commit message from the tip of the current branch. The
commit you create replaces the current tip -- if it was a
merge, it will have the parents of the current tip as
parents -- so the current top commit is discarded.
It is a rough equivalent for:
$ git reset --soft HEAD^
$ ... do something else to come up with the right tree ...
$ git commit -c ORIG_HEAD
but can be used to amend a merge commit.
The --amend is not, according to the manual page, there to amend the
commit message, but primarily to amend the commit.
If one does not want to amend the message, this is easily done with -C
HEAD. If one wants to amend the message but not by editing, one is
plain out of luck.
-C, -F and -m are all logically exclusive (and -C -e is the same as
-c). But --amend seems completely orthogonal to me with regard to the
commit message: it just has a different seed from the normal commit
message edit. You can override the seed with a normal commit using -c
-C -F and -m. Why not with --amend?
> If you are restarting the message from scratch, --amend does not
> make much sense.
It amends the _commit_. You can edit files, add them, and commit
additional changes. If you are using a dumb terminal (or a system
with nonworking VISUAL over the link in question), you don't _want_ an
editor called up.
> You can do:
>
> $ git reset HEAD^
> $ git commit -m "blah"
>
> if you do not want to reuse the commit message.
You can pretty much _always_ avoid --amend in a similar manner, but
why would you? It is convenient.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: git-diff on touched files: bug or feature?
From: Alexandre Julliard @ 2007-08-01 19:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vvebz3wh3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> Alexandre Julliard <julliard@winehq.org> writes:
>
>> .... For
>> instance in vc-git.el the workfile-unchanged-p function currently has
>> to rehash the file every time to see if it really changed, because we
>> can't afford to refresh the whole project at that point.
>
> Maybe I am missing something. Why can't you "afford to"?
>
> "update-index --refresh" looks at only the files whose cached
> stat information does indicate there might be chanegs. It does
> not rehash already up-to-date ones.
No, but it goes through the tree and stats every single file. On a
large project that can be slow, especially if you don't have enough
RAM to keep it all in cache, so it's not something we can do while the
user is interacting with a file.
--
Alexandre Julliard
julliard@winehq.org
^ 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