Re: Help on autocompletion not localized?
On Tue, Sep 11, 2018 at 2:55 PM Jean-Noël Avila wrote: > > Hi, > > > When invoking the autocompletion help with after a double > hyphen under zsh, the help list is not localized. I guess the help list > comes from some usage output of the on-going git command, but I wasn't > able to find where and how this happens (completion scripts are quite > hairy). I don't use zsh, but I guess that's because the help strings are hard coded in there (in English of course). You can start at __git_zsh_cmd_common() function. These strings are available (or at least possible to make them available) from 'git' binary, which should be translated. It's just a a matter of hooking up to zsh script. -- Duy
Re: Help with "fatal: unable to read ...." error during GC?
On Sat, Aug 11, 2018 at 4:25 PM Jeff King wrote: > > I do still have these warnings and no amount of git gc/git fsck/etc. > > has reduced them in any way: > > > > $ git gc > > warning: reflog of 'HEAD' references pruned commits > > warning: reflog of 'HEAD' references pruned commits > > warning: reflog of 'HEAD' references pruned commits > > warning: reflog of 'HEAD' references pruned commits > > warning: reflog of 'HEAD' references pruned commits > > warning: reflog of 'HEAD' references pruned commits > > warning: reflog of 'HEAD' references pruned commits > > warning: reflog of 'HEAD' references pruned commits > > I think these would go away via "reflog expire" (I'd have thought "git > gc" would do so, though). I wonder if this is yet another tool that > needs to be taught about worktree heads. You would need "reflog expire --expire-unreachable=now" because the default 30 days are probably too long for this case. And yes "reflog expire --all" needs to be aware of other heads (and other per-worktree refs in general). I'm pretty sure right now it only cares about the current worktree's head. -- Duy
Re: Help with "fatal: unable to read ...." error during GC?
On Sat, Aug 11, 2018 at 04:38:00PM +0200, Duy Nguyen wrote: > On Sat, Aug 11, 2018 at 4:25 PM Jeff King wrote: > > Responding myself and adding Duy to the cc to increase visibility among > > worktree experts. :) > > I do silently watch this thread (and yes I still have to fix that fsck > thing, hit a roadblock with ref names but I should really restart it > soon). Now you have found one more thing for me to do. Why Jeff why? > j/k :) I was actually thinking about doing it myself, but was worried that the refactoring might complicate things. And it sounds from the fact that you looked into it and hit a roadblock that it is more complicated than I thought. So I'll leave it for now, but I'm happy to review or discuss ideas. -Peff
Re: Help with "fatal: unable to read ...." error during GC?
On Sat, Aug 11, 2018 at 4:25 PM Jeff King wrote: > Responding myself and adding Duy to the cc to increase visibility among > worktree experts. :) I do silently watch this thread (and yes I still have to fix that fsck thing, hit a roadblock with ref names but I should really restart it soon). Now you have found one more thing for me to do. Why Jeff why? j/k -- Duy
Re: Help with "fatal: unable to read ...." error during GC?
On Sat, Aug 11, 2018 at 10:23:41AM -0400, Jeff King wrote:
> > I do still have these warnings and no amount of git gc/git fsck/etc.
> > has reduced them in any way:
> >
> > $ git gc
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
> > warning: reflog of 'HEAD' references pruned commits
>
> I think these would go away via "reflog expire" (I'd have thought "git
> gc" would do so, though). I wonder if this is yet another tool that
> needs to be taught about worktree heads.
>
> > I've run git gc --prune=all then git fsck reports only these dangling
> > commits:
> >
> > dangling commit cef0678a5e0765506e3fac41286696fd37a9b1e9
> > dangling commit 1729195f021a1b95ea8ca10b9c32e76bf2257e67
> > dangling commit 08385b9731291607a8c6d4bf10272002d8f31e1f
> > dangling commit c4ddfb2139eeb5a3c132dbfc84cc6e27fdeb46d1
> > dangling commit 1df8ebcc1cd5f59dd224ce1f3ba39f24370cf4e7
> >
> > (this is down from probably 50 or so "dangling ..." commits, blobs, and
> > trees before).
>
> I'd also expect "--prune=all" to drop all dangling heads. But I think
> this is the worktree thing, again. The code in fsck starts it
> connectivity check with this:
>
> if (head_points_at && !is_null_oid(&head_oid))
> fsck_handle_ref("HEAD", &head_oid, 0, NULL);
> for_each_rawref(fsck_handle_ref, NULL);
> if (include_reflogs)
> for_each_reflog(fsck_handle_reflog, NULL);
>
> but looking at the similar code in revision.c that has been upgraded to
> handle worktrees (e.g., add_reflogs_to_pending()), I think that is not
> going to look at worktree HEADs nor reflogs.
>
> I'd hoped to give you a one-liner to try out, but I think it will
> require some refactoring.
Responding myself and adding Duy to the cc to increase visibility among
worktree experts. :)
-Peff
Re: Help with "fatal: unable to read ...." error during GC?
On Sat, Aug 11, 2018 at 08:13:17AM -0400, Paul Smith wrote:
> I rebuilt Git 2.18.0 without optimization to try to get more debug
> information. Unfortunately I didn't think to create a backup of my
> problematic .git directory.
>
> When I ran the above command under the debugger using the non-optimized
> version of Git... it worked! That fixed the problem so that now when I
> run "git gc" using the original optimized version I no longer see the
> issue there either.
>
> So... clearly something is wrong but because I was dumb and didn't make
> a backup I can no longer reproduce the problem :(. On the other hand,
> my repository is no longer throwing errors so that's good.
Heh. Well, I would like to have known what the problem was. But if it
never happens again, we can go on with our lives. And if it does, then
we'll have another reproduction. :)
The fact that disabling optimizations changed things is worrisome. It
makes me wonder if this is somehow related to the struct-packing changes
in pack-objects. I don't know of any problems there, but in some
modifications to them post-v2.18, we had to deal with some race
conditions.
One alternative theory is that it wasn't the optimizations at all, but
rather the clock moving forward. The repack process cares about the
current time with respect to the mtime of the unreachable objects on
disk. It's possible that between yesterday and today, some objects
crossed the line to "too old to keep" (though from the earlier digging,
I'm not sure this is related to unreachable objects at all).
Thanks for your patience in digging into this, and please let us know if
you run into similar problems again.
> I do still have these warnings and no amount of git gc/git fsck/etc.
> has reduced them in any way:
>
> $ git gc
> warning: reflog of 'HEAD' references pruned commits
> warning: reflog of 'HEAD' references pruned commits
> warning: reflog of 'HEAD' references pruned commits
> warning: reflog of 'HEAD' references pruned commits
> warning: reflog of 'HEAD' references pruned commits
> warning: reflog of 'HEAD' references pruned commits
> warning: reflog of 'HEAD' references pruned commits
> warning: reflog of 'HEAD' references pruned commits
I think these would go away via "reflog expire" (I'd have thought "git
gc" would do so, though). I wonder if this is yet another tool that
needs to be taught about worktree heads.
> I've run git gc --prune=all then git fsck reports only these dangling
> commits:
>
> dangling commit cef0678a5e0765506e3fac41286696fd37a9b1e9
> dangling commit 1729195f021a1b95ea8ca10b9c32e76bf2257e67
> dangling commit 08385b9731291607a8c6d4bf10272002d8f31e1f
> dangling commit c4ddfb2139eeb5a3c132dbfc84cc6e27fdeb46d1
> dangling commit 1df8ebcc1cd5f59dd224ce1f3ba39f24370cf4e7
>
> (this is down from probably 50 or so "dangling ..." commits, blobs, and
> trees before).
I'd also expect "--prune=all" to drop all dangling heads. But I think
this is the worktree thing, again. The code in fsck starts it
connectivity check with this:
if (head_points_at && !is_null_oid(&head_oid))
fsck_handle_ref("HEAD", &head_oid, 0, NULL);
for_each_rawref(fsck_handle_ref, NULL);
if (include_reflogs)
for_each_reflog(fsck_handle_reflog, NULL);
but looking at the similar code in revision.c that has been upgraded to
handle worktrees (e.g., add_reflogs_to_pending()), I think that is not
going to look at worktree HEADs nor reflogs.
I'd hoped to give you a one-liner to try out, but I think it will
require some refactoring.
-Peff
Re: Help with "fatal: unable to read ...." error during GC?
On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote: > If so, can you try running it under gdb and getting a stack trace? > Something like: > > gdb git > [and then inside gdb...] > set args pack-objects --all --reflog --indexed-objects foobreak die > run > bt > > That might give us a clue where the broken object reference is coming > from. Oh no. I messed up :(. I rebuilt Git 2.18.0 without optimization to try to get more debug information. Unfortunately I didn't think to create a backup of my problematic .git directory. When I ran the above command under the debugger using the non-optimized version of Git... it worked! That fixed the problem so that now when I run "git gc" using the original optimized version I no longer see the issue there either. So... clearly something is wrong but because I was dumb and didn't make a backup I can no longer reproduce the problem :(. On the other hand, my repository is no longer throwing errors so that's good. I do still have these warnings and no amount of git gc/git fsck/etc. has reduced them in any way: $ git gc warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits Enumerating objects: 506556, done. Counting objects: 100% (506556/506556), done. Delta compression using up to 8 threads. Compressing objects: 100% (101199/101199), done. Writing objects: 100% (506556/506556), done. Total 506556 (delta 358957), reused 506556 (delta 358957) warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits Checking connectivity: 506556, done. I've run git gc --prune=all then git fsck reports only these dangling commits: dangling commit cef0678a5e0765506e3fac41286696fd37a9b1e9 dangling commit 1729195f021a1b95ea8ca10b9c32e76bf2257e67 dangling commit 08385b9731291607a8c6d4bf10272002d8f31e1f dangling commit c4ddfb2139eeb5a3c132dbfc84cc6e27fdeb46d1 dangling commit 1df8ebcc1cd5f59dd224ce1f3ba39f24370cf4e7 (this is down from probably 50 or so "dangling ..." commits, blobs, and trees before).
Re: Help with "fatal: unable to read ...." error during GC?
On Wed, Aug 08, 2018 at 10:45:49PM -0400, Paul Smith wrote:
> On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote:
> > If so, can you try running it under gdb and getting a stack trace?
> > Something like:
> >
> > gdb git
> > [and then inside gdb...]
> > set args pack-objects --all --reflog --indexed-objects foo > break die
> > run
> > bt
> >
> > That might give us a clue where the broken object reference is coming
>
> Here we go. I can rebuild with -Og or -O0 if more detailed debugging
> is needed; most everything appears to be optimized out:
No, I think this is enough to give a general sense of the problem
location.
> Compressing objects: 100% (10/10), done.
> Writing objects: 54% (274416/508176)
> Thread 1 "git" hit Breakpoint 1, die (err=err@entry=0x5a373a "unable to read
> %s") at usage.c:119
> 119 {
> (gdb) bt
> #0 die (err=err@entry=0x5a373a "unable to read %s") at usage.c:119
> #1 0x004563f3 in get_delta (entry=) at
> builtin/pack-objects.c:143
> #2 write_no_reuse_object () at builtin/pack-objects.c:308
> #3 0x00456592 in write_reuse_object (usable_delta=,
> limit=, entry=, f=) at
> builtin/pack-objects.c:516
> #4 write_object (write_offset=, entry=0x7fffc9a8d940,
> f=0x198fb70) at builtin/pack-objects.c:518
> #5 write_one () at builtin/pack-objects.c:576
> #6 0x004592f0 in write_pack_file () at builtin/pack-objects.c:849
> #7 cmd_pack_objects (argc=, argv=,
> prefix=) at builtin/pack-objects.c:3354
> #8 0x00404f06 in run_builtin (argv=, argc= out>, p=) at git.c:417
> #9 handle_builtin (argc=, argv=) at git.c:632
> #10 0x00405f21 in run_argv (argv=0x7fffe210,
> argcp=0x7fffe21c) at git.c:761
> #11 cmd_main (argc=, argc@entry=6, argv=,
> argv@entry=0x7fffe448) at git.c:761
> #12 0x00404b15 in main (argc=6, argv=0x7fffe448) at
> common-main.c:45
So that's quite unexpected. I assumed we'd have hit this problem while
deciding _which_ objects to write. But we get all the way to the point
of writing out the result before we notice it's missing.
I don't think I've run such a case before, but I wonder if "pack-objects
--all" is too lax about adding missing blobs during its object traversal
(especially during the "unreachable but recent" part of the traversal
that I mentioned, which should silently omit missing objects). I played
around with recreating this situation, though, and I don't think it's
possible to cause the results you're seeing. We come up with a list of
recent objects, but we only use it as a look-up index for discarding
too-old objects. So:
- it wouldn't ever cause us to choose to write an object into a pack,
which is what you're seeing
- we'd never consider a missing object; it's a pure lookup table, and
the actual list of objects we consider is found by walking the set
of packs
So that's probably a dead end.
What I really wonder is where we found out about that object name in the
first place. Can you instrument your Git build like this:
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index 71056d8294..5ff6de5ddf 100644
--- a/builtin/pack-objects.c
+++ b/builtin/pack-objects.c
@@ -1112,6 +1112,13 @@ static int add_object_entry(const struct object_id *oid,
enum object_type type,
struct packed_git *found_pack = NULL;
off_t found_offset = 0;
uint32_t index_pos;
+ static const struct object_id funny_oid = {
+ "\xc1\x04\xb8\xfb\x36\x31\xb5\xc5\x46\x95"
+ "\x20\x6b\x2f\x73\x31\x0c\x02\x3c\x99\x63"
+ };
+
+ if (!oidcmp(oid, &funny_oid))
+ warning("found funny oid");
display_progress(progress_state, ++nr_seen);
and similarly get a backtrace when we hit that warning()? (Or if you're
a gdb expert, you could probably use a conditional breakpoint, but I
find just modifying the source easier).
-Peff
Re: Help with "fatal: unable to read ...." error during GC?
On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote:
> If so, can you try running it under gdb and getting a stack trace?
> Something like:
>
> gdb git
> [and then inside gdb...]
> set args pack-objects --all --reflog --indexed-objects foobreak die
> run
> bt
>
> That might give us a clue where the broken object reference is coming
Here we go. I can rebuild with -Og or -O0 if more detailed debugging
is needed; most everything appears to be optimized out:
...
Compressing objects: 100% (10/10), done.
Writing objects: 54% (274416/508176)
Thread 1 "git" hit Breakpoint 1, die (err=err@entry=0x5a373a "unable to read
%s") at usage.c:119
119 {
(gdb) bt
#0 die (err=err@entry=0x5a373a "unable to read %s") at usage.c:119
#1 0x004563f3 in get_delta (entry=) at
builtin/pack-objects.c:143
#2 write_no_reuse_object () at builtin/pack-objects.c:308
#3 0x00456592 in write_reuse_object (usable_delta=,
limit=, entry=, f=) at
builtin/pack-objects.c:516
#4 write_object (write_offset=, entry=0x7fffc9a8d940,
f=0x198fb70) at builtin/pack-objects.c:518
#5 write_one () at builtin/pack-objects.c:576
#6 0x004592f0 in write_pack_file () at builtin/pack-objects.c:849
#7 cmd_pack_objects (argc=, argv=,
prefix=) at builtin/pack-objects.c:3354
#8 0x00404f06 in run_builtin (argv=, argc=, p=) at git.c:417
#9 handle_builtin (argc=, argv=) at git.c:632
#10 0x00405f21 in run_argv (argv=0x7fffe210, argcp=0x7fffe21c)
at git.c:761
#11 cmd_main (argc=, argc@entry=6, argv=,
argv@entry=0x7fffe448) at git.c:761
#12 0x00404b15 in main (argc=6, argv=0x7fffe448) at common-main.c:45
Re: Help with "fatal: unable to read ...." error during GC?
On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote: > Let's narrow it down first and make sure we're dying where I expect. > Can > you try: > > GIT_TRACE=1 git gc > > and confirm the program running when the fatal error is produced? > > From what you've shown it's going to be git-repack, but what I'm not > clear on is whether it is repack itself that is complaining, or the > pack-objects process it spawns. I'd guess the latter. You are correct: 15:27:24.264161 git.c:415 trace: built-in: git pack- objects --keep-true-parents --honor-pack-keep --non-empty --all -- reflog --indexed-objects --unpack-unreachable=2.weeks.ago --local -- delta-base-offset .git/objects/pack/.tmp-17617-pack > If so, can you try running it under gdb and getting a stack trace? I would... but I discovered all my Git binaries are stripped to the max and no symbols available. I'll do a quick rebuild with some debug info and get back to you. Thanks for the pointers!
Re: Help with "fatal: unable to read ...." error during GC?
On Wed, Aug 08, 2018 at 01:35:30PM -0400, Paul Smith wrote: > Thanks for the note! Unhappily for me none of these operations seem to > find any actionable problems... > [...] Drat. One other option is that it _could_ be related to the "old unreachable objects that are reachable from recent unreachable objects should be kept" code. That's supposed to quietly ignore broken links in unreachable objects, but there could be a bug. Let's narrow it down first and make sure we're dying where I expect. Can you try: GIT_TRACE=1 git gc and confirm the program running when the fatal error is produced? >From what you've shown it's going to be git-repack, but what I'm not clear on is whether it is repack itself that is complaining, or the pack-objects process it spawns. I'd guess the latter. If so, can you try running it under gdb and getting a stack trace? Something like: gdb git [and then inside gdb...] set args pack-objects --all --reflog --indexed-objects foo
Re: Help with "fatal: unable to read ...." error during GC?
On Wed, 2018-08-08 at 12:06 -0400, Jeff King wrote: > I'd have expected fsck to find it, too. However, looking at the code, > I'm not convinced that fsck is actually considering detached worktree > heads properly, either. Try: > > git rev-list --all --reflog --objects >/dev/null > > which I know checks worktrees correctly. I'd expect that to fail. > > If it does, then we need to narrow down which worktree is corrupt. > Perhaps something like: > > git worktree list | > while read worktree head junk; do > git rev-list --objects $head >/dev/null || > echo "$worktree seems corrupt" > done Thanks for the note! Unhappily for me none of these operations seem to find any actionable problems... $ git rev-list --all --reflog --objects >/dev/null warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits warning: reflog of 'HEAD' references pruned commits $ echo $? 0 $ git worktree list | while read wt head junk; do \ git rev-list --objects $head >/dev/null || echo "$wt seems corrupt"; \ done $ Just to be sure I updated the loop above to echo $wt and $head and they were correct. I also re-ran git gc after the above and still got the original error output so it didn't magically fix itself :).
Re: Help with "fatal: unable to read ...." error during GC?
On Wed, Aug 08, 2018 at 10:30:11AM -0400, Paul Smith wrote: > I recently upgraded from Git 2.9.2 to 2.18.0 (note, I have no > particular reason to believe this is related just passing info). I'm > running on Linux (64bit Ubuntu 18.04.1 but I've compiled Git myself > from source, I'm not using the distro version). > > I have a local repository I've been using for about two years (the > .git/description file, which I don't use, has a TLM of July 31, 2016), > with lots of worktrees being created/pruned/etc. during that time. > > Note I'm doing all these operations in the 'main' repository, not in > any of the worktrees. Hrm, there was a pretty serious corruption bug in early versions of the worktree code (IIRC, pruning would not consider detached HEADs from other worktrees, and could drop that object). > Yesterday, when I tried to fetch from my upstream I got a notification > about GC needed. Then GC failed with these errors (HEAD is set to > master which is the same as origin/master): > > warning: reflog of 'HEAD' references pruned commits > warning: reflog of 'HEAD' references pruned commits > warning: reflog of 'HEAD' references pruned commits > warning: reflog of 'HEAD' references pruned commits > warning: reflog of 'HEAD' references pruned commits > warning: reflog of 'HEAD' references pruned commits > warning: reflog of 'HEAD' references pruned commits > warning: reflog of 'HEAD' references pruned commits > warning: reflog of 'HEAD' references pruned commits > warning: reflog of 'HEAD' references pruned commits > fatal: unable to read c104b8fb3631b5c54695206b2f73310c023c9963 > error: failed to run repack So that definitely looks like the corruption I'd expect from the worktree bug, but... > I ran a git fsck --full which showed me a lot of dangling commits and > blobs, but no errors, no broken link messages, etc. I'd have expected fsck to find it, too. However, looking at the code, I'm not convinced that fsck is actually considering detached worktree heads properly, either. Try: git rev-list --all --reflog --objects >/dev/null which I know checks worktrees correctly. I'd expect that to fail. If it does, then we need to narrow down which worktree is corrupt. Perhaps something like: git worktree list | while read worktree head junk; do git rev-list --objects $head >/dev/null || echo "$worktree seems corrupt" done > I can't find that SHA anywhere: I looked in .git/objects, etc. I also > can't find any problems with my repo; obviously I haven't checked > everything but I can show the git log back to the initial commit, all > my stashes look fine, all my worktrees seem to be OK (git status etc. > work fine in all of them). "git status" might succeed if the corruption is further back in the history. > I would hate to have to throw this setup away since it has 23 stashes > and 25 worktrees in various states that would be annoying to have to > recreate... Definitely don't throw it away. I suspect you have a single corrupt worktree, and everything else is fine. -Peff
Re: Help...!
On Fri, Mar 16, 2018 at 07:38:07PM +0530, JYOTIK MAYUR wrote: > i am working on a project that is git hosting website like GitHub. I > am a student so i don't know much on how to make a website like GitHub > so could please tell me what can be the appropriate steps to make a > website like that(mostly the server part). Sure, just study the code of the following projects: - Go: https://gitea.io/ - C#: https://bonobogitserver.com/ - Java: http://gitblit.com/ Still, please note that this list deals with the development of Git, so your question clearly is off-topic here, so please refrain from asking such questions here. You could try https://www.reddit.com/r/git/ for a start.
Re: Help
Hi, On Thu, Sep 28, 2017 at 3:21 AM, Nityananda wrote: > Hello, > I am new to this community. I am facing a problem while using the > "make" command inside the "t/" folder. > > The error is > > > "1..31 > Makefile:49: recipe for target 't5551-http-fetch-smart.sh' failed > make[1]: *** [t5551-http-fetch-smart.sh] Error 1 > make[1]: Leaving directory '/home/nitya/projects/git/t' > Makefile:36: recipe for target 'test' failed > make: *** [test] Error 2" Could you try running "./t5551-http-fetch-smart.sh -v -i" to get more information about the failing test?
Re: Help needed for solving a few issues with building git
On Wed, 2017-07-05 at 01:30 +0530, Kaartic Sivaraam wrote: > I tried pointing it to the installed location, it doesn't seem to be > working. To elaborate a little on what I did, > > * I installed the "libcurl4-openssl-dev" package b > * I found that the 'include' directory to be present at > '/usr/include/x86_64-linux-gnu/curl'. I wasn't sure if > '/usr/lib/x86_64-linux-gnu/' is the corresponding library > directory. > * I took the common parent of both '/usr' and ran the > following > commands to build 'git' > > $ make CURLDIR=/usr prefix=/custom/location > $ make CURLDIR=/usr install prefix=/custom/location > > * The build did succeed but I get an error that "'https' > helper > is not found" > > Was anything I did, wrong? > Ok, at last I was able to build git with https support using 'curl' built from it's source. Anyways, thanks for the help, folks. > > This is probably because you are trying to run without installing? > > Nope. I'm *installing* git not using the binary wrappers. > > > Ask the "git" you built what its --exec-path is, and run "ls" on > > that directory to see if you have git-remote-https installed? > > > > Obviously, I don't see any 'git-remote-https' binary in the folder to > which I built git. > > > Trying a freshly built Git binaries without installing is done by > > setting GIT_EXEC_PATH to point at bin-wrappers/ directory at the > > top-level of your build tree (that is how our tests can run on an > > otherwise virgin box with no Git installed). > > >
Re: Help needed for solving a few issues with building git
On Mon, 2017-07-03 at 11:13 -0700, Junio C Hamano wrote: > Adding HTTPS support > > > > > > I tried to add HTTP/HTTPS support to the custom built version > > > for which > > > AFAIK 'git' depends on 'curl'. I tried providing the location > > > of the > > > curl source in the Makefile using the following line after > > > reading the > > > instructions in the Makefile. > > > > > > CURLDIR=/path/to/curl/source > > > Shouldn't this point at an installed location (iow, we do not build > curl from the source while building Git)? > > # Define CURLDIR=/foo/bar if your curl header and library files > are in > # /foo/bar/include and /foo/bar/lib directories. I tried pointing it to the installed location, it doesn't seem to be working. To elaborate a little on what I did, * I installed the "libcurl4-openssl-dev" package b * I found that the 'include' directory to be present at '/usr/include/x86_64-linux-gnu/curl'. I wasn't sure if '/usr/lib/x86_64-linux-gnu/' is the corresponding library directory. * I took the common parent of both '/usr' and ran the following commands to build 'git' $ make CURLDIR=/usr prefix=/custom/location $ make CURLDIR=/usr install prefix=/custom/location * The build did succeed but I get an error that "'https' helper is not found" Was anything I did, wrong? > This is probably because you are trying to run without installing? Nope. I'm *installing* git not using the binary wrappers. > Ask the "git" you built what its --exec-path is, and run "ls" on > that directory to see if you have git-remote-https installed? > Obviously, I don't see any 'git-remote-https' binary in the folder to which I built git. > Trying a freshly built Git binaries without installing is done by > setting GIT_EXEC_PATH to point at bin-wrappers/ directory at the > top-level of your build tree (that is how our tests can run on an > otherwise virgin box with no Git installed). > On Mon, 2017-07-03 at 13:11 -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > $ make NO_GETTEXT=1 NO_MSGFMT=1 > > may help. > Ok, I seem to have crapped a little. It seems following the intructions in the Makefile blindly led to this issue. Reading the instruction "Define NO_GETTEXT if you don't want Git output to be translated.", I defined NO_GETTEXT=1 in the Makefile itself! (as specified in the previous thread) I'm able to build git without localization support by using the following command, make NO_GETTEXT=1 prefix=/custom/location > NO_GETTEXT is "My build environment may or may not be capable of > doing the gettext things, but I choose not to use it in my build > result" but NO_MSGFMT is simply "I do not have the msgfmt tool". > > Having to specify both is rather unfortunate and we may want to > streamline this. I guess it's not required! -- Kaartic
Re: Help needed for solving a few issues with building git
Junio C Hamano writes: >> While trying to build (without the 'gettext' library that's required >> for localization) I get the following error, >> >> Manifying 8 pod documents >> SUBDIR templates >> MSGFMT po/build/locale/pt_PT/LC_MESSAGES/git.mo >> /bin/sh: 1: msgfmt: not found >> Makefile:2179: recipe for target >> 'po/build/locale/pt_PT/LC_MESSAGES/git.mo' failed >> make: *** [po/build/locale/pt_PT/LC_MESSAGES/git.mo] Error 127 >> >> What could I be missing? > > There is > > ifndef NO_GETTEXT > all:: $(MOFILES) > endif > > which attempts to avoid generating *.mo files, but that does not > seem to be working. The above comes from one of the Tcl things (probably gitk-git) For now $ make NO_GETTEXT=1 NO_MSGFMT=1 may help. NO_GETTEXT is "My build environment may or may not be capable of doing the gettext things, but I choose not to use it in my build result" but NO_MSGFMT is simply "I do not have the msgfmt tool". Having to specify both is rather unfortunate and we may want to streamline this.
Re: Help needed for solving a few issues with building git
Kaartic Sivaraam writes: > Hello all, > > Building without localization support > > I tried to build git from source without localization support by adding > the following line to the Makefile, > > NO_GETTEXT=1 > > It doesn't seem to be working for reasons I'm unable to find. I used > the following commands to build git. > > make prefix=$CUSTOM_BUILD_LOCATION > make install prefix=$CUSTOM_BUILD_LOCATION > > While trying to build (without the 'gettext' library that's required > for localization) I get the following error, > > Manifying 8 pod documents > SUBDIR templates > MSGFMT po/build/locale/pt_PT/LC_MESSAGES/git.mo > /bin/sh: 1: msgfmt: not found > Makefile:2179: recipe for target > 'po/build/locale/pt_PT/LC_MESSAGES/git.mo' failed > make: *** [po/build/locale/pt_PT/LC_MESSAGES/git.mo] Error 127 > > What could I be missing? There is ifndef NO_GETTEXT all:: $(MOFILES) endif which attempts to avoid generating *.mo files, but that does not seem to be working. > > > Adding HTTPS support > > I tried to add HTTP/HTTPS support to the custom built version for which > AFAIK 'git' depends on 'curl'. I tried providing the location of the > curl source in the Makefile using the following line after reading the > instructions in the Makefile. > > CURLDIR=/path/to/curl/source Shouldn't this point at an installed location (iow, we do not build curl from the source while building Git)? # Define CURLDIR=/foo/bar if your curl header and library files are in # /foo/bar/include and /foo/bar/lib directories. > Even after doing this the custom built git errors with the following > message when I try to use the 'git fetch' command, > > fatal: Unable to find remote helper for 'https' This is probably because you are trying to run without installing? Ask the "git" you built what its --exec-path is, and run "ls" on that directory to see if you have git-remote-https installed? Trying a freshly built Git binaries without installing is done by setting GIT_EXEC_PATH to point at bin-wrappers/ directory at the top-level of your build tree (that is how our tests can run on an otherwise virgin box with no Git installed).
Re: Help needed for solving a few issues with building git
On 2017-07-03 15:18, Kaartic Sivaraam wrote: > Hello all, > > Building without localization support > > I tried to build git from source without localization support by adding > the following line to the Makefile, > > NO_GETTEXT=1 > May be make NO_GETTEXT=yes
Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
Hi Peff, On Thu, 3 Nov 2016, Jeff King wrote: > On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote: > > > This is missing a Content-Transfer-Encoding. I think the default is the > > traditional 7-bit ascii encoding, but your body has characters with the > > high-bit set (your UTF-8 bullet). > > > > Try adding: > > > > Content-Transfer-Encoding: 8bit > > > > I haven't seen this before, but I do recall that vger's MTA is very > > picky about this and wants to rewrite transfer-encodings, so it seems > > plausible. > > Technically, I think you'd also need a: > > MIME-Version: 1.0 > > header. That seems to have done the trick, thank you so much! Ciao, Dscho
Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
On Thu, Nov 03, 2016 at 11:38:45AM -0400, Jeff King wrote:
> On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote:
>
> > This is missing a Content-Transfer-Encoding. I think the default is the
> > traditional 7-bit ascii encoding, but your body has characters with the
> > high-bit set (your UTF-8 bullet).
> >
> > Try adding:
> >
> > Content-Transfer-Encoding: 8bit
> >
> > I haven't seen this before, but I do recall that vger's MTA is very
> > picky about this and wants to rewrite transfer-encodings, so it seems
> > plausible.
>
> Technically, I think you'd also need a:
>
> MIME-Version: 1.0
>
> header. That being said, I just peeked at the send-email code and it
> looks like we try to add in these headers as necessary. It's possible
> there's a bug, though. What does "git send-email --dry-run" say is in
> the headers it sends out?
Answering my own question, it looks like send-email gets confused when
you give a content-type but no content-transfer-encoding. It wants to
fill in both or neither.
This probably helps:
diff --git a/git-send-email.perl b/git-send-email.perl
index da81be40c..784bb874b 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1568,11 +1568,13 @@ foreach my $t (@files) {
push @cc, recipients_cmd("cc-cmd", "cc", $cc_cmd, $t)
if defined $cc_cmd && !$suppress_cc{'cccmd'};
- if ($broken_encoding{$t} && !$has_content_type) {
+ if ($broken_encoding{$t}) {
$xfer_encoding = '8bit' if not defined $xfer_encoding;
- $has_content_type = 1;
- push @xh, "Content-Type: text/plain;
charset=$auto_8bit_encoding";
- $body_encoding = $auto_8bit_encoding;
+ if (!$has_content_type) {
+ $has_content_type = 1;
+ push @xh, "Content-Type: text/plain;
charset=$auto_8bit_encoding";
+ $body_encoding = $auto_8bit_encoding;
+ }
}
if ($broken_encoding{$t} && !is_rfc2047_quoted($subject)) {
but I think there is more cleanup to handle this case (e.g., it
auto-guesses utf-8, but it should pull the value from the existing
content-type header).
-Peff
Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
On Thu, Nov 03, 2016 at 11:34:53AM -0400, Jeff King wrote: > This is missing a Content-Transfer-Encoding. I think the default is the > traditional 7-bit ascii encoding, but your body has characters with the > high-bit set (your UTF-8 bullet). > > Try adding: > > Content-Transfer-Encoding: 8bit > > I haven't seen this before, but I do recall that vger's MTA is very > picky about this and wants to rewrite transfer-encodings, so it seems > plausible. Technically, I think you'd also need a: MIME-Version: 1.0 header. That being said, I just peeked at the send-email code and it looks like we try to add in these headers as necessary. It's possible there's a bug, though. What does "git send-email --dry-run" say is in the headers it sends out? -Peff
Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
On Thu, Nov 03, 2016 at 04:15:05PM +0100, Johannes Schindelin wrote: > When it finally sent out the mail, and I thought everything was alright, > thinking that I could turn out for the night with a well-deserved drink, I > got this from vger.kernel.org: > > -- snip -- > SMTP error from remote server for TEXT command, host: vger.kernel.org > (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong MIME > labeling on 8-bit character texts. > -- snap -- > > Is there *anybody* who could give me a clue what this means? That's a new one for me. One guess, though... > For the record, I tried to use `git send-email` to send out the > announcement for the very first time, and the headers of the mbox file I > fed to that command read thusly: > > -- snip -- > From 2.10.2.windows.1 Mon Sep 17 00:00:00 2001 > From: Johannes Schindelin > Date: Wed, 02 Nov 2016 21:43:54 +0100 > To: git-for-wind...@googlegroups.com, git@vger.kernel.org > Subject: [ANNOUNCE] Git for Windows 2.10.2 > Content-Type: text/plain; charset=UTF-8 > Fcc: Sent > -- snap -- This is missing a Content-Transfer-Encoding. I think the default is the traditional 7-bit ascii encoding, but your body has characters with the high-bit set (your UTF-8 bullet). Try adding: Content-Transfer-Encoding: 8bit I haven't seen this before, but I do recall that vger's MTA is very picky about this and wants to rewrite transfer-encodings, so it seems plausible. -Peff
Re: Help with vger's rules, was Re: [ANNOUNCE] Git for Windows 2.10.2
Johannes Schindelin writes: > thinking that I could turn out for the night with a well-deserved drink, I > got this from vger.kernel.org: > > -- snip -- > SMTP error from remote server for TEXT command, host: vger.kernel.org > (209.132.180.67) reason: 550 5.7.1 Content-Policy reject msg: Wrong MIME > labeling on 8-bit character texts. > -- snap -- > > Is there *anybody* who could give me a clue what this means? Have you tried postmaster (at vger.kernel.org)? > > For the record, I tried to use `git send-email` to send out the > announcement for the very first time, and the headers of the mbox file I > fed to that command read thusly: > > -- snip -- > From 2.10.2.windows.1 Mon Sep 17 00:00:00 2001 > From: Johannes Schindelin > Date: Wed, 02 Nov 2016 21:43:54 +0100 > To: git-for-wind...@googlegroups.com, git@vger.kernel.org > Subject: [ANNOUNCE] Git for Windows 2.10.2 > Content-Type: text/plain; charset=UTF-8 > Fcc: Sent > -- snap -- > > The only problem I could *possibly* imagine is this UTF-8 bullet character > used in the enumerations in the mail body: > >• [...] The above header you showed says "Content-type: text/plain; charset=UTF-8" and I am hoping that this response to you will go out with that labelling back to vger, so we will hopefully see if that bullet is the culprit (I doubt it, though). I have no specific suspect at this point yet, other than "somebody that gets your message from send-email and passes to vger may be mangling it".
Re: Help debugging git-svn
On Fri, Dec 18, 2015 at 11:28 AM, Edmundo Carmona Antoranz wrote: > Ok I came up with another idea to avoid having to deal with the > old svn history (I'm having no problems fetching/dcommitting with my > current repo). I already have the branches I work with, the thing is > that the revisions I fetched before I started using the svn authors > file have nasty IDs instead of human names. I though that I could > create a script to rewrite the whole history of the project adjusting > the usernames to real names (I'll take care of the details, no problem > there... just found out about filter-branch, could work for what I'm > thinking of). My question would be in the direction of rebuilding > git-svn metainfo once I'm done so that I can continue fetching from > svn as if nothing had happened. I checked the documentation in > git-scm.com but didn't find the details about it. Is there a > straight-forward document that explains how the git-svn metadata files > are built? > > Thanks in advance. .rev_map files appear to be simple enough. I'll have fun with them a little bit. Will let you know how it goes later (don't hold your breath it might take a while). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help debugging git-svn
Ok I came up with another idea to avoid having to deal with the old svn history (I'm having no problems fetching/dcommitting with my current repo). I already have the branches I work with, the thing is that the revisions I fetched before I started using the svn authors file have nasty IDs instead of human names. I though that I could create a script to rewrite the whole history of the project adjusting the usernames to real names (I'll take care of the details, no problem there... just found out about filter-branch, could work for what I'm thinking of). My question would be in the direction of rebuilding git-svn metainfo once I'm done so that I can continue fetching from svn as if nothing had happened. I checked the documentation in git-scm.com but didn't find the details about it. Is there a straight-forward document that explains how the git-svn metadata files are built? Thanks in advance. On Wed, Dec 16, 2015 at 6:36 AM, Edmundo Carmona Antoranz wrote: > On Wed, Dec 16, 2015 at 1:41 AM, Eric Wong wrote: >> >> Any chance you can reproduce this on a Linux system? >> I do not use non-Free systems and have no debugging experience >> there at all. >> > > My wish But it's a big resounding "no". > >>> With my very flawed knowledge of perl I have seen that the process is >>> getting to Ra.pm around here: >> >> It could also be a bug in the SVN bindings or the port of >> Perl. Which versions are you running? > > I'm working on git for windows 2.6.3. I think I could use cygwin, just > in case (I used it before). > >> >> >> I've also been wondering about the motivation of SVN developers to do a >> good job on maintaining their Perl bindings (given git-svn is likely the >> main user of them). >> We've certainly had problems in the past with SVN breaking and >> causing git-svn to segfault around 2011-2012; but it's been a while... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help debugging git-svn
On Wed, Dec 16, 2015 at 1:41 AM, Eric Wong wrote: > > Any chance you can reproduce this on a Linux system? > I do not use non-Free systems and have no debugging experience > there at all. > My wish But it's a big resounding "no". >> With my very flawed knowledge of perl I have seen that the process is >> getting to Ra.pm around here: > > It could also be a bug in the SVN bindings or the port of > Perl. Which versions are you running? I'm working on git for windows 2.6.3. I think I could use cygwin, just in case (I used it before). > > > I've also been wondering about the motivation of SVN developers to do a > good job on maintaining their Perl bindings (given git-svn is likely the > main user of them). > We've certainly had problems in the past with SVN breaking and > causing git-svn to segfault around 2011-2012; but it's been a while... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help debugging git-svn
Edmundo Carmona Antoranz wrote: > 1 [main] perl 5652 cygwin_exception::open_stackdumpfile: Dumping stack > trace to perl.exe.stackdump > > And then, in the file: > > Exception: STATUS_ACCESS_VIOLATION at rip=0048360C10C > rax=000601E4BFF8 rbx=5219E248 rcx=00060003A590 > rdx= rsi=A950 rdi=0004 > r8 = r9 = r10=0023 > r11=00048D78607A r12=0003 r13=06F54A98 > r14=000601E18030 r15=06F54AB0 > rbp=00054A88 rsp=0022B810 > program=C:\Program Files\Git\usr\bin\perl.exe, pid 5652, thread main > cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B Any chance you can reproduce this on a Linux system? I do not use non-Free systems and have no debugging experience there at all. > With my very flawed knowledge of perl I have seen that the process is > getting to Ra.pm around here: It could also be a bug in the SVN bindings or the port of Perl. Which versions are you running? I've also been wondering about the motivation of SVN developers to do a good job on maintaining their Perl bindings (given git-svn is likely the main user of them). We've certainly had problems in the past with SVN breaking and causing git-svn to segfault around 2011-2012; but it's been a while... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with Getting started to Contribute
karthik nayak writes: > There is also Junio's Blog where he keeps a list of things to be done > > http://git-blame.blogspot.de/p/leftover-bits.html I'd add this: https://git.wiki.kernel.org/index.php/SmallProjectsIdeas -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with Getting started to Contribute
Hello Tummala, On 04/28/2015 07:15 PM, Tummala Dhanvi wrote: Hi , I would like to contribute to git. Can you guys point me to some useful resources to get me started to contribute to git. I suggest you go through the Documentation, especially "Documentation/CodingGuidelines" and "Documentation/SubmittingPatches" to get an idea of the workflow and guidelines for contributing to Git. Also does git have something like junior jobs so that It can be done by new to contribution. All issues and bugs are discussed on the mailing list, so keep going through the list for potential problems. There is also Junio's Blog where he keeps a list of things to be done http://git-blame.blogspot.de/p/leftover-bits.html You could pick something from there and work on that. Have Fun. Regards, Karthik Also searching about the git in google points to some other organisation which uses git :((well this is because of the popularity of the git) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help needed: Tests failed While replacing char array with strbuf in bulk-checkin.c
On Mon, Mar 3, 2014 at 4:11 PM, saikrishna.sripada wrote: > I am trying do complete the microproject 4, inorder to apply to GSOC. > I have made the below changes: > > https://gist.github.com/anhsirksai/9334565 > > Post my changes compilation is succes in the source directory. > But when I ran the tests[make in t/ directory] my tests are failing saying > > " > free(): invalid pointer: 0x3630376532353636 *** > === Backtrace: = > /lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x2b5f3b540b96] > /home/saikrishna/Desktop/libcloud-0.14.1/sai/git/git[0x4fb829] > /home/saikrishna/Desktop/libcloud-0.14.1/sai/git/git[0x47d425] > /home/saikrishna/Desktop/libcloud-0.14.1/sai/git/git[0x4064ad] > /home/saikrishna/Desktop/libcloud-0.14.1/sai/git/git[0x405a04] > /home/saikrishna/Desktop/libcloud-0.14.1/sai/git/git[0x404cbd] > /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x2b5f3b4e376d] > /home/saikrishna/Desktop/libcloud-0.14.1/sai/git/git[0x405109] > " > > Can some one please help me with the memory allacation and strbuf_release() Read the microproject text carefully and _fully_. It provides the clue you need to understand the problem. Rewrite bulk-checkin.c:finish_bulk_checkin() to use a strbuf for handling packname, and explain why this is useful. Also check if the first argument of pack-write.c:finish_tmp_packfile() can be made const. If, after making a closer examination of the mentioned functions, the problem still eludes you, ask here again. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Thu, Oct 31, 2013 at 3:41 PM, Junio C Hamano wrote:
> Eugene Sajine writes:
>
>> One note: i tried the ${GIT_PREFIX:-.} and ${GIT_PREFIX} and it seems
>> to give the same results. What is the expected difference here?
>
> GIT_PREFIX may be an empty string when you run from the top-level,
> in which case you would end up with "cd && ..." and end up working
> in your $HOME.
>
got it! thank you!
Eugene
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
Eugene Sajine writes:
> One note: i tried the ${GIT_PREFIX:-.} and ${GIT_PREFIX} and it seems
> to give the same results. What is the expected difference here?
GIT_PREFIX may be an empty string when you run from the top-level,
in which case you would end up with "cd && ..." and end up working
in your $HOME.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Thu, Oct 31, 2013 at 2:15 PM, David Aguilar wrote:
> On Thu, Oct 31, 2013 at 11:07:19AM -0700, Junio C Hamano wrote:
>> David Aguilar writes:
>>
>> > A-ha.. I think adding the chdir to alias is possible using a function.
>>
>> You do not have to use a function to do so, no?
>
> Right, of course.
>
> So something like:
>
> [alias]
> example = "!cd ${GIT_PREFIX:-.} && git log \"$@\""
>
> should do the trick.
> --
> David
Awesome! It does work!
One note: i tried the ${GIT_PREFIX:-.} and ${GIT_PREFIX} and it seems
to give the same results. What is the expected difference here?
Thank you!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Thu, Oct 31, 2013 at 11:07:19AM -0700, Junio C Hamano wrote:
> David Aguilar writes:
>
> > A-ha.. I think adding the chdir to alias is possible using a function.
>
> You do not have to use a function to do so, no?
Right, of course.
So something like:
[alias]
example = "!cd ${GIT_PREFIX:-.} && git log \"$@\""
should do the trick.
--
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
David Aguilar writes: > A-ha.. I think adding the chdir to alias is possible using a function. You do not have to use a function to do so, no? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Thu, Oct 31, 2013 at 11:36:59AM -0400, Eugene Sajine wrote:
> On Wed, Oct 30, 2013 at 11:54 PM, Junio C Hamano wrote:
> > Eugene Sajine writes:
> >
> >> That was my initial intention, because I would like to be able to pass
> >> parameters like to git log or git blame correctly without the explicit
> >> use of $1. Could you please advise about how to make it work with the
> >> !sh -c ?
> >>
> >> Because the same exact (sed 's/@\\S*//') syntax didn't work with "sh -c".
> >
> > You can make it work if you think step-by-step. First, this is what
> > you want to run:
> >
> > sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' -
> >
> > so that "git euguess master..next" would turn into
> >
> > sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' - master..next
> >
> > Now, you want to wrap it into an alias, i.e.
> >
> > [alias]
> > euguess = "!sh -c ..."
> >
> > That ... part is read by our configuration reader, so you need to
> > quote the double quotes and backslashes with backslash, which would
> > give you something like:
> >
> > [alias]
> > euguess = "!sh -c 'git log --format=\"%h %ae %s\"
> > --date=short \"$@\" | sed \"s/@\\S*//\"' -"
> >
> >
>
> Junio,
>
> Thanks for taking the time - I appreciate that a lot.
> It does work properly now except there is some difference between the
> required pathnames:
>
> when i'm in a subfolder in git repo i can say
>
> git log filename
>
> But it seems that if the alias is used i need to specify full path
> from the root of the repo no matter where i am.
>
> git log a/b/c/filename
>
> the difference is obviously in the working directory
>
> when i add an alias:
>
> pd = "!sh -c 'pwd'"
>
> i get this:
>
> $ git pd
> /home/users/euguess/repo
>
> $ pwd
> /home/users/euguess/repo/a/b/c
>
> Is there any way to help that situation?
Here's the relevant details from Documentation/config.txt:
"""
If the alias expansion is prefixed with an exclamation point,
it will be treated as a shell command. For example, defining
"alias.new = !gitk --all --not ORIG_HEAD", the invocation
"git new" is equivalent to running the shell command
"gitk --all --not ORIG_HEAD". Note that shell commands will be
executed from the top-level directory of a repository, which may
not necessarily be the current directory.
'GIT_PREFIX' is set as returned by running 'git rev-parse --show-prefix'
from the original current directory. See linkgit:git-rev-parse[1].
"""
The $GIT_PREFIX variable should be available to the alias; it is
a path relative to the root which corresponds to the current
directory.
That doesn't quite play well with these aliases because they use
"$@", though.
One way to do it is to add another layer of indirection. Maybe
someone else on this list has a better suggestion, but this
should do the trick...
Create a shell script to contain your alias, and then point
your alias at it. e.g.
[alias]
example = "!/path/to/alias-script \"$@\""
and then the script can look like:
#!/bin/sh
unset CDPATH
if test -n "$GIT_PREFIX"
then
cd "$GIT_PREFIX"
fi
git log --format='%h %ae %s' --date=short "$@" | sed 's/@\\S*//'
...or something like that. I hope that helps.
I'm also curious if there's a way to avoid needing the extra script...
...
A-ha.. I think adding the chdir to alias is possible using a function.
[alias]
example = "!f() { cd \"${GIT_PREFIX:-.}\" && git log \"$@\"; }; f"
Does that work for you?
I hope that helps.
cheers,
--
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Wed, Oct 30, 2013 at 11:54 PM, Junio C Hamano wrote: > Eugene Sajine writes: > >> That was my initial intention, because I would like to be able to pass >> parameters like to git log or git blame correctly without the explicit >> use of $1. Could you please advise about how to make it work with the >> !sh -c ? >> >> Because the same exact (sed 's/@\\S*//') syntax didn't work with "sh -c". > > You can make it work if you think step-by-step. First, this is what > you want to run: > > sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' - > > so that "git euguess master..next" would turn into > > sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' - master..next > > Now, you want to wrap it into an alias, i.e. > > [alias] > euguess = "!sh -c ..." > > That ... part is read by our configuration reader, so you need to > quote the double quotes and backslashes with backslash, which would > give you something like: > > [alias] > euguess = "!sh -c 'git log --format=\"%h %ae %s\" > --date=short \"$@\" | sed \"s/@\\S*//\"' -" > > Junio, Thanks for taking the time - I appreciate that a lot. It does work properly now except there is some difference between the required pathnames: when i'm in a subfolder in git repo i can say git log filename But it seems that if the alias is used i need to specify full path from the root of the repo no matter where i am. git log a/b/c/filename the difference is obviously in the working directory when i add an alias: pd = "!sh -c 'pwd'" i get this: $ git pd /home/users/euguess/repo $ pwd /home/users/euguess/repo/a/b/c Is there any way to help that situation? Thanks, Eugene Thanks, Eugene -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
Eugene Sajine writes: > That was my initial intention, because I would like to be able to pass > parameters like to git log or git blame correctly without the explicit > use of $1. Could you please advise about how to make it work with the > !sh -c ? > > Because the same exact (sed 's/@\\S*//') syntax didn't work with "sh -c". You can make it work if you think step-by-step. First, this is what you want to run: sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' - so that "git euguess master..next" would turn into sh -c 'git log --format="..." "$@" | sed "s/@\S*//"' - master..next Now, you want to wrap it into an alias, i.e. [alias] euguess = "!sh -c ..." That ... part is read by our configuration reader, so you need to quote the double quotes and backslashes with backslash, which would give you something like: [alias] euguess = "!sh -c 'git log --format=\"%h %ae %s\" --date=short \"$@\" | sed \"s/@\\S*//\"' -" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Wed, Oct 30, 2013 at 5:02 PM, Junio C Hamano wrote: > Eugene Sajine writes: > >> On Wed, Oct 30, 2013 at 3:57 PM, Ralf Thielow wrote: >>> lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g' >>> >>> should work. >> >> >> It did! thanks! I didn't know that "!sh -c" is not needed > > "sh -c" is often used when you pass arguments to your scriptlets, > e.g. to allow > > git lg master..next > > you would want > > sh -c 'git log ... "$@" | sed ...' - > > so that > > git lg master..next > > turns into > > sh -c 'git log ... "$@" | sed ...' - master..next > > which makes $1="master..next" and fed to "git log". Junio, That was my initial intention, because I would like to be able to pass parameters like to git log or git blame correctly without the explicit use of $1. Could you please advise about how to make it work with the !sh -c ? Because the same exact (sed 's/@\\S*//') syntax didn't work with "sh -c". Thanks, Eugene -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
Eugene Sajine writes: > On Wed, Oct 30, 2013 at 3:57 PM, Ralf Thielow wrote: >> lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g' >> >> should work. > > > It did! thanks! I didn't know that "!sh -c" is not needed "sh -c" is often used when you pass arguments to your scriptlets, e.g. to allow git lg master..next you would want sh -c 'git log ... "$@" | sed ...' - so that git lg master..next turns into sh -c 'git log ... "$@" | sed ...' - master..next which makes $1="master..next" and fed to "git log". -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Wed, Oct 30, 2013 at 3:57 PM, Ralf Thielow wrote: > lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g' > > should work. It did! thanks! I didn't know that "!sh -c" is not needed > > On Wed, Oct 30, 2013 at 8:34 PM, Eugene Sajine wrote: >> Hi, >> >> I need some advice about creating the git command alias: >> >> I have this as the command: >> >> git log --pretty=format:"%h %ad %ae %s" --date=short | sed 's/@\S*//g' >> >> >> The purpose is to cut off the email domain and keep only username. >> >> I'm trying to create this as the alias: >> >> >> lg = !sh -c 'git log --pretty=format:"%h %ad %ae %s" --date=short | >> sed 's/@\S*//g'' - >> >> but it complains about the \S and i'm failing to come up with the >> escape sequence to make it work right. >> >> I know i can work around that by creating shell alias, but it is not >> what i would like to have. >> >> Any ideas? >> >> Thanks! >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
lg=!git log --pretty=format:'%h %ad %ae %s' --date=short | sed 's/@\\S*//g' should work. On Wed, Oct 30, 2013 at 8:34 PM, Eugene Sajine wrote: > Hi, > > I need some advice about creating the git command alias: > > I have this as the command: > > git log --pretty=format:"%h %ad %ae %s" --date=short | sed 's/@\S*//g' > > > The purpose is to cut off the email domain and keep only username. > > I'm trying to create this as the alias: > > > lg = !sh -c 'git log --pretty=format:"%h %ad %ae %s" --date=short | > sed 's/@\S*//g'' - > > but it complains about the \S and i'm failing to come up with the > escape sequence to make it work right. > > I know i can work around that by creating shell alias, but it is not > what i would like to have. > > Any ideas? > > Thanks! > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
On Wed, Oct 30, 2013 at 3:47 PM, Andrew Ardill wrote: > Have you tried backslash escaping the backslash? double escaping? > > I don't know how many are required, but I would try first \S, then > \\S, then S, etc > Regards, > > Andrew Ardill When i do that it stops understanding \S* as regexp so it removes only "@", while i need to remove from @ to the next whitespace Thanks, Eugene > > On 30 October 2013 12:34, Eugene Sajine wrote: >> Hi, >> >> I need some advice about creating the git command alias: >> >> I have this as the command: >> >> git log --pretty=format:"%h %ad %ae %s" --date=short | sed 's/@\S*//g' >> >> >> The purpose is to cut off the email domain and keep only username. >> >> I'm trying to create this as the alias: >> >> >> lg = !sh -c 'git log --pretty=format:"%h %ad %ae %s" --date=short | >> sed 's/@\S*//g'' - >> >> but it complains about the \S and i'm failing to come up with the >> escape sequence to make it work right. >> >> I know i can work around that by creating shell alias, but it is not >> what i would like to have. >> >> Any ideas? >> >> Thanks! >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help creating git alias
Have you tried backslash escaping the backslash? double escaping? I don't know how many are required, but I would try first \S, then \\S, then S, etc Regards, Andrew Ardill On 30 October 2013 12:34, Eugene Sajine wrote: > Hi, > > I need some advice about creating the git command alias: > > I have this as the command: > > git log --pretty=format:"%h %ad %ae %s" --date=short | sed 's/@\S*//g' > > > The purpose is to cut off the email domain and keep only username. > > I'm trying to create this as the alias: > > > lg = !sh -c 'git log --pretty=format:"%h %ad %ae %s" --date=short | > sed 's/@\S*//g'' - > > but it complains about the \S and i'm failing to come up with the > escape sequence to make it work right. > > I know i can work around that by creating shell alias, but it is not > what i would like to have. > > Any ideas? > > Thanks! > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with sparse checkouts
On Tue, Aug 13, 2013 at 1:27 AM, Ari Entlich wrote: > Hello all! > > At my current workplace, I have a git-svn repository which has an extremely > large working directory. I did not use the --stdlayout option in this clone, > so I have a number of branches in my working directory which duplicate large > amounts of trunk. There is a particularly large subdirectory which has now > been copied to branches four times (and hence shows up in my working > directory 5 times). This directory and its copies are making up the vast > majority of the files and storage space in my working directory. Furthermore, > I do not need or want to have access to the data in these particular > directories. Hence, I would like to use the sparse checkouts feature to > exclude them from my working directory. > > Let's say that these directories are all called "thedir". What I would like > to do with the sparse checkouts feature is to simply ignore directories with > this name anywhere in the working tree. Intuitively, it seems like I should > be able to put: > > !thedir > > or possibly > > !thedir/ > I think this should work (but I haven't tested it) / !thedir The first rule is to include all, the we exclude what we don't want using the second one (trailing slash or not is ok). > in the sparse-checkout file, but these don't seem to work. I've tried a > number of other things, but I always seem to either get the "sparse checkout > leaves no entry on working directory" error or no effect at all. In the end, > I basically just don't really understand how this file is supposed to work, > so I'd rather get some expert help here rather than thrashing about randomly. > I realize that sparse checkouts is usually used to select a specific > directory rather than what I'm trying to do, so I accept that what I want may > simply not be possible with the current implementation. I've asked on IRC, > but I wanted to ask here also since it seemed that most of the people I > talked to weren't that familiar with the sparse checkouts feature. > > Note that, while using --stdlayout would mitigate the massive working > directory somewhat, I would still probably want to exclude this directory > from my worktree. I will probably do a reclone at some point and use > --stdlayout, but I will still want to exclude this particular directory even > at that point. I had a lot of people on IRC telling me to just use > --stdlayout, which was a good suggestion, but didn't fully fulfill my needs. > > Thanks! > > Ari > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help using git subtree
Al 30/07/13 11:58, En/na Fredrik Gustafsson ha escrit: Git subtree is very convenient to get all the sub-projects into the main-project directory tree and to send back sub-project commits to the corresponding repository. But I don't understand the work flow very well. I haven't used subtree that much however how do you commit to upstream? AFAIK every commit to the subtree must be done in the subtree branch and then merged back to the "superproject"-branch with a subtree merge. I use "git subtree pull" and "git subtree push". AFAIK with subtree all commits are in the same repository, thus one does not need to go to the subtree branch to commit. This is one of the advantages of subtree. I can add a subtree with a given prefix and pull/push my commits to the repository, but how do I do to pull/push commits from the main-project to the corresponding repository avoiding sub-projects to be sent? You don't. A subtree is a subtree in your git-repo and is therefore a part of your repository. When you're using subtree that project will be a part of you project. I expected that there would be a way to split the main project and push it, in the same way that one can split one subtree and push it. If not, this could be a feature request. An other question I have is when will be subtree included in git packages. I had to compile git from sources in order to get this feature. If you're asking when git-subtree will move from contrib/ to core git, I don't know. That's a decision for Junio. I would argue that it shouldn't because submodules can do everything that subtrees are good at and git.git should focus on doing one solution well instead of doing the same thing in two bad ways. However since git.git already uses a subtree-like style for gitk, git-gui, etc. it doesn't seem like Junio agrees with me on this point. Right, I rephrase: When git-subtree will move from contrib/ to core git? Let me also empathize that I find git-subtree much more convenient than sub-modules. One can work with a single repository as it were a single project, one can commit changes that affect different sub-projects with just one command, use common tags and branches and so on. Si heu rebut aquest correu per error, us informo que pot contenir informació confidencial i privada i que està prohibit el seu ús. Us agrairiem que ho comuniqueu al remitent i l'elimineu. Gràcies. Si ha recibido este correo por error, le informo de que puede contener información confidencial y privada y que está prohibido su uso. Le agradeceré que lo comunique a su remitente y lo elimine. Gracias. If you have received this e-mail by error, please note that it may contain confidential and private information, therefore, the use of this information is strictly forbidden. Please inform the sender of the error and delete the information received. Thank you. Is this really something to have in e-mails to a public list? Some lists won't accept this type of e-mails, or simply just ignore you. Don't worry about this signature, it only applies if one receives this e-mail by mistake. Best regards, Gabriel -- Si heu rebut aquest correu per error, us informo que pot contenir informació confidencial i privada i que està prohibit el seu ús. Us agrairiem que ho comuniqueu al remitent i l'elimineu. Gràcies. Si ha recibido este correo por error, le informo de que puede contener información confidencial y privada y que está prohibido su uso. Le agradeceré que lo comunique a su remitente y lo elimine. Gracias. If you have received this e-mail by error, please note that it may contain confidential and private information, therefore, the use of this information is strictly forbidden. Please inform the sender of the error and delete the information received. Thank you. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help using git subtree
On Tue, Jul 30, 2013 at 11:32:22AM +0200, Gabriel Jover wrote: > Dear all, > > I am trying to avoid using git submodules and thus I am testing if > git subtree fit my needs. > I have a set of sub-projects linked to a main-project. Just out of curiosity, why are you trying to avoid submodules? > > Git subtree is very convenient to get all the sub-projects into the > main-project directory tree > and to send back sub-project commits to the corresponding repository. > But I don't understand the work flow very well. I haven't used subtree that much however how do you commit to upstream? AFAIK every commit to the subtree must be done in the subtree branch and then merged back to the "superproject"-branch with a subtree merge. > > I can add a subtree with a given prefix and pull/push my commits to > the repository, > but how do I do to pull/push commits from the main-project to the > corresponding repository > avoiding sub-projects to be sent? You don't. A subtree is a subtree in your git-repo and is therefore a part of your repository. When you're using subtree that project will be a part of you project. > > An other question I have is when will be subtree included in git packages. > I had to compile git from sources in order to get this feature. > git-subtree is a part of git, located in the contrib section. When your software distribution choose to distribute that with your git-package is not up to the git project to decide but something you need to ask your package maintainer. If you're asking when git-subtree will move from contrib/ to core git, I don't know. That's a decision for Junio. I would argue that it shouldn't because submodules can do everything that subtrees are good at and git.git should focus on doing one solution well instead of doing the same thing in two bad ways. However since git.git already uses a subtree-like style for gitk, git-gui, etc. it doesn't seem like Junio agrees with me on this point. > > Si heu rebut aquest correu per error, us informo que pot contenir informació > confidencial i privada i que està prohibit el seu ús. Us agrairiem que ho > comuniqueu al remitent i l'elimineu. Gràcies. > Si ha recibido este correo por error, le informo de que puede contener > información confidencial y privada y que está prohibido su uso. Le > agradeceré que lo comunique a su remitente y lo elimine. Gracias. > If you have received this e-mail by error, please note that it may contain > confidential and private information, therefore, the use of this information > is strictly forbidden. Please inform the sender of the error and delete the > information received. Thank you. Is this really something to have in e-mails to a public list? Some lists won't accept this type of e-mails, or simply just ignore you. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] Corrupted repository
Junio C Hamano writes: > Ramkumar Ramachandra writes: > >> Junio C Hamano wrote: $ ~/src/git error: object file .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty error: object file .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt >>> >>> So fsync() and close() thought that the filesystem stored this loose >>> object safely, but it turns out that the data is not on disk. >> >> Where should I start digging if I want to fix this? Actually you just >> need to tell me how to build reduced-case corruptions to test: I can >> trace and figure out the rest. > > That is a trip in the kernel source, isn't it? I cannot be your > guide there. Not necessarily. AFAICT, Git won't fsync object files by default, but does for pack files (to make sure the pack is written before unlinking the object files being packed): core.fsyncobjectfiles This boolean will enable fsync() when writing object files. This is a total waste of time and effort on a filesystem that orders data writes properly, but can be useful for filesystems that do not use journalling (traditional UNIX filesystems) or that only journal metadata and not file contents (OS X’s HFS+, or Linux ext3 with "data=writeback"). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] Corrupted repository
Junio C Hamano wrote: > A tl;dr is that we _trust_ our refs and everything reachable from > them has to be complete. If that is not the case, things will not > work, and it is not a priority to add workarounds in the normal > codepath to slow things down. Makes sense. > That does not forbid an addition of "git recover-corrupted-repo" > command, whose "assume everything might be broken" code is not > shared with the fastpath of other commands. I'm not looking for a kitchen-sink command: I'm looking for a well-documented toolset to precisely fix corruptions. We have some corruption tests in our testsuite already: I think I'll start digging there. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] Corrupted repository
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>>> $ ~/src/git
>>> error: object file
>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>> error: object file
>>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>>> fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
>>> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
>>
>> So fsync() and close() thought that the filesystem stored this loose
>> object safely, but it turns out that the data is not on disk.
>
> Where should I start digging if I want to fix this? Actually you just
> need to tell me how to build reduced-case corruptions to test: I can
> trace and figure out the rest.
That is a trip in the kernel source, isn't it? I cannot be your
guide there.
>
>>> artagnon|remote-cruft*+:~/src/git$ git prune
>>> artagnon|remote-cruft*+:~/src/git$ git status
>>> fatal: bad object HEAD
>>> fatal: bad object HEAD
>>
>> And the value in the HEAD was???
>
> ref: refs/heads/remote-cruft. That's why I included my prompt :)
>
>>> artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
>>> artagnon|master*+=:~/src/git$ git status
>>> ## master
>>> MM Documentation/git-ls-remote.txt
>>> MM remote.c
>>> MM t/t5505-remote.sh
>>> MM t/t5510-fetch.sh
>>> MM t/t5515-fetch-merge-logic.sh
>>> MM t/t5516-fetch-push.sh
>>> ?? lib/
>>> ?? outgoing/
>>>
>>> That status is completely bogus, by the way.
>>
>> ... which may suggest that your index file may have been corrupted
>> on the filesystem.
>
> Yeah, my question pertains to why is the index half-corrupted. Is
> there no checksum to say "index corrupted; do not display bogus
> nonsense"?
Another possibility is perhaps the objects that are referred to by
the index were missing or unreadable, and the index weren't.
>
>>> artagnon|master*+=:~/src/git$ git checkout remote-cruft
>>> fatal: reference is not a tree: remote-cruft
>>> artagnon|master=:~/src/git$ git reflog
>>> 21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
>>> refs/heads/remote-cruft
>>>
>>> What happened to the rest of my reflog?!
>>
>> On the filesystem known to not record the last consistent state of
>> the repository, the answer to that question may be rather obvious,
>> no?
>
> I didn't understand. What does .git/logs/HEAD have to do with any of
> this? Why is it truncated?
Explain why .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f
was truncated to yourself, and the same explanation would apply to
the .git/logs/HEAD file, I think.
> This was mainly a learning exercise for me: I wanted to see how good
> git was at working with corrupted repositories.
You could have just asked ;-).
A tl;dr is that we _trust_ our refs and everything reachable from
them has to be complete. If that is not the case, things will not
work, and it is not a priority to add workarounds in the normal
codepath to slow things down.
That does not forbid an addition of "git recover-corrupted-repo"
command, whose "assume everything might be broken" code is not
shared with the fastpath of other commands.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] Corrupted repository
Junio C Hamano wrote:
>> $ ~/src/git
>> error: object file
>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>> error: object file
>> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
>> fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
>> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
>
> So fsync() and close() thought that the filesystem stored this loose
> object safely, but it turns out that the data is not on disk.
Where should I start digging if I want to fix this? Actually you just
need to tell me how to build reduced-case corruptions to test: I can
trace and figure out the rest.
>> artagnon|remote-cruft*+:~/src/git$ git prune
>> artagnon|remote-cruft*+:~/src/git$ git status
>> fatal: bad object HEAD
>> fatal: bad object HEAD
>
> And the value in the HEAD was???
ref: refs/heads/remote-cruft. That's why I included my prompt :)
>> artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
>> artagnon|master*+=:~/src/git$ git status
>> ## master
>> MM Documentation/git-ls-remote.txt
>> MM remote.c
>> MM t/t5505-remote.sh
>> MM t/t5510-fetch.sh
>> MM t/t5515-fetch-merge-logic.sh
>> MM t/t5516-fetch-push.sh
>> ?? lib/
>> ?? outgoing/
>>
>> That status is completely bogus, by the way.
>
> ... which may suggest that your index file may have been corrupted
> on the filesystem.
Yeah, my question pertains to why is the index half-corrupted. Is
there no checksum to say "index corrupted; do not display bogus
nonsense"?
>> artagnon|master*+=:~/src/git$ git checkout remote-cruft
>> fatal: reference is not a tree: remote-cruft
>> artagnon|master=:~/src/git$ git reflog
>> 21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
>> refs/heads/remote-cruft
>>
>> What happened to the rest of my reflog?!
>
> On the filesystem known to not record the last consistent state of
> the repository, the answer to that question may be rather obvious,
> no?
I didn't understand. What does .git/logs/HEAD have to do with any of
this? Why is it truncated?
>> artagnon|master=:~/src/git$ git branch -D remote-cruft
>> error: Couldn't look up commit object for 'refs/heads/remote-cruft'
>
> The command would want to report what was at the tip, so it is
> understandable it may want to look up that commit before removing
> the ref.
I would have expected it to display a warning and remove the ref
anyway. Or error out, and override with a force-flag?
>> Fine, let's fetch.
>
> Why?
>
> "fetch" walks the ancestry graph on both ends to minimize transfers.
> It's not something you would expect to work when you know refs at
> your end does not even record what you do have. It _may_ appear to
> work if your refs are intact but you are missing objects, as they
> will not be transferred again from the good copy if you let your
> repository's ref claim that you have _all_ objects behind it when
> you actually don't.
Right. I expected it to figure out that I have a broken history and
fetch everything (which is what happened the second time, no?).
> What would have been a better starting point to untangle is to make
> a separate clone, pretending as if this repository did not even
> exist, and copy the resulting packfile into this repository. That
> would at least give you a known good copies of objects that you
> already have pushed out.
Yeah, I deliberately avoided doing that: apart from the config and
refs, I had no real unpushed work in ~/src/git anyway (I push _very_
frequently, which explains my "resolve HEAD early in current" patch).
The most important part of what I did was running unpack-objects by
hand: that fixed everything. I shouldn't have had to run that by hand
though: why isn't there an in-built way to unpack everything, remove
corruptions, and repack the good stuff?
> And the next step would have been (without doing any of the above
> "remove this branch, recreate this one anew") to compare the tips
> of refs in this broken repository and the clone. The same ones you
> can trust, and different ones you dig further.
Right. I didn't have local data in this case, so I didn't bother.
>> Was I being stupid, or is fixing corrupted repositories really this
>> non-trivial? Comments appreciated.
>
> I think "Let's fetch first" was the step that took you in a wrong
> direction that requires unnecessary work.
This was mainly a learning exercise for me: I wanted to see how good
git was at working with corrupted repositories. I did my surgery
fairly quickly, and avoided large network transfers (I have a slow
connection).
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [HELP] Corrupted repository
Ramkumar Ramachandra writes:
> $ ~/src/git
> error: object file
> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
> error: object file
> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f is empty
> fatal: loose object 8e6a6dda24b017915449897fcc1353a9b848fd2f (stored
> in .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f) is corrupt
So fsync() and close() thought that the filesystem stored this loose
object safely, but it turns out that the data is not on disk.
> artagnon|remote-cruft*+:~/src/git$ rm
> .git/objects/8e/6a6dda24b017915449897fcc1353a9b848fd2f
As you know it is empty, removing (as long as you do not forget what
the object name was, which may later become useful when untangling
the mess further) does not hurt very much.
> artagnon|remote-cruft*+:~/src/git$ git prune
> artagnon|remote-cruft*+:~/src/git$ git status
> fatal: bad object HEAD
> fatal: bad object HEAD
And the value in the HEAD was???
> artagnon|remote-cruft*+:~/src/git$ git symbolic-ref HEAD refs/heads/master
> artagnon|master*+=:~/src/git$ git status
> ## master
> MM Documentation/git-ls-remote.txt
> MM remote.c
> MM t/t5505-remote.sh
> MM t/t5510-fetch.sh
> MM t/t5515-fetch-merge-logic.sh
> MM t/t5516-fetch-push.sh
> ?? lib/
> ?? outgoing/
>
> That status is completely bogus, by the way.
... which may suggest that your index file may have been corrupted
on the filesystem.
> artagnon|master*+=:~/src/git$ git reset --hard
... and using that known-to-be-corrupt index, the working tree state
is discarded.
> artagnon|master*+=:~/src/git$ git checkout remote-cruft
> fatal: reference is not a tree: remote-cruft
> artagnon|master=:~/src/git$ git reflog
> 21ff915 HEAD@{10 minutes ago}: rebase -i (finish): returning to
> refs/heads/remote-cruft
>
> What happened to the rest of my reflog?!
On the filesystem known to not record the last consistent state of
the repository, the answer to that question may be rather obvious,
no?
> artagnon|master=:~/src/git$ git branch -D remote-cruft
> error: Couldn't look up commit object for 'refs/heads/remote-cruft'
The command would want to report what was at the tip, so it is
understandable it may want to look up that commit before removing
the ref.
> artagnon|master=:~/src/git$ rm .git/refs/heads/remote-cruft
> artagnon|master=:~/src/git$ git checkout -b remote-cruft
> Switched to a new branch 'remote-cruft'
>
> Huh? What happened to my upstream?
>
> artagnon|remote-cruft:~/src/git$ git branch -u ram/remote-cruft
> warning: ignoring broken ref refs/remotes/ram/remote-cruft.
So remotes/ram/remote-cruft is also broken.
> Fine, let's fetch.
Why?
"fetch" walks the ancestry graph on both ends to minimize transfers.
It's not something you would expect to work when you know refs at
your end does not even record what you do have. It _may_ appear to
work if your refs are intact but you are missing objects, as they
will not be transferred again from the good copy if you let your
repository's ref claim that you have _all_ objects behind it when
you actually don't.
What would have been a better starting point to untangle is to make
a separate clone, pretending as if this repository did not even
exist, and copy the resulting packfile into this repository. That
would at least give you a known good copies of objects that you
already have pushed out.
And the next step would have been (without doing any of the above
"remove this branch, recreate this one anew") to compare the tips
of refs in this broken repository and the clone. The same ones you
can trust, and different ones you dig further.
> Was I being stupid, or is fixing corrupted repositories really this
> non-trivial? Comments appreciated.
I think "Let's fetch first" was the step that took you in a wrong
direction that requires unnecessary work.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help with git-svn and SVN symlinks
Any update about this: I created this simple bug test to reproduce my problem. I tried on latest GIT, It fails. It is really preventing me from using GitSvn. Any help will be highly appreciated. Let me know if you have any questions. [GITSVN] $git --version git version 1.8.2.GIT [GITSVN] $git svn --version git-svn version 1.8.2.GIT (svn 1.5.7) #Create svn repo cd /tmp; mkdir git-svn-prob; cd /tmp/git-svn-prob; /usr/bin/svnadmin create SVNTest-repo svn co file:///tmp/git-svn-prob/SVNTest-repo SVNTest cd SVNTest echo "stuff in h" > h echo -n "link h" > hl svn add h hl svn commit -m "Adding two files"; #Create GIT-svn repo cd ..; mkdir GITSVN cd GITSVN git svn init file:///tmp/git-svn-prob/SVNTest-repo; git svn fetch # In SVN Repo, Modify hl to be link from file cd .. cd SVNTest; svn ps svn:special '*' hl rm hl ln -s h hl svn ci -m "Exisitng file modified to be link"; cat hl; # Fetch latest SVN rev and see problem cd .. cd GITSVN; git svn fetch; git co git-svn -f cat hl; diff hl ../SVNTest/hl # Fails, Should succeed -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help requested - trying to build a tool doing whole-tree commits
esr: >Junio C Hamano pobox.com>: >> Perhaps not exactly what you are looking for, but don't we have >> import-tar somewhere in contrib/fast-import hierarchy (sorry, not on >> a machine yet, and I cannot give more details). > >If I recall correctly, that can only be used for original import. You may find my (old) ag-import-patch tool useful. Although the name does not imply it, it allows to import a series of releases that can be available either as tarballs or as patches. http://ydirson.free.fr/soft/git/argit.git/ There's not much doc in there, and not so much I can remember myself from the short help string. IIRC you can specify which base revision a patch applies to (ie. it may apply to an older revision, not necessarily to the current HEAD). It has also quite some bitrot (git-* direct invocation, use of cg-tag, surely more). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help requested - trying to build a tool doing whole-tree commits
Junio C Hamano : > Perhaps not exactly what you are looking for, but don't we have > import-tar somewhere in contrib/fast-import hierarchy (sorry, not on > a machine yet, and I cannot give more details). If I recall correctly, that can only be used for original import. I think Andreas Schwab's suggestion (git add -A && git write-tree && git commit-tree && git update-ref) is probably the right thing. I'm going to try that. -- http://www.catb.org/~esr/";>Eric S. Raymond -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help requested - trying to build a tool doing whole-tree commits
On Fri, Nov 9, 2012 at 10:50 PM, Andreas Schwab wrote: > Unknown writes: Unknown Invalid? Please don't change the original email, makes it harder for other people to reply. >> I need a command or command sequence that will commit an entire file >> tree to a repository... >> >> (a) Allowing me to specify committer and author metadata, and >> >> (b) deleting paths not present in the previous commit on the current >> branch, and >> >> (c) allowing me to specify merge links from other previous commits. >> >> git commit -a passes (a) and (b) but not (c). > > git commit -a won't add new files, so you probably want to use git add > -A && git commit. I'm not quite sure what you mean with "merge links", > but if you want to create merge commits the you'll need to resort to > plumbing: git add -A && git write-tree && git commit-tree && git > update-ref. I've done something similar, except that I used git hash-object instead of git commit-tree so that I can specify every single detail about the commit object. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help requested - trying to build a tool doing whole-tree commits
Unknown writes: > (Apologies if this arrives twice. I'm on the road, with somewhat flaky email.) > > Because of my work on reposurgeon, I am sometimes asked to produce git > repositories for very old projects that not only are still using CVS > but have ancient releases not in the CVS repository, preserved only > as tarballs. Perhaps not exactly what you are looking for, but don't we have import-tar somewhere in contrib/fast-import hierarchy (sorry, not on a machine yet, and I cannot give more details). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help requested - trying to build a tool doing whole-tree commits
Unknown writes: > I need a command or command sequence that will commit an entire file > tree to a repository... > > (a) Allowing me to specify committer and author metadata, and > > (b) deleting paths not present in the previous commit on the current > branch, and > > (c) allowing me to specify merge links from other previous commits. > > git commit -a passes (a) and (b) but not (c). git commit -a won't add new files, so you probably want to use git add -A && git commit. I'm not quite sure what you mean with "merge links", but if you want to create merge commits the you'll need to resort to plumbing: git add -A && git write-tree && git commit-tree && git update-ref. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: help doing a hotfix bisect: cherry-pick -m ??
On Fri, Sep 7, 2012 at 1:27 PM, Junio C Hamano wrote: > Jim Cromie writes: > >> Broader question: > >> Im thinking that having a hotfix branch, and merging --no-commit would >> work better, >> especially when bisection lands on a commit which already contains >> some of those in the hotfix branch. > > When your history leading to the "bad" commit contains only part of > the hot-fix branch and not all of it, that may work better. good, I have a 1/2 grip at least. thank you. any tips on how to use the -m option ? Ive had no success passing small integers, and I need to include the commits from the merged branch The only alternative I have is to rework the split *_deferred patch on top of the merge-point, and hope that it tests ok with the original hotfix patch, then I can probably do the bisect. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: help doing a hotfix bisect: cherry-pick -m ??
Jim Cromie writes: > Broader question: > Im thinking that having a hotfix branch, and merging --no-commit would > work better, > especially when bisection lands on a commit which already contains > some of those in the hotfix branch. When your history leading to the "bad" commit contains only part of the hot-fix branch and not all of it, that may work better. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
