* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Matthias Urlichs @ 2005-07-28 7:45 UTC (permalink / raw)
To: git
In-Reply-To: <7v64uvh0mo.fsf@assigned-by-dhcp.cox.net>
Hi, Junio C Hamano wrote:
> The Debian build is not affected because it does not produce
> separate git-core and doc-git-core packages[*1*]; probably this
> was the reason you did not notice this.
git-core-doc, actually.
Debian does that only if the documentation is substantial. Even then,
manpages may not be segregated into -doc.
However, I *would* segregate gitk into its own Debian package, because
it requires wish et al., which would pull a large chunk of X11 stuff,
which people may not want on their server.
Patch follows separately -- I'll have to pull it from my other mess
(which includes yet another Debian package for Cogito ;-).
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
A zealot's stones will break my bones, but gods will never hurt me.
^ permalink raw reply
* Re: Handover, Make
From: Petr Baudis @ 2005-07-28 7:54 UTC (permalink / raw)
To: Brian O'Mahoney; +Cc: git
In-Reply-To: <42E813D3.7020804@khandalf.com>
Dear diary, on Thu, Jul 28, 2005 at 01:08:03AM CEST, I got a letter
where Brian O'Mahoney <omb@khandalf.com> told me that...
> First, congratulations Junio, on taking over this stuff, and all the best.
>
> Second, the killer argument, in the 'Recursive Make ... harmful' is the
> basic one that Recursive Makes breaks up the dependancy graph, and
> almost guarentees that it is wrong unless you do a lot of work to fix
> that artifact. Now git is small enough that make clean; make won't take
> too long
I think there are basically none dependencies like this, or if they are
any, they virtually never break under regular usage. At least I never do
make clean and I never saw a rebuild of git to break.
I think especially for smaller projects recursive make is just fine and
makes maintenance easier, and I think most of the arguments about the
dependency graph rarely matter in real projects (especially ones of the
size of git). So I'd say, keep it as it is till we can. :-)
> but git is also a basis for other layers, so there is good
> reason to try to get it right.
For what layers?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Petr Baudis @ 2005-07-28 7:51 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, Ryan Anderson, git
In-Reply-To: <42E8058B.7070907@gmail.com>
Dear diary, on Thu, Jul 28, 2005 at 12:07:07AM CEST, I got a letter
where A Large Angry SCM <gitzilla@gmail.com> told me that...
> Junio C Hamano wrote:
> >While I do not have strong objections to make the build process
> >go faster, it is somewhat disturbing that the Makefile pieces
> >maintained in subdirectories need to name things they touch
> >using paths that include the subdirectory names. I do not have
> >a better alternative to suggest, though...
>
> For a project the size of Git, is there any real benefit to this change?
>
> Besides pathing issues, you also have to aware that all identifiers in
> the included makefile fragments will be global.
>
> I don't object to the change but I see it as trading one maintenance
> issue for another.
I'd also argue that generally, larger files are inherently harder to
maintain, and having all the targets for all the subdirectories in a
single file sounds nightmarish. (OTOH, by now you probably know that I'm
a keep-it-as-local-as-possible junkie.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Matthias Urlichs @ 2005-07-28 9:40 UTC (permalink / raw)
To: git
In-Reply-To: <20050728075115.GB18907@pasky.ji.cz>
Hi, Petr Baudis wrote:
> having all the targets for all the subdirectories in a
> single file sounds nightmarish
which is why you'd include Makefile[.inc] snippets from subdirectories
instead.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
The only difference between a fool and a criminal who attacks a system is
that the fool attacks unpredictably and on a broader front.
-- Tom Gibb
^ permalink raw reply
* [PATCH] stgit: Handle 'A' flag for new files
From: Peter Osterlund @ 2005-07-28 11:55 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Hi,
Patches that add new files don't work correctly if git reports them
with the 'A' flag. StGIT claims there are unresolved conflicts. This
patch fixes it.
Signed-off-by: Peter Osterlund <petero2@telia.com>
diff --git a/stgit/git.py b/stgit/git.py
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -274,7 +274,7 @@ def commit(message, files = [], parents
raise GitException, 'No changes to commit'
# check for unresolved conflicts
- if not first and len(filter(lambda x: x[0] not in ['M', 'N', 'D'],
+ if not first and len(filter(lambda x: x[0] not in ['M', 'N', 'A', 'D'],
cache_files)) != 0:
raise GitException, 'Commit failed: unresolved conflicts'
--
Peter Osterlund - petero2@telia.com
http://web.telia.com/~u89404340
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-28 12:08 UTC (permalink / raw)
To: Josef Weidendorfer, Junio C Hamano; +Cc: git
In-Reply-To: <200507271458.43063.Josef.Weidendorfer@gmx.de>
Dear diary, on Wed, Jul 27, 2005 at 02:58:42PM CEST, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> told me that...
> Hi,
Hello,
> if I clone a remote head other than master via Cogito with
>
> cg-clone host:path#remoteHead,
>
> work on this branch, and try to push back my changes with
>
> cg-push,
>
> I get the error
>
> "pushing to a different head not supported yet".
>
> As far as I can see, there is no support in core GIT to make this ever work
> (at least with get-send-packs), as "git-send-pack" only updates a set of
> heads with the same name both locally and remote.
Yes. It sucks. :-)
> I suppose the best would be to always keep the same head names in cloned
> repositories - it seems to be easier to handle for users. Perhaps the only
> exception would be "master", as one probably would like to pull masters of
> different remote repositories into a local one (without really working on
> them).
I think that would be quite confusing. I mean, you added a remote "bar"
branch under name "foo" by cg-branch-add, but suddenly, branch "bar"
appears as well. Worse if you already have a different branch "bar".
> Thus, what about the following: Each time a remote head other than master is
> cloned, a head with the same name is created locally which is an alias to the
> local master. This way, cg-push almost works out of the box. Following patch
> implements this behavior.
See above. I would much rather see more flexible git-send-pack. Junio,
what about changing its [heads]* parameter e.g. to
[remotehead[:localhead]]* ?
Dear diary, on Thu, Jul 28, 2005 at 03:32:01AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
>
> > As far as I can see, there is no support in core GIT to make this ever work
> > (at least with get-send-packs), as "git-send-pack" only updates a set of
> > heads with the same name both locally and remote.
>
> Yes, it is my understanding that "clone" means to literally
> clone, not "pull into an empty repository with renamed head
> names", to the core GIT. I do not speak for Pasky, but Cogito's
> "clone" seems to have a bit different semantics (which I suspect
> is more friendly to the users in many situations).
cg-clone serves only for initializing the repository from a remote
source initially.
> Similarly, "push" to the core GIT (that is what git-send-pack is
> about) means performing a subset of "clone" in reverse. This is
> primarily to synchronise two repositories owned by a single
> person.
cg-push aims to serve as a general pushing mechanism, which should work
properly even if multiple people push to a single repository.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH] stgit: Handle 'A' flag for new files
From: Catalin Marinas @ 2005-07-28 12:20 UTC (permalink / raw)
To: Peter Osterlund; +Cc: git
In-Reply-To: <m3d5p3kuv1.fsf@telia.com>
Peter Osterlund <petero2@telia.com> wrote:
> Patches that add new files don't work correctly if git reports them
> with the 'A' flag. StGIT claims there are unresolved conflicts. This
> patch fixes it.
Thanks. Applied (together with the one below).
diff --git a/stgit/git.py b/stgit/git.py
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -292,7 +292,7 @@ def commit(message, files = [], parents
rm_files=[]
m_files=[]
for f in cache_files:
- if f[0] == 'N':
+ if f[0] in ['N', 'A']:
add_files.append(f[1])
elif f[0] == 'D':
rm_files.append(f[1])
@@ -437,7 +437,8 @@ def checkout(files = [], force = False):
def switch(tree_id):
"""Switch the tree to the given id
"""
- to_delete = filter(lambda x: x[0] == 'N', __tree_status(tree_id = tree_id))+ to_delete = filter(lambda x: x[0] in ['N', 'A'],
+ __tree_status(tree_id = tree_id))
if __run('git-read-tree -m', [tree_id]) != 0:
raise GitException, 'Failed git-read-tree -m %s' % tree_id
--
Catalin
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-07-28 13:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Josef Weidendorfer, Junio C Hamano, git
In-Reply-To: <20050728120806.GA2391@pasky.ji.cz>
Hi,
On Thu, 28 Jul 2005, Petr Baudis wrote:
> See above. I would much rather see more flexible git-send-pack. Junio,
> what about changing its [heads]* parameter e.g. to
> [remotehead[:localhead]]* ?
IMHO this opens the door for shooting in your own foot. Isn't it much too
easy to make a mistake with that syntax? What is so wrong with git-clone
not allowing you to name the HEAD differently?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] add "-f" option to git-commit-script to force commit withoutchanges
From: Johannes Schindelin @ 2005-07-28 14:47 UTC (permalink / raw)
To: git
Sometimes a failed automatic merge means that we do not want those
changes. In this case, it is desirable to commit the current HEAD (as if
actually something was merged).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-commit-script | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
89e6c9495d7877e9922b22d6c87f51c6902b7056
diff --git a/git-commit-script b/git-commit-script
--- a/git-commit-script
+++ b/git-commit-script
@@ -6,12 +6,16 @@
. git-sh-setup-script || die "Not a git archive"
usage () {
- die 'git commit [-m existing-commit] [<path>...]'
+ die 'git commit [-f] [-m existing-commit] [<path>...]'
}
+force=false
while case "$#" in 0) break ;; esac
do
case "$1" in
+ -f) shift
+ force=true
+ ;;
-m) shift
case "$#" in
0) usage ;;
@@ -82,7 +86,7 @@ else
fi >.editmsg
git-status-script >>.editmsg
fi
-if [ "$?" != "0" ]
+if [ "$?" != "0" -a $force = false ]
then
cat .editmsg
rm .editmsg
^ permalink raw reply
* [PATCH] remove "-r" option to xargs
From: Johannes Schindelin @ 2005-07-28 14:48 UTC (permalink / raw)
To: git
git-prune-script still contained that non-portable option.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-prune-script | 2 +-
1 files changed, 1 insertion, 1 deletion
diff --git a/git-prune-script b/git-prune-script
--- a/git-prune-script
+++ b/git-prune-script
@@ -20,6 +20,6 @@ sed -ne '/unreachable /{
s|\(..\)|\1/|p
}' | {
cd "$GIT_OBJECT_DIRECTORY" || exit
- xargs -r $dryrun rm -f
+ xargs $dryrun rm -f
}
^ permalink raw reply
* [PATCH] support older versions of libcurl
From: Johannes Schindelin @ 2005-07-28 14:49 UTC (permalink / raw)
To: git
Some newer features of libcurl are used which are not strictly necessary
for http-pull. Use them only if libcurl is new enough to know about them.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
http-pull.c | 6 ++++++
1 files changed, 6 insertions
diff --git a/http-pull.c b/http-pull.c
--- a/http-pull.c
+++ b/http-pull.c
@@ -171,19 +171,25 @@ int main(int argc, char **argv)
commit_id = argv[arg];
url = argv[arg + 1];
+#if LIBCURL_VERSION_NUM >= 0x070800
curl_global_init(CURL_GLOBAL_ALL);
+#endif
curl = curl_easy_init();
curl_ssl_verify = gitenv("GIT_SSL_NO_VERIFY") ? 0 : 1;
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, curl_ssl_verify);
+#if LIBCURL_VERSION_NUM >= 0x070907
curl_easy_setopt(curl, CURLOPT_NETRC, CURL_NETRC_OPTIONAL);
+#endif
base = url;
if (pull(commit_id))
return 1;
+#if LIBCURL_VERSION_NUM >= 0x070704
curl_global_cleanup();
+#endif
return 0;
}
^ permalink raw reply
* [PATCH] support bc version 1.04
From: Johannes Schindelin @ 2005-07-28 14:48 UTC (permalink / raw)
To: git
Test t6002 unnecessarily fails when bc is a bit older than average.
Signed-off-by: Johannes.Schindelin <Johannes.Schindelin@gmx.de>
---
t/t6002-rev-list-bisect.sh | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
ccea5a568914eafc07caf0c291afe5f962672cd3
diff --git a/t/t6002-rev-list-bisect.sh b/t/t6002-rev-list-bisect.sh
--- a/t/t6002-rev-list-bisect.sh
+++ b/t/t6002-rev-list-bisect.sh
@@ -11,8 +11,12 @@ bc_expr()
{
bc <<EOF
scale=1
-define abs(x) { if (x>=0) { return x; } else { return -x; } }
-define floor(x) { save=scale; scale=0; result=x/1; scale=save; return result; }
+define abs(x) {
+ if (x>=0) { return (x); } else { return (-x); }
+}
+define floor(x) {
+ save=scale; scale=0; result=x/1; scale=save; return (result);
+}
$*
EOF
}
^ permalink raw reply
* [RFD] socklen_t needs to be defined and libssl to be linked on old Mac OS X
From: Johannes Schindelin @ 2005-07-28 14:51 UTC (permalink / raw)
To: git
On older Mac OS X (10.2.8), no socklen_t is defined, and therefore
daemon.c does not compile. However, Mac OS X 10.4 seems to define
socklen_t differently.
Also, linking fails due to some symbols defined in libssl (not just
libcrypto).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Makefile | 4 ++++
daemon.c | 3 +++
2 files changed, 7 insertions
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -95,7 +95,11 @@ ifdef PPC_SHA1
LIB_OBJS += ppc/sha1.o ppc/sha1ppc.o
else
SHA1_HEADER=<openssl/sha.h>
+ifeq ($(shell uname -s),Darwin)
+ LIBS += -lcrypto -lssl
+else
LIBS += -lcrypto
+endif
endif
endif
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -5,6 +5,9 @@
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
+#ifdef __APPLE__
+typedef int socklen_t;
+#endif
static const char daemon_usage[] = "git-daemon [--inetd | --port=n]";
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-28 15:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Josef Weidendorfer, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0507281504100.25402@wgmdd8.biozentrum.uni-wuerzburg.de>
Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> Hi,
Hello,
> On Thu, 28 Jul 2005, Petr Baudis wrote:
>
> > See above. I would much rather see more flexible git-send-pack. Junio,
> > what about changing its [heads]* parameter e.g. to
> > [remotehead[:localhead]]* ?
>
> IMHO this opens the door for shooting in your own foot. Isn't it much too
> easy to make a mistake with that syntax?
What mistake?
> What is so wrong with git-clone not allowing you to name the HEAD
> differently?
Did you read the preceding discussion? When you are pushing from your
master branch to a remote branch, it may well be called different over
there.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-28 15:35 UTC (permalink / raw)
To: Josef Weidendorfer, Junio C Hamano; +Cc: git
In-Reply-To: <20050728120806.GA2391@pasky.ji.cz>
Dear diary, on Thu, Jul 28, 2005 at 02:08:07PM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> told me that...
> See above. I would much rather see more flexible git-send-pack. Junio,
> what about changing its [heads]* parameter e.g. to
> [remotehead[:localhead]]* ?
Ok, I was thinking backwards about it. I meant
[localhead[:remotehead]]*, sorry. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Petr Baudis @ 2005-07-28 15:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Catalin Marinas, Linus Torvalds, git, Marco Costalba
In-Reply-To: <7vd5p73jlu.fsf@assigned-by-dhcp.cox.net>
Hello,
after skimming through it, I think I completely like what you have
shown here. I'm only concerned about this:
Dear diary, on Mon, Jul 25, 2005 at 12:49:33AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> $ cat Documentation/.gitignore
> # ignore generated html files,
> # except foo.html which is maintained by hand
> !foo.html
> *.html
I think this is wrong, and my brief experiments confirm that. I think
that the actually useful semantics of exclusion would be for
_subsequent_ exclusions, not preliminary ones. You generally don't say
"I never want this ignored, but I want the rest of that ignored", but
"I want that ignored, except this". This also gives you more
flexibility:
*.html
!f*.html
fo*.html
would ignore *.html and fo*.html, but not any other f*.html filenames.
But more importantly,
.gitignore: *.txt
Documentation/.gitignore: !*.txt
will not work, which was the whole _point_ of the exclusion.
Could we please have this semantics changed for those reasons?
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-07-28 15:56 UTC (permalink / raw)
To: Petr Baudis; +Cc: Josef Weidendorfer, Junio C Hamano, git
In-Reply-To: <20050728153506.GL14229@pasky.ji.cz>
Hi,
On Thu, 28 Jul 2005, Petr Baudis wrote:
> Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
>
> > On Thu, 28 Jul 2005, Petr Baudis wrote:
> >
> > > See above. I would much rather see more flexible git-send-pack. Junio,
> > > what about changing its [heads]* parameter e.g. to
> > > [remotehead[:localhead]]* ?
> >
> > IMHO this opens the door for shooting in your own foot. Isn't it much too
> > easy to make a mistake with that syntax?
>
> What mistake?
To mix up different branches. With that syntax you can easily push changes
onto the wrong head.
I might well be wrong here, but I think the most common usage for git-push
is to update a public repository, which is done by one or just a few
maintainer(s), in which case it is no problem to enforce
localhead=remotehead. BTW, this whole multihead mess applies only to Jeffs
anyway :-)
I just do not see a high demand for mappings of remote and local HEAD
names, but rather a high potential of making mistakes (after all, it is
not the machine which makes mistakes, it's the human operator).
> If you want the holes in your knowledge showing up try teaching
> someone. -- Alan Cox
I like that one.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: Petr Baudis @ 2005-07-28 15:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Catalin Marinas, git, Marco Costalba
In-Reply-To: <7vll3uk4w7.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Jul 25, 2005 at 10:27:36PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Mon, 25 Jul 2005, Junio C Hamano wrote:
> >>
> >> I personally do not have preference either way, but am slightly
> >> biased towards the "cumulative" behaviour the patch attempts to
> >> implement, which was what Pasky said he wanted to have.
> >
> > I think that makes sense.
> >
> > Imagine, for example, that you have separate subdirectory structures for
> > Documentation and for source - maybe you'd put the "*.o" rule in the
> > source directory, and a "*.1" rule in the Docs subdirectory.
>
> I imagined it, but it appears to me that this is a bad example.
> My understanding of what Catalin and the proposed patch
> disagrees is whether the patterns in .gitignore at the top level
> should govern files under ppc/ and mozilla-sha1/ subdirectories;
> Catalin thinks they should not.
They should. If you don't want them take effect in most of the
directories, you would add them as ./pattern in the parent directory,
while if you want them to take effect in most of the directories, you
would exclude them in the ones you don't want the pattern to take effect
in (if you accept my proposal for ! semantics change).
> What I meant by "cumulative" (now I realize I might have
> misunderstood what Pasky wanted to mean by that word, though)
> was not just .gitignore in subdirectory being added, but the
> effect of patterns being added so far, either from the command
> line or by parent directories, last while in the deeper
> directories.
Yes, that's what I meant.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [RFC] extending git-ls-files --exclude.
From: A Large Angry SCM @ 2005-07-28 16:04 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Catalin Marinas, Linus Torvalds, git,
Marco Costalba
In-Reply-To: <20050728155210.GA17952@pasky.ji.cz>
Petr Baudis wrote:
> I think this is wrong, and my brief experiments confirm that. I think
> that the actually useful semantics of exclusion would be for
> _subsequent_ exclusions, not preliminary ones. You generally don't say
> "I never want this ignored, but I want the rest of that ignored", but
> "I want that ignored, except this". This also gives you more
> flexibility:
>
> *.html
> !f*.html
> fo*.html
>
> would ignore *.html and fo*.html, but not any other f*.html filenames.
> But more importantly,
>
> .gitignore: *.txt
> Documentation/.gitignore: !*.txt
>
> will not work, which was the whole _point_ of the exclusion.
So you're arguing for "last match wins" versus "first match wins". I,
personally, find the former more natural and easier to debug by hand.
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-07-28 16:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Josef Weidendorfer, git
In-Reply-To: <20050728153506.GL14229@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Thu, Jul 28, 2005 at 03:07:01PM CEST, I got a letter
> where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
>> IMHO this opens the door for shooting in your own foot. Isn't it much too
>> easy to make a mistake with that syntax?
>
> What mistake?
>
>> What is so wrong with git-clone not allowing you to name the HEAD
>> differently?
>
> Did you read the preceding discussion? When you are pushing from your
> master branch to a remote branch, it may well be called different over
> there.
The real question is why you would even want to do that.
Managing multiple heads and making sure which one is which even
on a single repository is a mental burden, at least to me. When
you can name local and remote differently, the name mappings
also need to be managed in addition to that. Yes, the mappings
can be automated by Porcelains, but that means we need to have
another configuration item around (which needs to be compatible
across Porcelains) to achieve that flexibility, but what does
that flexibility really buys you?
My gut feeling is that Johannes is right here, at least about
the send-pack side. Storing "master" pulled from a remote under
a name different from the remote is a different story. I do not
have much problem with that.
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Petr Baudis @ 2005-07-28 16:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Josef Weidendorfer, git
In-Reply-To: <7vwtnadi1y.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jul 28, 2005 at 06:14:17PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> My gut feeling is that Johannes is right here, at least about
> the send-pack side. Storing "master" pulled from a remote under
> a name different from the remote is a different story. I do not
> have much problem with that.
But that means you already have to manage the mapping anyway, with all
the burden of configuration items etc. And what if repository A has
branch 'foo' and repository B also has branch 'foo'?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: Junio C Hamano @ 2005-07-28 16:38 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.07.28.07.45.31.245357@smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> However, I *would* segregate gitk into its own Debian package, because
> it requires wish et al., which would pull a large chunk of X11 stuff,
> which people may not want on their server.
While I agree gitk should not come as part of git package, this
brings up a different issue.
Ideally, I'd want to see gitk packaged from its repository
kernel.org:/pub/scm/gitk/git.git/ Paul Mackerras maintains, not
from GIT one which _will_ lag behind.
We have a copy of gitk in git repository because Linus "merged"
it as "the coolest merge ever" example. While I intend to keep
updating from gitk repository from time to time only because I
do not want to ship ancient version of it, I see a big problem
down the road. What happens if someday Paul wanted to have a
toplevel Makefile of his own, or if somebody sends him a patch
to add debian/rules file to build a separate gitk package from
its own source tree? Pulling/merging from gitk repo to update
the copy git has suddenly becomes a nightmere.
While I _do_ rely on gitk in my git work, and I _do_ like its
simplicity (just a single file right now), my longer term
preference is to drop the copy we have in git tree and treat it
just like the other repository browser, qgit. Our documentation
should point people at it as part of the Porcelain suite.
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Junio C Hamano @ 2005-07-28 16:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Josef Weidendorfer, git
In-Reply-To: <20050728161815.GC17952@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> AFAIK the plan is to centralize all the kernel repositories to a single
> one. For that, developers would generally push into branches with name
> different that "master".
I did not know about that plan, but that is interesting and now
I understand why you think it is important to be able for more
than one person to push into a single repository.
How will the namespace of N-hundred branches in that repository
be managed? To avoid collisions, wouldn't there be some
coordination, and there will be branch names there that
everybody agrees that they are owned by you?
At that point, wouldn't it be easier for _you_ (as one kernel
developer who owns such globally unique branch names) to name
your branch you intend to push there the same way in your
working repository as well?
^ permalink raw reply
* Re: [PATCH/RFC] "Recursive Make considered harmful"
From: A Large Angry SCM @ 2005-07-28 17:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthias Urlichs, git
In-Reply-To: <7vk6jac2cv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
...
> While I agree gitk should not come as part of git package, this
> brings up a different issue.
>
> Ideally, I'd want to see gitk packaged from its repository
> kernel.org:/pub/scm/gitk/git.git/ Paul Mackerras maintains, not
> from GIT one which _will_ lag behind.
>
...
>
> While I _do_ rely on gitk in my git work, and I _do_ like its
> simplicity (just a single file right now), my longer term
> preference is to drop the copy we have in git tree and treat it
> just like the other repository browser, qgit. Our documentation
> should point people at it as part of the Porcelain suite.
Then this should happen sooner rather than later.
^ permalink raw reply
* Re: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
From: Johannes Schindelin @ 2005-07-28 17:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Josef Weidendorfer, git
In-Reply-To: <7v1x5ic1pe.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 28 Jul 2005, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > AFAIK the plan is to centralize all the kernel repositories to a single
> > one. For that, developers would generally push into branches with name
> > different that "master".
>
> I did not know about that plan, but that is interesting and now
> I understand why you think it is important to be able for more
> than one person to push into a single repository.
Is it possible that those plans only mean to centralize .git/objects/ and
leave the rest in single repositories? Seems much more sensible to me.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox