* Re: What's cooking in git.git (Aug 2009, #02; Wed, 12)
From: Junio C Hamano @ 2009-08-15 1:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3k516nic0.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
>> * jn/gitweb-blame (Thu Aug 6 19:11:52 2009 +0200) 14 commits
>> - gitweb: Create links leading to 'blame_incremental' using
>> JavaScript
>> - gitweb: Incremental blame (proof of concept)
>> - gitweb: Add optional "time to generate page" info in footer
>> + Revert the four topmost commits from jn/gitweb-blame topic
>> + gitweb: Create links leading to 'blame_incremental' using
>> JavaScript
>> + gitweb: Incremental blame (proof of concept)
>> + gitweb: Add optional "time to generate page" info in footer
>> + gitweb: Add -partial_query option to href() subroutine
>> + gitweb: Use light/dark for class names also in 'blame' view
>> + gitweb: Add author initials in 'blame' view, a la "git gui blame"
>> + gitweb: Mark commits with no "previous" in 'blame' view
>> + gitweb: Use "previous" header of git-blame -p in 'blame' view
>> + gitweb: Mark boundary commits in 'blame' view
>> + gitweb: Make .error style generic
>>
>> I haven't picked up Jakub's replacement to the second one from the tip.
>> We probably should merge up to "Use light/dark" (aef3768) to 'master' and
>> start the rest over.
>
> That would be good idea.
Thanks, will do.
> What about 'gitweb: fix variable scoping issue in git_get_projects_list'
> latest version of patch, adding (re)declaring $project_maxdepth,
> $projectroot as global variables using our? Or are you waiting for
> response of our resident Perl expert: Randal L. Schwartz (merlyn)?
Not in my queue, but no need to resend --- I can find it.
^ permalink raw reply
* Re: [PATCH] git stash: Give friendlier errors when there is nothing to apply
From: Junio C Hamano @ 2009-08-15 1:50 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Ori Avtalion
In-Reply-To: <20090815063956.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
> ...
>> A tangent; we might want an analogue to "shortlog -s -n" but based on
>> "blame".
>
> I'm sorry, I don't understand what you mean.
I often use shortlog to find whom to CC to, but sometimes blame output
gives us a much better picture.
$ git shortlog -s -n git-stash.sh | head -n 6
22 Junio C Hamano
4 Brandon Casey
2 Jeff King
2 Johannes Schindelin
2 Nanako Shiraishi
2 SZEDER Gábor
$ git blame -w git-stash.sh |
sed -e 's/^[0-9a-f]* (\(.*\) *200[7-9]-..-.. .*/\1/' |
sort | uniq -c | sort -n -r | head -n 6
110 Nanako Shiraishi
86 Junio C Hamano
55 Stephen Boyd
33 Brandon Casey
20 Abhijit Menon-Sen
16 Johannes Schindelin
^ permalink raw reply
* Re: [PATCH] block-sha1/sha1.c: silence compiler complaints by casting void* to uintptr_t
From: Junio C Hamano @ 2009-08-15 1:46 UTC (permalink / raw)
To: Brandon Casey
Cc: Linus Torvalds, Johannes Schindelin, nico, git, Brandon Casey
In-Reply-To: <5HEgWEs64y4Ty7FnekstRP8Q71pNi_FTweLbMhYWc6zoZBA4jkJqpQ@cipher.nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> writes:
> Linus Torvalds wrote:
>> I suspect it might as well be cast to "const char *", and then
>> hopefully you only need one cast.
>>
>> So maybe it could be written as
>>
>> data = (const char *) data + len;
>>
>> instead, and avoid the second cast (because the assignment should be ok,
>> since it's assigning back to a "const void *").
>
> Yep, that's enough. It produces an identical binary on all platforms
> except Solaris x86 using SUNWspro compiler.
Casting to "const char *" to tell compilers that we are interested in byte
address differences/increments makes sense to me, but I do not know how to
interpret your last comment.
Do you mean that SUNWspro compiler misbehave with the "cast to char *" and
do you meed your "casting to uintptr_t to explicitly compute byte
addresses as int" to make it behave?
^ permalink raw reply
* Re: http-push sends MKCOL command to create remote directory MKCOL http://user@server:80/url/.git/refs/ that already exists
From: Tay Ray Chuan @ 2009-08-15 1:28 UTC (permalink / raw)
To: willievu; +Cc: git
In-Reply-To: <1250264521299-3445796.post@n2.nabble.com>
Hi,
On Fri, Aug 14, 2009 at 11:42 PM, willievu<willievu@dev.java.net> wrote:
> Is MKCOL expected even for existing directory in the remote repository? Is
> this a WebDAV server problem that 500 is returned?
Yes, you should expect MKCOLs to be done on directories that already
exist. On my Apache server with WebDAV, when a MKCOL is done on a
directory that already exists, it returns 405. Reading the WebDAV
specs (http://www.webdav.org/specs/rfc4918.html#rfc.section.9.3.1):
405 (Method Not Allowed) - MKCOL can only be executed on an unmapped URL.
So this behaviour is accounted for in the spec itself, and git handles this too.
What I think is that your server isn't implementing WebDAV right, or
that you have some scripts/mods over the git repository you're serving
that are failing leading to the 500 error.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH] block-sha1/sha1.c: silence compiler complaints by casting void* to uintptr_t
From: Brandon Casey @ 2009-08-15 0:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: nico, gitster, torvalds, git, Brandon Casey
In-Reply-To: <alpine.DEB.1.00.0908150207270.8306@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 14 Aug 2009, Brandon Casey wrote:
>
>> Some compilers produce errors when arithmetic is attempted on pointers to
>> void. So cast to uintptr_t when performing arithmetic on void pointers.
>
> I am confused. Is sizeof(*(uintptr_t)NULL) not larger than 1, and as a
> consequence ((uintptr_t)p)+1 not different from ((void *)p)+1?
If you try this:
printf("NULL + 1: %u\n", (void*)NULL + 1);
the MIPSpro compiler complains like:
The expression must be a pointer to a complete object type.
printf("NULL + 1: %u\n", (void*)NULL + 1);
^
1 error detected in the compilation of "test.c".
Compilers other than gcc at least issue a warning, if they do
not also fail.
-brandon
^ permalink raw reply
* Re: [PATCH] block-sha1/sha1.c: silence compiler complaints by casting void* to uintptr_t
From: Brandon Casey @ 2009-08-15 0:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, nico, gitster, git, Brandon Casey
In-Reply-To: <alpine.LFD.2.01.0908141714040.3162@localhost.localdomain>
Linus Torvalds wrote:
> I suspect it might as well be cast to "const char *", and then
> hopefully you only need one cast.
>
> So maybe it could be written as
>
> data = (const char *) data + len;
>
> instead, and avoid the second cast (because the assignment should be ok,
> since it's assigning back to a "const void *").
Yep, that's enough. It produces an identical binary on all platforms
except Solaris x86 using SUNWspro compiler.
-brandon
^ permalink raw reply
* Re: [PATCH] block-sha1/sha1.c: silence compiler complaints by casting void* to uintptr_t
From: Linus Torvalds @ 2009-08-15 0:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Brandon Casey, nico, gitster, git, Brandon Casey
In-Reply-To: <alpine.DEB.1.00.0908150207270.8306@pacific.mpi-cbg.de>
On Sat, 15 Aug 2009, Johannes Schindelin wrote:
>
> I am confused. Is sizeof(*(uintptr_t)NULL) not larger than 1
You can't do that. "uintptr_t" isn't actually a pointer. It's just a
unsigned integer value large enough to contain a pointer.
So it's _not_ a "pointer to uint". It's "uint that can contain all the
bits of a poitner".
> and as a consequence ((uintptr_t)p)+1 not different from ((void *)p)+1?
No, they're the same.
That said, I suspect it might as well be cast to "const char *", and then
hopefully you only need one cast.
So maybe it could be written as
data = (const char *) data + len;
instead, and avoid the second cast (because the assignment should be ok,
since it's assigning back to a "const void *").
Linus
^ permalink raw reply
* Re: [PATCH] block-sha1/sha1.c: silence compiler complaints by casting void* to uintptr_t
From: Johannes Schindelin @ 2009-08-15 0:08 UTC (permalink / raw)
To: Brandon Casey; +Cc: nico, gitster, torvalds, git, Brandon Casey
In-Reply-To: <_-0l9qI_nKm-VVtKlL5hzen4bhcyRmiZ1z4jSmKK1LwECXueziRDzSTyacEehOkoqsfYIaEUlds@cipher.nrlssc.navy.mil>
Hi,
On Fri, 14 Aug 2009, Brandon Casey wrote:
> Some compilers produce errors when arithmetic is attempted on pointers to
> void. So cast to uintptr_t when performing arithmetic on void pointers.
I am confused. Is sizeof(*(uintptr_t)NULL) not larger than 1, and as a
consequence ((uintptr_t)p)+1 not different from ((void *)p)+1?
Ciao,
Dscho
^ permalink raw reply
* Linus' sha1 is much faster!
From: Pádraig Brady @ 2009-08-14 23:25 UTC (permalink / raw)
To: Bug-coreutils, Linus Torvalds; +Cc: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
I've noticed before that coreutils hashing utils
were a little behind in performance, but was prompted
to look at it again when I noticed the recently
updated sha1 implementation in git:
http://git.kernel.org/?p=git/git.git;a=history;f=block-sha1;h=d3121f7;hb=pu
Testing that with the attached program which I wrote
in a couple of mins to try and match sha1sum's system calls
shows that it's around 33% faster, as shown below:
$ gcc $(rpm -q --qf="%{OPTFLAGS}\n" coreutils) linus-sha1.c sha1.c -o linus-sha1
$ time ./linus-sha1 300MB_file
df1e19e245fee4f53087b50ef953ca2c8d1644d7 300MB_file
real 0m2.742s
user 0m2.516s
sys 0m0.206s
$ time ~/git/coreutils/src/sha1sum 300MB_file
df1e19e245fee4f53087b50ef953ca2c8d1644d7 300MB_file
real 0m4.166s
user 0m3.846s
sys 0m0.298s
So, could we use that code in coreutils?
Think of all the dead fish it would save.
I've also attached a trivial block-sha1 patch which doesn't
affect performance, but does suppress a signed unsigned
comparison warning which occurs with -Wextra for example.
cheers,
Pádraig.
[-- Attachment #2: linus-sha1.c --]
[-- Type: text/x-csrc, Size: 681 bytes --]
/* gcc -O2 -Wall linus-sha1.c sha1.c -o linus-sha1 */
#include <stdio.h>
#include <stdlib.h>
#include "sha1.h"
int main(int argc, char** argv)
{
if (argc != 2) return 1;
const char* filename = argv[1];
FILE *fp = fopen (filename, "r");
if (!fp) return 1;
#define BS 4096 /* match coreutils */
blk_SHA_CTX ctx;
blk_SHA1_Init(&ctx);
size_t nr;
char buf[BS];
while ((nr=fread_unlocked(buf, 1, sizeof(buf), fp)))
blk_SHA1_Update(&ctx, buf, nr);
unsigned char hash[20];
blk_SHA1_Final(hash, &ctx);
int i;
for (i=0; i<sizeof(hash); i++)
printf("%02x",*(hash+i));
printf(" %s\n", filename);
return 0;
}
[-- Attachment #3: block-sha1-signed-warning.diff --]
[-- Type: text/x-patch, Size: 998 bytes --]
>From fa75e818836f763357ff9b7bbde3327e1aabbe47 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <P@draigBrady.com>
Date: Sat, 15 Aug 2009 00:17:30 +0100
Subject: [PATCH] block-sha1: suppress signed unsigned comparison warning
* block-sha1/sha1.c: Use unsigned ints as the values
will never go negative.
---
block-sha1/sha1.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index d3121f7..be763d8 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -231,13 +231,13 @@ void blk_SHA1_Init(blk_SHA_CTX *ctx)
void blk_SHA1_Update(blk_SHA_CTX *ctx, const void *data, unsigned long len)
{
- int lenW = ctx->size & 63;
+ unsigned int lenW = ctx->size & 63;
ctx->size += len;
/* Read the data into W and process blocks as they get full */
if (lenW) {
- int left = 64 - lenW;
+ unsigned int left = 64 - lenW;
if (len < left)
left = len;
memcpy(lenW + (char *)ctx->W, data, left);
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Luke-Jr @ 2009-08-14 22:54 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Thomas Rast, Luke Dashjr, git
In-Reply-To: <20090815063958.6117@nanako3.lavabit.com>
On Friday 14 August 2009 04:39:58 pm Nanako Shiraishi wrote:
> Second of all, if a race condition makes an "add" fail, isn't it a good
> thing? If your "add" ignored such a failure, you'd be recording an
> inconsistent or incomplete state.
If the file doesn't exist, it is no longer in the current state.
> IMHO, fixing your racy script is a much cleaner solution to your problem
> than forcing "git add" to ignore errors.
In this situation, the race condition is not a bug, it is normal operation.
^ permalink raw reply
* [PATCH] block-sha1/sha1.c: silence compiler complaints by casting void* to uintptr_t
From: Brandon Casey @ 2009-08-14 22:52 UTC (permalink / raw)
To: nico; +Cc: gitster, torvalds, git, Brandon Casey
In-Reply-To: <alpine.LFD.2.00.0908130017080.10633@xanadu.home>
From: Brandon Casey <drafnel@gmail.com>
Some compilers produce errors when arithmetic is attempted on pointers to
void. So cast to uintptr_t when performing arithmetic on void pointers.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
This, on top of Nico's last patch "block-sha1: more good unaligned memory
access candidates", allows this series to compile and run successfully on
Sun Sparc and IRIX MIPS for me.
It produces no differences on Linux using gcc. gcc 3.4.6 and 4.1.2 produce
an identical binary for me on x86 and x86-64 with and without this change.
Any conceivable negative effects on other arch's?
-brandon
block-sha1/sha1.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index e5a1007..ccaba9e 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -246,14 +246,14 @@ void blk_SHA1_Update(blk_SHA_CTX *ctx, const void *data, unsigned long len)
memcpy(lenW + (char *)ctx->W, data, left);
lenW = (lenW + left) & 63;
len -= left;
- data += left;
+ data = (const void*) ((uintptr_t) data + left);
if (lenW)
return;
blk_SHA1_Block(ctx, ctx->W);
}
while (len >= 64) {
blk_SHA1_Block(ctx, data);
- data += 64;
+ data = (const void*) ((uintptr_t) data + 64);
len -= 64;
}
if (len)
--
1.6.4
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #02; Wed, 12)
From: Jakub Narebski @ 2009-08-14 22:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtz0co3xe.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * mr/gitweb-xz (Thu Aug 6 10:28:25 2009 -0400) 3 commits
> - gitweb: add support for XZ compressed snapshots
> - gitweb: update INSTALL regarding specific snapshot settings
> - gitweb: support to globally disable a snapshot format
>
> This should be safe as long as it does not silently enable itself for
> folks who merely updated gitweb to this version without explicitly asking
> for the new format (but I do not remember if that is what the patch does).
The latest version (v5, from 6.08) has XZ compressed snapshot ('txz')
disabled by default.
> * zf/maint-gitweb-acname (Sun Aug 2 09:42:24 2009 +0200) 1 commit
> - gitweb: parse_commit_text encoding fix
Good.
> * jn/gitweb-blame (Thu Aug 6 19:11:52 2009 +0200) 14 commits
> - gitweb: Create links leading to 'blame_incremental' using
> JavaScript
> - gitweb: Incremental blame (proof of concept)
> - gitweb: Add optional "time to generate page" info in footer
> + Revert the four topmost commits from jn/gitweb-blame topic
> + gitweb: Create links leading to 'blame_incremental' using
> JavaScript
> + gitweb: Incremental blame (proof of concept)
> + gitweb: Add optional "time to generate page" info in footer
> + gitweb: Add -partial_query option to href() subroutine
> + gitweb: Use light/dark for class names also in 'blame' view
> + gitweb: Add author initials in 'blame' view, a la "git gui blame"
> + gitweb: Mark commits with no "previous" in 'blame' view
> + gitweb: Use "previous" header of git-blame -p in 'blame' view
> + gitweb: Mark boundary commits in 'blame' view
> + gitweb: Make .error style generic
>
> I haven't picked up Jakub's replacement to the second one from the tip.
> We probably should merge up to "Use light/dark" (aef3768) to 'master' and
> start the rest over.
That would be good idea.
[...]
What about 'gitweb: fix variable scoping issue in git_get_projects_list'
latest version of patch, adding (re)declaring $project_maxdepth,
$projectroot as global variables using our? Or are you waiting for
response of our resident Perl expert: Randal L. Schwartz (merlyn)?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* RE : trailling whitespace with git am ?
From: PICCA Frédéric-Emmanuel @ 2009-08-14 22:21 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0908141516t757d2cb1tc6d0ff3805691418@mail.gmail.com>
> As it all is history (in the new code) already, there is nothing to talk about.
> Git-am in "next" branch just accepts such a patch without a warning.
ok no problem, I will waite for the "next" version :)
thanks
Frederic
^ permalink raw reply
* Re: RE : trailling whitespace with git am ?
From: Alex Riesen @ 2009-08-14 22:16 UTC (permalink / raw)
To: PICCA Frédéric-Emmanuel; +Cc: Junio C Hamano, git
On Fri, Aug 14, 2009 at 23:50, PICCA
Frédéric-Emmanuel<frederic-emmanuel.picca@synchrotron-soleil.fr>
wrote:
> Maybe git apply should warn the user a different way if their is that sort of
> dos/unix imcompatibilities.
As it all is history (in the new code) already, there is nothing to talk about.
Git-am in "next" branch just accepts such a patch without a warning.
^ permalink raw reply
* RE : trailling whitespace with git am ?
From: PICCA Frédéric-Emmanuel @ 2009-08-14 21:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0908141443vc54c009o9ec39b3f617311dd@mail.gmail.com>
> > so /s /t and /r are the same things for git ?
> almost. For git-apply's whitespace fixing code. Why?
Because for the user the message trailling whitespace was not clear
In fact the problem was a dos/unix format not a trailling space.
but whitespace=fix solve this problem. I was surprise first because I was looking for
remaining space at the end of lines of the patch not this CR+LF things.
Maybe git apply should warn the user a different way if their is that sort of dos/unix imcompatibilities.
thanks
Frederic
^ permalink raw reply
* Re: trailling whitespace with git am ?
From: Alex Riesen @ 2009-08-14 21:43 UTC (permalink / raw)
To: PICCA Frédéric-Emmanuel; +Cc: Junio C Hamano, git
On Fri, Aug 14, 2009 at 22:50, PICCA
Frédéric-Emmanuel<frederic-emmanuel.picca@synchrotron-soleil.fr>
wrote:
>> > git am --whitespace=fix was sufficient to apply the patch
>
>> Depending on your situation it can be an overkill: it'll remove _all_ trailing
>> white space. Not just \r (CR).
>
> so /s /t and /r are the same things for git ?
>
almost. For git-apply's whitespace fixing code. Why?
^ permalink raw reply
* Re: rebase-with-history -- a technique for rebasing without trashing your repo history
From: Nanako Shiraishi @ 2009-08-14 21:40 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Bjrn Steinbrink, Git Mailing List
In-Reply-To: <4A85D53D.9050805@alum.mit.edu>
Quoting Michael Haggerty <mhagger@alum.mit.edu>
> In [1] I compared rebase-with-history with both of the
> currently-available options (rebase and merge). Rebase and merge can
> each deal with some of the issues that come up, but each one falls flat
> on others. I believe that rebase-with-history has the advantages of both.
> .... Rebase-with-history is obviously
> not an earth-shattering revolution in DVCS technology, but my hope is
> that it could unobtrusively assist with a few minor pain points.
The saddest part is that your [1] works only in a case a user can easily handle manually, and doesn't help cases more complex than the most trivial ones, such as reordering and squashing commits, where the user may benefit if an automated support from VCS were available.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Nanako Shiraishi @ 2009-08-14 21:39 UTC (permalink / raw)
To: Luke-Jr; +Cc: Junio C Hamano, Thomas Rast, Luke Dashjr, git
In-Reply-To: <200908141539.18087.luke@dashjr.org>
Quoting "Luke-Jr" <luke@dashjr.org>
> On Friday 14 August 2009 02:52:33 pm Junio C Hamano wrote:
>> Thomas Rast <trast@student.ethz.ch> writes:
>> > Junio C Hamano wrote:
>> >> Chould you refresh my memory a bit?
>> >>
>> >> In what circumstance is "rm --ignore-unmatch" useful to begin with?
>> >
>> > Not sure about add --ignore-unmatch myself, but there's even an
>> > example of rm --ignore-unmatch in man git-filter-branch, along the
>> > lines of
>> >
>> > git filter-branch --index-filter '
>> > rm --ignore-unmach some_file_that_shouldnt_be_in_history
>> > ' -- --all
>>
>> Ah, that makes sense. I am not sure about "add --ignore-unmatch" myself
>> either, and an example similar to the above filter-branch would not apply
>> very easily (i.e. "add a file that should have been in history" would not
>> need --ignore-unmatch).
>
> The purpose of "add --ignore-unmatch" is to ignore race conditions where one
> of the files to be added has been deleted after git is executed, but before
> git scans it.
First of all, it should have been mentioned as part of your proposed commit log message.
Second of all, if a race condition makes an "add" fail, isn't it a good thing? If your "add" ignored such a failure, you'd be recording an inconsistent or incomplete state.
IMHO, fixing your racy script is a much cleaner solution to your problem than forcing "git add" to ignore errors.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] git stash: Give friendlier errors when there is nothing to apply
From: Nanako Shiraishi @ 2009-08-14 21:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ori Avtalion
In-Reply-To: <7v3a7ujhqb.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Ori Avtalion <ori@avtalion.name> writes:
>
>> The change makes sure a stash (given or default) exists before
>> checking if the working tree is dirty.
>>
>> If the default stash is requested, the old message was scary and
>> included a 'fatal' error from rev-parse:
>> fatal: Needed a single revision
>> : no valid stashed state found
>>
>> It is replaced with a friendlier 'Nothing to apply' error, similar to
>> 'git stash branch'.
>>
>> If a specific stash is specified, the 'Needed a single revision' errors
>> from rev-parse are suppressed.
>>
>> Signed-off-by: Ori Avtalion <ori@avtalion.name>
>> Acked-by: Thomas Rast <trast@student.ethz.ch>
>
> I do not see anything that might break existing usage of the command.
> Comments?
The patch looks good to me. I think it was my fault but you can avoid
adding two extra --quiet by inspecting i_tree (in other words, "$s^2:")
before w_tree and b_tree. Because a commit that is a stash exactly has
two parents, it may be good to also make sure 'git rev-parse "$s^3"'
fails.
s=$(git rev-parse --verify --default $ref_stash "$@") &&
! git rev-parse --quiet --verify "$s^3" >/dev/null &&
i_tree=$(git rev-parse --quiet --verify "$s^2:") &&
b_tree=$(git rev-parse --verify "$s^1:") &&
w_tree=$(git rev-parse --verify "$s:") ||
die "$*: no valid stashed state found"
> A tangent; we might want an analogue to "shortlog -s -n" but based on
> "blame".
I'm sorry, I don't understand what you mean.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: rebase-with-history -- a technique for rebasing without trashing your repo history
From: Michael Haggerty @ 2009-08-14 21:21 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Git Mailing List
In-Reply-To: <20090813233027.GA19833@atjola.homenet>
Björn Steinbrink wrote:
> On 2009.08.14 00:39:48 +0200, Michael Haggerty wrote:
>> Björn Steinbrink wrote:
>>> On 2009.08.13 14:46:07 +0200, Michael Haggerty wrote:
>>> And even for just continously forward porting a series of commits, a
>>> common case might be that upstream applied some patches, but not all.
>>> Can you deal with that?
[A discussion of various unsatisfactory approaches omitted...]
> But that's obviously total crap.
So I think we agree that it is not possible to retain history for a case
like this (which is essentially a general cherry-pick).
> [...]
> Doing a plain "git rebase subsystem topic" would of course also try to
> rebase the "o" commits, so that problematic. Instead, you do:
>
> git rebase --onto subsystem O topic
>
> That turns O..topic (the * commits) into patches, and applies them on
> top of O'. So the "o" commits aren't to be rebased.
>
> And that's exactly what your rebase-with-history would do as well. Just
> that O is naturally a common ancestor of subsystem and topic, and so
> just using "git rebase-w-h subsystem topic" would be enough. Conflicts
> etc. should be 100% the same.
>
> If you know that your upstream is going to rebase/rewrite history, you
> can tag (or otherwise mark) the current branching point of your branch,
> so you can easily specify it for the --onto rebase. IOW: This is
> primarily a social problem (tell your downstream that you rebase this or
> that branch), but having built-in support to store the branching point
> for rebasing _might_ be worth a thought.
Recording branch points manually, coordinating merges via email -- OMG
you are giving me flashbacks of CVS ;-)
*Of course* you can get around all of these problems if you put the
burden of bookkeeping on the user. The whole point of
rebase-with-history is to have the VCS handle it automatically!
>> and merging in a topic branch makes it more difficult to create an
>> easily-reviewable patch series. rebase-with-history has neither of
>> these problems.
>
> Sure, merging is a no-go if you submit patches by email (or other,
> similar means). But you compared that to an "enhanced" rebase approach,
> instead of comparing your rebase approach to the currently available
> one.
In [1] I compared rebase-with-history with both of the
currently-available options (rebase and merge). Rebase and merge can
each deal with some of the issues that come up, but each one falls flat
on others. I believe that rebase-with-history has the advantages of both.
The example in [2] was taken straight from the git-rebase man page [3];
I did not want to claim that current practice would use merging in this
situation, but rather just to show that rebase-with-history removes the
pain from this well-known example.
I think we are mostly in agreement. Rebase-with-history is obviously
not an earth-shattering revolution in DVCS technology, but my hope is
that it could unobtrusively assist with a few minor pain points.
Michael
[1]
http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html
[2]
http://softwareswirl.blogspot.com/2009/08/upstream-rebase-just-works-if-history.html
[3] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
^ permalink raw reply
* [PATCH v5 0/6] Re: {checkout,reset,stash} --patch
From: Nicolas Sebrecht @ 2009-08-14 20:57 UTC (permalink / raw)
To: Thomas Rast
Cc: Junio C Hamano, git, Jeff King, Sverre Rabbelier,
Nanako Shiraishi, Nicolas Sebrecht, Pierre Habouzit
In-Reply-To: <cover.1250164190.git.trast@student.ethz.ch>
The 13/08/09, Thomas Rast wrote:
> Junio C Hamano wrote:
> > * tr/reset-checkout-patch (Tue Jul 28 23:20:12 2009 +0200) 8 commits
> [...]
> > Progress?
>
> Slow, as always. There are three groups of changes:
<...>
> Thomas Rast (7):
> git-apply--interactive: Refactor patch mode code
> Add a small patch-mode testing library
> builtin-add: refactor the meat of interactive_add()
> Implement 'git reset --patch'
> Implement 'git checkout --patch'
> Implement 'git stash save --patch'
> DWIM 'git stash save -p' for 'git stash -p'
Tested-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
--
Nicolas Sebrecht
^ permalink raw reply
* RE : RE : RE : trailling whitespace with git am ?
From: PICCA Frédéric-Emmanuel @ 2009-08-14 20:50 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0908141348icee65d6kf4188cbd68405c0c@mail.gmail.com>
> > git am --whitespace=fix was sufficient to apply the patch
> Depending on your situation it can be an overkill: it'll remove _all_ trailing
> white space. Not just \r (CR).
so /s /t and /r are the same things for git ?
^ permalink raw reply
* Re: RE : RE : trailling whitespace with git am ?
From: Alex Riesen @ 2009-08-14 20:48 UTC (permalink / raw)
To: PICCA Frédéric-Emmanuel; +Cc: Junio C Hamano, git
On Fri, Aug 14, 2009 at 22:46, PICCA
Frédéric-Emmanuel<frederic-emmanuel.picca@synchrotron-soleil.fr>
wrote:
>> how can I do the difference between a patch with normal CR+LF (the autor use this format)
>> and a patch without CR+LF due to the webmail ?
>
>> That is a question to your webmail provider but I think you generally
>> can't. Use dos2unix as Alex suggested and you should be fine.
>
> git am --whitespace=fix was sufficient to apply the patch
>
Depending on your situation it can be an overkill: it'll remove _all_ trailing
white space. Not just \r (CR).
^ permalink raw reply
* Re: [PATCH 1/5] port --ignore-unmatch to "git add"
From: Luke-Jr @ 2009-08-14 20:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Luke Dashjr, git
In-Reply-To: <200908141539.18087.luke@dashjr.org>
Specific use-case of "git add --ignore-unmatched":
http://gitorious.org/gitbackup
Without this functionality, daily race conditions will break the
synchronisation.
^ permalink raw reply
* RE : RE : trailling whitespace with git am ?
From: PICCA Frédéric-Emmanuel @ 2009-08-14 20:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vab22i1dl.fsf@alter.siamese.dyndns.org>
> how can I do the difference between a patch with normal CR+LF (the autor use this format)
> and a patch without CR+LF due to the webmail ?
> That is a question to your webmail provider but I think you generally
> can't. Use dos2unix as Alex suggested and you should be fine.
git am --whitespace=fix was sufficient to apply the patch
^ 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