* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-29 11:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807282023290.3334@nehalem.linux-foundation.org>
Hi,
On Mon, 28 Jul 2008, Linus Torvalds wrote:
> You dismiss all my issues, and then you continue to talk about "correct",
> even though it isn't a correctness thing - it's a difference of opinion.
> Me, I *much* prefer the simplified history. That _is_ the correct one for
> me.
I'm not dismissing it, but your focus is on how to get this result. If the
results were always the same, I wouldn't have a problem at all.
That's why I'm trying to give you an example where the end result differs,
how are we supposed to get to an agreement on _how_ to get the result, if
we don't even agree on _what_ the result should be?
> And quite frankly, I've seen that behaviour from you before, when it comes
> to other things.
What exact behaviour is that? That I dare to disagree with you?
> So go away. Write the code. Come back with patches.
If you knew me that well, you also knew that such threats don't work with
me.
In this case you know perfectly well, that I don't know the code as well
as you, so without any help it would require a huge waste of time with the
risk of rejection.
bye, Roman
^ permalink raw reply
* Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Steffen Prohaska @ 2008-07-29 11:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Shawn O. Pearce, Johannes Sixt, git
In-Reply-To: <alpine.DEB.1.00.0807291310390.4631@eeepc-johanness>
On Jul 29, 2008, at 1:13 PM, Johannes Schindelin wrote:
> On Tue, 29 Jul 2008, Steffen Prohaska wrote:
>
>> On Jul 29, 2008, at 7:42 AM, Junio C Hamano wrote:
>>
>>> We prefer running the dashless form, and POSIX side already does
>>> so;
>>> we should use it in MinGW's start_command(), too.
>>
>> Thanks for reading my mind ;-) This was the alternative
>> justification I
>> had in mind after reading my patch again.
>
> Well, given that the justification you gave had the obvious flaw --
> which
> you even pointed out -- that non-builtins are _still_ affected, i.e.
> that
> you leave that bug unfixed (but your description purports that you
> want to
> fix that bug), it would have been wiser to give the alternative
> justification, which makes the commit obviously correct.
We still need to fix the problem with system_path(), because currently
we cannot release Git-1.6.0 on Windows. That is why I pointed out the
real problem we are facing. The (good) side-effect is that the
MSYS-codepath is now prepared for 1.7.
Steffen
^ permalink raw reply
* Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Johannes Schindelin @ 2008-07-29 11:18 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Shawn O. Pearce, Johannes Sixt, Git Mailing List, Junio C Hamano
In-Reply-To: <10AD8BDA-72E8-437D-8CFC-CDD71BB016F8@zib.de>
Hi,
On Tue, 29 Jul 2008, Steffen Prohaska wrote:
> On Jul 29, 2008, at 7:24 AM, Shawn O. Pearce wrote:
>
> > Steffen Prohaska <prohaska@zib.de> wrote:
> > > We prefer running the dashless form, so we should use it in MinGW's
> > > start_command(), too.
> > ...
> > > - We have non-builtins that are implemented in C, e.g. fast-import.c.
> > > These non-builtins will still compute wrong paths.
> >
> > This feels wrong to me. fast-import probably won't be adversly
> > impacted by not being able to read /etc/gitconfig, unless the user has
> > set something like core.deltaBaseCacheLimit and is doing an
> > incremental import. But other non-builtins may be impacted.
> >
> > It feels like we're fixing this in the wrong place. If the issue is
> > we don't find our installation directory correctly, we should find our
> > installation directory correctly, not work around it by calling
> > builtins through the git wrapper.
>
> For builtins it is not a work around but a real solution.
No, it is not a real solution. At least not for the goal you stated:
getting the correct "toplevel" directory. It is a workaround, because it
avoids the builtins being called as proper programs (which they should be
perfectly capable of, and which scripts still _are allowed to do_).
However, it is a solution. To a totally other problem, namely "I would
like to be able _not_ to install the builtins into the exec-path". Sure,
you break a few scripts that rely on the builtins being callable in the
dash-form, but at least the scripts we ship in git.git are safe.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Johannes Schindelin @ 2008-07-29 11:13 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, Shawn O. Pearce, Johannes Sixt, git
In-Reply-To: <42EF8777-BABC-4757-AD49-627320F24D39@zib.de>
Hi,
On Tue, 29 Jul 2008, Steffen Prohaska wrote:
> On Jul 29, 2008, at 7:42 AM, Junio C Hamano wrote:
>
> > We prefer running the dashless form, and POSIX side already does so;
> > we should use it in MinGW's start_command(), too.
>
> Thanks for reading my mind ;-) This was the alternative justification I
> had in mind after reading my patch again.
Well, given that the justification you gave had the obvious flaw -- which
you even pointed out -- that non-builtins are _still_ affected, i.e. that
you leave that bug unfixed (but your description purports that you want to
fix that bug), it would have been wiser to give the alternative
justification, which makes the commit obviously correct.
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-29 11:05 UTC (permalink / raw)
To: Jeff King; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080729043839.GC26997@sigill.intra.peff.net>
Hi,
On Tue, 29 Jul 2008, Jeff King wrote:
> On Tue, Jul 29, 2008 at 01:27:44AM +0200, Johannes Schindelin wrote:
>
> > > So the logical sequence was:
> > >
> > > git checkout production
> > > git merge -s theirs master
> >
> > To me, this suggests that they were too married to 'production' being
> > the "dominant" branch.
>
> Perhaps. But I see this as an operation on the production branch: "pull
> in master's changes, forgetting ours".
First of all, I cannot say how wrong it is to forget any changes in a
production branch without proper explanation. I.e. without a commit
message explaining _why_ the change was wrong to begin with.
It is messy at best, and I am happy that Git does not make that easy.
> In your workflow (git checkout master && git merge -s ours production &&
> git push origin master:production) we perform an operation on master,
> which doesn't seem as intuitive to me.
But why? Isn't the _content_ of "master" what we want?
> Not to mention that we might not _control_ master.
This is Git. We control all local branches.
> What about (and I think Sverre mentioned something like this
> previously):
>
> I forked the kernel and made some changes. Some of my changes got
> applied upstream. The others are now obsolete. Now I want to bring
> myself in sync with Linus, but I want to keep my history (either
> because the history is interesting to me, or because others are basing
> their work on it).
>
> Then your workflow, while still possible within the local repository,
> means you are munging the "linus" branch, which seems wrong. That branch
> is probably even just a tracking branch, which you would not want to
> build on, anyway.
No, this workflow almost _dictates_ a plain "pull" into your local branch.
The fact that a few commits were applied to upstream usually only means
that your merge succeeds trivially, since the merged branches contain the
_same_ changes.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Johannes Schindelin @ 2008-07-29 10:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, David Brown, Alex Riesen, Johannes Sixt, git
In-Reply-To: <alpine.LFD.1.10.0807281817230.3486@nehalem.linux-foundation.org>
Hi,
On Mon, 28 Jul 2008, Linus Torvalds wrote:
> On Mon, 28 Jul 2008, Junio C Hamano wrote:
> > >
> > > Anybody who uses extended attributes as part of a indexing scheme is
> > > just insane. Modifying the file you are indexing is not just
> > > fundamentally wrong to begin with, but it will then also be
> > > incredibly inefficient to read those entries one at a time.
> >
> > It's a typo and you are saying it _is_ fundamentally wrong, aren't
> > you?
>
> Not a typo, and I'm sayin that "it's not _just_ fundamentally wrong"
>
> So yes, it's fundamentally wrong, but it's worse than that. It's
> fundamentally wrong _and_ it's inefficient as hell.
I haven't looked at Beagle's source code either, but as a _user_ I can say
that it really became horribly, horribly slow after half a year of normal
usage.
And yes, uninstalling Beagle, backing up the files, reformatting and
putting the files back (to really get rid of the extended attributes
already in the file system) helped.
So the first thing I did, back when I still used openSUSE, was to
uninstall Beagle after the system install.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Johannes Schindelin @ 2008-07-29 10:45 UTC (permalink / raw)
To: David Brown
Cc: Junio C Hamano, Linus Torvalds, Alex Riesen, Johannes Sixt, git
In-Reply-To: <20080729014120.GA26807@old.davidb.org>
Hi,
On Mon, 28 Jul 2008, David Brown wrote:
> On Mon, Jul 28, 2008 at 06:31:24PM -0700, Junio C Hamano wrote:
>
> > Why does "rename(old, new)" change st_ctime when you move a regular
> >file?
>
> But, from the point of view of backup software, not updating the ctime
> on rename would be horrible, because you'd never know when files got
> renamed.
Any backup software that does not discover that there is a new _filename_
is not worth the label "software". Rather "daftware" or somesuch.
Ciao,
Dscho
^ permalink raw reply
* Re: short log and email address
From: Mark Brown @ 2008-07-29 10:22 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910807281125m7e555377l89cb57dff0f57ee2@mail.gmail.com>
On Mon, Jul 28, 2008 at 02:25:23PM -0400, Jon Smirl wrote:
> 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.
Both of them are me, though I have deliberately chosen to use the two
addresses (except for the stuff that went via ARM where the patch system
has the same inability to cope with multiple people with the same name).
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Mike Ralphson @ 2008-07-29 9:36 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Johannes Schindelin, sverre, Git Mailinglist,
Miklos Vajna
In-Reply-To: <20080729050218.GD26997@sigill.intra.peff.net>
2008/7/29 Jeff King <peff@peff.net>:
> On Mon, Jul 28, 2008 at 05:37:33PM -0700, Junio C Hamano wrote:
>
> I just didn't want history thrown away for two reasons:
>
> - historical interest; some of the commits had counterparts in devel
> that were done differently (because the two branches had diverged),
> but it might later be interesting to see how and why the stable
> changes were done (e.g., if a similar situation arose)
>
> - this project did not rebase, favoring the simplicity of "git pull"
> over clean history.
>
> Bear in mind that this project was not very big. I think devel had ~20
> commits, and stable had about ~5. So it was easy to get such confidence.
Is there any reason you couldn't have reverted the stable commits in
preparation for the merge from devel?
I.e. these commits were necessary to fix problems in production, they
now need to be reverted in order to cleanly apply the changes for the
next stable version, which includes fixes for all of these problems.
I can see you'd be preserving twice as much history instead of
throwing any away, but if scalability became an issue, you could
always squash all the reverts into one pre-merge commit.
git-merge-theirs-revert anyone?
Mike
^ permalink raw reply
* Re: Hackontest ideas?
From: Jakub Narebski @ 2008-07-29 9:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080729000103.GH32184@machine.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> Hi,
>
> participating in this might be fun, even if there is not much time
> left to sign up:
>
> http://www.hackontest.org/index.php?action=Root-projectDetail(120)
>
> (What feature in Git or a Git-related tool would you implement, given 24
> hours staight and unlimited pizza supply?)
A few ideas (some might be repeated)
* resumable clone
* git-push implemented as CGI
* support for ftp, ftps, sftp fetch
* support for gits (git over SSL/TLS) fetch
* relative blame, i.e. if you have blame data for some revision
(for example in "git gui blame") you want to have data for some
revision which is either direct ancestor or direct descendant
of the revision you have blame data for, aka "git blame --relative"
* "tree" blame, i.e. something like VievVC or GitHub shows:
for exach entry in a tree commit which brought it to current version
* graph log for gitweb, either generating images on the fly, or using
a few pre-defined images ('|', '-', '\', '/', etc.) and CSS.
* "MediaWiki history"-like or "MoinMoin info"-like view for gitweb
* improvements to "git log --follow" so it works also for nonlinear
history (for example "git log --follow gitweb/gitweb.perl" following
to the very first version of gitweb, then as gitweb.cgi)
* graphical history viewer for Git mode in Emacs.
* context sensitive searching in gitweb, for example searching
commits on given branch, or grepping files in given directory
* handling of svn:externals using submodules
* custom merge strategy for ChangeLog, for .po files
Blame merge strategy would take probably much more that 24h solely
in the initial design phase...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Ingo Molnar @ 2008-07-29 9:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080729055014.GE11947@spearce.org>
* Shawn O. Pearce <spearce@spearce.org> wrote:
> Ingo Molnar <mingo@elte.hu> wrote:
> >
> > Setup/background: distributed kernel testing cluster, [...]
> >
> > Problem: i noticed that git-fetch is a tad slow:
> >
> > titan:~/tip> time git-fetch
> > real 0m2.372s
> Also, I wonder if you really need to fetch over SSH. Doing a fetch
> over git:// is much quicker, as there is no SSH session setup
> overheads.
note that titan is a very beefy box, almost 3 GHz Core2Duo:
model name : Intel(R) Core(TM)2 CPU E6800 @ 2.93GHz
stepping : 5
cpu MHz : 2933.331
server is 3 GHz. So if we have a quadratic overhead on number of
branches, that's going to be quite a PITA.
> I wonder if git-pack-refs + fetching only a single branch will get you
> closer to the tip-fetch time.
should i pack on both repos? I dont explicitly pack anything, but on the
server it goes into regular gc runs. (which will pack most stuff,
right?)
Ingo
^ permalink raw reply
* Re: git merge --squash isn't "marked as a merge"??
From: Junio C Hamano @ 2008-07-29 8:53 UTC (permalink / raw)
To: git
In-Reply-To: <488ECB89.5060801@sneakemail.com>
"Peter Valdemar Mørch (Lists)" <4ux6as402@sneakemail.com> writes:
> Newbie alert:
>
> I have a feature branch where I have N tiny commits with sloppy/private
> commit messages....
Probably you would want to step back and _think_ why you want to squash in
the first place. I suspect the answer would lead to a better use of the
available set of tools, such as "use 'rebase -i' to clean up the original
history and then 'merge' (without squash) it or 'rebase' it".
^ permalink raw reply
* Re: git submodules
From: Petr Baudis @ 2008-07-29 8:51 UTC (permalink / raw)
To: Pierre Habouzit, Benjamin Collins, Avery Pennarun, Nigel Magnay,
Git ML
In-Reply-To: <20080729083755.GC32312@artemis.madism.org>
On Tue, Jul 29, 2008 at 10:37:55AM +0200, Pierre Habouzit wrote:
> So okay, let's scratch this "automatic reference" thing, I see its
> limits now, so what about having a .gitmodule entry look like:
>
> [submodule "$path"]
This is not a "$path" but arbitrary string. Please keep that in mind.
> path = "$path"
> url = git://somewhere/
> tracks = master
I do like this (well, I'd just name it "branch" instead of "tracks").
I use submodules very "traditionally" just to bind external projects of
certain version to my project, but I have been already thinking about
implementing this merely as a hint for others to know what branch should
the other developers follow when updating the submodule to a newer
version.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-29 8:45 UTC (permalink / raw)
To: Nigel Magnay; +Cc: Shawn O. Pearce, Benjamin Collins, Avery Pennarun, Git ML
In-Reply-To: <320075ff0807290118o62a6fc1eq3e90e32ef7783a17@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2247 bytes --]
On Tue, Jul 29, 2008 at 08:18:12AM +0000, Nigel Magnay wrote:
> >> I try to keep all my submodules on (no branch) as much as possible.
> >> In a way, I feel like that kind of relieves me of the chore of keeping
> >> mapping superproject branches to submodule branches in my head.
> >
> > At my former day-job we wrote our own "git submodule" in our
> > build system before gitlink was available in the core, let alone
> > git-submodule was a Porcelain command.
> >
> > Many developers who were new to Git found having a sea of 11 Git
> > repositories+working directories in a single build area difficult to
> > manage. They quickly found the detached HEAD feature in a submodule
> > to be a really handy way to know if they made changes there or not.
> >
> > Most of our developers also modified __git_ps1() in their bash
> > completion to use `git name-rev HEAD` to try and pick up a remote
> > branch name when on a detached HEAD. This slowed down their bash
> > prompts a little bit, but they found that "origin/foo" hint very
> > valuable to let them know they should start a new branch before
> > making changes.
> >
> > So I'm just echoing what Benjamin said above, only we did it
> > independently, and came to the same conclusion.
> >
>
> Hm.
> My developers are (mostly) on windows, so "altering PS1" or even
> writing "shell scripts" is way beyond them.
More importantly, you don't have all your submodule states in your PS1
so this argument is already moot for *nix users as well.
> They want it to "just work" (where their previous experience is SVN
> superprojects with multiple svn:externals). I have a hard time
> justifying the experience that if we're all working on master, then as
> soon as Joe Q developer does 'submodule update' then poof - his heads
> are disconnected.
Well, maybe it's not as hard, maybe what we lack are just submodule
aware porcelains (I mean we lack those for sure, but maybe it's also
the _only_ thing we miss to have a better user experience, and I begin
to believe it).
--
·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-29 8:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Steffen Prohaska, git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <7v8wvlmf6k.fsf@gitster.siamese.dyndns.org>
Zitat von Junio C Hamano <gitster@pobox.com>:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
> > Zitat von Steffen Prohaska <prohaska@zib.de>:
> > ...
> >> 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.
>
> > ...
> > Your patches make a lot of sense.
>
> I was almost going to suggest doing this everywhere not just on Windows,
> but execv_git_cmd() on the POSIX side already runs "git" wrapper, so this
> patch makes them in line, finally.
For this reason I'm in favor of these patches. I didn't run the full test suite
with them, yet, (you know, that takes a while on Windows), but "make *clone*
*fetch* *pack*" worked out OK.
-- Hannes
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-29 8:37 UTC (permalink / raw)
To: Benjamin Collins, Avery Pennarun, Nigel Magnay, Git ML
In-Reply-To: <20080729082135.GB32312@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]
On mar, jui 29, 2008 at 08:21:35 +0000, Pierre Habouzit wrote:
> * a way to remember where you want to push changes you do in the
> submodule to. That's a bit like branch tracking, but not quite. This
> is required so that we can (and I strongly believe we want that in
> the end) make many porcelain commands act on the full
> (super+sub)modules in a unified way, somehow hiding the submodules
> boundaries.
<snip>
>
>
> * What you "track" must be a per supermodule branch thing, so that if
> you do things like that:
<snip>
In fact, nowhere I used the name of the current submodule branch in my
examples, so maybe we don't really need it. What we need though, is a
way to tell where the submodules are pushed to, IO what they (try to)
track remotely, IOW of which remote reference they should always be a
parent.
Such an information is probably to be put in .gitmodules, this way,
you have the per-supermodule-branch setting I would like to see. And
then one would not care about the submodules be in a detached HEAD
because I believe those scenarii work well:
* If you do no changes in the submodules, all just works like it does
now.
* If your only work in the submodule is to refresh its state to the
tip of what it currently track, then well, we probably want a git
submodule command for that, and no further ado is done.
* If you just want a simple fix to go in the submodule, work from your
supermodule, as if there was no submodule. git-commit your changes
(which with a submodule aware git-commit would be transparent), then
you can push your work. And in the worst case scenario where you
cannot push because it's not a fast forward, you would fetch, merge
and push again.
You don't really need a name for the submodule, even if you want to
reset to the state before the merge because you screwed it, as
basically, git-reset would _also_ be submodule aware and DWYM
without an explicit reference for the submodule.
* If you have heavy works in the submodule, then you probably will
setup many submodule topic branches, work inside of it like you
already do, and the extra step of reattaching the HEAD somewhere is
not as bad as it is with (3) as it's a tiny overhead compared to all
you're going to do with your topic branches.
So okay, let's scratch this "automatic reference" thing, I see its
limits now, so what about having a .gitmodule entry look like:
[submodule "$path"]
path = "$path"
url = git://somewhere/
tracks = master
--
·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 1.6.0-rc1
From: Junio C Hamano @ 2008-07-29 8:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <7v4p69jefb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>>> Junio C Hamano, Mon, Jul 28, 2008 08:44:52 +0200:
>>>> Alex Riesen <raa.lkml@gmail.com> writes:
>>>>
>>>> > t2103-update-index-ignore-missing.sh still broken on Windows because
>>>> > of stat.st_size being 0 for directories there.
>>>>
>>>> I recall we did not reach a useful conclusion of that discussion.
>>>
>>> Why isn't the proposed patch useful? (and would it be possible to make
>>> the answer out of plain, small and short words?)
>>
>> Can you answer out of plain, small and short words why the proposed patch
>> is correct without unwanted side effects, not just "this seems to solve
>> the particular issue for me but I don't know if it has unintended side
>> effects"?
>
> Ok, I took a deeper look at the codepaths involved. Although it does work
> around the issue, I do not think your patch alone is the "correct" one in
> the longer term.
>
> It needs a bit of explanation, and the explanation won't be exactly
> "plain, small and short", unfortunately.
Alex, I ran the full test with this, but only on Linux boxes; obviously
not on any flavor of Windows. I think it is correct, and the "first line
of defence" fix is the same as your patch, so I'd assume it would work for
you as well. But extra eyeballs are always appreciated.
^ permalink raw reply
* Re: Hackontest ideas?
From: Petr Baudis @ 2008-07-29 8:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, git
In-Reply-To: <20080729053110.GD11947@spearce.org>
On Mon, Jul 28, 2008 at 10:31:10PM -0700, Shawn O. Pearce wrote:
> How about smart fetch/push over HTTP? E.g. a CGI (or extension to
> gitweb) that does native pack transport over HTTP rather than dumb
> object traversal with GET and WebDAV LOCK/PUT. Note that the push
> side doesn't need to support tell-me-more extension, making it a
> fairly trivial GET, POST (or PUT) sequence.
Ah, thanks for reminding me about this, nice!
Thanks all for their suggestions so far, I have added all of them plus
an extra. Now, if you want them implemented, some of you need to join as
implementers and the features need to get a lot of votes quickly! ;-))
(Frankly, I don't think there is really any chance to make it, but I
think having such a list of mid-size self-contained tasks might be
useful for other occasions, so I will haul it over to the wiki after the
deadline.)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Johannes Sixt @ 2008-07-29 8:33 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Junio C Hamano
In-Reply-To: <B6158330-640B-4CA3-8589-310FA8EA6CC9@zib.de>
Zitat von Steffen Prohaska <prohaska@zib.de>:
>
> On Jul 27, 2008, at 9:24 PM, Johannes Sixt wrote:
>
> > Zitat von Steffen Prohaska <prohaska@zib.de>:
> >
> >>
> >> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:
> >>
> >>> Zitat von Steffen Prohaska <prohaska@zib.de>:
> >>>> With MinGW's
> >>>>
> >>>> gcc.exe (GCC) 3.4.5 (mingw special)
> >>>> GNU ld version 2.17.50 20060824
> >>>>
> >>>> the old define caused link errors:
> >>>>
> >>>> git.o: In function `main':
> >>>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
> >>>> collect2: ld returned 1 exit status
> >>>>
> >>>> The modified define works.
> >>>
> >>> I have the same tools, but not this error. ???
> >>
> >> I cleaned my work tree and built several times but did not
> >> find out what exactly is causing the error. So I came up
> >> with the modified define, which declares the static
> >> mingw_main in global scope. I have no clue why I see the
> >> error that you don't have.
> >
> > Neither do I. But a strange line number you have there. In 01d9b2d
> > (from
> > mingw.git) I have 'exit(1)' in line 500 of git.c.
>
> I have the same in line 500. I am still wondering what this could
> mean. But I do not yet now :-(
Can you try 'make -k' and see whether you have a similar problem with the
non-builtins that have their own main()?
-- Hannes
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-29 8:21 UTC (permalink / raw)
To: Benjamin Collins; +Cc: Avery Pennarun, Nigel Magnay, Git ML
In-Reply-To: <b3889dff0807282251t7096a8c9wf477cf4495749d34@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4939 bytes --]
On Tue, Jul 29, 2008 at 05:51:31AM +0000, Benjamin Collins wrote:
> I try to keep all my submodules on (no branch) as much as possible.
> In a way, I feel like that kind of relieves me of the chore of keeping
> mapping superproject branches to submodule branches in my head.
Why would _you_ map them to superproject branches ? I mean it's pretty
much Git's matter. In fact, maybe calling them branches is not a
brilliant idea, what I would like would probably rather be some kind of
reflog like thing, but with one reflog per submodule and supermodule
branch.
I agree with you than when you don't have to do any change in the
submodule, detached HEADs just work. But when you often have to push
fixes in, it's a nightmare. Instead of just having to:
$EDITOR mysubmodule/file.c
git commit mysubmodule/file.c # that would ideally do a commit in the
# submodule then update the submodule
# state in the supermodule
git submodule mysubmodule push origin HEAD # push the submodule mysubmodule
# changes to the appropriate branch
git push origin HEAD
You have to:
cd submodule
git branch -D master
git checkout -b master
git commit file.c
cd ..
git commit submodule
cd submodule
git push origin HEAD:remote/branch/we/want/to/push/to
cd ..
git push origin HEAD
*phew*
I'm sorry but this is nowhere near a good UI. Of course the detached
head *currently* prevents you to shoot yourself in the foot, because
submodules are _that_ dangerous. But those also are tedious to work
with, like a lot, which makes currently our answer to big projects "do
not have GB-big repositories, split them in submodules" a bad joke,
because their ergonomy is nowhere near what you have with a monolithic
repository yet.
I'm trying to see what to do better. I believe we _need_ those things:
* a way to name the successive states of the submodule, a branch looks
like a good idea, but maybe we can "invent" some different idea so
that it looks and tastes like a branch, but is more automagic in the
sense that it's just a prettier name than a sha1.
This would allow to inspect the submodule history using
`gitk $this_name`. The $PS1 thing is nice, but you have to cd into
the submodule to see where it currently lives. So you rather need
something else.
* a way to remember where you want to push changes you do in the
submodule to. That's a bit like branch tracking, but not quite. This
is required so that we can (and I strongly believe we want that in
the end) make many porcelain commands act on the full
(super+sub)modules in a unified way, somehow hiding the submodules
boundaries.
For example, git commit file1 file2 file3 ... would do the
submodules commits if any, and then the supermodule one. Alternatively, if
you have e.g.:
$ git add mysubmodule/file1.c
$ git add superfile.c
$ git add mysubmodule # tell the supermodule we want to commit what
# is in the submodule index at the same time
$ git commit
Then if you run:
$ git push # fails complaining that mysubmodule is
# not pushed
$ git submodule mysubmodule push
$ git push # works
* What you "track" must be a per supermodule branch thing, so that if
you do things like that:
# you are in master in the supermodule with non pushed commits in
# the submodule
<.. oh crap there is a bug in the supermodule that I need to fix in
the production branch..>
$ git checkout production # would checkout in the submodule what
# matches
$ $EDITOR mysubmodule/something
$ git commit !$
$ ..push everything..
<.. okay let's now go back to master ..>
$ git checkout master
<... hack hack hack to finish the current WIP ...>
<... okay we're ready to merge production in ...>
$ git merge production # will DWYM with the submodules, IOW merge the
# `production` state into the current `master` one.
$ git sm mysubmodule push
$ git push
Try to write the same workflow with the current submodules, you'll
end up with a script at least 3 times as long, because you would
need to do everything by hand, including switching submodules,
naming temporary branches in them so that you can work decently and
perform the merges and so on.
--
·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: Nigel Magnay @ 2008-07-29 8:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Benjamin Collins, Avery Pennarun, Pierre Habouzit, Git ML
In-Reply-To: <20080729060449.GG11947@spearce.org>
>> I try to keep all my submodules on (no branch) as much as possible.
>> In a way, I feel like that kind of relieves me of the chore of keeping
>> mapping superproject branches to submodule branches in my head.
>
> At my former day-job we wrote our own "git submodule" in our
> build system before gitlink was available in the core, let alone
> git-submodule was a Porcelain command.
>
> Many developers who were new to Git found having a sea of 11 Git
> repositories+working directories in a single build area difficult to
> manage. They quickly found the detached HEAD feature in a submodule
> to be a really handy way to know if they made changes there or not.
>
> Most of our developers also modified __git_ps1() in their bash
> completion to use `git name-rev HEAD` to try and pick up a remote
> branch name when on a detached HEAD. This slowed down their bash
> prompts a little bit, but they found that "origin/foo" hint very
> valuable to let them know they should start a new branch before
> making changes.
>
> So I'm just echoing what Benjamin said above, only we did it
> independently, and came to the same conclusion.
>
Hm.
My developers are (mostly) on windows, so "altering PS1" or even
writing "shell scripts" is way beyond them. They want it to "just
work" (where their previous experience is SVN superprojects with
multiple svn:externals). I have a hard time justifying the experience
that if we're all working on master, then as soon as Joe Q developer
does 'submodule update' then poof - his heads are disconnected.
That said, I do also like the flexibility that having the superproject
on heads/foo and a submodule on heads/bar as it allows you to
integration test divergent submodule branches (indeed our CI system
automatically picks them up and tries all possible combinations).
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-29 8:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <7vr69dky93.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> Junio C Hamano, Mon, Jul 28, 2008 08:44:52 +0200:
>>> Alex Riesen <raa.lkml@gmail.com> writes:
>>>
>>> > t2103-update-index-ignore-missing.sh still broken on Windows because
>>> > of stat.st_size being 0 for directories there.
>>>
>>> I recall we did not reach a useful conclusion of that discussion.
>>
>> Why isn't the proposed patch useful? (and would it be possible to make
>> the answer out of plain, small and short words?)
>
> Can you answer out of plain, small and short words why the proposed patch
> is correct without unwanted side effects, not just "this seems to solve
> the particular issue for me but I don't know if it has unintended side
> effects"?
Ok, I took a deeper look at the codepaths involved. Although it does work
around the issue, I do not think your patch alone is the "correct" one in
the longer term.
It needs a bit of explanation, and the explanation won't be exactly
"plain, small and short", unfortunately.
-- >8 --
[PATCH] Teach gitlinks to ie_modified() and ce_modified_check_fs()
The ie_modified() function is the workhorse for refresh_cache_entry(),
i.e. checking if an index entry that is stat-dirty actually has changes.
After running quicker check to compare cached stat information with
results from the latest lstat(2) to answer "has modification" early, the
code goes on to check if there really is a change by comparing the staged
data with what is on the filesystem by asking ce_modified_check_fs().
However, this function always said "no change" for any gitlinks that has a
directory at the corresponding path. This made ie_modified() to miss
actual changes in the subproject.
The patch fixes this first by modifying an existing short-circuit logic
before calling the ce_modified_check_fs() function. It knows that for any
filesystem entity to which ie_match_stat() says its data has changed, if
its cached size is nonzero then the contents cannot match, which is a
correct optimization only for blob objects. We teach gitlink objects to
this special case, as we already know that any gitlink that
ie_match_stat() says is modified is indeed modified at this point in the
codepath.
With the above change, we could leave ce_modified_check_fs() broken, but
it also futureproofs the code by teaching it to use ce_compare_gitlink(),
instead of assuming (incorrectly) that any directory is unchanged.
Originally noticed by Alex Riesen on Cygwin.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
read-cache.c | 27 ++++++++++++++++++++++-----
1 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index b5916b0..a940f8d 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -152,7 +152,7 @@ static int ce_modified_check_fs(struct cache_entry *ce, struct stat *st)
break;
case S_IFDIR:
if (S_ISGITLINK(ce->ce_mode))
- return 0;
+ return ce_compare_gitlink(ce) ? DATA_CHANGED : 0;
default:
return TYPE_CHANGED;
}
@@ -192,6 +192,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
changed |= TYPE_CHANGED;
break;
case S_IFGITLINK:
+ /* We ignore most of the st_xxx fields for gitlinks */
if (!S_ISDIR(st->st_mode))
changed |= TYPE_CHANGED;
else if (ce_compare_gitlink(ce))
@@ -298,11 +299,22 @@ int ie_modified(const struct index_state *istate,
if (changed & (MODE_CHANGED | TYPE_CHANGED))
return changed;
- /* Immediately after read-tree or update-index --cacheinfo,
- * the length field is zero. For other cases the ce_size
- * should match the SHA1 recorded in the index entry.
+ /*
+ * Immediately after read-tree or update-index --cacheinfo,
+ * the length field is zero, as we have never even read the
+ * lstat(2) information once, and we cannot trust DATA_CHANGED
+ * returned by ie_match_stat() which in turn was returned by
+ * ce_match_stat_basic() to signal that the filesize of the
+ * blob changed. We have to actually go to the filesystem to
+ * see if the contents match, and if so, should answer "unchanged".
+ *
+ * The logic does not apply to gitlinks, as ce_match_stat_basic()
+ * already has checked the actual HEAD from the filesystem in the
+ * subproject. If ie_match_stat() already said it is different,
+ * then we know it is.
*/
- if ((changed & DATA_CHANGED) && ce->ce_size != 0)
+ if ((changed & DATA_CHANGED) &&
+ (S_ISGITLINK(ce->ce_mode) || ce->ce_size != 0))
return changed;
changed_fs = ce_modified_check_fs(ce, st);
@@ -1331,6 +1343,11 @@ static void ce_smudge_racily_clean_entry(struct cache_entry *ce)
* falsely clean entry due to touch-update-touch race, so we leave
* everything else as they are. We are called for entries whose
* ce_mtime match the index file mtime.
+ *
+ * Note that this actually does not do much for gitlinks, for
+ * which ce_match_stat_basic() always goes to the actual
+ * contents. The caller checks with is_racy_timestamp() which
+ * always says "no" for gitlinks, so we are not called for them ;-)
*/
struct stat st;
^ permalink raw reply related
* git merge --squash isn't "marked as a merge"??
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-29 7:49 UTC (permalink / raw)
To: git
Newbie alert:
I have a feature branch where I have N tiny commits with sloppy/private
commit messages. Being able to have private commits was the main reason
I'm using git (as a frontend to svn).
Today the feature is in a "good" state, and I want to merge it into a
main branch, showing a single commit with a well phrased message for all
the world to see. So I:
$ git checkout master
$ git merge --squash feature
$ git commit -F wellphrased.msg
Now I was expecting that:
$ git merge feature
would do nothing (I already did a merge!). But it pulls in all the
sloppy commits and messages from "feature"!
Of course now I could continue with a new branch made like this:
$ git checkout -b feature2 master
and continue working privately on feature2 again. Then I'll end up with
feature..feature47 before I'm done. Each with its own segment of my
private history. A real mess.
Can I continue on feature somehow so I privately can "git log" and
see all my messy commits (both before and after the "git merge
--squash") and then regularly "git merge" and/or "git merge --squash"
back and forth between "feature" and "master" as I deem appropriate?
I'm guessing that if the --squash *did* put in a "merge arrow" (setting
a "parent" of the commit to the head of feature) thereby allowing merge
to not do anything, then git log would also follow feature's sloppy
history too. They go together as a pair. Is that right? Testing this:
git help merge says about --squash:
> Produce the working tree and index state as if a real merge happened,
> but do not actually make a commit or move the HEAD, nor record
> $GIT_DIR/MERGE_HEAD to cause the next git commit command to create a
> merge commit.
So I tried "git merge --squash feature", then set up .git/MERGE_HEAD to
the same contents as .git/refs/heads/feature and then "git commit". This
produced the same result as "git merge" without --squash including all
the sloppy messages.
SO: It seems to me I cannot continuously merge "feature" to "master" in
chunks with "--squash" as I would like. Is that right? Is my desire
fundamentally misguided, and is there A Better Way?
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: GTP/0.1 terminology 101: commit reels and references
From: Sam Vilain @ 2008-07-29 7:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <alpine.DEB.1.00.0807290014110.2725@eeepc-johanness>
On Tue, 2008-07-29 at 00:30 +0200, Johannes Schindelin wrote:
> > 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.
>
> But does that not mean that any new ref branching off of an ancient commit
> changes all the pack boundaries?
No. A "References" object is a snapshot of all refs at a particular
time. If you want to make a new ref you make a new "References" object.
*all* of the new objects are contained in the new reel, and the new
reels do not affect the old reels.
> That should be easy, but I think that it would be _even better_ if we ask
> pack-objects to generate several packs from the needed objects. Ooops.
> That already exists:
>
> $ git pack-objects --max-pack-size=<n>
This does not deterministically generate the same pack for a given set of
refs across all git versions.
Your ideas would have been excellent earlier on, perhaps if developed
they might have resulted in something quite a bit simpler with all of
the features the current protocol has - but given we are in the second
half of a GSoC project of which the end is in sight then I think we
should shelve them until the project finishes. There has certainly been
a lot of useful things come out of them!
Cheers,
Sam.
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 23:12 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nigel Magnay, Git ML
In-Reply-To: <32541b130807281532v3eed94ebv8037247618e9bd55@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5156 bytes --]
On Mon, Jul 28, 2008 at 10:32:54PM +0000, Avery Pennarun wrote:
> On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
> > > It's unfortunate that submodules involve a commit->tree->commit link
> > > structure.
> >
> > Actually it's not a big problem, you just have to "dereference" twice
> > instead of one, and be prepared to the fact that the second dereference
> > may fail (because you miss some objects). I instead believe that
> > gitlinks are a good idea.
>
> It's actually complicated to generate the log, however. To be 100%
> accurate in creating a combined log of the supermodule and submodule,
> you'd have to check *for each supermodule commit* whether there were
> any changes in gitlinks. And gitlinks might move around between
> revisions, so you can't just look up a particular path in each
> revision; you have to traverse the entire tree. And you can't just
> look at the start and end supermodule commits to see if the gitlinks
> changed; they might have changed and then changed back, which is quite
> relevant to log messages.
I'm pretty clueless about how git-log works, but I fail to see how this
is harder than following file moves e.g. Of course it's more expensive
than git log, but it shouldn't really be more expensive than
`git log -M -C -C` already is.
> > Well, using the same [branch] as the supermodule is probably the less confusing
> > way. Of course, not being in the "same" branch as the supermodule would
> > clearly be a case of your tree being "dirty", and it would prevent a
> > "git checkout" to work in the very same way that git checkout doesn't
> > work if you have locally modified files.
> >
> > If your submodule branching layout uses the same names as the
> > supermodule branches then yes, it's going to hurt, but I believe it to
> > be unlikely (else you would become insane just trying to remember what
> > you are doing ;p).
>
> I think this is much more common than you think. An easy example is
> that I'm developing a new version of my application in the
> supermodule's "master", but it relies on a released version of my
> submodule, definitely not the experimental "master" version. Using
> your logic, the local branch of the submodule would be called master,
> but wouldn't correspond at all to the remote submodule's master.
Probably indeed, otoh the "remote" (assume it's origin) master state is
stored in "origin/master", not "master".
> I believe such a situation would be even worse than no branch at all.
> It could lead to people pushing/pulling all sorts of bad things from
> the wrong places. At least right now, people become confused and ask
> for help instead of becoming confused and making a mess.
Indeed. But that's only a name issue, I'm sure we can come up with
something decent. What I (we ?) want is actually a way to make
git-checkout/git-reset work so that when you switch branches (reset
--hard to a previous state) you remain on branch, because human brains
usually don't remember those silly detached HEADs commits sha1 well ;)
The problem is, `the branch I'm on in my submodule when the supermodule
is on $foo` is a quite local information. But that's really what we
would like to remember so that when you git checkout somewhere and git
checkout master back, submodules switches branch accordingly.
Saying that, I realize that we probably _really_ want to name submodule
branches the same as the supermodule ones, but should manage to find UIs
that don't confuse users wrt the fact that it may be disconnected from
the remote branch nameing.
I reckon that for my use, I would not have those problems, because we
have this kind of layout:
lib-foo/ <-- submodule to share the foo library.
lib-bar/ <-- submodule to share the bar library.
app-frotz/ <-- the frotz product
In another repository we have app-quux and the same submodules, and so
on.
We always try that our `master`s (where devel happens unlike git.git ;p)
use the most recent `master` versions from the submodules. And the
stable branches (IOW the software that we sold and released and for
which we provide support), have branches named $product/$version. We
have $product/$version branches in those submodules as well. If we have
a bug that needs a patch in say, lib-foo, then we push the patch into a
topic branch, that we merge in all the $product/$version that need it,
and into master as well. For such a setup that I believe to be sane,
then well, corresponding names fit the job perfectly.
Of course if one of your submodule is git.git where the not too unstable
code lives in `next` and not `master` and another one is one of my
project at work, where not too unstable code lives in `master` then
indeed you're somehow screwed because indeed the whole `master` concept
would be quite confusing. But honestly, I don't think it's less
confusing with the current way submodules work either.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 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