* Re: [PATCH] Document git-stash
From: Junio C Hamano @ 2007-07-01 6:48 UTC (permalink / raw)
To: しらいしななこ
Cc: GIT, Johannes Schindelin
In-Reply-To: <200707010533.l615XiH6006728@mi1.bluebottle.com>
Thanks.
^ permalink raw reply
* Re: [PATCH] git-svn: cache max revision in rev_db databases
From: Junio C Hamano @ 2007-07-01 6:49 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <20070701053114.GA1787@muzzle>
Thanks.
^ permalink raw reply
* Re: [PATCH] Document git-stash
From: Jeff King @ 2007-07-01 8:07 UTC (permalink / raw)
To: しらいしななこ
Cc: GIT, Johannes Schindelin, Junio C Hamano
In-Reply-To: <200707010533.l615XiH6006728@mi1.bluebottle.com>
On Sun, Jul 01, 2007 at 02:26:08PM +0900, しらいしななこ wrote:
> This describes the git-stash command.
A few minor language nits follow (Junio, I can provide a patch, but if
you haven't pushed it out, it might be simpler to just --amend). Some
are obviously correct, and some are minor or matters of taste. Feel free
to ignore the latter. :)
> +The modifications stashed away by this command can be listed with
> +`git-stash list`, inspected with `git-stash show`, and restored
> +(potentially on top of a different commit) with `git-stash apply`
> +commands. The default operation when called without options is to
> +save the changes away.
The 'commands' at the end of the first sentence doesn't quite work. It
needs to be either "with the `foo` command" or "with `foo`" (I think the
latter is preferable, since the list structure makes the article sound
awkward).
> +The latest stash you created is stored in `$GIT_DIR/refs/stash`; older
> +stashes are found in the reflog of this refererence and can be named using
s/refererence/reference/
> +the usual reflog syntax (e.g. `stash@{1}` is the stash one previously made,
> +`stash@{2}` is the one before it, `stash@{2.hours.ago}` is also possible).
"the stash one previously made" is a bit ambiguous (they've all been
previously made!). How about "is the most recently created stash"?
> +(no subcommand)::
> +
> + Save your local modifications to a new 'stash', and run `git-reset
> + --hard` to revert them.
For orthogonality's sake, should this be 'git-stash save', aliased to
just 'git-stash'? It would make this heading a little more intuitive,
and the very first paragraph (describing all of the modes) a little more
clear.
I can work up a patch if there's agreement.
> +list::
> +
> + List the stashes that you currently have. Each 'stash' is listed
> + with its name (e.g. `stash@{0}` is the latest stash, `stash@{1} is
> + the one before),
"...the one before, etc.)" is slightly more clear to me.
> the name of the branch that was current when the
> + stash was made, and a short description of the commit the stash was
> + based on.
"the name of the branch that was current when the stash was made" seems
a bit awkward, but it's actually quite accurate.
> + Show the changes recorded in the stash. When no `<stash>` is given,
> + shows the latest one. By default, the command shows diffstat, but
> + you can add `-p` option (i.e. `git stash show -p stash@{2}`) to view
> + it in patch form.
s/shows diffstat/shows the diffstat of the changes/
s/i.e./e.g./
Also, you can use any diff options. So maybe the whole thing would be
better written as (Is there a better term for "original parent" here?):
Show the changes recorded in the stash as a diff between the the
stashed state and its original parent. When no `<stash>` is given,
shows the latest one. By default, the command shows the diffstat, but
it will accept any format known to `git-diff` (e.g., `git-stash show
-p stash@{2}` to view the second most recent stash in patch form).
We refer to "the changes" a lot...maybe it would be better to introduce
and define a term like "stash changes" early on and then use it. But
without that, I'm not sure it's clear that the stash can really be
thought of as a diff (since, after all, git stores states, stashes
included). I guess we talk about that later, but at this point in the
manual I think it's a little confusing.
> +apply [<stash>]::
> +
> + Restores the changes recorded in the stash on top of the current
s/Restores/Restore/ to match the imperative of the other command
descriptions.
> + working tree state. When no `<stash>` is given, applies the latest
> + one. The working directory must match the index. When the changes
> + conflict, you need to resolve them by hand and mark the result with
> + `git add` as usual. When the changes are cleanly merged, your
> + earlier local changes stored in the stash becomes the differences
> + between the index and the working tree (i.e. `git diff`), except
> + that newly created files are registered in the index (i.e. `git diff
> + --cached` is necessary to review the newly added files).
I'm not quite sure I understand what this is saying.
> +clear::
> + Removes all the stashed states.
Maybe a note to indicate that this can lose data? Something like:
...stashed states. Note that those states will then be subject to
pruning, and may be difficult or impossible to recover.
> +When you are in the middle of something, you learn that there are
> +changes that possibly are relevant to what you are doing in the
> +upstream. When your local changes do not conflict with the changes in
> +the upstream, a simple `git pull` will let you move forward.
The first sentence would be more clear if we moved the prepositional
phrase "in the upstream":
When you are in the middle of something, you learn that there are
changes in the upstream that are possibly relevant to what you are
doing.
or even:
When you are in the middle of something, you learn that there are
upstream changes that are possibly relevant to what you are doing.
> ++
> +However, there are cases in which your local changes do conflict with
> +the upstream changes, and `git pull` refuses to overwrite your
> +changes. In such a case, you can first stash your changes away,
> +perform a pull, and then unstash, like this:
I think the "first" in the last sentence is confusing, since we don't
use a "then" in the second step ("perform a pull") to indicate that we
have gone on to the second step.
> +When you are in the middle of something, your boss comes in and
> +demands you to fix something immediately. Traditionally, you would
s/demands you to fix/demands that you fix/
> +make a commit to a temporary branch to store your changes away, and
> +come back to make the emergency fix, like this:
"come back" is pretty vague here. Maybe "return to your original
branch"?
Otherwise, I think the page is very well written, and the examples are
very clear.
-Peff
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Jeff King @ 2007-07-01 8:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vy7i1b6bt.fsf@assigned-by-dhcp.cox.net>
On Sat, Jun 30, 2007 at 12:17:10PM -0700, Junio C Hamano wrote:
> So I am somewhat negative on this, unless there is a way for
> scripts to say "Even though I say 'git foo', I do mean 'git foo'
> not whatever the user has aliased".
I had submitted GIT_NOALIAS=1 patches a while back, but IIRC, the
consensus was that it was a bit too ugly and fragile in concept.
-Peff
^ permalink raw reply
* [PATCH] Add USE_SHARED_LIBGIT flag to build and use libgit.so rather than libgit.a
From: Josh Triplett @ 2007-07-01 8:28 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 5708 bytes --]
Git builds a static libgit.a, and many commands which link to libgit.a,
resulting in many duplicate copies of the code in libgit.a. Add a
USE_SHARED_LIBGIT flag to the Makefile (off by default), which builds and uses
a shared library libgit.so instead.
The existing objects in libgit.a reference the symbols git_version_string and
git_usage_string, defined in git.c, but libgit does not include git.o, making
the library not self-contained, and leading to linking errors when trying to
use a shared library. Move those two symbols to help.c, where the references
from libgit occur.
This change does not install header files, versioned libraries, or anything
else that would support actually using libgit.so from anything other than the
installed git binaries. The built libgit.so exists solely for the benefit of
the installed git binaries that link to it.
Motivated by trying to install Git on a machine for which this makes the
difference between remaining under quota and not.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
---
Makefile | 31 ++++++++++++++++++++++++++-----
git.c | 5 -----
help.c | 5 +++++
3 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/Makefile b/Makefile
index a98e27a..db35b3b 100644
--- a/Makefile
+++ b/Makefile
@@ -124,6 +124,8 @@ all::
# If not set it defaults to the bare 'wish'. If it is set to the empty
# string then NO_TCLTK will be forced (this is used by configure script).
#
+# Define USE_SHARED_LIBGIT to create and use a shared library libgit.so rather
+# than a static library libgit.a.
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -146,6 +148,7 @@ STRIP ?= strip
prefix = $(HOME)
bindir = $(prefix)/bin
gitexecdir = $(bindir)
+libdir = $(prefix)/lib
sharedir = $(prefix)/share
template_dir = $(sharedir)/git-core/templates
ifeq ($(prefix),/usr)
@@ -290,7 +293,13 @@ endif
export PERL_PATH
+ifdef USE_SHARED_LIBGIT
+LIB_FILE=libgit.so
+LIBGIT=-L. -lgit
+else
LIB_FILE=libgit.a
+LIBGIT=$(LIB_FILE)
+endif
XDIFF_LIB=xdiff/lib.a
LIB_H = \
@@ -704,6 +713,7 @@ ETC_GITCONFIG_SQ = $(subst ','\'',$(ETC_GITCONFIG))
DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
+libdir_SQ = $(subst ','\'',$(libdir))
template_dir_SQ = $(subst ','\'',$(template_dir))
prefix_SQ = $(subst ','\'',$(prefix))
@@ -712,7 +722,7 @@ PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
PYTHON_PATH_SQ = $(subst ','\'',$(PYTHON_PATH))
TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH))
-LIBS = $(GITLIBS) $(EXTLIBS)
+LIBS = $(LIBGIT) $(XDIFF_LIB) $(EXTLIBS)
BASIC_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' \
-DETC_GITCONFIG='"$(ETC_GITCONFIG_SQ)"' $(COMPAT_CFLAGS)
@@ -721,6 +731,10 @@ LIB_OBJS += $(COMPAT_OBJS)
ALL_CFLAGS += $(BASIC_CFLAGS)
ALL_LDFLAGS += $(BASIC_LDFLAGS)
+ifdef USE_SHARED_LIBGIT
+ALL_CFLAGS += -fpic
+endif
+
export TAR INSTALL DESTDIR SHELL_PATH
@@ -747,16 +761,15 @@ gitk-wish: gitk GIT-GUI-VARS
chmod +x $@+ && \
mv -f $@+ $@
-git.o: git.c common-cmds.h GIT-CFLAGS
- $(QUIET_CC)$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
- $(ALL_CFLAGS) -c $(filter %.c,$^)
+git.o: common-cmds.h
git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(ALL_CFLAGS) -o $@ $(filter %.c,$^) git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-help.o: common-cmds.h
+help.o: help.c common-cmds.h GIT-CFLAGS
+ $(QUIET_CC)$(CC) -o $@ -c $(ALL_CFLAGS) -DGIT_VERSION='"$(GIT_VERSION)"' $<
git-merge-subtree$X: git-merge-recursive$X
$(QUIET_BUILT_IN)rm -f $@ && ln git-merge-recursive$X $@
@@ -908,7 +921,11 @@ $(patsubst git-%$X,%.o,$(PROGRAMS)): $(LIB_H) $(wildcard */*.h)
$(DIFF_OBJS): diffcore.h
$(LIB_FILE): $(LIB_OBJS)
+ifdef USE_SHARED_LIBGIT
+ $(QUIET_LINK)$(CC) -shared -o $@ $(LIB_OBJS)
+else
$(QUIET_AR)rm -f $@ && $(AR) rcs $@ $(LIB_OBJS)
+endif
XDIFF_OBJS=xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
xdiff/xmerge.o
@@ -996,6 +1013,10 @@ install: all
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) $(ALL_PROGRAMS) '$(DESTDIR_SQ)$(gitexecdir_SQ)'
$(INSTALL) git$X '$(DESTDIR_SQ)$(bindir_SQ)'
+ifdef USE_SHARED_LIBGIT
+ $(INSTALL) -d -m755 $(DESTDIR_SQ)$(libdir_SQ)
+ $(INSTALL) $(LIB_FILE) $(DESTDIR_SQ)$(libdir_SQ)
+endif
$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
$(MAKE) -C perl prefix='$(prefix_SQ)' install
ifndef NO_TCLTK
diff --git a/git.c b/git.c
index 29b55a1..1e24903 100644
--- a/git.c
+++ b/git.c
@@ -3,9 +3,6 @@
#include "cache.h"
#include "quote.h"
-const char git_usage_string[] =
- "git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate] [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]";
-
static void prepend_to_path(const char *dir, int len)
{
const char *old_path = getenv("PATH");
@@ -206,8 +203,6 @@ static int handle_alias(int *argcp, const char ***argv)
return ret;
}
-const char git_version_string[] = GIT_VERSION;
-
#define RUN_SETUP (1<<0)
#define USE_PAGER (1<<1)
/*
diff --git a/help.c b/help.c
index 1cd33ec..3f3ceeb 100644
--- a/help.c
+++ b/help.c
@@ -9,6 +9,11 @@
#include "common-cmds.h"
#include <sys/ioctl.h>
+const char git_usage_string[] =
+ "git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate] [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [ARGS]";
+
+const char git_version_string[] = GIT_VERSION;
+
/* most GUI terminals set COLUMNS (although some don't export it) */
static int term_columns(void)
{
--
1.5.2.2
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply related
* Re: [PATCH] Document git-stash
From: Junio C Hamano @ 2007-07-01 8:38 UTC (permalink / raw)
To: Jeff King
Cc: しらいしななこ, GIT,
Johannes Schindelin
In-Reply-To: <20070701080757.GA6093@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Jul 01, 2007 at 02:26:08PM +0900, しらいしななこ wrote:
>
>> This describes the git-stash command.
>
> A few minor language nits follow (Junio, I can provide a patch, but if
> you haven't pushed it out, it might be simpler to just --amend).
Although I sent out a Thanks already, I haven't even applied it
yet. Language nits are very much appreciated in the
Documentation area. Will take a look but it is getting late
here in California, so it has to wait for about 8 to 10 hours.
^ permalink raw reply
* Re: [PATCH] Document git-stash
From: しらいしななこ @ 2007-07-01 9:06 UTC (permalink / raw)
To: Jeff King; +Cc: GIT, Johannes Schindelin, Junio C Hamano
In-Reply-To: <20070701080757.GA6093@coredump.intra.peff.net>
Hi,
Quoting Jeff King <peff@peff.net>:
>> +(no subcommand)::
>> +
>> + Save your local modifications to a new 'stash', and run `git-reset
>> + --hard` to revert them.
>
> For orthogonality's sake, should this be 'git-stash save', aliased to
> just 'git-stash'? It would make this heading a little more intuitive,
> and the very first paragraph (describing all of the modes) a little more
> clear.
Johannes earlier asked for the same thing, and I think it is a good change.
>> +apply [<stash>]::
>> +
>> + Restores the changes recorded in the stash on top of the current
>
> s/Restores/Restore/ to match the imperative of the other command
> descriptions.
>
>> + working tree state. When no `<stash>` is given, applies the latest
>> + one. The working directory must match the index. When the changes
>> + conflict, you need to resolve them by hand and mark the result with
>> + `git add` as usual. When the changes are cleanly merged, your
>> + earlier local changes stored in the stash becomes the differences
>> + between the index and the working tree (i.e. `git diff`), except
>> + that newly created files are registered in the index (i.e. `git diff
>> + --cached` is necessary to review the newly added files).
>
> I'm not quite sure I understand what this is saying.
I don't understand myself anymore, either (^_^;) I just tried to follow
Jnio's earlier suggestion in his message. He said this.
| The three-way merge is done correctly here, and I would imagine
| the users would feel the UI quite natural _if_ this merge
| conflicts. "git diff" would show only the conflicted paths
| (because the updates coming from the old working tree is placed
| in the index for cleanly merged paths), editing a conflicted
| file and "git add $that_path" would resolve. That's exactly the
| same workflow for a conflicted merge.
|
| However, I think it is a bit counterintuitive to update the
| working tree change to the index if the merge did not conflict.
| It might be better to run an equivalent of "git reset", so that
| after "git save restore", the user can say "git diff" (not "git
| diff HEAD") to view the local changes. Perhaps...
>> +clear::
>> + Removes all the stashed states.
>
> Maybe a note to indicate that this can lose data? Something like:
>
> ...stashed states. Note that those states will then be subject to
> pruning, and may be difficult or impossible to recover.
I see. When I wrote it, I thought that saying "removes" was enough. It
seemed obvious to me that you would lose it when you remove it.
Thanks for fixing my language. I am not very good at writing English,
but you probably have already found it out (^_^;).
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
----------------------------------------------------------------------
Finally - A spam blocker that actually works.
http://www.bluebottle.com
^ permalink raw reply
* Re: [PATCH] Document git-stash
From: Jeff King @ 2007-07-01 9:19 UTC (permalink / raw)
To: しらいしななこ
Cc: GIT, Johannes Schindelin, Junio C Hamano
In-Reply-To: <200707010910.l619A23c027837@mi0.bluebottle.com>
On Sun, Jul 01, 2007 at 06:06:29PM +0900, しらいしななこ wrote:
> I don't understand myself anymore, either (^_^;) I just tried to follow
> Jnio's earlier suggestion in his message. He said this.
OK, we will wait for Junio to clarify tomorrow. :)
> >> + Removes all the stashed states.
> >
> > Maybe a note to indicate that this can lose data? Something like:
> >
> > ...stashed states. Note that those states will then be subject to
> > pruning, and may be difficult or impossible to recover.
>
> I see. When I wrote it, I thought that saying "removes" was enough. It
> seemed obvious to me that you would lose it when you remove it.
It is "enough" in the sense that the meaning is clear, but in general it
is very hard to convince git to forget things, and I think that is a
feature. There are so few commands in git where you can "lose" data that
I think it is worth marking them with a big X.
Really, I don't see the need to use 'clear' in general. The reflog works
as a stack, so old stashes will get out of the "top 10" eventually
anyway. In the long run, they will be cleaned up by "git reflog expire"
(or indirectly by "git gc").
> Thanks for fixing my language. I am not very good at writing English,
> but you probably have already found it out (^_^;).
Quite the contrary. If it had been very badly written, it would have
just been easier to rewrite it than to point out the few mistakes. :)
-Peff
^ permalink raw reply
* Re: most commonly used git commands?
From: Jan Hudec @ 2007-07-01 9:16 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20070630223504.GB2703@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]
On Sun, Jul 01, 2007 at 00:35:04 +0200, Alex Riesen wrote:
> Johannes Schindelin, Sat, Jun 30, 2007 16:31:48 +0200:
> > On Sat, 30 Jun 2007, Alex Riesen wrote:
> > > Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:
> > > > > No. It was meant as Alex said it. Windows (MinGW) doesn't understand
> > > > > "chmod a+x blub".
> > > >
> > > > Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to
> > > > begin with.
> > > >
> > >
> > > But it is necessary on Windows (Cygwin):
> >
> > I thought that on Cygwin, filemode=1? I mean, Cygwin _never_ had problems
> > with chmod under my fingers.
> >
>
> Try doing stat(2) on file.txt which contains "#!/bin/sh" in its first
> line and for which you have issued a chmod yet. Like a new file, or
> like every file in a git-tracked directory after you did a fresh
> checkout. Cygwin actually opens the files when doing stat(2), looks
> inside and tries to guess if they are executable.
>
> You should have said: "Cygwin _never_ had problems with chmod because
> it cannot and didn't make it work". It is not just chmod, the other
> side, stat, matters as well.
I always had the impression, that cygwin actually *implements* chmod and does
so using windows ACLs. And in ACL windows *do* support executable bit (I
copied some DLL with cygwin copy and it was NOT executable then). Of course
this only works on filesystems (NTFS, NTFS exported over CIFS) that support
ACLs. On FAT it might be doing something like you describe. Though it is
mostly irrelevant for git, because git does not work on FAT (Cygwin only
supports posix rename on NTFS).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Johannes Schindelin @ 2007-07-01 12:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Yann Dirson, Git Mailing List, Carlos Rica
In-Reply-To: <7vsl8894tc.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 30 Jun 2007, Junio C Hamano wrote:
> Your patch _closes the door_ for us to implement overriding aliases
> later if we wanted to; we would need to go back to the scripts and say
> "git --no-alias xyzzy" again.
No, it does not.
Carlos had a cute idea on IRC, but was too shy to mention it here. There
is a central place for Git's shell script, git-sh-setup. Defining an
environment variable there, GIT_NO_ALIAS, and honouring that in the Git
wrapper. Something similar is possible in Git.pm for perl scripts.
Note: I am opposed to overriding default parameters via alias. I am only
stating that it is still possible.
I am in favour of Linus' patch. Here's why: quite some times, I have been
asked (at a very late stage) "What still confuses me: what is the
difference between git-xyz and git xyz?" It _is_ confusing for beginners,
even if it is easy to explain.
Ciao,
Dscho
^ permalink raw reply
* Re: [Qgit RFC] commit --amend
From: Jan Hudec @ 2007-07-01 12:26 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550706102245p27aea579w65ee96161630a624@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1372 bytes --]
On Mon, Jun 11, 2007 at 07:45:51 +0200, Marco Costalba wrote:
> On 6/11/07, Jan Hudec <bulb@ucw.cz> wrote:
> >
> >I think I mostly understood it now. Thank you.
> >
>
> Anyhow I think this could be useful to you:
>
> /*
> getAllRefSha() returns the list of sha of a given
> type, where type is a mask of Git::RefType flags
> see src/git.h.
> In this case we want the sha of the current branch
> */
> QStringList revs = getAllRefSha(CUR_BRANCH);
>
> if (!revs.isEmpty()) {
>
> // all the sha info is stored in this QGit::Rev
> // class defined in src/common.h
> const Rev* r = revLookup(revs.first());
>
> // short log (title) is
> r->shortLog();
>
> // message body is
> r->longLog();
>
> // etc....
> }
Thanks.
I got stuck at git-commit --amend -F not working (because it's explicitely
forbidden), so I have to reimplement all of the commit stuff with plumbing
commands. I am in the middle of rewriting it currently. Unfortunately the
plumbing is a little too low-level.
However, I am currently not sure how to handle errors. If the current commit
fails, it will show a message box with it's output, but I can't see where it
is generated. It seems it's somewhere inside MyProcess, so I don't have to do
anything special though, right?
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* t7004-tag.sh fails (old gpg?)
From: Sven Verdoolaege @ 2007-07-01 12:49 UTC (permalink / raw)
To: Carlos Rica; +Cc: git
t7004-tag.sh fails for me:
* expecting success:
git-tag -s -m "A signed tag message" signed-tag &&
get_tag_msg signed-tag >actual &&
git-diff expect actual
gpg: Warning: using insecure memory!
gpg: [don't know]: invalid packet (ctb=00)
gpg: read_keyblock: read error: invalid packet
gpg: enum_keyblocks failed: invalid keyring
gpg: skipped `C O Mitter <committer@example.com>': invalid keyring
gpg: signing failed: invalid keyring
failed to sign the tag with GPG.
* FAIL 49: creating a signed tag with -m message should succeed
git-tag -s -m "A signed tag message" signed-tag &&
get_tag_msg signed-tag >actual &&
git-diff expect actual
I see that you alread check for presence of gpg, but maybe
you should also check that it is recent enough.
This is the version I have:
bash-3.00$ gpg --version
gpg (GnuPG) 1.0.6
Copyright (C) 2001 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
Home: ~/.gnupg
Supported algorithms:
Cipher: 3DES, CAST5, BLOWFISH, RIJNDAEL, RIJNDAEL192, RIJNDAEL256, TWOFISH
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
Hash: MD5, SHA1, RIPEMD160
skimo
^ permalink raw reply
* Re: [PATCH] t7004: ship trustdb to avoid gpg warnings
From: Carlos Rica @ 2007-07-01 12:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v1wfsak92.fsf@assigned-by-dhcp.cox.net>
We finally supplied every file generated by gpg. I talked a lot with
Johannes about what files could be safely threw away and I even ask
that in the #gnupg channel to remove this file. I hadn't seen those
messages.
The patch worked fine for me. Indeed, I realized that the file is
equal to that I shipped in the first version of the tests.
Thank you Junio for your effort on this.
2007/7/1, Junio C Hamano <gitster@pobox.com>:
> This avoids warning messages from gpg while verifying the tags; without it,
> the program complains that the key is not certified with a trusted signature.
>
> ---
> t/t7004/trustdb.gpg | Bin 0 -> 1280 bytes
> 1 files changed, 0 insertions(+), 0 deletions(-)
> create mode 100644 t/t7004/trustdb.gpg
>
> diff --git a/t/t7004/trustdb.gpg b/t/t7004/trustdb.gpg
> new file mode 100644
> index 0000000000000000000000000000000000000000..abace962b8bf84be688a6f27e4ebd0ee7052f210
> GIT binary patch
> literal 1280
> zcmZQfFGy!*W@Ke#U|?`dKkWykumMIcY@%4iM%7^n6rj+M4;MLzzlOX&pwTnxkD-}P
> zc^HbXN0fL!SIq1?>env3?W^3`d(OOU5YNaX{KU(k^<0;M@87ONv)_6ZxD={-=<kYO
> M2Ud3=2BC}r0AuhNr2qf`
>
> literal 0
> HcmV?d00001
>
> --
> 1.5.2
>
>
>
^ permalink raw reply
* Re: [PATCH] git-svn: allow dcommit to retain local merge information
From: Joakim Tjernlund @ 2007-07-01 13:09 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <20070620065600.GA25010@muzzle>
> > Sidenote:
> > Doing this
> > git-svn init -t tags -T trunk -b branches file:///usr/local/src/tst-git-svn/svn-uboot-repo
> > git-svn fetch --quiet
> > makes git svn fetch stop for rather long periods in do_update:
> > Found possible branch point: file:///usr/local/src/tst-git-svn/svn-uboot-repo/trunk => file:///usr/local/src/tst-git-svn/svn-uboot-repo/tags/snap-uboot-1.1.4, 2
> > Found branch parent: (tags/snap-uboot-1.1.4) 81eef14963597cc99ba375f52e6d0b3bc09e25f8
> > Following parent with do_update
> > Successfully followed parent
> >
> > Is it possible to speed up do_update?
>
> Use a do_switch()-enabled SVN to avoid do_update(). do_update will
> redownload everything. I have patched 1.4.3 debian packages with source
> and a diff here: http://git-svn.bogomips.org/svn. SVN 1.4.4 claims to
> have fixed the bindings, but 1.4.3 claimed the same thing, too...
> Confirmation of it working in SVN 1.4.4 would be nice.
I upgraded to svn 1.4.4 and it seemed to work OK, but then i noticed
some problems,
git clone -t tags -T trunk -b branches svn+ssh://devsrv/svn/TM-uboot
failed(error msg was something with "Malformed data ...")
I decided to go back to 1.4.3 with you patch, switch-editor-perl.diff
applied. Now the error was gone, but the clone operation did use
do_update insted of do_switch. Did I miss someting?
Jocke
^ permalink raw reply
* [PATCH] cvstrack: work on imported cvs and other git branches
From: Steffen Prohaska @ 2007-07-01 13:16 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska
The idea is to import a cvs repository using git cvsimport; build
a perfect history in git by cherry picking commits that are only
in cvs but not in git; and export only summaries back to cvs. Cvs
imports are organized on a separate git branch. git is used for
merging. The differences can be sent back to cvs as a squashed
commit together with a shortlog. Sent git commits are noted in
the cvs commit message and will be ignored in subsequent cvs
imports.
To get the idea you can run t/t9250-git-cvstrack.sh and explore
the git repository created in t/trash/gitwork.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
.gitignore | 4 +
Documentation/git-cvstrack.txt | 128 +++++++++++++++++++
Makefile | 1 +
git-cvstrack-fetch.sh | 52 ++++++++
git-cvstrack-init.sh | 20 +++
git-cvstrack-pull.sh | 10 ++
git-cvstrack-pushcvs.sh | 60 +++++++++
t/t9250-git-cvstrack.sh | 270 ++++++++++++++++++++++++++++++++++++++++
8 files changed, 545 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-cvstrack.txt
create mode 100755 git-cvstrack-fetch.sh
create mode 100755 git-cvstrack-init.sh
create mode 100755 git-cvstrack-pull.sh
create mode 100755 git-cvstrack-pushcvs.sh
create mode 100755 t/t9250-git-cvstrack.sh
I am using these scripts successfully for some time.
What do you think?
- Is the general concept useful?
- Comments on the coding style?
- Is using branches and tags to maintain the state a bad idea?
diff --git a/.gitignore b/.gitignore
index e8b060c..9924d07 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,6 +30,10 @@ git-count-objects
git-cvsexportcommit
git-cvsimport
git-cvsserver
+git-cvstrack-fetch
+git-cvstrack-init
+git-cvstrack-pull
+git-cvstrack-pushcvs
git-daemon
git-diff
git-diff-files
diff --git a/Documentation/git-cvstrack.txt b/Documentation/git-cvstrack.txt
new file mode 100644
index 0000000..10f2de1
--- /dev/null
+++ b/Documentation/git-cvstrack.txt
@@ -0,0 +1,128 @@
+git-cvstrack(1)
+=============
+
+NAME
+----
+git-cvstrack - work on imported cvs and other git branches
+
+SYNOPSIS
+--------
+'git-cvstrack-init' <cvsbranch>
+'git-cvstrack-fetch' [<cvsbranch>]
+'git-cvstrack-pull' <cvsbranch>
+'git-cvstrack-pushcvs' <cvsbranch> <cvsworkingcopy>
+
+DESCRIPTION
+-----------
+git-cvstrack tracks cvs branches imported by git-cvsimport and provides a
+mechanism to sent changes from git back to cvs squashed into a single commit.
+
+cvstrack can be used to start building a sane git history that integrates an
+exiting, active cvs and work done in git. Eventually the cvs repository can
+be closed and git will serve as the only SCM. At that time you already have a
+sane history from the point you started to use cvstrack.
+
+The basic workflow is as follows.
+
+1) Initial import from cvs and clone a tracking repository
+
+ git cvsimport -d /path/to/cvsroot -i -k -u -C cvsimported.git -o cvshead
+ git clone cvsimported.git cvstracker
+
+2) Initialize tracking
+
+ cd cvstracker
+ git checkout master
+ git cvstrack-init cvshead
+ cd ..
+
+3) Incrementally import work from cvs
+
+ git cvsimport -d /path/to/cvsroot -i -k -u -C cvsimported.git -o cvshead module
+
+4) Incrementally fetch to cvstracker
+
+ cd cvstracker
+ git checkout master
+ git cvstrack-pull cvshead # or git-cvstrack-fetch to avoid merge
+ cd ..
+
+5) Work on a git branch (you may want to clone cvstracker first to separate
+ working branches from cvstrack)
+
+ cd cvstracker
+ git checkout -b topic master
+ # edit files
+ git commit
+ cd ..
+
+6) Send changes to cvs
+
+ cvs -d /path/to/cvsroot checkout -d cvsworkingcopy module # or cvs update
+ cd cvstracker
+ git checkout master
+ git merge topic
+ git cvstrack-pushcvs cvshead ../cvsworkingcopy
+ # follow instructions from cvstrack-pushcvs here:
+ # edit message and cvs commit
+
+You can do (3)-(6) in any order. Note however, it is recommended to merge topic
+branches only if you plan to send them to cvs right away. It is a bad idea to
+let master and cvs diverge too much.
+
+Technical Details
+-----------------
+git-cvstrack maintains its state using two git branches and one tag per cvs
+branch. Commits imported by git-cvsimport are on origin/cvsbranch. From there
+commits are cherry-picked to cvspending/cvsbranch. Only commits that did not
+originate from git are cherry-picked. Commits originating from git are detected
+by examining if the cvs commit message contains 'git-cvstrack-revs:'. The tag
+cvspicked/cvsbranch marks the latest commit that was cherry picked.
+
+Because commits originating from git are filtered from the imported cvs branch
+the git history only contains 'real' changes. The git history is in a sense a
+perfect git history. Changes from cvs are handled as just another topic branch.
+Merges sent to cvs are filtered and will not enter the git side of the history
+twice.
+
+All the merging machinery of git can be used to merge git and cvs topic
+branches. cvs is treated as a second level citizen. Changes done in git are
+only sent back as a squashed commit. This is a good compromise because cvs
+can't handle nonlinear history anyway.
+
+Advanced Topics
+---------------
+You can track several cvsbranches by running git cvstrack-init multiple times.
+
+If a new cvs branch X is created after you started tracking with cvstrack
+you'll need to rebase cvstrack/X created by git cvstrack-init X to the parent
+of an existing cvstrack/... branch that corresponds to the cherry picked commit
+of the root point of the cvs topic branch.
+
+You may need to fix the parent commit of a cvs topic branch. git-cvsimport
+chooses the wrong parent for cvs topic branches if changes were commited to the
+head between the creation of the cvs branch and the first commit to it.
+See the following threads on the mailing list:
+
+http://marc.info/?l=git&m=118260312708709
+http://marc.info/?l=git&m=118262688431613
+
+OPTIONS
+-------
+<cvsbranch>::
+ Branch imported from cvs by git-cvsimport.
+
+<cvsworkingcopy>::
+ CVS working copy that matches <cvsbranch>.
+
+Author
+------
+Written by Steffen Prohaska <prohaska@zib.de>
+
+Documentation
+-------------
+Documentation by Steffen Prohaska <prohaska@zib.de>
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index 5d60dc8..8026e38 100644
--- a/Makefile
+++ b/Makefile
@@ -212,6 +212,7 @@ SCRIPT_SH = \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
git-lost-found.sh git-quiltimport.sh git-submodule.sh \
+ git-cvstrack-fetch.sh git-cvstrack-init.sh git-cvstrack-pull.sh git-cvstrack-pushcvs.sh \
git-filter-branch.sh
SCRIPT_PERL = \
diff --git a/git-cvstrack-fetch.sh b/git-cvstrack-fetch.sh
new file mode 100755
index 0000000..d4aa13b
--- /dev/null
+++ b/git-cvstrack-fetch.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+
+# need exactly one argument
+USAGE="[<branch>]"
+. git-sh-setup
+[[ $# -le 1 ]] || usage
+
+if [[ $# -eq 1 ]]
+then
+ branch=$1
+# which must be a remote branch
+ git branch -r | grep -q "/$branch\$" || die "Error: $branch must be a remote branch."
+
+# safety nets
+ git tag -l "cvspicked/$branch" >/dev/null || die "Error: missing tag cvspicked/$branch."
+ git branch | grep -q "cvspending/$branch" || die "Error: missing branch cvspending/$branch."
+
+ branches=$branch
+else
+ branches=$(git branch -l | cut -b 3- | grep ^cvspending/ | cut -b 12-)
+fi
+
+# fetch and cherry pick
+git fetch || exit 1
+
+origbranch=$(git branch | grep '^\*' | cut -b3-)
+
+for branch in $branches ; do
+ echo "Fetching new cvs commits to cvspending/$branch"
+ git branch -r | grep -q "/$branch\$" || { "Error: missing remote branch $branch, skipping ..." ; continue ; }
+ git tag -l "cvspicked/$branch" >/dev/null || { "Error: missing tag cvspicked/$branch, skipping ..." ; continue ; }
+
+ git checkout "cvspending/$branch" || exit 1
+#for r in $(git rev-list --pretty=oneline --reverse cvspicked/$branch..origin/$branch | grep -v '\[from git\]' | cut -d ' ' -f 1) ; do
+ for r in $(git rev-list --reverse "cvspicked/$branch..origin/$branch") ; do
+ git cat-file -p "$r" | egrep -q '^\[from git\]' && { echo "skipping $r" ; continue ; }
+ git cat-file -p "$r" | egrep -q '^git-cvstrack-revs: [0-9a-f]{40}\.\.[0-9a-f]{40}' && { echo "skipping $r" ; continue ; }
+ echo "picking $r"
+ output="$(git cherry-pick "$r")" ||
+ {
+ ret=$?
+ echo "$output"
+ echo "$output" | grep -q "CONFLICT" && die "Error: git cherry-pick detected CONFLICT and exited with $ret."
+ echo "Warning: git cherry-pick exited with $ret but didn't report a severe problem, continuing."
+ }
+ done
+ rm -f .msg
+ git tag -f -m "cherry-picked cvs $branch up to here" "cvspicked/$branch" "origin/$branch"
+done
+
+git checkout "$origbranch"
diff --git a/git-cvstrack-init.sh b/git-cvstrack-init.sh
new file mode 100755
index 0000000..cb60fe9
--- /dev/null
+++ b/git-cvstrack-init.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+# need exactly one argument
+USAGE="<branch>"
+. git-sh-setup
+[[ $# == 1 ]] || usage
+
+branch=$1
+
+# which must be a remote branch
+git branch -r | grep -q "/$branch\$" || die "Error: $branch must be a remote branch"
+
+# safety nets
+git tag -l "cvspicked/$branch" | grep -q "cvspicked/$branch" && die "Error: tag cvspicked/$branch already exists"
+git branch | grep -q "cvspending/$branch" && die "Error: branch cvspending/$branch already exists"
+
+
+# setup tracking
+git tag -f -m "cherry-picked cvs $branch up to here" cvspicked/$branch origin/$branch || exit 1
+git branch --no-track "cvspending/$branch" "origin/$branch" || exit 1
diff --git a/git-cvstrack-pull.sh b/git-cvstrack-pull.sh
new file mode 100755
index 0000000..3fd61c3
--- /dev/null
+++ b/git-cvstrack-pull.sh
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+USAGE="<branch>"
+. git-sh-setup
+[[ $# == 1 ]] || usage
+
+. git-cvstrack-fetch
+
+echo "Pulling new cvs commits"
+git pull . "cvspending/$branch"
diff --git a/git-cvstrack-pushcvs.sh b/git-cvstrack-pushcvs.sh
new file mode 100755
index 0000000..85e85fa
--- /dev/null
+++ b/git-cvstrack-pushcvs.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+# need exactly two arguments
+USAGE="<branch> <cvsworkingcopy>"
+. git-sh-setup
+[[ $# == 2 ]] || usage
+
+branch=$1
+cvswc=$2
+
+# branch must be a remote branch
+git branch -r | grep -q "/$branch\$" || die "Error: $branch must be a remote branch."
+
+[[ -d "$cvswc/CVS" ]] || die "Error: $cvswc must be a CVS working copy"
+
+# safety nets
+git tag -l "cvspicked/$branch" >/dev/null || die "Error: missing tag cvspicked/$branch."
+git branch | grep -q "cvspending/$branch" || die "Error: missing branch cvspending/$branch."
+
+# User should have fetched and pulled.
+# However, we don't require a fetch but enforce at least a local pull.
+origbranch="$(git branch | grep '^\*' | cut -b3-)"
+[[ $(git rev-parse "$origbranch") != $(git rev-parse "cvspending/$branch") ]] || { echo "Nothing to do. $origbranch and cvspending/$branch are identical." ; git checkout "$origbranch"; exit 0 ; }
+
+origbranchhead="$(git rev-parse HEAD)"
+
+git pull --no-commit . "cvspending/$branch" || die "local pull failed"
+git commit -m "Merge cvspending/$branch into $origbranch (preparing cvstrack-pushcvs)"
+git checkout "cvspending/$branch" || die "checkout cvspending/$branch failed"
+from=$(git rev-parse HEAD)
+git pull . "$origbranch" || die "local pull $origbranch failed"
+to=$(git rev-parse HEAD)
+
+echo "applying changes to cvs working copy $cvswc"
+cvsexportmsg="$( export GIT_DIR=$(cd "$GIT_DIR" ; pwd) ; cd "$cvswc" ; git cvsexportcommit -p -v -P "$from" "cvspending/$branch" )" \
+ || \
+ {
+ echo "git cvsexportcommit failed: rolling back changes to git repository."
+ git reset --hard "$from"
+ git checkout "$origbranch"
+ git reset --hard "$origbranchhead"
+ die "Error: git cvsexporcommit failed. Please carefully check message above."
+ }
+commitcmd=$(echo "$cvsexportmsg" | egrep '^ *cvs commit -F .msg')
+
+echo "YOUR SUMMARY HERE" >$cvswc/.msg
+echo "" >>$cvswc/.msg
+git log $from..$to | git shortlog >>$cvswc/.msg
+echo "" >>$cvswc/.msg
+echo "git-cvstrack-revs: $from..$to" >>$cvswc/.msg
+
+git checkout "$origbranch"
+
+echo ""
+echo "*Did not commit changes to CVS.*"
+echo "You need to edit the message in"
+echo " $cvswc/.msg"
+echo "and commit with"
+echo " (cd $cvswc ; $commitcmd)"
+echo ""
diff --git a/t/t9250-git-cvstrack.sh b/t/t9250-git-cvstrack.sh
new file mode 100755
index 0000000..274ed1d
--- /dev/null
+++ b/t/t9250-git-cvstrack.sh
@@ -0,0 +1,270 @@
+#!/bin/sh
+
+test_description='CVS export comit. '
+
+. ./test-lib.sh
+
+cvs >/dev/null 2>&1
+if test $? -ne 1
+then
+ test_expect_success 'skipping git-cvstrack tests, cvs not found' :
+ test_done
+ exit
+fi
+
+CVSROOT=$(pwd)/cvsroot
+CVSWORK=$(pwd)/cvswork
+export CVSROOT CVSWORK
+
+cvspscache="$HOME/.cvsps/$(echo $CVSROOT | sed -e 's%/%#%g')#src"
+rm -f $cvspscache
+
+rm -rf "$CVSROOT" "$CVSWORK"
+mkdir "$CVSROOT" &&
+cvs init &&
+mkdir "$CVSROOT/src"
+cvs -Q co -d "$CVSWORK" src &&
+rm -rf .git ||
+exit 1
+
+test_expect_success \
+ 'initial cvs commit' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 1" >>a.txt &&
+ echo "b: line 1" >>b.txt &&
+ cvs add a.txt b.txt &&
+ cvs commit -m "cvs commit 1"
+ )'
+
+# fighting cvsps' fuzz
+sleep 2
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C cvstracker -o cvshead src'
+
+test_expect_success \
+ 'cloning git and initializing cvstrack' \
+ 'git-clone cvstracker gitwork &&
+ ( cd gitwork &&
+ git-cvstrack-init cvshead
+ )'
+
+test_expect_success \
+ 'second initialization should fail' \
+ '( cd gitwork &&
+ ! git-cvstrack-init cvshead
+ )'
+
+test_expect_success \
+ 'initialization of non-existing branch should fail' \
+ '( cd gitwork &&
+ ! git-cvstrack-init wrong-name
+ )'
+
+test_expect_success \
+ 'cvs commit 2' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 2" >>a.txt &&
+ echo "b: line 2" >>b.txt &&
+ cvs commit -m "cvs commit 2"
+ )'
+
+# fighting cvsps' fuzz
+sleep 2
+
+test_expect_success \
+ 'cvs commit 3' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 3" >>a.txt &&
+ echo "b: line 3" >>b.txt &&
+ cvs commit -m "cvs commit 3"
+ )'
+
+# fighting cvsps' fuzz
+sleep 2
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C cvstracker -o cvshead src'
+
+test_expect_success \
+ 'commiting to git' \
+ '( cd gitwork &&
+ git-checkout master &&
+ echo "a: line 3 from git" >>a.txt &&
+ git-add a.txt &&
+ git-commit -m "git commit 1" &&
+ echo "c: line 1" >>c.txt &&
+ git-add c.txt &&
+ git-commit -a -m "git commit 2" &&
+ rm b.txt &&
+ git-rm b.txt &&
+ git-commit -a -m "git commit 3"
+ )'
+
+test_expect_success \
+ 'tracking cvs commits 2-3' \
+ '( cd gitwork &&
+ git-cvstrack-fetch cvshead
+ )'
+
+test_expect_success \
+ 'cvs commit 4' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 4" >>a.txt &&
+ echo "b: line 4" >>b.txt &&
+ cvs commit -m "cvs commit 4"
+ )'
+
+# fighting cvsps' fuzz
+sleep 2
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C cvstracker -o cvshead src'
+
+test_expect_success \
+ 'tracking cvs commits 4' \
+ '( cd gitwork &&
+ git-cvstrack-fetch cvshead
+ )'
+
+test_expect_success \
+ 'merging' \
+ '( cd gitwork &&
+ git-checkout master &&
+ ! git-cvstrack-pull cvshead &&
+ git-rm b.txt &&
+ echo "a: line 1" >a.txt &&
+ echo "a: line 2" >>a.txt &&
+ echo "a: line 3" from git >>a.txt &&
+ echo "a: line 4" >>a.txt &&
+ git-add a.txt &&
+ git-commit -m "Merge cvspending/cvshead into master (resolved conflicts)"
+ )'
+
+test_expect_success \
+ 'cvs commit 5' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 5" >>a.txt &&
+ echo "b: line 5" >>b.txt &&
+ cvs commit -m "cvs commit 5"
+ )'
+
+# fighting cvsps' fuzz
+sleep 2
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C cvstracker -o cvshead src'
+
+test_expect_success \
+ 'tracking cvs commits 5' \
+ '( cd gitwork &&
+ git-cvstrack-fetch cvshead
+ )'
+
+test_expect_success \
+ 'merging' \
+ '( cd gitwork &&
+ git-checkout master &&
+ ! git-cvstrack-pull cvshead &&
+ git-rm b.txt &&
+ git-commit -m "Merge cvspending/cvshead into master (resolved conflicts)"
+ )'
+
+test_expect_success \
+ 'cvs commit 6' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 6" >>a.txt &&
+ cvs commit -m "cvs commit 6"
+ )'
+# fighting cvsps' fuzz
+sleep 2
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C cvstracker -o cvshead src'
+
+test_expect_success \
+ 'tracking cvs commits 6' \
+ '( cd gitwork &&
+ git-cvstrack-fetch cvshead
+ )'
+
+test_expect_success \
+ 'pushcvs' \
+ '( cd gitwork &&
+ git-cvstrack-pushcvs cvshead "$CVSWORK"
+ ) &&
+ ( cd "$CVSWORK" &&
+ cvs commit -F .msg &&
+ rm .msg
+ )'
+# fighting cvsps' fuzz
+sleep 2
+
+test_expect_success \
+ 'cvs commit 7' \
+ '( cd "$CVSWORK" &&
+ echo "a: line 7" >>a.txt &&
+ cvs commit -m "cvs commit 7"
+ )'
+# fighting cvsps' fuzz
+sleep 2
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C cvstracker -o cvshead src'
+
+test_expect_success \
+ 'tracking cvs commits 7' \
+ '( cd gitwork &&
+ git-cvstrack-fetch cvshead
+ )'
+
+test_expect_success \
+ 'more work in git' \
+ '( cd gitwork &&
+ git-cvstrack-pull cvshead &&
+ echo "c: line 2 from git" >>c.txt &&
+ git-commit -a -m "another git commit"
+ )'
+
+test_expect_success \
+ 'if pushcvs fails git repository must be unchanged' \
+ '( rm "$CVSWORK/c.txt" &&
+ cd gitwork &&
+ before=$(find .git/refs -type f -print -exec cat \{\} \;) &&
+ ! git-cvstrack-pushcvs cvshead "$CVSWORK" &&
+ after=$(find .git/refs -type f -print -exec cat \{\} \;) &&
+ test "$before" = "$after"
+ )'
+
+test_expect_success \
+ 'pushcvs' \
+ '( cd "$CVSWORK" &&
+ cvs up
+ ) &&
+ ( cd gitwork &&
+ git-cvstrack-pushcvs cvshead "$CVSWORK"
+ ) &&
+ ( cd "$CVSWORK" &&
+ cvs commit -F .msg &&
+ rm .msg
+ )'
+# fighting cvsps' fuzz
+sleep 2
+
+test_expect_success \
+ 'importing to git' \
+ 'git-cvsimport -v -a -i -k -u -z 1 -a -C cvstracker -o cvshead src'
+
+test_expect_success \
+ 'tracking cvs commits' \
+ '( cd gitwork &&
+ git-cvstrack-fetch cvshead
+ )'
+
+test_done
--
1.5.2.2.660.gc5eb3
^ permalink raw reply related
* Re: Start deprecating "git-command" in favor of "git command"
From: Yann Dirson @ 2007-07-01 13:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: walt, git
In-Reply-To: <Pine.LNX.4.64.0706302236210.4438@racer.site>
On Sat, Jun 30, 2007 at 10:37:07PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 30 Jun 2007, walt wrote:
>
> > Linus Torvalds wrote:
> > > I realize that a lot of people use the "git-xyzzy" format, and we have
> > > various historical reasons for it...
> >
> > One of the historical reasons was to allow users of gnu interactive
> > tools to delete the git wrapper script, as outlined in 'INSTALL'.
> >
> > Seems unlikely that 'git' could still be deleted if your proposed
> > changes are implemented. I recall that a few people cared a lot
> > about this, and not too long ago.
>
> All this would be less of a problem if Git consisted only of builtins,
> since you could easily do "mv git gitscm" then. *sigh*
That *would* be a problem for all porcelains - stgit, guilt, qgit,
etc, all have to find git...
Best regards,
--
Yann
^ permalink raw reply
* Re: Start deprecating "git-command" in favor of "git command"
From: Johannes Schindelin @ 2007-07-01 13:48 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Linus Torvalds, Git Mailing List
In-Reply-To: <20070701082202.GB6093@coredump.intra.peff.net>
Hi,
On Sun, 1 Jul 2007, Jeff King wrote:
> On Sat, Jun 30, 2007 at 12:17:10PM -0700, Junio C Hamano wrote:
>
> > So I am somewhat negative on this, unless there is a way for
> > scripts to say "Even though I say 'git foo', I do mean 'git foo'
> > not whatever the user has aliased".
>
> I had submitted GIT_NOALIAS=1 patches a while back, but IIRC, the
> consensus was that it was a bit too ugly and fragile in concept.
I think it is not GIT_NOALIAS that is ugly and fragile in concept. It is
the whole notion that you can define default parameters via aliases that
is ugly and fragile.
The possibility to say
git config alias.log '!rm -rf /home/peff'
on somebody _else's_ machine makes me go shudder.
And there's another thing. On some machines, rm is aliased to 'rm -i'.
That's good, right? NO! It _forces_ me to either look at the aliases on
that particular box, or alternatively (which is what I actually do),
specify _exactly_ what I want (I never do "rm", I always do "rm -i" or "rm
-f", or "git rm"). That's because the default behaviour is
_different_ on _different_ boxes. Repeat after me: consistency is good,
inconsistency is bad.
So, yes, I am glad we have the option of using GIT_NOALIAS (which I forgot
until jasam had this idea on IRC, independently), but no, I'd like not to
use it. Not because GIT_NOALIAS is ugly, but because individual
overriding default behaviours via peculiar aliases is.
Ciao,
Dscho
^ permalink raw reply
* Re: t7004-tag.sh fails (old gpg?)
From: Johannes Schindelin @ 2007-07-01 14:09 UTC (permalink / raw)
To: skimo; +Cc: Carlos Rica, git
In-Reply-To: <20070701124953.GH7969MdfPADPa@greensroom.kotnet.org>
Hi,
On Sun, 1 Jul 2007, Sven Verdoolaege wrote:
> gpg: Warning: using insecure memory!
> gpg: [don't know]: invalid packet (ctb=00)
> gpg: read_keyblock: read error: invalid packet
> gpg: enum_keyblocks failed: invalid keyring
> gpg: skipped `C O Mitter <committer@example.com>': invalid keyring
> gpg: signing failed: invalid keyring
That means that gpg somehow barfs on the keyring. I somehow had the
impression that the keyrings were binary compatible on different
systems... What system do you have?
> bash-3.00$ gpg --version
> gpg (GnuPG) 1.0.6
It is 1.4.5 here.
> Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
AFAIK DSA should suffice.
Ciao,
Dscho
^ permalink raw reply
* Re: Non-http dumb protocols
From: Johannes Schindelin @ 2007-07-01 14:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vbqewakz8.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sat, 30 Jun 2007, Junio C Hamano wrote:
> Having said that, I have a feeling that many people do not build
> any of the commit walkers, and especially the http walker,
> because they have no need for dumb protocols, and libcurl-dev is
> just another piece of dependency they do not have to have.
Interestingly, I just was involved in a discussion on IRC, where somebody
(out of quotat concerns) wants to use sftp to push to a bare repository,
which is served via HTTP.
Unfortunately, it seems that all persons wanting to have some support for
that, expect others to do the work for them.
However, there is a miniscule non-zero chance that eventually somebody
might want to realise an sftp push protocol (where you basically need the
ls-remote part of the fetcher, too, to determine what to pack and send).
And to complete a dumb sftp fetch protocol, you'd need a commit walker,
so I'd like to have at least a minimal interface for commit walkers
waiting for that saviour.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] cvstrack: work on imported cvs and other git branches
From: Johannes Schindelin @ 2007-07-01 14:35 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11832957963860-git-send-email-prohaska@zib.de>
Hi,
On Sun, 1 Jul 2007, Steffen Prohaska wrote:
> The idea is to import a cvs repository using git cvsimport; build a
> perfect history in git by cherry picking commits that are only in cvs
> but not in git; and export only summaries back to cvs. Cvs imports are
> organized on a separate git branch. git is used for merging. The
> differences can be sent back to cvs as a squashed commit together with a
> shortlog. Sent git commits are noted in the cvs commit message and will
> be ignored in subsequent cvs imports.
Wouldn't it be more intuitive to add a --squash option to
git-cvsexportcommit?
> To get the idea you can run t/t9250-git-cvstrack.sh and explore
> the git repository created in t/trash/gitwork.
Hmm. I would have expected such a non-descriptive description _after_ the
commit message, not _in_ it.
Ciao,
Dscho
^ permalink raw reply
* Re: [StGIT PATCH 0/6] New and improved DAG appliedness series
From: Karl Hasselström @ 2007-07-01 14:35 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, git
In-Reply-To: <20070630195451.GL7730@nan92-1-81-57-214-146.fbx.proxad.net>
On 2007-06-30 21:54:51 +0200, Yann Dirson wrote:
> On Sun, Jun 10, 2007 at 02:54:47AM -0700, Karl Hasselström wrote:
>
> > This took a while, but here it is. (Actually, I finished this
> > about a week ago, but had no Internet connection so I couldn't
> > send it.)
>
> Is this the latest version of the DAG patches, or is there maybe a
> public repo where you push your work ?
This is the latest version, and no, I don't yet have a public repo
that I push this stuff to.
I've been travelling a lot the last few weeks, and I'm not quite done
yet, so I haven't had time to even follow the mailing list properly,
but after that I plan to start a pu-ish (rebasing) integration branch
for the patches that I, you, and others post to the list.
> It happens that my refactorings touches virtually everything,
I noticed. :-)
> so there will be conflicts,
:-)
> and the best thing to do is probably that I rebase my work on yours.
Thanks for the vote of confidence. Please go ahead; as I said, you
already have the latest version of my series, and it may be a while
yet before I have much time to burn on StGIT.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] cvstrack: work on imported cvs and other git branches
From: Steffen Prohaska @ 2007-07-01 15:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707011533370.4438@racer.site>
On Jul 1, 2007, at 4:35 PM, Johannes Schindelin wrote:
> On Sun, 1 Jul 2007, Steffen Prohaska wrote:
>
>> The idea is to import a cvs repository using git cvsimport; build a
>> perfect history in git by cherry picking commits that are only in cvs
>> but not in git; and export only summaries back to cvs. Cvs imports
>> are
>> organized on a separate git branch. git is used for merging. The
>> differences can be sent back to cvs as a squashed commit together
>> with a
>> shortlog. Sent git commits are noted in the cvs commit message and
>> will
>> be ignored in subsequent cvs imports.
>
> Wouldn't it be more intuitive to add a --squash option to
> git-cvsexportcommit?
Maybe.
But how to handle commits that are sent to cvs and come back
through git-cvsimport?
How can they be handled with git-cvsexportcommit/git-cvsimport?
>> To get the idea you can run t/t9250-git-cvstrack.sh and explore
>> the git repository created in t/trash/gitwork.
>
> Hmm. I would have expected such a non-descriptive description
> _after_ the
> commit message, not _in_ it.
thanks, I'll remember this for future patches.
Steffen
^ permalink raw reply
* Re: t7004-tag.sh fails (old gpg?)
From: Sven Verdoolaege @ 2007-07-01 15:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Carlos Rica, git
In-Reply-To: <Pine.LNX.4.64.0707011507310.4438@racer.site>
On Sun, Jul 01, 2007 at 03:09:06PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 1 Jul 2007, Sven Verdoolaege wrote:
>
> > gpg: Warning: using insecure memory!
> > gpg: [don't know]: invalid packet (ctb=00)
> > gpg: read_keyblock: read error: invalid packet
> > gpg: enum_keyblocks failed: invalid keyring
> > gpg: skipped `C O Mitter <committer@example.com>': invalid keyring
> > gpg: signing failed: invalid keyring
>
> That means that gpg somehow barfs on the keyring. I somehow had the
> impression that the keyrings were binary compatible on different
> systems... What system do you have?
A regular (old) Linux system:
Linux greensroom 2.4.23 #3 SMP Mon Jan 5 14:14:32 CET 2004 i686 unknown unknown GNU/Linux
skimo
^ permalink raw reply
* Re: t7004-tag.sh fails (old gpg?)
From: Carlos Rica @ 2007-07-01 15:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: skimo, git
In-Reply-To: <Pine.LNX.4.64.0707011507310.4438@racer.site>
2007/7/1, Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Sun, 1 Jul 2007, Sven Verdoolaege wrote:
>
> > gpg: Warning: using insecure memory!
> > gpg: [don't know]: invalid packet (ctb=00)
> > gpg: read_keyblock: read error: invalid packet
> > gpg: enum_keyblocks failed: invalid keyring
> > gpg: skipped `C O Mitter <committer@example.com>': invalid keyring
> > gpg: signing failed: invalid keyring
>
> That means that gpg somehow barfs on the keyring. I somehow had the
> impression that the keyrings were binary compatible on different
> systems... What system do you have?
>
> > bash-3.00$ gpg --version
> > gpg (GnuPG) 1.0.6
>
> It is 1.4.5 here.
I have gpg (GnuPG) 1.4.1 here, in the system I used to generate the key.
^ permalink raw reply
* [PATCH] Fix t5516-fetch for systems where `wc -l` outputs whitespace.
From: Brian Gernhardt @ 2007-07-01 15:48 UTC (permalink / raw)
To: git
When wc outputs whitespace, the test "$(command | wc -l)" = 1 is
broken because " 1" != "1". Let the shell eat the whitespace by
using test 1 = $(command | wc -l) instead.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
As per the previous discussion on the list.
t/t5516-fetch-push.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 08d58e1..c0fa2ba 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -226,7 +226,7 @@ test_expect_success 'push with colon-less refspec (3)' '
git branch -f frotz master &&
git push testrepo frotz &&
check_push_result $the_commit heads/frotz &&
- test "$( cd testrepo && git show-ref | wc -l )" = 1
+ test 1 = $( cd testrepo && git show-ref | wc -l )
'
test_expect_success 'push with colon-less refspec (4)' '
@@ -239,7 +239,7 @@ test_expect_success 'push with colon-less refspec (4)' '
git tag -f frotz &&
git push testrepo frotz &&
check_push_result $the_commit tags/frotz &&
- test "$( cd testrepo && git show-ref | wc -l )" = 1
+ test 1 = $( cd testrepo && git show-ref | wc -l )
'
--
1.5.2.2.590.gf578-dirty
^ permalink raw reply related
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