* [ANN] ditz 0.4 released
From: William Morgan @ 2008-07-28 20:26 UTC (permalink / raw)
To: Git Mailing List
Ditz version 0.4 has been released! This release features improved git
integration.
http://ditz.rubyforge.org
Ditz is a simple, light-weight distributed issue tracker designed to work with
distributed version control systems like git, darcs, Mercurial, and Bazaar. It
can also be used with centralized systems like SVN.
Ditz maintains an issue database directory on disk, with files written in a
line-based and human-editable format. This directory can be kept under version
control, alongside project code.
Ditz provides a simple, console-based interface for creating and updating the
issue database file, and some rudimentary HTML generation capabilities for
producing world-readable status pages. It currently offers no central public
method of bug submission.
Synopsis:
# set up project. creates the bugs.yaml file.
1. ditz init
2. ditz add-release
# add an issue
3. ditz add
# where am i?
4. ditz status
5. ditz todo (or simply "ditz")
# do work
6. write code
7. ditz close <issue-id>
8. commit
9. goto 3
# finished!
10. ditz release <release-name>
Changes:
## 0.4 / 2008-07-27
* bugfix: HOME environment variable now correctly detected on windows
* hooks loaded from both home directory and project directory
* added bash shell completion
* plugin architecture for tighter SCM integration, etc
* 'ditz grep' should also grep against comments, log messages, etc
* added man page
* removed ditz-convert-from-monolith
* lots of HTML output tweaking
--
William <wmorgan-git@masanjin.net>
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 20:59 UTC (permalink / raw)
To: Nigel Magnay, Git ML
In-Reply-To: <20080728205545.GB10409@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]
On Mon, Jul 28, 2008 at 08:55:45PM +0000, Pierre Habouzit wrote:
> On Mon, Jul 28, 2008 at 08:23:39PM +0000, Nigel Magnay wrote:
> That too indeed (the "easier to clone" bit). OTOH, I don't like the
> .git/submodules idea a lot, if you mean to put a usual $GIT_DIR layout
> inside of it. With what I propose, you find objects for all your
> super/sub-modules in the usual store, which eases many things.
> Especially, I believe that when you replace a subdirectory of a project
> with a submodule, git-blame could benefit quite a lot from this to be
> able to glue history back through the submodule limits, without having
> to refactor a _lot_ of code: it would merely have to dereference so
> called "gitlinks" to the commit then tree, hence twice, and just do its
> usual work, with your proposal, we still rely on having to recurse in
> subdirectories which requires more boilerplate code.
And of _course_ this is also true for git-log, which is like 10x as
important for me (like I don't remember if I used git-blame this year,
whereas I used git-log in the last 10 minutes ;p)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 20:55 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Git ML
In-Reply-To: <320075ff0807281323l51bb6478j30e3e4c490974a70@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4157 bytes --]
On Mon, Jul 28, 2008 at 08:23:39PM +0000, Nigel Magnay wrote:
> >
> > While trying to sum up some things I'd like submodules to do, and things
> > like that, I came to ask myself why the heck we were doing things the
> > way we currently do wrt submodules.
> >
> > This question is related to the `.git` directories of submodules. I
> > wonder why we didn't chose to use a new reference namespace
> > (refs/submodules/$path/$remote/$branch).
> >
> I'm maybe being a bit slow - what would be the contents of (say)
> refs/submodules/moduleA/remotes/origin/master ? The ref
> that's currently in moduleA/.git/refs/remotes/origin/master ?
Yes.
> > It also has the absolutely nice property to share objects, so that
> > projects that replaced a subdirectory with a submodule don't see their
> > checkouts grow too large.
> >
>
> Ah.. are you meaning that the top-level repository contains all the
> commits in all the submodules?
Yes. My suggestion is to share all the references, prefixing the
submodules ones with a distinct prefix (namely
refs/submodules/$name-of-the-submodule) to avoid any conflict, and share
the object store. You get coherent reflogs and stuff like that for free
on top.
> I was thinking a bit about submodules (because of the earlier
> discussions about submodule update only pulling from origin, and the
> associated difficulties) and started wondering if the best place for
> the git repository for (say) submoduleA was really
> <...>/submoduleA/.git/<> and not (say) something like
> ..git/submodules/submoduleA/<>. This would be nicer for people trying
> to pull revisions from you because they could easily find submodule
> repositories regardless or not of whether they currently exist in your
> WC.
That too indeed (the "easier to clone" bit). OTOH, I don't like the
.git/submodules idea a lot, if you mean to put a usual $GIT_DIR layout
inside of it. With what I propose, you find objects for all your
super/sub-modules in the usual store, which eases many things.
Especially, I believe that when you replace a subdirectory of a project
with a submodule, git-blame could benefit quite a lot from this to be
able to glue history back through the submodule limits, without having
to refactor a _lot_ of code: it would merely have to dereference so
called "gitlinks" to the commit then tree, hence twice, and just do its
usual work, with your proposal, we still rely on having to recurse in
subdirectories which requires more boilerplate code.
> I got as far as looking at discussions around .gitlink but ran out of
> avaiable time.
I shall say I never followed them, as I was uninterested with such
subjects before, (but now is as I use them at work). But I don't recall
such an idea to have been discussed at all, so...
> > Having that, one can probably extend most of the porcelains in _very_
> > straightforward ways. For example, a local topic branch `topic` would be
> > the union of the supermodule `topic` branch, and all the
> > `refs/submodules/$names/topic` ones.
> >
> > Most importantly, it would help implementing that tries to make your
> > submodules stay _on branch_. One irritating problem with submodules, is
> > that when someone else commited, and that you git submodule update,
> > you're on a detached head. Absolutely horrible. If you see your current
> > branch (assume it's master), then when you do that, you would update
> > your `refs/submodules/$name/master` references instead and keep the
> > submodule HEADs `on branch`. Of course we can _probably_ hack something
> > together along those lines with the current setup, but it would be _so_
> > much more convenient this way...
> >
>
> For me, if I'm on heads/blah in the superproject, I probably want to
> be on heads/blah in *all* submodules. But that's maybe just me.
Yes, that's what I tried to say, so if it wasn't clear, it's exactly
what I would like to do/have.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [Fundamental problem with relative system paths] [PATCH 2/2] run-command (Windows): Run dashless "git <cmd>"
From: Johannes Sixt @ 2008-07-28 20:37 UTC (permalink / raw)
To: Steffen Prohaska
Cc: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <1217224228-31303-2-git-send-email-prohaska@zib.de>
Zitat von Steffen Prohaska <prohaska@zib.de>:
> This might solve a fundamental problem we have with the
> computation of system directories based on relative paths
> in combination with the new gitexecpath 'libexec/git-core'.
> The problem is that the program 'git' is hardlinked to
> directories with different depth. It is either used as
> 'bin/git' (1 directory) or as 'libexec/git-core/git-*'
> (2 directories). Thus, using the same relative path
> in system_path() yields different results when starting from the
> two locations. I recognized the problem because /etc/gitconfig
> is no longer be read.
>
> The patch below might fix the problem by always calling 'bin/git'
> for builtin commands. The computation in system_path() would
> always start from 'bin' and thus yields predictable results. I
> am not sure however if it fully solves the problem because other
> code paths might run the dashed forms directly.
This paragraph should go into the commit message.
> I think the only way to verify correctness would be to stop
> installing the dashed forms for builtins. If they were not
> installed they could not be called. The only entry point for all
> builtins would be 'bin/git'. I don't think we want to stop
> installing the dashed forms right away.
>
> So what shall we do?
Your patches make a lot of sense.
> -- 8< --
> We prefer running the dashless form, so we should use it in
> MinGW's start_command(), too.
>
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
-- Hannes
^ permalink raw reply
* Re: gitk crashes when quitting gitk while it is is reading commits (was Re: gitk crashing on Windows.)
From: Eric Raible @ 2008-07-28 20:31 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, paulus
In-Reply-To: <E7C7B8BA-6050-40DE-917C-200EAE9CA6E8@zib.de>
On Mon, Jul 28, 2008 at 12:18 PM, Steffen Prohaska <prohaska@zib.de> wrote:
> I don't think so. The error Jurko reported might be the same error
> that was reported earlier and filed as issue 125:
>
> http://code.google.com/p/msysgit/issues/detail?id=125
I agree - sounds the same.
> I don't think the problem is Windows-specific. At least on Mac I am
> seeing similar problems. When I hit CTRL-q while gitk is still reading
> the commits, it crashes with as segfault.
>
> Steffen
I also agree that it easily could be a generic problem.
But the fact remains that it used to reliably crash on me,
and no longer does with more recent source.
But I still can't find a relevant commit, which makes me
feel like I'm a) still a complete git newbie, or b) imagining
the whole thing.
- Eric
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 20:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vljzlrca9.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 22:20, Junio C Hamano <gitster@pobox.com> wrote:
> "Sverre Rabbelier" <alturin@gmail.com> writes:
>> Mhhh, but the proposed strategy there was in response to the 'insane'
>> git-merge-theirs version, not to the 'exact opposite of
>> git-merge-ours' that I refer to now, yes?
>
> No.
Nanako Shiraishi's patch was not in response to the "git-merge-theirs"
thread, or I am missing something here....?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git submodules
From: Nigel Magnay @ 2008-07-28 20:23 UTC (permalink / raw)
To: Pierre Habouzit, Git ML
In-Reply-To: <20080728162003.GA4584@artemis.madism.org>
>
> While trying to sum up some things I'd like submodules to do, and things
> like that, I came to ask myself why the heck we were doing things the
> way we currently do wrt submodules.
>
> This question is related to the `.git` directories of submodules. I
> wonder why we didn't chose to use a new reference namespace
> (refs/submodules/$path/$remote/$branch).
>
I'm maybe being a bit slow - what would be the contents of (say)
refs/submodules/moduleA/remotes/origin/master ? The ref
that's currently in moduleA/.git/refs/remotes/origin/master ?
> This would have the net benefit that most of the plumbing tasks would be
> easier if they have to deal with submodules, because they aren't in this
> uncomfortable situation where they have to recurse into another git
> directory to know what to do.
>
> It also has the absolutely nice property to share objects, so that
> projects that replaced a subdirectory with a submodule don't see their
> checkouts grow too large.
>
Ah.. are you meaning that the top-level repository contains all the
commits in all the submodules?
> We probably still want submodules to act like plain independant git
> repositories, but one can still *fake* that this way: submodules have
> only a .git/config file (also probably an index and a couple of things
> like that, but that's almost a different issue for what I'm considering
> now) that has the setting:
>
> [core]
> submodule = true
>
> This could make all the builtins look for the real $GIT_DIR up, which in
> turn gives the submodule "name". Then, for this submodule, every
> reference, remote name, ... would be virtualized using the
> "remote/$submodule_name" prefix. IOW, in a submodule "some/sub/module"
> the branch "origin/my/topic/branch" is under:
> refs/submodules/some/sub/module/origin/my/topic/branch
> <-- submod. --><-- submod. --><-- --><-- branch -->
> namespace path/name remote
> Note that this doesn't mean that we must rip out .gitmodules, because
> it's needed to help splitting the previous reference name properly, and
> for bootstrapping purposes.
>
I was thinking a bit about submodules (because of the earlier
discussions about submodule update only pulling from origin, and the
associated difficulties) and started wondering if the best place for
the git repository for (say) submoduleA was really
<...>/submoduleA/.git/<> and not (say) something like
.git/submodules/submoduleA/<>. This would be nicer for people trying
to pull revisions from you because they could easily find submodule
repositories regardless or not of whether they currently exist in your
WC.
I got as far as looking at discussions around .gitlink but ran out of
avaiable time.
>
> Having that, one can probably extend most of the porcelains in _very_
> straightforward ways. For example, a local topic branch `topic` would be
> the union of the supermodule `topic` branch, and all the
> `refs/submodules/$names/topic` ones.
>
> Most importantly, it would help implementing that tries to make your
> submodules stay _on branch_. One irritating problem with submodules, is
> that when someone else commited, and that you git submodule update,
> you're on a detached head. Absolutely horrible. If you see your current
> branch (assume it's master), then when you do that, you would update
> your `refs/submodules/$name/master` references instead and keep the
> submodule HEADs `on branch`. Of course we can _probably_ hack something
> together along those lines with the current setup, but it would be _so_
> much more convenient this way...
>
For me, if I'm on heads/blah in the superproject, I probably want to
be on heads/blah in *all* submodules. But that's maybe just me.
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-28 20:20 UTC (permalink / raw)
To: sverre
Cc: Junio C Hamano, Johannes Schindelin, Jeff King, Git Mailinglist,
Miklos Vajna
In-Reply-To: <bd6139dc0807281310j16b4ef5alf9738ec0f3270ba0@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Mon, Jul 28, 2008 at 22:07, Junio C Hamano <gitster@pobox.com> wrote:
>> That reminds me of:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/89178
>>
>> to one of whose messages I sent a response today.
>
> Mhhh, but the proposed strategy there was in response to the 'insane'
> git-merge-theirs version, not to the 'exact opposite of
> git-merge-ours' that I refer to now, yes?
No.
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 20:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Jeff King, Git Mailinglist, Miklos Vajna
In-Reply-To: <7vproxrcvu.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 28, 2008 at 22:07, Junio C Hamano <gitster@pobox.com> wrote:
> That reminds me of:
>
> http://thread.gmane.org/gmane.comp.version-control.git/89178
>
> to one of whose messages I sent a response today.
Mhhh, but the proposed strategy there was in response to the 'insane'
git-merge-theirs version, not to the 'exact opposite of
git-merge-ours' that I refer to now, yes? Do you have any particular
feelings wrt to that?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-28 20:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807282008470.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Well, I have to say that the workflow is a bit backwards if the person who
> _publishes_ the thing is the one saying "Ooops, my version no goodie,
> other version please, but so that pull still works".
>
> I would have expected the one who has the good version to make the choice.
That reminds me of:
http://thread.gmane.org/gmane.comp.version-control.git/89178
to one of whose messages I sent a response today.
^ permalink raw reply
* Re: [PATCH] Allow installing in the traditional way
From: Johannes Sixt @ 2008-07-28 20:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod4itrgg.fsf@gitster.siamese.dyndns.org>
Zitat von Junio C Hamano <gitster@pobox.com>:
> In an earlier commit c70a8d9 (Makefile: Do not install a copy of 'git' in
> $(gitexecdir), 2008-07-21), we tried to avoid installing two git, one in
> /usr/bin/git and the other in /usr/libexec/git-core/git. It mistakenly
> removed the only copy of git when gitexecdir and bindir are set to the
> same directory, i.e. the traditional layout.
The patch looks fine. Thanks for fixing up my mistakes.
-- Hannes
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Avery Pennarun @ 2008-07-28 20:00 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080728192651.GA26677@sigill.intra.peff.net>
On 7/28/08, Jeff King <peff@peff.net> wrote:
> My situation was two long-running branches, "stable" and "devel",
> both of which were worked on by many developers. One person was in
> charge of integration and branch management. They wanted "stable" to
> get the contents of "devel" (which were now ready for release), ignoring
> any small fixes that had been done on "stable" (since they had all been
> moved over to "devel" previously, but in subtly different ways that
> would create conflicts). And "git reset" was not an option, because they
> wanted to keep the history of "stable" in case those fixes needed to be
> looked at later.
>
> So the logical sequence was:
>
> git checkout production
> git merge -s theirs master
I have to say, this somehow feels wrong to me. What you're saying is
essentially that "stable has already been merged into devel" followed
by "and now we want to catch stable up to devel."
It really is two separate thoughts, and merging devel directly into
stable - literally by *undoing* all the changes from stable - doesn't
sound like it should be considered a safe operation.
Personally, I've started enjoying the "--no-ff" option to git-merge.
That way I can do
git checkout master
git merge production
git checkout production
git merge --no-ff master
The latter merge isn't really a "merge" since it could have been just
fast forwarded. But it avoids the aesthetic problems of commits like
"merge production into master" showing up in the master branch. It
also means that "git reset --hard HEAD^" works whether or not a
fastforward would have been theoretically possible.
Of course, this whole discussion is really just about how to make your
log look cleaner, and we could debate forever about that. It may make
sense to simply provide "theirs" as an exact mirror of "ours" if only
in the name of symmetry.
Have fun,
Avery
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 19:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807282008470.8986@racer>
On Mon, Jul 28, 2008 at 21:09, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Well, I have to say that the workflow is a bit backwards if the person who
> _publishes_ the thing is the one saying "Ooops, my version no goodie,
> other version please, but so that pull still works".
Why so? In this case the other branch was also owned by the publishing
person. I don't quite follow how this is any stranger than ours?
(Which is stranger to me, why would you want to merge in a branch if
you're not going to do anything with it anyway? I'm sure there are
valid workflows for it, which is why we have it, just saying that I
think 'theirs' makes more sense to me than 'ours')
> I would have expected the one who has the good version to make the choice.
Why have the person with the good version merge with... a bad version?
Isn't it usually "I will merge with you, because I know your branch
makes things go twice as fast" (paraphrasing Linus from his git talk
at google).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Sverre Rabbelier @ 2008-07-28 19:48 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Git Mailinglist, Johannes Schindelin
In-Reply-To: <20080728181424.GM32057@genesis.frugalware.org>
On Mon, Jul 28, 2008 at 20:14, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>> So, in short: what does the list think about adding
>> "git-merge-theirs", that does (although possibly less 'hackish'):
>>
>> cat > git-merge-theirs << EOF
>> #!/bin/sh
>> eval git read-tree --reset -u \\\$\$#
>> EOF
>
> Isn't this the stupid one?
No, the stupid one did "take all non-conflicting hunks from our side,
and any for conflicting hunks, take theirs", which was rather silly I
must say, although I have heard one use-cases where it makes sense (no
I don't think we should have a git-merge-theirs-on-conflict).
> It's perfect for my testing needs, but this is not something that people
> should ever use on a real repo.
What about the use-case I described in my first mail?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-28 19:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807282008470.8986@racer>
On Mon, Jul 28, 2008 at 08:09:55PM +0100, Johannes Schindelin wrote:
> Well, I have to say that the workflow is a bit backwards if the person who
> _publishes_ the thing is the one saying "Ooops, my version no goodie,
> other version please, but so that pull still works".
>
> I would have expected the one who has the good version to make the choice.
My situation was two long-running branches, "stable" and "devel",
both of which were worked on by many developers. One person was in
charge of integration and branch management. They wanted "stable" to
get the contents of "devel" (which were now ready for release), ignoring
any small fixes that had been done on "stable" (since they had all been
moved over to "devel" previously, but in subtly different ways that
would create conflicts). And "git reset" was not an option, because they
wanted to keep the history of "stable" in case those fixes needed to be
looked at later.
So the logical sequence was:
git checkout production
git merge -s theirs master
-Peff
^ permalink raw reply
* Re: GTP/0.1 terminology 101: commit reels and references
From: Sam Vilain @ 2008-07-28 19:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <alpine.DEB.1.00.0807281350590.2725@eeepc-johanness>
On Mon, 2008-07-28 at 14:01 +0200, Johannes Schindelin wrote:
> > - the reel has a defined object order (which as I hoped to demonstrate
> > in the test cases, is just a refinement of rev-list --date-order)
>
> Do you mean that the commit reel is a list pointing to bundles that can be
> sorted topologically by their contained commits?
Yes, but it is more defined than that. There are still ambiguities with
topological sort, so the gittorrent spec specified exactly how all ties
are broken. They happen to be a further refinement of --date-order,
with respect to the ordering of commits.
> > - deltas always point in one direction, to objects "earlier" on
> > the reel, so that slices of the reel sent on the network can be made
> > thin without resulting in unresolvable deltas (which should be
> > possible to do on commit boundaries using rev-list --objects-edge)
> That is exactly what bundles do. They are thin, as they assume that a few
> "preconditions", i.e. refs, are present.
Ok. I think there are also some other trivial differences such as
bundles containing refs (which in the context of gittorrent will be
useless).
> > - the behaviour at the beginning of the reel is precisely defined
> > (although as I said, I think that the decision might be worth
> > revisiting - perhaps getting just the latest reel is a useful
> > 'shallow clone')
>
> If you want to allow shallow clones, you must make the bundles non-thin.
> That would be a major bandwidth penalty.
>
> I'd rather not allow shallow clones with Gitorrent.
By "Shallow" I think I mean a different thing to you. I mean something
akin to just the last pack's worth of commits.
> > It's the lack of guarantees which is the issue, really.
>
> It should not be too difficult to provide a rev-list option (which is
> inherited by git-bundle, then) to pay an extra time to make sure that the
> bundle is minimal.
Ok. But from the current implementation's perspective, this is not yet
needed, we are just using the existing API.
Actually what would be useful would be for the thin pack generation to
also allow any object to be specified as its input list, not just
commits... then we wouldn't have to break blocks on commit boundaries
(see http://gittorrent.utsl.gen.nz/rfc.html#org-blocks).
> > In order to take the download work of the entire pack and distribute it
> > over multiple peers, you need a way to carve the bundle up. This has to
> > happen in such a way that the fragments that you get back will actually
> > fit together at the end, and also in such a way that you don't lose the
> > benefits of delta compression.
>
> That should be relatively easy.
>
> > The way I thought would be best to do that would be to line up all the
> > objects in an exactly defined way - hence, the "reel" concept - and then
> > chop that up.
>
> What exactly is that exact definition?
http://gittorrent.utsl.gen.nz/rfc.html#org-reels
> Is it the output of "rev-list --all --objects", chopped into equal chunks
> at commit boundaries? If so, it should probably be equal in terms of
> size, right?
No. It's chopped by uncompressed size.
http://gittorrent.utsl.gen.nz/rfc.html#org-blocks
> The tricky thing, of course, is to make that thing incremental, i.e.
> replace only a minimal amount of items in the "commit reel" (if I
> understood correctly, and the commit reel refers to a list of sets of
> commits with their objects) when a branch was modified.
You would make a new reel to cover a new bunch of updates. It's
important that the reels don't change too often for reasons I describe
in the RFC.
> Hmm. Maybe it would be time for you to draw a tiny diagram for all the
> people too lazy like me, which shows roughly how the communication between
> the peers should look like, and how the reel fits in.
As I said in my recent message to the list, I wrote another top level
overview here:
http://gittorrent.utsl.gen.nz/rfc.html#org-blocks
Cheers,
Sam.
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Junio C Hamano @ 2008-07-28 19:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: SZEDER Gábor, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807281605330.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 28 Jul 2008, SZEDER Gábor wrote:
>
>> there is a race somewhere in these 'git-mv: Keep moved index entries
>> inact' changes.
>>
>> The test cases 'git mv should overwrite symlink to a file' or 'git mv
>> should overwrite file with a symlink' fail occasionaly. It's quite
>> non-deterministic: I have run t7001-mv.sh in a loop (see below) and
>> one or the other usually fails around 50 runs (but sometimes only
>> after 150). Adding some tracing echos to the tests shows that both
>> tests fail when running 'git diff-files' at the end.
>
> To make it more convenient to test: with this patch it fails all the time:
It's because we rename(2) but do not read back ctime, and reuse the cached
data from the old path that was renamed. After the failed test that moves
a regular file "move" to "symlink":
$ stat symlink
File: `symlink'
Size: 2 Blocks: 8 IO Block: 4096 regular file
Device: 30ah/778d Inode: 18104337 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1012/ junio) Gid: ( 40/ src)
Access: 2008-07-28 11:49:55.000000000 -0700
Modify: 2008-07-28 11:48:41.000000000 -0700
Change: 2008-07-28 11:48:42.000000000 -0700
But the cached stat information looks like this:
$ ../../git-ls-files --stat
ctime=1217270921, mtime=1217270921, ino=18104337, mode=100644, uid=1012, gid=40symlink
We need to refresh the entry to pick up potential ctime changes.
read-cache.c | 7 ++++++-
builtin-ls-files.c | 21 +++++++++++++++------
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 1cae361..834096f 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -40,7 +40,7 @@ static void replace_index_entry(struct index_state *istate, int nr, struct cache
void rename_index_entry_at(struct index_state *istate, int nr, const char *new_name)
{
- struct cache_entry *old = istate->cache[nr], *new;
+ struct cache_entry *old = istate->cache[nr], *new, *refreshed;
int namelen = strlen(new_name);
new = xmalloc(cache_entry_size(namelen));
@@ -51,6 +51,11 @@ void rename_index_entry_at(struct index_state *istate, int nr, const char *new_n
cache_tree_invalidate_path(istate->cache_tree, old->name);
remove_index_entry_at(istate, nr);
+
+ /* the renaming could have smudged the ctime */
+ refreshed = refresh_cache_entry(new, 0);
+ if (refreshed && refreshed != new)
+ new = refreshed;
add_index_entry(istate, new, ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
}
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index e8d568e..a6b30c8 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -16,6 +16,7 @@ static int show_deleted;
static int show_cached;
static int show_others;
static int show_stage;
+static int show_stat;
static int show_unmerged;
static int show_modified;
static int show_killed;
@@ -205,16 +206,20 @@ static void show_ce_entry(const char *tag, struct cache_entry *ce)
tag = alttag;
}
- if (!show_stage) {
- fputs(tag, stdout);
- } else {
+ if (show_stage)
printf("%s%06o %s %d\t",
tag,
ce->ce_mode,
abbrev ? find_unique_abbrev(ce->sha1,abbrev)
: sha1_to_hex(ce->sha1),
ce_stage(ce));
- }
+ else if (show_stat)
+ printf("ctime=%u, mtime=%u, ino=%u, mode=%o, uid=%u, gid=%u\t",
+ ce->ce_ctime, ce->ce_mtime, ce->ce_ino,
+ ce->ce_mode, ce->ce_uid, ce->ce_gid);
+
+ else
+ fputs(tag, stdout);
write_name_quoted(ce->name + offset, stdout, line_terminator);
}
@@ -235,7 +240,7 @@ static void show_files(struct dir_struct *dir, const char *prefix)
if (show_killed)
show_killed_files(dir);
}
- if (show_cached | show_stage) {
+ if (show_cached | show_stage | show_stat) {
for (i = 0; i < active_nr; i++) {
struct cache_entry *ce = active_cache[i];
int dtype = ce_to_dtype(ce);
@@ -488,6 +493,10 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
show_stage = 1;
continue;
}
+ if (!strcmp(arg, "-S") || !strcmp(arg, "--stat")) {
+ show_stat = 1;
+ continue;
+ }
if (!strcmp(arg, "-k") || !strcmp(arg, "--killed")) {
show_killed = 1;
require_work_tree = 1;
@@ -593,7 +602,7 @@ int cmd_ls_files(int argc, const char **argv, const char *prefix)
/* With no flags, we default to showing the cached files */
if (!(show_stage | show_deleted | show_others | show_unmerged |
- show_killed | show_modified))
+ show_killed | show_modified | show_stat))
show_cached = 1;
read_cache();
^ permalink raw reply related
* gitk crashes when quitting gitk while it is is reading commits (was Re: gitk crashing on Windows.)
From: Steffen Prohaska @ 2008-07-28 19:18 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20080728T162025-946@post.gmane.org>
On Jul 28, 2008, at 6:29 PM, Eric Raible wrote:
> Jurko Gospodnetić <jurko.gospodnetic <at> docte.hr> writes:
>
>> When you run gitk from a git repository on Windows it starts up and
>> starts updating its 'Row X/Y' output labels. This lasts for a few
>> seconds but if you terminate the application before this updating is
>> complete you get a Windows message stating:
>>
>> 'Wish Application has encountered a problem and needs to close. We
>> are sorry for the inconvenience.'
>>
>> and the standard 'Send Error Report'/'Don't Send' buttons.
>>
>> Hope this helps.
>>
>> Best regards,
>> Jurko Gospodnetić
>
> Though I can't find the relevant commit at the moment
> I believe that this is one already fixed in the latest
> from git://repo.or.cz/git/mingw/4msysgit.git.
I don't think so. The error Jurko reported might be the same error
that was reported earlier and filed as issue 125:
http://code.google.com/p/msysgit/issues/detail?id=125
I don't think the problem is Windows-specific. At least on Mac I am
seeing similar problems. When I hit CTRL-q while gitk is still reading
the commits, it crashes with as segfault.
Steffen
^ permalink raw reply
* Re: short log and email address
From: Johannes Schindelin @ 2008-07-28 19:11 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807281157u44c08a59ld3bdc0416e8a1d03@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Jon Smirl wrote:
> On 7/28/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Mon, 28 Jul 2008, Jon Smirl wrote:
> >
> > > Using the -e option in shortlog changes the results by spitting
> > > things out by email address instead of leaving them combined by
> > > name. That's probably not what you want. Instead you want
> > > everything combined by name and then display the most recent email
> > > address used.
> >
> > What is so wrong with _not_ using -e (since you do not want to see the
> > email address stored in the commit message, and -e would be asking for
> > that _exactly_)?
>
> I wanted -e to give me the most recent email so that I would know how
> to sort the mailmap alias list.
As I explained, that is not what -e is _supposed_ to do. In Git, content
is king, and as such -e should look at the content. Unsurprisingly, that
is exactly what it does.
Nothing prohibits you from post-processing the output, though.
Ciao,
Dscho
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Johannes Schindelin @ 2008-07-28 19:09 UTC (permalink / raw)
To: Jeff King; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080728185604.GA26322@sigill.intra.peff.net>
Hi,
On Mon, 28 Jul 2008, Jeff King wrote:
> On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier wrote:
>
> > Thus resulting in a 'wrong way around' merge as part of master? It
> > would say "Merge branch 'master' into otherbranch", while what
> > happened was "Merge branch 'otherbranch' into master".
> >
> > So, in short: what does the list think about adding
> > "git-merge-theirs", that does (although possibly less 'hackish'):
> >
> > cat > git-merge-theirs << EOF
> > #!/bin/sh
> > eval git read-tree --reset -u \\\$\$#
> > EOF
>
> I ran into this exact situation while showing somebody how awesome git
> was, and it was a little embarrasing to say "oops, now we have to do
> this backwards."
Well, I have to say that the workflow is a bit backwards if the person who
_publishes_ the thing is the one saying "Ooops, my version no goodie,
other version please, but so that pull still works".
I would have expected the one who has the good version to make the choice.
Ciao,
Dscho
^ permalink raw reply
* Re: short log and email address
From: Jon Smirl @ 2008-07-28 18:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807281928400.8986@racer>
On 7/28/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Mon, 28 Jul 2008, Jon Smirl wrote:
>
> > Using the -e option in shortlog changes the results by spitting things
> > out by email address instead of leaving them combined by name. That's
> > probably not what you want. Instead you want everything combined by name
> > and then display the most recent email address used.
>
>
> What is so wrong with _not_ using -e (since you do not want to see the
> email address stored in the commit message, and -e would be asking for
> that _exactly_)?
I wanted -e to give me the most recent email so that I would know how
to sort the mailmap alias list.
>
> After the fact, you can annotate the names with all you like. For
> example, the most recent email address for that person.
>
> But as Mark pointed out, the name might be a bad key. Maybe you will have
> to do something completely different, namely maintain a separate list of
> (correct) names and emails, and then having line numbers in .mailmap,
> like:
>
> 1 <davem@sunset>
> 1 <davem@sunrise>
> 1 <davem@moonshine>
> 2 <dave.miller@miller.com>
> 2 <dave.miller@highnoon.miller.com>
>
> etc
>
> However, I have to say that I see small value in that, and an inordinate
> amount of work that nobody wants to do.
We could order the aliases until the correct alias is the last one. An
initial proxy would be to use the most recent email address on the
person's commits.
The trick is automating the maintenance. Modify checkpatch,pl to look
up the person's name up in the mailmap file and retrieve all matching
aliases.
If the name isn't in mailmap, tell them to make a patch adding their
name or to change their name.
If the name is there but the email is not the last one in the list,
tell them to make a patch rearranging mailmap to reflect their current
name/email.
If name is there and email is last on list, don't complain.
>
> Ciao,
> Dscho
>
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-28 18:56 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist, Miklos Vajna, Johannes Schindelin
In-Reply-To: <bd6139dc0807280754x76b6ffedg6bf756dfce23f1e3@mail.gmail.com>
On Mon, Jul 28, 2008 at 04:54:17PM +0200, Sverre Rabbelier wrote:
> Thus resulting in a 'wrong way around' merge as part of master? It
> would say "Merge branch 'master' into otherbranch", while what
> happened was "Merge branch 'otherbranch' into master".
>
> So, in short: what does the list think about adding
> "git-merge-theirs", that does (although possibly less 'hackish'):
>
> cat > git-merge-theirs << EOF
> #!/bin/sh
> eval git read-tree --reset -u \\\$\$#
> EOF
I ran into this exact situation while showing somebody how awesome git
was, and it was a little embarrasing to say "oops, now we have to do
this backwards."
So I think it would be nice for completeness, although I admit that my
situation was rare (but no rarer, perhaps, than "-s ours").
-Peff
PS You may find your shell snippet a bit more readable by quoting 'EOF'.
^ permalink raw reply
* Re: short log and email address
From: Johannes Schindelin @ 2008-07-28 18:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807281106y56f8b67ao86f78822c4b4ad58@mail.gmail.com>
Hi,
On Mon, 28 Jul 2008, Jon Smirl wrote:
> Using the -e option in shortlog changes the results by spitting things
> out by email address instead of leaving them combined by name. That's
> probably not what you want. Instead you want everything combined by name
> and then display the most recent email address used.
What is so wrong with _not_ using -e (since you do not want to see the
email address stored in the commit message, and -e would be asking for
that _exactly_)?
After the fact, you can annotate the names with all you like. For
example, the most recent email address for that person.
But as Mark pointed out, the name might be a bad key. Maybe you will have
to do something completely different, namely maintain a separate list of
(correct) names and emails, and then having line numbers in .mailmap,
like:
1 <davem@sunset>
1 <davem@sunrise>
1 <davem@moonshine>
2 <dave.miller@miller.com>
2 <dave.miller@highnoon.miller.com>
etc
However, I have to say that I see small value in that, and an inordinate
amount of work that nobody wants to do.
Ciao,
Dscho
^ permalink raw reply
* Re: short log and email address
From: Jon Smirl @ 2008-07-28 18:25 UTC (permalink / raw)
To: Mark Brown; +Cc: Git Mailing List
In-Reply-To: <20080728181101.GA9148@sirena.org.uk>
On 7/28/08, Mark Brown <broonie@sirena.org.uk> wrote:
> On Mon, Jul 28, 2008 at 02:06:06PM -0400, Jon Smirl wrote:
> > Using the -e option in shortlog changes the results by spitting things
> > out by email address instead of leaving them combined by name. That's
> > probably not what you want. Instead you want everything combined by
> > name and then display the most recent email address used.
>
> Apart from anything else you're assuming that people's names are
> globally unique - they aren't. I'm aware of several Mark Browns active
> in the free software world, for example.
There is a conflicting problem, multiple people with the same name and
people using multiple email addresses. The only solution I can see is
for the Mark Brown developers to get together and come up with a way
to differentiate their signatures (initial, nickname, etc), otherwise
I can't tell them apart from someone using multiple email addresses.
Mark Brown <broonie@opensource.wolfsonmicro.com>
Mark Brown <broonie@sirena.org.uk>
Same or two different people? These two names have committed to the kernel.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-28 18:24 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807281610270.8986@racer>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2110 bytes --]
Hi,
On Mon, 28 Jul 2008, Johannes Schindelin wrote:
> On Mon, 28 Jul 2008, Johannes Schindelin wrote:
>
> > On Mon, 28 Jul 2008, SZEDER Gábor wrote:
> >
> > > there is a race somewhere in these 'git-mv: Keep moved index entries
> > > inact' changes.
> > >
> > > The test cases 'git mv should overwrite symlink to a file' or 'git
> > > mv should overwrite file with a symlink' fail occasionaly. It's
> > > quite non-deterministic: I have run t7001-mv.sh in a loop (see
> > > below) and one or the other usually fails around 50 runs (but
> > > sometimes only after 150). Adding some tracing echos to the tests
> > > shows that both tests fail when running 'git diff-files' at the end.
> >
> > To make it more convenient to test: with this patch it fails all the
> > time:
>
> Ooops. Seems like I changed the test 23 to fail, instead of test 24.
> However, I think it is the same bug: the index is newer by one second,
> so it seems that the patch for builtin-mv.c did not really keep the data
> "intact".
>
> Note that a test case should use test-chmtime to force this scenario,
> not sleep a second.
>
> Unfortunately, I already spent my Git time budget for today, so the ball
> is out of my half for now.
Hah! I had a few minutes, and this is my analysis:
Just try to "mv" a file, and look at the _ctime_ before and after. Yes,
that is right, at least on my system (ext3) it _changes_.
So the test 23 and 24 in t7001-mv.sh are totally bogus. They purport to
test that git-mv retains the whole meta-information in the cache and
therefore the index does not need to be updated.
However, it _does_ need to be updated, exactly because ctime changed.
Only that the test failed to test what it tried to test, instead
succeeding erroneously, just because the index was racy most of the time
and got silently updated.
So, this is the analysis. The fixes will have to be done by somebody
else, because /me goes running now.
(Possible fixes I envisage: update ctime via stat() after rename(), or
just give up and scrap the whole "leave cache_entry inact" thing.)
Ciao,
Dscho
^ 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