Now, if you say git log --walk-reflogs --relative-date next@{yesterday} it shows the reflog date as a relative date expression. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> --- log-tree.c | 3 ++- reflog-walk.c | 6 +++--- reflog-walk.h | 3 ++- 3 files changed, 7 insertions(+), 5 deletions(-) diff --git a/log-tree.c b/log-tree.c index f043ad3..843a7c5 100644 --- a/log-tree.c +++ b/log-tree.c @@ -225,7 +225,8 @@ void show_log(struct rev_info *opt, ...

Exactly. You are absolutely right. I should have done that when I did the show-branch --reflog workaround to pass 0. -

We pass a timestamp (i.e. number of seconds elapsed since Jan 1 1970, 00:00:00 GMT) to the function. So there is no need to "fix" the timestamp according to the timezone. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> --- Just compile & run this little test program to see what I mean: #include "cache.h" int main(int argc, char **argv) { time_t t = time(NULL); printf("%s\n", show_rfc2822_date(t, 100)); printf("%s\n", show_date(t, 100, 0)); printf("%s\n", ...

The latest is git 1.4.4.4. Available for example from http://kernel.org/pub/software/scm/git/ -- Jakub Narebski Warsaw, Poland ShadeHawk on #git -

l

I think you are talking about the second semantics; I was talking about the first one. In other words, the one whose semantics of: $ git log --max-count=10 --skip=5 --reverse HEAD is to first internally run $ git log --max-count=10 --skip=5 HEAD then reverse the resulting 10 commits and spit them out. Now, "git log --max-count=10 --skip=5" does not need to call limit_list(). It needs to traverse the usual date-sorted revs->commits for fifteen rounds. Looking at your patch ...

I think --reverse is just fine. It is "reverse" from usual, and people already know (or they should learn) what the usual order I only speak for myself, but I always prefer to address my message's To: header to the person I am primarily talking to, while leaving other people on Cc: line (which usually includes the list address). -

Signed-off-by: Yann Dirson <ydirson@altern.org> --- Take two: I had forgotten to add "rebase" to the list of stack commands for the purpose of help. stgit/commands/rebase.py | 69 ++++++++++++++++++++++++++++++++++++++++++++++ stgit/main.py | 2 + t/t2200-rebase.sh | 33 ++++++++++++++++++++++ 3 files changed, 104 insertions(+), 0 deletions(-) diff --git a/stgit/commands/rebase.py b/stgit/commands/rebase.py new file mode 100644 index 0000000..79d67a7 --- ...

Well... to *this* mail indeed :}

