* Re: Hackontest ideas?
From: Shawn O. Pearce @ 2008-07-29 5:31 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Petr Baudis, git
In-Reply-To: <20080729001016.GT32057@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis <pasky@ucw.cz> wrote:
> >
> > (What feature in Git or a Git-related tool would you implement, given 24
> > hours staight and unlimited pizza supply?)
>
> Restartable git-clone? :-)
>
> It was a GSoC idea this year, but in the end nobody started working on
> it.
>
> (I was about to work on it, but finally my 'builtin-merge' application
> was accepted.)
Yea, we eventually decided it was probably too small for a
GSoC project. Given how quickly you put together your git-merge
project, I'm actually happy we got you working on git-merge and
not restartable clone, as I think you may have finished restartable
clone in 24 hours and then said "now what mr. mentor?" ;-)
Pasky, et.al.:
How about smart fetch/push over HTTP? E.g. a CGI (or extension to
gitweb) that does native pack transport over HTTP rather than dumb
object traversal with GET and WebDAV LOCK/PUT. Note that the push
side doesn't need to support tell-me-more extension, making it a
fairly trivial GET, POST (or PUT) sequence.
--
Shawn.
^ permalink raw reply
* [PATCH] merge-base: die with an error message if not passed a commit ref
From: Christian Couder @ 2008-07-29 5:42 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin; +Cc: Miklos Vajna, Jakub Narebski
Before this patch "git merge-base" just exited with error code 1
and without an error message in case it was passed a ref to an
object that is not a commit (for example a tree).
This patch makes it "die" in this case with an error message.
While at it, this patch also refactors the code to get the
commit reference from an argument into a new
"get_commit_reference" function.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-merge-base.c | 26 +++++++++++++++++---------
1 files changed, 17 insertions(+), 9 deletions(-)
diff --git a/builtin-merge-base.c b/builtin-merge-base.c
index 1cb2925..3382b13 100644
--- a/builtin-merge-base.c
+++ b/builtin-merge-base.c
@@ -22,10 +22,23 @@ static int show_merge_base(struct commit *rev1, struct commit *rev2, int show_al
static const char merge_base_usage[] =
"git merge-base [--all] <commit-id> <commit-id>";
+static struct commit *get_commit_reference(const char *arg)
+{
+ unsigned char revkey[20];
+ struct commit *r;
+
+ if (get_sha1(arg, revkey))
+ die("Not a valid object name %s", arg);
+ r = lookup_commit_reference(revkey);
+ if (!r)
+ die("Not a valid commit name %s", arg);
+
+ return r;
+}
+
int cmd_merge_base(int argc, const char **argv, const char *prefix)
{
struct commit *rev1, *rev2;
- unsigned char rev1key[20], rev2key[20];
int show_all = 0;
git_config(git_default_config, NULL);
@@ -40,13 +53,8 @@ int cmd_merge_base(int argc, const char **argv, const char *prefix)
}
if (argc != 3)
usage(merge_base_usage);
- if (get_sha1(argv[1], rev1key))
- die("Not a valid object name %s", argv[1]);
- if (get_sha1(argv[2], rev2key))
- die("Not a valid object name %s", argv[2]);
- rev1 = lookup_commit_reference(rev1key);
- rev2 = lookup_commit_reference(rev2key);
- if (!rev1 || !rev2)
- return 1;
+ rev1 = get_commit_reference(argv[1]);
+ rev2 = get_commit_reference(argv[2]);
+
return show_merge_base(rev1, rev2, show_all);
}
--
1.6.0.rc0.42.g186458.dirty
^ permalink raw reply related
* Re: [PATCH 2/2 v2] run-command (Windows): Run dashless "git <cmd>" (solves part of problem with system_path)
From: Junio C Hamano @ 2008-07-29 5:42 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Steffen Prohaska, Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <20080729052459.GC11947@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> 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.
>
> Though I can see where it may be a good idea to at some point
> in the future (git 1.7?) stop creating the redundant builtin
> links under libexec/git-core.
I agree; that is why I already applied Steffen's original patch with quite
a different justification from the updated one:
commit b048b9a803f48d88595877271b53bf9ec400e4ba
Author: Steffen Prohaska <prohaska@zib.de>
Date: Mon Jul 28 07:50:28 2008 +0200
run-command (Windows): Run dashless "git <cmd>"
We prefer running the dashless form, and POSIX side already does so; we
should use it in MinGW's start_command(), too.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [PATCH] merge-base: die with an error message if not passed a commit ref
From: Junio C Hamano @ 2008-07-29 5:45 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin, Miklos Vajna, Jakub Narebski
In-Reply-To: <20080729074253.b4617027.chriscool@tuxfamily.org>
Thanks; queued for 1.6.0.
^ permalink raw reply
* Re: q: git-fetch a tad slow?
From: Shawn O. Pearce @ 2008-07-29 5:50 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080728160138.GA12777@elte.hu>
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
>
> There are hundreds of branches, so i thought fetching a single branch
> alone would improve things:
>
> titan:~/tip> time git-fetch origin master
> real 0m0.942s
>
> But that's still slow - so i use a (lame) ad-hoc script instead:
>
> titan:~/tip> time tip-fetch
> real 0m0.246s
OK, yes, when there are _many_ branches like that limiting fetch
to a narrow focus of only the branch(es) you must have can make it
go much faster. Part of the problem is we loop over the branches
many times, and those are O(N) loops (N=number of branches). We
could do better, but we don't.
One reason why your tip-fetch runs so much better is because we don't
have to enumerate the hundreds of advertised branches offered up by
the remote peer to find the one you want to fetch. Your tip-fetch
is reading only that one ref file (.git/refs/heads/master) and
that's pretty much it.
In contrast git-upload-pack on the server side must open and read
_all_ ref files under .git/refs/ and send them to the client, who
then has to loop over them at least twice before it can decide if
a match exists. That's a lot more data to shove down over SSH.
Granted its only 42 bytes + refname per ref, but its still more.
Those O(N) loops I referred to earlier can explain why for hundreds
of branches it gets ugly. That turns into an O(N^2) matching
algorithm. Not pretty. A simple hash would solve a lot of that,
changing the first time from 0m2.372s to much closer to the scond
time of 0m0.942s.
Neither of which can compete with your tip-fetch.
Have you tried using git-pack-refs to pack the branches on the
remote repository?
If you update all of the branches, run `git pack-refs --all --prune`,
then allow the testing clients to start fetching it may go much
quicker. The pack-refs moves all of the individual ref files into
the single .git/packed-refs file, reducing the number of files we
need to open and read to service a single fetch client.
I wonder if git-pack-refs + fetching only a single branch will get
you closer to the tip-fetch time.
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.
--
Shawn.
^ permalink raw reply
* Re: git submodules
From: Benjamin Collins @ 2008-07-29 5:51 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Pierre Habouzit, Nigel Magnay, Git ML
In-Reply-To: <32541b130807281440v64f3cb9ci50cf6d16be4f2f82@mail.gmail.com>
On Mon, Jul 28, 2008 at 4:40 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> Most importantly in my case, my submodules (libraries shared between
> apps) have a very different branching structure than my supermodules.
> It wouldn't be particularly meaningful to force them to use the same
> branch names.
>
> Further, if you don't have a separate .git directory for each
> submodule, you can't *switch* branches on the submodule independently
> of the supermodule in any obvious way. This is also useful; I might
> want to test updating to the latest master of my submodule, see if it
> still works with my supermodule, and if so, commit the new gitlink in
> the supermodule. This is a very common workflow for me.
I second this sentiment. I happen to very much *like* the fact that
the coupling between submodules and their super-projects is minimal.
The flexibility this allows is very useful. Of course, it brings to
mind the comment Stroustrup once made about C++ blowing off your whole
leg.
> On the other hand, your thought about combining the "git log" messages
> is quite interesting. That *is* something I'd benefit from, along
> with being able to git-bisect across submodules. If I'm in the
> supermodule, I want to see *all* the commits that might have changed
> in my application, not just the ones in the supermodule itself. I
> suspect this isn't simple at all to implement, however, as you'd have
> to look inside the file tree of a given commit in order to find
> whether any submodule links have changed in that commit. It's
> unfortunate that submodules involve a commit->tree->commit link
> structure.
Let my contrariness begin...
I can see how someone might find such a feature in "git log" useful,
but I don't think I would. I have 3 submodules in my project right
now, and I don't always want to see the changes. Most of the time, I
don't care, actually. When I do care, I can search the output of "git
log" for commits that touch the path where my submodule lives (through
Gitk, usually), and I can open another Gitk for details.
As for "git bisect": I haven't done this and I'm too busy to try to
contrive something for the purposes of this email, but wouldn't it
basically already do what you want? Seems that you'd just run "git
submodule update" after each step of the bisect.
>
> > One irritating problem with submodules, is
> > that when someone else commited, and that you git submodule update,
> > you're on a detached head. Absolutely horrible.
>
> I think that roughly everyone agrees with the above statement by now.
> It would also be trivial to fix it, if only we knew what "fix" means.
> So far, I haven't seen any good suggestions for what branch name to
> use automatically in a submodule, and believe me, I've been looking
> for one :)
I disagree with this completely. I think the detached head is
actually fantastic because it tells you all the right things:
a) the branch your submodule is on is ultimately irrelevant
b) it reminds you that this is not your project. It's part of your
project managed in a special way by Git, but your project is in ..
c) if you want to do work in this part of your project that comes from
somewhere else, you need to be thoughtful about how you manage its
branches.
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.
I pretty much support submodules as they are, with the exception of
wanting "git submodule update" to be executed automatically at times.
^ 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 5:51 UTC (permalink / raw)
To: Shawn O. Pearce, Johannes Sixt
Cc: Git Mailing List, Junio C Hamano, Johannes Schindelin
In-Reply-To: <20080729052459.GC11947@spearce.org>
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. The
solution however needs to be tested without builtins installed
in libexec/git-core. Note that Unix runs builtins using the
git wrapper too (see execv_git_cmd), so the patch makes the MinGW
port behaving more like the Unix version.
My patch however does not solve the problem for non-builtins, so I agree
that we are not fixing the real problem.
Maybe we could do the following:
- Add a switch RELOCATABLE_PREFIX to the Makefile.
- If RELOCATABLE_PREFIX is defined, system paths will not be
interpreted as is, but a prefix will be computed at runtime. For
example, if git is installed in /some/patch/bin/git, then
system_path("/etc") will return "/some/path/etc".
- As Dscho proposed, system_path() needs to be intelligent enough
to find the prefix for executables located either in bindir or in
gitexecdir.
Adding a switch to the Makefile would make the relocation magic
explicit, instead of relying on relative paths. This has also the
advantage that we can just use the default paths for gitexecdir,
template_dir, ... , instead of overriding them in MINGW section of the
Makefile. We only would set RELOCATABLE_PREFIX there. Actually some
more work is needed because prefix is used for defining system paths and
also for defining the installation directory. Maybe we could add
installprefix to explicitly distinguish between the two purposes.
Steffen
^ 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 5:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <7v4p69meka.fsf@gitster.siamese.dyndns.org>
On Jul 29, 2008, at 7:42 AM, Junio C Hamano wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
>> 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.
>>
>> Though I can see where it may be a good idea to at some point
>> in the future (git 1.7?) stop creating the redundant builtin
>> links under libexec/git-core.
>
> I agree; that is why I already applied Steffen's original patch with
> quite
> a different justification from the updated one:
>
> commit b048b9a803f48d88595877271b53bf9ec400e4ba
> Author: Steffen Prohaska <prohaska@zib.de>
> Date: Mon Jul 28 07:50:28 2008 +0200
>
> run-command (Windows): Run dashless "git <cmd>"
>
> 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.
Steffen
^ permalink raw reply
* Re: git submodules
From: Shawn O. Pearce @ 2008-07-29 6:04 UTC (permalink / raw)
To: Benjamin Collins; +Cc: Avery Pennarun, Pierre Habouzit, Nigel Magnay, Git ML
In-Reply-To: <b3889dff0807282251t7096a8c9wf477cf4495749d34@mail.gmail.com>
Benjamin Collins <aggieben@gmail.com> wrote:
> On Mon, Jul 28, 2008 at 4:40 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> >
> > > One irritating problem with submodules, is
> > > that when someone else commited, and that you git submodule update,
> > > you're on a detached head. Absolutely horrible.
> >
> > I think that roughly everyone agrees with the above statement by now.
> > It would also be trivial to fix it, if only we knew what "fix" means.
> > So far, I haven't seen any good suggestions for what branch name to
> > use automatically in a submodule, and believe me, I've been looking
> > for one :)
>
> I disagree with this completely. I think the detached head is
> actually fantastic [...]
Ditto with Benjamin. Detached head is a fantastic idea.
> [...] because it tells you all the right things:
> a) the branch your submodule is on is ultimately irrelevant
> b) it reminds you that this is not your project. It's part of your
> project managed in a special way by Git, but your project is in ..
> c) if you want to do work in this part of your project that comes from
> somewhere else, you need to be thoughtful about how you manage its
> branches.
>
> 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.
--
Shawn.
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Alex Riesen @ 2008-07-28 21:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsj6tsm3.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Mon, Jul 28, 2008 08:44:52 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > t2103-update-index-ignore-missing.sh still broken on Windows because
> > of stat.st_size being 0 for directories there.
>
> I recall we did not reach a useful conclusion of that discussion.
Why isn't the proposed patch useful? (and would it be possible to make
the answer out of plain, small and short words?)
^ permalink raw reply
* Re: [PATCH] Make use of stat.ctime configurable
From: Alex Riesen @ 2008-07-28 21:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Brown, Junio C Hamano, Johannes Schindelin, Johannes Sixt,
git
In-Reply-To: <alpine.LFD.1.10.0807280906530.3486@nehalem.linux-foundation.org>
Linus Torvalds, Mon, Jul 28, 2008 18:09:32 +0200:
> It really is just Beagle that is (was? I can dream) a piece of
> unbelievable crap.
>
> 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.
>
> And no other sane model would ever touch 'ctime'.
Beagle is not alone. Google Desktop Search was mentioned before.
> Oh, well. Making ctime configurable is not wrong per se. But if it's
> Beagle that triggers this, the fix is sadly in the wrong place.
Never said it was a fix. Same as CRLF conversion is not a feature.
^ permalink raw reply
* [PATCH] Improve the placement of core.trustctime in the documentation
From: Alex Riesen @ 2008-07-28 21:47 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Johannes Schindelin, Linus Torvalds,
Johannes Sixt, git
In-Reply-To: <20080728162043.GG32184@machine.or.cz>
Accidentally, it split a _chapter_ about a file data corrup...
conversion for a weird, but common operating system.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Petr Baudis, Mon, Jul 28, 2008 18:20:43 +0200:
> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
> > diff --git a/Documentation/config.txt b/Documentation/config.txt
> > index 1a13abc..552c134 100644
> > --- a/Documentation/config.txt
> > +++ b/Documentation/config.txt
> > @@ -149,6 +149,13 @@ core.safecrlf::
> > `core.autocrlf`, git will reject the file. The variable can
> > be set to "warn", in which case git will only warn about an
> > irreversible conversion but continue the operation.
> > +
> > +core.trustctime::
> > + If false, the ctime differences between the index and the
> > + working copy are ignored; useful when the inode change time
> > + is regularly modified by something outside Git (file system
> > + crawlers and some backup systems).
> > + See linkgit:git-update-index[1]. True by default.
> > +
> > CRLF conversion bears a slight chance of corrupting data.
> > autocrlf=true will convert CRLF to LF during commit and LF to
>
> Somehow, this particular position of the new hunk does not feel like the
> best choice. ;-)
>
It's alphabetical. Why? Oh, shit... Screw alphabetical
Documentation/config.txt | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 552c134..61c3760 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -117,6 +117,13 @@ core.fileMode::
the working copy are ignored; useful on broken filesystems like FAT.
See linkgit:git-update-index[1]. True by default.
+core.trustctime::
+ If false, the ctime differences between the index and the
+ working copy are ignored; useful when the inode change time
+ is regularly modified by something outside Git (file system
+ crawlers and some backup systems).
+ See linkgit:git-update-index[1]. True by default.
+
core.quotepath::
The commands that output paths (e.g. 'ls-files',
'diff'), when not given the `-z` option, will quote
@@ -149,13 +156,6 @@ core.safecrlf::
`core.autocrlf`, git will reject the file. The variable can
be set to "warn", in which case git will only warn about an
irreversible conversion but continue the operation.
-
-core.trustctime::
- If false, the ctime differences between the index and the
- working copy are ignored; useful when the inode change time
- is regularly modified by something outside Git (file system
- crawlers and some backup systems).
- See linkgit:git-update-index[1]. True by default.
+
CRLF conversion bears a slight chance of corrupting data.
autocrlf=true will convert CRLF to LF during commit and LF to
--
1.6.0.rc0.76.g581e
^ permalink raw reply related
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-29 6:20 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080728213727.GA3721@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Mon, Jul 28, 2008 08:44:52 +0200:
>> Alex Riesen <raa.lkml@gmail.com> writes:
>>
>> > t2103-update-index-ignore-missing.sh still broken on Windows because
>> > of stat.st_size being 0 for directories there.
>>
>> I recall we did not reach a useful conclusion of that discussion.
>
> Why isn't the proposed patch useful? (and would it be possible to make
> the answer out of plain, small and short words?)
Can you answer out of plain, small and short words why the proposed patch
is correct without unwanted side effects, not just "this seems to solve
the particular issue for me but I don't know if it has unintended side
effects"?
^ permalink raw reply
* Re: [PATCH] Improve the placement of core.trustctime in the documentation
From: Junio C Hamano @ 2008-07-29 6:23 UTC (permalink / raw)
To: Alex Riesen
Cc: Petr Baudis, Johannes Schindelin, Linus Torvalds, Johannes Sixt,
git
In-Reply-To: <20080728214716.GB3721@blimp.local>
Alex Riesen <raa.lkml@gmail.com> writes:
> Accidentally, it split a _chapter_ about a file data corrup...
> conversion for a weird, but common operating system.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> Petr Baudis, Mon, Jul 28, 2008 18:20:43 +0200:
>> On Mon, Jul 28, 2008 at 08:31:28AM +0200, Alex Riesen wrote:
>> > diff --git a/Documentation/config.txt b/Documentation/config.txt
>> > index 1a13abc..552c134 100644
>> > --- a/Documentation/config.txt
>> > +++ b/Documentation/config.txt
>> > @@ -149,6 +149,13 @@ core.safecrlf::
>> > `core.autocrlf`, git will reject the file. The variable can
>> > be set to "warn", in which case git will only warn about an
>> > irreversible conversion but continue the operation.
>> > +
>> > +core.trustctime::
>> > + If false, the ctime differences between the index and the
>> > + working copy are ignored; useful when the inode change time
>> > + is regularly modified by something outside Git (file system
>> > + crawlers and some backup systems).
>> > + See linkgit:git-update-index[1]. True by default.
>> > +
>> > CRLF conversion bears a slight chance of corrupting data.
>> > autocrlf=true will convert CRLF to LF during commit and LF to
>>
>> Somehow, this particular position of the new hunk does not feel like the
>> best choice. ;-)
>>
>
> It's alphabetical. Why? Oh, shit... Screw alphabetical
Yeah, I think it makes sense to put this after core.filemode.
^ permalink raw reply
* Re: theirs/ours was Re: [PATCH 6/6] Add a new test for using a custom merge strategy
From: Junio C Hamano @ 2008-07-29 6:35 UTC (permalink / raw)
To: Jeff King; +Cc: sverre, Johannes Schindelin, Git Mailinglist, Miklos Vajna
In-Reply-To: <20080729050845.GE26997@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Your reason was "it keeps your crap in the history". And while I
> generally am in favor of getting rid of crap and keeping a clean
> history, I think it is very much dependent on the individual project's
> preferences. IOW, that history might not contain "crap" but rather
> now-obsolete changes that are of historical interest.
>
> But I do agree that -Xtheirs is crap. ;)
Yes, that is why I did not merge 'master' with "theirs" merge into it to
subsume it. I reverted -Xtheirs from 'next' (due to "never-rewind during
the cycle" rule) and intend to rebuild 'next' without it when 1.6.0 ships.
However, that does not keep me from holding onto its tip privately (and I
do, as the machinery to pass -Xoption through git-merge to backends would
be useful later).
IOW, "now-obsolete changes that are of historical interest" does not
necessarily justify a "subsuming" merge using "-s ours" or "-s theirs".
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-28 23:12 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Nigel Magnay, Git ML
In-Reply-To: <32541b130807281532v3eed94ebv8037247618e9bd55@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 5156 bytes --]
On Mon, Jul 28, 2008 at 10:32:54PM +0000, Avery Pennarun wrote:
> On 7/28/08, Pierre Habouzit <madcoder@debian.org> wrote:
> > > It's unfortunate that submodules involve a commit->tree->commit link
> > > structure.
> >
> > Actually it's not a big problem, you just have to "dereference" twice
> > instead of one, and be prepared to the fact that the second dereference
> > may fail (because you miss some objects). I instead believe that
> > gitlinks are a good idea.
>
> It's actually complicated to generate the log, however. To be 100%
> accurate in creating a combined log of the supermodule and submodule,
> you'd have to check *for each supermodule commit* whether there were
> any changes in gitlinks. And gitlinks might move around between
> revisions, so you can't just look up a particular path in each
> revision; you have to traverse the entire tree. And you can't just
> look at the start and end supermodule commits to see if the gitlinks
> changed; they might have changed and then changed back, which is quite
> relevant to log messages.
I'm pretty clueless about how git-log works, but I fail to see how this
is harder than following file moves e.g. Of course it's more expensive
than git log, but it shouldn't really be more expensive than
`git log -M -C -C` already is.
> > Well, using the same [branch] as the supermodule is probably the less confusing
> > way. Of course, not being in the "same" branch as the supermodule would
> > clearly be a case of your tree being "dirty", and it would prevent a
> > "git checkout" to work in the very same way that git checkout doesn't
> > work if you have locally modified files.
> >
> > If your submodule branching layout uses the same names as the
> > supermodule branches then yes, it's going to hurt, but I believe it to
> > be unlikely (else you would become insane just trying to remember what
> > you are doing ;p).
>
> I think this is much more common than you think. An easy example is
> that I'm developing a new version of my application in the
> supermodule's "master", but it relies on a released version of my
> submodule, definitely not the experimental "master" version. Using
> your logic, the local branch of the submodule would be called master,
> but wouldn't correspond at all to the remote submodule's master.
Probably indeed, otoh the "remote" (assume it's origin) master state is
stored in "origin/master", not "master".
> I believe such a situation would be even worse than no branch at all.
> It could lead to people pushing/pulling all sorts of bad things from
> the wrong places. At least right now, people become confused and ask
> for help instead of becoming confused and making a mess.
Indeed. But that's only a name issue, I'm sure we can come up with
something decent. What I (we ?) want is actually a way to make
git-checkout/git-reset work so that when you switch branches (reset
--hard to a previous state) you remain on branch, because human brains
usually don't remember those silly detached HEADs commits sha1 well ;)
The problem is, `the branch I'm on in my submodule when the supermodule
is on $foo` is a quite local information. But that's really what we
would like to remember so that when you git checkout somewhere and git
checkout master back, submodules switches branch accordingly.
Saying that, I realize that we probably _really_ want to name submodule
branches the same as the supermodule ones, but should manage to find UIs
that don't confuse users wrt the fact that it may be disconnected from
the remote branch nameing.
I reckon that for my use, I would not have those problems, because we
have this kind of layout:
lib-foo/ <-- submodule to share the foo library.
lib-bar/ <-- submodule to share the bar library.
app-frotz/ <-- the frotz product
In another repository we have app-quux and the same submodules, and so
on.
We always try that our `master`s (where devel happens unlike git.git ;p)
use the most recent `master` versions from the submodules. And the
stable branches (IOW the software that we sold and released and for
which we provide support), have branches named $product/$version. We
have $product/$version branches in those submodules as well. If we have
a bug that needs a patch in say, lib-foo, then we push the patch into a
topic branch, that we merge in all the $product/$version that need it,
and into master as well. For such a setup that I believe to be sane,
then well, corresponding names fit the job perfectly.
Of course if one of your submodule is git.git where the not too unstable
code lives in `next` and not `master` and another one is one of my
project at work, where not too unstable code lives in `master` then
indeed you're somehow screwed because indeed the whole `master` concept
would be quite confusing. But honestly, I don't think it's less
confusing with the current way submodules work either.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: GTP/0.1 terminology 101: commit reels and references
From: Sam Vilain @ 2008-07-29 7:00 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Joshua Roys, gittorrent, git, Jonas Fonseca
In-Reply-To: <alpine.DEB.1.00.0807290014110.2725@eeepc-johanness>
On Tue, 2008-07-29 at 00:30 +0200, Johannes Schindelin wrote:
> > Yes, but it is more defined than that. There are still ambiguities with
> > topological sort, so the gittorrent spec specified exactly how all ties
> > are broken. They happen to be a further refinement of --date-order,
> > with respect to the ordering of commits.
>
> But does that not mean that any new ref branching off of an ancient commit
> changes all the pack boundaries?
No. A "References" object is a snapshot of all refs at a particular
time. If you want to make a new ref you make a new "References" object.
*all* of the new objects are contained in the new reel, and the new
reels do not affect the old reels.
> That should be easy, but I think that it would be _even better_ if we ask
> pack-objects to generate several packs from the needed objects. Ooops.
> That already exists:
>
> $ git pack-objects --max-pack-size=<n>
This does not deterministically generate the same pack for a given set of
refs across all git versions.
Your ideas would have been excellent earlier on, perhaps if developed
they might have resulted in something quite a bit simpler with all of
the features the current protocol has - but given we are in the second
half of a GSoC project of which the end is in sight then I think we
should shelve them until the project finishes. There has certainly been
a lot of useful things come out of them!
Cheers,
Sam.
^ permalink raw reply
* git merge --squash isn't "marked as a merge"??
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-29 7:49 UTC (permalink / raw)
To: git
Newbie alert:
I have a feature branch where I have N tiny commits with sloppy/private
commit messages. Being able to have private commits was the main reason
I'm using git (as a frontend to svn).
Today the feature is in a "good" state, and I want to merge it into a
main branch, showing a single commit with a well phrased message for all
the world to see. So I:
$ git checkout master
$ git merge --squash feature
$ git commit -F wellphrased.msg
Now I was expecting that:
$ git merge feature
would do nothing (I already did a merge!). But it pulls in all the
sloppy commits and messages from "feature"!
Of course now I could continue with a new branch made like this:
$ git checkout -b feature2 master
and continue working privately on feature2 again. Then I'll end up with
feature..feature47 before I'm done. Each with its own segment of my
private history. A real mess.
Can I continue on feature somehow so I privately can "git log" and
see all my messy commits (both before and after the "git merge
--squash") and then regularly "git merge" and/or "git merge --squash"
back and forth between "feature" and "master" as I deem appropriate?
I'm guessing that if the --squash *did* put in a "merge arrow" (setting
a "parent" of the commit to the head of feature) thereby allowing merge
to not do anything, then git log would also follow feature's sloppy
history too. They go together as a pair. Is that right? Testing this:
git help merge says about --squash:
> Produce the working tree and index state as if a real merge happened,
> but do not actually make a commit or move the HEAD, nor record
> $GIT_DIR/MERGE_HEAD to cause the next git commit command to create a
> merge commit.
So I tried "git merge --squash feature", then set up .git/MERGE_HEAD to
the same contents as .git/refs/heads/feature and then "git commit". This
produced the same result as "git merge" without --squash including all
the sloppy messages.
SO: It seems to me I cannot continuously merge "feature" to "master" in
chunks with "--squash" as I would like. Is that right? Is my desire
fundamentally misguided, and is there A Better Way?
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-29 8:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <7vr69dky93.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> Junio C Hamano, Mon, Jul 28, 2008 08:44:52 +0200:
>>> Alex Riesen <raa.lkml@gmail.com> writes:
>>>
>>> > t2103-update-index-ignore-missing.sh still broken on Windows because
>>> > of stat.st_size being 0 for directories there.
>>>
>>> I recall we did not reach a useful conclusion of that discussion.
>>
>> Why isn't the proposed patch useful? (and would it be possible to make
>> the answer out of plain, small and short words?)
>
> Can you answer out of plain, small and short words why the proposed patch
> is correct without unwanted side effects, not just "this seems to solve
> the particular issue for me but I don't know if it has unintended side
> effects"?
Ok, I took a deeper look at the codepaths involved. Although it does work
around the issue, I do not think your patch alone is the "correct" one in
the longer term.
It needs a bit of explanation, and the explanation won't be exactly
"plain, small and short", unfortunately.
-- >8 --
[PATCH] Teach gitlinks to ie_modified() and ce_modified_check_fs()
The ie_modified() function is the workhorse for refresh_cache_entry(),
i.e. checking if an index entry that is stat-dirty actually has changes.
After running quicker check to compare cached stat information with
results from the latest lstat(2) to answer "has modification" early, the
code goes on to check if there really is a change by comparing the staged
data with what is on the filesystem by asking ce_modified_check_fs().
However, this function always said "no change" for any gitlinks that has a
directory at the corresponding path. This made ie_modified() to miss
actual changes in the subproject.
The patch fixes this first by modifying an existing short-circuit logic
before calling the ce_modified_check_fs() function. It knows that for any
filesystem entity to which ie_match_stat() says its data has changed, if
its cached size is nonzero then the contents cannot match, which is a
correct optimization only for blob objects. We teach gitlink objects to
this special case, as we already know that any gitlink that
ie_match_stat() says is modified is indeed modified at this point in the
codepath.
With the above change, we could leave ce_modified_check_fs() broken, but
it also futureproofs the code by teaching it to use ce_compare_gitlink(),
instead of assuming (incorrectly) that any directory is unchanged.
Originally noticed by Alex Riesen on Cygwin.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
read-cache.c | 27 ++++++++++++++++++++++-----
1 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index b5916b0..a940f8d 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -152,7 +152,7 @@ static int ce_modified_check_fs(struct cache_entry *ce, struct stat *st)
break;
case S_IFDIR:
if (S_ISGITLINK(ce->ce_mode))
- return 0;
+ return ce_compare_gitlink(ce) ? DATA_CHANGED : 0;
default:
return TYPE_CHANGED;
}
@@ -192,6 +192,7 @@ static int ce_match_stat_basic(struct cache_entry *ce, struct stat *st)
changed |= TYPE_CHANGED;
break;
case S_IFGITLINK:
+ /* We ignore most of the st_xxx fields for gitlinks */
if (!S_ISDIR(st->st_mode))
changed |= TYPE_CHANGED;
else if (ce_compare_gitlink(ce))
@@ -298,11 +299,22 @@ int ie_modified(const struct index_state *istate,
if (changed & (MODE_CHANGED | TYPE_CHANGED))
return changed;
- /* Immediately after read-tree or update-index --cacheinfo,
- * the length field is zero. For other cases the ce_size
- * should match the SHA1 recorded in the index entry.
+ /*
+ * Immediately after read-tree or update-index --cacheinfo,
+ * the length field is zero, as we have never even read the
+ * lstat(2) information once, and we cannot trust DATA_CHANGED
+ * returned by ie_match_stat() which in turn was returned by
+ * ce_match_stat_basic() to signal that the filesize of the
+ * blob changed. We have to actually go to the filesystem to
+ * see if the contents match, and if so, should answer "unchanged".
+ *
+ * The logic does not apply to gitlinks, as ce_match_stat_basic()
+ * already has checked the actual HEAD from the filesystem in the
+ * subproject. If ie_match_stat() already said it is different,
+ * then we know it is.
*/
- if ((changed & DATA_CHANGED) && ce->ce_size != 0)
+ if ((changed & DATA_CHANGED) &&
+ (S_ISGITLINK(ce->ce_mode) || ce->ce_size != 0))
return changed;
changed_fs = ce_modified_check_fs(ce, st);
@@ -1331,6 +1343,11 @@ static void ce_smudge_racily_clean_entry(struct cache_entry *ce)
* falsely clean entry due to touch-update-touch race, so we leave
* everything else as they are. We are called for entries whose
* ce_mtime match the index file mtime.
+ *
+ * Note that this actually does not do much for gitlinks, for
+ * which ce_match_stat_basic() always goes to the actual
+ * contents. The caller checks with is_racy_timestamp() which
+ * always says "no" for gitlinks, so we are not called for them ;-)
*/
struct stat st;
^ permalink raw reply related
* Re: git submodules
From: Nigel Magnay @ 2008-07-29 8:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Benjamin Collins, Avery Pennarun, Pierre Habouzit, Git ML
In-Reply-To: <20080729060449.GG11947@spearce.org>
>> I try to keep all my submodules on (no branch) as much as possible.
>> In a way, I feel like that kind of relieves me of the chore of keeping
>> mapping superproject branches to submodule branches in my head.
>
> At my former day-job we wrote our own "git submodule" in our
> build system before gitlink was available in the core, let alone
> git-submodule was a Porcelain command.
>
> Many developers who were new to Git found having a sea of 11 Git
> repositories+working directories in a single build area difficult to
> manage. They quickly found the detached HEAD feature in a submodule
> to be a really handy way to know if they made changes there or not.
>
> Most of our developers also modified __git_ps1() in their bash
> completion to use `git name-rev HEAD` to try and pick up a remote
> branch name when on a detached HEAD. This slowed down their bash
> prompts a little bit, but they found that "origin/foo" hint very
> valuable to let them know they should start a new branch before
> making changes.
>
> So I'm just echoing what Benjamin said above, only we did it
> independently, and came to the same conclusion.
>
Hm.
My developers are (mostly) on windows, so "altering PS1" or even
writing "shell scripts" is way beyond them. They want it to "just
work" (where their previous experience is SVN superprojects with
multiple svn:externals). I have a hard time justifying the experience
that if we're all working on master, then as soon as Joe Q developer
does 'submodule update' then poof - his heads are disconnected.
That said, I do also like the flexibility that having the superproject
on heads/foo and a submodule on heads/bar as it allows you to
integration test divergent submodule branches (indeed our CI system
automatically picks them up and tries all possible combinations).
^ permalink raw reply
* Re: git submodules
From: Pierre Habouzit @ 2008-07-29 8:21 UTC (permalink / raw)
To: Benjamin Collins; +Cc: Avery Pennarun, Nigel Magnay, Git ML
In-Reply-To: <b3889dff0807282251t7096a8c9wf477cf4495749d34@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4939 bytes --]
On Tue, Jul 29, 2008 at 05:51:31AM +0000, Benjamin Collins wrote:
> I try to keep all my submodules on (no branch) as much as possible.
> In a way, I feel like that kind of relieves me of the chore of keeping
> mapping superproject branches to submodule branches in my head.
Why would _you_ map them to superproject branches ? I mean it's pretty
much Git's matter. In fact, maybe calling them branches is not a
brilliant idea, what I would like would probably rather be some kind of
reflog like thing, but with one reflog per submodule and supermodule
branch.
I agree with you than when you don't have to do any change in the
submodule, detached HEADs just work. But when you often have to push
fixes in, it's a nightmare. Instead of just having to:
$EDITOR mysubmodule/file.c
git commit mysubmodule/file.c # that would ideally do a commit in the
# submodule then update the submodule
# state in the supermodule
git submodule mysubmodule push origin HEAD # push the submodule mysubmodule
# changes to the appropriate branch
git push origin HEAD
You have to:
cd submodule
git branch -D master
git checkout -b master
git commit file.c
cd ..
git commit submodule
cd submodule
git push origin HEAD:remote/branch/we/want/to/push/to
cd ..
git push origin HEAD
*phew*
I'm sorry but this is nowhere near a good UI. Of course the detached
head *currently* prevents you to shoot yourself in the foot, because
submodules are _that_ dangerous. But those also are tedious to work
with, like a lot, which makes currently our answer to big projects "do
not have GB-big repositories, split them in submodules" a bad joke,
because their ergonomy is nowhere near what you have with a monolithic
repository yet.
I'm trying to see what to do better. I believe we _need_ those things:
* a way to name the successive states of the submodule, a branch looks
like a good idea, but maybe we can "invent" some different idea so
that it looks and tastes like a branch, but is more automagic in the
sense that it's just a prettier name than a sha1.
This would allow to inspect the submodule history using
`gitk $this_name`. The $PS1 thing is nice, but you have to cd into
the submodule to see where it currently lives. So you rather need
something else.
* a way to remember where you want to push changes you do in the
submodule to. That's a bit like branch tracking, but not quite. This
is required so that we can (and I strongly believe we want that in
the end) make many porcelain commands act on the full
(super+sub)modules in a unified way, somehow hiding the submodules
boundaries.
For example, git commit file1 file2 file3 ... would do the
submodules commits if any, and then the supermodule one. Alternatively, if
you have e.g.:
$ git add mysubmodule/file1.c
$ git add superfile.c
$ git add mysubmodule # tell the supermodule we want to commit what
# is in the submodule index at the same time
$ git commit
Then if you run:
$ git push # fails complaining that mysubmodule is
# not pushed
$ git submodule mysubmodule push
$ git push # works
* What you "track" must be a per supermodule branch thing, so that if
you do things like that:
# you are in master in the supermodule with non pushed commits in
# the submodule
<.. oh crap there is a bug in the supermodule that I need to fix in
the production branch..>
$ git checkout production # would checkout in the submodule what
# matches
$ $EDITOR mysubmodule/something
$ git commit !$
$ ..push everything..
<.. okay let's now go back to master ..>
$ git checkout master
<... hack hack hack to finish the current WIP ...>
<... okay we're ready to merge production in ...>
$ git merge production # will DWYM with the submodules, IOW merge the
# `production` state into the current `master` one.
$ git sm mysubmodule push
$ git push
Try to write the same workflow with the current submodules, you'll
end up with a script at least 3 times as long, because you would
need to do everything by hand, including switching submodules,
naming temporary branches in them so that you can work decently and
perform the merges and so on.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Johannes Sixt @ 2008-07-29 8:33 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git, Junio C Hamano
In-Reply-To: <B6158330-640B-4CA3-8589-310FA8EA6CC9@zib.de>
Zitat von Steffen Prohaska <prohaska@zib.de>:
>
> On Jul 27, 2008, at 9:24 PM, Johannes Sixt wrote:
>
> > Zitat von Steffen Prohaska <prohaska@zib.de>:
> >
> >>
> >> On Jul 26, 2008, at 10:37 PM, Johannes Sixt wrote:
> >>
> >>> Zitat von Steffen Prohaska <prohaska@zib.de>:
> >>>> With MinGW's
> >>>>
> >>>> gcc.exe (GCC) 3.4.5 (mingw special)
> >>>> GNU ld version 2.17.50 20060824
> >>>>
> >>>> the old define caused link errors:
> >>>>
> >>>> git.o: In function `main':
> >>>> C:/msysgit/git/git.c:500: undefined reference to `mingw_main'
> >>>> collect2: ld returned 1 exit status
> >>>>
> >>>> The modified define works.
> >>>
> >>> I have the same tools, but not this error. ???
> >>
> >> I cleaned my work tree and built several times but did not
> >> find out what exactly is causing the error. So I came up
> >> with the modified define, which declares the static
> >> mingw_main in global scope. I have no clue why I see the
> >> error that you don't have.
> >
> > Neither do I. But a strange line number you have there. In 01d9b2d
> > (from
> > mingw.git) I have 'exit(1)' in line 500 of git.c.
>
> I have the same in line 500. I am still wondering what this could
> mean. But I do not yet now :-(
Can you try 'make -k' and see whether you have a similar problem with the
non-builtins that have their own main()?
-- Hannes
^ permalink raw reply
* Re: Hackontest ideas?
From: Petr Baudis @ 2008-07-29 8:35 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, git
In-Reply-To: <20080729053110.GD11947@spearce.org>
On Mon, Jul 28, 2008 at 10:31:10PM -0700, Shawn O. Pearce wrote:
> How about smart fetch/push over HTTP? E.g. a CGI (or extension to
> gitweb) that does native pack transport over HTTP rather than dumb
> object traversal with GET and WebDAV LOCK/PUT. Note that the push
> side doesn't need to support tell-me-more extension, making it a
> fairly trivial GET, POST (or PUT) sequence.
Ah, thanks for reminding me about this, nice!
Thanks all for their suggestions so far, I have added all of them plus
an extra. Now, if you want them implemented, some of you need to join as
implementers and the features need to get a lot of votes quickly! ;-))
(Frankly, I don't think there is really any chance to make it, but I
think having such a list of mid-size self-contained tasks might be
useful for other occasions, so I will haul it over to the wiki after the
deadline.)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: GIT 1.6.0-rc1
From: Junio C Hamano @ 2008-07-29 8:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <7v4p69jefb.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
>>> Junio C Hamano, Mon, Jul 28, 2008 08:44:52 +0200:
>>>> Alex Riesen <raa.lkml@gmail.com> writes:
>>>>
>>>> > t2103-update-index-ignore-missing.sh still broken on Windows because
>>>> > of stat.st_size being 0 for directories there.
>>>>
>>>> I recall we did not reach a useful conclusion of that discussion.
>>>
>>> Why isn't the proposed patch useful? (and would it be possible to make
>>> the answer out of plain, small and short words?)
>>
>> Can you answer out of plain, small and short words why the proposed patch
>> is correct without unwanted side effects, not just "this seems to solve
>> the particular issue for me but I don't know if it has unintended side
>> effects"?
>
> Ok, I took a deeper look at the codepaths involved. Although it does work
> around the issue, I do not think your patch alone is the "correct" one in
> the longer term.
>
> It needs a bit of explanation, and the explanation won't be exactly
> "plain, small and short", unfortunately.
Alex, I ran the full test with this, but only on Linux boxes; obviously
not on any flavor of Windows. I think it is correct, and the "first line
of defence" fix is the same as your patch, so I'd assume it would work for
you as well. But extra eyeballs are always appreciated.
^ permalink raw reply
* Re: 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