* Re: [PATCH] INSTALL: Update section about git-frotz form.
From: Miklos Vajna @ 2008-07-07 13:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhcb2a1hj.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 645 bytes --]
On Sun, Jul 06, 2008 at 07:10:00PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> The mention of 1997 was correct when it was made, and I think it still is
> true to some extent (http://savannah.gnu.org/forum/forum.php?forum_id=5189
> says it has not been actively maintained for quite some time), but I think
> it is no longer relevant to us whether many users use gnuit or moved away
> to graphical file managers because of its name change.
>
> The only people possibly affected are people who has older version of
> gnuit that has been called git, so how about shortening the section even
> further like:
Thanks, I like it.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] builtin-rerere: fix conflict markers parsing
From: Olivier Marin @ 2008-07-07 13:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807071400180.18205@racer>
Johannes Schindelin a écrit :
>
> So what about
>
> <<<<<<< This hunk contains =====
> anythin
> =======
>
> Hello
> =======
> somethin else
> >>>>>>> problem!
>
>
> If you fix it, I think you should do it properly, and analyze the index.
If I read the code correctly, this case is not a problem at all because what
is important is the content between <<< and >>> : even if you match the wrong
=== marker, you will match the first one only, then parsing will success and
preimage file will be OK. Also because we always match in the same order the
sha1 will be the same.
Anyway, I do not know how to match the right === marker.
Olivier.
^ permalink raw reply
* Re: [PATCH] builtin-rerere: fix conflict markers parsing
From: Johannes Schindelin @ 2008-07-07 14:06 UTC (permalink / raw)
To: Olivier Marin; +Cc: Junio C Hamano, git
In-Reply-To: <48722038.1010203@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 916 bytes --]
Hi,
On Mon, 7 Jul 2008, Olivier Marin wrote:
> Johannes Schindelin a écrit :
> >
> > So what about
> >
> > <<<<<<< This hunk contains =====
> > anythin
> > =======
> >
> > Hello
> > =======
> > somethin else
> > >>>>>>> problem!
> >
> >
> > If you fix it, I think you should do it properly, and analyze the index.
>
> If I read the code correctly, this case is not a problem at all because what
> is important is the content between <<< and >>> : even if you match the wrong
> === marker, you will match the first one only, then parsing will success and
> preimage file will be OK. Also because we always match in the same order the
> sha1 will be the same.
>
> Anyway, I do not know how to match the right === marker.
Okay, but then the obvious question is: what do you do about "<<<<<<"
lines that are not a marker?
Same remark as before: if you fix rerere, why not do it properly?
Ciao,
Dscho
^ permalink raw reply
* Re: [HACK] t/test-lib.sh HACK: Add -s/--show-hack to test suite.
From: Stephan Beyer @ 2008-07-07 14:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807062241040.7342@eeepc-johanness>
Hi,
> > This option realizes a stupid hack that tries to run the test
> > cases line by line (separated by &&).
>
> In what way is that better than "sh -x t????-*.sh"?
Your suggestion is more like "./t????-*.sh -v" instead of -s, at least
on bash and dash here.
But I didn't know the -x flag and it seems that this could be used in
test-lib.sh to make the hack faster, more robust and less hacky ;-)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* BUG: make install with FileVault on Mac OS X
From: Jonathon Mah @ 2008-07-07 14:01 UTC (permalink / raw)
To: git
Hi,
(I don't subscribe to this list, so please copy me in on replies)
Mac OS X 10.5.4, Git 1.5.6.2
I use FileVault for my home directory: my files are stored on an
encrypted disk image which is mounted on my home (/Users/jonathon).
When I run "sudo make install", perllocal.pod gets written to:
/Users/jonathon/System/Library/Perl/5.8.8/darwin-thread-multi-2level/
perllocal.pod
under my home directory instead of at the root of the drive.
Presumably this is because it's writing to /System at the root of the
current mount, not at the rooty-root.
perl/perl.mak:9 reads:
# MakeMaker ARGV: (q[PREFIX=/Users/jonathon])
which is later used to prefix /System. I don't have expertise in this
area, so I'm hoping someone else can correct the error.
Thanks!
Jonathon Mah
me@JonathonMah.com
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Avery Pennarun @ 2008-07-07 14:25 UTC (permalink / raw)
To: Sylvain Joyeux
Cc: Johannes Schindelin, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <20080707062142.GA5506@jhaampe.org>
On 7/7/08, Sylvain Joyeux <sylvain.joyeux@dfki.de> wrote:
> Yes, it fetches objects (admittedly, it updates something on the current
> partition), but AFAIK does not change the state of the repository. So I thought
> that it could be considered as a no-op from the repo point of view. The idea
> behind the 'fetch' thing was to get the latest objects from the repository,
> therefore being able to know the relationship between the currently committed
> submodule state
I haven't looked at your patch, so I don't know if you're calling
fetch in such a way that it doesn't update any refs. Anyway, fetching
is definitely not a no-op as far as the user is concerned. For
example, if I'm on my laptop outside my company's LAN and I try to
fetch, it might take 30+ seconds for fetch to time out waiting for our
server. So it's not okay to fetch unless I specifically ask for a
fetch.
The trick here, I think, is that there's only one time the submodule
should be linked to a commit you don't actually have. It should only
happen if your parent module (supermodule) has been updated, but you
haven't recently done a fetch in the submodule. Thus, I'd say the
best fix would be to find a way to have "git pull" or "git fetch" in
the supermodule also do a fetch in the submodule. I think it's fair
to expect "fetchy" operations like fetch and pull to perhaps do some
extra fetches, but not fair to expect "status" to do extra work like
that.
Also note that "your supermodule links to a commit that you haven't
fetched yet" is a perfectly okay state to report to the user. I might
use a "?" or something to indicate that.
Have fun,
Avery
^ permalink raw reply
* Re: Re* [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Brian Gernhardt @ 2008-07-07 14:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Git List
In-Reply-To: <7vvdzi5fl5.fsf@gitster.siamese.dyndns.org>
On Jul 7, 2008, at 3:16 AM, Junio C Hamano wrote:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Doesn't this make the behavior of the command inconsistent between
>> "git-rebase" and "git-rebase -m"?
>
> Hmm, it makes "rebase -i" different, too. Luckily, I haven't pushed
> anything out, so I can rewind and all I lose is just a few dozens of
> minutes.
Ah, I missed the exit in the $do_merge conditional. Bah. I had
considered rebase--interactive a completely different beast and didn't
consider it at all. We've moved a little beyond my goal of "always
get git-pull to set ORIG_HEAD." However, consistency is a higher
goal. :-)
I originally only set ORIG_HEAD if rebase was operating on the current
HEAD. Now we're setting it to the original state of the branch rebase
is operating on. Thinking about it, I'm not certain this is what we
want. Should ORIG_HEAD refer the the previous state of HEAD, or to
the previous state of the current branch?
> The one from Brian has another serious issue. That patch does not
> allow
> you to refer to ORIG_HEAD during conflict resolution, which is quite
> different from how "merge" lets you use ORIG_HEAD. We need to set
> ORIG_HEAD upfront if we want to tell user that ORIG_HEAD can be
> reliably
> used across workflows the same way to name where we were before.
I was under the impression that this was not desired. I originally
get ORIG_HEAD up front, and was told that it should happen much later
in the process so that a reset during conflict resolution wouldn't
blow it away.
> When we correctly update "rebase" to do this, because one codepath
> of it
> uses "am" as its backend, we cannot use the patch I sent out
> earlier. We
> probably need to do something like this (minimally tested).
The patch looks correct to me, other than my question of what
ORIG_HEAD should be set to after "git rebase upstream other_branch".
~~ Brian
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Brian Gernhardt @ 2008-07-07 14:36 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Git List
In-Reply-To: <20080707111803.GF31490@mit.edu>
On Jul 7, 2008, at 7:18 AM, Theodore Tso wrote:
> On Sun, Jul 06, 2008 at 11:28:36PM -0700, Junio C Hamano wrote:
>> (1) ORIG_HEAD is not strictly necessary these days, because we have
>> reflogs;
>
> True, but (and please correct me if I'm wrong) ORIG_HEAD will always
> be pointing out HEAD before the user typed pretty much any git
> porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,
> it you have to paw through multiple HEAD@{n} to find the 'n' which
> corresponds to state before executing the git plumbing command, since
> multiple git plumbing commands could have updated the HEAD's reflog,
> right?
This is _exactly_ why I wanted `pull --rebase` to set ORIG_HEAD.
Reflogs are great in their own way, but having ORIG_HEAD regularly
being available for a quick way to set it back or refer to the
original state is just too useful.
~~ Brian
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-07 14:34 UTC (permalink / raw)
To: Avery Pennarun
Cc: Sylvain Joyeux, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <32541b130807070725p6fa4d0dfne9f04bc857920dc7@mail.gmail.com>
Hi,
On Mon, 7 Jul 2008, Avery Pennarun wrote:
> The trick here, I think, is that there's only one time the submodule
> should be linked to a commit you don't actually have. It should only
> happen if your parent module (supermodule) has been updated, but you
> haven't recently done a fetch in the submodule.
Noooooo!
If I am actively working on the submodule, the supermodule has _no
business_ trying to wreck my state.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-07 14:37 UTC (permalink / raw)
To: Avery Pennarun
Cc: Sylvain Joyeux, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <alpine.DEB.1.00.0807071533240.18205@racer>
Hi,
On Mon, 7 Jul 2008, Johannes Schindelin wrote:
> On Mon, 7 Jul 2008, Avery Pennarun wrote:
>
> > The trick here, I think, is that there's only one time the submodule
> > should be linked to a commit you don't actually have. It should only
> > happen if your parent module (supermodule) has been updated, but you
> > haven't recently done a fetch in the submodule.
>
> Noooooo!
>
> If I am actively working on the submodule, the supermodule has _no
> business_ trying to wreck my state.
Ooops. The part I should have quoted was this:
> Thus, I'd say the best fix would be to find a way to have "git pull" or
> "git fetch" in the supermodule also do a fetch in the submodule.
Now you will understand my objection, hopefully,
Dscho
^ permalink raw reply
* Re: [HACK] t/test-lib.sh HACK: Add -s/--show-hack to test suite.
From: Johannes Schindelin @ 2008-07-07 14:41 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git
In-Reply-To: <20080707140841.GB6726@leksak.fem-net>
Hi,
On Mon, 7 Jul 2008, Stephan Beyer wrote:
> > > This option realizes a stupid hack that tries to run the test cases
> > > line by line (separated by &&).
> >
> > In what way is that better than "sh -x t????-*.sh"?
>
> Your suggestion is more like "./t????-*.sh -v" instead of -s, at least
> on bash and dash here.
No, I meant without "-v".
> But I didn't know the -x flag and it seems that this could be used in
> test-lib.sh to make the hack faster, more robust and less hacky ;-)
It would obsolete your hack, I suggest. Obviously, you haven't tried it
yet.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-rerere: fix conflict markers parsing
From: Olivier Marin @ 2008-07-07 14:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807071505470.18205@racer>
Johannes Schindelin a écrit :
>
> Okay, but then the obvious question is: what do you do about "<<<<<<"
> lines that are not a marker?
The answer is the same.
> Same remark as before: if you fix rerere, why not do it properly?
If you have a better fix send a patch or at least give me some clues.
Olivier.
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Sylvain Joyeux @ 2008-07-07 14:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Avery Pennarun, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <alpine.DEB.1.00.0807071537070.18205@racer>
> > Thus, I'd say the best fix would be to find a way to have "git pull" or
> > "git fetch" in the supermodule also do a fetch in the submodule.
> If I am actively working on the submodule, the supermodule has _no
> business_ trying to wreck my state.
Is it possible to make 'fetch' only .. well .. fetch objects, without
updating any refs ? In that case it would wreck no state as no state
would be updated.
--
=======================================================================
Dr. Ing. Sylvain Joyeux sylvain.joyeux@dfki.de
Researcher
DFKI Robotik Lab -- Bremen http://www.dfki.de/robotik
Tel: 0049 421 218 64136
=======================================================================
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Avery Pennarun @ 2008-07-07 14:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sylvain Joyeux, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <alpine.DEB.1.00.0807071533240.18205@racer>
On 7/7/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 7 Jul 2008, Avery Pennarun wrote:
> > Thus, I'd say the best fix would be to find a way to have "git pull" or
> > "git fetch" in the supermodule also do a fetch in the submodule.
>
> Noooooo!
>
> If I am actively working on the submodule, the supermodule has _no
> business_ trying to wreck my state.
Hmm... how does doing a fetch wreck your state? I thought fetch was
supposed to be a pretty harmless operation. We're not talking about
doing a "git submodule update" automatically (which would be deadly,
albeit only because "git submodule update" is so destructive at
present).
All I'm suggesting is, when doing a "git fetch" in the supermodule,
simply do a "cd submodule && git fetch" automatically. Probably
should be optional, but seems like it could make sense for most uses,
and avoids the (probably much more common) annoyance of fetching in
the supermodule and taking my laptop on the road, only to find out
that I don't actually have all the objects I need.
On the other hand, for my own workflow I'm shifting increasingly
toward having all my "submodules" share a single repo anyway, in which
case fetching in the supermodule *would* automatically fetch all my
relevant submodule objects too.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Sylvain Joyeux @ 2008-07-07 15:00 UTC (permalink / raw)
To: Avery Pennarun
Cc: Johannes Schindelin, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <32541b130807070725p6fa4d0dfne9f04bc857920dc7@mail.gmail.com>
> I haven't looked at your patch, so I don't know if you're calling
> fetch in such a way that it doesn't update any refs.
Frankly, I don't know either. But since the question is more on a design
level, it does not matter for now.
> Thus, I'd say the
> best fix would be to find a way to have "git pull" or "git fetch" in
> the supermodule also do a fetch in the submodule. I think it's fair
> to expect "fetchy" operations like fetch and pull to perhaps do some
> extra fetches, but not fair to expect "status" to do extra work like
> that.
I do agree on the principle, it is just that I don't know where to do it
otherwise. Would the involved people be fine with a new "git submodule
fetch" command ?
> Also note that "your supermodule links to a commit that you haven't
> fetched yet" is a perfectly okay state to report to the user. I might
> use a "?" or something to indicate that.
For now, my patch shows '!' ... But I'm open to other suggestions.
Sylvain
^ permalink raw reply
* Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch
From: Brian Gernhardt @ 2008-07-07 15:03 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Theodore Tso, Junio C Hamano, Git List
In-Reply-To: <m34p71gbuk.fsf@localhost.localdomain>
On Jul 7, 2008, at 7:42 AM, Jakub Narebski wrote:
> Theodore Tso <tytso@MIT.EDU> writes:
>
>> True, but (and please correct me if I'm wrong) ORIG_HEAD will always
>> be pointing out HEAD before the user typed pretty much any git
>> porcelein command (which saves HEAD into ORIG_HEAD), but with
>> reflogs,
>> it you have to paw through multiple HEAD@{n} to find the 'n' which
>> corresponds to state before executing the git plumbing command, since
>> multiple git plumbing commands could have updated the HEAD's reflog,
>> right?
>
> You can always use _branch_ reflog, either in the <branch>@{1} form,
> or in @{1} shortcut form. @{1} should be equovalent to ORIG_HEAD
> even for rebase.
I personally expected @{1} to be identical to HEAD@{1}. Since
omitting a ref usually refers to HEAD, why shouldn't omitting it when
referring to the reflogs mean the HEAD log? The definition of @{1} is
useful since there's no other easy way to get "current branch's
reflog", but I think it's non-obvious. (Since HEAD@{1} is something
completely different, I think the only other way to refer to @{1} is $
(git symbolic-ref)@{1}.)
Also, your statement is only true if ORIG_HEAD was on the branch you
are currently working. If we want ORIG_HEAD to mean "state of HEAD
before last command", then "git rebase upstream topic" from master
should leave ORIG_HEAD pointing to master, not topic@{1}. It also is
no longer true if you switch branches. Having ORIG_HEAD set to the
point before a pull is useful to compare multiple branches to both the
old and new position of your updated branch.
If we're going to have ORIG_HEAD set by _any_ command, we should
probably come up with some consistent definition of it and set it
appropriately. The first place most people encounter ORIG_HEAD is
after a pull, where it acts something like a reverse of FETCH_HEAD
(old state of local vs. new state of remote). However, pull only sets
ORIG_HEAD by way of merge and reset sets ORIG_HEAD as well. So the
current definition appears to be "the prior state of the last branch
to be drastically changed." By this definition, ORIG_HEAD should be
set by am and rebase as per Junio's patch.
You could make an argument for removing ORIG_HEAD, it's functionality
being replaced by the reflogs. At this point, it's a rather
established bit of git, and I think has usefulness of it's own.
~~ Brian
^ permalink raw reply
* stgit error on status command
From: Jon Smirl @ 2008-07-07 15:10 UTC (permalink / raw)
To: Git Mailing List
jonsmirl@terra:~$ stg --version
Stacked GIT 0.14.3.163.g06f9
git version 1.5.6.1
Python version 2.5.2 (r252:60911, Apr 21 2008, 11:17:30)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
jonsmirl@terra:~$
jonsmirl@terra:~/fs$ stg status
Error: Unhandled exception:
Traceback (most recent call last):
File "/usr/local/lib/python2.5/site-packages/stgit/main.py", line 278, in main
ret = command.func(parser, options, args)
File "/usr/local/lib/python2.5/site-packages/stgit/commands/status.py",
line 119, in func
options.diff_flags)
File "/usr/local/lib/python2.5/site-packages/stgit/commands/status.py",
line 75, in status
diff_flags = diff_flags)
File "/usr/local/lib/python2.5/site-packages/stgit/git.py", line
255, in tree_status
for t, fn in parse_git_ls(GRun('diff-index', '-z', *args).raw_output()):
File "/usr/local/lib/python2.5/site-packages/stgit/git.py", line
201, in parse_git_ls
mode_a, mode_b, sha1_a, sha1_b, t = line.split(' ')
ValueError: need more than 1 value to unpack
jonsmirl@terra:~/fs$
jonsmirl@terra:~/fs$ git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# renamed: arch/powerpc/boot/dts/digispeaker-alpha.dts ->
arch/powerpc/boot/dts/dspeak01.dts
# renamed: arch/powerpc/platforms/52xx/digispeaker_alpha.c ->
arch/powerpc/platforms/52xx/dspeak0
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: arch/powerpc/platforms/52xx/dspeak01.c
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-07 15:21 UTC (permalink / raw)
To: Sylvain Joyeux
Cc: Avery Pennarun, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <20080707145726.GI3696@joyeux>
Hi,
On Mon, 7 Jul 2008, Sylvain Joyeux wrote:
> > > Thus, I'd say the best fix would be to find a way to have "git pull" or
> > > "git fetch" in the supermodule also do a fetch in the submodule.
> > If I am actively working on the submodule, the supermodule has _no
> > business_ trying to wreck my state.
>
> Is it possible to make 'fetch' only .. well .. fetch objects, without
> updating any refs ? In that case it would wreck no state as no state
> would be updated.
You have no business sneaking a fetch into an operation that does not need
one. Period.
If that is _still_ not enough to convince you: think about sitting in a
plane, high above the clouds. Yes, we try to support that mode of
operation.
Hthf,
Dscho
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-07 15:23 UTC (permalink / raw)
To: Avery Pennarun
Cc: Sylvain Joyeux, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <32541b130807070757s4ba03e28tf4701f479e27b687@mail.gmail.com>
Hi,
On Mon, 7 Jul 2008, Avery Pennarun wrote:
> On 7/7/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Mon, 7 Jul 2008, Avery Pennarun wrote:
> > > Thus, I'd say the best fix would be to find a way to have "git pull" or
> > > "git fetch" in the supermodule also do a fetch in the submodule.
> >
> > Noooooo!
> >
> > If I am actively working on the submodule, the supermodule has _no
> > business_ trying to wreck my state.
>
> Hmm... how does doing a fetch wreck your state?
It updates the tracking branches. And guess what I use the tracking
branches for? Yes, to track other people's changes.
It would wreck my state.
Anyway, fetch is wrong, wrong, wrong, if all you want to do is see the
_state_ of your submodule.
If that state is that the superproject has a commit that the submodule
knows nothing about, then that is _exactly_ what needs to be reported.
Don't play cute games,
Dscho
^ permalink raw reply
* Re: [PATCH] builtin-rerere: fix conflict markers parsing
From: Johannes Schindelin @ 2008-07-07 15:29 UTC (permalink / raw)
To: Olivier Marin; +Cc: Junio C Hamano, git
In-Reply-To: <48722BD9.4090406@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 920 bytes --]
Hi,
On Mon, 7 Jul 2008, Olivier Marin wrote:
> Johannes Schindelin a écrit :
> >
> > Okay, but then the obvious question is: what do you do about "<<<<<<"
> > lines that are not a marker?
>
> The answer is the same.
I think not. You say you want to do something about the ambiguity, but
fact is: the conflict markers are ambiguous. They always have been, will
ever be, and I do not even have to argue for it. Or do I?
> > Same remark as before: if you fix rerere, why not do it properly?
>
> If you have a better fix send a patch or at least give me some clues.
Did I not say that the index has enough information? Or at least hint at
it?
Of course, we could run with your solution. But that only fixes a corner
case, right?
So a proper fix will be needed eventually anyway.
And no, I will not work on it: this is not my itch, and my time is being
stolen too much already, these days.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Avery Pennarun @ 2008-07-07 15:36 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sylvain Joyeux, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <alpine.DEB.1.00.0807071621300.18205@racer>
On 7/7/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 7 Jul 2008, Avery Pennarun wrote:
> > Hmm... how does doing a fetch wreck your state?
>
> It updates the tracking branches. And guess what I use the tracking
> branches for? Yes, to track other people's changes.
>
> It would wreck my state.
>
> Anyway, fetch is wrong, wrong, wrong, if all you want to do is see the
> _state_ of your submodule.
>
> If that state is that the superproject has a commit that the submodule
> knows nothing about, then that is _exactly_ what needs to be reported.
>
> Don't play cute games,
Hmm, somehow we're not understanding each other here.
I think we have already agreed that "git status" and/or "git submodule
status" are obviously not good times to be fetching things. And a
perfectly valid "submodule status" is that your submodule can't be
updated because you're missing some objects and should fetch.
What I suggested was to recursively do "git fetch" in submodules at
the time of doing fetch or pull operations on the supermodule, in
order to help ensure that all necessary objects have been fetched. To
reference an earlier email of yours, this would *improve* git's
usability for people who try to use it on a plane, by reducing the
number of cases where they have forgotten to fetch.
(1) Do you think fetching missing submodule objects when fetching the
supermodule is a bad idea, or a good one? (2) On top of that, do you
think updating the submodule's refs when I do "git fetch" in the
supermodule is a good one (it seems you think it don't)? (3) And on
top of that, if either of those is a good idea, should it be a config
option? (4) And should that option default on or off?
In case anyone cares about my preferences, I think (1) makes sense,
(2) is probably too dangerous, (3) should be yes, or perhaps people
should be taught to run "git submodule fetch" to fetch submodules and
leave "git fetch" alone, and (4) if it's configurable, it should do it
by default, because in 99% of situations I can imagine, fetching a
supermodule and not fetching its referenced submodule commit will not
be useful behaviour.
Thanks,
Avery
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Sylvain Joyeux @ 2008-07-07 15:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Avery Pennarun, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <alpine.DEB.1.00.0807071620030.18205@racer>
On Mon, Jul 07, 2008 at 04:21:00PM +0100, Johannes Schindelin wrote:
> > > > Thus, I'd say the best fix would be to find a way to have "git pull" or
> > > > "git fetch" in the supermodule also do a fetch in the submodule.
> > > If I am actively working on the submodule, the supermodule has _no
> > > business_ trying to wreck my state.
> >
> > Is it possible to make 'fetch' only .. well .. fetch objects, without
> > updating any refs ? In that case it would wreck no state as no state
> > would be updated.
>
> You have no business sneaking a fetch into an operation that does not need
> one. Period.
Well. Given that yourself were replying to having "git fetch" fetching
submodules as well, maybe you could tell me how "git fetch" is an
operation that does not need fetching[1].
Moreover, on the "need" point, I do think that git-submodule (or git in
general) needs a way to fetch (or to git remote update) all submodules
in one operation. Otherwise, managing submodules becomes hell very
quickly.
Sylvain
[1] I know, it sounds like a smurf talking.
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Sylvain Joyeux @ 2008-07-07 15:52 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Avery Pennarun, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <alpine.DEB.1.00.0807071621300.18205@racer>
On Mon, Jul 07, 2008 at 04:23:02PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 7 Jul 2008, Avery Pennarun wrote:
>
> > On 7/7/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > On Mon, 7 Jul 2008, Avery Pennarun wrote:
> > > > Thus, I'd say the best fix would be to find a way to have "git pull" or
> > > > "git fetch" in the supermodule also do a fetch in the submodule.
> > >
> > > Noooooo!
> > >
> > > If I am actively working on the submodule, the supermodule has _no
> > > business_ trying to wreck my state.
> >
> > Hmm... how does doing a fetch wreck your state?
>
> It updates the tracking branches. And guess what I use the tracking
> branches for? Yes, to track other people's changes.
And ... I'll ask the same question again, then maybe you will be so nice
as to give me the information that you do not want to share with the
earthling that I am.
Is there no way to fetch only objects without updating no refs ?
> Anyway, fetch is wrong, wrong, wrong, if all you want to do is see the
> _state_ of your submodule.
Agreed. Now, can we move on and discuss Avery's point which was to have
a SEPARATE operation which fetches all submodules in one command ?
> Don't play cute games,
OK. Maybe you're god in the small world of git-submodule or whatever,
but could you at least *try* to explain things to people which are
trying to understand what is SOOOOOOOOOOOOOOO
HOOORRRRRRRIIIIBBBBLLLLLLLLYYYYYYYYY BAD when the only information they
have is:
THIS IS HORRIBLY BAD, GO AWAY
Sylvain
^ permalink raw reply
* Re: [PATCH] better git-submodule status output
From: Johannes Schindelin @ 2008-07-07 16:10 UTC (permalink / raw)
To: Avery Pennarun
Cc: Sylvain Joyeux, Junio C Hamano, Lars Hjemli, Ping Yin,
Mark Levedahl, git
In-Reply-To: <32541b130807070836n5c6efadu184114f7ed1476e0@mail.gmail.com>
Hi,
On Mon, 7 Jul 2008, Avery Pennarun wrote:
> What I suggested was to recursively do "git fetch" in submodules at
> the time of doing fetch or pull operations on the supermodule, in
> order to help ensure that all necessary objects have been fetched.
IMO "git submodule update" is just good enough.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn sucks when it should not
From: Avery Pennarun @ 2008-07-07 16:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Wong, git
In-Reply-To: <alpine.DEB.1.00.0807071242180.18205@racer>
On 7/7/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> # It heavily relies on curl being able to screen-scrape the directories,
> # in other words, it wants an HTTP on the other side that has directory
> # listings enabled.
I wrote a similar script myself, although it makes assumptions about
the meaning of /branches and /tags rather than using the dirs vs.
files trick.
Rather than relying on screen scraping with curl, you might prefer to
use "svn ls" instead, since it'll work with any svn-compatible
repository type and (I presume) doesn't require special web server
settings.
Have fun,
Avery
^ 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