* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-18 11:17 UTC (permalink / raw)
To: Petr Baudis
Cc: Erik B?gfors, Aaron Bentley, Matthieu Moy, bazaar-ng,
Linus Torvalds, Andreas Ericsson, git
In-Reply-To: <20061018110841.GS20017@pasky.or.cz>
Petr Baudis wrote:
> But somewhere else in the thread it's been said that bundles can also
> contain merges. Does that means that bundles can look like:
>
> 1
> / \
> 2 4
> | | _
> 3 5 |
> \ / | a bundle
> 6 |
> ~
>
> In that case [merge bundle], against what the big diff from 6 is done?
> 2? 4? Or even 1?
Or do you use equivalent of git combined diff format?
http://www.kernel.org/pub/software/scm/git/docs/git-diff-tree.html
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 11:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Robert Collins, bazaar-ng, git, Jakub Narebski
In-Reply-To: <4535EB7C.7030209@op5.se>
Dear diary, on Wed, Oct 18, 2006 at 10:53:16AM CEST, I got a letter
where Andreas Ericsson <ae@op5.se> said that...
> Robert Collins wrote:
> >Anyone can push and pull from each other - full stop. Whenever they
> >'pull' in bzr terms, they get fast-forward happening (if I understand
> >the git fast-forward behaviour correctly). After a fast-forward, the
> >dotted decimal revision numbers in the two branches are identical - and
> >they remain immutable until another fast forward occurs.
..snip..
> >You can determine it locally - if you know any of the motherships
> >revisions locally, we can generate the dotted-revnos that the
> >motherships master-branch would have from the local data - and the last
> >merge of mothership you did will have given you that details.
>
>
> To me, this means bazaar isn't distributed at all and I could achieve
> much the same distributedness(?) by rsyncing an SVN repo, working
> against that and then rsyncing it back with some fancy merging. In other
> words, bazaar requires there to be one Lord of the Code, or some of the
> key features break down.
Well as far as I understand, the Lord of the Code is whoever you pulled
from the last time.
It's just a different focus here. If I understood everything in this
thread correctly, both Git and Bazaar have persistent (SHA1, UUID) and
volatile (revspec, revision number) revision ids. The only difference is
that Git primarily presents the user with the SHA1 ids while Bazaar
primarily presents the user with a revision number (and that revspecs
change after every commit while revision numbers change only after a
merge).
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* [BUG] git-log shows first parent and repeated last for octopus merge
From: Jakub Narebski @ 2006-10-18 11:11 UTC (permalink / raw)
To: git
When trying to find how many merges and how many octopus merges (merges with
more than two parents) are in git.git repository I have encountered the
following strange output of git-log:
1000:jnareb@roke:~/git> git log --parents --full-history --max-count=1 \
211232bae64bcc60bbf5d1b5e5b2344c22ed767e -- a//b
commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e <last parent repeated>
Merge: d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b... d0d0d0b...
[...]
while git-show gives correct output
1005:jnareb@roke:~/git> git show 211232bae64bcc60bbf5d1b5e5b2344c22ed767e
commit 211232bae64bcc60bbf5d1b5e5b2344c22ed767e
Merge: fc54a9c... 9e30dd7... c4b83e6... 6602659... b28858b...
[...]
Same with git-rev-list, also shows correct output:
1005:jnareb@roke:~/git> git rev-list --header --parents --max-count=1 \
211232bae64bcc60bbf5d1b5e5b2344c22ed767e
211232bae64bcc60bbf5d1b5e5b2344c22ed767e [...]
tree cdafa88fa4ed7fcc7bb6c64d62e2d7c4d3b65e42
parent fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc
parent 9e30dd7c0ecc9f10372f31539d0122db97418353
parent c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a
parent 660265909fc178581ef327076716dfd3550e6e7b
parent b28858bf65d4fd6d8bb070865518ec43817fe7f3
[...]
1008:jnareb@roke:~/git> git --version
git version 1.4.2.1
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Petr Baudis @ 2006-10-18 11:08 UTC (permalink / raw)
To: Erik B?gfors
Cc: Aaron Bentley, Matthieu Moy, bazaar-ng, Linus Torvalds,
Andreas Ericsson, git, Jakub Narebski
In-Reply-To: <845b6e870610180228m39829c49nf37e07e76e744250@mail.gmail.com>
Dear diary, on Wed, Oct 18, 2006 at 11:28:32AM CEST, I got a letter
where Erik B?gfors <zindar@gmail.com> said that...
> On 10/18/06, Petr Baudis <pasky@suse.cz> wrote:
> >Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter
> >where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
> >> Petr Baudis wrote:
> >> > Another aspect of this is that Git (Linus ;) is very focused on getting
> >> > the history right, nice and clean (though it does not _mandate_ it and
> >> > you can just wildly do one commit after another; it just provides tools
> >> > to easily do it).
> >>
> >> Yes, rebasing is very uncommon in the bzr community. We would rather
> >> evaluate the complete change than walk through its history. (Bundles
> >> only show the changes you made, not the changes you merged from the
> >> mainline.)
> >>
> >> In an earlier form, bundles contained a patch for every revision, and
> >> people *hated* reading them. So there's definitely a cultural
> >> difference there.
> >
> >BTW, I think what describes the Git's (kernel's) stance very nicely is
> >what I call the Al Viro's "homework problem":
> >
> > http://lkml.org/lkml/2005/4/7/176
> >
> >If I understand you right, the bzr approach is what's described as "the
> >dumbest kind" there? (No offense meant!)
>
> Yes and no, The bundle includes both the full final thing, and each
> step along the way. Each step along the way is something you'll get
> when you merge it.
>
> Once merged, it will be "next one" in the description above. It would
> typically look something like this in "bzr log"(shortened) In this
> example, doing C requires doing A and B as well...
>
> committer: foobar@foobar.com
> message: merged in C
> -------
> committer: bar@bar.com
> message: opps, fix bug in A
> -------
> committer: bar@bar.com
> message: implement B
> -------
> committer: bar@bar.com
> message: implement A
>
> So, you'll get full history, including errors made :) You can also
> see who approved it to this branch (foobar) and who did the actual
> work (bar)
I see, that's what I've been missing, thanks. So it's the middle path
(as any other commonly used VCS for that matter, expect maybe darcs?;
patch queues and rebasing count but it's a hack, not something properly
supported by the design of Git, since at this point the development
cannot be fully distributed).
I also assume that given this is the case, the big diff does really not
serve any purpose besides human review?
But somewhere else in the thread it's been said that bundles can also
contain merges. Does that means that bundles can look like:
1
/ \
2 4
| | _
3 5 |
\ / | a bundle
6 |
~
In that case, against what the big diff from 6 is done? 2? 4? Or even 1?
--
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
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: VCS comparison table
From: Matthew D. Fuller @ 2006-10-18 10:32 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Aaron Bentley, Linus Torvalds, Carl Worth, bazaar-ng, git,
Jakub Narebski
In-Reply-To: <4535E844.8010604@op5.se>
On Wed, Oct 18, 2006 at 10:39:32AM +0200 I heard the voice of
Andreas Ericsson, and lo! it spake thus:
>
> So in essence, the revnos work wonderfully so long as there is a
> central server to make them immutable?
It seems from my somewhat detached perspective that there's a lot of
conflation of 'conventions' with 'capabilities' around this thread...
With a single linear branch, revnos work wonderfully, and are probably
much more useful than any sort of UUID. It would be silly in this day
and age to design a VCS aimed specifically for this use case, of
course. That doesn't mean a VCS shouldn't make it easy, though.
With a star config, revnos are useful locally and with reference to
the "main" branch[es]. And, most of the world is star configs of one
sort or another. Actually, one might say that practically ALL the
world outside of linux-kernel is star-configs ;)
In many cases in the star setup, a revno (particularly along the
'trunk') is more directly useful than a UUID; consider particularly
the case of somebody who's just mirroring/following, not actively
developing. In some cases, the UUID is more useful. Certainly, using
a revno in a case where the UUID is more appropriate is Bad, but
that's just a matter of using the right tool.
With a uber-distributed full-mesh setup, revnos may be basically
useless for anything except local lookups (which boils down to
"useless for most anything you'd identify a revision for"). For that
case, you'd practically always use the UUID, and pretend revnos don't
exist.
The merge revno forms (123.5.2.17 and the like), I'm somewhat
ambivalent about in many ways. But, you don't have to use them any
more than you have to use "top-level" revnos. If either form of revno
is Wrong for your case (whether it be because "I hate numbers
wholesale", or because "Numbers don't cover this case usefully"), then
you just use the UUID and pretend the number isn't there. If you
wanted them completely out of sight, I wouldn't expect it to be very
hard to talk bzr into never showing the revnos and just showing the
UUID ("revid").
[ I don't speak for bzr, despite the fact that I'm about to appear to ]
>From where I sit, revnos are quite useful in the first 1.5 or 2 cases.
Some would argue that they're not useless in the third case as well,
but that's no necessary point to hash out; it certainly does no
technical harm to have them there, since you can just ignore them if
they don't help you. I think a good case could be made that the vast
majority of VCS use in the world is a form of case 2.
Git comes out of a world where case 3 is All, and the other cases are,
if not actively ignored, at least far secondary considerations, so it
can hardly be surprising that it doesn't have or want something that
adds practically nothing to its case.
bzr, both in its own development schema, and in the expected audience,
is overwhelmingly case 2 (of which case 1 is really just a degenerate
version), but that doesn't mean case 3 is ignored or impossible. The
UUID's are there for when you need them, and can be used anywhere you
might use a number, and just as easily. It's a community convention
to organize development in such a way that the number is "usually"
useful, and when it is, it's certainly easier. That doesn't mean you
HAVE to use it in cases where it doesn't fit, though. "bzr people
like to avoid using UUID's" doesn't lead to "bzr can't handle the
cases where UUID's are necessary".
> Doesn't this mean that one of your key features doesn't actually
> work in a completely distributed setup
That's one way of phrasing it, I guess. I'd say rather "a particular
feature isn't applicable to a completely distributed setup". I'm sure
git has a lot of features that are key for somebody that "don't work"
for someone else, just because they're doing something that person
doesn't want done. Just because somebody else thinks their toaster
oven is a great way to solder, doesn't mean you have to sell yours.
You can just leave it in the cupboard and use an iron instead.
--
Matthew Fuller (MF4839) | fullermd@over-yonder.net
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
^ permalink raw reply
* Re: [PATCH] git-imap-send: Strip smtp From_ header from imap message.
From: Junio C Hamano @ 2006-10-18 10:28 UTC (permalink / raw)
To: Mike McCormack; +Cc: git, Markus Amsler
In-Reply-To: <45367A5F.7060507@codeweavers.com>
Mike McCormack <mike@codeweavers.com> writes:
> Junio C Hamano wrote:
>> Markus Amsler <markus.amsler@oribi.org> writes:
>>
>>> Cyrus imap refuses messages with a 'From ' Header.
>>>
>>> Signed-off-by: Markus Amsler <markus.amsler@oribi.org>
>>
>> Do you know if this change does not upset other implementations
>> of imap servers?
>>
>> Mike, are you Ok with this change?
>
> Works for me with Courier IMAP. I'm no expert on mail headers either,
> so no objections from me.
>
> Mike
Thanks; then will apply.
By the way, Markus, did you send the patch with imap-send? It
had a funny whitespace corruptions.
^ permalink raw reply
* Re: [PATCH] git-imap-send: Strip smtp From_ header from imap message.
From: Mike McCormack @ 2006-10-18 19:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Markus Amsler, git
In-Reply-To: <7vlknegnwk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Markus Amsler <markus.amsler@oribi.org> writes:
>
>> Cyrus imap refuses messages with a 'From ' Header.
>>
>> Signed-off-by: Markus Amsler <markus.amsler@oribi.org>
>
> Do you know if this change does not upset other implementations
> of imap servers?
>
> Mike, are you Ok with this change?
Works for me with Courier IMAP. I'm no expert on mail headers either,
so no objections from me.
Mike
^ permalink raw reply
* Re: [PATCH] Use diff3 instead of merge in merge-recursive.
From: Johannes Schindelin @ 2006-10-18 10:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eh4sfr$3ej$1@sea.gmane.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 789 bytes --]
Hi,
On Wed, 18 Oct 2006, Jakub Narebski wrote:
> Uwe Zeisberger wrote:
>
> > If no error occurs, merge (from rcs 5.7) is nothing but:
> >
> > diff3 -E -am -L label1 -L label2 -L label3 file1 file2 file3 > tmpfile
> > cat tmpfile > file1
> >
> > Using diff3 directly saves one fork per conflicting file.
>
> Doesn't xdiff library git uses have diff3/merge equivalent?
> Couldn't we use that instead (on less dependency, better performance)?
We have only half of libxdiff, lacking the patch functionality. And AFAIUI
the minimal implementation of diff3 in xdiff just uses a diff of the first
pair on the third file (or some other order). So, it is not really a
diff3/merge: it would fail in fairly trivial cases.
Ciao,
Dscho
P.S.: Davide, correct me if I'm wrong.
^ permalink raw reply
* Re: heads-up: git-index-pack in "next" is broken
From: Johannes Schindelin @ 2006-10-18 10:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git, Linus Torvalds
In-Reply-To: <7vu022gqji.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 17 Oct 2006, Junio C Hamano wrote:
> +/*
> + * Even if sizeof(union delta_base) == 24 on 64-bit archs, we really want
> + * to memcmp() only the first 20 bytes.
> + */
> +#define UNION_BASE_SZ 20
Excuse me for joining the game, but why don't you just use the
recently introduced hashcmp() for that purpose? AFAIU you do exactly that,
you compare hashes.
Ciao,
Dscho
^ permalink raw reply
* Re: Make the ftplugin right wrt gitdir
From: Jeff King @ 2006-10-18 9:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <200610181107.56260.madcoder@debian.org>
On Wed, Oct 18, 2006 at 11:07:54AM +0200, Pierre Habouzit wrote:
> well the result file is here:
> http://madism.org/~madcoder/dotfiles/vim/ftplugin/git.vim
I was able to grab it...my comments are below.
> if exists("b:did_ftplugin")
> finish
> endif
>
> let b:did_ftplugin = 1
>
> setlocal tw=74
> setlocal nowarn nowb
Do things like tw really have anything to do with the ftplugin?
Shouldn't they instead go into the user's vimrc?
> "{{{ function Git_diff_windows
>
> function! Git_diff_windows(vertsplit, auto)
> let i = 0
> let list_of_files = ''
>
> " drop everything until '# (will commit)' and the next empty line
> while i <= line('$')
> let line = getline(i)
> if line =~ '^#\s*(will commit)$'
> let i = i + 2
> break
> endif
>
> let i = i + 1
> endwhile
>
> " read file names until we have EOF or an empty line
> while i <= line('$')
> let line = getline(i)
> if line =~ '^#\s*[a-z ]*:.*->.*$'
> let file = substitute(line, '\v^#[^:]*:.*->\s*(.*)\s*$', '\1', '')
> let list_of_files = list_of_files . ' '.file
> let file = substitute(line, '\v^#[^:]*:\s*(.*)\s*->.*$', '\1', '')
> let list_of_files = list_of_files . ' '.file
> elseif line =~ '^#\s*[a-z ]*:'
> let file = substitute(line, '\v^#[^:]*:\s*(.*)\s*$', '\1', '')
> let list_of_files = list_of_files . ' '.file
> elseif line =~ '^#\s*$'
> break
> endif
>
> let i = i + 1
> endwhile
>
> if list_of_files == ""
> return
> endif
>
> if a:vertsplit
> rightbelow vnew
> else
> rightbelow new
> endif
This all looks OK to me, but then I don't really know vim script very
well. :)
> silent! setlocal ft=diff previewwindow bufhidden=delete nobackup noswf nobuflisted nowrap buftype=nofile
> let gitDir = system('git rev-parse --git-dir 2>/dev/null')
> let gitDir = substitute(gitDir, '.git\n', '', '')
> let wd = getcwd()
> if gitDir != ''
> exe 'cd '.gitDir
> endif
> exe 'normal :r!LANG=C git diff HEAD -- ' . list_of_files . "\n1Gdd"
> exe 'normal :r!LANG=C git diff HEAD -- ' . list_of_files . " \| git apply --stat\no\<esc>1GddO\<esc>"
> exe 'cd '.wd
> setlocal nomodifiable
This procedure seems a bit hack-ish and fragile. I think the chdir is
necessary not just to handle autochdir, but also because we want to do
any diff from the top-level instead of a subdir. Why do we
unconditionally set LANG=C? What about quoting for the file list?
In general, is this really that much nicer than simply using the '-v'
flag to git-commit?
> if g:git_diff_spawn_mode == 1
> call Git_diff_windows(0, 1)
> elseif g:git_diff_spawn_mode == 2
> call Git_diff_windows(1, 1)
> endif
This should probably handle the case where g:git_diff_spawn_mode is not
defined (otherwise vim complains loudly):
if exists("g:git_diff_spawn_mode")
" do nothing
elseif g:git_diff_spawn_mode == 1
etc.
-Peff
^ permalink raw reply
* Re: [PATCH] Use diff3 instead of merge in merge-recursive.
From: Johannes Schindelin @ 2006-10-18 9:38 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20061018085949.GA26501@cepheus.pub>
Hi Uwe,
On Wed, 18 Oct 2006, Uwe Zeisberger wrote:
> If no error occurs, merge (from rcs 5.7) is nothing but:
>
> diff3 -E -am -L label1 -L label2 -L label3 file1 file2 file3 > tmpfile
> cat tmpfile > file1
Interesting. I wonder if we could streamline the code such that index_fd
is called directly on the output of diff3? Of course, the result has to be
removed when the call to diff3 fails.
> I didn't made any timing tests or further tests for correctness, but I
> hope Johannes still has the framework from the time when he converted
> the Python script to C?
>
> @Johannes: If so, could you test this patch?
I have to dig a little where I have it, but I think I can give it a try in
a few hours (imagine this lyrics to the melody of the day job blues).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use diff3 instead of merge in merge-recursive.
From: Jakub Narebski @ 2006-10-18 9:35 UTC (permalink / raw)
To: git
In-Reply-To: <20061018085949.GA26501@cepheus.pub>
Uwe Zeisberger wrote:
> If no error occurs, merge (from rcs 5.7) is nothing but:
>
> diff3 -E -am -L label1 -L label2 -L label3 file1 file2 file3 > tmpfile
> cat tmpfile > file1
>
> Using diff3 directly saves one fork per conflicting file.
Doesn't xdiff library git uses have diff3/merge equivalent?
Couldn't we use that instead (on less dependency, better performance)?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-18 9:28 UTC (permalink / raw)
To: Petr Baudis
Cc: Aaron Bentley, Matthieu Moy, bazaar-ng, Linus Torvalds,
Andreas Ericsson, git, Jakub Narebski
In-Reply-To: <20061018003920.GK20017@pasky.or.cz>
On 10/18/06, Petr Baudis <pasky@suse.cz> wrote:
> Dear diary, on Wed, Oct 18, 2006 at 02:30:14AM CEST, I got a letter
> where Aaron Bentley <aaron.bentley@utoronto.ca> said that...
> > Petr Baudis wrote:
> > > Another aspect of this is that Git (Linus ;) is very focused on getting
> > > the history right, nice and clean (though it does not _mandate_ it and
> > > you can just wildly do one commit after another; it just provides tools
> > > to easily do it).
> >
> > Yes, rebasing is very uncommon in the bzr community. We would rather
> > evaluate the complete change than walk through its history. (Bundles
> > only show the changes you made, not the changes you merged from the
> > mainline.)
> >
> > In an earlier form, bundles contained a patch for every revision, and
> > people *hated* reading them. So there's definitely a cultural
> > difference there.
>
> BTW, I think what describes the Git's (kernel's) stance very nicely is
> what I call the Al Viro's "homework problem":
>
> http://lkml.org/lkml/2005/4/7/176
>
> If I understand you right, the bzr approach is what's described as "the
> dumbest kind" there? (No offense meant!)
Yes and no, The bundle includes both the full final thing, and each
step along the way. Each step along the way is something you'll get
when you merge it.
Once merged, it will be "next one" in the description above. It would
typically look something like this in "bzr log"(shortened) In this
example, doing C requires doing A and B as well...
committer: foobar@foobar.com
message: merged in C
-------
committer: bar@bar.com
message: opps, fix bug in A
-------
committer: bar@bar.com
message: implement B
-------
committer: bar@bar.com
message: implement A
So, you'll get full history, including errors made :) You can also
see who approved it to this branch (foobar) and who did the actual
work (bar)
/Erik
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-18 9:20 UTC (permalink / raw)
To: Aaron Bentley
Cc: Carl Worth, Petr Baudis, Linus Torvalds, Andreas Ericsson,
bazaar-ng, git, Matthieu Moy
In-Reply-To: <45359F36.6050609@utoronto.ca>
Aaron Bentley wrote:
> Carl Worth wrote:
>> On Wed, 18 Oct 2006 03:28:30 +0200, Jakub Narebski wrote:
>>> Isn't it easier to review than "bundle", aka. mega-patch?
>>
>> There are even more important reasons to prefer a series of
>> micro-commits over a mega-patch than just ease of merging.
>
> A bundle isn't a mega-patch. It contains all the source revisions. So
> when you merge or pull it, you get all the original revisions in your
> repository.
But what patch reviewer see is a mega-patch showing the changeset
of a whole "bundle", isn't it?
[...]
>> Now, I do admit that it is often useful to take the overall view of a
>> patch series being submitted. This is often the case when a patch
>> series is in some sub-module of the code for which I don't have as
>> much direct involvement. In cases like that I will often do review
>> only of the diff between the tips of the mainline and the branch of
>> interest, (or if I trust the maintainer enough, perhaps just the
>> diffstat between the two). But I'm still very glad that what lands in
>> the history is the series of independent changes, and not one mega
>> commit.
>
> So the difference here is that bundles preserve the original commits the
> changes came from, so even though it's presented as an overview, you
> still have a series of independent changes in your history.
I think it is much better to review series of patches commit by commit;
besides it allows to correct some inner patches before applying the whole
series or drop one of patches in series (and it happened from time to time
on git mailing list).
So if git introduces bundles, I think they would take form of series
of "patch" mails + introductory email with series description (currently
it is not saved anywhere), shortlog, diffstat and perhaps more metainfo
like bundle parent (which I think should be email form of branch really),
tags introduced etc.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Make the ftplugin right wrt gitdir
From: Pierre Habouzit @ 2006-10-18 9:07 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061018090231.GA18807@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]
Le mer 18 octobre 2006 11:02, Jeff King a écrit :
> On Wed, Oct 18, 2006 at 10:10:59AM +0200, Pierre Habouzit wrote:
> > > Looks like the patch is missing (more sleep required?).
> >
> > err, the patch is here:
> > <1161132446703-git-send-email-madcoder@debian.org>
>
> Right, that's the "be more robust" patch which applies on top of
> something else (presumably "nice ftplugin for vim"), but the last one
> I got of that (<11611319761977-git-send-email-madcoder@debian.org>)
> causes vim errors and you immediately followed up with "that's still
> not the good one." Where is that patch?
hmm I see, curious though, I must have do sth stupid :|
well the result file is here:
http://madism.org/~madcoder/dotfiles/vim/ftplugin/git.vim
I've not access to my git repo from here, feel free to grab it and
commit it, I don't care if there is not my name on it.
and as of gitEmail you're right I don't use it, I wanted to to hilight
the email address in the gitAuthor zone, but well, basically, it sucks,
that makes too many colors.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: VCS comparison table
From: Jakub Narebski @ 2006-10-18 9:07 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Aaron Bentley, Carl Worth, Linus Torvalds, bazaar-ng, git
In-Reply-To: <4535E844.8010604@op5.se>
Andreas Ericsson wrote:
> Aaron Bentley wrote:
>> Well, there's distributed, and then there's *DISTRIBUTED*. We don't
>> quasi-randomly merge each others' branches. We have a star topology
>> around bzr.dev. So when we refer to revnos, they're usually in bzr.dev.
>>
>
> So in essence, the revnos work wonderfully so long as there is a central
> server to make them immutable?
>
> Doesn't this mean that one of your key features doesn't actually work in
> a completely distributed setup (i.e., each dev has his own repo, there
> is no mother-ship, everyone pulls from each other)?
>
> I can see the six-line hook that lays the groundwork for this in git
> before me right now. I'll happily refuse to write it down anywhere. I
> get the feeling that sha's are easier to handle in the long run, while
> revno's might be good to use in development work. In git, we have
> <branch/tag/"committish">~<number> syntax for this.
>
> In my experience, finding the revision sha of an old bug is what takes
> time. Copy-paste is just as fast with 20 bytes as with 4 bytes. Honestly
> now, do you actually remember the revno for a bug that you stopped
> working on three weeks ago, or do you have to go look it up? If someone
> wants to notify you about the revision a bug was introduced, do they not
> communicate the revno to you by email/irc/somesuch?
Revnos were supposed to be superior to using sha1 (or shortened sha1)
as commit identifiers because of two key features:
1. They were simplier than sha1, therefore easier to use
2. Given two revisions related by lineage (i.e. one is ancestor of
the other) you can from a glance know which revision was earlier
But the details invalidated 1.: for complicated history, for a large
project, with many contributors and nonlinear development we have
www.repository.com:127.2.31.57 vs 988859a (7 chars shortcut of sha1)
to have immutable revno. And we have to use _immutable_ (up to few
years) revison identifiers, unless we want our "simple ids" scheme
to make a mess...
And I'm not sure if 2. is true, if even for revisions with direct
lineage we don't have to compare 127.15.2.16 with 210.2.20.3 for
example. Having generation number would solve 2.; as of now git
check for fast-forward case by checking if merge-base of two
revisions is one of the revisions.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: VCS comparison table
From: Peter Baumann @ 2006-10-18 9:04 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Aaron Bentley, Carl Worth, Jakub Narebski, Linus Torvalds,
bazaar-ng, git
In-Reply-To: <4535E844.8010604@op5.se>
2006/10/18, Andreas Ericsson <ae@op5.se>:
> Aaron Bentley wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Carl Worth wrote:
> >> Aaron, thanks for carrying this thread along and helping to bridge
> >> some communication gaps. For example, when I saw your original two two
> >> diagrams I was totally mystified how you were claiming that appending
> >> a couple of nodes and edges to a DAG could change the "order" of the
> >> DAG.
> >>
> >> I think I understand what you're describing with the leftmost-parent
> >> ordering now. But it's definitely an ordering that I would describe as
> >> local-only. That is, the ordering has meaning only with respect to a
> >> particular linearization of the DAG and that linearization is
> >> different from one repository to the next.
> >
> > Well, the linarization for any particular head is well-defined, but
> > since different branches have different heads...
> >
> >> If in practice, nobody does the mirroring "pull" operation then how
> >> are the numbers useful? For example, given your examples above, if
> >> I'm understanding the concepts and terminology correctly, then if A
> >> and B both "merge" from each other (and don't "pull") then they will
> >> each end up with identical DAGs for the revision history but totally
> >> distinct numbers. Correct?
> >
> > The DAGs will be different. If A merges B, we get:
> >
> > a
> > |
> > b
> > |\
> > c d
> > |\|
> > | e
> > |/
> > f
> >
> > If B merges A before this, nothing happens, because B is already a
> > superset of A.
> >
> > If B merges afterward, we get this:
> > a
> > |
> > b
> > |\
> > d c
> > |/|
> > e |
> > |\|
> > | f
> > |/
> > g
> >
>
> Seems like an awful lot of merge commits. In git, I think these trees
> would be identical (actually both to bazaar and to each other), with the
> exception that the 'g' commit wouldn't exist, since git does
> fast-forward and relies on dependency-chain only to present the graph
> instead of mucking around with info in external files (recording of
> fetches).
>
Ok. This I don't get. Let me recaptulize:
Branch A
a
|
b
|
c
Branch B
a
|
b
| \
d c
| /
e
In branch A, do merge branch B (git pull B) you get as result branch B, because
A fastforwards to B and you don't get a merge commit f
In branch B, do merge branch A (git pull A), the result would be
branch B, because
we are already uptodate.
You _never_ have a commit f or g.
-Peter
^ permalink raw reply
* Re: Make the ftplugin right wrt gitdir
From: Jeff King @ 2006-10-18 9:02 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <200610181010.59995.madcoder@debian.org>
On Wed, Oct 18, 2006 at 10:10:59AM +0200, Pierre Habouzit wrote:
> > Looks like the patch is missing (more sleep required?).
>
> err, the patch is here:
> <1161132446703-git-send-email-madcoder@debian.org>
Right, that's the "be more robust" patch which applies on top of
something else (presumably "nice ftplugin for vim"), but the last one I
got of that (<11611319761977-git-send-email-madcoder@debian.org>) causes
vim errors and you immediately followed up with "that's still not the
good one." Where is that patch?
-Peff
^ permalink raw reply
* Re: [PATCH] git-imap-send: Strip smtp From_ header from imap message.
From: Markus Amsler @ 2006-10-18 8:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike McCormack
In-Reply-To: <7vlknegnwk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Markus Amsler <markus.amsler@oribi.org> writes:
>
>> Cyrus imap refuses messages with a 'From ' Header.
>>
>> Signed-off-by: Markus Amsler <markus.amsler@oribi.org>
>
> Do you know if this change does not upset other implementations
> of imap servers?
I only tested it with cyrus 2.1.18 on debian. I did some research: The
From_ header field was introduced in rfc976 which only affects UUCP(Unix
to Unix CoPy). I assume it's an invalid header field in SMTP/IMAP, and
most implementation ignores it.
I'm no mail header guru, so I could be wrong
Markus
>
> Mike, are you Ok with this change?
>
> ---
> imap-send.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/imap-send.c b/imap-send.c
> index 362e474..16804ab 100644
> --- a/imap-send.c
> +++ b/imap-send.c
> @@ -1226,6 +1226,14 @@ split_msg( msg_data_t *all_msgs, msg_dat
> if (msg->len < 5 || strncmp( data, "From ", 5 ))
> return 0;
>
> + p = strchr( data, '\n' );
> + if (p) {
> + p = &p[1];
> + msg->len -= p-data;
> + *ofs += p-data;
> + data = p;
> + }
> +
> p = strstr( data, "\nFrom " );
> if (p)
> msg->len = &p[1] - data;
>
>
^ permalink raw reply
* [PATCH] Use diff3 instead of merge in merge-recursive.
From: Uwe Zeisberger @ 2006-10-18 8:59 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
If no error occurs, merge (from rcs 5.7) is nothing but:
diff3 -E -am -L label1 -L label2 -L label3 file1 file2 file3 > tmpfile
cat tmpfile > file1
Using diff3 directly saves one fork per conflicting file.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
merge-recursive.c | 34 +++++++++++++++++++++++-----------
1 files changed, 23 insertions(+), 11 deletions(-)
It passes `make test` when NO_SVN_TESTS is defined. (I'll write a
separate mail about that.)
I didn't made any timing tests or further tests for correctness, but I
hope Johannes still has the framework from the time when he converted
the Python script to C?
@Johannes: If so, could you test this patch?
Best regards
Uwe
diff --git a/merge-recursive.c b/merge-recursive.c
index 2ba43ae..9e3f9d7 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -657,8 +657,11 @@ static struct merge_file_info merge_file
char orig[PATH_MAX];
char src1[PATH_MAX];
char src2[PATH_MAX];
+ char tmppath[PATH_MAX];
+
const char *argv[] = {
- "merge", "-L", NULL, "-L", NULL, "-L", NULL,
+ "diff3", "-E", "-am",
+ "-L", NULL, "-L", NULL, "-L", NULL,
NULL, NULL, NULL,
NULL
};
@@ -668,23 +671,31 @@ static struct merge_file_info merge_file
git_unpack_file(a->sha1, src1);
git_unpack_file(b->sha1, src2);
- argv[2] = la = xstrdup(mkpath("%s/%s", branch1, a->path));
- argv[6] = lb = xstrdup(mkpath("%s/%s", branch2, b->path));
- argv[4] = lo = xstrdup(mkpath("orig/%s", o->path));
- argv[7] = src1;
- argv[8] = orig;
- argv[9] = src2,
+ argv[4] = la = xstrdup(mkpath("%s/%s", branch1, a->path));
+ argv[8] = lb = xstrdup(mkpath("%s/%s", branch2, b->path));
+ argv[6] = lo = xstrdup(mkpath("orig/%s", o->path));
+ argv[9] = src1;
+ argv[10] = orig;
+ argv[11] = src2;
+
+ fd = git_mkstemp(tmppath, sizeof(tmppath),
+ ".merge_file_XXXXXX");
+ if (fd < 0)
+ die("unable to create temp-file");
+
+ dup2(fd, 1);
+ close(fd);
- code = run_command_v(10, argv);
+ code = run_command_v(12, argv);
free(la);
free(lb);
free(lo);
if (code && code < -256) {
- die("Failed to execute 'merge'. merge(1) is used as the "
- "file-level merge tool. Is 'merge' in your path?");
+ die("Failed to execute 'diff3'. diff3(1) is used as the "
+ "file-level merge tool. Is 'diff3' in your path?");
}
- fd = open(src1, O_RDONLY);
+ fd = open(tmppath, O_RDONLY);
if (fd < 0 || fstat(fd, &st) < 0 ||
index_fd(result.sha, fd, &st, 1,
"blob"))
@@ -693,6 +704,7 @@ static struct merge_file_info merge_file
unlink(orig);
unlink(src1);
unlink(src2);
+ unlink(tmppath);
result.clean = WEXITSTATUS(code) == 0;
} else {
--
1.4.3.rc2
--
Uwe Zeisberger
http://www.google.com/search?q=1+newton+in+kg*m+%2F+s%5E2
^ permalink raw reply related
* t9100-git-svn-basic.sh fails
From: Uwe Zeisberger @ 2006-10-18 8:59 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]
zeisberg@cepheus:~$ uname -a
Linux cepheus 2.6.19-rc2-g51018b0a #17 SMP Mon Oct 16 12:51:05 CEST 2006 i686 GNU/Linux
zeisberg@cepheus:~$ dpkg -l subversion libsvn1 libapr1 libaprutil1 libdb4.4
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii libapr1 1.2.7-6 The Apache Portable Runtime Library
ii libaprutil1 1.2.7+dfsg-2 The Apache Portable Runtime Utility Library
ii libdb4.4 4.4.20-3 Berkeley v4.4 Database Libraries [runtime]
ii libsvn1 1.4.0-5 Shared libraries used by Subversion
ii subversion 1.4.0-5 Advanced version control system
zeisberg@cepheus:~/gsrc/git$ sh GIT-VERSION-GEN
GIT_VERSION = 1.4.2.4.g3453
(BTW, why that:
zeisberg@cepheus:~/gsrc/git$ grep ^DEF_VER GIT-VERSION-GEN
DEF_VER=v1.4.3.GIT
)
zeisberg@cepheus:~/gsrc/git/t$ sh t9100-git-svn-basic.sh
Perl SVN libraries not found, tests requiring those will be skipped
define NO_SVN_TESTS to skip git-svn tests
* ok 1: initialize git-svn
* ok 2: import an SVN revision into git
* ok 3: checkout from svn
* ok 4: try a deep --rmdir with a commit
* ok 5: detect node change from file to directory #1
* ok 6: detect node change from directory to file #1
* ok 7: detect node change from file to directory #2
* ok 8: detect node change from directory to file #2
* ok 9: remove executable bit from a file
* ok 10: add executable bit back file
* ok 11: executable file becomes a symlink to bar/zzz (file)
* ok 12: new symlink is added to a file that was also just made executable
FATAL: Unexpected exit with code 9
There is a warning about installing SVN Perl libraries to get fewer
bugs. Is that one of those? Is that test failure already known?
The output of the verbose run is attached.
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=i+squared
[-- Attachment #2: t9100-git-svn-basic-out.txt --]
[-- Type: text/plain, Size: 8258 bytes --]
Perl SVN libraries not found, tests requiring those will be skipped
define NO_SVN_TESTS to skip git-svn tests
* expecting success: git-svn init file:///home/zeisberg/gsrc/git/t/trash/svnrepo/test-git-svn
* ok 1: initialize git-svn
* expecting success: git-svn fetch
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/foo.link
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/foo
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/bar
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/bar/zzz
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/exec.sh
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/dir
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/dir/a
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/dir/a/b
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/dir/a/b/c
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/dir/a/b/c/d
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/dir/a/b/c/d/e
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/tree/dir/a/b/c/d/e/file
Checked out revision 1.
r1 = efbb057bfd612e3cd1890112efd96b4a2e397d89
* ok 2: import an SVN revision into git
* expecting success: svn co file:///home/zeisberg/gsrc/git/t/trash/svnrepo/test-git-svn /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/foo.link
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/foo
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/bar
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/bar/zzz
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec.sh
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir/a
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir/a/b
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir/a/b/c
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir/a/b/c/d
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir/a/b/c/d/e
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir/a/b/c/d/e/file
Checked out revision 1.
* ok 3: checkout from svn
* expecting success: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch &&
svn up /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree &&
test -d /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir && test ! -d /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir/a
diff-tree efbb057bfd612e3cd1890112efd96b4a2e397d89 78d4a6294c9d0dcac49c38ece1c1f20c74edcc68
A dir/file
A file
D dir/a/b/c/d/e/file
D dir/a/b/c/d/e/file
D dir/a/b/c/d/e
D dir/a/b/c/d/e/file
D dir/a/b/c/d/e
D dir/a/b/c/d
D dir/a/b/c/d/e/file
D dir/a/b/c/d/e
D dir/a/b/c/d
D dir/a/b/c
D dir/a/b/c/d/e/file
D dir/a/b/c/d/e
D dir/a/b/c/d
D dir/a/b/c
D dir/a/b
D dir/a/b/c/d/e/file
D dir/a/b/c/d/e
D dir/a/b/c/d
D dir/a/b/c
D dir/a/b
D dir/a
Committing 78d4a6294c9d0dcac49c38ece1c1f20c74edcc68: try a deep --rmdir with a commit
At revision 2.
r2 = f303d50d91b0f8353e1c8950b04b74ad1da89074
Done committing 1 revisions to SVN
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/file
D /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir/a
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/dir/file
Updated to revision 2.
* ok 4: try a deep --rmdir with a commit
* expecting failure: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch
diff-tree f303d50d91b0f8353e1c8950b04b74ad1da89074 c3711a70e5dfac068e95b43b0778dce17d3f3c53
* ok 5: detect node change from file to directory #1
* expecting failure: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch2
diff-tree f303d50d91b0f8353e1c8950b04b74ad1da89074 5eba97b4b68c76437c6a3dfd8c1712c235e6dbf1
* ok 6: detect node change from directory to file #1
* expecting failure: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch3
diff-tree f303d50d91b0f8353e1c8950b04b74ad1da89074 db5f4bce8265b9807ef76a92717af6a846c941dd
* ok 7: detect node change from file to directory #2
* expecting failure: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch4
diff-tree f303d50d91b0f8353e1c8950b04b74ad1da89074 97060150727530f2fa4b34e13ca83566501a0274
* ok 8: detect node change from directory to file #2
* expecting success: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
svn up /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree &&
test ! -x /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec.sh
diff-tree f303d50d91b0f8353e1c8950b04b74ad1da89074 f56cfd05f6959633698abb413a76e3879568fe6a
property 'svn:executable' deleted from 'exec.sh'.
Committing f56cfd05f6959633698abb413a76e3879568fe6a: remove executable bit from a file
At revision 3.
r3 = 150272d4f56833af23385f41289fa133fef9061d
Done committing 1 revisions to SVN
U /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec.sh
Updated to revision 3.
* ok 9: remove executable bit from a file
* expecting success: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
svn up /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree &&
test -x /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec.sh
diff-tree 150272d4f56833af23385f41289fa133fef9061d 835354f30dee357f2292e0d8457534d3c36a9ee0
property 'svn:executable' set on 'exec.sh'
Committing 835354f30dee357f2292e0d8457534d3c36a9ee0: add executable bit back file
At revision 4.
r4 = 5ff396d7d67dae86e0d031f10971bbd01c7dbc7a
Done committing 1 revisions to SVN
U /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec.sh
Updated to revision 4.
* ok 10: add executable bit back file
* expecting success: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
svn up /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree &&
test -L /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec.sh
diff-tree 5ff396d7d67dae86e0d031f10971bbd01c7dbc7a aecafe170fda3a28cffa283084038a78e0b9453a
D exec.sh
A exec.sh
Committing aecafe170fda3a28cffa283084038a78e0b9453a: executable file becomes a symlink to bar/zzz (file)
At revision 5.
r5 = b11753149d160cd083342368a6a817b67ebe5343
Done committing 1 revisions to SVN
D /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec.sh
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec.sh
Updated to revision 5.
* ok 11: executable file becomes a symlink to bar/zzz (file)
* expecting success: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
svn up /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree &&
test -x /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/bar/zzz &&
test -L /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec-2.sh
diff-tree b11753149d160cd083342368a6a817b67ebe5343 e68439578ed56b3c33137a4f1fb7f9f74a4c5abf
A exec-2.sh
Committing e68439578ed56b3c33137a4f1fb7f9f74a4c5abf: new symlink is added to a file that was also just made executable
At revision 6.
r6 = 601ae0df2203d0b8c81774101d426b4b009b0f59
Done committing 1 revisions to SVN
A /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec-2.sh
Updated to revision 6.
* ok 12: new symlink is added to a file that was also just made executable
* expecting success: git-svn commit --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
svn up /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree &&
test -f /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec-2.sh &&
test ! -L /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec-2.sh &&
diff -u help /home/zeisberg/gsrc/git/t/trash/.git/svn/git-svn/svn-tree/exec-2.sh
diff-tree 601ae0df2203d0b8c81774101d426b4b009b0f59 69fa6b2e91eb2b7af80e86b4af01d6c539f0aa21
D exec-2.sh
A exec-2.sh
FATAL: Unexpected exit with code 9
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-18 8:53 UTC (permalink / raw)
To: Robert Collins; +Cc: bazaar-ng, git, Jakub Narebski
In-Reply-To: <1161147348.3423.24.camel@localhost.localdomain>
Robert Collins wrote:
> On Tue, 2006-10-17 at 12:08 +0200, Andreas Ericsson wrote:
>> Robert Collins wrote:
>>> On Tue, 2006-10-17 at 11:20 +0200, Jakub Narebski wrote:
>>>> ---- time --->
>>>>
>>>> --*--*--*--*--*--*--*--*--*-- <branch>
>>>> \ /
>>>> \-*--X--*--/
>>>>
>>>> The branch it used to be on is gone...
>>> In bzr 0.12 this is :
>>> 2.1.2
>>>
>> Would it be a different number in a different version of bazaar?
>
> The dotted decimal display has only been introduced in bzr 0.12
>
>>> (assuming the first * is numbered '1'.)
>>>
>>> These numbers are fairly stable, in particular everything's number in
>>> the mainline will be the same number in all the branches created from it
>>> at that point in time, but a branch that initially creates a revision or
>>> obtains it before the mainline will have a different number until they
>>> syncronise with the mainline via pull.
>>>
>> So basically anyone can pull/push from/to each other but only so long as
>> they decide upon a common master that handles synchronizing of the
>> number part of the url+number revision short-hands?
>
> Anyone can push and pull from each other - full stop. Whenever they
> 'pull' in bzr terms, they get fast-forward happening (if I understand
> the git fast-forward behaviour correctly). After a fast-forward, the
> dotted decimal revision numbers in the two branches are identical - and
> they remain immutable until another fast forward occurs.
This is where it breaks down for me. "until another fast forward occurs"
is just not good enough, imo.
>
>> One thing that's been nagging me is how you actually find out the
>> url+number where the desired revision exists. That is, after you've
>> synced with master, or merged the mothership's master-branch into one of
>> your experimental branches where you've done some work that went before
>> mothership's master's current tip, do you have to have access to the
>> mothership's repo (as in, do you have to be online) to find out the
>> number part of url+number shorthand, or can you determine it solely from
>> what you have on your laptop?
>
> You can determine it locally - if you know any of the motherships
> revisions locally, we can generate the dotted-revnos that the
> motherships master-branch would have from the local data - and the last
> merge of mothership you did will have given you that details.
To me, this means bazaar isn't distributed at all and I could achieve
much the same distributedness(?) by rsyncing an SVN repo, working
against that and then rsyncing it back with some fancy merging. In other
words, bazaar requires there to be one Lord of the Code, or some of the
key features break down.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-18 8:39 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Carl Worth, Jakub Narebski, Linus Torvalds, bazaar-ng, git
In-Reply-To: <45359B2A.1070102@utoronto.ca>
Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Carl Worth wrote:
>> Aaron, thanks for carrying this thread along and helping to bridge
>> some communication gaps. For example, when I saw your original two two
>> diagrams I was totally mystified how you were claiming that appending
>> a couple of nodes and edges to a DAG could change the "order" of the
>> DAG.
>>
>> I think I understand what you're describing with the leftmost-parent
>> ordering now. But it's definitely an ordering that I would describe as
>> local-only. That is, the ordering has meaning only with respect to a
>> particular linearization of the DAG and that linearization is
>> different from one repository to the next.
>
> Well, the linarization for any particular head is well-defined, but
> since different branches have different heads...
>
>> If in practice, nobody does the mirroring "pull" operation then how
>> are the numbers useful? For example, given your examples above, if
>> I'm understanding the concepts and terminology correctly, then if A
>> and B both "merge" from each other (and don't "pull") then they will
>> each end up with identical DAGs for the revision history but totally
>> distinct numbers. Correct?
>
> The DAGs will be different. If A merges B, we get:
>
> a
> |
> b
> |\
> c d
> |\|
> | e
> |/
> f
>
> If B merges A before this, nothing happens, because B is already a
> superset of A.
>
> If B merges afterward, we get this:
> a
> |
> b
> |\
> d c
> |/|
> e |
> |\|
> | f
> |/
> g
>
Seems like an awful lot of merge commits. In git, I think these trees
would be identical (actually both to bazaar and to each other), with the
exception that the 'g' commit wouldn't exist, since git does
fast-forward and relies on dependency-chain only to present the graph
instead of mucking around with info in external files (recording of
fetches).
>> So in that situation the numbers will not help A and B determine that
>> they have identical history or even identical working trees.
>
> They don't really have identical history.
>
As explained above, they would be identical in git. The fact that you
register a fast-forward as a merge makes them not so, but this is
something most gitizens are against, as it can quickly clutter up the DAG.
>> So what good are the numbers?
>
> They are good for naming mainline revisions that introduced particular
> changes.
>
>> I can see that the numbers would have applicability with reference to
>> a single repository, (or equivalently a mirror of that repository),
>> but no utility as soon as there is any distributed development
>> happening.
>
> Well, there's distributed, and then there's *DISTRIBUTED*. We don't
> quasi-randomly merge each others' branches. We have a star topology
> around bzr.dev. So when we refer to revnos, they're usually in bzr.dev.
>
So in essence, the revnos work wonderfully so long as there is a central
server to make them immutable?
Doesn't this mean that one of your key features doesn't actually work in
a completely distributed setup (i.e., each dev has his own repo, there
is no mother-ship, everyone pulls from each other)?
I can see the six-line hook that lays the groundwork for this in git
before me right now. I'll happily refuse to write it down anywhere. I
get the feeling that sha's are easier to handle in the long run, while
revno's might be good to use in development work. In git, we have
<branch/tag/"committish">~<number> syntax for this.
In my experience, finding the revision sha of an old bug is what takes
time. Copy-paste is just as fast with 20 bytes as with 4 bytes. Honestly
now, do you actually remember the revno for a bug that you stopped
working on three weeks ago, or do you have to go look it up? If someone
wants to notify you about the revision a bug was introduced, do they not
communicate the revno to you by email/irc/somesuch?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-18 8:13 UTC (permalink / raw)
To: Aaron Bentley; +Cc: Jakub Narebski, bazaar-ng, git
In-Reply-To: <4535685C.4010502@utoronto.ca>
Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jakub Narebski wrote:
>> Aaron Bentley wrote:
>> By the way, are bzr "bundles" compatibile with ordinary patch?
>> git-format-patch patches are. They have additional metainfo,
>> but they are patches in heart.
>
> Yes, they are.
>
Sounds a bit like [PATCH 0/8] would have the output of
git diff $(git merge-base master)..topic-branch
for any given patch-series. It might be easier to review the whole
patch-series in some cases. Especially with patch-series where more than
one patch touches the same part of the code.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Make the ftplugin right wrt gitdir
From: Pierre Habouzit @ 2006-10-18 8:10 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061018070239.GD3507@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 659 bytes --]
Le mer 18 octobre 2006 09:02, Jeff King a écrit :
> On Wed, Oct 18, 2006 at 02:47:25AM +0200, Pierre Habouzit wrote:
> > sorry for the mess, I'm a bit tired :)
> > Here is a third patch to fix the plugin to find the git-dir
> > properly.
> >
> > Also add a nice shortcut to quit that buffer.
>
> Looks like the patch is missing (more sleep required?).
err, the patch is here:
<1161132446703-git-send-email-madcoder@debian.org>
at least I see it on the list for my part
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- 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