[Many thanks to Junio for explaining in generous detail how to think properly about branches in git's distributed model.] We are making progress in our conversion to git, but one of our developers, on pushing into our company repo, has encountered this error: % git push updating 'refs/heads/master' from 6b421066e842203e383e1dc466c1cdef10de56b1 to 2a8e554ae0c99d44988690c9fce693b3f5f128fa Generating pack... Done counting 61 objects. Result has 32 objects. Deltifying 32 objects. ...

Don't tell us tcsh is doing something ugly like opening the tty for stdout/stderr instead of using the ones it inherited from its parent. 'cause that's just useless! -- Shawn. -

That was output to stdout made from the update hook in my case. I do not know your setup, but if you make sure your update hook does not spit out anything to its stdout (diag can go to stderr), you should be able to work it around. Funny thing is, at least in recent enough git, I think we set up redirection to force output from hook scripts to stderr, but I do not remember when it happened. Let's see... ...goes and looks... That was supposed to have been fixed with commit cd83c74c ...

We are using git 1.4.4.1, the latest I thought available, not 1.4.4.4 (perhaps you mis-typed?). In any case, I personally would love to try the latest build of git, but I don't think I can convince the rest of the company to do so. I just got an email from one of the developers. He seems to think this is alleviated by using bash instead of tcsh. He said he is debugging his environment to see if he can isolate the problem. I have asked for more details and if I can find out more, I ...

Hi, BTW this fixes your "git-log --walk-reflogs -1 --pretty=s master@{1.day}" bug. Ciao, Dscho -

Aha, progress ;-). But it still seems to pick up entry that is less than specified number of hours if I do: $ git log --walk-reflogs -4 master@{1.hour} | head -2 commit 33dd19c2a9c0b114436f53d86fc1c2c5e00c26bb Reflog: master@{Sat, 20 Jan 2007 00:01:35 -0800} (Junio C Ham It is Jan 20th 02:10 now and the master was not pointing at that commit 1 hour ago. Anyway, I am done for the night -- I haven't finished testing the updated 'master' and 'next', so I'll push out the ...

The static variable "prefix" was shadowed by an unused parameter of the same name. In case of execution in a subdirectory, the static variable was accessed, leading to a crash. Signed-off-by: Knoppix User <knoppix@zweitrechner.(none)> --- On Sat, 20 Jan 2007, Martin Waitz wrote: > git-apply inside the "src" directory segfaulted. Well, that was not the complete truth now, was it? Cannily, you avoided mentioning the use of the "--cached" argument... But as you see, your evil ...

Here is what I have at the top of the topic (after a few fixups, so it might not apply directly). -- >8 -- [PATCH] Fix --walk-reflog with --pretty=oneline Now, "git log --abbrev-commit --pretty=o --walk-reflogs HEAD" is reasonably pleasant to use. Signed-off-by: Junio C Hamano <junkio@cox.net> --- Documentation/git-rev-list.txt | 4 +++- log-tree.c | 3 ++- reflog-walk.c | 33 ++++++++++++++++++++++----------- reflog-walk.h ...

I'm sure you're right; I don't know enough about CVS to comment. The real fix would seem to be to completely remove the special case for added files and let it drop through to the normal update code. However, I'm not confident about that either. Andy -- Dr Andrew Parkins, M Eng (Hons), AMIEE andyparkins@gmail.com -

Hi, Blame me, not Johannes ;-) As for the #ifdef stuff, I'd rather have a look if it can't be done cleanly by conditional compiling, like we do for NO_MMAP, for example. Ciao, Dscho -

I consider this branch only the sandbox for the MinGW port. Although I've tried to make the branch as clean as possible, it is still a bit messy, and not everything is #ifdef'd that should be. For this reason I will not try to convince Junio to pull this topic directly. The goal is rather to work towards a complete port, then later factor out patches that bring 'master' or 'next' closer to this branch so that finally only at most a I like this idea. -- Hannes -

Most likely it is the st_ino field - the kernel assigns unique inode numbers for pipes from an "unsigned long" counter, which is 64-bit in this case, and *stat() calls must fail with EOVERFLOW if the inode number does not fit into ino_t, which is 32-bit here. This problem is known for some time, and there is even a kernel patch proposed as a workaround (which makes the counter 32-bit): http://permalink.gmane.org/gmane.linux.file-systems/12526 AFAIK, that patch is not upstream yet - so ...

Not that I want to sabotage this discussion, but you have a very valid po= int. A timeout can always be crossed, and then bad things[tm] happen. My idea is to create a marker file when creating (yet) unconnected loose = objects, i.e. on commit/push/fetch. After the ref was updated or on abor= t, this marker would be removed. Prune then can simply search for the ol= dest marker and only remove objects older than this marker. Of course this also can mean that a marker file somehow stays and ...

So this what we typically currently get by using "stg pull . branchname", when HEAD is the stack branch. I can easily see that called as "stg rebase", with --to argument defaulting to parent branch (as given by branch.<name>.merge) when the HEAD is the stack branch. That would be a neat replacement for "stg pull . <name>". Calling 'stg rebase' from the branch to rebase onto, however, can't guess which stack to rebase - there are possibly many stacks forked off your branch. In that case, ...

I'm not sure I understand. Since the "current StGIT stack" is the one pointed to by HEAD, how do you specify, when HEAD points to the target Hm, the operation is not just about moving the stack base, it also has to reapply patches, so, whereas the central concept is about moving the base, the whole operation is indeed about the rebaseing the whole stack. I'm not sure we need to expose the "stack base" to the user as an object she could manipulate all alone, I'd rather think it should ...