* Re: cogito remote branch
From: MichaelTiloDressel @ 2007-11-09 13:51 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <47345E85.8090702@op5.se>
Such a pity. We just got used to it.
-----Original Message-----
Date: Fri, 09 Nov 2007 14:20:05 +0100
Subject: Re: cogito remote branch
From: Andreas Ericsson
To: "MichaelTiloDressel@t-online.de"
MichaelTiloDressel@t-online.de wrote:
> Hi,
>
> I just saw the scripts cg-update, cg-push .. scripts try to guess a
> branch name functioning as origin if no argument is given. These
scripts
> seam to use a branch named -origin if it exists and the
> current
> branch is named and is not the branch named master.
>
> I like that feature. Is it anywhere documented?
>
> In case there is no branch named -origin the scripts just
> use origin even if the current branch is not master. I would prefer
the
> scripts to fail in this case and to print a message asking the user to
> specifically name a branch.
>
Cogito is deprecated, and has been for quite some time. The "remote"
feature of core git (inspired by cogito) offers similar benefits.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Jakub Narebski @ 2007-11-09 13:57 UTC (permalink / raw)
To: git
In-Reply-To: <473463E0.7000406@gmail.com>
Carlos Rica wrote:
> + struct option options[] = {
> + { OPTION_STRING, 'l', NULL, &list, "pattern", "list tag names",
> + PARSE_OPT_OPTARG, NULL, (intptr_t) no_pattern },
> + OPT_STRING('F', NULL, &msgfile, "file", "message in a file"),
Does it matter that you use OPTION_STRING here and OPT_STRING macro there?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/2] Add strchrnul()
From: Andreas Ericsson @ 2007-11-09 13:59 UTC (permalink / raw)
To: Jakub Narebski; +Cc: René Scharfe, Junio C Hamano, Git Mailing List
In-Reply-To: <fh1o4o$jei$1@ger.gmane.org>
Jakub Narebski wrote:
> [Cc: Andreas Ericsson <ae@op5.se>,
> René Scharfe <rene.scharfe@lsrfire.ath.cx>,
> Junio C Hamano <gitster@pobox.com>,
> git@vger.kernel.org]
>
I'm not sure what's up with this, but I didn't see this email on git@vger,
so re-adding it to the Cc list now.
>
> Original patch lacked adding appropriate test to configure,
> i.e. something like below to configure.ac
>
> #
> # Define NO_STRCHRNUL if you don't have strchrnul.
> AC_CHECK_FUNC(strchrnul,
> [NO_STRCHRNUL=],
> [NO_STRCHRNUL=YesPlease])
> AC_SUBST(NO_STRCHRNUL)
>
> and the following line to config.mak.in
>
> NO_STRCHRNUL=@NO_STRCHRNUL@
>
>> This seems overly complicated. How about this instead?
> [...]
>> I'm fairly much against forcing people to know what library
>> functions they have in order to get software to compile
>> properly. This is, imo, a neater solution, and also inlines
>> the function as suggested by Dscho.
>
> Wouldn't it be better to add ./configure check instead? See above.
>
> Although I guess that people using ./configure to set compilation
> options (to generate config.mak.autogen) are minority...
>
Perhaps. I know I don't anyway, and now it's become standard not to
do so for a significant part of the git-tracking world.
>> +#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
>> +# define strchrnul(s, c) gitstrchrnul(s, c)
>> +static inline char *gitstrchrnul(const char *s, int c)
>> +{
>> + while (*s && *s != c)
>> + s++;
>> +
>> + return (char *)s;
>> +}
>> +#endif
>> +
>
> This is good solution, although I'm not sure about the check itself.
> What if somebody has libc which is not glibc, but it does have
> strchrnul?
>
They most likely fall into the minority that get to suffer from
using code that's as fast as what's in there today, although
a bit more readable. The glibc optimization is really only
worthwhile for architectures where strchrnul()-like operations
have microcode support, or when it's used on large strings.
YMMV. I suppose rewriting it as
#if defined(__GLIBC_PREREQ) && __GLIBC_PREREQ(2, 1)
# define HAVE_STRCHRNUL
#endif
#ifdef HAVE_STRCHRNUL
...
would work too, and will provide an easier way out for other fellas
wanting to say "Hey, my favourite solaris libc has this too!". OTOH,
that rewrite can be done when the first such case appears.
>> diff --git a/builtin-fetch--tool.c b/builtin-fetch--tool.c
>
> This IMHO should go to separate patch.
>
*shrug* Rene had it in his. Monkey see monkey do ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: cogito remote branch
From: Johannes Schindelin @ 2007-11-09 14:17 UTC (permalink / raw)
To: MichaelTiloDressel@t-online.de; +Cc: Andreas Ericsson, git
In-Reply-To: <1IqUGN-1XXOVs0@fwd33.aul.t-online.de>
Hi,
On Fri, 9 Nov 2007, MichaelTiloDressel@t-online.de wrote:
> Such a pity. We just got used to it.
It's open source. You are free to use/maintain it.
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG] git-rebase fails when a commit message contains a diff
From: Johannes Schindelin @ 2007-11-09 14:18 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, Jonas Fonseca, git
In-Reply-To: <B2BAA0E1-8DA7-417D-AE25-53D8690810ED@zib.de>
Hi,
On Fri, 9 Nov 2007, Steffen Prohaska wrote:
> On Nov 9, 2007, at 2:51 AM, Junio C Hamano wrote:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > That's a known design limitation of applymbox/mailinfo. Any
> > > line that looks like a beginning of a patch in e-mail ("^--- ",
> > > "^---$", "^diff -", and "^Index: ") terminates the commit log.
> >
> > Ok, so that explains the symptom. What's the next step?
> >
> > * The applymbox/mailinfo pair should continue to split the
> > commit log message at the first such line. There is no point
> > breaking established workflow, and people in communities that
> > exchange patches via e-mail already know to avoid this issue
> > by indenting quoted diff snippet in the log message,
> > e.g. 5be507fc.
>
> I wasn't aware of this.
But there's a really easy workaround: use --merge with git rebase.
Ciao,
Dscho
^ permalink raw reply
* Re: [BUG] git-rebase fails when a commit message contains a diff
From: Johannes Schindelin @ 2007-11-09 14:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonas Fonseca, git
In-Reply-To: <7v1wb0xhxq.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 8 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 8 Nov 2007, Junio C Hamano wrote:
> >
> >> I wonder if this is a sensible thing to do, regardless of the issue
> >> of commit log message that contains anything.
> >>
> >> The patch replaces git-rebase with git-rebase--interactive. The only
> >> difference from the existing "git-rebase -i" is if the command is
> >> called without "-i" the initial "here is the to-do list. please
> >> rearrange the lines, modify 'pick' to 'edit' or whatever as
> >> appropriate" step is done without letting the user edit the list.
> >
> > Hmm. I don't know, really. I had the impression that the "git
> > format-patch | git am" pipeline would be faster.
>
> Heh, I did not read rebase--interactive carefully enough.
>
> Unless told to use merge with "rebase -m", rebase replays the change by
> extracting and applying patches, and speed comparison was about that vs
> merge based replaying; I thought make_patch was done in order to avoid
> using cherry-pick (which is based on merge-recursive) and doing patch
> application with three-way fallback. Apparently that is not what
> "interactive" does.
>
> Perhaps pick_one () could be taught to perform the 3-way fallback dance
> git-am plays correctly. The patch I sent to make
> git-rebase--interactive take over git-rebase would then become quite
> reasonable, I would think.
I have a different idea: How about changing cherry-pick to try a simple
patch first? If that fails, we can always go back to merge-recursive (or
merge-nu once that is ready).
Ciao,
Dscho
^ permalink raw reply
* fatal: serious inflate inconsistency
From: bob @ 2007-11-09 14:14 UTC (permalink / raw)
To: git
From: kranki@mac.com
Subject: fatal: serious inflate inconsistency
Date: November 8, 2007 10:56:02 PM EST
To: majordomo@vger.kernel.org
Hi, list.
Sorry, but I am not that familiar with git's internal workings,
but here is a failure that I can consistently create. I am
running MacOSX 10.4.10 with git compiled from source.
Here is the problem output that I am receiving:
apple07:~/rmwHtmlOld bob$ git version
git version 1.5.3.5
apple07:~/rmwHtmlOld bob$ git init
Initialized empty Git repository in .git/
apple07:~/rmwHtmlOld bob$ git add .
apple07:~/rmwHtmlOld bob$ git commit --all
Created initial commit 49b4183: Initial commit
10993 files changed, 3615639 insertions(+), 0 deletions(-)
create mode 100644 .gitignore
create mode 100755 bk.sh
.
.
.
create mode 100755 ter/webalizer/webalizer.hist
apple07:~/rmwHtmlOld bob$ cd ..
apple07:~ bob$ mkdir rmwHtml.git
apple07:~ bob$ cd rmwHtml.git/
apple07:~/rmwHtml.git bob$ git --bare init --share
usage: git-init [-q | --quiet] [--template=<template-directory>] [--
shared]
apple07:~/rmwHtml.git bob$ git --bare init --shared
Initialized empty shared Git repository in /Users/bob/rmwHtml.git/
apple07:~/rmwHtml.git bob$ git --bare fetch ../rmwHtmlOld master:master
warning: no common commits
remote: Generating pack...
remote: Done counting 11402 objects.
remote: Deltifying 11402 objects...
remote: 100% (11402/11402) done
Indexing 11402 objects...
100% (11402/11402) done
Resolving 3356 deltas...
fatal: serious inflate inconsistency
remote: Total 11402 (delta 3356), reused 0 (delta 0)
fatal: index-pack died with error code 128
fatal: Fetch failure: ../rmwHtmlOld
apple07:~/rmwHtml.git bob$
The ... represent about 11,000 files that I did not feel needed to be
included.
The total directory being put in the repository is about 4gig.
There are two files that are about 1.0gig each. I had them as one which
in MacOSX 10.4.10 showed as 1.88gig and think that this may be the
problem, but don't know why since my searches show that git should
handle files up to 2gig. If I am wrong and there is a lesser limit,
then
I apologize.
I have this directory, rmwHtmlOld, saved as a tarball and can recreate
the above as needed.
I apologize if I am doing something wrong that I am not aware of.
I use git for several different projects and have no problem with them.
I would appreciate any help that you can provide. Thank you for
your time.
^ permalink raw reply
* Re: [BUG] git-rebase fails when a commit message contains a diff
From: Steffen Prohaska @ 2007-11-09 14:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jonas Fonseca, git
In-Reply-To: <Pine.LNX.4.64.0711091417500.4362@racer.site>
On Nov 9, 2007, at 3:18 PM, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 9 Nov 2007, Steffen Prohaska wrote:
>
>> On Nov 9, 2007, at 2:51 AM, Junio C Hamano wrote:
>>
>>> Junio C Hamano <gitster@pobox.com> writes:
>>>
>>>> That's a known design limitation of applymbox/mailinfo. Any
>>>> line that looks like a beginning of a patch in e-mail ("^--- ",
>>>> "^---$", "^diff -", and "^Index: ") terminates the commit log.
>>>
>>> Ok, so that explains the symptom. What's the next step?
>>>
>>> * The applymbox/mailinfo pair should continue to split the
>>> commit log message at the first such line. There is no point
>>> breaking established workflow, and people in communities that
>>> exchange patches via e-mail already know to avoid this issue
>>> by indenting quoted diff snippet in the log message,
>>> e.g. 5be507fc.
>>
>> I wasn't aware of this.
>
> But there's a really easy workaround: use --merge with git rebase.
It's no longer a problem for me. I now know the limitation and
the work around. But others could get bitten, too. We could
save them.
Steffen
^ permalink raw reply
* linux-2.6 clone with CygWin git
From: Medve Emilian @ 2007-11-09 14:29 UTC (permalink / raw)
To: git
Hello,
I noticed that something might not be right with my CygWin git (latest
CygWin relevant build packages + a few days old git build from the next
& master branches). When I clone, say, Linus' tree over the native git
protocol everything goes fine but a git-status shows this:
$ git-status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: include/linux/netfilter/xt_CONNMARK.h
# modified: include/linux/netfilter/xt_DSCP.h
# modified: include/linux/netfilter/xt_MARK.h
# modified: include/linux/netfilter/xt_TCPMSS.h
# modified: include/linux/netfilter_ipv4/ipt_CONNMARK.h
# modified: include/linux/netfilter_ipv4/ipt_DSCP.h
# modified: include/linux/netfilter_ipv4/ipt_ECN.h
# modified: include/linux/netfilter_ipv4/ipt_MARK.h
# modified: include/linux/netfilter_ipv4/ipt_TCPMSS.h
# modified: include/linux/netfilter_ipv4/ipt_TOS.h
# modified: include/linux/netfilter_ipv4/ipt_TTL.h
# modified: include/linux/netfilter_ipv6/ip6t_HL.h
# modified: include/linux/netfilter_ipv6/ip6t_MARK.h
# modified: net/ipv4/netfilter/ipt_ECN.c
# modified: net/ipv4/netfilter/ipt_TOS.c
# modified: net/ipv4/netfilter/ipt_TTL.c
# modified: net/ipv6/netfilter/ip6t_HL.c
# modified: net/netfilter/xt_CONNMARK.c
# modified: net/netfilter/xt_DSCP.c
# modified: net/netfilter/xt_MARK.c
# modified: net/netfilter/xt_TCPMSS.c
#
no changes added to commit (use "git add" and/or "git commit -a")
git-fsck --strict --full finds no fault in the clone, git-reset --hard
goes fine but changes nothing in the output of git-status. Some
additional superficial investigation showed that git-diff doesn't even
compare my checked out tree against the latest commit. Checkout of
various commits shows the same issue.
Can somebody please double-check this scenario for me just to validate
that this happens only due to some particular factors combination on my
box?
Thanks,
Emil.
^ permalink raw reply
* Re: [PATCH] Make builtin-tag.c use parse_options.
From: Johannes Schindelin @ 2007-11-09 14:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, jasampler
In-Reply-To: <fh1p10$nta$1@ger.gmane.org>
Hi,
[re Cc:ing jasam]
On Fri, 9 Nov 2007, Jakub Narebski wrote:
> Carlos Rica wrote:
>
> > + struct option options[] = {
> > + { OPTION_STRING, 'l', NULL, &list, "pattern", "list tag names",
> > + PARSE_OPT_OPTARG, NULL, (intptr_t) no_pattern },
>
> > + OPT_STRING('F', NULL, &msgfile, "file", "message in a file"),
>
> Does it matter that you use OPTION_STRING here and OPT_STRING macro there?
I guess it is because of the PARSE_OPT_OPTARG thing, together with
no_pattern. We need to know if -l was specified, even if no argument was
passed in.
Hth,
Dscho
^ permalink raw reply
* Re: git push failing, unpacker error
From: Jon Smirl @ 2007-11-09 14:37 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9e4733910711082155t62df9d4by10bd3f546ffbd950@mail.gmail.com>
I updated both sides to current git and it still fails. How do I debug this?
What's causing this, "error: pack-objects died with strange error"?
jonsmirl@terra:~/mpc5200b$ git push dreamhost
To ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git
* [new branch] m24 -> linus/m24
* [new branch] m25 -> linus/m25
* [new branch] m26 -> linus/m26
* [new branch] m28 -> linus/m28
* [new branch] m29 -> linus/m29
Counting objects: 81156, done.
Compressing objects: 100% (15280/15280), done.
error: pack-objects died with strange errorMiB | 412 KiB/s
unpack index-pack abnormal exit
ng refs/remotes/linus/m24 n/a (unpacker error)
ng refs/remotes/linus/m25 n/a (unpacker error)
ng refs/remotes/linus/m26 n/a (unpacker error)
ng refs/remotes/linus/m28 n/a (unpacker error)
ng refs/remotes/linus/m29 n/a (unpacker error)
error: failed to push to 'ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git'
jonsmirl@terra:~/mpc5200b$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: git push failing, unpacker error
From: Jon Smirl @ 2007-11-09 14:43 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9e4733910711090637tcf7e837na863a4276578bf3f@mail.gmail.com>
On 11/9/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> I updated both sides to current git and it still fails. How do I debug this?
> What's causing this, "error: pack-objects died with strange error"?
My remote host is running 2.4.32, is git ok on that kernel?
>
>
> jonsmirl@terra:~/mpc5200b$ git push dreamhost
> To ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git
> * [new branch] m24 -> linus/m24
> * [new branch] m25 -> linus/m25
> * [new branch] m26 -> linus/m26
> * [new branch] m28 -> linus/m28
> * [new branch] m29 -> linus/m29
> Counting objects: 81156, done.
> Compressing objects: 100% (15280/15280), done.
> error: pack-objects died with strange errorMiB | 412 KiB/s
> unpack index-pack abnormal exit
> ng refs/remotes/linus/m24 n/a (unpacker error)
> ng refs/remotes/linus/m25 n/a (unpacker error)
> ng refs/remotes/linus/m26 n/a (unpacker error)
> ng refs/remotes/linus/m28 n/a (unpacker error)
> ng refs/remotes/linus/m29 n/a (unpacker error)
> error: failed to push to 'ssh://jonsmirl1@git.digispeaker.com/~/mpc5200b.git'
> jonsmirl@terra:~/mpc5200b$
>
>
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] tests: git push mirror mode tests V2 -- add tag tests
From: Andy Whitcroft @ 2007-11-09 14:45 UTC (permalink / raw)
To: git
In-Reply-To: <1194603673.0@pinky>
Add additional tests to the the V2 tests testing the handling of
tags in --mirror mode. We expect these to be tracked in line with
the master.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
Note that this patch is cumulative on top of the following
patch:
tests: git push mirror mode tests V2
These two patches together replace the 4/4 from the original
series.
---
t/t5517-push-mirror.sh | 105 +++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 104 insertions(+), 1 deletions(-)
diff --git a/t/t5517-push-mirror.sh b/t/t5517-push-mirror.sh
index a65d2f5..ec87ce5 100755
--- a/t/t5517-push-mirror.sh
+++ b/t/t5517-push-mirror.sh
@@ -30,6 +30,7 @@ mk_repo_pair () {
}
+# BRANCH tests
test_expect_success 'push mirror does not create new branches' '
mk_repo_pair &&
@@ -96,7 +97,7 @@ test_expect_success 'push mirror does not remove branches' '
'
-test_expect_success 'push mirror does not add, update and remove together' '
+test_expect_success 'push mirror does not add, update and remove branches together' '
mk_repo_pair &&
(
@@ -122,4 +123,106 @@ test_expect_success 'push mirror does not add, update and remove together' '
'
+
+# TAG tests
+test_expect_success 'push mirror does not create new tags' '
+
+ mk_repo_pair &&
+ (
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git tag -f tmaster master &&
+ git push --mirror up
+ ) &&
+ master_master=$(cd master && git show-ref -s --verify refs/tags/tmaster) &&
+ mirror_master=$(cd mirror && git show-ref -s --verify refs/tags/tmaster) &&
+ test "$master_master" = "$mirror_master"
+
+'
+
+test_expect_success 'push mirror does not update existing tags' '
+
+ mk_repo_pair &&
+ (
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git tag -f tmaster master &&
+ git push --mirror up &&
+ echo two >foo && git add foo && git commit -m two &&
+ git tag -f tmaster master &&
+ git push --mirror up
+ ) &&
+ master_master=$(cd master && git show-ref -s --verify refs/tags/tmaster) &&
+ mirror_master=$(cd mirror && git show-ref -s --verify refs/tags/tmaster) &&
+ test "$master_master" = "$mirror_master"
+
+'
+
+test_expect_success 'push mirror does not force update existing tags' '
+
+ mk_repo_pair &&
+ (
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git tag -f tmaster master &&
+ git push --mirror up &&
+ echo two >foo && git add foo && git commit -m two &&
+ git tag -f tmaster master &&
+ git push --mirror up &&
+ git reset --hard HEAD^
+ git tag -f tmaster master &&
+ git push --mirror up
+ ) &&
+ master_master=$(cd master && git show-ref -s --verify refs/tags/tmaster) &&
+ mirror_master=$(cd mirror && git show-ref -s --verify refs/tags/tmaster) &&
+ test "$master_master" = "$mirror_master"
+
+'
+
+test_expect_success 'push mirror does not remove tags' '
+
+ mk_repo_pair &&
+ (
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git tag -f tremove master &&
+ git push --mirror up &&
+ git tag -d tremove
+ git push --mirror up
+ ) &&
+ (
+ cd mirror &&
+ invert git show-ref -s --verify refs/tags/tremove
+ )
+
+'
+
+test_expect_success 'push mirror does not add, update and remove tags together' '
+
+ mk_repo_pair &&
+ (
+ cd master &&
+ echo one >foo && git add foo && git commit -m one &&
+ git tag -f tmaster master &&
+ git tag -f tremove master &&
+ git push --mirror up &&
+ git tag -d tremove &&
+ git tag tadd master &&
+ echo two >foo && git add foo && git commit -m two &&
+ git tag -f tmaster master &&
+ git push --mirror up
+ ) &&
+ master_master=$(cd master && git show-ref -s --verify refs/tags/tmaster) &&
+ master_add=$(cd master && git show-ref -s --verify refs/tags/tadd) &&
+ mirror_master=$(cd mirror && git show-ref -s --verify refs/tags/tmaster) &&
+ mirror_add=$(cd mirror && git show-ref -s --verify refs/tags/tadd) &&
+ test "$master_master" = "$mirror_master" &&
+ test "$master_add" = "$mirror_add" &&
+ (
+ cd mirror &&
+ invert git show-ref -s --verify refs/tags/tremove
+ )
+
+'
+
test_done
^ permalink raw reply related
* [PATCH] git-push: add documentation for the newly add --mirror mode
From: Andy Whitcroft @ 2007-11-09 15:01 UTC (permalink / raw)
To: git
In-Reply-To: <1194619555.0@pinky>
Add some basic documentation on the --mirror mode for git-push.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
Documentation/git-push.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index e5dd4c1..2403621 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -62,6 +62,14 @@ the remote repository.
\--all::
Instead of naming each ref to push, specifies that all
refs under `$GIT_DIR/refs/heads/` be pushed.
+
+\--mirror::
+ Instead of naming each ref to push, specifies that all
+ refs under `$GIT_DIR/refs/heads/` and `$GIT_DIR/refs/tags/`
+ be mirrored to the remote repository. Newly created local
+ refs will be pushed to the remote end, locally updated refs
+ will be force updated on the remote end, and deleted refs
+ will be removed from the remote end.
\--dry-run::
Do everything except actually send the updates.
^ permalink raw reply related
* Re: linux-2.6 clone with CygWin git
From: Andreas Ericsson @ 2007-11-09 15:00 UTC (permalink / raw)
To: Medve Emilian; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174D8A2@az33exm24.fsl.freescale.net>
Medve Emilian wrote:
> Hello,
>
>
> I noticed that something might not be right with my CygWin git (latest
> CygWin relevant build packages + a few days old git build from the next
> & master branches). When I clone, say, Linus' tree over the native git
> protocol everything goes fine but a git-status shows this:
>
> $ git-status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: include/linux/netfilter/xt_CONNMARK.h
> # modified: include/linux/netfilter/xt_DSCP.h
> # modified: include/linux/netfilter/xt_MARK.h
> # modified: include/linux/netfilter/xt_TCPMSS.h
> # modified: include/linux/netfilter_ipv4/ipt_CONNMARK.h
> # modified: include/linux/netfilter_ipv4/ipt_DSCP.h
> # modified: include/linux/netfilter_ipv4/ipt_ECN.h
> # modified: include/linux/netfilter_ipv4/ipt_MARK.h
> # modified: include/linux/netfilter_ipv4/ipt_TCPMSS.h
> # modified: include/linux/netfilter_ipv4/ipt_TOS.h
> # modified: include/linux/netfilter_ipv4/ipt_TTL.h
> # modified: include/linux/netfilter_ipv6/ip6t_HL.h
> # modified: include/linux/netfilter_ipv6/ip6t_MARK.h
> # modified: net/ipv4/netfilter/ipt_ECN.c
> # modified: net/ipv4/netfilter/ipt_TOS.c
> # modified: net/ipv4/netfilter/ipt_TTL.c
> # modified: net/ipv6/netfilter/ip6t_HL.c
> # modified: net/netfilter/xt_CONNMARK.c
> # modified: net/netfilter/xt_DSCP.c
> # modified: net/netfilter/xt_MARK.c
> # modified: net/netfilter/xt_TCPMSS.c
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> git-fsck --strict --full finds no fault in the clone, git-reset --hard
> goes fine but changes nothing in the output of git-status. Some
> additional superficial investigation showed that git-diff doesn't even
> compare my checked out tree against the latest commit. Checkout of
> various commits shows the same issue.
>
> Can somebody please double-check this scenario for me just to validate
> that this happens only due to some particular factors combination on my
> box?
>
Your filesystem is not case sensitive and there are files with identical
names (apart from the case thing) in the Linux kernel repo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: corrupt object on git-gc
From: Yossi Leybovich @ 2007-11-09 15:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Yossi Leybovich
In-Reply-To: <473464A2.7080003@op5.se>
On Nov 9, 2007 8:46 AM, Andreas Ericsson <ae@op5.se> wrote:
>
> Is this a super-secret project or you can make a tarball of the .git
> directory and send it to me? Trying to track down the cause through
> email is decidedly slow.
>
Actually yes , I am not sure I can send the repository , I will
farther check that.
>
> One tree uses the object. I'm not sure if any commit-objects
> use the tree. Try
>
> for b in $(git branch --no-color -a | cut -b3-); do
> for rev in $(git rev-list HEAD); do
> git ls-tree -r $rev | grep -q 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
> test $? -eq 0 && echo $rev && break
> done
> done
tried this and it return empty
[mellanox@mellanox-compile ib]$
[mellanox@mellanox-compile ib]$ for b in $(git branch --no-color -a |
cut -b3-); do
> for rev in $(git rev-list HEAD); do
> git ls-tree -r $rev | grep -q 2d9263c6d23595e7cb2a21e5ebbb53655278dff8;
> test $? -eq 0 && echo $rev && break;
> done; done
[mellanox@mellanox-compile ib]$
[mellanox@mellanox-compile ib]$
[BTW I didn't notice u use the b varieble so I also tried gi rev-list
$b but still empty ]
I also tried to remove object and tree and apperently other trees and
commits reference to these objects
mv ../9458b3786228369c63936db65827de3cc06200 ../4b/
mv: cannot stat `../9458b3786228369c63936db65827de3cc06200': No such
file or directory
[mellanox@mellanox-compile ib]$ mv
.git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../4b/
[mellanox@mellanox-compile ib]$ mv
.git/objects/2d/9263c6d23595e7cb2a21e5ebbb53655278dff8 ../2d/
[mellanox@mellanox-compile ib]$ git-fsck --full
broken link from tree e5a0044c4ccae7635f07414c1f155bac72d25fd9
to tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
dangling commit 0d43a63623237385e432572bf61171713dcd8e98
dangling commit 4fc6b1127e4a7f4ff5b65a2dd8a90779b5aff3e0
dangling commit 7da607374fe2b1ae09228d2035dd608c73dad7c8
dangling commit 004ef09ae022c60a30f9cd61f90d18df5db3628e
broken link from tree 8bd00402b2a20024f4556107b8a729b0205657db
to tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
dangling commit 85112c6fabb6b8913ab244a8645d67380616eba6
missing tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
dangling commit bd98481afa93356fa6daa4b6f88c4e631ae2fd72
dangling commit e81e3d2c9c25e5bf5b31327b10b23f9bd0a6d056
dangling commit 92ff9b8cbc771345c9cde0c7fef2c23bb79242b9
>
> If it turns up empty, you *should* be able to safely delete
> 2d9263c6d23595e7cb2a21e5ebbb53655278dff8 and
> 4b9458b3786228369c63936db65827de3cc06200
>
> Make sure to take a backup first though.
a lot of commits and trees point to this
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
>
^ permalink raw reply
* Re: linux-2.6 clone with CygWin git
From: Simon Sasburg @ 2007-11-09 15:02 UTC (permalink / raw)
To: Medve Emilian; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174D8A2@az33exm24.fsl.freescale.net>
This is not a problem with git.
The kernel tree contains files which only differ from other files by case.
If on a case-insensitive filesystem this will cause problems like the
ones you noticed.
On Nov 9, 2007 3:29 PM, Medve Emilian <Emilian.Medve@freescale.com> wrote:
> Hello,
>
>
> I noticed that something might not be right with my CygWin git (latest
> CygWin relevant build packages + a few days old git build from the next
> & master branches). When I clone, say, Linus' tree over the native git
> protocol everything goes fine but a git-status shows this:
>
> $ git-status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: include/linux/netfilter/xt_CONNMARK.h
> # modified: include/linux/netfilter/xt_DSCP.h
> # modified: include/linux/netfilter/xt_MARK.h
> # modified: include/linux/netfilter/xt_TCPMSS.h
> # modified: include/linux/netfilter_ipv4/ipt_CONNMARK.h
> # modified: include/linux/netfilter_ipv4/ipt_DSCP.h
> # modified: include/linux/netfilter_ipv4/ipt_ECN.h
> # modified: include/linux/netfilter_ipv4/ipt_MARK.h
> # modified: include/linux/netfilter_ipv4/ipt_TCPMSS.h
> # modified: include/linux/netfilter_ipv4/ipt_TOS.h
> # modified: include/linux/netfilter_ipv4/ipt_TTL.h
> # modified: include/linux/netfilter_ipv6/ip6t_HL.h
> # modified: include/linux/netfilter_ipv6/ip6t_MARK.h
> # modified: net/ipv4/netfilter/ipt_ECN.c
> # modified: net/ipv4/netfilter/ipt_TOS.c
> # modified: net/ipv4/netfilter/ipt_TTL.c
> # modified: net/ipv6/netfilter/ip6t_HL.c
> # modified: net/netfilter/xt_CONNMARK.c
> # modified: net/netfilter/xt_DSCP.c
> # modified: net/netfilter/xt_MARK.c
> # modified: net/netfilter/xt_TCPMSS.c
> #
> no changes added to commit (use "git add" and/or "git commit -a")
>
> git-fsck --strict --full finds no fault in the clone, git-reset --hard
> goes fine but changes nothing in the output of git-status. Some
> additional superficial investigation showed that git-diff doesn't even
> compare my checked out tree against the latest commit. Checkout of
> various commits shows the same issue.
>
> Can somebody please double-check this scenario for me just to validate
> that this happens only due to some particular factors combination on my
> box?
>
>
> Thanks,
> Emil.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: linux-2.6 clone with CygWin git
From: David Brown @ 2007-11-09 15:03 UTC (permalink / raw)
To: Medve Emilian; +Cc: git
In-Reply-To: <598D5675D34BE349929AF5EDE9B03E270174D8A2@az33exm24.fsl.freescale.net>
On Fri, Nov 09, 2007 at 07:29:07AM -0700, Medve Emilian wrote:
># modified: include/linux/netfilter/xt_CONNMARK.h
>
>Can somebody please double-check this scenario for me just to validate
>that this happens only due to some particular factors combination on my
>box?
It's because of the case-insensitive nature of the filesystem. The kernel
contains both an xt_connmark.h and an xt_CONNMARK.h file, that are
different. But only one exists on Windows, so git sees the first one it
wrote as having been modified.
David
^ permalink raw reply
* [PATCH REPLACEMENT for 2/2] git status: show relative paths when run in a subdirectory
From: Johannes Schindelin @ 2007-11-09 15:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: David Symonds, Brian Gernhardt, Jon Smirl, Git Mailing List,
gitster
In-Reply-To: <7v8x593zyv.fsf@gitster.siamese.dyndns.org>
To show the relative paths, the function formerly called quote_crlf()
(now called quote_path()) takes the prefix as an additional argument.
While at it, the static buffers were replaced by strbufs.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Thu, 8 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > -static const char *quote_crlf(const char *in, char *buf, size_t sz)
> > +static const char *quote_crlf(const char *in, int len, char *buf, size_t sz,
> > + const char *prefix)
> > {
>
> This is not quote_*crlf* anymore.
>
> > @@ -118,8 +150,8 @@ static void wt_status_print_filepair(struct wt_status *s,
> > const char *one, *two;
> > char onebuf[PATH_MAX], twobuf[PATH_MAX];
> >
> > - one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
> > - two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
> > + one = quote_crlf(p->one->path, -1, onebuf, sizeof(onebuf), s->prefix);
> > + two = quote_crlf(p->two->path, -1, twobuf, sizeof(twobuf), s->prefix);
>
> I wonder if it makes more sense to use strbuf here...
Here you are.
builtin-runstatus.c | 1 +
t/t7502-status.sh | 91 +++++++++++++++++++++++++++++++++++++++++++++++++++
wt-status.c | 69 ++++++++++++++++++++++++++-------------
wt-status.h | 1 +
4 files changed, 139 insertions(+), 23 deletions(-)
create mode 100755 t/t7502-status.sh
diff --git a/builtin-runstatus.c b/builtin-runstatus.c
index 2db25c8..8d167a9 100644
--- a/builtin-runstatus.c
+++ b/builtin-runstatus.c
@@ -14,6 +14,7 @@ int cmd_runstatus(int argc, const char **argv, const char *prefix)
git_config(git_status_config);
wt_status_prepare(&s);
+ s.prefix = prefix;
for (i = 1; i < argc; i++) {
if (!strcmp(argv[i], "--color"))
diff --git a/t/t7502-status.sh b/t/t7502-status.sh
new file mode 100755
index 0000000..269b334
--- /dev/null
+++ b/t/t7502-status.sh
@@ -0,0 +1,91 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E. Schindelin
+#
+
+test_description='git-status'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ : > tracked &&
+ : > modified &&
+ mkdir dir1 &&
+ : > dir1/tracked &&
+ : > dir1/modified &&
+ mkdir dir2 &&
+ : > dir1/tracked &&
+ : > dir1/modified &&
+ git add . &&
+ test_tick &&
+ git commit -m initial &&
+ : > untracked &&
+ : > dir1/untracked &&
+ : > dir2/untracked &&
+ echo 1 > dir1/modified &&
+ echo 2 > dir2/modified &&
+ echo 3 > dir2/added &&
+ git add dir2/added
+'
+
+cat > expect << \EOF
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# new file: dir2/added
+#
+# Changed but not updated:
+# (use "git add <file>..." to update what will be committed)
+#
+# modified: dir1/modified
+#
+# Untracked files:
+# (use "git add <file>..." to include in what will be committed)
+#
+# dir1/untracked
+# dir2/modified
+# dir2/untracked
+# expect
+# output
+# untracked
+EOF
+
+test_expect_success 'status' '
+
+ git status > output &&
+ git diff expect output
+
+'
+
+cat > expect << \EOF
+# On branch master
+# Changes to be committed:
+# (use "git reset HEAD <file>..." to unstage)
+#
+# new file: ../dir2/added
+#
+# Changed but not updated:
+# (use "git add <file>..." to update what will be committed)
+#
+# modified: ../dir1/modified
+#
+# Untracked files:
+# (use "git add <file>..." to include in what will be committed)
+#
+# untracked
+# ../dir2/modified
+# ../dir2/untracked
+# ../expect
+# ../output
+# ../untracked
+EOF
+
+test_expect_success 'status with relative paths' '
+
+ (cd dir1 && git status) > output &&
+ git diff expect output
+
+'
+
+test_done
diff --git a/wt-status.c b/wt-status.c
index 03b5ec4..0d25362 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -82,33 +82,46 @@ static void wt_status_print_trailer(struct wt_status *s)
color_fprintf_ln(s->fp, color(WT_STATUS_HEADER), "#");
}
-static const char *quote_crlf(const char *in, char *buf, size_t sz)
+static char *quote_path(const char *in, int len,
+ struct strbuf *out, const char *prefix)
{
- const char *scan;
- char *out;
- const char *ret = in;
+ if (len > 0)
+ strbuf_grow(out, len);
+ strbuf_setlen(out, 0);
+
+ if (prefix) {
+ int off = 0;
+ while (prefix[off] && off < len && prefix[off] == in[off])
+ if (prefix[off] == '/') {
+ prefix += off + 1;
+ in += off + 1;
+ len -= off + 1;
+ off = 0;
+ } else
+ off++;
+
+ for (; *prefix; prefix++)
+ if (*prefix == '/')
+ strbuf_addstr(out, "../");
+ }
- for (scan = in, out = buf; *scan; scan++) {
- int ch = *scan;
- int quoted;
+ for (; (len < 0 && *in) || len > 0; in++, len--) {
+ int ch = *in;
switch (ch) {
case '\n':
- quoted = 'n';
+ strbuf_addstr(out, "\\n");
break;
case '\r':
- quoted = 'r';
+ strbuf_addstr(out, "\\r");
break;
default:
- *out++ = ch;
+ strbuf_addch(out, ch);
continue;
}
- *out++ = '\\';
- *out++ = quoted;
- ret = buf;
}
- *out = '\0';
- return ret;
+
+ return out->buf;
}
static void wt_status_print_filepair(struct wt_status *s,
@@ -116,10 +129,12 @@ static void wt_status_print_filepair(struct wt_status *s,
{
const char *c = color(t);
const char *one, *two;
- char onebuf[PATH_MAX], twobuf[PATH_MAX];
+ struct strbuf onebuf, twobuf;
- one = quote_crlf(p->one->path, onebuf, sizeof(onebuf));
- two = quote_crlf(p->two->path, twobuf, sizeof(twobuf));
+ strbuf_init(&onebuf, 0);
+ strbuf_init(&twobuf, 0);
+ one = quote_path(p->one->path, -1, &onebuf, s->prefix);
+ two = quote_path(p->two->path, -1, &twobuf, s->prefix);
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
switch (p->status) {
@@ -151,6 +166,8 @@ static void wt_status_print_filepair(struct wt_status *s,
die("bug: unhandled diff status %c", p->status);
}
fprintf(s->fp, "\n");
+ strbuf_release(&onebuf);
+ strbuf_release(&twobuf);
}
static void wt_status_print_updated_cb(struct diff_queue_struct *q,
@@ -205,8 +222,9 @@ static void wt_read_cache(struct wt_status *s)
static void wt_status_print_initial(struct wt_status *s)
{
int i;
- char buf[PATH_MAX];
+ struct strbuf buf;
+ strbuf_init(&buf, 0);
wt_read_cache(s);
if (active_nr) {
s->commitable = 1;
@@ -215,11 +233,12 @@ static void wt_status_print_initial(struct wt_status *s)
for (i = 0; i < active_nr; i++) {
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
color_fprintf_ln(s->fp, color(WT_STATUS_UPDATED), "new file: %s",
- quote_crlf(active_cache[i]->name,
- buf, sizeof(buf)));
+ quote_path(active_cache[i]->name, -1,
+ &buf, s->prefix));
}
if (active_nr)
wt_status_print_trailer(s);
+ strbuf_release(&buf);
}
static void wt_status_print_updated(struct wt_status *s)
@@ -254,7 +273,9 @@ static void wt_status_print_untracked(struct wt_status *s)
const char *x;
int i;
int shown_header = 0;
+ struct strbuf buf;
+ strbuf_init(&buf, 0);
memset(&dir, 0, sizeof(dir));
dir.exclude_per_dir = ".gitignore";
@@ -291,9 +312,11 @@ static void wt_status_print_untracked(struct wt_status *s)
shown_header = 1;
}
color_fprintf(s->fp, color(WT_STATUS_HEADER), "#\t");
- color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%.*s",
- ent->len, ent->name);
+ color_fprintf_ln(s->fp, color(WT_STATUS_UNTRACKED), "%s",
+ quote_path(ent->name, ent->len,
+ &buf, s->prefix));
}
+ strbuf_release(&buf);
}
static void wt_status_print_verbose(struct wt_status *s)
diff --git a/wt-status.h b/wt-status.h
index 7744932..f58ebcb 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -23,6 +23,7 @@ struct wt_status {
int workdir_untracked;
const char *index_file;
FILE *fp;
+ const char *prefix;
};
int git_status_config(const char *var, const char *value);
--
1.5.3.5.1645.g1f4df
^ permalink raw reply related
* git 1.5.3.5 error over NFS
From: Bill Lear @ 2007-11-09 15:31 UTC (permalink / raw)
To: git
I've brought this up before, but I don't recall a resolution to it.
We have an NFS-mounted filesystem, and git pull is choking on it.
% uname -a
Linux uhlr.zopyra.com 2.6.9-42.0.2.ELsmp #1 SMP Wed Aug 23 13:38:27 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
% git --version
git version 1.5.3.5
% git pull
remote: Generating pack...
remote: Done counting 998 objects.
remote: Result has 836 objects.
remote: Deltifying 836 objects.
remote: 100% (836/836) done
Indexing 836 objects...
remote: Total 836 (delta 526), reused 688 (delta 380)
100% (836/836) done
Resolving 526 deltas...
fatal: cannot pread pack file: No such file or directory
fatal: index-pack died with error code 128
fatal: Fetch failure: git://source/repo
I looked through the archives of this list and did not see a final
resolution, other than a suspected bug in the OS NFS code.
Do we just need to update our OS?
Bill
^ permalink raw reply
* Re: corrupt object on git-gc
From: Johannes Sixt @ 2007-11-09 15:34 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: Andreas Ericsson, git, Yossi Leybovich
In-Reply-To: <4fe79b4b0711090701g7a43cdfdi5e20e5ffb437d7bb@mail.gmail.com>
Yossi Leybovich schrieb:
> [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']
You can try to create a clone (after you have fixed up the artificial
breakages that you made). If that goes well, then the bad object is
referenced only from reflogs.
-- Hannes
^ permalink raw reply
* git-gui messes up the diff view on non ASCII characters
From: Peter Baumann @ 2007-11-09 15:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
I'm managing some UTF-8 encoded LaTeX files in git, which include some
non ASCII characters like the german ä,ö and ü. If I view the diff with
git-diff on an UTF8 enabled terminal, all looks nice. So does the diff
view in gitk after I commited my changes. Only git-gui shows some
"strange" characters, so I assume it is an encoding problem.
I have to admit that I'm totally unaware how this should work, but at
least I think my configuration is correct here, because otherwise git-diff
or gitk would show the same behaviour. Is there anything which could be
done to make git-gui happy, too?
-Peter
^ permalink raw reply
* Re: corrupt object on git-gc
From: Yossi Leybovich @ 2007-11-09 15:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Andreas Ericsson, git, Yossi Leybovich
In-Reply-To: <47347E0E.1040205@viscovery.net>
On Nov 9, 2007 10:34 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Yossi Leybovich schrieb:
> > [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']
>
> You can try to create a clone (after you have fixed up the artificial
> breakages that you made). If that goes well, then the bad object is
> referenced only from reflogs.
>
git clone ib ib-clone
Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/
0 blocks
[mellanox@mellanox-compile ib-clone]$ cd ib-clone/
[mellanox@mellanox-compile ib-clone]$ git branch -a
* mlx4
origin/HEAD
origin/master
origin/mlx4
origin/mlx4-work
origin/mthca
origin/second_port
[mellanox@mellanox-compile ib-clone]$ git-gc
Generating pack...
Done counting 3288 objects.
Deltifying 3288 objects...
error: corrupt loose object '4b9458b3786228369c63936db65827de3cc06200'
fatal: object 4b9458b3786228369c63936db65827de3cc06200 cannot be read
error: failed to run repack
So still I cant pack my repository
> -- Hannes
>
>
^ permalink raw reply
* Re: Inconsistencies with git log
From: Linus Torvalds @ 2007-11-09 15:54 UTC (permalink / raw)
To: Jon Smirl; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <9e4733910711071609t3e5412f1mf02e501b2d820bb3@mail.gmail.com>
On Wed, 7 Nov 2007, Jon Smirl wrote:
>
> Then why doesn't this work?
Jon, lookie here:
> jonsmirl@terra:~/mpc5200b$ git log Documentation
> all the log for Documentation....
> jonsmirl@terra:~/mpc5200b$ cd Documentation
> jonsmirl@terra:~/mpc5200b/Documentation$ git log Documentation
Instead of the above sequence, do:
jonsmirl@terra:~/mpc5200b$ ls Documentation
.. all the files in Documentation ..
jonsmirl@terra:~/mpc5200b$ cd Documentation
jonsmirl@terra:~/mpc5200b/Documentation$ ls Documentation
and now tell me, why doesn't that work? And can't you see how *stupid*
your complaint is?
The rule is:
- git log without arguments gives the whole, unabridged, and full
history.
- git log with arguments gives the *simplified* history for those
arguments.
But the arguments - if they exist - are always relative. You want things
like filename completion to work. Making the pathname arguments absolute
would be horrible. Think about it: it's just much more logical to always
be able to say "I want the log for file xyz", and you don't want that to
be absolute, since you shouldn't care where in the tree you are.
And the fact that git log gives the whole history when you don't give any
arguments at all IN NO WAY makes it any more sensible to give "absolute"
pathnames. The history being "whole" has nothing to do with the pathnames
being "absolute". The two are totally independent issues.
Linus
^ permalink raw reply
* Re: corrupt object on git-gc
From: Johannes Sixt @ 2007-11-09 16:03 UTC (permalink / raw)
To: Yossi Leybovich; +Cc: Andreas Ericsson, git, Yossi Leybovich
In-Reply-To: <4fe79b4b0711090753r52abd3e1ree64271c0fa229f6@mail.gmail.com>
Yossi Leybovich schrieb:
> On Nov 9, 2007 10:34 AM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> Yossi Leybovich schrieb:
>>> [about corrupt loose object '4b9458b3786228369c63936db65827de3cc06200']
>> You can try to create a clone (after you have fixed up the artificial
>> breakages that you made). If that goes well, then the bad object is
>> referenced only from reflogs.
>>
>
>
> git clone ib ib-clone
> Initialized empty Git repository in /home/mellanox/work/symm/ib-clone/.git/
> 0 blocks
Make this:
git clone file:///home/mellanox/work/symm/ib ib-clone
otherwise you get a hard-linked identical copy, but you want to use the git
protocol to create the clone.
-- Hannes
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox