* Re: VCS comparison table
From: Aaron Bentley @ 2006-10-25 18:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Erik Bågfors, bazaar-ng, git, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0610231623340.3962@g5.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
>
> On Tue, 24 Oct 2006, Erik Bågfors wrote:
>
>>I don't see any problem doing a "gitk --all" equivalent in bzr.
>
>
> The problem? How do you show a commit that is _common_ to two branches,
> but has different revision names in them?
If you're talking about the old-style single-integer revnos, each
revision only has one of those, because that revision dictates the path
you must take to the origin when determining its revno. Many others may
share that revno, but each revision has only one.
The new-style dotted-series-of-ints revnos, I agree, will change.
They're not something I use.
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFFP6/B0F+nu1YWqI0RAs76AJ9nE4BnL2tLDPQwqjQvCi6okDTdpQCdFQ9V
GoL1BWO+L2FxjLjRrCjKtuY=
=yQ6t
^ permalink raw reply
* Re: (unknown)
From: Junio C Hamano @ 2006-10-25 18:41 UTC (permalink / raw)
To: andyparkins; +Cc: git
In-Reply-To: <E1Gck4m-0003J1-00@dvr.360vision.com>
andyparkins@gmail.com writes:
> From b149c0fca7399030225750958bf5c962c3796b44 Mon Sep 17 00:00:00 2001
> From: Andy Parkins <andyparkins@gmail.com>
> Date: Wed, 25 Oct 2006 15:49:50 +0100
> Subject: [PATCH] Make new builtin cherry match documentation for "+" and "-"
> To: git@vger.kernel.org
> X-TUID: 218b478df3f8d847
> X-UID: 128
> X-Length: 1090
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> Message-Id: <200610251549.51121.andyparkins@gmail.com>
I'd be commenting on your patch but won't be able to take any of
them until these "Subject: (unknown)" are corrected.
> "+" and "-" don't match the documentation, where "+" means the patch /is/ in
> upstream, "-" means it isn't
The documentation was utterly wrong. The comment at the
beginning of git-cherry.sh was better but slightly wrong.
I have a few fixes queued but I was busy for the last couple of
nights and haven't pushed them out.
^ permalink raw reply
* Re: (unknown)
From: Junio C Hamano @ 2006-10-25 18:38 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610251610.02446.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2006 October 25 15:53, Jakub Narebski wrote:
>
>> Check if "git clone --use-separate-remote" isn't what you want.
>
> I did try that, but then the branches don't appear in git branch. I still
> like that they exist.
"git branch -r" perhaps.
^ permalink raw reply
* Re: git-*arch* in git-arch rpm
From: Junio C Hamano @ 2006-10-25 18:35 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20061025112327.16220.qmail@e5d824cd35b8a9.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> On Tue, Oct 24, 2006 at 10:35:38PM -0700, Junio C Hamano wrote:
>> Gerrit Pape <pape@smarden.org> writes:
>> > Hi, there're two programs in the git-arch rpm that shouldn't be there:
>
>> So we need at least this?
>
> And this I think, but can't test it.
Thanks.
I ended up doing something very similar to yours after sending
out the initial patch (my FC box is a notebook resurrected from
boneyard and I need to sneakernet to do any RPM work, so latency
of feedback from that box is rather long X-<).
^ permalink raw reply
* Re: [PATCH] document the <tree ish> <file> blob reference syntax
From: Junio C Hamano @ 2006-10-25 18:33 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <38fafea491402334df335c486270ebe9@pinky>
Andy Whitcroft <apw@shadowen.org> writes:
> It is possible to specify a specific file within a tree-ish
> symbolically. For example you can find the contents of
> a specific file in a specific commit as below:
>
> git cat-file -p v1.2.4:git-prune.sh
Didn't we document this elsewhere recently in git-rev-parse?
How about this instead?
-- >8 --
[PATCH] Refer to git-rev-parse:Specifying Revisions from git.txt
The brief list given in "Symbolic Identifiers" section of the
main documentation is good enough for overview, but help the
reader to find a more comrehensive list as needed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 3af6fc6..b00607e 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -562,6 +562,9 @@ HEAD::
a valid head 'name'
(i.e. the contents of `$GIT_DIR/refs/heads/<head>`).
+For a more complete list of ways to spell object names, see
+"SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1].
+
File/Directory Structure
------------------------
--
1.4.3.2.gc1a4
^ permalink raw reply related
* Re: [PATCH qgit] Change also tag marks when changing graph size
From: Marco Costalba @ 2006-10-24 19:45 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Git Mailing List
In-Reply-To: <200610242041.22230.Josef.Weidendorfer@gmx.de>
On 10/24/06, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 24 October 2006 18:47, Marco Costalba wrote:
> > When changing graph size with CTRL+ and CTRL-
> > update also tag/branch marks.
> >
> > Also little cleanup.
> > ---
> >
> > Hi Josef,
> >
> > please tell me if you are working on the same files, in this case I
> > will step back and wait you to finish your patch series and eventually
> > resubmit this one at the end.
>
> No, that is fine. Currently, I have not much time.
> Just curious: What did you expect next in my patch series? :-)
>
Quoting from your last e-mail:
"The new painting code regroups the drawing commands in
multiple switch-statements to prepare for far simpler code
with booleans for different elements, and not one type only."
Indeed it's not clear to me what the above line means exactly, it just
smells like there is something more cooking. Sorry If I've
misunderstood.
> Now that everything is drawn directly, the question is what to do with
> the new flexibility. E.g. we _could_ implement different
> graph drawing algorithms next to the original qgit one,
> e.g. mimicking gitk.
One little secret of current algorithm is that it just needs to know
the "state" of previous revision graph to calculate the next one. (see
Git::updateLanes() and lanes.cpp), it's a kind of a "rasterized" graph
drawing, i.e. line by line.
I didn't studied gitk in deep but it seems a little bit less simpler.
Anyway if you are interested it's for sure worth trying ;-)
^ permalink raw reply
* Re: [git failure] failure pulling latest Linus tree
From: H. Peter Anvin @ 2006-10-25 17:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b9ce1tk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> For some reason which we haven't been able to track down yet, the
>> recent load imposed by FC6 caused zeus1's load to skyrocket, but not
>> zeus2's... it's largely a mystery.
>
> Would kernel.org prefer RPM cut on a FC6 box now?
>
No; since we have now (finally) archieved "OS parity" we're going to
keep hera, zeus1, and zeus2 in sync going forward.
>> HOWEVER, git 1.4.3 seems to have been bad chicken. When we ran it we
>> got a neverending stream of segfaults in the logs.
>
> If that is git-daemon dying when talking to older clients, that
> has been fixed in 1.4.3.2 (it's virtual hosting support had an
> off-by-one wrong check to tell older clients from newer one).
>
> Sorry about that -- we heard about the incompatibility this
> Monday.
This stuff happens... it's dealt with now.
-hpa
^ permalink raw reply
* Re: [git failure] failure pulling latest Linus tree
From: Junio C Hamano @ 2006-10-25 17:35 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <453F8630.2000608@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> For some reason which we haven't been able to track down yet, the
> recent load imposed by FC6 caused zeus1's load to skyrocket, but not
> zeus2's... it's largely a mystery.
Would kernel.org prefer RPM cut on a FC6 box now?
> HOWEVER, git 1.4.3 seems to have been bad chicken. When we ran it we
> got a neverending stream of segfaults in the logs.
If that is git-daemon dying when talking to older clients, that
has been fixed in 1.4.3.2 (it's virtual hosting support had an
off-by-one wrong check to tell older clients from newer one).
Sorry about that -- we heard about the incompatibility this
Monday.
^ permalink raw reply
* Re: Bugreport: core-tutorial example outdated?
From: J. Bruce Fields @ 2006-10-25 17:24 UTC (permalink / raw)
To: Clemens Koller; +Cc: git
In-Reply-To: <453F9BA5.3020104@anagramm.de>
On Wed, Oct 25, 2006 at 07:15:17PM +0200, Clemens Koller wrote:
> Hi there!
>
> I just studied
> http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html
> to get more into the details of git. But the following commands:
>
> $ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
> $ git-cat-file "blob" 557db03
>
> just bring up a
>
> fatal: Not a valid object name 557db03de
>
> I guess the documentation is slightly outdated and might need a fix.
Works for me. The precise names there depend on the files you create
being byte-for-byte identical to the ones created by the echo commands
in the tutorial. If yours aren't identical, then you should just use
the names that the previous ls command instead.
^ permalink raw reply
* Re: Bugreport: core-tutorial example outdated?
From: Johannes Schindelin @ 2006-10-25 17:23 UTC (permalink / raw)
To: Clemens Koller; +Cc: git
In-Reply-To: <453F9BA5.3020104@anagramm.de>
Hi,
On Wed, 25 Oct 2006, Clemens Koller wrote:
> I just studied
> http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html
> to get more into the details of git. But the following commands:
>
> $ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
> $ git-cat-file "blob" 557db03
>
> just bring up a
>
> fatal: Not a valid object name 557db03de
Did you actually add a file with the content "Hello World\n"? If not, you
should not be surprised.
Hth,
Dscho
^ permalink raw reply
* Re: VCS comparison table
From: David Rientjes @ 2006-10-25 17:21 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Lachlan Patrick, bazaar-ng, git
In-Reply-To: <20061025094900.GA26989@coredump.intra.peff.net>
On Wed, 25 Oct 2006, Jeff King wrote:
> Yes, it's true that some operations might be easier to play with in the
> shell. However, does it actually come up that you want to modify
> existing git programs? The more common usage seems to be gluing the
> plumbing together in interesting ways, and that is still very much
> supported.
>
Yes, it does. I'll give you an example from six months ago: there was a
need for the group that I work with to support a faster type of hashing
function for whatever reason. This would have been simple with previous
versions of git, but if you've ever looked at the SHA1 code in git, you'll
realize that you're probably better off never trying to touch it. There
is absolutely _no_ abstraction of it at all and the code is so deeply
coupled in the source that abstracting it away is a pain.
Likewise, there is always room for personal or organizational tweaks on
the part of the developer. Things like distributed pulling and
merging should actually be pretty simple to implement if the complexity
wasn't so high in the merge-* family. This is something I implemented
after an enormous headache because we were dealing with very large
projects: yes, larger than the Linux kernel. And this is _exactly_ where
piping would help; we have implementations of distributed grep over very
large datasets (on the order of terabytes).
> You can do the same thing in C. In fact, look at how similar
> git-whatchanged, git-log, and git-diff are.
>
No you can't. Making a one line addition, commenting out a line, or
changing a simple flag in a shell script is much easier. And like I
already said, you can save multiple versions for your common use if you
work on a specific project much of the time and change how it operates
depending on the needs of that one project so you never need to do it
again or you can _distribute_ that shell file to your colleagues so that
everybody is doing their work via the same method. This makes it so you
can just say "type X, then type Y, then type Z" and everybody is operating
together without training them on how to use git.
> > This all became very obvious when the tutorials came out on "how to use
> > git in 20 commands or less" effectively. These tutorials shouldn't need
> > to exist with an information manager that started as a quick, efficient,
> > and _simple_ project. You're treating git development in the same light
>
> Sorry, I don't see how this is related to the programming language _at
> all_. Are you arguing that the interface of git should be simplified so
> that such tutorials aren't necessary? If so, then please elaborate, as
> I'm sure many here would like to hear proposals for improvements. If
> you're arguing that git now has too many features, then which features
> do you consider extraneous?
>
It's not, it's related to the original vision of git which was meant for
efficiency and simplicity. A year ago it was very easy to pick up the
package and start using it effectively within a couple hours. Keep in
mind that this was without tutorials, it was just reading man pages.
Today it would be very difficult to know what the essential commands are
and how to use them simply to get the job done, unless you use the
tutorials. This _inherently_ goes against the approach of trying to
provide something that is simple to the developer.
Revision control is something that should exist in the background that
does it's simple job very efficiently. Unfortunately git has tried to
move its presence into the foreground and requiring developers to spend
more time on learning the system.
Have you never tried to show other people git without giving them a
tutorial on the most common uses? Try it and you'll see the confusion.
That _specifically_ illustrates the ever-increasing lack of simplicity
that git has acquired.
> I don't agree with this. There are tons of enhancements that I find
> useful (e.g., '...' rev syntax, rebasing with 3-way merge, etc) that I
> think other developers ARE using. There are scalability and performance
> improvements. And there are new things on the way (Junio's pickaxe work)
> that will hopefully make git even more useful than it already is.
>
There are _not_ scalability improvements. There may be some slight
performance improvements, but definitely not scalability. If you have
ever tried to use git to manage terabytes of data, you will see this
becomes very clear. And "rebasing with 3-way merge" is not something
often used in industry anyway if you've followed the more common models
for revision control within large companies with thousands of engineers.
Typically they all work off mainline.
> If you don't think recent git versions are worthwhile, then why don't
> you run an old version? You can even use git to cherry-pick patches onto
> your personal branch.
>
I do. And that's why I would recommend to any serious developer to use
1.2.4; this same version that I used for kernel development at Google.
> Where?
>
Few months back here on the mailing list. When I tried cleaning up even
one program, I got the response back from the original author "why fix a
non-problem?" because his argument was that since it worked the code
doesn't matter.
http://marc.theaimsgroup.com/?l=git&m=115589472706036
And that is simply one thread of larger conversations that have taken
place off-list and aren't archived.
> I don't agree, but since you haven't provided anything specific enough
> to discuss, there's not much to say.
>
If there's a question about some of the sloppiness in the git source code
as it stands today, that's a much bigger issue than the sloppiness. My
advice would be to pick up a copy of K&R's 2nd edition C programming
language book, read it, and then take a tour of the source code.
> Can you name one customization that you would like to perform now that
> you feel can't be easily done (and presumably that would have been
> easier in the past)?
>
Yes, those mentioned above.
^ permalink raw reply
* Bugreport: core-tutorial example outdated?
From: Clemens Koller @ 2006-10-25 17:15 UTC (permalink / raw)
To: git
Hi there!
I just studied
http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html
to get more into the details of git. But the following commands:
$ git-cat-file -t 557db03de997c86a4a028e1ebd3a1ceb225be238
$ git-cat-file "blob" 557db03
just bring up a
fatal: Not a valid object name 557db03de
I guess the documentation is slightly outdated and might need a fix.
Best greets,
--
Clemens Koller
_______________________________
R&D Imaging Devices
Anagramm GmbH
Rupert-Mayer-Str. 45/1
81379 Muenchen
Germany
http://www.anagramm.de
Phone: +49-89-741518-50
^ permalink raw reply
* Re: [git failure] failure pulling latest Linus tree
From: H. Peter Anvin @ 2006-10-25 17:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Jes Sorensen, Junio C Hamano, git
In-Reply-To: <20061025161323.GF11916@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Wed, Oct 25, 2006 at 05:43:44PM CEST, I got a letter
> where "H. Peter Anvin" <hpa@zytor.com> said that...
>> HOWEVER, git 1.4.3 seems to have been bad chicken. When we ran it we
>> got a neverending stream of segfaults in the logs.
>
> Could you provide some details, please? Ideally a backtrace or
> something? Also, it might be a good idea to use 1.4.3.2 since it fixes a
> problem with compatibility of git-daemon and older git clients.
>
I'm afraid I can't anymore since I've flushed those binaries. 1.4.3.2
works fine, it seems, but we hadn't gotten that update until yesterday.
^ permalink raw reply
* Re: [PATCH 1/2] New stg command: assimilate
From: Catalin Marinas @ 2006-10-25 16:41 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061025163231.GA30478@diana.vm.bytemark.co.uk>
On 25/10/06, Karl Hasselström <kha@treskal.com> wrote:
> On 2006-10-22 15:08:02 +0200, Karl Hasselström wrote:
>
> > + def name_taken(name):
> > + return patchname in name2patch or crt_series.patch_exists(patchname)
>
> I just realized, by means of an infinite loop, that "patchname" should
> be replaced with just "name" in the body of this function. Would you
> like me to resend the patch?
I can do it, no need to resend. I'll push the patch tonight and you
can check it (I also fixed the "reversed" call as it is not available
in my Python implementation).
--
^ permalink raw reply
* Re: [PATCH 1/2] New stg command: assimilate
From: Karl Hasselström @ 2006-10-25 16:32 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20061022130802.17015.50188.stgit@localhost>
On 2006-10-22 15:08:02 +0200, Karl Hasselström wrote:
> + def name_taken(name):
> + return patchname in name2patch or crt_series.patch_exists(patchname)
I just realized, by means of an infinite loop, that "patchname" should
be replaced with just "name" in the body of this function. Would you
like me to resend the patch?
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: git-merge-subordinate
From: Shawn Pearce @ 2006-10-25 16:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git
In-Reply-To: <Pine.LNX.4.63.0610251819080.3286@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 25 Oct 2006, Jakub Narebski wrote:
>
> > Matthew Wilcox wrote:
> >
> > > Linus doesn't like seeing unnecessary merges in his tree. I'm not a huge
> > > fan of them either. Wouldn't it be nice if we had a merge method that
> > > did a merge without creating a merge? I call it git-merge-subordinate
> > > (since my tree is subordinate to the tree I'm pulling from). I suppose
> > > you could call it 'slave' if you want to be more pithy. Anyway, this
> > > is a first attempt, and it's totally cargo-cult programming; I make no
> > > claim that I understand what I'm doing. But it does seem to work.
> >
> > Hmmm... the --squash option to git-merge/git-pull isn't enough?
>
> What subordinate does is not _merge_, but _rebase_ on top of the fetched
> commit. So yes, --squash isn't enough ;-)
And I would suggest calling it 'git-merge-rebase', as the strategy
really is rebase... :-)
--
^ permalink raw reply
* Hanging fetches
From: Petr Baudis @ 2006-10-25 16:25 UTC (permalink / raw)
To: git
Hi,
due to the problem with kernel.org, I have a somewhat ugly situation
on repo.or.cz now:
root 16370 0.0 0.0 2112 732 ? S 16:47 0:00 \_ /USR/SBIN/CRON
repo 16371 0.0 0.0 2776 1236 ? Ss 16:47 0:00 \_ /bin/bash /home/repo/repomgr/updatecheck.sh
repo 16377 0.0 0.0 2776 648 ? S 16:47 0:00 \_ /bin/bash /home/repo/repomgr/updatecheck.sh
repo 17685 0.0 0.0 2780 1252 ? S 16:47 0:00 \_ /bin/bash /home/repo/repomgr/update.sh linux-2.6
repo 17689 0.0 0.0 2872 1372 ? S 16:47 0:00 \_ /bin/sh /home/pasky/bin/git-fetch -f -u -k --mirror-all
pub/scm/linux/kernel/git/torvalds/linux-2.6.git
repo 17702 0.0 0.0 2872 720 ? S 16:47 0:00 \_ /bin/sh /home/pasky/bin/git-fetch -f -u -k --mirror-org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
repo 17703 0.0 0.0 2872 644 ? S 16:47 0:00 \_ /bin/sh /home/pasky/bin/git-fetch -f -u -k --mirnel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
repo 17704 0.0 0.0 2836 1328 ? S 16:47 0:00 | \_ /bin/sh /home/pasky/bin/git-ls-remote git://m/linux/kernel/git/torvalds/linux-2.6.git
repo 17716 0.0 0.0 2836 616 ? S 16:47 0:00 | \_ /bin/sh /home/pasky/bin/git-ls-remote gib/scm/linux/kernel/git/torvalds/linux-2.6.git
repo 17717 0.0 0.0 2956 940 ? S 16:47 0:00 | | \_ git-peek-remote git //git.kernel.org/git/torvalds/linux-2.6.git
repo 17718 0.0 0.0 27488 552 ? S 16:47 0:00 | \_ sort -t ? -k 2
repo 17719 0.0 0.0 2836 592 ? S 16:47 0:00 | \_ /bin/sh /home/pasky/bin/git-ls-remote gib/scm/linux/kernel/git/torvalds/linux-2.6.git
repo 17705 0.0 0.0 2872 628 ? S 16:47 0:00 \_ /bin/sh /home/pasky/bin/git-fetch -f -u -k --mirnel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
It's 18:24 now and peek-remote is hanging in a read(). My question is,
will this *ever* time out, and when? :) Perhaps the timeouts should be
adjusted to a more reasonable value, or implemented if they are missing
altogether, but I'm not sure what would be the best way to go about it -
alarm()? What value would be reasonable?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: git-merge-subordinate
From: Johannes Schindelin @ 2006-10-25 16:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eho29l$1td$1@sea.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 799 bytes --]
Hi,
On Wed, 25 Oct 2006, Jakub Narebski wrote:
> Matthew Wilcox wrote:
>
> > Linus doesn't like seeing unnecessary merges in his tree. I'm not a huge
> > fan of them either. Wouldn't it be nice if we had a merge method that
> > did a merge without creating a merge? I call it git-merge-subordinate
> > (since my tree is subordinate to the tree I'm pulling from). I suppose
> > you could call it 'slave' if you want to be more pithy. Anyway, this
> > is a first attempt, and it's totally cargo-cult programming; I make no
> > claim that I understand what I'm doing. But it does seem to work.
>
> Hmmm... the --squash option to git-merge/git-pull isn't enough?
What subordinate does is not _merge_, but _rebase_ on top of the fetched
commit. So yes, --squash isn't enough ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [git failure] failure pulling latest Linus tree
From: Petr Baudis @ 2006-10-25 16:13 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Jes Sorensen, Junio C Hamano, git
In-Reply-To: <453F8630.2000608@zytor.com>
Dear diary, on Wed, Oct 25, 2006 at 05:43:44PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> said that...
> HOWEVER, git 1.4.3 seems to have been bad chicken. When we ran it we
> got a neverending stream of segfaults in the logs.
Could you provide some details, please? Ideally a backtrace or
something? Also, it might be a good idea to use 1.4.3.2 since it fixes a
problem with compatibility of git-daemon and older git clients.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: git-merge-subordinate
From: Jakub Narebski @ 2006-10-25 16:11 UTC (permalink / raw)
To: git
In-Reply-To: <20061025155009.GD5591@parisc-linux.org>
Matthew Wilcox wrote:
> Linus doesn't like seeing unnecessary merges in his tree. I'm not a huge
> fan of them either. Wouldn't it be nice if we had a merge method that
> did a merge without creating a merge? I call it git-merge-subordinate
> (since my tree is subordinate to the tree I'm pulling from). I suppose
> you could call it 'slave' if you want to be more pithy. Anyway, this
> is a first attempt, and it's totally cargo-cult programming; I make no
> claim that I understand what I'm doing. But it does seem to work.
Hmmm... the --squash option to git-merge/git-pull isn't enough?
--squash::
Produce the working tree and index state as if a real
merge happened, but do not actually make a commit or
move the `HEAD`, nor record `$GIT_DIR/MERGE_HEAD` to
cause the next `git commit` command to create a merge
commit. This allows you to create a single commit on
top of the current branch whose effect is the same as
merging another branch (or more in case of an octopus).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Carl Worth @ 2006-10-25 15:54 UTC (permalink / raw)
To: James Henstridge
Cc: Jakub Narebski, Andreas Ericsson, bazaar-ng, Matthew D. Fuller,
Linus Torvalds, git
In-Reply-To: <a7e835d40610250308v5d577482m139742e7fe1db185@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]
On Wed, 25 Oct 2006 18:08:22 +0800, "James Henstridge" wrote:
> If there aren't, or you made the merge by mistake, you can make a call
> to "bzr revert" to clean things up without ever having created a new
> revision.
One result of this approach is that developers of different trees
don't necessarily have common revision IDs to compare. Imagine a
question like:
When you ran that test did you have the same code I've got?
In git, the answer would be determined by comparing revision IDs.
In bzr, the only answer I'm hearing is attempting a merge to see if it
introduces any changes. (I'm deliberately avoiding "pull" since we're
talking about distributed cases here).
And to comment on something mentioned earlier in the thread, there's
no need for "wildly complex" distributed scenarios. All of these
issues are present with developers working together as peers, (and
each considering their own repository as canonical).
A harder question (for bzr) is:
Do you have all of the history I've got?
(The problem being that when one developer is missing some history and
merges it in, she necessarily creates new history, so there's never a
stable point for both sides to agree on.)
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* git-merge-subordinate
From: Matthew Wilcox @ 2006-10-25 15:50 UTC (permalink / raw)
To: git
Linus doesn't like seeing unnecessary merges in his tree. I'm not a huge
fan of them either. Wouldn't it be nice if we had a merge method that
did a merge without creating a merge? I call it git-merge-subordinate
(since my tree is subordinate to the tree I'm pulling from). I suppose
you could call it 'slave' if you want to be more pithy. Anyway, this
is a first attempt, and it's totally cargo-cult programming; I make no
claim that I understand what I'm doing. But it does seem to work.
While working on it, I found a small bug in git-merge. When
no_trivial_merge_strategies has more than one component, setting
index_merge to f doesn't work. So first, here's the patch to git-merge
adding support for 'subordinate':
--- /usr/bin/git-merge 2006-07-29 15:47:09.000000000 -0600
+++ /home/willy/bin/git-merge 2006-10-25 09:21:00.000000000 -0600
@@ -9,15 +9,15 @@
LF='
'
-all_strategies='recursive octopus resolve stupid ours'
+all_strategies='recursive octopus resolve stupid subordinate ours'
default_twohead_strategies='recursive'
default_octopus_strategies='octopus'
-no_trivial_merge_strategies='ours'
+no_trivial_merge_strategies='subordinate ours'
use_strategies=
index_merge=t
if test ""; then
- all_strategies='resolve octopus stupid ours'
+ all_strategies='resolve octopus stupid subordinate ours'
default_twohead_strategies='resolve'
fi
@@ -154,12 +154,15 @@
for s in $use_strategies
do
- case " $s " in
- *" $no_trivial_merge_strategies "*)
- index_merge=f
- break
- ;;
- esac
+ for t in $no_trivial_merge_strategies
+ do
+ case "$s" in
+ "$t")
+ index_merge=f
+ break
+ ;;
+ esac
+ done
done
case "$#" in
And now, here's the extremely lame git-merge-subordinate script.
#!/bin/sh
#
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2005 Junio C Hamano
#
# Resolve two trees, using enhancd multi-base read-tree.
# The first parameters up to -- are merge bases; the rest are heads.
bases= head= remotes= sep_seen=
for arg
do
case ",$sep_seen,$head,$arg," in
*,--,)
sep_seen=yes
;;
,yes,,*)
head=$arg
;;
,yes,*)
remotes="$remotes$arg "
;;
*)
bases="$bases$arg "
;;
esac
done
# Give up if we are given more than two remotes -- not handling octopus.
case "$remotes" in
?*' '?*)
exit 2 ;;
esac
# Give up if this is a baseless merge.
if test '' = "$bases"
then
exit 2
fi
git-rebase $remotes || exit 2
if result_tree=$(git-write-tree 2>/dev/null)
then
exit 0
else
echo "Simple merge failed, trying Automatic merge."
if git-merge-index -o git-merge-one-file -a
then
exit 0
else
exit 1
fi
fi
^ permalink raw reply
* Re: (unknown)
From: Karl Hasselström @ 2006-10-25 15:31 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200610251610.02446.andyparkins@gmail.com>
On 2006-10-25 16:10:02 +0100, Andy Parkins wrote:
> My apologies to everyone for the constant noise I keep dumping on
> the list. I promise I'm trying really hard to be good.
I always try sending the patch to myself first, since something almost
always goes wrong on the first try. This helps against most problems,
but certainly not all. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Question about commit message conventions
From: Andreas Ericsson @ 2006-10-25 15:23 UTC (permalink / raw)
To: Erik Mouw; +Cc: Tobias Toedter, git
In-Reply-To: <20061024140856.GH5639@harddisk-recovery.com>
Erik Mouw wrote:
> On Tue, Oct 24, 2006 at 03:49:44PM +0200, Tobias Toedter wrote:
>
>> On the other hand, concerning the approval of other developers, what's the
>> difference between "Signed-off-by:" and "Acked-by:"? Are there any
>> more "*-by:" fields that are in use?
>
> Acked-by is usually used when someone (not the upstream maintainer the
> patch was send to) agrees with the patch. I.e.: (s)he says the content
> of the patch is OK without actually acknowledging something about the
> right to submit.
>
If you sift through the Linux kernel, you will find numerous patches
where subsystem maintainers have acked patches sent to them. I *think*
this usually means that they have reviewed the patch and approve of it,
but not modified it. The Ack is then solely for Linus' benefits and
tells him that at least one pair of eyes have already gone over the patch.
Subsys maintainers sometimes also add Signed-off-by: lines, which I
assume means they have tweaked the patch somewhat or somehow
collaborated with the author in producing it. I know Junio signs off
patches he modifies, and I'm guessing this habit is inherited from the
kernel workflow which was most likely encouraged by Linus when he was
the Git maintainer.
Lots of guesswork here, but in a sane world I can't be too far off the
mark ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: (unknown)
From: Andy Parkins @ 2006-10-25 15:10 UTC (permalink / raw)
To: git
In-Reply-To: <ehntnv$b1k$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
On Wednesday 2006 October 25 15:53, Jakub Narebski wrote:
> Check if "git clone --use-separate-remote" isn't what you want.
I did try that, but then the branches don't appear in git branch. I still
like that they exist.
> And please correct mail sending.
AHHHH!!! I thought I had. Dagnamit; I think an upgrade in Debian overwrote my
manual git-imap-send compile. The git-imap-send bug was fixed in
e0b0830726286287744cc9e1a629a534bbe75452, but doesn't seem to have made it
into debian yet.
I'm getting so sick of looking like an idiot.
My apologies to everyone for the constant noise I keep dumping on the list. I
promise I'm trying really hard to be good.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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