* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Martin Langhoff @ 2007-10-12 4:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Harning Jr., git
In-Reply-To: <Pine.LNX.4.64.0710111704570.4174@racer.site>
On 10/12/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I, for one, am totally opposed to this split. All too often valuable
> _user_ discussions turn into _technical_ discussions, and thence into a
> throwing back and forth patches.
<aol>mee too! - I think it's the kind of development culture that
Linus tries to foster, and I suspect Junio likes too: "talk in
patches" which is a lot more productive than "talk like a pirate",
bikeshedding and other maladies that can fester in mailing lists.
So no split for me ;-) We have the additional alibi that git users are
supposed to be programmers.
m
^ permalink raw reply
* Re: [PATCH - amended] git-gui: update Italian translation
From: Shawn O. Pearce @ 2007-10-12 4:15 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Paolo Ciarrocchi, git, Johannes Schindelin
In-Reply-To: <200710102218.23482.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> wrote:
...
> So here it is. (Sent as an attachment because I fear mangling, sorry).
...
> Subject: [PATCH] git-gui: update Italian translation
>
> An Italian glossary was also added. Some changes:
> * commit (verb): (creare una) nuova revisione
> * commit (noun): revisione
> * checkout: attivazione
> * tracking branch: duplicato locale di ramo remoto
> * repository: archivio
> * some terms are used with more consistency
Thanks. I saw no further discussion on this thread so I have applied
the attached patch as-is. It will be in my repo.or.cz tree in a
couple of hours.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Fixed crash in fetching remote tags when there is not tags.
From: Shawn O. Pearce @ 2007-10-12 4:07 UTC (permalink / raw)
To: Alex Riesen
Cc: Jeff King, Väinö Järvelä, git, Junio C Hamano
In-Reply-To: <20071010212735.GB16635@steel.home>
Alex Riesen <raa.lkml@gmail.com> wrote:
> Still, I'd suggest move the test into the caller, firstly because it
> is the only place that special. Also, I can't think of a proper reason
> to add a NULL ref to a reflist, and so the crashing tail_link_ref will
> help us find the callers which use tail_link_ref incorrectly
> (illogically too).
>
> As the result of patter expansion can be NULL (empty pattern, as it
> seems), lets just check for it. I parked the patch below locally.
>
> diff --git a/remote.c b/remote.c
> index 5e92378..58d63ed 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -884,7 +884,8 @@ int get_fetch_map(struct ref *remote_refs,
> rm->peer_ref->name);
> }
>
> - tail_link_ref(ref_map, tail);
> + if (ref_map)
> + tail_link_ref(ref_map, tail);
>
> return 0;
> }
I disagree with Alex's argument above, because the result of the
pattern expansion can be NULL due to a pattern that matched nothing
from the remote. This can easily happen if the user originally
configured "remote.$name.fetch = +refs/heads/subdir/*:..." and
then the remote deletes all branches from refs/heads/subdir at some
point in the future.
I think the above patch is the only thing to do here. Perhaps Alex
can write up a formal patch and send it to back to the list and CC
Lars Hjemli <hjemli@gmail.com> so he can put it into the patch queue.
--
Shawn.
^ permalink raw reply
* Re: How to have multiple working copy directories use the same repository?
From: Shawn O. Pearce @ 2007-10-12 3:52 UTC (permalink / raw)
To: Alex Riesen, Bill Priest; +Cc: git
In-Reply-To: <20071011190025.GC2804@steel.home>
Alex Riesen <raa.lkml@gmail.com> wrote:
> Bill Priest, Thu, Oct 11, 2007 20:10:50 +0200:
> > I've looked at the "git for CVS users" section in
> > the docs and this appears to create two repositories.
> > Is there a way to have two working directories that
> > utilize the same repository?
>
> Look for "alternates" in git's documentation. But read all the
> warnings regarding git-gc and git-prune. Make a note of ".keep" files.
Really I think Bill wants the contrib/workdir/git-new-workdir script.
Its downside is that it makes heavy use of symlinks under the
.git directory for the secondary working directories, and you do
have to watch out for committing changes to a branch when more
than one working directory has that branch as its current branch.
But otherwise it works very well for this use case.
Also you may get a few warnings from your HEAD reflog saying objects
no longer exist when you do a git-gc within a working directory.
This can happen for example if you use `git rebase -i` in a working
directory a few times and then later run git-gc from a different
working directory. But since its just intermediate rebase state
its probably not that big of a deal to have it go missing.
You shouldn't run `git gc --prune` if any of the working directories
has staged but uncommitted changes in them. Such changes are held
in the working directory's index, which will not be considered
as reachable (as it isn't visible to git-gc) and the objects will
be pruned. That would not too be pleasant to debug.
Heh. As you can see it has some "issues" with its use. Its a very
powerful tool, but it does give you more than enough room to shoot
yourself in the foot. Using it is like tieing a gun to your ankle,
keeping it aimed at your big toe at all times, with a string tied
to your wrist and the gun's trigger. Reach too far and *bam*.
Which is why its still in contrib status.
--
Shawn.
^ permalink raw reply
* RE: Is it possible for git to support binary differencing for binary files?
From: franky @ 2007-10-12 3:04 UTC (permalink / raw)
To: 'Lars Hjemli'; +Cc: git
In-Reply-To: <8c5c35580710111027t127fe9d5qe098d5372783b0@mail.gmail.com>
This is also useful. 3x. However, git-gc is what I want.
-----Original Message-----
From: Lars Hjemli [mailto:hjemli@gmail.com]
Sent: Friday, October 12, 2007 1:27 AM
To: 银平
Cc: git@vger.kernel.org
Subject: Re: Is it possible for git to support binary differencing for
binary files?
On 10/11/07, 银平 <yinping@kooxoo.com> wrote:
> Storing binary files as deltas is helpful to keep source and binary files
> together and in sync So is it possible for git to do that as svn. This is
> my only pain when using git.
Could 'git diff --binary' and 'git apply --binary' be what you're looking
for?
--
larsh
^ permalink raw reply
* RE: Is it possible for git to support binary differencing for binary files?
From: franky @ 2007-10-12 3:01 UTC (permalink / raw)
To: 'Jean-Luc Herren'; +Cc: git
In-Reply-To: <470E633D.8060107@gmx.ch>
git-gc works perfectly! Thanks all very much.
-----Original Message-----
From: Jean-Luc Herren [mailto:jlh@gmx.ch]
Sent: Friday, October 12, 2007 1:54 AM
To: 银平
Cc: git@vger.kernel.org
Subject: Re: Is it possible for git to support binary differencing for
binary files?
银平 wrote:
> Hi.
> Storing binary files as deltas is helpful [...] So is it
> possible for git to do that as svn. This is my only pain when
> using git.
Yes, and git does this already in pack files. Maybe you're not
seeing it because you haven't packed anything yet. Try to run
'git gc'.
jlh
^ permalink raw reply
* Re: Suggestion for mailing lists... split [PATCH]-es into own list
From: Baz @ 2007-10-11 22:53 UTC (permalink / raw)
To: Thomas Harning Jr.; +Cc: git
In-Reply-To: <e47324780710110857s472bf099u3e350d17a2c29f78@mail.gmail.com>
On 11/10/2007, Thomas Harning Jr. <harningt@gmail.com> wrote:
> I use gmail as my mail client and it doesn't grok 'PATCH' filters
> (primarily the case of the word).
>
> Are there any of you using Gmail that has managed to get around this issue....?
Try this in the 'has the words' box (the whole thing):
to:git@vger.kernel.org -("+++ b" subject:"[PATCH")
Obviously get rid of the '-' for the other filter you'll want. Patches
that lead to discussion will probably get both tags. The "+++ b" is so
you don't class mails that don't have a patch in the body as patch
mails.
> Perhaps we should have a separate mailing list for patches vs discussion.
>
> --
> Thomas Harning Jr.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: Linus Torvalds @ 2007-10-11 22:33 UTC (permalink / raw)
To: Sam Vilain; +Cc: martin f krafft, git discussion list
In-Reply-To: <470E9AD5.2090002@vilain.net>
On Fri, 12 Oct 2007, Sam Vilain wrote:
>
> 1. do a --cherry-pick rev-list on just the file being merged and see if
> all the changes on one side disappear, in which case just take the result.
>
> 2. see if the files were identical at some point, in which case use a
> new merge base for that file based on the changes since that revision.
>
> I actually thought #2 was already the way recursive worked!
Actually, I think both of these are fundamentally wrong.
The reason is that you talk about "the file".
Anything that is based on per-file heuristics is going to mean that you
use a history that is not necessarily compatible with the _other_ files in
the project.
I agree 100% that per-file history information is going to find more
things to merge automatically. But the point I was trying to make was that
"automatic merges" aren't always *good*.
I realize that pretty much every single theoretical merge algorithm out
there tries to make merges happen automatically as much as possible, but
they all en dup having strange issues.
For example, take a patch that cherry-picked into mainline from a
development branch, but that partly depended on some support-feature that
wasn't in mainline yet. So then there is another patch that removes part
of that patch from mainline. So mainline is fine.
Now, three months later, the development branch is stable, and is fully
merged. What happens?
Git will largely get this right. Git will look at the last *global* common
base, and will just look at the contents, and do a reasonable job. Yes,
there will probably be conflicts (because both the development branch and
the mainline ended up touching the same parts of the files thanks to the
cherry-pick, and yet mainline has some added hacks on top to disable it),
but on the whole that's exactly what you want!
(Alternatively, maybe the "remove the part that wasn't supported yet"
ended up meaning that that particular part of the patch was excised
entirely from mainline, and there was no conflict at all, and git just
merged the new stuff from the development branch cleanly! So I'm not
saying that it *has* to conflict, I'm just saying that it might have).
In other words: git always "does the right thing". Assuming both branches
are stable and working, git does a very reasonable thing. It's obviously
not always the thing people may *want*, but it's guaranteed to be a
reasonable and simple guess, and there's no way it's "too clever for its
own good, and just screwed the pooch entirely".
In contrast, your suggested merge strategy would be HORRIBLY BROKEN!
Why? Because it doesn't look at the *common* history to the project, it
looks at some per-file state that is totally bogus and has no relevance.
Think it through: what happens if there were files with the same content
(because of the cherry-pick), and then the file history for one of the
branches was later changed to disable something because the support for it
wasn't in the "whole history"?
Right: the final merge will contain that change! Because there as a time
where the file was identical (the cherry-pick), so you're taking all the
later changes to that file (the undo)!
Notice? Totally the wrong thing to do!
So this is a classic case of trying to make "easier" merges, but where the
whole approach is totally broken! You simply MUST NOT add logic like that.
It's a lot better to give a conflict, than to try to be "clever", and
silently do the wrong thing.
Yes, you can be really stupid, and silently do the wrong thing too, but if
you're stupid, at least the "silent wrong thing" is never really subtle,
it's pretty much guaranteed to easily explainable. And the good news is
that you didn't have a complicated and fragile algorithm just to get the
wrong answer.
(Put another way: if you are always going to have situations where you get
the wrong answer, you'd better take the simple and stupid algorithm,
because people are more likely to then be able to _predict_ that wrong
answer and are thus more ready to handle it!)
So being clever really is the wrong thing to do. And using history that
isn't global and true history (ie just looking at one file, and deciding
that matching that one file "means" something) is fundamnetally broken.
In fact, in general, individual pieces of history are totally worthless.
The fact that some individual change was done in one branch doesn't really
tell you *anything*. The reason that change was done may be implied by all
the previous changes, or conversely, later changes may have undone the
change, so any merge algorithm that starts to look at individual commits
is likely to be pure and utter crap - exactly because it's starting to
make decisions based on local information that may not be valid in the big
picture.
(Where the "big picture" may be either about "space" - other files - or
about "time" - other commits, that simply mean that the individual changes
of one commit are meaningless on their own).
Btw, one thing to note is how well the simple and stupid git merge
strategy works. It turns out that doing things with the "big picture"
model actually does work really well. People think that they need
"finegrained history" to make good merges, but I think most people who
have actually done a fair number of merges with git have noticed that it's
actually pretty dang painless.
But to be honest, there are cases where git isn't being very helpful. In
particular, I think there *are* things that git could probably be more
helpful with, but looking at local history is not one of them, I think.
So here are some suggestions on things I think we could improve on:
- I think it would be wonderful to have a helper tool for handling
conflicts.
In particular, while I don't think per-file history is good for
resolving conflicts *automatically*, I actually do think that per-file
history can be a good way to *manually* resolve conflicts.
In other words, it you have a conflict, I think it would be wonderful
to have some git-gui-like thing that can show the history (with
patches) for that file, and basically combine a three-way graphical
merge *with* some per-commit information where you can say "choose the
thing that that commit did for this conflict".
So I think git already has tools to help resolve conflicts, and I
personally love doing "gitk --merge" or "git log -p --merge" when a
conflict does happen, but I think some smart GUI person could do
something even much better!
And notice how I think that it's *really* wrong to use per-file history
automatically, but that I think it's not wrong at all to use it when
there's a human that says "ok, obviously pick that case". Things that
are horrible when they cause subtle and automatic resolves can be very
good when they cause subtle resolves that a human looked at!
- I suspect we have issues with common whitespace changes, where we again
could probably help people resolve whitespace changes etc better.
Again, I don't think those are necessarily things you want to do
automatically, but I know from personal experience that handling things
like one side having done a re-indent can be *really* annoying, just
because you end up doing tons of mindless stuff when you fix up all the
totally idiotic and usually trivial conflicts.
.. and I'm sure there are other things we could do better too, but the
above two are things that while they haven't happened for me for the
kernel (probably because we have learnt how to not cause them over the
years), I've seen them in other places.
And yes, the above two suggestions fall solidly in the "conflicts aren't
bad per se, but you want to make the tool really help you resolve them!"
camp.
Linus
^ permalink raw reply
* [PATCH] fix contrib/hooks/post-receive-email hooks.recipients error message
From: Jeff Muizelaar @ 2007-10-11 21:49 UTC (permalink / raw)
To: git; +Cc: Andy Parkins
Have the error message for missing recipients actually report the
missing config variable and not a fictional one.
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index cbbd02f..b188aa3 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -138,7 +138,15 @@ generate_email()
# Check if we've got anyone to send to
if [ -z "$recipients" ]; then
- echo >&2 "*** hooks.recipients is not set so no email will be sent"
+ case "$refname_type" in
+ "annotated tag")
+ config_name="hooks.announcelist"
+ ;;
+ *)
+ config_name="hooks.mailinglist"
+ ;;
+ esac
+ echo >&2 "*** $config_name is not set so no email will be sent"
echo >&2 "*** for $refname update $oldrev->$newrev"
exit 0
fi
^ permalink raw reply related
* [PATCH] add simple install replacement
From: Robert Schiele @ 2007-10-11 21:52 UTC (permalink / raw)
To: git; +Cc: gitster
This patch adds a very simple install replacement script to git.
This allows more easy installation on systems that don't have a
compatible install.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
---
gitinstall | 35 +++++++++++++++++++++++++++++++++++
1 files changed, 35 insertions(+), 0 deletions(-)
create mode 100755 gitinstall
diff --git a/gitinstall b/gitinstall
new file mode 100755
index 0000000..8b346d6
--- /dev/null
+++ b/gitinstall
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+MKDIRMODE=0
+MODE=755
+while getopts 'dm:' FLAG; do
+ case "$FLAG" in
+ d) MKDIRMODE=1;;
+ m) MODE="$OPTARG";;
+ *) exit 1;;
+ esac
+done
+if test "$OPTIND" != 1; then
+ shift `expr $OPTIND - 1`
+fi
+if test $MKDIRMODE = 1; then
+ mkdir -p "$@"
+ chmod "$MODE" "$@"
+else
+ if test $# = 2 && ! test -d "$2"; then
+ rm -rf "$2"
+ cp "$1" "$2"
+ chmod "$MODE" "$2"
+ else
+ FILES=
+ while test $# != 1; do
+ FILES="$FILES $1"
+ shift
+ done
+ for i in $FILES; do
+ rm -rf "$1/"`basename "$i"`
+ cp "$i" "$1"
+ chmod "$MODE" "$1/"`basename "$i"`
+ done
+ fi
+fi
--
1.5.2.4
^ permalink raw reply related
* snapshot @ git.kernel.org
From: g00fi/goofy_ @ 2007-10-11 21:51 UTC (permalink / raw)
To: git
Hi there,
is it possible that the snapshot function on git.kernel.org is broken?
In every tree I tried, the downloaded file is only ~200 byte.
Or did I misunderstand the snapshot-link?
rgds,
G.Harasek
^ permalink raw reply
* Re: inexplicable failure to merge recursively across cherry-picks
From: Sam Vilain @ 2007-10-11 21:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: martin f krafft, git discussion list
In-Reply-To: <alpine.LFD.0.999.0710100808150.3838@woody.linux-foundation.org>
Linus Torvalds wrote:
> So git doesn't try to avoid conflicts per se: the merge strategies are
> fundamentally pretty simple (rename detection and the whole "recursive
> merge" thing may not be simple code, but the concepts are pretty
> straightforward), and they handle all the really *obvious* cases, but at
> the same time, I feel strongly that anything even half-way subtle should
> not be left to the SCM - the SCM should show it and make it really easy
> for the user to then fix it up.
This is true. However I think there are some obvious places for
improvement that does look at the file history, when the regular
algorithm fails;
1. do a --cherry-pick rev-list on just the file being merged and see if
all the changes on one side disappear, in which case just take the result.
2. see if the files were identical at some point, in which case use a
new merge base for that file based on the changes since that revision.
I actually thought #2 was already the way recursive worked!
Sam.
^ permalink raw reply
* Re: Split a subversion repo into several git repos
From: Sam Vilain @ 2007-10-11 21:40 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Eivind LM, git
In-Reply-To: <27DDC599-C7A0-4660-B5C6-7DFCEB137C14@steelskies.com>
Jonathan del Strother wrote:
>> For example, I want to convert one subversion repository which
>> contains the folders:
>> trunk/projectA
>> trunk/projectB
>>
>> into two git repositories:
>> projectA.git
>> projectB.git
>
> I have a slightly different layout to you -
>
> projectA/trunk
> projectA/branches
> projectA/tags
> projectB/trunk
> projectB/branches
> projectB/tags
> etc
>
> - but I've been creating separate git repos from that with (for
> example) :
>
> git-svn init -t tags -b branches -T trunk http://svn.host.com/projectA
> git-svn fetch
>
>
> Or will git-svn not work with your sort of layout?
It does work. Use:
git-svn init -t projectA/tags -b projectA/branches \
-T trunk/projectA http://svn.host.com/
git fetch
Also you can expect the import results of each branch to be the same
regardless of whether you import all at once using a command like the
above, or import a single path without passing -t / -b / -T to git svn init.
If you have a lot of projects to mine from a single repository, use
svnsync or SVN::Mirror/svk and then import from the local repository
with --use-svm-props.
Sam.
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: David Kastrup @ 2007-10-11 21:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jonathan del Strother, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0710112227000.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 11 Oct 2007, Jonathan del Strother wrote:
>
>> On 11 Oct 2007, at 21:53, David Kastrup wrote:
>>
>> > Johannes Sixt <j.sixt@viscovery.net> writes:
>> >
>> > > Jonathan del Strother schrieb:
>> > > > How are you going to test that git works on paths with spaces if the
>> > > > test suite doesn't run there?
>> > >
>> > > By writing a specific test?
>> >
>> > This is going to be much less thorough. And it does no harm if the
>> > test scripts demonstrate defensive programming.
>
> We do not have _extensive_ tests. We want to do some coding in
> addition to waiting for our machines to finish the test. D'oh.
A good reason for not requiring special tests just for spaces.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: RCS keyword expansion
From: Sam Vilain @ 2007-10-11 21:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Oliver Kullmann, git
In-Reply-To: <Pine.LNX.4.64.0710112144380.4174@racer.site>
Johannes Schindelin wrote:
> The problem is this: for efficiency, git does not change files which have
> not changes between the last version checked out (whatever that is) and
> the current version.
>
> This seems counterintuitive to people coming from SVN/CVS: they expect
> _every_ file to be touched when checking out.
Well, that's not entirely true. SVN for one doesn't change the keywords
on files that haven't changed. You can't have a keyword that expands to
the current head revision, for instance.
SVN's answer to the problem of how this works with merging is largely
arbitrary; if you are merging changes in, the $Id$ becomes expanded to
the merge that affected that path, not the change that introduced this
version of the file.
Sam.
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Johannes Schindelin @ 2007-10-11 21:31 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <63D5CE5B-51DD-4017-B2E2-2ADC5DCBE849@steelskies.com>
Hi,
On Thu, 11 Oct 2007, Jonathan del Strother wrote:
> On 11 Oct 2007, at 21:53, David Kastrup wrote:
>
> > Johannes Sixt <j.sixt@viscovery.net> writes:
> >
> > > Jonathan del Strother schrieb:
> > > > How are you going to test that git works on paths with spaces if the
> > > > test suite doesn't run there?
> > >
> > > By writing a specific test?
> >
> > This is going to be much less thorough. And it does no harm if the
> > test scripts demonstrate defensive programming.
We do not have _extensive_ tests. We want to do some coding in addition
to waiting for our machines to finish the test. D'oh.
> I would also point out that most tests have already been written to
> handle this case - ones that don't quote their paths are in the
> minority.
That might very well be the case, and your goal is laudable. However, I
have to agree that most devs (indeed, since you are the first to try to
fix it, _all_ except for you) do not care that deeply about spaces in the
path, and having a _single_ test for this would be the logical solution.
I mean, we do not force our main developers to run the most obscure setups
all the time just to make sure that it runs fine. Otherwise none of us
could run Linux, but a couple would be coerced into running Windows, for
example.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: Jonathan del Strother @ 2007-10-11 21:22 UTC (permalink / raw)
To: David Kastrup; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <85k5pts796.fsf@lola.goethe.zz>
On 11 Oct 2007, at 21:53, David Kastrup wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Jonathan del Strother schrieb:
>>> How are you going to test that git works on paths with spaces if the
>>> test suite doesn't run there?
>>
>> By writing a specific test?
>
> This is going to be much less thorough. And it does no harm if the
> test scripts demonstrate defensive programming.
I would also point out that most tests have already been written to
handle this case - ones that don't quote their paths are in the
minority.
^ permalink raw reply
* Re: RCS keyword expansion
From: Sam Vilain @ 2007-10-11 21:20 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0710111953460.7441@perkele.intern.softwolves.pp.se>
Peter Karlsson wrote:
> Randal L. Schwartz:
>
>> That's not a job for a source code manager to do. It's a job for your
>> build/install tool.
>
> Since there is no build step involved (my web site is just a CVS checkout at
> the moment), it's a job for the checkout step. I'd really want to avoid
> having a separate copy of the web site just so that I can do a "make
> install". That would sort of negate the savings in disk space I hope seeing
> by moving from CVS to Git.
The problem is that asking for the "last commit that changed a file" is
one of those features which comes out of the wash with proper merge
support. There is often no clear answer to that question.
Here's an example. Say two people apply a patch on their own branches,
which are subsequently merged. The file was the same on both branches;
the commits may have exactly the same date, but different committers.
Now, consider what happens as you are switching branches. Instead of
just being able to check the file identity in the tree, the system has
to somehow know that the (derived) ancestry of the file is different,
and now the content has to change. That makes something that was
extremely fast, slow.
It's the sort of thing that's possible to arrange to work using hooks
(with whatever arbitrary decisions you choose to make for the areas
where it would be ambiguous), but no-one bothered because people
realised that it probably means you're trying to encapsulate the
information in the wrong place.
Sam.
^ permalink raw reply
* Re: [PATCH] cvsserver: added support for update -p
From: Frank Lichtenheld @ 2007-10-11 21:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio C Hamano, Jan Wielemaker
In-Reply-To: <Pine.LNX.4.64.0710112158330.4174@racer.site>
On Thu, Oct 11, 2007 at 09:59:28PM +0100, Johannes Schindelin wrote:
> On Thu, 11 Oct 2007, Frank Lichtenheld wrote:
>
> > + if ( exists ( $state->{opt}{p} ) )
>
> I see you kept the coding style, which is not in agreement with the rest
> of git... Intention or oversight?
It is in agreement with the rest of git-cvsserver. I really like the
style of the other perl stuff in git better, but I wasn't sure what
style takes precedence...
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] cvsserver: added support for update -p
From: Johannes Schindelin @ 2007-10-11 20:59 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Git Mailing List, Junio C Hamano, Jan Wielemaker
In-Reply-To: <1192120573-16765-1-git-send-email-frank@lichtenheld.de>
Hi,
On Thu, 11 Oct 2007, Frank Lichtenheld wrote:
> + if ( exists ( $state->{opt}{p} ) )
I see you kept the coding style, which is not in agreement with the rest
of git... Intention or oversight?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fixing path quoting issues
From: David Kastrup @ 2007-10-11 20:53 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jonathan del Strother, git, Junio C Hamano
In-Reply-To: <470DD3B8.1080809@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Jonathan del Strother schrieb:
>> How are you going to test that git works on paths with spaces if the
>> test suite doesn't run there?
>
> By writing a specific test?
This is going to be much less thorough. And it does no harm if the
test scripts demonstrate defensive programming.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: RCS keyword expansion
From: Johannes Schindelin @ 2007-10-11 20:47 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20071011155956.GC11693@cs-wsok.swansea.ac.uk>
Hi,
On Thu, 11 Oct 2007, Oliver Kullmann wrote:
> On Thu, Oct 11, 2007 at 08:09:22AM -0700, Randal L. Schwartz wrote:
> > >>>>> "Peter" == Peter Karlsson <peter@softwolves.pp.se> writes:
> >
> > Peter> I mainly want to have $Date$ expand in RCS/CVS manner, i.e to when the
> > Peter> file was last changed. Possibly even have an $Id$ that gives me
> > Peter> something useful (name and commit hash, perhaps?). Is it possible to do
> > Peter> this? Can it be done through git-cvsserver?
> >
> > That's not a job for a source code manager to do. It's a job for your
> > build/install tool. See how "git --version" gets created in the core distro,
> > and follow that example.
> >
>
> This looks like a misunderstanding of what $Date$ is used for: It has
> not much to do with a version number (such things are decisions by the
> developers), but it is an identification stamp, typically used to
> identify exactly which piece of code is involved in a given executable.
It does not matter if it is a date or a version number.
The problem is this: for efficiency, git does not change files which have
not changes between the last version checked out (whatever that is) and
the current version.
This seems counterintuitive to people coming from SVN/CVS: they expect
_every_ file to be touched when checking out.
So there is not much we will do to accomodate in git; touching files which
have not changed at all (even if containing a $Id$ or a $Date$) is not the
way we want it...
As Randal already suggested: if you need something like this, you better
have a build procedure which replaced $Date$ _at a given time_ (make
install) with the current date.
Ciao,
Dscho
^ permalink raw reply
* Re: [StGit PATCH 09/13] Clear up the semantics of Series.new_patch
From: Catalin Marinas @ 2007-10-11 20:42 UTC (permalink / raw)
To: David Kågedal; +Cc: Karl Hasselström, git
In-Reply-To: <87prznxvmq.fsf@lysator.liu.se>
On 10/10/2007, David Kågedal <davidk@lysator.liu.se> wrote:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
> > On 08/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> >> Couldn't "stg pick --reverse" create a new commit and use that? That
> >> is, given that we want to revert commit C, create a new commit C* with
> >
> > Series.new_patch already creates a commit, why should we move the
> > functionality to 'pick'? The only call to new_patch with commit=False
> > seems to be from 'uncommit' (and it makes sense indeed).
>
> It might be true that the assertion could be amended so that if
> commit=True, then it is allowed to have top/bottom that doesn't
> correspond to a commit and its parent.
I'll fix this and add a test for pick --reverse.
--
Catalin
^ permalink raw reply
* Re: yet another workflow question...
From: Jing Xue @ 2007-10-11 20:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Patrick Doyle
In-Reply-To: <200710111610.55364.andyparkins@gmail.com>
Quoting Andy Parkins <andyparkins@gmail.com>:
> - Mobility. This one is a bit distributed, but I hope you'll let
> me have it.
> I often do work on my desktop at home, my desktop at work and my laptop.
> By setting my remotes up correctly in git it's really easy to walk to
> another system and pick up exactly where I left off from the other
> computer. More importantly though, when you accidentally make changes in
> two places, there is no danger of data loss.
To extend on this point, after picking up the randomly checked-in save
point on another computer, the save point itself can be easily
git-reset'ed. So there won't be commits like "it's utter broken but i
got to go home" polluting the history. I find that extremely handy.
Cheers.
--
Jing Xue
^ permalink raw reply
* Re: Status of kha/experimental
From: Catalin Marinas @ 2007-10-11 20:38 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, David Kågedal, Git Mailing List
In-Reply-To: <20071010082602.GF12970@diana.vm.bytemark.co.uk>
On 10/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-10-09 23:46:13 +0200, Yann Dirson wrote:
> > The best situation would be that there would be a code freeze at
> > some time, during which I could update those patches without too
> > much perturbations, but that may be asking a lot :)
>
> There aren't that many of us working on StGit. If you can give a
> reasonably accurate start date and duration of the freeze,
This would mean that I have to be more organised :-).
> I don't
> think it would be a problem.Others would simply have to be aware that
> any patches not merged before the freeze would have to be rebased on
> top of your work once the freeze is over.
I'll try - let's say we freeze it starting with the coming Monday
(what's currently in kha/safe will be merged anyway) and aim to
release 0.14 in about 3 weeks (or as soon as we fix the major bugs).
--
Catalin
^ 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