Sanjoy Mahajan <[EMAIL PROTECTED]> writes:
> + git bisect bad
> Bisecting: 2 revisions left to test after this
> + cat .git/HEAD
> b4634484815e1879512a23e4f59eef648135c30a
> + git bisect bad
> b4634484815e1879512a23e4f59eef648135c30a is first bad commit
> diff-tree b4634484815e1879512a23e4f59eef64
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> While I have not updated the send-pack : syntax, I
> added a horrible hack that some people may love to see. This
> removes the need to use git-rev-parse from many commands.
Yes, I think this makes sense. We had three different sha1 parsers:
get_s
Linus Torvalds <[EMAIL PROTECTED]> writes:
> In this format, "src" makes sense as a generic sha1_name, and _not_
> necessarily limited to a ref-name.
>
> IOW, there's really no reason to not allow
>
> git-send-pack .. dest .. :dst-ref
>
> where "" may be something else than a ref (but a ref
I have been having lots of fun using 'git bisect' to find the commit
that broke S3 wake on my laptop. But in its last step it gives an
answer that cannot be right. I had not used git until now, so I may be
missing something obvious: Corrections will be gratefully received. I'm
using git from git
fix one 'should it be static?' warning and
two 'mixing declarations and code' warnings.
Signed-off-by: Alecs King <[EMAIL PROTECTED]>
---
connect.c|3 ++-
ssh-pull.c |2 +-
tools/mailinfo.c |2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/connect.c
Hi,
My apologies if this has already been found and reported; I'm not
tracking the list closely.
It seems that newly introduced files are not shown in gitweb.
For example, see the following commit:
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fce0d5740322b98b863f9e
Well, I pushed it out, although I do agree that we should be
able to give anything get_sha()-able on the source side of the
push. Probably a revised version should have the following
semantics:
$ git-send-pack [--all] [...]
- When no is specified:
- with '--all', it is the same as spe
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> > git-send-pack parent $(git-rev-parse HEAD^):master
>
> When I do something like your example, I create a temporary
> lightweight tag and push it. Snapshots in JIT are just a bunch
> of lightweight tags so..
I like the scripting, and combining
Linus Torvalds <[EMAIL PROTECTED]> writes:
> git-send-pack parent $(git-rev-parse HEAD^):master
>
> and there's no real reason why that syntax shouldn't just work: it's
> entirely logical to say "I want to push out the parent of my HEAD as
> 'master' on the other end", and that's _exactly_
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> This allows git-send-pack to push local refs to a destination
> repository under different names.
Looks good, except I was almost hoping for one modification:
> Here is the name mapping rules for refs.
>
> * If there is no ref mapping on the comman
Fixed location of HTML documents in debian doc-base file.
Without this fix debian package won't install properly (complains
about missing /usr/share/doc/git-core/html directory).
---
debian/git-core.doc-base |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
194759c0447f88804dfb43615
Linus Torvalds <[EMAIL PROTECTED]> writes:
> The real problem with git-send-pack is that the local and remote names
> have to be the same, which is a bug, really. It _should_ be perfectly fine
> to do something like
>
> git-send-pack ..dest.. localname:remotename
>
> which would push the l
Hi,
On Wed, 3 Aug 2005, Linus Torvalds wrote:
On Wed, 3 Aug 2005, Johannes Schindelin wrote:
I try to write a "git annotate" based on the output of git-whatchanged.
You can't. It's fundamentally not doable, because you lose the merge
information.
That's why I said I need git-rev-tree. In
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> Wouldn't something like this work equally well?
Nope, for several reasons:
- it's _horribly_ inefficient (ie it traverses directories that it
doesn't need to)
- it shows all the changeset comments, regardless of whether they are
releant or
Martin Sivak <[EMAIL PROTECTED]> writes:
> I mean, how would you setup different identities for more user
> accounts on the same server (it doesn't happen often, but..)?
I do not claim the way I do is the best way, but I do that all
the time.
I just use different "name" to connect, by setting up
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Btw, I'm not sure this is a wonderful idea. I found it useful for doing
>
> git-whatchanged -p drivers/scsi/aic7xxx/aic79xx*
>
> since I was interested in seeign if only that particular driver had had
> changes. But it's hacky and pretty limited,
> I understand why you would want this if your ssh binary is
> called something other than ssh [*1*], but I doubt the example
> you gave needs this patch. Could you explain why having
> something like this in your .ssh/config file is not enough?
>
> Host foo.bar.xz
> Protocol 1
>
On Wednesday 03 August 2005 20:07, Junio C Hamano wrote:
> Josef, could you give it a try please?
Perfect. Thanks.
Josef
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.htm
On Wed, 3 Aug 2005, Josef Weidendorfer wrote:
>
> But my example shows that the error happens even with 2 branches totally
> unrelated to each other: if branch1 got a new commit, you can not push to
> branch2 from another clone.
Sure you can.
git-send-pack remote branch2
and you've j
On Wed, 3 Aug 2005, Josef Weidendorfer wrote:
>
> Yes it is. To reproduce:
> Create a repository with 2 branches.
> Make 2 clones of the 2 branches via SSH.
> Make a commit on one clone and push.
> Make another commit on the other clone and push => ERROR
This works perfectly fine, you just have
This patch seems to fix the problem.
* If the original value of remote ref refers to an object we do
not have, and if the ref is one of the branches we are trying
to push, we refuse to update it.
* Otherwise, we do not attempt to use such an value when
computing what objects to put in
On Wed, 3 Aug 2005, Johannes Schindelin wrote:
>
> On Wed, 3 Aug 2005, Linus Torvalds wrote:
>
> > Are you sure you have a good git version on master? I've never seen
> > anything like that, and I push all the time..
>
> Call him Zaphod: he has two heads (master and pu). You don't.
Oh, but I
On Wed, 3 Aug 2005, Johannes Schindelin wrote:
>
> I try to write a "git annotate" based on the output of git-whatchanged.
You can't. It's fundamentally not doable, because you lose the merge
information.
So you need to use a combination of git-rev-list _and_ git-whatchanged.
Use the "--par
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> I think in addition to the existing ref_newer() check, which
> makes sure you are advancing the remote head, not just replacing
> with something unrelated, making sure that we have objects
> referenced by ref->old_sha1 we obtained from the remote on
I ended up looking at wildcards in pathspecs, but wasn't quite ready
enough to pay the price of real wildcards. This limited form is the end
result.
It allows a final '*' in the path matching to indicate that we don't care
about the "match exact files/subdirectories only" rule.
So while
On Wednesday 03 August 2005 19:08, you wrote:
> Yes it is. To reproduce:
You do not need 2 clones.
It is enough to have one clone with a branch, and you make a commit in the
original repository.
Afterwards, pushing a new commit from the clone gives the error.
After pulling the missing commit fro
On Wednesday 03 August 2005 19:37, you wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
> > I started out to make the "-f" flag to send-file work around it, but I
> > never finished that, partly because it really ends up being the same
> > thing as "git-fetch-pack" in reverse, which was against
Linus Torvalds <[EMAIL PROTECTED]> writes:
> I started out to make the "-f" flag to send-file work around it, but I
> never finished that, partly because it really ends up being the same thing
> as "git-fetch-pack" in reverse, which was against the whole point of
> git-send-pack. Send-pack is mean
Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> ~/tmp/git/clone2> cg-push
> 'refs/heads/branch2': updating from 80e4d426dd4c865b943cc1121b580a946eee921d
> to 8196067677e3415ce404ea5bc35731ac7d56115d
> fatal: bad object f7e944b036fd00af656b262140c1dc93ceffadb1
> Packing 0 objects
> Unpacking 0 ob
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > Are you sure you have a good git version on master? I've never seen
> > anything like that, and I push all the time..
>
> I have been esuspecting that it happens only because I rewind
> and rebase "p
Martin Sivak <[EMAIL PROTECTED]> writes:
> This patch make possible to use alternate ssh binary or ssh helper
> script. The script can be used to give additional parameters to ssh
> binary (like private key, protocol version, ...).
>
> Example script could look like this:
>
> #!/bin/sh
> ssh -1 -i
On Wednesday 03 August 2005 18:50, you wrote:
> Hi,
>
> On Wed, 3 Aug 2005, Linus Torvalds wrote:
> > Are you sure you have a good git version on master? I've never seen
> > anything like that, and I push all the time..
>
> Call him Zaphod: he has two heads (master and pu). You don't. As I said in
IIRC, git-local-pull still doesn't work for a packed source repository,
because it doesn't include the possibility of copying a pack (or
extracting an object) if the requested object is in a pack.
I can probably fix it if anyone cares, but it's not something I use
personally, so I don't know if
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Are you sure you have a good git version on master? I've never seen
> anything like that, and I push all the time..
I have been esuspecting that it happens only because I rewind
and rebase "pu", which you never do. The thing is, even though
I rewind
Hi,
On Wed, 3 Aug 2005, Linus Torvalds wrote:
Are you sure you have a good git version on master? I've never seen
anything like that, and I push all the time..
Call him Zaphod: he has two heads (master and pu). You don't. As I said in
another mail, this could be very well related to Junio's
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > I've lost that state. Can you explain a bit mroe..
>
> Sorry, you have not lost anything. It is my bad that this is
> the first time I brought it up. I've been seeing that from time
> to time when I
Hi,
On Wed, 3 Aug 2005, Junio C Hamano wrote:
Sorry, you have not lost anything. It is my bad that this is
the first time I brought it up. I've been seeing that from time
to time when I push to either my "send to master" repository
from my working repository, or from the "send to master"
repo
Linus Torvalds <[EMAIL PROTECTED]> writes:
> I've lost that state. Can you explain a bit mroe..
Sorry, you have not lost anything. It is my bad that this is
the first time I brought it up. I've been seeing that from time
to time when I push to either my "send to master" repository
from my worki
On Wed, 3 Aug 2005, Junio C Hamano wrote:
>
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > Yeah, probably not. git-rev-list does so much more than git-rev-tree ever
> > did.
>
> Does rev-list do --edges ;-)?
No, but does anybody use it? It _may_ be interesting as a git-merge-base
thing, b
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Yeah, probably not. git-rev-list does so much more than git-rev-tree ever
> did.
Does rev-list do --edges ;-)?
BTW, I have two known bugs/problems that I haven't resolved,
which is bothering me quite a bit. Yes, it is my fault (lack of
time and conc
This patch make possible to use alternate ssh binary or ssh helper
script. The script can be used to give additional parameters to ssh
binary (like private key, protocol version, ...).
Example script could look like this:
#!/bin/sh
ssh -1 -i myprivatekey.key "$@"
The patch itself is realy very s
On Tue, 2 Aug 2005, Junio C Hamano wrote:
>
> How about git-rev-tree? Does anybody care?
Yeah, probably not. git-rev-list does so much more than git-rev-tree ever
did.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PR
Hi,
On Tue, 2 Aug 2005, Junio C Hamano wrote:
Linus Torvalds <[EMAIL PROTECTED]> writes:
It has no point any more, all the tools check the file status on their
own, and yes, the thing should probably be removed.
How about git-rev-tree? Does anybody care?
I try to write a "git annotate" b
- Call inflateEnd to release zlib state after use.
- After resolving delta, free base object data.
Signed-off-by: Sergey Vlasov <[EMAIL PROTECTED]>
---
unpack-objects.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
890ab530c0c0aad5c070690498d3b1254c7a30bc
diff --git a/unpack-o
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Anyone have any good scripts for taking patches in email and turning
> them into git commits, preferrably while preserving the author
> information?
StGIT can do this as well, via the 'stg import -m' command. You will
see it as a GIT commit (with 'git
Hello,
sometimes I have to work in trees for which I have only read
permissions; cogito has problems then - for example:
-> cg-diff
fatal: unable to create new cachefile
fatal: unable to create temp-file
It would be nice if there was at least a way to specify some TMPDIR
instead of t
Hi, Ryan Anderson wrote:
> Since these emails are sent *very* fast, delivery order tends to be the
> dominating factor in how they sort in your inbox, as they will all have
> the same time. So that's a trifle annoying.
That's trivially fixable: just generate your own Date: header and
add a secon
47 matches
Mail list logo
