* What's in git.git tonight
From: Junio C Hamano @ 2005-12-17 9:37 UTC (permalink / raw)
To: git
Since 0.99.9n, there have been a couple of fixes and some
documentation updates. One notable is that we do not allow '?',
'*' and '[' in ref names anymore --- this was done after the
list discussion with Pasky and friends.
Another notable is "We do not like HEAD branch" patch, but I've
been thinking seriously about reverting it and replace its
effect by also reverting the misguided attempt to disambiguate
branch names and tag names. This patch with a commit message
will follow in a separate message; it currently lives in the
proposed updates branch. One positive effect this change brings
is that it fixes a corner case bug/confusion Johannes mentioned
the other day while diagnosing the trouble Len had with his
repository (I do not think the problem has anything to do with
Len's trouble, though). If you have a branch called "dead", and
you also have a tag called "dead", and if your repository has
only one object whose name begins with "dead"
(e.g. "deadbeef1234..."), "git rev-parse --verify dead" would
pick up the "deadbeef1234..." object, not "dead" tag nor "dead"
head. When no such object exists, "git rev-parse --verify dead"
fails, saying "dead" is ambiguous between heads and tags. This
is just confused, and "reverting the misguided disambiguation"
change will make it pick up the "dead" tag in either case. Most
likely I'll have it in "master" after further testing over the
weekend.
One important patch waiting in the proposed updates is to give
an option to git-fetch-pack to keep the downloaded pack without
unpacking it; this was primarily done to help Cogito, but I
haven't heard back about it from Pasky yet. The primary
difference between this and the clone-pack change that is
already in the master branch, from the user's point of view, is
that git-fetch-pack can be efficiently used in an already
populated repository [*1*]. Imagine cloning "master" branch
from linux-2.6 repository of Linus, and then fetching ALL branch
from libata-dev repository of Jeff --- the difference is large
enough that you would want to keep the downloaded stuff packed,
while you do want to take advantage of the fact that you already
have objects from Linus. Currently it saves exploding about a
~800K pack with 1100 objects in it. Although I mentioned we are
supposed to be in deep feature freeze, I feel it is worth to
have this one in 1.0.
[Footnote]
*1* Theoretically we could deprecate git-clone-pack and use
git-fetch-pack exclusively, if we are willing to create refs
matching what the remote has in the wrapper script git-clone.
^ permalink raw reply
* Re: qgit reports errors in the git repository
From: Junio C Hamano @ 2005-12-17 9:36 UTC (permalink / raw)
To: Marco Costalba; +Cc: Pavel Roskin, git
In-Reply-To: <e5bfff550512170044v59f96262ica6511e981889ea9@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> Using
>
> git-clone http://digilander.libero.it/mcostalba/qgit.git qgit_test
>
> does not work (never did). Peraphs it's time I dig a little bit deeper.
Do you keep qgit.git/info/refs, qgit.git/objects/info/packs, and
possibly qgit.git/objects/info/alternates up-to-date under
http://digilander.libero.it/mcostalba/? Your server seems to
give friendly "no such page" instead of usual 404 not found for
nonexisting paths, which means that you would probably need to
have an empty info/alternates file there, and if you do not have
packs then empty info/packs files as well.
Also I suspect once you start packing your repository the
downloaders would have a hard time --- instead of getting "not
found" as a cue to switch to fetching packs they would get the
"friendly page" and mistakenly think the loose object stored in
your repository is corrupt.
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-17 9:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512162342010.3698@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> That said, I think a lot of newbies might want to have a "git undo", and
> not because of any BK history. Even if it just ends up being nothing but
> shorthand for "git reset --hard ORIG_HEAD".
I agree to this in principle, but I am afraid "git undo" is too
generic and fuzzy a term. Things you might possibly want to
undo depends on what you did last [*1*]. In most undoable
cases, "reset --hard" is almost right but most likely would
result in information loss.
If we want to really newbie-proof the "undo" command, I think
the hard ones are not the ones that can be approximated with
reset ORIG_HEAD, but other "No way to undo" ones and "Nothing to
undo" ones.
Earlier on the list I gave an overview on merge for an unnamed
person with only an e-mail address, and one thing struck me as
quite hard to explain was that there are two kinds of "merge
failures" --- ones that did not even start the merge and ones
that failed in the middle due to conflicts. Somebody totally
new to git, after seeing "git pull" to fail in the first kind,
would get scared and type "git undo". We could prevent doing
damage by making sure we remove ORIG_HEAD in "Nothing to undo"
situations, but if we say "Nothing to undo" when the user types
"git undo" in such a situation, we will surely hear "what do you
mean? the command said failed to pull and I wanted to recover
from that!".
It also is not clear if it is wise to clear ORIG_HEAD for "No
way to undo" ones. Doing so would rob useful undo information
from people who know git and expect "No way to undo" ones do not
muck with the existing ORIG_HEAD.
Even for the ones that we would do "reset --hard ORIG_HEAD",
many lose information, and "undo" to me implies "undo only what
the last command messed up", which is not what actually happens.
The word "reset" does not have that connotation -- it takes you
to some defined state, which may be close to what you had before
but may not be exactly the same if you had local changes in your
tree. HEAD, ORIG_HEAD, and HEAD^ are such defined states you
can go, and the user gives where he wants to go explicitly.
"undo" does not really say where to go and hides halfway what we
do, without doing exactly what the user would expect (and cannot
be implemented fully unless we are willing to take a snapshot of
working tree, I suspect).
[Appendix]
*1* List of commands that a user might want to undo.
A merge or non-merge commit, cherry-pick, and revert::
reset --hard HEAD^ ;# this can be helped by leaving ORIG_HEAD
# but "--hard" is not quite right;
# your working tree could have been
# dirty at irrelevant paths
A fetch fast-forwarding non-current branch::
No way to undo -- we do not keep the old information.
A merge, that was fast-forward::
reset ORIG_HEAD ;# never "--hard" -- your working tree could
# have been dirty and in this case
# there is no information loss.
A merge attempt, conflicted::
reset --hard ORIG_HEAD
# again, "--hard" is not quite right --
# your working tree could have been
# dirty at irrelevant paths.
A merge attempt, did not even start because index or tree was dirty::
Nothing to undo.
A successful checkout (switch branch)::
No way to undo -- we do not keep the old information.
git-update-index and git-add::
No way to really undo -- we do not keep the old
information. The closest is "git reset" but it reverts
more than the last operation.
rebase::
reset --hard ORIG_HEAD
am/applymbox::
No way to undo -- we do not keep the old information.
;# this can be helped by leaving ORIG_HEAD
^ permalink raw reply
* Re: bad git pull
From: Linus Torvalds @ 2005-12-17 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy82kbiho.fsf@assigned-by-dhcp.cox.net>
On Fri, 16 Dec 2005, Junio C Hamano wrote:
>
> You guys were on BK for how many months, and have been on git
> for how many months now? Do BK-familiarity factor matter, and
> will it continue to matter for how long?
I don't think it is a huge deal, I suspect that people who used BK have a
much easier time with git if only because they already understand the
whole distributed thing and about commits and merges.
That said, I think a lot of newbies might want to have a "git undo", and
not because of any BK history. Even if it just ends up being nothing but
shorthand for "git reset --hard ORIG_HEAD".
Linus
^ permalink raw reply
* Re: qgit reports errors in the git repository
From: Junio C Hamano @ 2005-12-17 6:55 UTC (permalink / raw)
To: Marco Costalba; +Cc: Pavel Roskin, git
In-Reply-To: <e5bfff550512161247v4c187cc0gedae8234d454c3b6@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
>> > So perpahs this assumption is broken and works only on my box.
>> >
>> > Can you please send me also the git-ls-remote ./.git output?
>>
>> Attached. Apparently my sort (coreutils 5.2.1) thinks that caret
>> follows period in C locale, so v0.99^{} goes after v0.99.9n^{}. Since
>> there should be a reason for sort in git-ls-remote.sh, I assume it's the
>> script that should be fixed.
>>
>> Not that I would object against qgit being more robust :-)
Somehow I am getting your message without the message your
message is a reply to, but anyway, guessing without having
access to qgit source [*1*], you seem to be running ls-remote
against the local repository, reading its output and deciding if
"xyzzy" is followed immediately by "xyzzy^{}" then it is a tag
otherwise it is a non tag object?
If you are always doing that against the local repository, then
peek-remote would be more efficient, does not sort, and
"xyzzy^{}" comes immediately after "xyzzy", which I do not see
an immediate need of changing.
[Footnote]
*1* Why is that http:// URL does not work is mystery to me which
I do not particularly interested in figuring out myself. Maybe
the site is trying to be too helpful and showing "Oh where do
you want to go" page with status 200 which confuses the h*ck out
of downloaders?
^ permalink raw reply
* Re: [PATCH] Fix git-am --skip
From: Junio C Hamano @ 2005-12-17 6:41 UTC (permalink / raw)
To: Jan Harkes; +Cc: git
In-Reply-To: <20051217060106.GS30531@delft.aura.cs.cmu.edu>
Thanks.
^ permalink raw reply
* [PATCH] Fix git-am --skip
From: Jan Harkes @ 2005-12-17 6:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
git-am --skip does not unpack the next patch and ends up reapplying the
old patch, believing that it is the new patch in the sequence.
If the old patch applied successfully it will commit it with the
supposedly skipped log message and ends up dropping the following patch.
If the patch did not apply the user is left with the conflict he tried
to skip and has to unpack the next patch in the sequence by hand to get
git-am back on track.
By clearing the resume variable whenever skips bumps the sequence
counter we correctly unpack the next patch. I also added another
resume= in the case a patch file is missing from the sequence to
avoid the same problem when a file in the sequence was removed.
Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>
---
git-am.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
5cfce3a48e6a6cf08caa5fae990eeeaf08154921
diff --git a/git-am.sh b/git-am.sh
index 1a114bc..731ab1f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -211,6 +211,7 @@ this=`cat "$dotest/next"`
if test "$skip" = t
then
this=`expr "$this" + 1`
+ resume=
fi
if test "$this" -gt "$last"
@@ -225,6 +226,7 @@ do
msgnum=`printf "%0${prec}d" $this`
next=`expr "$this" + 1`
test -f "$dotest/$msgnum" || {
+ resume=
go_next
continue
}
--
0.99.9.GIT
^ permalink raw reply related
* Re: git merge questions
From: Junio C Hamano @ 2005-12-17 3:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Don Zickus, git
In-Reply-To: <Pine.LNX.4.63.0512170056380.11000@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> just a thought: maybe in this case -- git fails to recognize a rename --
> Pasky's idea would have some merit.
It is not as simple as that. If you look at the output of the
following command, you would understand why.
$ git rev-list ^$(git merge-base test test2) test2 -- \
arch/powerpc/Kconfig arch/ppc64/Kconfig |
git diff-tree --pretty -C -r --stdin --abbrev --name-status \
arch/powerpc/Kconfig arch/ppc64/Kconfig
The transition happened over time with multiple commits.
First ppc64/Kconfig was somewhat stripped of its contents,
starting at this commit:
diff-tree bcdd1ea... (from 5bfc826...)
Author: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon Sep 19 23:13:24 2005 +1000
[PATCH] powerpc: Move arch/ppc*/oprofile/Kconfig to arch/powerpc
These files are identical.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul Mackerras <paulus@samba.org>
M arch/ppc64/Kconfig
and after a lot of hard work, powerpc/Kconfig gets
created.
diff-tree 14cf11a... (from e5baa39...)
Author: Paul Mackerras <paulus@samba.org>
Date: Mon Sep 26 16:04:21 2005 +1000
powerpc: Merge enough to start building in arch/powerpc.
This creates the directory structure under arch/powerpc and a bunch
of Kconfig files...
A arch/powerpc/Kconfig
After that both continues to exist for some time, and finally
ppc64/Kconfig gets deleted with this one:
diff-tree 7568cb4... (from c55377e...)
Author: Paul Mackerras <paulus@samba.org>
Date: Mon Nov 14 17:30:17 2005 +1100
powerpc: Move most remaining ppc64 files over to arch/powerpc
Also deletes files in arch/ppc64 that are no longer used now that
we don't compile with ARCH=ppc64 any more.
Signed-off-by: Paul Mackerras <paulus@samba.org>
M arch/powerpc/Kconfig
D arch/ppc64/Kconfig
You cannot record "this is the rename" by attributing that
information to one particular commit. Even looking at the
commit history one by one you cannot really say powerpc/Kconfig
is a rename of ppc64/Kconfig. I suspect that it is not really a
rename --- from reading of the log messages, its original
contents were moved around and scattered over to other Kconfig
files in the tree, or along with other configuration pieces got
consolidated into powerpc/Kconfig, or perhaps both.
^ permalink raw reply
* Re: bad git pull
From: Junio C Hamano @ 2005-12-17 2:19 UTC (permalink / raw)
To: Morten Welinder; +Cc: Linus Torvalds, Don Zickus, git
In-Reply-To: <118833cc0512161637v1d180f9fh66a7dc6d3fe11d2b@mail.gmail.com>
Morten Welinder <mwelinder@gmail.com> writes:
>> - undo the last commit entirely ("hard reset to previous state"):
>>
>> - undo the last pull ("bk unpull"): "hard reset to ORIG_HEAD":
>
> It would be outright peachy if Documentation/git-commit.txt and
> Documentation/git-pull.txt mentioned these. That is certainly
> where I would look first to answer the "what if I screwed up?"
> question.
Yup. Maybe one line comment at the bottom of these manual pages
pointing at git-reset manual page (which has nice examples
section) would be good enough?
-- >8 --
[PATCH] Examples of resetting.
Morten Welinder says examples of resetting is really about
recovering from botched commit/pulls. I agree that pointers
from commands that cause a reset to be needed in the first place
would be very helpful.
Also reset examples did not mention "pull/merge" cases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index b92cf48..8b91f22 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -66,6 +66,10 @@ OPTIONS
Update specified paths in the index file before committing.
+If you make a commit and then found a mistake immediately after
+that, you can recover from it with gitlink:git-reset[1].
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 0cac563..4ce799b 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -37,6 +37,11 @@ include::merge-options.txt[]
include::merge-strategies.txt[]
+If you tried a merge which resulted in a complex conflicts and
+would want to start over, you can recover with
+gitlink:git-reset[1].
+
+
HOW MERGE WORKS
---------------
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index c65ca9a..3a7d385 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -104,6 +104,11 @@ merge the remote `origin` head into the
local `master` branch.
+If you tried a pull which resulted in a complex conflicts and
+would want to start over, you can recover with
+gitlink:git-reset[1].
+
+
SEE ALSO
--------
gitlink:git-fetch[1], gitlink:git-merge[1]
diff --git a/Documentation/git-reset.txt b/Documentation/git-reset.txt
index 0204891..c6a269b 100644
--- a/Documentation/git-reset.txt
+++ b/Documentation/git-reset.txt
@@ -111,6 +111,39 @@ remain there.
changes still in the working tree.
------------
+Undo a merge or pull::
++
+------------
+$ git pull <1>
+Trying really trivial in-index merge...
+fatal: Merge requires file-level merging
+Nope.
+...
+Auto-merging nitfol
+CONFLICT (content): Merge conflict in nitfol
+Automatic merge failed/prevented; fix up by hand
+$ git reset --hard <2>
+
+<1> try to update from the upstream resulted in a lot of
+conflicts; you were not ready to spend a lot of time merging
+right now, so you decide to do that later.
+<2> "pull" has not made merge commit, so "git reset --hard"
+which is a synonym for "git reset --hard HEAD" clears the mess
+from the index file and the working tree.
+
+$ git pull . topic/branch <3>
+Updating from 41223... to 13134...
+Fast forward
+$ git reset --hard ORIG_HEAD <4>
+
+<3> merge a topic branch into the current branch, which resulted
+in a fast forward.
+<4> but you decided that the topic branch is not ready for public
+consumption yet. "pull" or "merge" always leaves the original
+tip of the current branch in ORIG_HEAD, so resetting hard to it
+brings your index file and the working tree back to that state,
+and resets the tip of the branch to that commit.
+------------
Author
------
^ permalink raw reply related
* Re: bad git pull
From: Junio C Hamano @ 2005-12-17 1:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512161701400.3698@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Or maybe "git commit" should always _write_ ORIG_HEAD with the old head,
> so that we can always do an "undo" by doing "git reset --hard ORIG_HEAD"
> regardless of whether the last thing was a "git commit" or a "git pull".
>
> Hmm?
If we define "git undo" as "Revert the tree to the state one
before the last successfull commit/pull", then overwriting
ORIG_HEAD as you say at the commit time and always using "git
reset --hard ORIG_HEAD" would make sense.
I fail to see the merit of "git undo/unpull/unmerge/..."; mostly
because I have never seen BK and do not benefit from the
familiarity factor at all. To people without BK experience,
having too many synonyms (e.g. "git undo" does something magical
by feeding "git reset --hard" with ORIG_HEAD) might be just more
noise and confusion. I can see them asking "why are there two
ways to do identical things?".
However, the reason I am maintaining git is not to make it
useful for _me_, but to make it useful for the kernel people, so
if these BK-like synonyms help them, I'm all for it. If we are
going to do that, somebody needs to describe what should each
command do in each case in detail, because I do not know BK at
all.
You guys were on BK for how many months, and have been on git
for how many months now? Do BK-familiarity factor matter, and
will it continue to matter for how long?
^ permalink raw reply
* Re: git merge questions
From: Junio C Hamano @ 2005-12-17 1:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Don Zickus, git
In-Reply-To: <Pine.LNX.4.63.0512170056380.11000@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> just a thought: maybe in this case -- git fails to recognize a rename --
> Pasky's idea would have some merit. You could then provide git with some
> extra information a la .git/info/grafts: "Even if you, git, do not believe
> it: this file *was* renamed from blah to blop".
Yeah, except small details such as: where does it record it, and
how does the information presented to the user, and how does the
user tell git that information should be used?
What would be interesting would be to extend on this thing I
just wrote:
Something like:
$ git resolve-renamed-path arch/ppc64/ arch/powerpc/
to mean "I want the result of this merge to rename ppc64/Kconfig
to powerpc/Kconfig", perhaps?
I think this would work very nicely even without rename
detectino by the recursive strategy. What would happen with
resolve strategy is that unchanged paths are removed from
arch/ppc64 and added to arch/powerpc by the usual read-tree
merge rules, and all paths (not just unrecognizable renames --
because resolve would not even try) that have been changed on
the "test" branch would be in stage1+stage3 state in arch/ppc64,
while the corresponding ones in arch/powerpc are collapsed
("only added in test2 branch") to stage0. The fictional
resolve-renamed-path command (notice that I removed the explicit
"Kconfig" from the sample command line) could go through the
index file, looking for paths that arch/powerpc/ has stage0 and
arch/ppc64 has stage1+3, and perform the renaming merge at that
point.
^ permalink raw reply
* Re: bad git pull
From: Linus Torvalds @ 2005-12-17 1:05 UTC (permalink / raw)
To: Morten Welinder; +Cc: Junio C Hamano, Don Zickus, git
In-Reply-To: <118833cc0512161637v1d180f9fh66a7dc6d3fe11d2b@mail.gmail.com>
On Fri, 16 Dec 2005, Morten Welinder wrote:
>
> It would be outright peachy if Documentation/git-commit.txt and
> Documentation/git-pull.txt mentioned these. That is certainly
> where I would look first to answer the "what if I screwed up?"
> question.
It might be even better to have some of the "safe" versions around. Ie
something that refuses to "undo" a merge (you want to "unpull" it or
"unmerge" it), and refuses to "undo" when there's a ORIG_HEAD around that
implies that the last commit was a "pull" (in which case again "undo" may
be the wrong thing to do, since it will only undo _one_ commit, even
though the pull might have fast-forwarded a _lot_ of commits).
Of course, if we do that, we should also make sure that "git commit"
removes ORIG_HEAD.
Or maybe "git commit" should always _write_ ORIG_HEAD with the old head,
so that we can always do an "undo" by doing "git reset --hard ORIG_HEAD"
regardless of whether the last thing was a "git commit" or a "git pull".
Hmm?
Linus
^ permalink raw reply
* Re: bad git pull
From: Morten Welinder @ 2005-12-17 0:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Don Zickus, git
In-Reply-To: <Pine.LNX.4.64.0512161347490.3698@g5.osdl.org>
> - undo the last commit entirely ("hard reset to previous state"):
>
> git reset --hard HEAD^
>
> This was "bk undo"
>
> - undo the last pull ("bk unpull"): "hard reset to ORIG_HEAD":
>
> git reset --hard ORIG_HEAD
>
> This was "bk unpull".
It would be outright peachy if Documentation/git-commit.txt and
Documentation/git-pull.txt mentioned these. That is certainly
where I would look first to answer the "what if I screwed up?"
question.
Morten
^ permalink raw reply
* Re: git merge questions
From: Johannes Schindelin @ 2005-12-16 23:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Don Zickus, git
In-Reply-To: <7voe3gd6ul.fsf@assigned-by-dhcp.cox.net>
Hi,
just a thought: maybe in this case -- git fails to recognize a rename --
Pasky's idea would have some merit. You could then provide git with some
extra information a la .git/info/grafts: "Even if you, git, do not believe
it: this file *was* renamed from blah to blop".
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Nicolas Pitre @ 2005-12-16 22:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Johannes Schindelin, Junio C Hamano,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512161412310.3698@g5.osdl.org>
On Fri, 16 Dec 2005, Linus Torvalds wrote:
>
>
> On Fri, 16 Dec 2005, Nicolas Pitre wrote:
>
> > On Fri, 16 Dec 2005, Linus Torvalds wrote:
> >
> > > But, for example:
> > >
> > > [torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null
> > > real 0m37.993s
> > > user 0m41.912s
> > > sys 0m0.400s
> >
> > Hmmm... I'd like to have a system like that too, where reality is
> > smaller than the sum of system and user time. ;-)
>
> It's called "smp".
Gah! Maybe I should have tried the same before posting, since I get
this on my P4 with HT:
real 0m36.930s
user 0m41.971s
sys 0m0.656s
/me hides shamefully
Nicolas
^ permalink raw reply
* Re: git merge questions
From: Junio C Hamano @ 2005-12-16 22:17 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <68948ca0512161335k50a3ec64lee6f73ea4f8ae23f@mail.gmail.com>
Don Zickus <dzickus@gmail.com> writes:
>> and then, the digging I suggested yields these:
>>
>> $ ls -l arch/{ppc64,powerpc}/Kconfig
>> -rw-rw-r-- 1 junio src 24279 Dec 16 12:55 arch/powerpc/Kconfig
>> -rw-rw-r-- 1 junio src 11027 Dec 16 12:58 arch/ppc64/Kconfig
>> $ git ls-files -s arch/ppc64/Kconfig arch/powerpc/Kconfig
>> 100644 bb2efdd566a9d590d64184b10b097e4b7ed17e95 0 arch/powerpc/Kconfig
>> 100644 c658650af429672267409508b02b38754c11a40f 1 arch/ppc64/Kconfig
>> 100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3 arch/ppc64/Kconfig
>> ..
>> The result you want in this case is to merge changes between
>> c65865 (stage1 of old path) and 8abf11 (stage3 of old path) into
>> bb2efd (the latest contents of the new path) and register it as
>> the result of merge for arch/powerpc/Kconfig, and remove
>> arch/ppc64/Kconfig. So the sequence would be:
>>
>> $ orig=$(git unpack-file c65865)
>> $ from_test=$(git unpack-file 8abf11)
>> $ merge $from_test $orig arch/powerpc/Kconfig
>> merge: warning: conflicts during merge
I suspect there might be a room for improvement to make this
easier with a new command, if this becomes a common pattern.
Something like:
$ git resolve-renamed-path arch/ppc64/Kconfig arch/powerpc/Kconfig
to mean "I want the result of this merge to rename ppc64/Kconfig
to powerpc/Kconfig", perhaps? There are three cases: (1) we
renamed they didn't --- this is the case we are looking at and
there will be stage1 and stage3 but not stage2 for the old path,
and stage0 for the new path; (2) they renamed we didn't --- this
would happen if you pulled test2 into test, and there will be
stage1 and stage2 but not stage3 for the old path, and stage0
for the new path; (3) both of us renamed.
The third case is handled by the merge command automatically.
Old path will not remain to bother you even if the merge of the
new path needs hand-resolving, so you do not need
resolve-renamed-path command to deal with that case.
> Now say I didn't know the name of the rename and I had to dig
> that up. Would the following be the right way or is there
> something easier?
>
> %git log <renamed file> #grab the last commit id from here
> %git-diff-tree -p <last commit id> # search for the new file
That would work.
Or an explicit rename detection to see where many of the
neighbouring paths moved (this is very expensive):
mb=$(git merge-base test test2)
git diff-tree -r --diff-filter=R -M -l0 --name-status $mb test2
Or the diff-tree between the merge base and your current tree
and perhaps the other tree (this may give a lot of cruft):
mb=$(git merge-base test test2)
git diff-tree -r --diff-filter=A --name-status $mb test2
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Linus Torvalds @ 2005-12-16 22:12 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Martin Langhoff, Johannes Schindelin, Junio C Hamano,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512161636150.26663@localhost.localdomain>
On Fri, 16 Dec 2005, Nicolas Pitre wrote:
> On Fri, 16 Dec 2005, Linus Torvalds wrote:
>
> > But, for example:
> >
> > [torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null
> > real 0m37.993s
> > user 0m41.912s
> > sys 0m0.400s
>
> Hmmm... I'd like to have a system like that too, where reality is
> smaller than the sum of system and user time. ;-)
It's called "smp".
You can buy then anywhere.
Linus
^ permalink raw reply
* Re: bad git pull
From: Linus Torvalds @ 2005-12-16 22:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Morten Welinder, Don Zickus, git
In-Reply-To: <7vfyoshmp6.fsf@assigned-by-dhcp.cox.net>
On Fri, 16 Dec 2005, Junio C Hamano wrote:
>
> Morten Welinder <mwelinder@gmail.com> writes:
>
> >> While I am sympathetic, this "Oops, I said pull when I meant
> >> fetch" sounds remotely similar to "oops, I said 'rm -r' when I
> >> meant to say 'ls -r'". Is it that the tool is too fragile?
> >
> > Didn't bk come with some kind of (one-level) undo pull? It should not
> > be too hard to create something similar considering that one could
> > just leave new objects in the db orphaned.
>
> Yes, that is called "git reset".
Well, this is one area where BK and git differ a lot. BK didn't overload
many things onto the same "reset" functionality, but had specific
operations for specific cases.
Also BK would never leave a merge in the git kind of half-merged state,
because BK refuses to have two branches open. Instead, BK had a special
way of handling merges, which worked fine but quite frankly I have very
little idea of how it worked (it was some kind of "shadow BK tree", it was
called ".bk/RESOLVE/" or something like that - but because the tools
were so nice, you never really had any reason to look into it, so I
don't know what it did).
BK would never change the working tree itself until the merge was done, so
you would never need to do what a plain "git reset --hard" (without any
arguments) does.
In many ways the BK thing was very nice, although the git way is perhaps a
bit more flexible (because git makes the intermediate tree visible you can
easily edit the merge errors, and compile/test the result, before you
decide to commit any manual merge).
I really do like the way git does merges now (especially after the last
round of git-diff-tree fixes that allow comparing the different stages),
but the BK way is in some ways cleaner and leaves less potential for
confusion since it avoids ever exposing you to any half-merged state.
You may remember how I initially argued that we should always try to merge
stuff outside of the normal working directory. And I still _like_ that
approach, although I've since decided that I actually prefer the current
git way is even better in practice.
But "git reset" is a lot more than the "revert to previous state". It
_also_ does - without the error checking - what "bk fix" used to do
(which is to undo the last commit, so that you can re-commit it), and it
also does what "bk undo" used to do. It also does "bk unpull".
So "git reset" really does a whole lot of different and _mostly_ related
things:
- undo any half-way changes (very similar to just "git checkout -f"), and
just reset to the state of the last successful commit (ie "current
HEAD"):
git reset --hard
BK didn't need this, although if you just want to remove your edits
(which "git reset --hard" also does), you could - like with git - just
do a "checkout" operation, of course.
- undo the last commit, but don't undo the working tree ("soft reset to
parent of head").
git reset HEAD^
I think this was "bk fix -C".
- undo the last commit entirely ("hard reset to previous state"):
git reset --hard HEAD^
This was "bk undo"
- undo the last pull ("bk unpull"): "hard reset to ORIG_HEAD":
git reset --hard ORIG_HEAD
This was "bk unpull".
where the last two are obviously just special cases of a generic "undo to
arbitrary previous commit state".
BK in many ways had more hand-holding (which I think is good, and "git" to
some degree has an unnecessarily "hard core" approach to these things).
For example, I think "bk undo" not only asked you about it, but it also
only ever undid the last commit (and refused to undo a pull or merge). If
you wanted to undo to some arbitrary state, you had to use the "-a" flag,
iirc.
Of course, under BK the "undo" operation was final, so BK _had_ to be more
careful. With git, if you undo to some arbitrary state, you can still
"re-do" all your commits if you just find the old head (and
git-fsck-objects will help you do that), so in that sense git doesn't
_need_ to be as careful as BK was.
Linus
^ permalink raw reply
* Re: Why do we need [PATCH]?
From: Sam Ravnborg @ 2005-12-16 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsnwenqy.fsf@assigned-by-dhcp.cox.net>
On Fri, Dec 16, 2005 at 01:27:33PM -0800, Junio C Hamano wrote:
> Sam Ravnborg <sam@ravnborg.org> writes:
>
> > I looked at the source and found the -k option, but adding [PATCH]
> > should not be default behaviour so this is not the correct solution.
>
> The "correct" solution depends on where you come from. That
> extra [PATCH] is a carryover from BK days, I was told by Linus,
> to make e-mailed things stand out --- I've never used BK but I
> am guessing that things were not as obvious as our commit
> messages, perhaps?
You can a typical bk commit here:
http://linus.bkbits.net:8080/linux-2.5/cset@1.2243?nav=index.html|ChangeSet@-9M
And here it made much more sense sine the author/comitter info are
less structured. Also we do nto have the Signed-off-by: stuff back then.
> We have "Author/Committer" distinction so
> the [PATCH] marker is redundant.
>
> The rewrite, "git-am" does not bother with adding [PATCH], but
> the original "git-applymbox", being everyday Linus' tool, was
> left as it was, not to disrupt the workflow of Linus.
Thanks, I had forgotten the git-am rewrite.
I will use that in the future - if I remember.
Sam
^ permalink raw reply
* Re: [RFC] faking cvs annotate
From: Nicolas Pitre @ 2005-12-16 21:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Johannes Schindelin, Junio C Hamano,
Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0512160843450.3060@g5.osdl.org>
On Fri, 16 Dec 2005, Linus Torvalds wrote:
> But, for example:
>
> [torvalds@g5 linux-history]$ time git-whatchanged drivers/char/Makefile > /dev/null
> real 0m37.993s
> user 0m41.912s
> sys 0m0.400s
Hmmm... I'd like to have a system like that too, where reality is
smaller than the sum of system and user time. ;-)
Nicolas
^ permalink raw reply
* Re: qgit reports errors in the git repository
From: Junio C Hamano @ 2005-12-16 21:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: Pavel Roskin, junkio, git
In-Reply-To: <e5bfff550512161247v4c187cc0gedae8234d454c3b6@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> Type information is already available in git-ls-remote.sh...
???? is it ???? where and how ????
The only thing you know is where things are, and optionally if
that thing is a tag object or not (by presense or lack of
corresponding "it^{}").
^ permalink raw reply
* Re: git merge questions
From: Don Zickus @ 2005-12-16 21:35 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vy82keo8p.fsf@assigned-by-dhcp.cox.net>
> and then, the digging I suggested yields these:
>
> $ ls -l arch/{ppc64,powerpc}/Kconfig
> -rw-rw-r-- 1 junio src 24279 Dec 16 12:55 arch/powerpc/Kconfig
> -rw-rw-r-- 1 junio src 11027 Dec 16 12:58 arch/ppc64/Kconfig
> $ git ls-files -s arch/ppc64/Kconfig arch/powerpc/Kconfig
> 100644 bb2efdd566a9d590d64184b10b097e4b7ed17e95 0 arch/powerpc/Kconfig
> 100644 c658650af429672267409508b02b38754c11a40f 1 arch/ppc64/Kconfig
> 100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3 arch/ppc64/Kconfig
> $ ls arch/{powerpc,ppc64}/Kconfig~*
> ls: arch/powerpc/Kconfig~*: No such file or directory
> ls: arch/ppc64/Kconfig~*: No such file or directory
> $ git diff --theirs arch/ppc64/Kconfig
> * Unmerged path arch/ppc64/Kconfig
> diff --git a/arch/ppc64/Kconfig b/arch/ppc64/Kconfig
>
> The merge algorithm thought your branch (that is, test2 which is
> v2.6.15-rc4) removed the old ppc64/Kconfig path, but the other
> branch (test1 which has diff between v2.6.14 and v2.6.14.4) made
> updates to that file. For the other path, it simply thought
> your branch added a new file arch/powerpc/Kconfig while the
> other branch did not do anything to that path between v2.6.14
> and v2.6.14.4, so it merged it already.
>
> The result you want in this case is to merge changes between
> c65865 (stage1 of old path) and 8abf11 (stage3 of old path) into
> bb2efd (the latest contents of the new path) and register it as
> the result of merge for arch/powerpc/Kconfig, and remove
> arch/ppc64/Kconfig. So the sequence would be:
>
> $ orig=$(git unpack-file c65865)
> $ from_test=$(git unpack-file 8abf11)
> $ merge $from_test $orig arch/powerpc/Kconfig
> merge: warning: conflicts during merge
>
> After resolving the conflict in $from_test file, and other conflicts:
>
> $ ed $from_test
> $ cat $from_tset >arch/ppc64/Kconfig
> $ rm arch/powerpc/Kconfig
> $ rm $orig $from_test
> $ git update-index --add --remove arch/ppc64/Kconfig arch/powerpc/Kconfig
> # also mark paths you hand-resolved such as Makefile, drivers/pcmcia/i82365.c
> # etc. with "git update-index" here.
> $ git commit
>
> would commit the result of the merge.
>
Wow. That makes sense then. All your digging techniques seem to be
fairly straightforward. Now say I didn't know the name of the rename
and I had to dig that up. Would the following be the right way or is
there something easier?
%git log <renamed file> #grab the last commit id from here
%git-diff-tree -p <last commit id> # search for the new file
Thanks again,
Don
^ permalink raw reply
* Re: Why do we need [PATCH]?
From: Junio C Hamano @ 2005-12-16 21:27 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20051216210145.GA25311@mars.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> writes:
> I looked at the source and found the -k option, but adding [PATCH]
> should not be default behaviour so this is not the correct solution.
The "correct" solution depends on where you come from. That
extra [PATCH] is a carryover from BK days, I was told by Linus,
to make e-mailed things stand out --- I've never used BK but I
am guessing that things were not as obvious as our commit
messages, perhaps? We have "Author/Committer" distinction so
the [PATCH] marker is redundant.
The rewrite, "git-am" does not bother with adding [PATCH], but
the original "git-applymbox", being everyday Linus' tool, was
left as it was, not to disrupt the workflow of Linus.
^ permalink raw reply
* Re: git merge questions
From: Junio C Hamano @ 2005-12-16 21:16 UTC (permalink / raw)
To: Don Zickus; +Cc: git
In-Reply-To: <7vacf0g4ga.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> What puzzles me is that I think it is supposed to have done all
> the above for you. Namely:
>
> $ ls -l arch/ppc64/Kconfig <1>
> $ git ls-files -s arch/ppc64/Kconfig <2>
> $ ls -l arch/powerpc/Kconfig arch/powerpc/Kconfig~* <3>
> $ git ls-files -s arch/powerpc/Kconfig <4>
>
> <1> should not remain --- recursive merge could have notied that
> the file was moved.
> <2> ditto.
> <3> arch/powerpc/Kconfig should be there with possibly merge
> conflict markers.
> <4> stage1 with merge base version (possibly renamed), stage2
> with test2 version, stage3 with your test version (definitely
> renamed).
I know what happened. That Kconfig file was modified between
v2.6.14 and v2.6.15-rc4 beyond recognition, and the rename
detection did not think it was renamed.
The merge has this message:
CONFLICT (delete/modify): arch/ppc64/Kconfig deleted in HEAD and
modified in e14ee1ed34e25df6ea93b0bfb1bc4138cd26bea2. Version
e14ee1ed34e25df6ea93b0bfb1bc4138cd26bea2 of arch/ppc64/Kconfig
left in tree.
and then, the digging I suggested yields these:
$ ls -l arch/{ppc64,powerpc}/Kconfig
-rw-rw-r-- 1 junio src 24279 Dec 16 12:55 arch/powerpc/Kconfig
-rw-rw-r-- 1 junio src 11027 Dec 16 12:58 arch/ppc64/Kconfig
$ git ls-files -s arch/ppc64/Kconfig arch/powerpc/Kconfig
100644 bb2efdd566a9d590d64184b10b097e4b7ed17e95 0 arch/powerpc/Kconfig
100644 c658650af429672267409508b02b38754c11a40f 1 arch/ppc64/Kconfig
100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3 arch/ppc64/Kconfig
$ ls arch/{powerpc,ppc64}/Kconfig~*
ls: arch/powerpc/Kconfig~*: No such file or directory
ls: arch/ppc64/Kconfig~*: No such file or directory
$ git diff --theirs arch/ppc64/Kconfig
* Unmerged path arch/ppc64/Kconfig
diff --git a/arch/ppc64/Kconfig b/arch/ppc64/Kconfig
The merge algorithm thought your branch (that is, test2 which is
v2.6.15-rc4) removed the old ppc64/Kconfig path, but the other
branch (test1 which has diff between v2.6.14 and v2.6.14.4) made
updates to that file. For the other path, it simply thought
your branch added a new file arch/powerpc/Kconfig while the
other branch did not do anything to that path between v2.6.14
and v2.6.14.4, so it merged it already.
The result you want in this case is to merge changes between
c65865 (stage1 of old path) and 8abf11 (stage3 of old path) into
bb2efd (the latest contents of the new path) and register it as
the result of merge for arch/powerpc/Kconfig, and remove
arch/ppc64/Kconfig. So the sequence would be:
$ orig=$(git unpack-file c65865)
$ from_test=$(git unpack-file 8abf11)
$ merge $from_test $orig arch/powerpc/Kconfig
merge: warning: conflicts during merge
After resolving the conflict in $from_test file, and other conflicts:
$ ed $from_test
$ cat $from_tset >arch/ppc64/Kconfig
$ rm arch/powerpc/Kconfig
$ rm $orig $from_test
$ git update-index --add --remove arch/ppc64/Kconfig arch/powerpc/Kconfig
# also mark paths you hand-resolved such as Makefile, drivers/pcmcia/i82365.c
# etc. with "git update-index" here.
$ git commit
would commit the result of the merge.
^ permalink raw reply
* Re: Why do we need [PATCH]?
From: Dave Jones @ 2005-12-16 21:13 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20051216210145.GA25311@mars.ravnborg.org>
On Fri, Dec 16, 2005 at 10:01:45PM +0100, Sam Ravnborg wrote:
> I've just applied a patch to my git tree using git-applymbox.
> It worked like a charm as it often do.
> But then when I did a quick check with gitk it stuck me that
> the subject was prefixed with [PATCH].
> I am aware that the [PATCH] in subject tell me:
> "patch is received from somewhere and applied by me to the .git tree".
> This is in comparsion to patches received when I merge a git tree for
> example.
>
> But with common practice to use sign-off I wonder the value of this
> patch marker.
> When browsing the kernel shortlog I often focus on first word in subject
> - cause this tells me what system/drivers is changed. But with the
> [PATCH] marker I have to read some non-sense to see actual subject.
>
> The information is redundant since metadata already tell me who is the
> author and who committed the change.
> So could we have it removed or if people continue to find it usefull
> then at least hide it behind some option. Using the [PATCH] prefix is
> not the natural thing to do with git.
>
> I looked at the source and found the -k option, but adding [PATCH]
> should not be default behaviour so this is not the correct solution.
I'm still using Linus' original 'applypatch' script, on which I think
this stuff was based, and this behaviour annoyed me too.
So I changed it to do this..
if [ -f .treename ]; then
TREENAME=`cat .treename`
else
TREENAME='PATCH'
fi
(echo "[$TREENAME] $SUBJECT" ; if [ -s $MSGFILE ]; then echo ; cat $MSGFILE; fi ) > $final
and then I have a .treename in say the AGP tree, containing just 'AGPGART',
and the changelogs get the prefixes that actually mean something useful.
(And those markers are invaluable when searching through history for changes)
Dave
^ 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