* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Jeff King @ 2008-07-29 12:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: sverre, Git Mailinglist, Miklos Vajna
In-Reply-To: <alpine.DEB.1.00.0807291301060.4631@eeepc-johanness>
On Tue, Jul 29, 2008 at 01:05:11PM +0200, Johannes Schindelin wrote:
> > 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.
Of course; I even mentioned the same in another part of the thread. But
that isn't a difference between "ours" and "theirs"; any time you are
discarding some changes, you should mention why.
> > 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?
Sure, which means we must _read_ from master. But you are _changing_
master. Whereas I view this as an operation on the production branch.
Please don't misunderstand me. I am not saying your way of thinking
about it is wrong (or even less right than mine). What I have been
trying to say this whole thread is that it is reasonable for a user to
model the goal as I have described, and that git can easily support the
direct implementation of achieving that goal (which is what Sverre asked
originally -- is this useful to people?).
> > Not to mention that we might not _control_ master.
>
> This is Git. We control all local branches.
Sort of. Consider the kernel example I gave. A "linus" branch represents
"this is where Linus is." But that _isn't_ where Linus is if you have
added an extra merge commit to it. So either we throw away the change
made to the "linus" branch, or we forever have extra merges that Linus
does not have.
So yes, obviously you can do whatever you like with your local branches.
But you complained in my example that the "production" branch was
unnecessarily being treated as "dominant". My example was meant to
indicate that the "thrown away" branch is dominant for a reason (in this
case, it is my work branch, while the other is a tracking branch).
> 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.
I don't see the point in talking about "usually". In the scenario in
which I used it, the merge _didn't_ succeed trivially. Of course,
usually you would not use "-s theirs". But the question was "is this
ever useful?" and my answer was "rarely, but here is an example of when
I wanted it."
If you are using "-s theirs" frequently, you are probably doing
something wrong. But that doesn't mean it is wrong for it to exist.
-Peff
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: Roman Zippel @ 2008-07-29 12:32 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Tim Harper, git
In-Reply-To: <20080729053108.GH26997@sigill.intra.peff.net>
Hi,
On Tue, 29 Jul 2008, Jeff King wrote:
> > Can we please get past this and look at what is required to produce the
> > correct history?
>
> You seem to be indicating here (and elsewhere in the thread) that there
> exists some history graph for which neither "git log" nor "git log
> --full-history" produces the output you want, but that there is some
> better output (even if it might take more time to compute).
>
> Perhaps I am just slow, but I haven't been able to figure out what that
> history is, or what the "correct" output should be. Can you try to state
> more clearly what it is you are looking for?
Most frequently this involves changes where the same change is merged
twice. Another interesting example is kernel/printk.c where a change is
added and later removed again before it's merged.
With "git-log --full-history" you see these changes, but it lacks the
necessary merges to produce a full graph. As consequence none of the
graphical front ends produce a useful history graph.
This problem now hits me now more seriously in a repository conversion,
where it frequently happened, that changes were applied both locally and
upstream, so that I have relatively many of these empty merges and the
default git-log output is useless. --full-history is more of a workaround
than a real solution and again the history graph in _all_ graphical front
ends is useless.
More generally this means in any kind of situation where you maintain your
own repository and it takes a while until upstream accepts your changes,
so that you frequently have duplicated changes (because upstream doesn't
use git or doesn't pull directly), you have to be careful to get the right
history out of git.
The point is now that I think the problem is solvable even within Linus'
constraints, so that git-log produces the right output by default and a
workaround like --full-history isn't needed anymore.
bye, Roman
^ permalink raw reply
* Re: git-svn and svn:externals, was Re: Hackontest ideas?
From: Jakub Narebski @ 2008-07-29 12:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Eric Wong, git
In-Reply-To: <alpine.DEB.1.00.0807291354130.4631@eeepc-johanness>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 29 Jul 2008, Jakub Narebski wrote:
>
> > * handling of svn:externals using submodules
>
> I doubt that this is easy. Otherwise, Eric would have done it a long time
> ago.
Yeah, I guess is too large a project for Hackontest.
> The main concern I have is to get the semantics right: AFAICT
> svn:externals has _no notion_ of "what is current". It just _always_
> fetches the HEAD. Even if you check out an ancient revision in the
> "superproject".
If I understand correctly with version 1.5 svn:externals can be
specified using "peg revisions", so they could refer to some specific
revision of 'external', like git submodules.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git submodules
From: Johannes Schindelin @ 2008-07-29 12:15 UTC (permalink / raw)
To: Petr Baudis
Cc: Pierre Habouzit, Benjamin Collins, Avery Pennarun, Nigel Magnay,
Git ML
In-Reply-To: <20080729085125.GJ32184@machine.or.cz>
Hi,
On Tue, 29 Jul 2008, Petr Baudis wrote:
> On Tue, Jul 29, 2008 at 10:37:55AM +0200, Pierre Habouzit wrote:
>
> > 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.
As long as you only use it in "submodule status" to say what the relation
of the current revision is with respect to the "tracks" branch...
But then, how does the relation to the currently _committed_ state get
displayed?
Ciao,
Dscho
^ permalink raw reply
* Re: [trivial fast-export PATCH] Fix typo in documentation
From: Johannes Schindelin @ 2008-07-29 12:06 UTC (permalink / raw)
To: Nick Andrew; +Cc: git
In-Reply-To: <20080729045026.27648.54610.stgit@marcab.local.tull.net>
Hi,
On Tue, 29 Jul 2008, Nick Andrew wrote:
> hg-fast-export.txt | 10 +++++-----
I do not see this in git.git. Maybe you meant to Cc: Simon Hausmann,
Rocco Rutte or Han-Wen?
Or Chris Lee, who seems to be the owner of fast-export.git.
Ciao,
Dscho
^ permalink raw reply
* Re: Bizarre missing changes (git bug?)
From: David Kastrup @ 2008-07-29 12:00 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0807291235350.6791@localhost.localdomain>
Roman Zippel <zippel@linux-m68k.org> writes:
> On Mon, 28 Jul 2008, Linus Torvalds wrote:
>
>> 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.
I'd like to add to Linus' suggested course of action the task "look up
threat in a dictionary".
> 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.
If _you_ need the functionality, you can easily keep it around in _your_
copy. That's what I do with a few patches that were not accepted here.
So the "risk of rejection" has no real cost for you (apart from an
occasional rebase on origin, which is cheap). Just for others. And of
no-one else argues your case, then they probably don't mind.
--
David Kastrup
^ permalink raw reply
* git-attic
From: Paul Gideon Dann @ 2008-07-29 11:57 UTC (permalink / raw)
To: git
Hello all,
I looked around everywhere for a script that could make it easy for me
to store stale branches in refs/attic for possible later retrieval. I
don't like such branches lying around in refs/heads and used to tag them
to clear them out of the way, but then that makes "git push origin
--tags" unusable, since I don't want to push my stale branches out...
Anyway, I wrote my own little script in the end and thought it might be
useful to others.
Please Cc pdgiddie@gmail.com in replies,
Paul Gideon Dann
Usage: git-attic
git-attic store <ref> [<commit>]
git-attic remove <ref>
#!/bin/bash
###
# Original Author: Paul Gideon Dann <pdgiddie@gmail.com>
###
showUsage() {
echo "Usage: git-attic"
echo " git-attic store <ref> [<commit>]"
echo " git-attic remove <ref>"
}
case $1 in
"store")
if [[ ! $2 ]]; then
showUsage
exit 1
fi
if [[ $3 ]]; then
OBJECT_SHA1=`git-rev-parse --revs-only $3`
if [[ ! $OBJECT_SHA1 ]]; then
echo "$3 is not a recognisable commit object."
exit 1
fi
else
OBJECT_SHA1=`git show-ref -h HEAD | awk '{print $1}'`
fi
git update-ref refs/attic/$2 $OBJECT_SHA1
echo "$2 stored in attic."
;;
"remove")
if [[ ! $2 ]]; then
showUsage
exit 1
fi
OBJECT_SHA1=`git show-ref attic/$2 | awk '{print $1}'`
if [[ ! $OBJECT_SHA1 ]]; then
echo "$2 does not exist in the attic!"
exit 1
fi
git update-ref -d refs/attic/$2 $OBJECT_SHA1
echo "$2 removed from attic."
;;
*)
if [[ $1 ]]; then
showUsage
else
# display contents of attic
git for-each-ref --format="%(refname)" refs/attic | awk -F /
'{print $3}'
fi
;;
esac
^ permalink raw reply
* git-svn and svn:externals, was Re: Hackontest ideas?
From: Johannes Schindelin @ 2008-07-29 11:56 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, Eric Wong, git
In-Reply-To: <m3myk1t54c.fsf@localhost.localdomain>
Hi,
On Tue, 29 Jul 2008, Jakub Narebski wrote:
> * handling of svn:externals using submodules
I doubt that this is easy. Otherwise, Eric would have done it a long time
ago.
The main concern I have is to get the semantics right: AFAICT
svn:externals has _no notion_ of "what is current". It just _always_
fetches the HEAD. Even if you check out an ancient revision in the
"superproject".
Ciao,
Dscho
^ permalink raw reply
* SSL + mod_dav + Git
From: Chris Hart @ 2008-07-29 11:53 UTC (permalink / raw)
To: git
Hi guys, I've been up all night on this one and after exhaustive
Googling and checking the sleepy #git, decided to check with the
mailing list! Here's the current problem:
Git is working perfectly over SSH. The server is Ubuntu, and doing
cadaver https://serveraddress/.git successfully authenticates using
the passwd file I provided to Apache. Basically I've done everything
from Rutger's guide
(http://www.kernel.org/pub/software/scm/git/docs/v1.4.4.4/howto/setup-git-server-over-http.txt)
except for the ~/.netrc stuff.
However, once authenticated to the .git folder (cadaver through
https), basic commands give strange errors or 404s. Ls throws "Listing
collection `/.git/': failed:
Could not read status line: Secure connection truncated" and cd
/to/some/legitimate/directory throws "Could not access /.git/dir/ (not
WebDAV-enabled?):
404 Not Found." Oddly tab-completion for cd suggests the contents of
the directory (although I'm cadaver-ing from localhost). Same results
remotely in a browser: authenticates successfully and gives 404s.
Trying git clone https://server/.git throws:
"warning: remote HEAD refers to nonexistent ref, unable to checkout"
...despite the working certificate and authorization. Any ideas?
Thanks infinity and one to anybody with attention for this!
Chris
Note: Apache owns all the files here so I really hope it's not a
permissions thing.
------------------ Git version info --------------------
server> git version 1.5.4.3
remote-laptop> git version 1.5.6.4
------------------------------------------------------------
^ permalink raw reply
* 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
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