* Re: Can I remove stg sync --undo ?
From: Karl Hasselström @ 2008-07-08 4:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807071347n17e2e09ai761b849d2d03bc9c@mail.gmail.com>
On 2008-07-07 21:47:13 +0100, Catalin Marinas wrote:
> 2008/7/5 Karl Hasselström <kha@treskal.com>:
>
> > On 2008-07-04 23:05:11 +0100, Catalin Marinas wrote:
> >
> > > There are two operations that can conflict for sync - pushing a
> > > patch and the actual sync'ing, i.e. a three-way merge with the
> > > patch to be synchronised with (kind of fold).
> >
> > My guess is that conflicts of the first type would work out of the
> > box (i.e. they'd get an extra log entry) while conflicts of the
> > second type would not.
>
> I don't really care as long as I can get back to the patch state
> before running the sync command if anything goes wrong. So, one undo
> level would be enough.
>
> > We need a sync undo test.
>
> Yes but not sure what how undo would behave in this situation yet.
OK, then I'll write a simple test that makes sure undo and sync
interact the way I imagine they should. ;-)
> > With just "stg undo" (or reset or redo), you get the usual
> > new-infrastructure check about dirty index and working tree (the
> > whole index must be clean, and the parts of the worktree we need
> > to touch must be clean). Which prevents you from undoing a
> > conflicting push, for example.
> >
> > With the --hard flag, any uncleanliness in index or worktree
> > simply gets zapped (just like with git reset --hard). I'm not 100%
> > happy with this -- what I'd really like is to zap only the files
> > that we need to touch. But I haven't figured out a good way to do
> > that.
>
> OK, not much to comment here, it's your implementation :-).
But you too get to live with the design decisions ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Shawn O. Pearce @ 2008-07-08 4:19 UTC (permalink / raw)
To: Jakub Narebski, Marek Zawirski
Cc: git, Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Miklos Vajna,
Johannes Schindelin, Stephan Beyer, Christian Couder,
Daniel Barkalow
In-Reply-To: <200807080227.43515.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> I'd very much like to have (or perhaps to wrote) some sort of interim
> progress report for Google Summer of Code 2008 projects on
> http://git.or.cz/gitwiki/SoC2008Projects. Therefore I'd like you to
> expand and/or correct those mini-summaries below.
>
> (It would be, I guess, good preparation for GSoC 2008 mid-term
> evaluations, which according to GSoC 2008 timeline
> http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
> are to take place July 7 -- July 14.)
Yes, it is that time for evaluations. The evaluations are now open
to students and mentors alike; please make sure you complete them
by the deadline of July 14th.
> 4. Eclipse plugin push support (!)
>
> Student: Marek Zawirski
> Mentor: Shawn O. Pearce
>
> I am not following egit/jgit development close enough, but if I remember
> correctly there is some code which provides very rudimentary support
> for native generation of simplified packs, and IIRC also for push over
> some protocols.
>
> And there is push support over SFTP and (encrypted) Amazon S3...
Marek is on holiday right now, so I have to answer for him here.
Otherwise I would have preferred to let him do it.
Thus far Marek has completed generation of packs, including delta
re-use from packs using either v1 or v2 index, including taking
advantage of the CRC inside the v2 index to accelerate a safe reuse.
This code permits jgit to write a valid pack.
The packing code does not (yet) search for a delta base, or create
a new delta for an undeltified object. Packing loose objects packs
them as whole objects in the pack file, resulting in little to no
reduction over their loose object size. This is not a limitation
of Java. Marek and I simply decided that protocol support was more
important than really tight network transport at this point in time.
As a result of being able to create pack files Marek was able to
implement the client side of git-push for the native pack transfer
service, aka push over SSH, push to another local repository (by
forking 'git receive-pack') and push over anonymous git://.
Using Marek's pack generation code I added support for push over
the dumb sftp:// and amazon-s3:// protocols, with the latter also
supporting transparent client side encryption.
I chose to add these features to jgit partly as an exercise to prove
that Marek's code was built well enough to be reused for this task,
partly because I wanted to backup some private personal repositories
to Amazon S3, and partly to prove that multiple dumb transports
could implement push support.
All of the above is done in the non-Eclipse, BSD licensed jgit
library, making it available to any tool built on top of the Java
platform, even if said tool does not use the Eclipse platform or
any other code from Eclipse.
At this point Marek's code is in the main egit.git tree's master
branch, and is in "production" use by myself and Robin, and maybe
a few others. I am quite happy with the work Marek has completed
to date for the project.
When Marek returns from his holiday he will be working on Eclipse
UI features to expose this jgit push functionality to the end-user
within the Eclipse workbench.
--
Shawn.
^ permalink raw reply
* Re: [StGit PATCH] Remove --undo flags from stg commands and docs
From: Karl Hasselström @ 2008-07-08 4:21 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807071354j50dca83aya90317f97f559b19@mail.gmail.com>
On 2008-07-07 21:54:01 +0100, Catalin Marinas wrote:
> 2008/7/4 Karl Hasselström <kha@treskal.com>:
>
> > In this one, I've just removed the --undo flag from sync without
> > adding anything back. Still undetermined if that's OK.
>
> I think it should be ok (see the other thread). Anyway, have you
> heard of anyone else using sync apart from me?
No, I haven't.
I've tried to understand what it does, and as far as I can tell it
doesn't do quite what I want. (What I want is the ability to 3-way
merge StGit patch stacks, so that I can modify the same patch stack in
several places and merge back and forth. From what I recall, the sync
command is more like a 2-way merge -- that is, it doesn't take the
last common ancestor into account. But it's been a while since I
studied it.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Jeff King @ 2008-07-08 4:26 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <F0AD23BC-FA9A-4593-8942-228C428B661E@silverinsanity.com>
On Mon, Jul 07, 2008 at 11:03:46AM -0400, Brian Gernhardt wrote:
> I personally expected @{1} to be identical to HEAD@{1}. Since omitting a
> ref usually refers to HEAD, why shouldn't omitting it when referring to
> the reflogs mean the HEAD log? The definition of @{1} is useful since
> there's no other easy way to get "current branch's reflog", but I think
> it's non-obvious. (Since HEAD@{1} is something completely different, I
> think the only other way to refer to @{1} is $(git symbolic-ref)@{1}.)
FYI, there was much discussion about this exact point:
http://thread.gmane.org/gmane.comp.version-control.git/38379
(I don't know that it has that much bearing on the current discussion,
but since I went to the trouble of digging it up, I thought you might
find it useful).
-Peff
^ permalink raw reply
* Re: [StGit PATCH 0/2] push optimizations
From: Karl Hasselström @ 2008-07-08 4:36 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807071412j71780300p87d00cccea6cd8f4@mail.gmail.com>
On 2008-07-07 22:12:26 +0100, Catalin Marinas wrote:
> 2008/7/2 Karl Hasselström <kha@treskal.com>:
>
> > Here's the git-apply call you asked for. You were right: it was a
> > huge speed-up.
>
> I know, I've been through this couple of years ago :-)
:-P
> > I set up a benchmark to test it:
> >
> > * 32 directories, each containing 32 subdirectories, each
> > containing 32 small (and different) files.
>
> Can you try with a Linux kernel like the -mm tree? You get normally
> sized patches which might show a difference with the patch log. You
> can clone the for-akpm branch on git://linux-arm.org/linux-2.6 and
> just uncommit ~300 patches.
Sure, I'll do that. (But one of the reasons I chose a fully synthetic
benchmark is that I wanted to start a performance suite similar to our
test suite, and we want such a thing to be repeatable but not too
large. (That said, operating on points of the kernel history that are
fixed should do the trick as well. I'll try to find such points -- a
long string of -mm patches somewhere in the history maybe?))
> > * I set all this up with a python script feeding fast-import. A
> > huge time-saver!
>
> What is fast-import?
man git-fast-import
I'll try to clean up and publish the script I used.
> > * Pop patches, git-reset to upstream, then goto top patch. This
> > makes sure that we use the new infrastructure to push, and that
> > we get one file-level conflict in each patch.
> >
> > Before the first patch, the "goto" command took 4:27 minutes,
> > wall-clock time. After the first patch, it took 1:31. After the
> > second, 0:48; one second or so slower than the stable branch
> > (which does not have a patch stack log).
>
> One second is just noise and depends on how warm the caches are. You
> could run a few times consecutively and discard the first result but
> we don't need to be that accurate.
I did run a few times, and it did indeed fluctuate some -- but I'm
pretty sure there was a measurable slowdown. Though I agree that it's
close enough that it doesn't really make a difference.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] avoid null SHA1 in oldest reflog
From: Jeff King @ 2008-07-08 4:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When the user specifies a ref by a reflog entry older than
one we have (e.g., "HEAD@{20 years ago"}), we issue a
warning and give them the "from" value of the oldest reflog
entry. That is, we say "we don't know what happened before
this entry, but before this we know we had some particular
SHA1".
However, the oldest reflog entry is often a creation event
such as clone or branch creation. In this case, the entry
claims that the ref went from "00000..." (the null sha1) to
the new value, and the reflog lookup returns the null sha1.
While this is technically correct (the entry tells us that
the ref didn't exist at the specified time) it is not
terribly useful to the end user. What they probably want
instead is "the oldest useful sha1 that this ref ever had".
This patch changes the behavior such that if the oldest ref
would return the null sha1, it instead returns the first
value the ref ever had.
We never discovered this problem in the test scripts because
we created "fake" reflogs that had only a specified segment
of history. This patch updates the tests with a creation
event at the beginning of history.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
---
This patch was generally well-received in the first posting, but didn't
get applied. I think it was because the previous thread ended with me
voicing one concern: should we do this magic other places? I think the
answer is no, we don't need to. And even if I am wrong, then this is
probably still the right fix for _this_ bit, and we can fix the other if
and when a bug report comes in.
refs.c | 4 ++++
t/t1400-update-ref.sh | 9 ++++++++-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/refs.c b/refs.c
index 9e8e858..6c6e9e5 100644
--- a/refs.c
+++ b/refs.c
@@ -1412,6 +1412,10 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
tz = strtoul(tz_c, NULL, 10);
if (get_sha1_hex(logdata, sha1))
die("Log %s is corrupt.", logfile);
+ if (is_null_sha1(sha1)) {
+ if (get_sha1_hex(logdata + 41, sha1))
+ die("Log %s is corrupt.", logfile);
+ }
if (msg)
*msg = ref_msg(logdata, logend);
munmap(log_mapped, mapsz);
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index f387d46..ca99d37 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -155,7 +155,8 @@ rm -f .git/$m .git/logs/$m expect
git update-ref $m $D
cat >.git/logs/$m <<EOF
-$C $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150320 -0500
+0000000000000000000000000000000000000000 $C $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150320 -0500
+$C $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150350 -0500
$A $B $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150380 -0500
$F $Z $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150680 -0500
$Z $E $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150980 -0500
@@ -186,6 +187,12 @@ test_expect_success \
'Query "master@{May 26 2005 23:32:00}" (exactly history start)' \
'rm -f o e
git rev-parse --verify "master@{May 26 2005 23:32:00}" >o 2>e &&
+ test '"$C"' = $(cat o) &&
+ test "" = "$(cat e)"'
+test_expect_success \
+ 'Query "master@{May 26 2005 23:32:30}" (first non-creation change)' \
+ 'rm -f o e
+ git rev-parse --verify "master@{May 26 2005 23:32:30}" >o 2>e &&
test '"$A"' = $(cat o) &&
test "" = "$(cat e)"'
test_expect_success \
--
1.5.6
^ permalink raw reply related
* Re: [StGit PATCH] Discard stderr output from git apply
From: Karl Hasselström @ 2008-07-08 4:39 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0807071349u7c35d2fcr5025b2b282f290f6@mail.gmail.com>
On 2008-07-07 21:49:31 +0100, Catalin Marinas wrote:
> 2008/7/4 Karl Hasselström <kha@treskal.com>:
>
> > It prints error messages when it fails, and we don't need to see
> > them since we don't care exactly _why_ it failed.
>
> Are you sure we don't need this? I found it useful when running
> "import" to see why a patch failed.
Aww, you're right. Apply isn't just called from the simple merge fast
path, it's also used to apply patches. Who would've guessed? ;-)
I'll add a parameter to shut it up or not depending on the caller's
preferences.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Cloning marks pack for .keep
From: Shawn O. Pearce @ 2008-07-08 4:46 UTC (permalink / raw)
To: Jean-Luc Herren, Junio C Hamano; +Cc: Git Mailing List, Daniel Barkalow
In-Reply-To: <48728A52.8080107@gmx.ch>
Jean-Luc Herren <jlh@gmx.ch> wrote:
> After cloning a local repository with "git clone file://...", the
> resulting repo had one big pack file, as expected, but also a
> matching ".keep" file. Certainly this is a bug, isn't it? The
> same happens if I clone git.git. I used git 1.5.6.1 but observed
> the same with the current master. I bisected this behavior to
> commit fa740529 by Shawn O. Pearce (CC'ing him). Since this dates
> back to 2007, I wonder if maybe only I am seeing this, but I
> cannot think of any reason for it.
This is a known issue to me; I have been seeing this behavior
myself since probably fa74 hit next. I just don't clone often
so I've never thought about it much. ;-)
I'm willing to bet its the hard-coded:
+ args.lock_pack = 1;
inside of fetch_refs_via_pack() that is causing the .keep file to
stay around after the clone. When this gets set the caller must
delete the transport->pack_lockfile (if non-null) once the refs
have all been updated to reference the objects downloaded into the
pack file. Under git-clone all refs are new and there is little to
no chance that someone issues "git gc" at the same time as the fetch
is running, so git-clone never cleaned up the pack_lockfile.
I think this would fix it.
--8<--
Remove unnecessary pack-*.keep file after successful git-clone
Once a clone is successful we no longer need to hold onto the
.keep file created by the transport. Delete the file so we
can later repack the complete repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-clone.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 7bcc664..7ee8275 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -337,6 +337,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
char branch_top[256], key[256], value[256];
struct strbuf reflog_msg;
+ struct transport *transport = NULL;
struct refspec refspec;
@@ -458,8 +459,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
refs = clone_local(path, git_dir);
else {
struct remote *remote = remote_get(argv[0]);
- struct transport *transport =
- transport_get(remote, remote->url[0]);
+ transport = transport_get(remote, remote->url[0]);
if (!transport->get_refs_list || !transport->fetch)
die("Don't know how to clone %s", transport->url);
@@ -529,6 +529,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
option_no_checkout = 1;
}
+ if (transport)
+ transport_unlock_pack(transport);
+
if (!option_no_checkout) {
struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
struct unpack_trees_options opts;
--
1.5.6.74.g8a5e
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] completion: add branch options --contains --merged --no-merged
From: Shawn O. Pearce @ 2008-07-08 4:49 UTC (permalink / raw)
To: Eric Raible; +Cc: Git Mailing List, Junio C Hamano, szeder
In-Reply-To: <279b37b20807071341k3551e61cl10c5969600ba8218@mail.gmail.com>
Eric Raible <raible@gmail.com> wrote:
> Signed-off-by: Eric Raible <raible@gmail.com>
Trivially-Acked-by: Shawn O. Pearce <spearce@spearce.org>
;-)
More completion support that probably should go to maint, as the
functionality in git-branch is in 1.5.6 but we (again) forgot to
make sure the completion was up-to-date prior to release.
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index 0eb8df0..22e109d 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -546,7 +546,7 @@ _git_branch ()
> --*)
> __gitcomp "
> --color --no-color --verbose --abbrev= --no-abbrev
> - --track --no-track
> + --track --no-track --contains --merged --no-merged
> "
> ;;
> *)
> --
> 1.5.6.1.1071.g76fb.dirty
--
Shawn.
^ permalink raw reply
* uninstalling Git
From: Christian Jaeger @ 2008-07-08 4:57 UTC (permalink / raw)
To: Git Mailing List
Hello,
There are two situations where I'm missing a way to uninstall Git:
- accidental install with prefix=/usr instead of prefix=/usr/local which
I usually choose
- removing cruft from older gits, like tools and their man/info pages
which don't exist anymore in newer Git releases
I wonder why there's no "uninstall" make target. Ok, maybe some people
would argue that installing and uninstalling software through make has
never been the best way, but usually I don't have problems with software
providing "make uninstall", and I'm left with no solution for the above
once I choose to use "make install" for Git.
[
Well, there's the "checkinstall" tool, but for some reason using
checkinstall (version 1.6.1(-7) from Debian lenny) leads to some strange
problems:
at first I always got (with a fresh tree):
...
if test -r /usr/share/info/dir; then \
install-info --info-dir=/usr/share/info git.info ;\
install-info --info-dir=/usr/share/info gitman.info ;\
else \
echo "No directory found in /usr/share/info" >&2 ; \
fi
No `START-INFO-DIR-ENTRY' and no `This file documents'.
install-info(git.info): unable to determine description for `dir' entry
- giving up
No `START-INFO-DIR-ENTRY' and no `This file documents'.
install-info(gitman.info): unable to determine description for `dir'
entry - giving up
make[1]: *** [install-info] Error 1
make[1]: Leaving directory `/usr/src/GIT/T/git.1/Documentation'
make: *** [install-info] Error 2
and now I'm consistently getting (each time with a fresh tree):
asciidoc -b docbook -d book user-manual.txt
FAILED: unexpected error:
------------------------------------------------------------
Traceback (most recent call last):
File "/usr/bin/asciidoc", line 4014, in asciidoc
config.load_all(CONF_DIR)
File "/usr/bin/asciidoc", line 3637, in load_all
for f in os.listdir(filters):
OSError: [Errno 2] No such file or directory: '/etc/asciidoc/filters'
...
and now, again with a fresh tree but without -j2:
# checkinstall make prefix=/usr install install-doc install-info
...
asciidoc -b docbook -d manpage -f asciidoc.conf \
-agit_version=1.5.6.GIT -o git-add.xml+ git-add.txt
FAILED: unexpected error:
------------------------------------------------------------
Traceback (most recent call last):
File "/usr/bin/asciidoc", line 4014, in asciidoc
config.load_all(CONF_DIR)
File "/usr/bin/asciidoc", line 3637, in load_all
for f in os.listdir(filters):
OSError: [Errno 2] No such file or directory: '/etc/asciidoc/filters'
------------------------------------------------------------
make[1]: *** [git-add.xml] Error 1
make[1]: Leaving directory `/usr/src/GIT/T/git.1/Documentation'
make: *** [install-doc] Error 2
**** Installation failed. Aborting package creation.
Cleaning up...OK
Bye.
where /etc/asciidoc/filters clearly is a non-empty directory. It seems
to behave non-deterministically. So my guess is that checkinstall is
using LD_PRELOAD tricks or some such and just doesn't work for the task
here, at least not without fixing something.
]
So,
- is there any (good?) reason there is no uninstall target? Should I
look into creating one?
- do you have better or working alternative suggestions?
Actually I'd be happy if there are more elegant solutions than make
uninstall, since there is the race/hen-and-egg problem of having to run
"make uninstall" from the tree before checking out the new version, and
checking out the new version of course needs git, meaning the "right"
approach would be to keep the working dir of the last install for the
purpose of uninstallation until after having built the new version.
Maybe it's enough to just keep the toplevel Makefile, but that would be
making assumptions. Maybe I should talk with the Debian people about how
to build debs easily for such purposes (and not using the standard
Debian packages -- I'd really like to just have an own single package
without any applied patches etc.)?
Thanks,
Christian.
^ permalink raw reply
* Re: An alternate model for preparing partial commits
From: Jeff King @ 2008-07-08 4:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0806281549060.9925@racer>
On Sat, Jun 28, 2008 at 03:51:12PM +0100, Johannes Schindelin wrote:
> > Here's a somewhat hackish implementation of "git stash -i" that just
> > relies on "add -i":
>
> I like it.
Thinking about this some more, it seems to me to lack one really
important feature that "git add -i" has: you must stash all in one go.
That is, I may do some of the adds as "git add <file1> <file2>" and then
pick out the rest of the changes with "git add -p". And traditionally,
stashing has been about dumping all changes, so everything happened at
once.
But I think what I would really like here is to say "now I don't want to
stage for a commit; I want to stage into some bucket, so that I can
clear my workspace for making the commit". And then proceed to use "add"
or "add -i" in the usual way, except that they go into my bucket. And at
the end, I switch back to staging for a commit, make the commit, and
then start picking things out of my bucket.
And that workflow is not too hard to imagine by just pointing
GIT_INDEX_FILE to the bucket.
But I am still thinking on this, so I'll let it percolate and then maybe
try to implement something once I have a better sense of exactly what
workflow I want. I just thought I would throw it out there for others to
ponder.
-Peff
^ permalink raw reply
* Re: Test breakage [Re: [ANNOUNCE] GIT 1.5.6.2]
From: Jeff King @ 2008-07-08 5:16 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <g4t342$9m8$1@ger.gmane.org>
On Mon, Jul 07, 2008 at 02:44:49PM +0200, Michael J Gruber wrote:
> On Kubuntu 7.10 (not my choice, this is at work...), "make test" gives:
>
> *** t9600-cvsimport.sh ***
> [...]
> * FAIL 6: update git module
> cd module-git &&
> git cvsimport -a -z 0 module &&
> git merge origin &&
> cd .. &&
> test_cmp module-cvs/o_fortuna module-git/o_fortuna
>
> On the second (and subsequent) run, "make test" succeeds. I tried again
> with a fresh copy from the tarball, same effect: failure on 1, success on
> 2 and following.
I tried reproducing on my Debian box with various weaks of $LANG, but I
couldn't. Can you please try running "./t9600-cvsimport.sh -v -i" and
send us the output of a failing instance. It's not clear which step in
failing test is causing the problem, or if cvsps is giving off any
useful errors.
> This is with LANG=de_DE.UTF-8, whereas with LANG=C the tests succeed the
> first time already. Are tests supposed to be done in C locale only? Do
> they reuse data from a previous test run? I didn't notice this with
> 1.5.6.1.
They should be perfectly repeatable, but I have run into problems in the
past with cruft in my ~/.cvsps directory. However, we should be setting
$HOME properly in t9600 to avoid this, so I'm not sure what the culprit
is.
-Peff
^ permalink raw reply
* PATCH] Documentation: Tweak use case in "git stash save --keep-index"
From: Eric Raible @ 2008-07-08 5:18 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano, szeder
The documentation suggests using "git stash apply" in the
--keep-index workflow even though doing so will lead to clutter
in the stash. And given that the changes are about to be
committed anyway "git stash pop" is more sensible.
Additionally the text preceeding the example claims that it
works for "two or more commits", but the example itself is
really tailored for just two. Expanding it just a little
makes it clear how the procedure generalizes to N commits.
Signed-off-by: Eric Raible <raible@gmail.com>
---
Note that this is relative to Junio's pu branch (v1.5.6.2-397-g20210bb)
Documentation/git-stash.txt | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index df26901..bf241da 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -201,9 +201,10 @@ $ git add --patch foo
$ git stash save --keep-index
$ build && run tests
$ git commit -m 'First part'
-$ git stash apply
+$ git stash pop
+... repeat above five steps until one commit remains ...
$ build && run tests
-$ git commit -a -m 'Second part'
+$ git commit foo -m 'Remaining parts'
----------------------------------------------------------------
SEE ALSO
--
1.5.6.1.1073.g489ff.dirty
^ permalink raw reply related
* Re: [PATCH] completion: add branch options --contains --merged --no-merged
From: Junio C Hamano @ 2008-07-08 5:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Eric Raible, Git Mailing List, szeder
In-Reply-To: <20080708044922.GD2542@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Eric Raible <raible@gmail.com> wrote:
>> Signed-off-by: Eric Raible <raible@gmail.com>
>
> Trivially-Acked-by: Shawn O. Pearce <spearce@spearce.org>
>
> ;-)
>
> More completion support that probably should go to maint, as the
> functionality in git-branch is in 1.5.6 but we (again) forgot to
> make sure the completion was up-to-date prior to release.
I am actually getting more worried about completion code getting larger
and larger without its performance impact not being looked at nor
addressed adequately. In my regular working tree:
$ echo Docu<TAB>
completes "mentation/" instantly, but:
$ git log -- Docu<TAB>
takes about 1.5 to 2 seconds to complete the same.
^ permalink raw reply
* Re: uninstalling Git
From: Eric Hanchrow @ 2008-07-08 5:30 UTC (permalink / raw)
To: git
In-Reply-To: <4872F3B0.6050406@jaeger.mine.nu>
>>>>> "Christian" == Christian Jaeger <christian@jaeger.mine.nu> writes:
Christian> I wonder why there's no "uninstall" make target.
This is a problem with lots of packages, not just git. Here are two
things I do:
* When I remember, I use "gnu stow" to manage installations; doing so
makes uninstallation easy.
* Failing that, I run
find /usr -printf '%T@ ' -ls | sort -n | cut -d\ -f 2-
and assume that all the installed files have the same last-modified
timestamps -- once you've found one of them in that pipeline's output,
you've found them all, since they'll all be adjacent.
--
Asking the Iraqi people to assume Saddam's debts
is rather like telling a man who has been shot in the head
that he has to pay for the bullet.
-- James Surowiecki
^ permalink raw reply
* Re: PATCH] Documentation: Tweak use case in "git stash save --keep-index"
From: Junio C Hamano @ 2008-07-08 5:39 UTC (permalink / raw)
To: Eric Raible; +Cc: Git Mailing List, Junio C Hamano, szeder
In-Reply-To: <279b37b20807072218o19dabd97y2c4edc62fb980ca4@mail.gmail.com>
"Eric Raible" <raible@gmail.com> writes:
> The documentation suggests using "git stash apply" in the
> --keep-index workflow even though doing so will lead to clutter
> in the stash. And given that the changes are about to be
> committed anyway "git stash pop" is more sensible.
Yeah, I was pondering about this myself. After popping the remaining
part, you would "git add -p" the next batch, the same "stash save -k-i" to
save the remaining bits away, and continue. Will queue.
BUT
It is very likely that in this workflow you would sometimes find that what
you staged (and left in the working tree after "save -k-i") is faulty and
you need to tweak it in place to make it into a good enough shape for
committing. The example probably should talk about what happens.
Editing, testing and committing is fine, but then what? Will the "pop"
wipe that unplanned change you made after "save -k-i" out? (the answer is
no and this is safe, but the reader of the documentaiton needs it
explained)
Also this may be a good way to split an existing commit into five during a
"rebase -i" session, and the example in the documentation might want to
talk about it in that larger picture.
> Documentation/git-stash.txt | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
> index df26901..bf241da 100644
> --- a/Documentation/git-stash.txt
> +++ b/Documentation/git-stash.txt
> @@ -201,9 +201,10 @@ $ git add --patch foo
> $ git stash save --keep-index
> $ build && run tests
> $ git commit -m 'First part'
> -$ git stash apply
> +$ git stash pop
> +... repeat above five steps until one commit remains ...
> $ build && run tests
> -$ git commit -a -m 'Second part'
> +$ git commit foo -m 'Remaining parts'
> ----------------------------------------------------------------
^ permalink raw reply
* git push to amazon s3 [was: [GSoC] What is status of Git's Google Summer of Code 2008 projects?]
From: Tarmigan @ 2008-07-08 5:48 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Marek Zawirski, git, Daniel Barkalow, Nick Hengeveld,
Johannes Schindelin
(trimmed cc list to folks who've touched http-push.c)
On Mon, Jul 7, 2008 at 9:19 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Using Marek's pack generation code I added support for push over
> the dumb sftp:// and amazon-s3:// protocols, with the latter also
> supporting transparent client side encryption.
>
> I chose to add these features to jgit partly as an exercise to prove
> that Marek's code was built well enough to be reused for this task,
> partly because I wanted to backup some private personal repositories
> to Amazon S3, and partly to prove that multiple dumb transports
> could implement push support.
That sounds cool. I've been looking into adding s3 push into cgit,
and was looking into modifying http-push.c, but got in over my head.
I had trouble trying to make it fit into the DAV model that http-push
is built around, in part because s3 doesn't seem to support any
locking and a lot of the http-push code seems to be around the
locking.
Can you describe the s3 support that you added? Did you do any
locking when you pushed? The objects and packs seem likely to be
naturally OK, but I was worried about refs/ and especially
objects/info/packs and info/refs (fetch over http works currently out
of the box with publicly accessable s3 repos).
Thanks,
Tarmigan
PS For anyone else who's interested, here's some instructions on how I
got started with s3 and git:
Start by creating an amazon s3 account
Next download and install "aws" from http://timkay.com/aws/
Set it up and install your amazon keys as specified.
# I setup a bucket named git_test.
s3mkdir git_test
# Run this script to upload a git repo to amazon (run
update-server-info first):
#!/bin/bash
for i in $(tree -fi --noreport git_test_orig.git) ; do
#exclude directories
if [ ! -d $i ] ; then
echo $i
s3put "x-amz-acl: public-read" git_test/ $i
fi
done
# Then you can clone (really, feel free to clone from this url. It
should just work):
git clone http://s3.amazonaws.com/git_test/git_test_orig.git
# This experimenting on the git.git repo will set you back about US$0.05
^ permalink raw reply
* Re: git push to amazon s3 [was: [GSoC] What is status of Git's Google Summer of Code 2008 projects?]
From: Mike Hommey @ 2008-07-08 5:56 UTC (permalink / raw)
To: Tarmigan
Cc: Shawn O. Pearce, Marek Zawirski, git, Daniel Barkalow,
Nick Hengeveld, Johannes Schindelin
In-Reply-To: <905315640807072248w44ccdc4y2f1cf54a10c50c43@mail.gmail.com>
On Mon, Jul 07, 2008 at 10:48:59PM -0700, Tarmigan wrote:
> (trimmed cc list to folks who've touched http-push.c)
>
> On Mon, Jul 7, 2008 at 9:19 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Using Marek's pack generation code I added support for push over
> > the dumb sftp:// and amazon-s3:// protocols, with the latter also
> > supporting transparent client side encryption.
> >
> > I chose to add these features to jgit partly as an exercise to prove
> > that Marek's code was built well enough to be reused for this task,
> > partly because I wanted to backup some private personal repositories
> > to Amazon S3, and partly to prove that multiple dumb transports
> > could implement push support.
>
> That sounds cool. I've been looking into adding s3 push into cgit,
> and was looking into modifying http-push.c, but got in over my head.
> I had trouble trying to make it fit into the DAV model that http-push
> is built around, in part because s3 doesn't seem to support any
> locking and a lot of the http-push code seems to be around the
> locking.
>
> Can you describe the s3 support that you added? Did you do any
> locking when you pushed? The objects and packs seem likely to be
> naturally OK, but I was worried about refs/ and especially
> objects/info/packs and info/refs (fetch over http works currently out
> of the box with publicly accessable s3 repos).
FWIW, I'm starting to work again on the http backend overhaul. My idea
is to provide a generic dumb protocol vfs-like interface, so that other
dumb protocols could be built out of it.
Mike
^ permalink raw reply
* Re: [PATCH] fix "git-submodule add a/b/c/repository"
From: Junio C Hamano @ 2008-07-08 6:02 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Sylvain Joyeux, Lars Hjemli, Ping Yin, git
In-Reply-To: <4872DE54.5010804@gmail.com>
Mark Levedahl <mlevedahl@gmail.com> writes:
> Junio C Hamano wrote:
>> I'd like to hear clarifications on two counts, please?
>> (1) If Sylvain wanted to have that appear at dir0/dir1/init not init,
>> would it have been sufficient to give that path twice (once for
>> <repository> and another for <path> parameter) to make things work as
>> expected?
>>
> git-submodule really requires two arguments:
>
> $ git submodule add <URL> <relative-path-to-module-in-tree>
>
> and supports two modes:
>
> 1) relative-path exists and is a valid repo: just add the module, it
> was created in tree, the user is expected to eventually push this to
> the given URL so other users will get this as normal. This exists to
> simplify the process of creating a repo to begin with.
>
> 2) relative-path doesn't exist: clone from the URL. This is the normal use.
> submodule supports adding a module in one of two ways:
>
> So,
>
> $ git submodule add dir0/dir1/init dir0/dir1/init
>
> will add the repo, but also makes the repo its own origin. I don't
> think this makes sense.
>> (2) Is it generally considered a sane use case to specify an existing
>> repository inside the working tree of a superproject as a submodule
>> using "git submodule add" like Sylvain's example did?
>>
>> I would have understood if the command were "git add dir0/dir1/init",
>> but I have this vague recolleciton that "git submodule add" is about
>> telling our repository about a submodule that comes from _outside_.
>>
>>
>>
> Adding an existing in-tree repo, ala
>
> $ git submodule add <intended-URL> <path>
>
> is there to ease the initial creation of a submodule. It can be
> created and registered in-tree, and later pushed to the server. This
> is sane, but is not the normal usage (makes sense only on creation).
Thanks.
The above is quite a bit more information than I can read from
Documentation/git-submodule.txt; care to send it in in a patch form?
^ permalink raw reply
* Re: uninstalling Git
From: Matthieu Moy @ 2008-07-08 6:28 UTC (permalink / raw)
To: Eric Hanchrow; +Cc: git
In-Reply-To: <87od59c58s.fsf@offby1.atm01.sea.blarg.net>
Eric Hanchrow <offby1@blarg.net> writes:
> * Failing that, I run
>
> find /usr -printf '%T@ ' -ls | sort -n | cut -d\ -f 2-
>
I usualy do
touch /tmp/dumb.txt
make install
find /usr -newer /tmp/dumb.txt
for that.
--
Matthieu
^ permalink raw reply
* What should "git branch --merged master" do?
From: Junio C Hamano @ 2008-07-08 6:49 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, Lars Hjemli
e8b404c (git-branch: add support for --merged and --no-merged, 2008-04-17)
introduced "git branch --merged" to show the branches that are contained
within the current HEAD. I.e. the ones that you can say "git branch -d"
and do not have to say "-D" to delete.
Currently "git branch --merged master" fails with a message:
fatal: A branch named 'master' already exists.
but --merged and its opposite --no-merged are in spirit very similar to
another option --contains in that it is meant to be used as a way to
influence which branches are _reported_, and not about creating a new
branch.
Perhaps we should change them to default to HEAD (to retain the current
behaviour) but take a commit, and show branches that are merged to the
commit or not yet fully merged to the commit, respectively?
Incidentally, "git branch --with" fails without the mandatory commit
argument, and if we are going to do the above, we probably should default
the argument to HEAD as well.
Here is an attempt to update --with but I am not happy with it.
The patch makes
$ git branch --contains
work as expected, but breaks
$ git branch --contains master
You need to spell "git branch --contains=master" instead. Which means it
is a regression and cannot be applied. I suspect I am not using
parse_options() in an optimal way, but I did not find a way for my
callback to tell "I consumed the next parameter and it was mine" or "The
next one is not my optional parameter" back to the parse_options(), so
probably parse_options() need to be fixed to update this without
regression, I suspect.
builtin-branch.c | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index d279702..ee722a2 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -411,7 +411,7 @@ static int opt_parse_with_commit(const struct option *opt, const char *arg, int
struct commit *commit;
if (!arg)
- return -1;
+ arg = "HEAD";
if (get_sha1(arg, sha1))
die("malformed object name %s", arg);
commit = lookup_commit_reference(sha1);
@@ -438,13 +438,15 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN( 0 , "color", &branch_use_color, "use colored output"),
OPT_SET_INT('r', NULL, &kinds, "act on remote-tracking branches",
REF_REMOTE_BRANCH),
- OPT_CALLBACK(0, "contains", &with_commit, "commit",
- "print only branches that contain the commit",
- opt_parse_with_commit),
+ {
+ OPTION_CALLBACK, 0, "contains", &with_commit, "commit",
+ "print only branches that contain the commit",
+ PARSE_OPT_OPTARG, opt_parse_with_commit,
+ },
{
OPTION_CALLBACK, 0, "with", &with_commit, "commit",
"print only branches that contain the commit",
- PARSE_OPT_HIDDEN, opt_parse_with_commit,
+ PARSE_OPT_HIDDEN | PARSE_OPT_OPTARG, opt_parse_with_commit,
},
OPT__ABBREV(&abbrev),
^ permalink raw reply related
* Re: Cloning marks pack for .keep
From: Teemu Likonen @ 2008-07-08 6:57 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Jean-Luc Herren, Junio C Hamano, Git Mailing List,
Daniel Barkalow
In-Reply-To: <20080708044606.GC2542@spearce.org>
Shawn O. Pearce wrote (2008-07-08 04:46 +0000):
> Jean-Luc Herren <jlh@gmx.ch> wrote:
> > After cloning a local repository with "git clone file://...", the
> > resulting repo had one big pack file, as expected, but also
> > a matching ".keep" file. Certainly this is a bug, isn't it? The
> > same happens if I clone git.git. I used git 1.5.6.1 but observed
> > the same with the current master. I bisected this behavior to
> > commit fa740529 by Shawn O. Pearce (CC'ing him). Since this dates
> > back to 2007, I wonder if maybe only I am seeing this, but I cannot
> > think of any reason for it.
>
> This is a known issue to me; I have been seeing this behavior myself
> since probably fa74 hit next. I just don't clone often so I've never
> thought about it much. ;-)
Earlier I noticed that this issue sometimes causes the repository to
grow pretty much after "git gc" because .keep packs are not touched.
This was discussed two months ago:
http://thread.gmane.org/gmane.comp.version-control.git/81856
I tend to think that .keep packs are not good idea at least for small
and medium sized repos. For _really_ big ones I'm not sure.
^ permalink raw reply
* Re: stgit error on status command
From: Karl Hasselström @ 2008-07-08 7:02 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List, Catalin Marinas
In-Reply-To: <9e4733910807070810i14c8856vfbec24127e711285@mail.gmail.com>
Thanks for the report.
The problem is that we mis-parse the output of git diff-index when
rename detection is on (and it prints more than one filename on one
line). This happens if you give stg status the --diff-opts=-M flag,
but you didn't -- but it could also happen if you have the
stgit.diff-opts config variable set.
I'll try to get a patch out tonight. In the mean time, if you like you
should be able to work around the problem by unsetting
stgit.diff-opts.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: J.H. @ 2008-07-08 7:20 UTC (permalink / raw)
To: Lea Wiemann
Cc: Jakub Narebski, git, Sam Vilain, Joshua Roys, Sverre Rabbelier,
Sverre Rabbelier, David Symonds, Marek Zawirski, Shawn O. Pearce,
Miklos Vajna, Johannes Schindelin, Stephan Beyer,
Christian Couder, Daniel Barkalow
In-Reply-To: <4872E858.4080607@gmail.com>
>From a quick an cursory glance I think we are well on track with the
Gitweb stuff (though I'll let Lea do a full status update). It looks
like most of the code is in place, and there is a test site up and
running on one of the kernel.org machines (though not anywhere near
production yet - I still need to port some of my other changes to Lea's
change set so we can try this out for real on Kernel.org)
- John 'Warthog9' Hawley
On Tue, 2008-07-08 at 06:08 +0200, Lea Wiemann wrote:
> Jakub Narebski wrote:
> > 3. Gitweb caching
>
> I'll post a complete status update in the next few days. And three
> large patches (including the mechanize test). ;-)
>
> > Lea has chosen caching data and memcached as primary caching engine,
> > and is working on object layer on top of Git.pm, namely Git::Repo and
> > friends, which will be used by gitweb. If I understand correctly
> > caching is to be done, or at least helped by this layer.
>
> That's correct, except that I'm not using Git.pm anywhere; Git::Repo is
> independent of Git.pm. More about that later...
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Jakub Narebski @ 2008-07-08 7:39 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Junio C Hamano, git, Christian Couder, Daniel Barkalow
In-Reply-To: <20080708014734.GE6726@leksak.fem-net>
On Tue, 8 July 2008, Stephan Beyer wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>>
>> I _really_ wanted to merge the basic bits and rewrite of "am" at least to
>> pu tonight, but I had to drop them after noticing that it does not seem to
>> handle --rebasing at all (it parses to set $rebasing but after that where
>> does that bit go?
>
> Yes, you are right that am --rebasing is a no-op.
> That option was a little mystery to me, because it seemed to do nothing
> special, but I'll check again (bash-completion etc) and do appropriate
> changes.
Undocumented option '--rebasing' to git-am is internal option changing
git-am behavior to be better used by git-rebase, namely it does not
change commit message even if it doesn't follow git commit message
convention, for example if it begins not with single line summary
of commit, separated by empty line, but by multi-line paragraph.
See also t/t3405-rebase-malformed.sh
Although I am not sure if when rebase is rewritten using git-sequencer
implementing "git am --rebasing" would be truly needed. On the other
hand side it would be nice to have some _documented_ option which would
allow to git-am mail messages with commits not following git commit
messages convention...
--
Jakub Narebski
Poland
^ 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