* Re: should git download missing objects?
From: Petr Baudis @ 2006-11-14 20:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vac2v6qru.fsf@assigned-by-dhcp.cox.net>
On Mon, Nov 13, 2006 at 09:22:13PM CET, Junio C Hamano wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > ... Junio, what's its life
> > expectancy? I guess this usage scenario is something to take into
> > account when thinking about removing it, I know that I wanted to get rid
> > of it in the past but now my opinion is changing.
>
> It uses the same commit walker semantics and mechanism so I do
> not think it is too much burden to carry it, but I'd rather have
> something that works over git native protocol if we really care
> about this. People without ssh access needs to be able to
> recover over git:// protocol.
Even though I obviously agree with the above, it would be useful to have
the flag even though git:// (which is apparently harder to get right
than the others) is not supported. After all, most repositories I've
seen that are available over git:// are available over HTTP as well.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-14 19:59 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Andy Whitcroft, Junio C Hamano, git
In-Reply-To: <20061114192914.GD4299@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]
On Tue, 14 Nov 2006 14:29:14 -0500, Shawn Pearce wrote:
> Uh, see contrib/completion/git-completion.bash.
Oops. I had seen this and thought I had installed it properly a while
ago, (copied it to /etc/bash_completion.d/git), but I hadn't realized
it wasn't active in the shell I used to test while composing that
email.
> "git <TAB>" completes commands. It offers too many completions
> for your taste it sounds like, as it also offers plumbing... but
> that's fixable. :-)
Yes, I think we'd all be better off if we could designate some subset
of the current git commands as not being intended for users to type on
the command line and pulled them out of the completion scripts.
It is tough though. Looking through what's available in the short list
from "git --help" I notice that update-index isn't there, and that's
currently still required, (as we've been discussing here). But even
things as "core plumbing" as git rev-list I find extremely useful on
the command like with simple pipelines.
On the other hand, there are definitely some commands I've never
typed, and are not intended to be typed by the user. Here are a few I
see as fairly obvious just from skimming the list:
merge-*
http-*
ssh-*
upload-*
mktag
mktree
check-ref-format
...
There are a bunch of others as well. Maybe it would be easier to start
with the list in git --help and see what should be added to that.
The documentation for some of the above commands have phrases such as
"Invoked by <other command>" and "usually not invoked by the end user"
which does make the distinction quite clear. So it would be nice if
git could keep these away from the user more.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Petr Baudis @ 2006-11-14 19:47 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git
In-Reply-To: <87hcx1u934.wl%cworth@cworth.org>
On Tue, Nov 14, 2006 at 08:22:39PM CET, Carl Worth wrote:
> For reference, the latest potential batch of new users that I'm
> dealing with is the set of Fedora package maintainers who are looking
> at replacing CVS for their tree of package-building scripts. They are
> currently evaluating systems and liking the interface of hg. Here's
> the top of the current thread:
>
> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00030.html
>
> Here's the report about "git commit -a" confusion that led to my patch
> above:
>
> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html
>
> And here's my reply where I suggest that git UI might still be
> improved in these areas:
>
> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00149.html
Hmm, did they (not) consider Cogito? They wouldn't have those issues.
;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Missing features in git
From: Petr Baudis @ 2006-11-14 19:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn Pearce, Jakub Narebski, Karl Hasselström, git
In-Reply-To: <Pine.LNX.4.64.0611141037120.3327@woody.osdl.org>
On Tue, Nov 14, 2006 at 07:40:30PM CET, Linus Torvalds wrote:
> On Tue, 14 Nov 2006, Shawn Pearce wrote:
>
> > Jakub Narebski <jnareb@gmail.com> wrote:
> > > Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisa?:
> > > >
> > > > For example, we could skip the "bisect" branch, since
> > > > you aren't supposed to commit to that anyway.
> > >
> > > Well, to have "branch" to which you could not commit, just put ref
> > > outside refs/heads.
> > >
> > > Another solution would be to be able to put non-head ref in HEAD,
> > > but allow to commit only if the prefix is refs/heads/
> >
> > That's not a bad idea. Then you can checkout a tag and have
> > 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
> > $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
> > as their current branch, reminding them they are looking at the past.
There's been a brief discussion on a related topic in
http://news.gmane.org/find-root.php?message_id=%3cPine.LNX.4.58.0507120938240.17536%40g5.osdl.org%3e
(apparently the Linus-has-another-totally-awesome-idea kind (no irony
(*))). Before, Cogito did basically what's proposed above to permit
again: storing a random sha1 in the HEAD when it is seeked away to some
historical commit. It switched to using a temporary branch for this
purpose, but I'm not sure about the Linus' reasoning that
"in order for a "git checkout" to not get confused and possibly
throwing a cogito temporary head away ..."
which has been apparently clear to me back then. :-(
> I agree. This would probably be a good way to do "read-only branches".
>
> Allowing people to do a "git checkout" on anything committish, but then
> not allowing them to commit to that, is probably the right thing to do.
So, the basic relaxation is that "again after a year, HEAD does not
have to be a ref at all".
> Together with a nice readable error message from "git commit" (and merge,
> and pull - although you might well allow "fetch" to update the thing that
> current HEAD points to, though), this would be a lot easier to use for
> people who just follow somebody elses branch.
Hmm, so that there would be something like refs/tracking/master as an
alternative to refs/heads/master? I'm not really sure if it is a good
idea. On one hand, you can relax my favorite fastforward restrictions on
those tracking branches, but I think the net worth is negative since you
will have to burden new users with yet another concept of "readonly
branches", tell them things like "either do git clone --no-tracking or
the first time you will want to commit something locally, create a
'head' using git checkout -b master HEAD" (you are already on a "master"
branch but it's a different "master", you know?) etc.
(*) You never are ironical about Linus, the Chuck Norris of CS. (And a
hero, too!)
--
Petr "Pasky the Wow Pruit Igoe is
Awesome Too!" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Cleaning up git user-interface warts
From: Shawn Pearce @ 2006-11-14 19:29 UTC (permalink / raw)
To: Carl Worth; +Cc: Andy Whitcroft, Junio C Hamano, git
In-Reply-To: <87hcx1u934.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> wrote:
> 2) From git-<TAB>, (maybe the solution for this is to make
> "git <TAB>" work and only do tab-completion for the commands
> blessed enough to appear in "git --help"? Also push the tab
> completion stuff out as a standard part of packages.
Uh, see contrib/completion/git-completion.bash.
"git <TAB>" completes commands. It offers too many completions
for your taste it sounds like, as it also offers plumbing... but
that's fixable. :-)
--
^ permalink raw reply
* Cleaning up git user-interface warts
From: Carl Worth @ 2006-11-14 19:22 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Junio C Hamano, git
In-Reply-To: <455A1137.8030301@shadowen.org>
[-- Attachment #1: Type: text/plain, Size: 3070 bytes --]
On Tue, 14 Nov 2006 18:55:51 +0000, Andy Whitcroft wrote:
> Carl Worth wrote:
> > As has been discussed recently, update-index isn't intended as a
> > "porcelain" command so the mention of it in the output of git-commit
> > does lead to some user confusion.
>
> Are we sure this isn't porcelain-ish? We need to use it in merge
> conflict correction and the like? You can't use git-commit there as a
> replacement. I'd expect it to be 'git update-index' rather than
> 'git-update-index' of course.
It was Junio that recently said update-index is plumbing, not
porcelain.
So, the fact that conflict resolution still requires the use of
update-index would just be the next thing to fix. A name for a
replacement to use there could be "git resolve <paths>", (since the
old git-resolve is now officially deprecated). That's a name that
matches what hg uses in this situation, (another option is "resolved"
which is what stg uses, but I think verbs for commands work better in
general).
It would be really nice if none of the "common" commands had a hyphen
in them, for example.
And then, the next phase of my evil plan would be to introduce a -i
option for git-commit making it commit the state in the index. Then
git-commit with no options could work like "git-commit -a" does now,
(with the additional protection of not committing any unmerged
files---that is the new "git resolve" would be required before "git
commit" would work after a conflict). Users who really, really like
the current behavior of git-commit could use the new alias support to
pass the new -i option in order to maintain compatible behavior.
Then, the last thing I'd really like to fix is to allow a usage of
"git merge <branch>" instead of the awkward "git pull . <branch>".
With that, most of the user-interface warts that I regularly run into
with git would be solved. Oh, except it would also be nice to
eliminate the "plumbing" commands in a couple of places:
1) From the "man git" man page
2) From git-<TAB>, (maybe the solution for this is to make
"git <TAB>" work and only do tab-completion for the commands
blessed enough to appear in "git --help"? Also push the tab
completion stuff out as a standard part of packages.
Anyway, now I've just gone and blown all my secret plans for changing
git in ways to make it less intimidating for new users.
For reference, the latest potential batch of new users that I'm
dealing with is the set of Fedora package maintainers who are looking
at replacing CVS for their tree of package-building scripts. They are
currently evaluating systems and liking the interface of hg. Here's
the top of the current thread:
https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00030.html
Here's the report about "git commit -a" confusion that led to my patch
above:
https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html
And here's my reply where I suggest that git UI might still be
improved in these areas:
https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00149.html
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Missing features in git
From: Edgar Toernig @ 2006-11-14 18:55 UTC (permalink / raw)
To: linux; +Cc: git, linux
In-Reply-To: <20061114134958.5326.qmail@science.horizon.com>
linux@horizon.com wrote:
>
> Personally, I'd prefer if the requirement that HEAD point to
> refs/heads were enforced when checking in rather than checking out.
>
> Then you could check out an arbitrary version without any of the annoyance
> above; I could "git checkout tags/foo" or even "git checkout deadbeef~3".
> I wouldn't be on a current branch (which would necessitate changing
> "git branch" output), so HEAD would simply contain an object ID directly
> rather than being a symlink/symref.
I wholeheartedly agree. For the casual user it's IMHO the most
annoying behaviour of git that you can't simply checkout an arbitrary
commit without creating a new (most of the time temporary) branch first.
Often you don't plan to change the checked out tree and giving it a
new branch name ahead is cumbersome, especially as you know that you'll
never commit into it and have to delete the branch before checking out
another tag. I would prefer this behaviour:
$ git checkout v2.6.16
... i.e. check whether it builds
$ git checkout v2.6.17
... test this one
$ git checkout v2.6.18
... change something
$ git commit
error: can't commit. not on any branch.
use "git commit -b <new-branch-name>" to commit into a new one.
$ git commit -b my-v2.6.18
^ permalink raw reply
* Re: [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
From: Andy Whitcroft @ 2006-11-14 18:55 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, git
In-Reply-To: <87k61yt1x2.wl%cworth@cworth.org>
Carl Worth wrote:
> As has been discussed recently, update-index isn't intended as a
> "porcelain" command so the mention of it in the output of git-commit
> does lead to some user confusion.
> ---
> wt-status.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index 7dd6857..4edabcd 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -126,7 +126,7 @@ static void wt_status_print_changed_cb(s
> int i;
> if (q->nr)
> wt_status_print_header("Changed but not updated",
> - "use git-update-index to mark for commit");
> + "use \"git commit <files>\" to commit or \"git commit -a\" for all");
> for (i = 0; i < q->nr; i++)
> wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
> if (q->nr)
> --
> 1.4.3.3.gf040
Are we sure this isn't porcelain-ish? We need to use it in merge
conflict correction and the like? You can't use git-commit there as a
replacement. I'd expect it to be 'git update-index' rather than
'git-update-index' of course.
^ permalink raw reply
* Re: Missing features in git
From: Linus Torvalds @ 2006-11-14 18:40 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, Karl Hasselström, git
In-Reply-To: <20061114174939.GB4299@spearce.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1410 bytes --]
On Tue, 14 Nov 2006, Shawn Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
> > Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisa?:
> > >
> > > For example, we could skip the "bisect" branch, since
> > > you aren't supposed to commit to that anyway.
> >
> > Well, to have "branch" to which you could not commit, just put ref
> > outside refs/heads.
> >
> > Another solution would be to be able to put non-head ref in HEAD,
> > but allow to commit only if the prefix is refs/heads/
>
> That's not a bad idea. Then you can checkout a tag and have
> 'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
> $(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
> as their current branch, reminding them they are looking at the past.
I agree. This would probably be a good way to do "read-only branches".
Allowing people to do a "git checkout" on anything committish, but then
not allowing them to commit to that, is probably the right thing to do.
Together with a nice readable error message from "git commit" (and merge,
and pull - although you might well allow "fetch" to update the thing that
current HEAD points to, though), this would be a lot easier to use for
people who just follow somebody elses branch.
Junio, what do you think? It wouldn't even be backwards incompatible,
because we're strictly allowing a superset of what we used to..
Linus
^ permalink raw reply
* Re: git-rev-list: --objects list inconsistency
From: Linus Torvalds @ 2006-11-14 18:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4559E6A9.9A30A236@eudaptics.com>
On Tue, 14 Nov 2006, Johannes Sixt wrote:
>
> As you can see, without --objects, master^^..master and --max-count=2
> list the same two commits.
"--max-count=X" and "master^^..master" are two TOTALLY different things.
The fact that they happened to give the same results without "--objects"
is a random thing, and not at all guaranteed. For example, if "master" (or
its parent) had been a merge, it probably wouldn't have given the same
result even _without_ "--objects".
> But with --objects I get different object lists. I don't even know which
> one is the one to expect, but I certainly would not have expected the
> lists to be different. What's wrong here?
Nothing is wrong. You're asking for two totally different things.
With "--max-count=2", you're saying "I want the first two commits", and
then the "--objects" part extends that to all the other object types too.
So you get two commits _and_ every single object reachable from those two
commits.
In contrast, with "master^^..master", you're saying "I want everything
that is reachable from "master", but _not_ reachable from it's
grand-parent. And the "--objects" flag extends that to all the other
object types too.
So you get (in this case) two commits _and_ all the objects that are
reachable from those two commits but that are _not_ reachable from the
grandparent.
That's a totally different thing, obviously. There's likely to be a lot of
objects in common between "master" and its grandparent, and you literally
asked to not be shown those objects. In the first case, you didn't ask for
the exclusion of the grandparent.
So you should expect a big difference in almost all cases. In one case,
you ask for an exclusion, in the other case, you just say "just the first
two commits, please". Not at all equivalent.
^ permalink raw reply
* Re: git-rev-list: --objects list inconsistency
From: Junio C Hamano @ 2006-11-14 17:58 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4559E6A9.9A30A236@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> I observed a puzzling behavior of git-rev-list:
>
> $ git-rev-list master^^..master
> f3364ca9405e17772fecea1d06c40b9965b8e6e4
> bb3bfda219a85d2d49e62c261b9c8f6795ebdc22
> $ git-rev-list --max-count=2 master
> f3364ca9405e17772fecea1d06c40b9965b8e6e4
> bb3bfda219a85d2d49e62c261b9c8f6795ebdc22
> $ git-rev-list --objects master^^..master |wc -l
> 10
You are asking to get objects reachable from master but exclude
objects reachable from master^^.
> $ git-rev-list --objects --max-count=2 master |wc -l
> 2376
You are asking to get objects reachable from master and master^.
You have 2300+ objects that are common in trees of master,
master^ and master^^.
^ permalink raw reply
* Re: Missing features in git
From: Shawn Pearce @ 2006-11-14 17:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Karl Hasselström, git
In-Reply-To: <200611141845.18930.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisa?:
> >
> > For example, we could skip the "bisect" branch, since
> > you aren't supposed to commit to that anyway.
>
> Well, to have "branch" to which you could not commit, just put ref
> outside refs/heads.
>
> Another solution would be to be able to put non-head ref in HEAD,
> but allow to commit only if the prefix is refs/heads/
That's not a bad idea. Then you can checkout a tag and have
'ref: refs/tags/v1.11' in HEAD, which means anyone who puts
$(git-symbolic-ref) calls into their PS1 will see "refs/tags/v1.11"
as their current branch, reminding them they are looking at the past.
Doing bisect branch in refs/bisect rather than refs/heads/bisect
would then likewise remind the user that they are bisecting, and
since neither matches refs/heads/* you cannot commit.
--
^ permalink raw reply
* Re: [PATCH 3/5] allow cloning a repository "shallowly"
From: Junio C Hamano @ 2006-11-14 17:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611141145390.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I understand "no need making it shallow", but I am not sure if a
>> non-NULL return from lookup_object() tells us that.
>
> You are probably right, how about has_sha1_file()?
>
>> I think register_shallow() can take commits that are already shallow()
>> so maybe we can remove this "if() continue"?
>
> Yes, it can, but that is not necessarily correct: since .git/shallow is
> constructed from the registered shallow commits, we would make a commit
> shallow which is really not shallow.
>
> So, how about
>
>> > + if (lookup_object(sha1) || has_sha1_file(sha1))
>> > + continue;
If I understand the code correctly, this loop is reading what
the other side thinks your shallows should be (based on your
earlier "deepen" request or if this is initial fetch based on
your depth). Even if we already have that object, if that
object _is_ shallow on our end, don't we need to keep it marked
as shallow? Will we get ancestors of this commit from the other
end (and "shallow" lines for some of them to properly cauterize
the chain)?
^ permalink raw reply
* Re: Missing features in git
From: Jakub Narebski @ 2006-11-14 17:45 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061114173657.GC5453@diana.vm.bytemark.co.uk>
Dnia wtorek 14. listopada 2006 18:36, Karl Hasselström napisał:
>
> For example, we could skip the "bisect" branch, since
> you aren't supposed to commit to that anyway.
Well, to have "branch" to which you could not commit, just put ref
outside refs/heads.
Another solution would be to be able to put non-head ref in HEAD,
but allow to commit only if the prefix is refs/heads/
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 2/5] support fetching into a shallow repository
From: Junio C Hamano @ 2006-11-14 17:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611141140530.13772@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I think the "commit = p->item" part is trying to do a tail
>> recursion optimization, but this is a bit too clever to my
>> liking (at first I mistook that the code forgot to re-point p at
>> its parents list and incrementing cur_depth).
>
> I take it as a compliment ;-)
>
> Seriously again, would you like me to add a comment, or rather do away
> with the tail recursion optimization? It is not a huge optimization
> anyway. Maybe a cleverer way would be to use an object_array instead of a
> commit_list?
Leaving it as a compliment is just fine.
^ permalink raw reply
* Re: Missing features in git
From: Karl Hasselström @ 2006-11-14 17:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611141815.24236.jnareb@gmail.com>
On 2006-11-14 18:15:23 +0100, Jakub Narebski wrote:
> Karl Hasselström wrote:
> > On 2006-11-14 15:53:18 +0100, Jakub Narebski wrote:
>
> > > And what would happen if you want to checkout other branch?
> > > Where the ID in the HEAD would go to? HEAD just _has_ to be
> > > reference to _branch_.
> >
> > The id that used to be HEAD would not be saved anywhere. It would
> > still be reachable from your refs, presumably, just like before
> > you checked it out. (It would not be the case that you had made
> > commits on an unnamed branch that would now get lost, because the
> > tool would refuse to commit until you had created a name for the
> > branch.)
>
> If HEAD would contain an commit ID directly, then you shouldn't be
> able to commit at all.
I agree. You aren't on a branch, so you can't commit. (Of course,
creating a branch for the commit you're on is trivial: "git checkout
-b <branchname>".)
> Not very useful, it is.
Well, as long as you only want to visit the past, not change it, it
can be useful. For example, we could skip the "bisect" branch, since
you aren't supposed to commit to that anyway.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Missing features in git
From: Jakub Narebski @ 2006-11-14 17:15 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061114154739.GB5453@diana.vm.bytemark.co.uk>
Karl Hasselström wrote:
> On 2006-11-14 15:53:18 +0100, Jakub Narebski wrote:
>
>> linux@horizon.com wrote:
>>
>>> Then you could check out an arbitrary version without any of the
>>> annoyance above; I could "git checkout tags/foo" or even "git
>>> checkout deadbeef~3". I wouldn't be on a current branch (which
>>> would necessitate changing "git branch" output), so HEAD would
>>> simply contain an object ID directly rather than being a
>>> symlink/symref.
>>
>> And what would happen if you want to checkout other branch? Where
>> the ID in the HEAD would go to? HEAD just _has_ to be reference to
>> _branch_.
>
> The id that used to be HEAD would not be saved anywhere. It would
> still be reachable from your refs, presumably, just like before you
> checked it out. (It would not be the case that you had made commits on
> an unnamed branch that would now get lost, because the tool would
> refuse to commit until you had created a name for the branch.)
If HEAD would contain an commit ID directly, then you shouldn't be able
to commit at all. Not very useful, it is.
--
Jakub Narebski
^ permalink raw reply
* [PATCH] commit: Steer new users toward "git commit -a" rather than update-index
From: Carl Worth @ 2006-11-14 16:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 733 bytes --]
As has been discussed recently, update-index isn't intended as a
"porcelain" command so the mention of it in the output of git-commit
does lead to some user confusion.
---
wt-status.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 7dd6857..4edabcd 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -126,7 +126,7 @@ static void wt_status_print_changed_cb(s
int i;
if (q->nr)
wt_status_print_header("Changed but not updated",
- "use git-update-index to mark for commit");
+ "use \"git commit <files>\" to commit or \"git commit -a\" for all");
for (i = 0; i < q->nr; i++)
wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
if (q->nr)
--
1.4.3.3.gf040
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* git-rev-list: --objects list inconsistency
From: Johannes Sixt @ 2006-11-14 15:54 UTC (permalink / raw)
To: git
I observed a puzzling behavior of git-rev-list:
$ git-rev-list master^^..master
f3364ca9405e17772fecea1d06c40b9965b8e6e4
bb3bfda219a85d2d49e62c261b9c8f6795ebdc22
$ git-rev-list --max-count=2 master
f3364ca9405e17772fecea1d06c40b9965b8e6e4
bb3bfda219a85d2d49e62c261b9c8f6795ebdc22
$ git-rev-list --objects master^^..master |wc -l
10
$ git-rev-list --objects --max-count=2 master |wc -l
2376
As you can see, without --objects, master^^..master and --max-count=2
list the same two commits.
But with --objects I get different object lists. I don't even know which
one is the one to expect, but I certainly would not have expected the
lists to be different. What's wrong here?
BTW, the objects listed with --objects --max-count=2 are basically the
entire tree at master plus the few objects that changed since master^^.
$ git --version
git version 1.4.4.rc2.gc8641
-- Hannes
^ permalink raw reply
* Re: Missing features in git
From: Karl Hasselström @ 2006-11-14 15:47 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ejcl6l$bo0$1@sea.gmane.org>
On 2006-11-14 15:53:18 +0100, Jakub Narebski wrote:
> linux@horizon.com wrote:
>
> > Then you could check out an arbitrary version without any of the
> > annoyance above; I could "git checkout tags/foo" or even "git
> > checkout deadbeef~3". I wouldn't be on a current branch (which
> > would necessitate changing "git branch" output), so HEAD would
> > simply contain an object ID directly rather than being a
> > symlink/symref.
>
> And what would happen if you want to checkout other branch? Where
> the ID in the HEAD would go to? HEAD just _has_ to be reference to
> _branch_.
The id that used to be HEAD would not be saved anywhere. It would
still be reachable from your refs, presumably, just like before you
checked it out. (It would not be the case that you had made commits on
an unnamed branch that would now get lost, because the tool would
refuse to commit until you had created a name for the branch.)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Missing features in git
From: Karl Hasselström @ 2006-11-14 15:39 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20061114134958.5326.qmail@science.horizon.com>
On 2006-11-14 08:49:58 -0500, linux@horizon.com wrote:
> One feature that I noticed is missing, is that there's no easy way
> to do a "git reset --hard" while doing a "git checkout" style merge.
>
> An example of when you'd want to do this is performing a "git
> bisect" with a local "#define DEBUG 1" change. Particularly if you
> hit a non-compiling version and need to back up.
Yes, this feature would be good to have. StGIT makes it a little less
painful to hack around this limitation, but you still have to remember
popping your patches before running "git bisect good|bad".
Then again, in StGIT's case this could be solved by creating an "stg
bisect" command that takes care of this for you. But I still agree
with you that it would be a win if regular git could do as you
describe.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Missing features in git
From: Jakub Narebski @ 2006-11-14 14:53 UTC (permalink / raw)
To: git
In-Reply-To: <20061114134958.5326.qmail@science.horizon.com>
linux@horizon.com wrote:
> One thing I noticed is that with ref logs, you've just re-invented the
> CVS problem of associating history with a name. If you want to rename
> a branch (say, from "mischacks" to something suitable for publication),
> do you rename the log or not? It's a less virulent form, but it seems
> like the same disease.
Well, it would be nice to have command to rename branches (with its reflog)
and to rename tags (even in their packed format).
[...]
> Then you could check out an arbitrary version without any of the annoyance
> above; I could "git checkout tags/foo" or even "git checkout deadbeef~3".
> I wouldn't be on a current branch (which would necessitate changing
> "git branch" output), so HEAD would simply contain an object ID directly
> rather than being a symlink/symref.
And what would happen if you want to checkout other branch? Where the ID
in the HEAD would go to? HEAD just _has_ to be reference to _branch_.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Missing features in git
From: linux @ 2006-11-14 13:49 UTC (permalink / raw)
To: git; +Cc: linux
I've been writing some more git docs, and I came across a few
things git does that I'm not sure are desirable.
One thing I noticed is that with ref logs, you've just re-invented the
CVS problem of associating history with a name. If you want to rename
a branch (say, from "mischacks" to something suitable for publication),
do you rename the log or not? It's a less virulent form, but it seems
like the same disease.
Another minor quibble: AFAICT, "git checkout -f -m" is meaningless (-f
overrides -m), but doesn't complain.
One feature that I noticed is missing, is that there's no easy way to do a
"git reset --hard" while doing a "git checkout" style merge.
An example of when you'd want to do this is performing a "git bisect"
with a local "#define DEBUG 1" change. Particularly if you
hit a non-compiling version and need to back up.
The only way to do this currently is somethig like:
git checkout -b temp HEAD^
git branch -f bisect temp
git checkout bisect
git branch -d temp
or the way git-bisect does it
echo "$rev" > "$GIT_DIR/refs/heads/new-bisect"
git checkout new-bisect || exit
mv "$GIT_DIR/refs/heads/new-bisect" "$GIT_DIR/refs/heads/bisect" &&
GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD refs/heads/bisect
Either way, it reserves a second branch name, and seems like a bit of
a hack. I'm already a bit annoyed that "bisect" is reserved but not
clearly documented as such, and note that the branch name "new-bisect",
which we are switched to temporarily, does not match the pattern
"refs/heads/bisect*" that bisect_start checks for.
The only thing I don't know is if this should be a git-checkout
option or a git-reset option. The former shares far more code,
but the latter might make more logical sense.
Personally, I'd prefer if the requirement that HEAD point to
refs/heads were enforced when checking in rather than checking out.
Then you could check out an arbitrary version without any of the annoyance
above; I could "git checkout tags/foo" or even "git checkout deadbeef~3".
I wouldn't be on a current branch (which would necessitate changing
"git branch" output), so HEAD would simply contain an object ID directly
rather than being a symlink/symref.
It's a bit of a PITA auditing the code base to find everywhere affected
by changing this invariant, but it doesn't conceptually difficult.
Is there anything fundamental that this would break?
The above would make a "-b <newbranch>" option to git-commit more useful,
but it's not a half-bad idea as it is. It's just one extra command
(git checkout -b newbranch; git commit), but it takes a bit of
thinking to realize that "git checkout", which normally modifies the
working directory, won't touch your ready-to-be-committed changes in
^ permalink raw reply
* Re: [ANNOUNCE] Git Queues 0.10
From: Andreas Ericsson @ 2006-11-14 13:13 UTC (permalink / raw)
To: Josef Sipek; +Cc: git
In-Reply-To: <20061114101037.GA8075@filer.fsl.cs.sunysb.edu>
Josef Sipek wrote:
> Git Queues (aka. gq) is a series of bash scripts which add a Mercurial
> queues-like [1] functionality and interface to git.
gq-project.org
Might I suggest gitq or giq instead? gq is a fairly widespread and
established tool already.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [PATCH 4/5] allow deepening of a shallow repository
From: Johannes Schindelin @ 2006-11-14 11:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7qeze0q.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 13 Nov 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Now, by saying "git fetch -depth <n> <repo>" you can deepen
> > a shallow repository.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > commit.c | 13 +++++++++++++
> > commit.h | 3 ++-
> > fetch-pack.c | 22 ++++++++++++++++------
> > git-fetch.sh | 12 +++++++++++-
> > shallow.c | 8 ++++++--
> > upload-pack.c | 57 ++++++++++++++++++++++++++++++++++++++++++++++-----------
> > diff --git a/upload-pack.c b/upload-pack.c
> > index ebe1e5a..162dd34 100644
> > --- a/upload-pack.c
> > +++ b/upload-pack.c
> > @@ -134,6 +134,7 @@ static void create_pack_file(void)
> > } else {
> > for (i = 0; i < want_obj.nr; i++) {
> > struct object *o = want_obj.objects[i].item;
> > + o->flags &= ~UNINTERESTING;
> > add_pending_object(&revs, o, NULL);
> > }
> > for (i = 0; i < have_obj.nr; i++) {
>
> I am puzzled why this is needed in this series. In other words,
> do we have a bug in the current upload-pack that does not have
> shallow already by not clearing UNINTERESTING bit? In yet other
> words, I haven't figured out which part of the shallow series
> makes it necessary to clear UNINTERESTING bit from wanted
> object.
IIRC (has been a long time, hasn't it?) the test failed without that line,
and I was too lazy to investigate why. But ICRI ;-)
> > @@ -547,23 +554,51 @@ static void receive_needs(void)
> >...
> > + for (i = 0; i < shallows.nr; i++) {
> > + struct object *object = shallows.objects[i].item;
> > + if (object->flags & NOT_SHALLOW) {
> > + struct commit_list *parents;
> > + packet_write(1, "unshallow %s",
> > + sha1_to_hex(object->sha1));
> > + object->flags &= ~CLIENT_SHALLOW;
> > + /* make sure the real parents are parsed */
> > + unregister_shallow(object->sha1);
> > + parse_commit((struct commit *)object);
> > + parents = ((struct commit *)object)->parents;
> > + while (parents) {
> > + add_object_array(&parents->item->object,
> > + NULL, &want_obj);
> > + parents = parents->next;
> > + }
> > + }
>
> I doubt unregister_shallow() is enough to ensure that the next
> parse_commit() re-parses to recover its parents. parse_commit()
> says "if (item->object.parsed) return 0" upfront. Don't you
> need to do:
>
> object->parsed = 0;
>
> before parse_commit()?
Yes. Somehow, an important part of unregister_shallow() went missing (yet
another proof that my poor-man's-StGit does not always work). I think that
the "object->parsed = 0;" should go into unregister_shallow() like this:
diff --git a/commit.c b/commit.c
index d5103cd..4451376 100644
--- a/commit.c
+++ b/commit.c
@@ -258,6 +258,7 @@ int write_shallow_commits(int fd, int us
int unregister_shallow(const unsigned char *sha1)
{
int pos = commit_graft_pos(sha1);
+ struct commit *commit = lookup_commit(sha1);
if (pos < 0)
return -1;
if (pos + 1 < commit_graft_nr)
@@ -265,6 +266,8 @@ int unregister_shallow(const unsigned ch
sizeof(struct commit_graft *)
* (commit_graft_nr - pos - 1));
commit_graft_nr--;
+ if (commit)
+ commit->object.parsed = 0;
return 0;
}
Ciao,
Dscho
^ permalink raw reply related
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