* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Karl Hasselström @ 2006-10-26 9:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehppbg$phq$1@sea.gmane.org>
On 2006-10-26 09:50:48 +0200, Jakub Narebski wrote:
> That said, git-am should understand QP with coding in mail headers.
I really hope it does, since I just patched StGIT to generate such
headers. (Out of pure vanity -- I don't want my name mangled!)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: What's in git.git
From: Jakub Narebski @ 2006-10-26 9:19 UTC (permalink / raw)
To: git
In-Reply-To: <7vk62npipb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I did not hear any comments on the left-right stuff; perhaps
> it is not needed, or it is not useful as its current shape (it
> could be enhanced to say which starting commits each of the
> commit is reachable from, by borrowing much of show-branch
> code).
It looks reasonable, and useful.
> I looked at Pasky's "project forks" gitweb code, and while I
> liked it a lot (having a demonstration site repo.or.cz really
> helps), I read on #git log that Pasky himself was having
> doubt, so it is parked in "pu", not in "next".
Perhaps that's for the best.
By the way, Pasky, where one can find your changes to gitweb?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-10-26 9:24 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehpu4t$ch2$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> I've flushed all the 'gitweb/' changes from "next" and core
>> support that some of them needed; notably "for-each-ref" and
>> "blame --porcelain" is now in "master". Oh, and "annotate"
>> is now a mere synonym for "blame -c".
>> gitweb: prepare for repositories with packed refs.
>> gitweb: use for-each-ref to show the latest activity across branches
>
> This unfortunately means that I cannot test gitweb based on 'master'
> branch using _released_ git core, git version 1.4.3.3, as it doesn't have
> git-for-each-ref nor git-show-ref.
As long as "master" version of gitweb goes with "master" version
of the core, I do not see it as a problem. Otherwise how would
you make any progress?
> ... Should
> we try to wait for core feature to mature to released version before using
> it in gitweb?
That's both insulting and inconsistent.
Insulting in that somehow you seem to feel "master" is lessor
quality than "maint", and inconsistent in that you seem to find
"gitweb" is somehow more special than other scripts we ship as
part of the git.git project sources.
Anyhow, I have done my fair share of git hacking for the week,
so I'll stop venting and go to bed.
^ permalink raw reply
* Re: merge-recursive, was Re: What's in git.git
From: Jakub Narebski @ 2006-10-26 9:25 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0610261114520.3286@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> BTW what happened to the builtin shortlog? It is the last Perl script I
> use regularly... (should make people happy who are stuck with Activision
> Perl...)
BTW. both Perl version and builtin shorlog have email->real name translation
table built in. In Perl script version it is in __DATA__ section, and we
could update it using Inline::Files module, in C version it was in table.
But in fact this list is project specific. Shouldn't we make it customizable
(::sigh::, yet another file in $GIT_DIR...).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: merge-recursive, was Re: What's in git.git
From: Junio C Hamano @ 2006-10-26 9:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0610261114520.3286@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 26 Oct 2006, Junio C Hamano wrote:
>
>> We'd still need more work on merge-recursive to fix the
>> overcautious "working file will be overwritten by merge" --
>> this is really needed for usability.
>
> I am sorry, but I do not have the time to wrap my head around this for at
> least another week. It seems to be a complicated problem (not the fix,
> mind you, but the side effects you have to think of!), and I stupidly
> started to play with shallow clones when I knew I had no time already.
No need to worry nor feel pressure; it's all volunteer work and
we do this for fun.
> BTW what happened to the builtin shortlog? It is the last Perl script I
> use regularly... (should make people happy who are stuck with Activision
> Perl...)
Yeah, I was wondering about it too, when I was looking for
something readily mergeable to "next" today. I must have
misplaced it.
^ permalink raw reply
* Re: VCS comparison table
From: Junio C Hamano @ 2006-10-26 9:33 UTC (permalink / raw)
To: James Henstridge
Cc: bazaar-ng, Carl Worth, Matthew D. Fuller, Linus Torvalds,
Andreas Ericsson, git, Jakub Narebski
In-Reply-To: <a7e835d40610260152k658aeaf0hb900cb63870c04e4@mail.gmail.com>
"James Henstridge" <james@jamesh.id.au> writes:
> Can you really just rely on equal revision IDs meaning you have the
> same code though?
If you two have the same commit that is a guarantee that you two
have identical trees. The reverse is not true as logic 101
would teach ;-).
Doing fast-forward instead of doing a "useless" merges helps
somewhat but not in cases like two people merging the same
branches the same way or two people applying the same patch on
top of the same commit. You need to compare tree object IDs for
that.
>> 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).
>
> Or run "bzr missing". If the sole missing revision is a merge (and
> not the revisions introduced by the merge), you could assume that you
> have the same tree state.
Is it "you could assume" or "it is guaranteed"? If former, what
kind of corner cases could invalidate that assumption?
^ permalink raw reply
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Junio C Hamano @ 2006-10-26 9:33 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061026091925.GD13780@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2006-10-26 09:50:48 +0200, Jakub Narebski wrote:
>
>> That said, git-am should understand QP with coding in mail headers.
>
> I really hope it does, since I just patched StGIT to generate such
> headers. (Out of pure vanity -- I don't want my name mangled!)
Sorry for an earlier hiccup.
^ permalink raw reply
* Re: merge-recursive, was Re: What's in git.git
From: Junio C Hamano @ 2006-10-26 9:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ehputm$ch2$3@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Johannes Schindelin wrote:
>
>> BTW what happened to the builtin shortlog? It is the last Perl script I
>> use regularly... (should make people happy who are stuck with Activision
>> Perl...)
>
> BTW. both Perl version and builtin shorlog have email->real name translation
> table built in. In Perl script version it is in __DATA__ section, and we
> could update it using Inline::Files module, in C version it was in table.
> But in fact this list is project specific. Shouldn't we make it customizable
> (::sigh::, yet another file in $GIT_DIR...).
It already reads from .mailmap which could be tracked as part of
the sources (if it is project specific it would be better if it
can be shared among members).
^ permalink raw reply
* Re: [PATCH (resend)] gitweb: Use --no-commit-id in git_commit and git_commitdiff
From: Jakub Narebski @ 2006-10-26 9:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejsvpi4d.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Use --no-commit-id option to git-diff-tree command in git_commit and
> > git_commitdiff to filter out commit ID output that git-diff-tree adds
> > when called with only one <tree-ish> (not only for --stdin). Remove
> > filtering commit IDs from git-diff-tree output.
> >
> > This option is in git since at least v1.0.0, so make use of it.
>
> *BLUSH*
>
> I think we would need something like this, if only for
> completeness.
>
> -- >8 --
> [PATCH] combine-diff: honour --no-commit-id
>
> Somehow we forgot to look at no_commit_id flag in these
> codepaths.
It's good that I haven't started coding support for combined commitdiff
in gitweb, as I would probably wonder why the code doesn't work ;-)
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Karl Hasselström @ 2006-10-26 9:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpscfo1z1.fsf@assigned-by-dhcp.cox.net>
On 2006-10-26 02:33:54 -0700, Junio C Hamano wrote:
> Sorry for an earlier hiccup.
Without the occasional hiccup we wouldn't have any itches to scratch,
and there would be no progress. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: merge-recursive, was Re: What's in git.git
From: Jakub Narebski @ 2006-10-26 9:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkn3o1w1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> BTW. both Perl version and builtin shorlog have email->real name translation
>> table built in. In Perl script version it is in __DATA__ section, and we
>> could update it using Inline::Files module, in C version it was in table.
>> But in fact this list is project specific. Shouldn't we make it customizable
>> (::sigh::, yet another file in $GIT_DIR...).
>
> It already reads from .mailmap which could be tracked as part of
> the sources (if it is project specific it would be better if it
> can be shared among members).
By the way, if I read code correctly, it read '.mailmap' from _current_
directory. Shouldn't it read qx(git-rev-parse --show-cdup)/.mailmap ?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-26 9:50 UTC (permalink / raw)
To: James Henstridge
Cc: Carl Worth, bazaar-ng, Matthew D. Fuller, Linus Torvalds, git,
Jakub Narebski
In-Reply-To: <a7e835d40610260152k658aeaf0hb900cb63870c04e4@mail.gmail.com>
James Henstridge wrote:
> On 25/10/06, Carl Worth <cworth@cworth.org> wrote:
>> 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.
>
> Can you really just rely on equal revision IDs meaning you have the
> same code though?
>
Yes. Because each commit contains parent revision id's, which in turn
contain *their* parent revision id's, which in turn..., you know you
have exactly the same revision, code, and history leading up to that
revision. You may have other revisions on top or on other branches, but
all commits, including merge-points and whatnot, leading to that
particular revision id are EXACTLY identical.
> Lets say that I clone your git repository, and then we both merge the
> same diverged branch. Will our head revision IDs match? From a quick
> look at the logs of cairo, it seems that the commits generated for
> such a merge include the date and author, so the two commits would
> have different SHA1 sums (and hence different revision IDs).
>
> So I'd have a revision you don't have and vice versa, even though the
> trees are identical.
>
Merges preserve author and commit info. You may need to create a new
branch (a git branch, the cheap kind which is a 41-byte file) and fetch
"his" into "yours". This will be very cheap if you both have the same
code but not the same history, as everything but a few commit-objects
will be shared. A more likely scenario though is this;
Bob writes a feature that doesn't work as per spec. He doesn't know why.
He asks Alice to have a look, so he communicates the commits to her by
"please pull this branch from here", or by sending patches and telling
Alice the branch-point revision to apply them to.
Alice creates the "bobs-bugs/nr1232" at the branch-point and fetches
Bobs branch into that or applies the patches on top of that (in the
fetch scenario she wouldn't need to know the branch point, since git
would figure this out for her).
She knows this should create a revision named 00123989aaddeddad39, so if
it doesn't, she doesn't have the same code.
I imagine this works roughly the same in bazaar, although the original
case where tests have already been done and the testers wanted to know
if they had the exact same revision Just Works in git.
>
>> 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).
>
> Or run "bzr missing". If the sole missing revision is a merge (and
> not the revisions introduced by the merge), you could assume that you
> have the same tree state.
>
"assume" != "know", or was that just sloppy phrasing?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Jakub Narebski @ 2006-10-26 9:56 UTC (permalink / raw)
To: git
In-Reply-To: <7vpscfo1z1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
>> On 2006-10-26 09:50:48 +0200, Jakub Narebski wrote:
>>
>>> That said, git-am should understand QP with coding in mail headers.
>>
>> I really hope it does, since I just patched StGIT to generate such
>> headers. (Out of pure vanity -- I don't want my name mangled!)
>
> Sorry for an earlier hiccup.
That said, I don't think that Nicolas Pitre wanted to have "index-pâck"
in subject instead of "index-pack".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: James Henstridge @ 2006-10-26 9:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: bazaar-ng, Matthew D. Fuller, Linus Torvalds, Andreas Ericsson,
Carl Worth, git, Jakub Narebski
In-Reply-To: <7vu01ro20b.fsf@assigned-by-dhcp.cox.net>
On 26/10/06, Junio C Hamano <junkio@cox.net> wrote:
> "James Henstridge" <james@jamesh.id.au> writes:
>
> > Can you really just rely on equal revision IDs meaning you have the
> > same code though?
>
> If you two have the same commit that is a guarantee that you two
> have identical trees. The reverse is not true as logic 101
> would teach ;-).
That was the point I was trying to make. Carl asserted that in git
you could tell if you had the same tree as someone else based on
revision IDs, which doesn't seem to be the case all the time.
The reverse assertion (that if you have the same revision ID, you have
the same tree) seems to hold equally in git and Bazaar.
> Doing fast-forward instead of doing a "useless" merges helps
> somewhat but not in cases like two people merging the same
> branches the same way or two people applying the same patch on
> top of the same commit. You need to compare tree object IDs for
> that.
Sure, you can do the same in Bazaar by comparing the inventories for
the two revisions.
>
> >> 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).
> >
> > Or run "bzr missing". If the sole missing revision is a merge (and
> > not the revisions introduced by the merge), you could assume that you
> > have the same tree state.
>
> Is it "you could assume" or "it is guaranteed"? If former, what
> kind of corner cases could invalidate that assumption?
The merge revision will also include any manual conflict resolution.
If the other person resolved the conflicts differently.
^ permalink raw reply
* Re: merge-recursive, was Re: What's in git.git
From: Junio C Hamano @ 2006-10-26 10:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Linus Torvalds
In-Reply-To: <7v3b9bpgvs.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> BTW what happened to the builtin shortlog? It is the last Perl script I
>> use regularly... (should make people happy who are stuck with Activision
>> Perl...)
>
> Yeah, I was wondering about it too, when I was looking for
> something readily mergeable to "next" today. I must have
> misplaced it.
I looked at the code again.
This is a prime demonstration that it makes more sense to keep
script version until we flush out configurability issues.
The built-in mailmap list is easily overridden with ".mailmap"
which presumably projects would want to keep under version
control, so it is less of an issue, but not everybody would
necessarily want to name that file ".mailmap".
There is a "dot3" merge source shortening logic that is very
specific to the kernel, and this cannot be customized per
project. If it were kept as Perl script, each project could
limp along with a copy of this script, modified for their needs,
without making the script itself customizable. Rewriting it
into C does not _forbid_ that kind of use, but certainly it
makes it more cumbersome to do so.
First I'd probably ask kernel folks to maintain their own
copy of .mailmap at the toplevel of their source tree, so that
we can remove this kernel specific built-in mailmap from
shortlog (I'd even do so before switching from the Perl
version).
The dot3 logic is probably best substituted with config, a
version controllable file similar to .mailmap, or command line
parameters, but I am not sure which one is the best way to go.
Whatever mechanism is used, It essentially is to define a
mapping from a long string to its abbreviation (currently there
is one hardcoded one, that replaces /pub/scm/linux/kernel/git/
to /.../), to be applied to the first line of log message body.
Presumably other projects could have more than one "popular"
prefixes that appear often, so (if we take command line
approach, which I think is the worst of the three possibilities)
the "slightly more generalized" version would look something
like this perhaps?
git-shortlog --mailmapfile=.mailmap \
--abbrev=/pub/scm/linux/kernel/git/,/.../ \
--abbrev=/pub/scm/,/.../../
We could even define the --abbrev stuff as 's/from/to/' but that
would make it harder for us to shake Perl off, and in practice
this is to shorten the merge source repository name, so
deliberately limiting its feature to simple string replace like
the above might make more sense.
^ permalink raw reply
* Why perl-Git RPM doesn't come with Git.pm docs (with Git.3pm.gz)?
From: Jakub Narebski @ 2006-10-26 10:07 UTC (permalink / raw)
To: git
I have just installed git 1.4.3.3, compiling it from source rpm (SRPMS)
because I have Fedora Core 4 based distribution (Aurox 11.1) and i386 rpm
is built for Fedora Core 5 via rpmbuild --rebuild, and I do wonder why
perl-Git module has only
/usr/lib/perl5/vendor_perl/5.8.6/Git.pm
in it, and doesn't have Git.pm documentation
/usr/share/man/man3/Git.3pm.gz
I'm also curious wy I had to install perl-Error (Error module), if
I compiled git myself. Ahhh... I see, perl(Error) is in BuildRequires
in git.spec (BuildRequires?).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: VCS comparison table
From: Jeff King @ 2006-10-26 10:10 UTC (permalink / raw)
To: James Henstridge
Cc: Junio C Hamano, bazaar-ng, Matthew D. Fuller, Linus Torvalds,
Andreas Ericsson, Carl Worth, git, Jakub Narebski
In-Reply-To: <a7e835d40610260257r5f05ea4gc934f1c1cc267977@mail.gmail.com>
On Thu, Oct 26, 2006 at 05:57:20PM +0800, James Henstridge wrote:
> >If you two have the same commit that is a guarantee that you two
> >have identical trees. The reverse is not true as logic 101
> >would teach ;-).
>
> That was the point I was trying to make. Carl asserted that in git
> you could tell if you had the same tree as someone else based on
> revision IDs, which doesn't seem to be the case all the time.
If you have the same revision (commit IDs), you have the same tree (at
the same time, by the same committer, etc).
If you have a different revision (commit), you may or may not have the
same tree. You can then check the tree id, which will either be the same
(you have the same tree) or differ (you don't).
Thus, in the converse, if you have the same tree, you _will_ have the
same tree id. You may or may not have the same commit id.
^ permalink raw reply
* Re: VCS comparison table
From: Andreas Ericsson @ 2006-10-26 10:13 UTC (permalink / raw)
To: Matthew D. Fuller; +Cc: bazaar-ng, David Lang, git
In-Reply-To: <20061025235306.GD17019@over-yonder.net>
Matthew D. Fuller wrote:
>
>> 3. pull from each other frequently to keep in sync.
>>
>> this changes the topology to
>>
>> Master
>> / \
>> dev1--dev2
>>
>> if they do this with bzr then the revno's break, they each get extra
>> commits showing up (so they can never show the same history).
>
> These two are either/or, not and; either they pull (in which case
> their old mainline is no longer meaningful), or they merge (in which
> case they get the 'extra' merge commits).
>
>
>> in git this is a non-issue, they can pull back and forth and the
>> only new history to show up will be changes.
>
> In git, this is a non-issue because you don't get to CHOOSE which way
> to work.
Yes they do. They can (and in this case probably will) create a
topic-branch named "the-other-dev/featureX" and keep it solely for
tracking the other peers changes, keeping their own topic-branch for
their own changes, and another branch where they merge both changes in,
or cherry-pick from each branch to get to the desired result fast. This
works easily because in git
a) branches are as cheap as I can ever imagine an SCM making them.
b) the "slice the DAG and view anything you like from any branch you
like any time you like and mix them however you want" approach of the
visualizers makes it trivial for a 10-year old fledgling programmer to
see what changes what, and where, and by whom, and why.
The "b" above was a feature I didn't know I needed until it became
available to me. Thanks to Paul Mackerras (spelling?) for creating the
wonderful gitk tool, and to Marco Costalba for making a faster and, imo,
more capable version of it.
> You always (if you can) pull and obliterate your local
> mainline. In bzr, it's only an 'issue' because you CAN choose, and
> CAN maintain your local mainline.
Git puts emphasis on code. Bazaar puts emphasis on developers and
branch-structure. Depending on your preferrence, I imagine one suits
some people better. I really, really, really don't care if my branch-tip
gets moved because I hadn't made any changes to it while the other dev
hacked away or if it causes a merge because we had decided to work on
different parts of the feature. Perhaps this is a result of the insanely
good visualizers (kudos again to Paul and Marco) that easily lets me see
who did what when and where anyways. What I *do* care about is being
able to easily make sure all the devs have the same code to work and
test with.
> You CAN choose, right now, to do a
> git and pull back and forth and only new history show up as changed by
> creating a 'bzr-pull' shell script that does a 'bzr pull || bzr merge'
> (though you'd be a lot better off adding a '--fast-forward-if-you-can'
> option to merge and aliasing that over).
>
> More basically, though, I don't think that "histories become exactly
> equivalent" is a necessary pass-word to enter the Hallowed City of
> Truely Distributed Development.
The only issue I have with bzr's revno's and truly distributed setup is
that, by looking at the table, it seems to claim that you have found
some miraculous way to make revnos work without a central server. Since
everyone agrees that they don't, this should IMO be listed as mutually
exclusive features.
On a side-note, git has made my life easier, so I childishly want to
defend it and see it on top of every list in the world. Something I'm
sure I share with more people on this list and with some of the bazaar
users/devs. ;-)
^ permalink raw reply
* Re: [PATCH 1/3] make index-pâck able to complete thin packs
From: Catalin Marinas @ 2006-10-26 10:13 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jakub Narebski, git
In-Reply-To: <20061026091925.GD13780@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> wrote:
> On 2006-10-26 09:50:48 +0200, Jakub Narebski wrote:
>
>> That said, git-am should understand QP with coding in mail headers.
>
> I really hope it does, since I just patched StGIT to generate such
> headers. (Out of pure vanity -- I don't want my name mangled!)
It looks like it does, that's how I applied some of your patches ('stg
import' doesn't understand them).
--
^ permalink raw reply
* Re: [PATCH] git-svnimport: support for partial imports
From: Sasha Khapyorsky @ 2006-10-26 10:31 UTC (permalink / raw)
To: Karl Hasselstr?m; +Cc: Junio C Hamano, git, Matthias Urlichs
In-Reply-To: <20061026084710.GC13780@diana.vm.bytemark.co.uk>
On 10:47 Thu 26 Oct , Karl Hasselstr?m wrote:
> On 2006-10-26 00:50:26 +0200, Sasha Khapyorsky wrote:
>
> > This adds support for partial svn imports. Let's assume that SVN
> > repository layout looks like:
> >
> > $trunk/path/to/our/project
> > $branches/path/to/our/project
> > $tags/path/to/our/project
> >
> > , and we would like to import only tree under this specific
> > 'path/to/our/project' and not whole tree under $trunk, $branches,
> > etc.. Now we will be be able to do it by using '-P
> > path/to/our/project' option with git-svnimport.
>
> Isn't this already doable with "-T trunk/path/to/our/project -t
> tags/path/to/our/project -b branches/path/to/our/project"?
In such case git-svnimport will not be able to resolve branches and
tags names - note that actual SVN paths are:
branches/<branch-name>/path/to/our/project
tags/<tag-name>/path/to/our/project
^ permalink raw reply
* [PATCH] gitweb: Check git base URLs before generating URL from it
From: Jakub Narebski @ 2006-10-26 10:26 UTC (permalink / raw)
To: git
Check if each of git base URLs in @git_base_url_list is true before
appending "/$project" to it to generate project URL.
This fixes the error that for default configuration for gitweb in
Makefile, with GITWEB_BASE_URL empty (and "++GITWEB_BASE_URL++" being
"" in gitweb.cgi), we had URL of "/$project" in the summary view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I don't think that anybody would want base URL of "0".
gitweb/gitweb.perl | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 35a9afb..0d2ea72 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2516,7 +2516,8 @@ sub git_summary {
# or make project git URL from git base URL and project name
my $url_tag = "URL";
my @url_list = git_get_project_url_list($project);
- @url_list = map { "$_/$project" } @git_base_url_list unless @url_list;
+ @url_list = map { $_ ? "$_/$project" : () }
+ @git_base_url_list unless @url_list;
foreach my $git_url (@url_list) {
next unless $git_url;
print "<tr><td>$url_tag</td><td>$git_url</td></tr>\n";
--
1.4.3.3
^ permalink raw reply related
* [PATCH] Improve git-prune -n output
From: Andy Parkins @ 2006-10-26 10:38 UTC (permalink / raw)
To: git
prune_object() in show_only mode would previously just show the path to the
object that would be deleted. The path the object is stored in shouldn't be
shown to users, they only know about sha1 identifiers so show that instead.
Further, the sha1 alone isn't that useful for examining what is going to be
deleted. This patch also adds the object type to the output, which makes it
easy to pick out, say, the commits and use git-show to display them.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-prune.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/builtin-prune.c b/builtin-prune.c
index 7290e6d..e3bcf5f 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -16,8 +16,13 @@ static struct rev_info revs;
static int prune_object(char *path, const char *filename, const unsigned char *sha1)
{
+ char type[20];
+
if (show_only) {
- printf("would prune %s/%s\n", path, filename);
+ if (sha1_object_info(sha1, type, NULL)) {
+ strcpy( type, "unknown type" );
+ }
+ printf("would prune %s %s\n", sha1_to_hex( sha1 ), type );
return 0;
}
unlink(mkpath("%s/%s", path, filename));
--
1.4.2.3
^ permalink raw reply related
* Re: VCS comparison table
From: Erik Bågfors @ 2006-10-26 10:45 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Matthew D. Fuller, bazaar-ng, David Lang, git
In-Reply-To: <45408A53.10400@op5.se>
> On a side-note, git has made my life easier, so I childishly want to
> defend it and see it on top of every list in the world. Something I'm
> sure I share with more people on this list and with some of the bazaar
> users/devs. ;-)
Haha, I feel the same way about bzr. Some of the features that bazaar
has, such as how it preservs the leftmost parent and treats that
specially in some cases, are things that I REALLY love and don't want
to live without.
All in all, I feel that git and bazaar and both excellent products,
what will happen in the future will be interesting to see.
/Erik
--
google talk/jabber. zindar@gmail.com
SIP-phones: sip:erik_bagfors@gizmoproject.com
^ permalink raw reply
* Re: VCS comparison table
From: Vincent Ladeuil @ 2006-10-26 10:52 UTC (permalink / raw)
To: Jeff King
Cc: James Henstridge, Junio C Hamano, bazaar-ng, Matthew D. Fuller,
Linus Torvalds, Carl Worth, Andreas Ericsson, git, Jakub Narebski
In-Reply-To: <20061026101038.GA13310@coredump.intra.peff.net>
>>>>> "Jeff" == Jeff King <peff@peff.net> writes:
Jeff> On Thu, Oct 26, 2006 at 05:57:20PM +0800, James Henstridge wrote:
>> >If you two have the same commit that is a guarantee that you two
>> >have identical trees. The reverse is not true as logic 101
>> >would teach ;-).
>>
>> That was the point I was trying to make. Carl asserted that in git
>> you could tell if you had the same tree as someone else based on
>> revision IDs, which doesn't seem to be the case all the time.
Jeff> If you have the same revision (commit IDs), you have
Jeff> the same tree (at the same time, by the same committer,
Jeff> etc).
Jeff> If you have a different revision (commit), you may or
Jeff> may not have the same tree. You can then check the tree
Jeff> id, which will either be the same (you have the same
Jeff> tree) or differ (you don't).
Jeff> Thus, in the converse, if you have the same tree, you
Jeff> _will_ have the same tree id. You may or may not have
Jeff> the same commit id.
Ok, so git make a distinction between the commit (code created by
someone) and the tree (code only).
Commits are defined by their parents.
Trees are defined by their content only ?
If that's the case, how do you proceed ?
Calculate a sha1 representing the content (or the content of the
diff from parent) of all the files and dirs in the tree ? Or
from the sha1s of the files and dirs themselves recursively based
on sha1s of the files and dirs they contain ?
I ask because the later seems to provide some nice effects
similar to what makes BDD
(http://en.wikipedia.org/wiki/Binary_decision_diagram) so
efficient: you can compare graphs of any complexity or size in
O(1) by just comparing their signatures.
Vincent
^ permalink raw reply
* Re: [PATCH] git-svnimport: support for partial imports
From: Karl Hasselström @ 2006-10-26 10:54 UTC (permalink / raw)
To: Sasha Khapyorsky; +Cc: Junio C Hamano, git, Matthias Urlichs
In-Reply-To: <20061026103120.GA15502@sashak.voltaire.com>
On 2006-10-26 12:31:20 +0200, Sasha Khapyorsky wrote:
> On 10:47 Thu 26 Oct, Karl Hasselström wrote:
> > Isn't this already doable with "-T trunk/path/to/our/project -t
> > tags/path/to/our/project -b branches/path/to/our/project"?
>
> In such case git-svnimport will not be able to resolve branches and
> tags names - note that actual SVN paths are:
>
> branches/<branch-name>/path/to/our/project
> tags/<tag-name>/path/to/our/project
Aahh, right. I didn't think of that.
--
Karl Hasselström, kha@treskal.com
^ 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