* Update a bare repository
From: Thomas Glanzmann @ 2007-07-17 6:30 UTC (permalink / raw)
To: GIT
Hello,
what I would like to do is the following:
I have a _bare_ clone of a git repository and would like to update it
from Junios repository at kernel.org from time to time.
How do I do that? In a way that it is a fire and forget solution? It
should also fetch new upstream branches.
"git pull" does not work. "git fetch" does, but it does update all
references?
(faui02) [~/work/repositories/mirror/git.git] git pull
fatal: /usr/bin/git-pull cannot be used without a working tree.
(faui02) [~/work/repositories/mirror/git.git] git fetch
(faui02) [~/work/repositories/mirror/git.git]
I also would like to check that it is impossible to push anything to the
repository.
Thomas
^ permalink raw reply
* Re: I never want to push a given change
From: Brian Gernhardt @ 2007-07-17 5:06 UTC (permalink / raw)
To: nathan bullock; +Cc: git
In-Reply-To: <916b88c10707162204k69e47d25w1c03c04544bcbdf7@mail.gmail.com>
On Jul 17, 2007, at 1:04 AM, nathan bullock wrote:
> Ahhh, thanks for that. You forced me to go stare at the git rebase
> documentation
> until I actually understood what it does. It looks like that will work
> perfectly.
Well, I was perfectly willing to go into more detail if needed. But
sometimes people just need a push in the right direction. Plus, I'm
too lazy to go into details until asked. ;-)
Glad I could help.
~~ Brian
^ permalink raw reply
* Re: I never want to push a given change
From: nathan bullock @ 2007-07-17 5:04 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: git
In-Reply-To: <76ACB85D-2969-406A-AA11-EAF2A104B9E7@silverinsanity.com>
On 7/16/07, Brian Gernhardt <benji@silverinsanity.com> wrote:
>
> On Jul 16, 2007, at 12:18 PM, nathan bullock wrote:
>
> > I have been using git for a little while and one thing that I would
> > like to
> > be able to do is never push a given change, or set of changes.
> >
> > So lets say I clone a .git repository. Then I make a couple of changes
> > that I don't want anyone else to see, do a commit. Then I make some
> > other changes that I want everyone else to see and do another commit.
> >
> > How do I push just the second commit?
> > And how do I make it so that every other time I do a push after
> > this that
> > first commit will never be sent?
>
> Generally the way I do such things is multiple branches. Have a
> branch "local" (or a more descriptive name) that isn't pushed out
> anywhere. Place any changes you do NOT want shared on that brach.
> Place changes to be shared on the master or appropriate topic
> branch. Instead of committing changes to be shared on top of the
> local ones, use "git rebase" to keep the local branch on top of the
> shared ones.
>
Ahhh, thanks for that. You forced me to go stare at the git rebase documentation
until I actually understood what it does. It looks like that will work
perfectly.
Nathan
^ permalink raw reply
* Re: A question about git-rev-list
From: Junio C Hamano @ 2007-07-17 4:33 UTC (permalink / raw)
To: David Kastrup; +Cc: Linus Torvalds, git
In-Reply-To: <85bqecm4mn.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> ... The problem I have
> with that is that "somefile.c" renders commits uninteresting, but
> not if they have interesting parents (what do their parents have to do
> with it?). So if I have
>
> A -> B -> B1 -> C -> HEAD
>
> where somefile.c does not change between B and B1, then
> git-rev-list HEAD --not B -- somefile.c
> spews out
> HEAD
> C
> and that's it. Quite as expected. However,
> git-rev-list HEAD --not B --parents -- somefile.c
> spews out
> HEAD C
> C B1
> B1 B
>
> and look and behold, B1 became interesting because of its unlisted
> parent B.
>
> There is something wrong with that.
There indeed is, and that is not what I am seeing.
Running this script in an empty directory gives me:
#!/bin/sh
GIT_AUTHOR_NAME='A U Thor'
GIT_AUTHOR_EMAIL=a.u.thor@example.xz
GIT_COMMITTER_NAME="$GIT_AUTHOR_NAME"
GIT_COMMITTER_EMAIL="$GIT_AUTHOR_EMAIL"
GIT_AUTHOR_DATE='2007-07-16 00:00:00 +0000'
GIT_COMMITTER_DATE='2007-07-16 00:00:00 +0000'
export GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL \
GIT_AUTHOR_DATE GIT_COMMITTER_DATE
rm -fr .git
git init
echo A >somefile.c; git add somefile.c; git commit -m 'A'; git tag A
echo B >somefile.c; git add somefile.c; git commit -m 'B'; git tag B
echo B1 >another; git add another; git commit -m 'B1'; git tag B1
echo C >somefile.c; git add somefile.c; git commit -m 'C'; git tag C
echo H >somefile.c; git add somefile.c; git commit -m 'H'; git tag H
git rev-list --parents HEAD --not B -- somefile.c |
git name-rev --tags --stdin
$ sh t000.sh
Initialized empty Git repository in .git/
Created initial commit 7a13cf5: A
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 somefile.c
Created commit b66d40b: B
1 files changed, 1 insertions(+), 1 deletions(-)
Created commit 5530c91: B1
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 another
Created commit 7ee2b7e: C
1 files changed, 1 insertions(+), 1 deletions(-)
Created commit 71fafc0: H
1 files changed, 1 insertions(+), 1 deletions(-)
71fafc0f49ffb82b123c09ec0857f9f458ed32c4 (tags/H) 7ee2b7ed072190c56a2eedda3130f6bb729d0da1 (tags/C)
7ee2b7ed072190c56a2eedda3130f6bb729d0da1 (tags/C) b66d40bd7ed6d7403c16d8e37e6e410852598247 (tags/B)
The commit listed are H and then C; their (rewritten) parents
are C and B, respectively.
^ permalink raw reply
* Re: Another question about importing SVN with fast-import
From: Shawn O. Pearce @ 2007-07-17 3:38 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707162204480.14971@reaper.quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> wrote:
> First off, I would just like to say fast-import rocks. It's well named
> too ...
I'm glad you like it. ;-)
> Now the question. Shawn recently added C and R operations - almost as
> soon as they were asked for too.
Sometimes I'm responsive...
> However, how do you copy a file from a
> particular revision?
and sometimes not so much. You can't do that right now. I've wanted
to open up the data subcommand to allow another form that lets you
specify data from a branch and file path (thus selecting a blob
from another revision) but I haven't gotten around to it. I also
don't have time to do it during the earlier part of this week.
Maybe I'll get to it later near the end of the week.
It shouldn't be too difficult now with the tree_content_get()
function that I recently defined for the C/R commands. The SHA-1
comes back in the tree_entry leaf, but that codepath is only valid
for the tip of a branch that fast-import knows about in memory.
If it doesn't then you probably need to fallback into raw tree
parsing. Ugh.
The way prior frontends have handled this is they assigned marks
to every blob, and then had a translation table within the frontend
of revision->mark, so that anytime it needed a given revision of a
file it knew what mark to send to fast-import. This does require
that the frontend maintain basically everything...
> I have just hit a point where someone deleted a
> directory, and then copied one of the files from that directory back from
> an old revision (as two separate commits). Since I'm not tracking any
> branch contents in my front-end, and the copy operation only works from
> the current branch head I seem to be stuck ... or have I missed something?
Yea, I got nothing. I can't think of any method to make that work
aside from using marks. Or teaching fast-import how to do tree
lookup, like I described above.
--
Shawn.
^ permalink raw reply
* Re: Tips for debugging fast-import front-ends
From: Shawn O. Pearce @ 2007-07-17 3:27 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Julian Phillips
In-Reply-To: <469B736F.12FA24EA@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Julian Phillips wrote:
> > At some point in the "messy" phase I get an error from fast-import saying:
> >
> > fatal: path foo not in branch
> >
> > This seems to happen when I attempt to copy a file that is also changed in
> > the same commit. What I would like to do is find out what things look
> > like just before that point - the problem is that fast-import seems to not
> > create anything on failure. So, apart restarting the import and stopping
> > just before the broken commit, is there any way to find out what
> > fast-import thinks the branch looks like?
>
> Redirect the input stream to a file instead of to fast-import, then feed
> fast-import from this file. This way you can reproduce the failure more
> quickly. Also, you can run fast-import from a debugger.
I tend to dump my test stream to a file, then process that through
fast-import. Running fast-import in the debugger is uh, ugly, as
I make heavy use of FLEX_ARRAY whenever there is interesting data.
So simple printing of any useful data (like the name of a tree
entry) is not so simple without doing pointer addition and type
casting in gdb. Sometimes I just break down and add a few targeted
printf()'s to the code. That always tells me what's up.
One easy thing that you can do is add a 'checkpoint' command
right before the bad commit (assuming you know roughly where it is
breaking). This will cause fast-import to flush all of its buffers
back to disk, and update the Git repository, before reading the
next command. The result is that when you crash you have everything
that fast-import processed right up to that last checkpoint.
Clearly doing too many checkpoints is going to remove the fast part
of fast-import, but at least you have a -import. ;-)
After reading this thread I have decided to add some frontend
debugging support into fast-import, like dumping out the most
recently received commands and the current branch and tree state
before it die()'s with a protocol error or bad path error, and maybe
also try to do a partial checkpoint (close out the packfile, don't
update refs or marks, but instead write them to the state dump file).
This way the frontend developer can inspect the overall state and
better understand what might have gone wrong.
Unfortunately I won't get it done in the next few days, but maybe
before the weekend.
--
Shawn.
^ permalink raw reply
* Re: problem viewing git.git with gitk on cygwin
From: Shawn O. Pearce @ 2007-07-17 3:14 UTC (permalink / raw)
To: Ray Lehtiniemi; +Cc: git
In-Reply-To: <200707161330.36907.rayl@mail.com>
Ray Lehtiniemi <rayl@mail.com> wrote:
> i'm seeing a problem with gitk on cygwin. if i try and view the history of
> git itself, it seems to stop at version 22dcbb. interestingly, the next
> commit 3ef378 has an embedded CTRL-Z character in the commit message.
>
> possible DOS EOF handling bug? or is there a repo setting i need to be
> tweaking?
>
> using git version 1.5.2.2, installed using the cygwin package setup tool.
Not Git's fault; Tcl on Cygwin honors EOF. Because nobody would
ever put that byte into a data stream. ;-)
Looks like gitk needs to add -eofchar {} to an fconfigure command
before it reads data from Git. Otherwise on Windows systems it
just stops reading. I better do the same to git-gui. *sigh*
--
Shawn.
^ permalink raw reply
* Re: I never want to push a given change
From: Brian Gernhardt @ 2007-07-17 3:12 UTC (permalink / raw)
To: nathan bullock; +Cc: git
In-Reply-To: <916b88c10707160918n7a4948g5fb55a9d8ace9833@mail.gmail.com>
On Jul 16, 2007, at 12:18 PM, nathan bullock wrote:
> I have been using git for a little while and one thing that I would
> like to
> be able to do is never push a given change, or set of changes.
>
> So lets say I clone a .git repository. Then I make a couple of changes
> that I don't want anyone else to see, do a commit. Then I make some
> other changes that I want everyone else to see and do another commit.
>
> How do I push just the second commit?
> And how do I make it so that every other time I do a push after
> this that
> first commit will never be sent?
Generally the way I do such things is multiple branches. Have a
branch "local" (or a more descriptive name) that isn't pushed out
anywhere. Place any changes you do NOT want shared on that brach.
Place changes to be shared on the master or appropriate topic
branch. Instead of committing changes to be shared on top of the
local ones, use "git rebase" to keep the local branch on top of the
shared ones.
~~ B
^ permalink raw reply
* Re: Changes in function read_pipe
From: Junio C Hamano @ 2007-07-16 23:50 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Kristian Høgsberg, Johannes Schindelin
In-Reply-To: <469B9939.5050800@gmail.com>
Carlos Rica <jasampler@gmail.com> writes:
> Some people talked recently about renaming the function read_pipe
> (sha1_file.c) to the better name read_fd.
> Here I discuss other possible changes to the current version:
>
> 1. It now requires to allocate memory for the buffer before calling it,
> you cannot pass it a pointer set to NULL or not initializated at all.
It should be a trivial and easy fix to add "initial allocation"
at the beginning of the function. While I suspect that the
optimal initial allocation would be different for different
callers, probably we would not care that much.
> 2. The function doesn't terminate the data with NUL, and if you
> need that, you must to realloc before adding the '\0', because
> the function only returns the size of the data, not the buffer size.
Among the existing callers, index_fd() does not need NUL
termination, but we are almost always allocating more than
needed when the final size is unknown, so giving an extra NUL
(of course not including that in the final result size) would
not hurt. Other callers are 'stripspace' and 'mktag', and I
would imagine 'tag' and 'commit' when they are reading the
message from the standard input would benefit from the implicit
NUL termination. I'd say go for it.
> 3. When function fails in reading (xread returns < 0), buffer is not
> freed.
I do not think this is a problem. The current callers seem to
do something like this:
if (read_pipe(fd, ...)) {
free(buf);
return error(...);
}
but not freeing, and reporting how many you read so far, would
allow readers to work on results partially read (not to be
confused with the EAGAIN which is already handled with xread()).
^ permalink raw reply
* Re: Can someone explain this git-blame/git-rev behavior to me?
From: Junio C Hamano @ 2007-07-16 23:13 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86sl7oaasx.fsf@lola.quinscape.zz>
David Kastrup <dak@gnu.org> writes:
> git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin
>
> d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92)
>
> So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into
> a loop of blame.
Without the final name-rev, it reads:
d87b90e4... b5dd9d20... 280242d1...
Without the --parent option, you get only d87b90e4...; the
option tells the command to additionally give you the (virtual)
parents in the simplified history on the same line as well.
Now, true parents of d87b90e4 are b5dd9d20 and 00449f99; the
former changes the path you are interested in, but the latter
does not. Which means in this history:
$ git show-branch d87b90e4 00449f99 280242d1
! [d87b90e4] Merge branch 'js/fmt-merge-msg'
! [00449f99] Make git-fmt-merge-msg a builtin
! [280242d1] send-email: do not barf when Term::ReadLine does not
---
- [d87b90e4] Merge branch 'js/fmt-merge-msg'
++ [00449f99] Make git-fmt-merge-msg a builtin
+ [b5dd9d20] Fix print-log and diff compatibility with recent vc
+ [b5dd9d20~1] git-svn: avoid fetching files outside of the URL w
+ [b5dd9d20~2] Improve git-peek-remote
+ [b5dd9d20~3] t8001-annotate: fix a bash-ism in this test
+++ [280242d1] send-email: do not barf when Term::ReadLine does not
the true history of a side branch forked at 280242d1 to 00449f99
is simplified away, and 00449f99 is replaced with the boundary
commit 280242d1:
00449f99 d87b90e4
o--( branch that does not change the path) ---*
/ /
---o----------o----------o----------o------------*
280242d1 b5dd9d20~3 b5dd9d20~2 b5dd9d20~1 b5dd9d20
Note that 280242d1 is reachable from v1.4.2-rc1~88, so the
traversal does not go beyond it (as you said --not $that).
^ permalink raw reply
* Re: git-config: replaces ~/.gitconfig symlink with real file
From: Junio C Hamano @ 2007-07-16 22:46 UTC (permalink / raw)
To: Bradford Smith; +Cc: Nikolai Weibull, git
In-Reply-To: <f158199e0707160626j1025ab2cp3339ca6ab91d9af0@mail.gmail.com>
"Bradford Smith" <bradford.carl.smith@gmail.com> writes:
> ... So, I guess I need to add a GIT_CONFIG_HOME
> environment variable.
I suspect that is going down a wrong path.
We use the sequence:
fd = creat("temporary location");
write(fd, ...);
close(fd);
rename("temporary location", "final location");
in quite a lot of codepaths. I think they can be factored out,
to take the "final location" (and perhaps a suggested temporary
directory) as an parameter, and that code can check that "final
location" is a symlink to somewhere else and create the
temporary next to the target file.
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Junio C Hamano @ 2007-07-16 22:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <e5bfff550707161102n3b6da174i7bbff64e1739a1b2@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 7/16/07, Marco Costalba <mcostalba@gmail.com> wrote:
>> On 7/16/07, Junio C Hamano <gitster@pobox.com> wrote:
>> >
>> > I'd say making --show-message-size option incompatible with diff output
>> > would be good enough futureproofing for now.
>> >
>> Oooops, I didn't see your post.
>>
>> I agree 100%, please tell me if doc it's clear enough or it would be
>> better to clarify that "message log" it means only message and no diff
>> content.
>>
>
> Sorry to bother you again, but my English is very bad and I would like
> to be clear.
>
> When i say no diff content I mean that git log --log-size -p it's a
> perfect valid command but --log-size will make git print the size of
> _only_ the log part, it means from the line after "log size xxx\n"
> until the end of log message that can be '\0' (if no diff) or the
> beginning of diff part.
What I originally meant with my comment was to _error_ out if
the user says "git log --log-size -p" (or "git show --log-size"
without "-s").
But I guess it is probably fine, as long as it is crystal clear
to the users that we do not do size for non log part. I still
have this nagging feeling that this is an ugly workaround for Qt
library's programming interface, though...
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Linus Torvalds @ 2007-07-16 22:03 UTC (permalink / raw)
To: Scott Lamb; +Cc: Thomas Glanzmann, GIT
In-Reply-To: <469BEA21.5080308@slamb.org>
On Mon, 16 Jul 2007, Scott Lamb wrote:
> Linus Torvalds wrote:
> >
> > In fact, with the Solaris behaviour for unlink(), you *cannot* have a
> > non-broken "remove()".
>
> I'd hoped to see that they made a new syscall to properly implement the
> new behavior.
Ahh, yes, with a new system call you could do it.
> But they didn't. It reminds me of glibc's pselect().
Yeah, that was a bit pointless, although it does make it easier to port
binaries and then have them to work in practice most of the time.
Linus
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Scott Lamb @ 2007-07-16 21:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Thomas Glanzmann, GIT
In-Reply-To: <alpine.LFD.0.999.0707161442410.20061@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Mon, 16 Jul 2007, Scott Lamb wrote:
>> But Solaris remove() is broken, too, so it's a moot point.
>
> In fact, with the Solaris behaviour for unlink(), you *cannot* have a
> non-broken "remove()".
I'd hoped to see that they made a new syscall to properly implement the
new behavior. But they didn't. It reminds me of glibc's pselect().
Best regards,
Scott
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: [PATCH 6/6] Add git-rewrite-commits
From: Sven Verdoolaege @ 2007-07-16 21:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <20070716200404.GT999MdfPADPa@greensroom.kotnet.org>
On Mon, Jul 16, 2007 at 10:04:04PM +0200, Sven Verdoolaege wrote:
> - a SHA1 of a commit that appears in a commit message is replaced
> by the rewritten commit iff it was rewritten to a single commit.
> That is, if the commit was pruned or rewritten (through a commit
> filter) to more than one commit, then the SHA1 is left alone.
Sorry. I misremembered. I considered doing it this way, but
then thought it was better to replace the SHA1 with a(n abbreviated)
null SHA1 to signify that the commit had gone.
skimo
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Linus Torvalds @ 2007-07-16 21:44 UTC (permalink / raw)
To: Scott Lamb; +Cc: Thomas Glanzmann, GIT
In-Reply-To: <469BE1D4.1070408@slamb.org>
On Mon, 16 Jul 2007, Scott Lamb wrote:
>
> But Solaris remove() is broken, too, so it's a moot point.
In fact, with the Solaris behaviour for unlink(), you *cannot* have a
non-broken "remove()".
So the right fix is always to fix "unlink()" instead.
There really aren't any downsides (since no program can rely on it
_anyway_, unless we're talking about some magic "early bootup" time
scripts that depend on only running as root, and only ever running on UFS
- but those kinds of scripts could be trivially fixed and are obviously
under Sun control anyway)
Linus
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Scott Lamb @ 2007-07-16 21:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Thomas Glanzmann, GIT
In-Reply-To: <alpine.LFD.0.999.0707161332280.20061@woody.linux-foundation.org>
Linus Torvalds wrote:
> No, but we don't *want* the "rmdir for directories" part!
>
> That's the whole point.
>
> Calling "remove()" would be *wrong*. We want the *sane* "unlink()"
> behaviour, where it only removes files, and returns an error for
> directories.
Of course, but when used immediately after stat() says the path does not
refer to a directory, I would prefer SUS remove() (rmdir() for
directories) to Solaris unlink() (break_filesystem() on directories).
But Solaris remove() is broken, too, so it's a moot point. The
post-patch behavior is good enough - as you said, it won't happen during
reasonable usage and the problem's not unique to git.
Best regards,
Scott
--
Scott Lamb <http://www.slamb.org/>
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Linus Torvalds @ 2007-07-16 21:19 UTC (permalink / raw)
To: Brian Downing; +Cc: Thomas Glanzmann, git, gitster
In-Reply-To: <20070716210612.GI19073@lavos.net>
On Mon, 16 Jul 2007, Brian Downing wrote:
>
> Apparently "enterprise class" in this case really means "fully
> compatibility with all those wonderful userland implementations of
> rmdir." :-)
I see the smiley, but it's actually not possible even for that.
The broken "unlink()" behaviour doesn't work on any other filesystem (eg
NFS) at all anyway, and even on UFS would only work for root (or
setuid-root) binaries. So any user-land that depended on it literally
wouldn't work _anyway_, even on Solaris itself.
And we're talking about the same company that was *famous* for screwing
people over when they converted from SunOS to Solaris and broke binaries
_and_ source code in the process.
So no, "compatibility" can't realistically be the reason.
Linus
^ permalink raw reply
* Re: A question about git-rev-list
From: David Kastrup @ 2007-07-16 21:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0707161258560.20061@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, 16 Jul 2007, David Kastrup wrote:
>>
>> if I do
>>
>> git-rev-list --remove-empty HEAD --not some-commit -- filename | tail -1
>>
>> do I have any guarantee that the commit id I get (if any) is a direct
>> descendant of some-commit?
>
> No. You get the guarantee that
>
> - it's some kind of parent of HEAD
> - it's *not* a parent of some-commit
>
> But the trivial case is a simple history like
>
> /-B-\
> A D
> \-C-/
>
> (where "A" is the root commit, and "D" is the current HEAD, and there are
> two development lines from A to D).
>
> If you now do
>
> git-rev-list HEAD --not C
>
> you would generally see B on the list of commits, even though it's
> obviously not a direct descendant of C.
Ok, thanks. As explained in a different posting, I try to tackle this
now with the equivalent of
git-rev-list HEAD --parents --not B -- somefile.c | awk '/ B/{print $1}'
This will give me one descendant if there is one. The problem I have
with that is that "somefile.c" renders commits uninteresting, but
not if they have interesting parents (what do their parents have to do
with it?). So if I have
A -> B -> B1 -> C -> HEAD
where somefile.c does not change between B and B1, then
git-rev-list HEAD --not B -- somefile.c
spews out
HEAD
C
and that's it. Quite as expected. However,
git-rev-list HEAD --not B --parents -- somefile.c
spews out
HEAD C
C B1
B1 B
and look and behold, B1 became interesting because of its unlisted
parent B.
There is something wrong with that.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Another question about importing SVN with fast-import
From: Julian Phillips @ 2007-07-16 21:11 UTC (permalink / raw)
To: git
First off, I would just like to say fast-import rocks. It's well named
too ...
Now the question. Shawn recently added C and R operations - almost as
soon as they were asked for too. However, how do you copy a file from a
particular revision? I have just hit a point where someone deleted a
directory, and then copied one of the files from that directory back from
an old revision (as two separate commits). Since I'm not tracking any
branch contents in my front-end, and the copy operation only works from
the current branch head I seem to be stuck ... or have I missed something?
--
Julian
---
What I want to find out is -- do parrots know much about Astro-Turf?
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Brian Downing @ 2007-07-16 21:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Thomas Glanzmann, git, gitster
In-Reply-To: <alpine.LFD.0.999.0707161252330.20061@woody.linux-foundation.org>
On Mon, Jul 16, 2007 at 12:58:14PM -0700, Linus Torvalds wrote:
> I have to say that I'm still a bit shocked that Solaris would have that
> kind of behaviour. And they call that pile of sh*t "enterprise class"..
Apparently "enterprise class" in this case really means "fully
compatibility with all those wonderful userland implementations of
rmdir." :-)
-bcd
^ permalink raw reply
* Re: Can someone explain this git-blame/git-rev behavior to me?
From: David Kastrup @ 2007-07-16 20:41 UTC (permalink / raw)
To: git
In-Reply-To: <469B9843.835B5356@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> David Kastrup wrote:
>>
>> I am looking for a descendant of tags/v1.4.4-rc1~72 with regard to
>> contrib/emacs/vc-git.el by scanning the output of the first command
>> in the following pipeline:
>>
>> git-rev-list --parents HEAD ^tags/v1.4.4-rc1~72 -- vc-git.el|git-name-rev --stdin|fgrep tags/v1.4.4-rc1
>>
>> This gives:
>> 4de0f9f9b6ed1731de00b67952504e5a783f54a4 (tags/v1.5.0-rc0~31) 1259404c7e5cd88b7f6692986469cd20cbfacdad (tags/v1.4.4-rc1~71)
>> 1259404c7e5cd88b7f6692986469cd20cbfacdad (tags/v1.4.4-rc1~71) b4aee09e610567529dc619d7324dc2fe85a11db5 (tags/v1.4.4-rc1~72) 0abc0260fa3419de649fcc1444e3d256a17ca6c7 (tags/v1.4.3.2~6)
>>
>> And this looks like it would tell us that tags/v1.4.4-rc1~72 has with
>> regard to vc-git.el a child tags/v1.4.4-rc1~71 and a grandchild of
>> tags/v1.5.0-rc0~31.
>>
>> Now if I instead do
>> git-rev-list --parents HEAD -- vc-git.el|git-name-rev --stdin|fgrep tags/v1.4.4-rc1
>>
>> 4de0f9f9b6ed1731de00b67952504e5a783f54a4 (tags/v1.5.0-rc0~31) b4aee09e610567529dc619d7324dc2fe85a11db5 (tags/v1.4.4-rc1~72)
>> b4aee09e610567529dc619d7324dc2fe85a11db5 (tags/v1.4.4-rc1~72) 474a90fef9ebcdedee041b2def4b9a98b94cd146 (tags/v1.4.3.2~8)
>>
>> I get to see that the child of tags/v1.4.4-rc1~72 is actually
>> tags/v1.5.0-rc0~31, skipping tags/v1.4.4-rc1~71 which presumably did
>> not change vc-git.el.
>>
>> So the ^tags/v1.4.4-rc1~72 specification caused an additional mention
>> of tags/v1.4.4-rc1~71 even though, with regard to vc-git.el, it would
>> be equivalent to tags/v1.4.4-rc1~72.
>>
>> So is there a way I can get the information of the second call without
>> the performance loss of going through the entire history?
>
> It seems that there is an unwanted interaction between --parents and
> history simplification at the edge commits. I don't think that there
> will be an easy solution.
After some testing, it would appear that indeed the --parents option
causes the problematic behavior. I find this surprising since
--parents should not have an effect on which lines are getting
displayed, should it? It should just make those lines that _are_
getting displayed longer.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Thomas Glanzmann @ 2007-07-16 20:39 UTC (permalink / raw)
To: Linus Torvalds; +Cc: GIT
In-Reply-To: <alpine.LFD.0.999.0707161332280.20061@woody.linux-foundation.org>
Hello,
> No, but we don't *want* the "rmdir for directories" part!
that is what I meant. We call unlink because we want unlink to _fail_ on
directories while it deletes file. I forgot about the original
discussion but Johannes refreshed my memory. If a file in our history
becomes a directory we want to get it out of our way. And we want to do
that by call unlink.
Thomas
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Linus Torvalds @ 2007-07-16 20:34 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: GIT
In-Reply-To: <20070716202550.GH16878@cip.informatik.uni-erlangen.de>
On Mon, 16 Jul 2007, Thomas Glanzmann wrote:
>
> Hello,
>
> > > is there a reason why we call unlink and not remove?
>
> > Exactly because we only want to remove _files_.
>
> of course. That is the whole point. Call unlink for files, rmdir for
> directories.
No, but we don't *want* the "rmdir for directories" part!
That's the whole point.
Calling "remove()" would be *wrong*. We want the *sane* "unlink()"
behaviour, where it only removes files, and returns an error for
directories.
Linus
^ permalink raw reply
* Re: [PATCH] Do _not_ call unlink on a directory
From: Linus Torvalds @ 2007-07-16 20:29 UTC (permalink / raw)
To: Thomas Glanzmann; +Cc: Scott Lamb, git, gitster
In-Reply-To: <alpine.LFD.0.999.0707161315120.20061@woody.linux-foundation.org>
On Mon, 16 Jul 2007, Linus Torvalds wrote:
>
> [..] mkdir/rmdir have existed as
> system calls since at least SVR3.
Correction. Apparently since 4.2BSD (1983).
Linus
^ 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