* Re: What's in git.git (stable) and announcing GIT 1.5.0 preview
From: Robert Fitzsimons @ 2006-12-26 13:22 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emr01i$hcb$1@sea.gmane.org>
> > gitweb: Allow search to be disabled from the config file.
>
> Hmmmm... IIRC this did not removed the search form. Besides it is not like
> the basic search is expensive...
I just double checked. The search feature is enabled by default, when
the feature is disable the search form isn't shown.
I don't mind if this change is reverted.
Robert
^ permalink raw reply
* git-cvsimport and git-checkout problem
From: Hannu Koivisto @ 2006-12-26 14:13 UTC (permalink / raw)
To: git
Greetings,
I'm learning git and decided to try importing a small CVS module
into a git repository (before attempting a really big one).
Existence of -i in git-cvsimport would seem to imply that it
checkouts by default but it didn't seem to do that. That is, I did
"git-cvsimport -d ~/.cvs_root -C module module" and I got a
"module" directory that contains ".git" directory but nothing else.
And saying "git checkout master" in "module" doesn't seem to do
anything.
Finally I realized to try "git-checkout -f master" and that
worked. By reading git-checkout(1) I just cannot see why -f was
needed in this case or even what it generally does ("re-read of
everything" -- um, what everything and why would you explicitly
want to re-read that everything?).
I'm using git 1.4.4.3 and cvsps 2.1 (from a git repository
recommended by some web page) on Debian GNU/Linux.
--
Hannu
^ permalink raw reply
* Errors when updating an old git.git repository
From: Hannu Koivisto @ 2006-12-26 14:49 UTC (permalink / raw)
To: git
Greetings,
I just did "git-clone git://git.kernel.org/pub/scm/git/git.git".
git-pull in the resulting repository gives "Already up-to-date."
and "git-pull --tags" does the same. Just what I'd expect.
Before I did that, I had an old (several months) git.git repository
laying on the hard drive and I updated it with "git pull". It
complained something tag related and I tried again with "git pull
--tags". Now I'm in a situation where "git-pull --tags" gives "No
changes." but plain "git-pull" gives me this:
-------------------------------------------------------------------
remote: Generating pack...
remote: Done counting 293 objects.
remote: Result has 214 objects.
remote: Deltifying 214 objects.
remote: 14/214) done14) done
Unpacking 214 objects
remote: Total 214, written 214 (delta 156), reused 181 (delta 123)
100% (214/214) done
error: no such remote ref refs/heads/jc/bind
error: no such remote ref refs/heads/jc/bind-2
error: no such remote ref refs/heads/gb/diffdelta
* refs/heads/pu: not updating to non-fast forward branch 'pu' of git://git.kernel.org/pub/scm/git/git
old...new: 0c9951a...f959571
Already up-to-date.
-------------------------------------------------------------------
If I run either git-pull or "git-pull --tags" again, I get the same
results.
Since updating a freshly cloned repository doesn't result to such
an odd behaviour, I assume this old repository is broken somehow.
If someone wants to inspect it, I can make it available via web.
I'm using git 1.4.4.3 on Debian GNU/Linux.
--
Hannu
^ permalink raw reply
* Re: [PATCH 5/5] git-add: add ignored files when asked explicitly.
From: Johannes Schindelin @ 2006-12-26 15:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslf3khsc.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 25 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Mon, 25 Dec 2006, Junio C Hamano wrote:
> >
> >> $ git add foo.o
> >> $ git add '*.o'
> >
> > Most people do
> >
> > $ git add *.o
> >
> > instead, where bash expands the expression. Maybe this new behaviour
> > should be hidden between a "-f" option?
>
> When would anybody do "git add *.o"?
Not exactly "git add *.o", but when I see in git-status that there are
only a couple of files which are untracked, and I want them added, I
lazily do "git add *".
Ciao,
Dscho
^ permalink raw reply
* Re: Errors when updating an old git.git repository
From: Lars Hjemli @ 2006-12-26 15:37 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <87d566ww3r.fsf@trews52.bothi.fi>
On 12/26/06, Hannu Koivisto <azure@iki.fi> wrote:
> error: no such remote ref refs/heads/jc/bind
> error: no such remote ref refs/heads/jc/bind-2
> error: no such remote ref refs/heads/gb/diffdelta
I guess you have some branch references in the file
.git/remotes/origin that shouldn't be there, so you can just remove
the lines that mention 'jc/bind', 'jc/bind-2' and 'gb/diffdelta' from
that file.
> * refs/heads/pu: not updating to non-fast forward branch 'pu' of git://git.kernel.org/pub/scm/git/git
> old...new: 0c9951a...f959571
The pu branch is rebased all the time so it needs a '+' in
.git/remotes/origin to be automatically updated, like this:
Pull: +pu:pu
(or you can run 'git pull -f' to force the update)
--
larsh
^ permalink raw reply
* Re: [RFC] git reflog show
From: Johannes Schindelin @ 2006-12-26 16:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce
In-Reply-To: <7vwt4fj1cs.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 25 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Also I highly doubt visualization based on parents information rewritten
> >> to match the reflog order is of _any_ use. By rewriting the parenthood,
> >> you are losing the topology and your visualization is no better than
> >> what "tac .git/logs/$ref" would give.
> >
> > Okay, but if they are _not_ rewritten, we can reuse the log machinery to
> > show the revisions in "upstream..master@{2.hours.ago}", but in the order
> > they came into the local repository.
>
> Shawn's code was about showing where the tip of the branch was,
> and I think you are talking about something entirely different,
> which I would address later.
If I read Shawn's mail correctly, it is not only about the tip.
> The most valuable parts of the revision walking code are about ancestry
> traversal and history simplification with pathspec, neither of which
> makes much sense to use when "walking" reflog.
Sorry to be a PITA here, but I think that it _would_ make sense. Quite
often I ask myself "That feature in this file used to work. When and how
was it changed?" Right now, I use git-log with path simplification, but
with reflog walking, I could ask in a more specific way!
> But it _also_ makes sense to use reflog when the primary thing we are
> interested in seeing is not how the tip jumped around, but seeing how
> the branch acquired commits, which I think is what you are suggesting.
> What we would want to have is a sort order different from the existing
> topo or date, which is "reflog order".
I think it should not be a different sort order. As you pointed out
yourself, a "git reset --hard HEAD^" removes the assumption of the commit
list being a DAG.
Rather, I think about introducing a "get_parents(revs, commit)" function
in revision.c, which takes reflog information rather than commit->parents
if "--walk-reflogs" is passed to setup_revisions().
I hope to have a proof of concept later today.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-add: warn when adding an ignored file with an explicit request.
From: Johannes Schindelin @ 2006-12-26 16:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <empitl$t6p$1@sea.gmane.org>
Hi,
On Mon, 25 Dec 2006, Jakub Narebski wrote:
> P.S. Were all the patches sent as replies to introductory letter?
I actually don't like that convention at all. It makes for a _huge_ thread
of unrelated discussions, since most of the time the series is _exactly_
because the patches are somewhat independent (otherwise you could not
separate them).
Ciao,
Dscho
^ permalink raw reply
* Re: What's in git.git (stable) and announcing GIT 1.5.0 preview
From: Jakub Narebski @ 2006-12-26 19:02 UTC (permalink / raw)
To: Robert Fitzsimons; +Cc: git
In-Reply-To: <20061226132204.GB6558@localhost>
Robert Fitzsimons wrote:
>>> gitweb: Allow search to be disabled from the config file.
>>
>> Hmmmm... IIRC this did not removed the search form. Besides it is not like
>> the basic search is expensive...
>
> I just double checked. The search feature is enabled by default, when
> the feature is disable the search form isn't shown.
>
> I don't mind if this change is reverted.
I'm sorry. My mistake. And it is turned on by default, and not overridable
by default (checking overridable feature is one call to git-repo-config,
at least now), and I have nothing against this feature.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC] git reflog show
From: Junio C Hamano @ 2006-12-26 19:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Shawn Pearce
In-Reply-To: <Pine.LNX.4.63.0612261654330.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Shawn's code was about showing where the tip of the branch was,
>> and I think you are talking about something entirely different,
>> which I would address later.
>
> If I read Shawn's mail correctly, it is not only about the tip.
What I meant was that I did not see anything that mentions
"$ref@{ago}~47" and such; what was shown was only about the
transition between the tip.
>> The most valuable parts of the revision walking code are about ancestry
>> traversal and history simplification with pathspec, neither of which
>> makes much sense to use when "walking" reflog.
>
> Sorry to be a PITA here, but I think that it _would_ make sense. Quite
> often I ask myself "That feature in this file used to work. When and how
> was it changed?" Right now, I use git-log with path simplification, but
> with reflog walking, I could ask in a more specific way!
When you put it that way, it sort of makes sense. Right now,
get_revision() walks the chain of commits using the parent links
and the history simplification (try_to_simplify_commit) looks at
each commit and compares the tree with its parents' trees to
decide if the commit is worth considering.
If we _had_ an object type "reflog entry" which has one "parent
reflog entry" field and an associated "tip commit" object, just
like a commit object has zero or more "parent commit" field and
an associated "tree" object, the same algorithm could be taught
to follow the "parent reflog entry" chain while walking and look
at the tree associated with "tip commit" for the history
simplification purposes.
I am not proposing to introduce a new object type here, but
conceptually we could. Maybe a quick hack would be to represent
each reflog entry as a phony "struct commit" in core,
1. whose tree is taken from the tree of the tip commit,
2. whose buffer is handcrafted by the true commit log message
with data from reflog, and
3. whose parent list points at another phony "commit" that
represents ref@{N+1} reflog entry.
Then we would give a new populate_parent() member to "struct
revinfo" which is called instead of parse_object() to fill the
commit's parent list before traversal. With 1. we do not have
to touch any code for history simplification, with 2. we do not
have to touch pretty-print-commit (the result would include
whatever reflog wants to add in the message automatically), and
with 3. plus populate_parent callback would give us the
traversal.
>> But it _also_ makes sense to use reflog when the primary thing we are
>> interested in seeing is not how the tip jumped around, but seeing how
>> the branch acquired commits, which I think is what you are suggesting.
>> What we would want to have is a sort order different from the existing
>> topo or date, which is "reflog order".
>
> I think it should not be a different sort order. As you pointed out
> yourself, a "git reset --hard HEAD^" removes the assumption of the commit
> list being a DAG.
I think I misunderstood your proposal and the misunderstanding
resulted in an unrelated useful enhancement ;-). If HEAD@{0}
and HEAD@{2} points at the same commit, then obviously commits
reachable from that commit did not come into the branch no later
than HEAD@{2} time (what HEAD@{0} says becomes irrelevant), so
you can define an order that lists commits in the order the
earliest time they appeared on a branch.
^ permalink raw reply
* Re: [PATCH 5/5] git-add: add ignored files when asked explicitly.
From: Junio C Hamano @ 2006-12-26 19:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612261632360.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > Most people do
>> >
>> > $ git add *.o
>> >
>> > instead, where bash expands the expression. Maybe this new behaviour
>> > should be hidden between a "-f" option?
>>
>> When would anybody do "git add *.o"?
>
> Not exactly "git add *.o", but when I see in git-status that there are
> only a couple of files which are untracked, and I want them added, I
> lazily do "git add *".
I changed it to warn and refuse and made it only add under -f
flag.
^ permalink raw reply
* [PATCH] add git-reflog to .gitignore
From: Nicolas Pitre @ 2006-12-26 19:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
... and move git-blame with the other commands.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/.gitignore b/.gitignore
index 91e6966..60e5002 100644
--- a/.gitignore
+++ b/.gitignore
@@ -11,6 +11,7 @@ git-applypatch
git-archimport
git-archive
git-bisect
+git-blame
git-branch
git-cat-file
git-check-ref-format
@@ -88,6 +89,7 @@ git-quiltimport
git-read-tree
git-rebase
git-receive-pack
+git-reflog
git-relink
git-repack
git-repo-config
@@ -153,4 +155,3 @@ config.status
config.mak.autogen
config.mak.append
configure
-git-blame
^ permalink raw reply related
* Re: Errors when updating an old git.git repository
From: Hannu Koivisto @ 2006-12-26 19:22 UTC (permalink / raw)
To: git
In-Reply-To: <8c5c35580612260737vae2669dkac6a81fe863484d4@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 12/26/06, Hannu Koivisto <azure@iki.fi> wrote:
> I guess you have some branch references in the file
> .git/remotes/origin that shouldn't be there, so you can just remove
> the lines that mention 'jc/bind', 'jc/bind-2' and 'gb/diffdelta' from
> that file.
Thanks, but I don't need to fix the repository since a clean clone
works, I just wanted to report it so that git can be fixed, if
possible.
>> * refs/heads/pu: not updating to non-fast forward branch 'pu' of git://git.kernel.org/pub/scm/git/git
>> old...new: 0c9951a...f959571
>
> The pu branch is rebased all the time so it needs a '+' in
> .git/remotes/origin to be automatically updated, like this:
>
> Pull: +pu:pu
>
> (or you can run 'git pull -f' to force the update)
I ran 'git pull -f' and it gave me this:
-------------------------------------------------------------------
remote: Generating pack...
remote: Done counting 293 objects.
remote: Result has 214 objects.
remote: Deltifying 214 objects.
remote: 100% (214/214) done
Unpacking 214 objects
remote: Total 214, written 214 (delta 156), reused 181 (delta 123)
100% (214/214) done
error: no such remote ref refs/heads/jc/bind
error: no such remote ref refs/heads/jc/bind-2
error: no such remote ref refs/heads/gb/diffdelta
* refs/heads/pu: forcing update to non-fast forward branch 'pu' of git://git.kernel.org/pub/scm/git/git
old...new: 0c9951a...f959571
* refs/heads/man: fast forward to branch 'man' of git://git.kernel.org/pub/scm/git/git
old..new: 55beec2..da0e8b5
* refs/heads/todo: fast forward to branch 'todo' of git://git.kernel.org/pub/scm/git/git
old..new: a94df75..32e72b6
* refs/heads/next: fast forward to branch 'next' of git://git.kernel.org/pub/scm/git/git
old..new: 50dae10..9c0d79d
* refs/heads/html: fast forward to branch 'html' of git://git.kernel.org/pub/scm/git/git
old..new: 30e1db1..d793de5
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
Already up-to-date.
-------------------------------------------------------------------
Now further 'git pull's also display "Fetch failure:
git://git.kernel.org/pub/scm/git/git.git". It no longer mentions
the 'pu' branch, though.
--
Hannu
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2006-12-26 19:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emr0bt$hcb$2@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> I'd still like the preserving reflogged data during pruning and
> repacking to be optional (default to on).
What does that really _mean_?
Some time after reflog was introduced, you started talking about
it on #git channel saying "you could refer to master@{yesterday}
to get it back, but only unless you pruned".
I think that behaviour was a bug, which was there only because
reflog was bolted onto the plumbing as an afterthought. If the
data reflog keeps is integral part of git (and in v1.5.0 we are
making it so by turning it on by default), you should not have
to say "but only unless" part, which indicates loss of useful
information.
So you either keep objects that reflog entries need, or you
discard reflog entries that point at them when you discard
certain objects you do not need anymore. Removing objects
without removing reflog entries that become stale because of
missing objects takes us back to the "bolted on, not really
integrated" situation. It makes reflog "sometimes work but only
sometimes", and most likely it does not work when the user most
wants it to.
With the current code in 'next', you can discard unwanted reflog
entries using "reflog expire", and then do prune/repack, and can
be assured that the objects that remaining reflog entries want
are still there (modulo bugs -- at least that is the intent).
You could update prune/repack so that they do not look at reflog
data, and have them also remove reflog entries that have become
stale after they do their primary things (either pruning or
repacking), as part of the same invocation. I will not code
that for you because I do not think it is an improvement over
what we have now (for one thing, you cannot prune selectively,
as I already said).
> But failing that I'd
> like to have option to "reflog expire" to remove only specific
> (pattern match, prefix match?) entries, for example to remove
> all the "commit --amend" and StGIT work, but leaving rebases,
> resets, merges and other stuff.
I would say "Patches welcome"; this is not from my sarcastic
side but because I suspect there might be a remote chance that
it might turn out to be useful in some situation. It is just
that my suspicion is not strong enough to tempt me to do so
myself, because I think that even with such an elaborate
selection mechanism in place, what the users would do in
practice would boil down to what --expire-unreachable does.
^ permalink raw reply
* Re: What's in git.git (stable)
From: Luben Tuikov @ 2006-12-26 20:25 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin
Cc: git, Randal L. Schwartz, Josef Weidendorfer
In-Reply-To: <7vac1fy5ae.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> I am not quite sure about that. An old timer would work in a
> newly cloned repository after all, and what this "newbie
> protection" is breaking is not existing repositories but
> expectation from existing users.
Hmm, "newbie protection" doesn't sound good. It sounds like
"screw the old-timers and let's change well-established workflow".
The expectation is that one always pulls into origin, merges
into master, and maybe checks out master to see the remote
master. From then on, they decide what, where and how to
merge (from) master into any local branches, and then
eventually export local branches to the public.
The "^branch.\.*" options seem to be counter-intuitive to
1) git's behavor and 2) see above.
Generally "pulling" a remote master in a local branch, without
the local "origin+master" being fast-forwarded/merged should be
considered non-git-conformant behavior. Assuming that the local
branch is a branch of master/origin, which is almost ever the case.
> In any case, here is a patch for discussion.
>
> diff --git a/git-parse-remote.sh b/git-parse-remote.sh
> index f163821..b4d071b 100755
> --- a/git-parse-remote.sh
> +++ b/git-parse-remote.sh
> @@ -145,10 +145,22 @@ canon_refs_list_for_fetch () {
> merge_branches=$(git-repo-config \
> --get-all "branch.${curr_branch}.merge")
> fi
> - # If we are fetching only one branch, then first branch
> - # is the only thing that makes sense to merge anyway,
> - # so there is no point refusing that traditional rule.
> - if test $# != 1 && test "z$merge_branches" = z
> + if test "z$merge_branches" = z &&
> + # If we are fetching only one branch, then
> + # first branch is the only thing that makes
> + # sense to merge anyway, so there is no point
> + # refusing that traditional rule.
> + test $# != 1 &&
> +
> + # Also, old timers have been happily working
> + # with the first branch rule without having
> + # any branch.*.merge configuration, so if
> + # there is none, do not bother with this
> + # "newbie protection". A newly cloned
> + # repository would have branch.master.merge
> + # set for it.
It should probably have branch.*.remote _and_ branch.*.merge set
for completeness. Or we should remove the branch.* options
from git-config and leave this up to porcelains.
> + git repo-config --get-regexp \
> + '^branch\..*\.merge$' >/dev/null
How does this "set" it?
Luben
> then
> merge_branches=..this..would..never..match..
> fi
^ permalink raw reply
* Re: [PATCH 5/5] git-add: add ignored files when asked explicitly.
From: Johannes Schindelin @ 2006-12-26 22:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wmmfpfw.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 26 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> > Most people do
> >> >
> >> > $ git add *.o
> >> >
> >> > instead, where bash expands the expression. Maybe this new behaviour
> >> > should be hidden between a "-f" option?
> >>
> >> When would anybody do "git add *.o"?
> >
> > Not exactly "git add *.o", but when I see in git-status that there are
> > only a couple of files which are untracked, and I want them added, I
> > lazily do "git add *".
>
> I changed it to warn and refuse and made it only add under -f
> flag.
Thanks!
Ciao,
Dscho
^ permalink raw reply
* Re: Errors when updating an old git.git repository
From: Johannes Schindelin @ 2006-12-26 22:54 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git
In-Reply-To: <87ac1awjh0.fsf@trews52.bothi.fi>
Hi,
On Tue, 26 Dec 2006, Hannu Koivisto wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > On 12/26/06, Hannu Koivisto <azure@iki.fi> wrote:
>
> > I guess you have some branch references in the file
> > .git/remotes/origin that shouldn't be there, so you can just remove
> > the lines that mention 'jc/bind', 'jc/bind-2' and 'gb/diffdelta' from
> > that file.
>
> Thanks, but I don't need to fix the repository since a clean clone
> works, I just wanted to report it so that git can be fixed, if possible.
Git works quite as expected here, so there is nothing to fix.
> error: no such remote ref refs/heads/jc/bind
> error: no such remote ref refs/heads/jc/bind-2
> error: no such remote ref refs/heads/gb/diffdelta
Since you said it is an older git repository, I guess that in your
.git/remotes/origin are some lines like this:
Pull: refs/heads/jc/bind:refs/heads/jc/bind
So, you _asked_ git to fetch these three branches! By not providing _any_
remote, you said: "look into .git/remotes/origin". And in that file you
said: "fetch bind, bind-2 and diffdelta".
And git faithfully reports that it cannot fetch these branches (they are
no longer there) and errors out.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git reflog show
From: Johannes Schindelin @ 2006-12-26 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn Pearce
In-Reply-To: <7v64byfpic.fsf@assigned-by-dhcp.cox.net>
Hi,
On Tue, 26 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> The most valuable parts of the revision walking code are about
> >> ancestry traversal and history simplification with pathspec, neither
> >> of which makes much sense to use when "walking" reflog.
> >
> > Sorry to be a PITA here, but I think that it _would_ make sense. Quite
> > often I ask myself "That feature in this file used to work. When and
> > how was it changed?" Right now, I use git-log with path
> > simplification, but with reflog walking, I could ask in a more
> > specific way!
>
> When you put it that way, it sort of makes sense. Right now,
> get_revision() walks the chain of commits using the parent links and the
> history simplification (try_to_simplify_commit) looks at each commit and
> compares the tree with its parents' trees to decide if the commit is
> worth considering.
>
> [...]
>
> I am not proposing to introduce a new object type here, but
> conceptually we could. Maybe a quick hack would be to represent
> each reflog entry as a phony "struct commit" in core,
>
> 1. whose tree is taken from the tree of the tip commit,
>
> 2. whose buffer is handcrafted by the true commit log message
> with data from reflog, and
>
> 3. whose parent list points at another phony "commit" that
> represents ref@{N+1} reflog entry.
I see only one problem with this approach: "next..master@{0}" would stop
to work as expected.
> >> But it _also_ makes sense to use reflog when the primary thing we are
> >> interested in seeing is not how the tip jumped around, but seeing how
> >> the branch acquired commits, which I think is what you are
> >> suggesting. What we would want to have is a sort order different
> >> from the existing topo or date, which is "reflog order".
> >
> > I think it should not be a different sort order. As you pointed out
> > yourself, a "git reset --hard HEAD^" removes the assumption of the
> > commit list being a DAG.
>
> I think I misunderstood your proposal and the misunderstanding resulted
> in an unrelated useful enhancement ;-). If HEAD@{0} and HEAD@{2} points
> at the same commit, then obviously commits reachable from that commit
> did not come into the branch no later than HEAD@{2} time (what HEAD@{0}
> says becomes irrelevant), so you can define an order that lists commits
> in the order the earliest time they appeared on a branch.
I fear that this traversal is not as easy as it seems. We cannot just
blindly walk the reflogs, since the simplification relies on being able to
actually rewrite the commit_list. Also, if a commit was seen, it must be
possible to show it _again_. And if you show the commit diff, you rely on
commit->parents actually containing the rewritten parents. And the same
commit could be in revs->commits twice, and the correct reflog has still
to be shown.
So I tend to think that rewriting the parents, buffer _and_ flags is the
way to go.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] git reflog show
From: Junio C Hamano @ 2006-12-26 23:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612270006460.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I am not proposing to introduce a new object type here, but
>> conceptually we could. Maybe a quick hack would be to represent
>> each reflog entry as a phony "struct commit" in core,
>>
>> 1. whose tree is taken from the tree of the tip commit,
>>
>> 2. whose buffer is handcrafted by the true commit log message
>> with data from reflog, and
>>
>> 3. whose parent list points at another phony "commit" that
>> represents ref@{N+1} reflog entry.
>
> I see only one problem with this approach: "next..master@{0}" would stop
> to work as expected.
I was not talking about doing this as part of the usual
"rev-list". This is a special hack to support reflog, and that
is Ok, because reflog is a very special hack itself. I was
trying to rephrase what you said about reusing revision
traversal machinery for walking reflog. The actual syntax would
more likely to be:
reflog show master@{20}..master@{4} -- paths...
where you do NOT even allow handle_revision_arg() to interpret
double-dots, nor sha1_hex() to interpret master@{20}. We do not
want the real commit objects when walking reflog entries.
You are going to synthesize an imaginary commit ancestry chain
that corresponds to the reflog entries of 'master' branch (so
you would error out when your replacement handle_revision_arg()
finds either is not a reflog entry and/or talk about different
refs).
In other words, the usual "next..master@{0}" WILL not do this
phony wrapping with "imaginary reflog objects". We know it
cannot work.
>> I think I misunderstood your proposal and the misunderstanding resulted
>> in an unrelated useful enhancement ;-). If HEAD@{0} and HEAD@{2} points
>> at the same commit, then obviously commits reachable from that commit
>> did not come into the branch no later than HEAD@{2} time (what HEAD@{0}
>> says becomes irrelevant), so you can define an order that lists commits
>> in the order the earliest time they appeared on a branch.
>
> I fear that this traversal is not as easy as it seems. We cannot just
> blindly walk the reflogs, since the simplification relies on being able to
> actually rewrite the commit_list. Also, if a commit was seen, it must be
> possible to show it _again_. And if you show the commit diff, you rely on
> commit->parents actually containing the rewritten parents. And the same
> commit could be in revs->commits twice, and the correct reflog has still
> to be shown.
I think you are misunderstanding me completely. This part is
about a separate topic of using reflog when walking the real
history. We do not wrap or do anything funky like that. We
just walk the true history. We do not walk reflog at all.
Then, before you output anything, at the point you would call
topological sort, instead you would sort the commits with the
timestamp of the earliest appearance in the repository (or on
a particular branch), instead of the usual commit date. And
reflog data is how you would determine when each commit appeared
in this repository (or on this particular branch).
^ permalink raw reply
* Re: What's in git.git (stable)
From: Junio C Hamano @ 2006-12-26 23:54 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git, Randal L. Schwartz, Josef Weidendorfer
In-Reply-To: <418215.90592.qm@web31809.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
>> I am not quite sure about that. An old timer would work in a
>> newly cloned repository after all, and what this "newbie
>> protection" is breaking is not existing repositories but
>> expectation from existing users.
>
> Hmm, "newbie protection" doesn't sound good. It sounds like
> "screw the old-timers and let's change well-established workflow".
As far as I am concerned, this is a topic already closed four
days ago with commit fb8696d9.
Are you way too behind, are you rubbing it in, or am I
hallucinating and fb8696d9 did not actually fix it?
^ permalink raw reply
* Re: Errors when updating an old git.git repository
From: Junio C Hamano @ 2006-12-27 0:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Hannu Koivisto
In-Reply-To: <Pine.LNX.4.63.0612262350070.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Git works quite as expected here, so there is nothing to fix.
>
>> error: no such remote ref refs/heads/jc/bind
>> error: no such remote ref refs/heads/jc/bind-2
>> error: no such remote ref refs/heads/gb/diffdelta
>
> Since you said it is an older git repository, I guess that in your
> .git/remotes/origin are some lines like this:
>
> Pull: refs/heads/jc/bind:refs/heads/jc/bind
>
> So, you _asked_ git to fetch these three branches!
I think it only half explains the problem. Maybe my memory is
failing, but I do not recall pushing out any of these topic
branches, perhaps except jc/bind long time ago.
How did Hannu end up with these branches, both under his
$GIT_DIR/refs/heads/ and in $GIT_DIR/remotes/origin or
remote.origin.fetch in $GIT_DIR/config?
I see identical failure report from ancient time
http://article.gmane.org/gmane.comp.version-control.git/21629
Maybe I did push them out earlier.
How about doing something like this? In explain_fetch_failure
I think we could look at $ls_remote_result and automagically fix
remotes/$remote_nick or remote.$remote_nick.fetch, but I am lazy
;-)
-- >8 --
diff --git a/git-fetch.sh b/git-fetch.sh
index ffbd44f..361dfa3 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -81,6 +81,7 @@ case "$#" in
esac
remote_nick="$1"
+datasrc=$(get_data_source "$1")
remote=$(get_remote_url "$@")
refs=
rref=
@@ -272,6 +273,21 @@ then
fi
fi
+explain_fetch_failure () {
+ where=
+ case "$datasrc" in
+ '') ;;
+ config) where="remotes.$remote_nick.fetch configuration" ;;
+ branch) where=".git/branches/$remote_nick file" ;;
+ remotes) where=".git/remotes/$remote_nick file" ;;
+ esac
+ if test "z$where" != z
+ then
+ echo >&2 "You may have stale remote branches in $where"
+ echo >&2 "Remove them if they do not exist anymore."
+ fi
+}
+
fetch_main () {
reflist="$1"
refs=
@@ -325,8 +341,10 @@ fetch_main () {
break
done
)
- expr "z$head" : "z$_x40\$" >/dev/null ||
+ expr "z$head" : "z$_x40\$" >/dev/null || {
+ explain_fetch_failure
die "No such ref $remote_name at $remote"
+ }
echo >&2 "Fetching $remote_name from $remote using $proto"
git-http-fetch -v -a "$head" "$remote/" || exit
;;
@@ -385,6 +403,7 @@ fetch_main () {
case "$sha1" in
failed)
echo >&2 "Fetch failure: $remote"
+ explain_fetch_failure
exit 1 ;;
# special line coming from index-pack with the pack name
pack)
^ permalink raw reply related
* [PATCH 2/2] git-svn: dcommit should diff against the current HEAD after committing
From: Eric Wong @ 2006-12-27 0:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
In-Reply-To: <1167179258485-git-send-email-normalperson@yhbt.net>
This is a followup to dd31da2fdc199132c9fd42023aea5b33672d73cc.
Regardless of whether we commit an alternate head, we always
diff-tree based on the current HEAD, and rebase against our
remote reference as necessary.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 4288a05..c2cdceb 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -512,15 +512,15 @@ sub dcommit {
}
return if $_dry_run;
fetch();
- my @diff = command('diff-tree', $head, $gs, '--');
+ my @diff = command('diff-tree', 'HEAD', $gs, '--');
my @finish;
if (@diff) {
@finish = qw/rebase/;
push @finish, qw/--merge/ if $_merge;
push @finish, "--strategy=$_strategy" if $_strategy;
- print STDERR "W: $head and $gs differ, using @finish:\n", @diff;
+ print STDERR "W: HEAD and $gs differ, using @finish:\n", @diff;
} else {
- print "No changes between current $head and $gs\n",
+ print "No changes between current HEAD and $gs\n",
"Resetting to the latest $gs\n";
@finish = qw/reset --mixed/;
}
--
1.4.4.3.gd4ada
^ permalink raw reply related
* [PATCH 1/2] git-svn: quiet down tests and fix some unportable shell constructs
From: Eric Wong @ 2006-12-27 0:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Eric Wong
The latest changes to git-commit have made it more verbose; and
I was running the setup of the tests outside of the test_expect_*,
so errors in those were not caught. Now we move them to where
they can be eval'ed and have their output trapped.
export var=value has been removed
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t9100-git-svn-basic.sh | 258 +++++++++++++++++++++++-----------------------
1 files changed, 127 insertions(+), 131 deletions(-)
diff --git a/t/t9100-git-svn-basic.sh b/t/t9100-git-svn-basic.sh
index 0edf19e..c22fe47 100755
--- a/t/t9100-git-svn-basic.sh
+++ b/t/t9100-git-svn-basic.sh
@@ -19,180 +19,176 @@ esac
echo 'define NO_SVN_TESTS to skip git-svn tests'
-mkdir import
-cd import
-
-echo foo > foo
-if test -z "$NO_SYMLINK"
-then
- ln -s foo foo.link
-fi
-mkdir -p dir/a/b/c/d/e
-echo 'deep dir' > dir/a/b/c/d/e/file
-mkdir -p bar
-echo 'zzz' > bar/zzz
-echo '#!/bin/sh' > exec.sh
-chmod +x exec.sh
-svn import -m 'import for git-svn' . "$svnrepo" >/dev/null
-
-cd ..
-rm -rf import
-
test_expect_success \
- 'initialize git-svn' \
- "git-svn init $svnrepo"
+ 'initialize git-svn' "
+ mkdir import &&
+ cd import &&
+ echo foo > foo &&
+ if test -z '$NO_SYMLINK'
+ then
+ ln -s foo foo.link
+ fi
+ mkdir -p dir/a/b/c/d/e &&
+ echo 'deep dir' > dir/a/b/c/d/e/file &&
+ mkdir bar &&
+ echo 'zzz' > bar/zzz &&
+ echo '#!/bin/sh' > exec.sh &&
+ chmod +x exec.sh &&
+ svn import -m 'import for git-svn' . $svnrepo >/dev/null &&
+ cd .. &&
+ rm -rf import &&
+ git-svn init $svnrepo"
test_expect_success \
'import an SVN revision into git' \
'git-svn fetch'
-test_expect_success "checkout from svn" "svn co $svnrepo $SVN_TREE"
+test_expect_success "checkout from svn" "svn co $svnrepo '$SVN_TREE'"
name='try a deep --rmdir with a commit'
-git checkout -f -b mybranch remotes/git-svn
-mv dir/a/b/c/d/e/file dir/file
-cp dir/file file
-git update-index --add --remove dir/a/b/c/d/e/file dir/file file
-git commit -m "$name"
-
-test_expect_success "$name" \
- "git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch &&
- svn up $SVN_TREE &&
- test -d $SVN_TREE/dir && test ! -d $SVN_TREE/dir/a"
+test_expect_success "$name" "
+ git checkout -f -b mybranch remotes/git-svn &&
+ mv dir/a/b/c/d/e/file dir/file &&
+ cp dir/file file &&
+ git update-index --add --remove dir/a/b/c/d/e/file dir/file file &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch &&
+ svn up '$SVN_TREE' &&
+ test -d '$SVN_TREE'/dir && test ! -d '$SVN_TREE'/dir/a"
name='detect node change from file to directory #1'
-mkdir dir/new_file
-mv dir/file dir/new_file/file
-mv dir/new_file dir/file
-git update-index --remove dir/file
-git update-index --add dir/file/file
-git commit -m "$name"
-
-test_expect_failure "$name" \
- 'git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch' \
- || true
+test_expect_failure "$name" "
+ mkdir dir/new_file &&
+ mv dir/file dir/new_file/file &&
+ mv dir/new_file dir/file &&
+ git update-index --remove dir/file &&
+ git update-index --add dir/file/file &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch" || true
name='detect node change from directory to file #1'
-rm -rf dir $GIT_DIR/index
-git checkout -f -b mybranch2 remotes/git-svn
-mv bar/zzz zzz
-rm -rf bar
-mv zzz bar
-git update-index --remove -- bar/zzz
-git update-index --add -- bar
-git commit -m "$name"
-
-test_expect_failure "$name" \
- 'git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch2' \
- || true
+test_expect_failure "$name" "
+ rm -rf dir '$GIT_DIR'/index &&
+ git checkout -f -b mybranch2 remotes/git-svn &&
+ mv bar/zzz zzz &&
+ rm -rf bar &&
+ mv zzz bar &&
+ git update-index --remove -- bar/zzz &&
+ git update-index --add -- bar &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch2" || true
name='detect node change from file to directory #2'
-rm -f $GIT_DIR/index
-git checkout -f -b mybranch3 remotes/git-svn
-rm bar/zzz
-git-update-index --remove bar/zzz
-mkdir bar/zzz
-echo yyy > bar/zzz/yyy
-git-update-index --add bar/zzz/yyy
-git commit -m "$name"
-
-test_expect_failure "$name" \
- 'git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch3' \
- || true
+test_expect_failure "$name" "
+ rm -f '$GIT_DIR'/index &&
+ git checkout -f -b mybranch3 remotes/git-svn &&
+ rm bar/zzz &&
+ git-update-index --remove bar/zzz &&
+ mkdir bar/zzz &&
+ echo yyy > bar/zzz/yyy &&
+ git-update-index --add bar/zzz/yyy &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch3" || true
name='detect node change from directory to file #2'
-rm -f $GIT_DIR/index
-git checkout -f -b mybranch4 remotes/git-svn
-rm -rf dir
-git update-index --remove -- dir/file
-touch dir
-echo asdf > dir
-git update-index --add -- dir
-git commit -m "$name"
-
-test_expect_failure "$name" \
- 'git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch4' \
- || true
+test_expect_failure "$name" "
+ rm -f '$GIT_DIR'/index &&
+ git checkout -f -b mybranch4 remotes/git-svn &&
+ rm -rf dir &&
+ git update-index --remove -- dir/file &&
+ touch dir &&
+ echo asdf > dir &&
+ git update-index --add -- dir &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch4" || true
name='remove executable bit from a file'
-rm -f $GIT_DIR/index
-git checkout -f -b mybranch5 remotes/git-svn
-chmod -x exec.sh
-git update-index exec.sh
-git commit -m "$name"
-
-test_expect_success "$name" \
- "git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
- svn up $SVN_TREE &&
- test ! -x $SVN_TREE/exec.sh"
+test_expect_success "$name" "
+ rm -f '$GIT_DIR'/index &&
+ git checkout -f -b mybranch5 remotes/git-svn &&
+ chmod -x exec.sh &&
+ git update-index exec.sh &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch5 &&
+ svn up '$SVN_TREE' &&
+ test ! -x '$SVN_TREE'/exec.sh"
name='add executable bit back file'
-chmod +x exec.sh
-git update-index exec.sh
-git commit -m "$name"
-
-test_expect_success "$name" \
- "git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
- svn up $SVN_TREE &&
- test -x $SVN_TREE/exec.sh"
-
+test_expect_success "$name" "
+ chmod +x exec.sh &&
+ git update-index exec.sh &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch5 &&
+ svn up '$SVN_TREE' &&
+ test -x '$SVN_TREE'/exec.sh"
if test -z "$NO_SYMLINK"
then
name='executable file becomes a symlink to bar/zzz (file)'
- rm exec.sh
- ln -s bar/zzz exec.sh
- git update-index exec.sh
- git commit -m "$name"
- test_expect_success "$name" \
- "git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
- svn up $SVN_TREE &&
- test -L $SVN_TREE/exec.sh"
+ test_expect_success "$name" "
+ rm exec.sh &&
+ ln -s bar/zzz exec.sh &&
+ git update-index exec.sh &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch5 &&
+ svn up '$SVN_TREE' &&
+ test -L '$SVN_TREE'/exec.sh"
name='new symlink is added to a file that was also just made executable'
- chmod +x bar/zzz
- ln -s bar/zzz exec-2.sh
- git update-index --add bar/zzz exec-2.sh
- git commit -m "$name"
- test_expect_success "$name" \
- "git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
- svn up $SVN_TREE &&
- test -x $SVN_TREE/bar/zzz &&
- test -L $SVN_TREE/exec-2.sh"
+ test_expect_success "$name" "
+ chmod +x bar/zzz &&
+ ln -s bar/zzz exec-2.sh &&
+ git update-index --add bar/zzz exec-2.sh &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch5 &&
+ svn up '$SVN_TREE' &&
+ test -x '$SVN_TREE'/bar/zzz &&
+ test -L '$SVN_TREE'/exec-2.sh"
name='modify a symlink to become a file'
- echo git help > help || true
- rm exec-2.sh
- cp help exec-2.sh
- git update-index exec-2.sh
- git commit -m "$name"
-
- test_expect_success "$name" \
- "git-svn set-tree --find-copies-harder --rmdir remotes/git-svn..mybranch5 &&
- svn up $SVN_TREE &&
- test -f $SVN_TREE/exec-2.sh &&
- test ! -L $SVN_TREE/exec-2.sh &&
- diff -u help $SVN_TREE/exec-2.sh"
+ test_expect_success "$name" "
+ echo git help > help || true &&
+ rm exec-2.sh &&
+ cp help exec-2.sh &&
+ git update-index exec-2.sh &&
+ git commit -m '$name' &&
+ git-svn set-tree --find-copies-harder --rmdir \
+ remotes/git-svn..mybranch5 &&
+ svn up '$SVN_TREE' &&
+ test -f '$SVN_TREE'/exec-2.sh &&
+ test ! -L '$SVN_TREE'/exec-2.sh &&
+ diff -u help $SVN_TREE/exec-2.sh"
fi
if test "$have_utf8" = t
then
name="commit with UTF-8 message: locale: $GIT_SVN_LC_ALL"
- echo '# hello' >> exec-2.sh
- git update-index exec-2.sh
- git commit -m 'éïâˆ'
- export LC_ALL="$GIT_SVN_LC_ALL"
- test_expect_success "$name" "git-svn set-tree HEAD"
+ LC_ALL="$GIT_SVN_LC_ALL"
+ export LC_ALL
+ test_expect_success "$name" "
+ echo '# hello' >> exec-2.sh &&
+ git update-index exec-2.sh &&
+ git commit -m 'éïâˆ' &&
+ git-svn set-tree HEAD"
unset LC_ALL
else
echo "UTF-8 locale not set, test skipped ($GIT_SVN_LC_ALL)"
--
1.4.4.3.gd4ada
^ permalink raw reply related
* Re: Errors when updating an old git.git repository
From: Hannu Koivisto @ 2006-12-27 0:45 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612262350070.19693@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 26 Dec 2006, Hannu Koivisto wrote:
>
> Git works quite as expected here, so there is nothing to fix.
Since the documentation didn't seem to specify what happens when a
remote branch is deleted (I'm assuming that's the case), _I_ didn't
expect it.
>> error: no such remote ref refs/heads/jc/bind
>> error: no such remote ref refs/heads/jc/bind-2
>> error: no such remote ref refs/heads/gb/diffdelta
>
> Since you said it is an older git repository, I guess that in your
> .git/remotes/origin are some lines like this:
>
> Pull: refs/heads/jc/bind:refs/heads/jc/bind
>
> So, you _asked_ git to fetch these three branches!
Well, that's true from a technical standpoint, but I didn't add
those lines to .git/remotes/origin, git did when I cloned the
repository. When one updates tracking branches and a branch has
been deleted in the remote repository, I think it wouldn't be
insane to expect git also to remove the line (if not the actual
branch). If that is not desired, I'd rather the message wasn't an
error but something along the lines of "note: remote branch jc/bind
no longer exists, please update .git/remotes/origin". It's bit odd
to get errors in a situation that (given the assumption) isn't
erroneous.
--
Hannu
^ permalink raw reply
* Re: Errors when updating an old git.git repository
From: Junio C Hamano @ 2006-12-27 0:58 UTC (permalink / raw)
To: Hannu Koivisto; +Cc: git, Johannes Schindelin
In-Reply-To: <877iwew4iw.fsf@trews52.bothi.fi>
Hannu Koivisto <azure@iki.fi> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
>> So, you _asked_ git to fetch these three branches!
>
> Well, that's true from a technical standpoint, but I didn't add
> those lines to .git/remotes/origin, git did when I cloned the
> repository. When one updates tracking branches and a branch has
> been deleted in the remote repository, I think it wouldn't be
> insane to expect git also to remove the line (if not the actual
> branch). If that is not desired, I'd rather the message wasn't an
> error but something along the lines of "note: remote branch jc/bind
> no longer exists, please update .git/remotes/origin". It's bit odd
> to get errors in a situation that (given the assumption) isn't
> erroneous.
I would be a bit reluctant to remove tracking automagically, but
I fully agree that a comment like that would be needed.
Patches?
^ permalink raw reply
* Re: What's in git.git (stable)
From: Luben Tuikov @ 2006-12-27 1:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Randal L. Schwartz, Josef Weidendorfer
In-Reply-To: <7vd566ciwq.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> >> I am not quite sure about that. An old timer would work in a
> >> newly cloned repository after all, and what this "newbie
> >> protection" is breaking is not existing repositories but
> >> expectation from existing users.
> >
> > Hmm, "newbie protection" doesn't sound good. It sounds like
> > "screw the old-timers and let's change well-established workflow".
>
> As far as I am concerned, this is a topic already closed four
> days ago with commit fb8696d9.
>
> Are you way too behind, are you rubbing it in, or am I
> hallucinating and fb8696d9 did not actually fix it?
I'm behind. I'll pull and take a look at that commit.
Luben
^ 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