* git reveals a bug in (some versions) BSD diff
From: Johannes Schindelin @ 2005-08-12 12:32 UTC (permalink / raw)
To: git
Hi,
big was my surprise when my daily routine of "git pull" && "make test"
failed. "git bisect" revealed that commit 8e832e: "String comparison of
test is done with '=', not '=='." was the culprit.
But it isn't. The version of diff present on my iBook (OS 10.2.8) does not
work properly in this case:
(echo a; echo b | tr -d '\012') >frotz.2
(echo a; echo c; echo b | tr -d '\012') >frotz.3
diff -u frotz.2 frotz.3
yields
--- a1 2005-08-12 14:24:19.000000000 +0200
+++ a2 2005-08-12 14:24:27.000000000 +0200
@@ -1,2 +1,3 @@
a
+c
b
Note the missing "\ No newline at end of file". The same happens on
sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2
server.
How to go about that? Silently ignore the missing line in apply.c? Force
users to update their diff to a sane version?
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Use "-script" postfix for scripts
From: Johannes Schindelin @ 2005-08-12 13:28 UTC (permalink / raw)
To: git
For consistency reasons, the names of all scripts should end in "-script".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This may be a bit controversial (people might find it unnecessary).
Subject to discussion.
---
Makefile | 15 ++++++++-------
git-cherry-script | 0
git-clone-dumb-http-script | 0
git-clone-script | 2 +-
git-rebase-script | 4 ++--
git-request-pull-script | 4 ++--
git-shortlog-script | 0
git-whatchanged-script | 0
8 files changed, 13 insertions(+), 12 deletions(-)
rename git-cherry => git-cherry-script (100%)
rename git-clone-dumb-http => git-clone-dumb-http-script (100%)
rename git-shortlog => git-shortlog-script (100%)
rename git-whatchanged => git-whatchanged-script (100%)
5cc55f08d874b61f1067857c7310fac325504ec8
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -58,15 +58,16 @@ SPARSE_FLAGS?=-D__BIG_ENDIAN__ -D__power
SCRIPTS=git git-apply-patch-script git-merge-one-file-script git-prune-script \
- git-pull-script git-tag-script git-resolve-script git-whatchanged \
- git-fetch-script git-status-script git-commit-script \
- git-log-script git-shortlog git-cvsimport-script git-diff-script \
- git-reset-script git-add-script git-checkout-script git-clone-script \
- gitk git-cherry git-rebase-script git-relink-script git-repack-script \
+ git-pull-script git-tag-script git-resolve-script \
+ git-whatchanged-script git-fetch-script git-status-script \
+ git-commit-script git-log-script git-shortlog-script \
+ git-cvsimport-script git-diff-script git-reset-script git-add-script \
+ git-checkout-script git-clone-script gitk git-cherry-script \
+ git-rebase-script git-relink-script git-repack-script \
git-format-patch-script git-sh-setup-script git-push-script \
git-branch-script git-parse-remote git-verify-tag-script \
- git-ls-remote-script git-clone-dumb-http git-rename-script \
- git-request-pull-script git-bisect-script
+ git-ls-remote-script git-clone-dumb-http-script \
+ git-rename-script git-request-pull-script git-bisect-script
SCRIPTS += git-count-objects-script
# SCRIPTS += git-send-email-script
diff --git a/git-cherry b/git-cherry-script
similarity index 100%
rename from git-cherry
rename to git-cherry-script
diff --git a/git-clone-dumb-http b/git-clone-dumb-http-script
similarity index 100%
rename from git-clone-dumb-http
rename to git-clone-dumb-http-script
diff --git a/git-clone-script b/git-clone-script
--- a/git-clone-script
+++ b/git-clone-script
@@ -89,7 +89,7 @@ yes,yes)
rsync $quiet -avz --ignore-existing "$repo/refs/" "$D/.git/refs/"
;;
http://*)
- git-clone-dumb-http "$repo" "$D"
+ git-clone-dumb-http-script "$repo" "$D"
case "$?" in
2)
echo "Somebody should define smarter http server protocol" >&2
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -7,7 +7,7 @@
usage="usage: $0 "'<upstream> [<head>]
-Uses output from git-cherry to rebase local commits to the new head of
+Uses output from git-cherry-script to rebase local commits to the new head of
upstream tree.'
case "$#,$1" in
@@ -36,7 +36,7 @@ trap "rm -rf $tmp-*" 0 1 2 3 15
>$fail
-git-cherry $upstream $ours |
+git-cherry-script $upstream $ours |
while read sign commit
do
case "$sign" in
diff --git a/git-request-pull-script b/git-request-pull-script
--- a/git-request-pull-script
+++ b/git-request-pull-script
@@ -24,12 +24,12 @@ headrev=`git-rev-parse --verify $head^0`
echo "The following changes since commit $baserev:"
git log --max-count=1 --pretty=short "$baserev" |
-git-shortlog | sed -e 's/^\(.\)/ \1/'
+git-shortlog-script | sed -e 's/^\(.\)/ \1/'
echo "are found in the git repository at:"
echo
echo " $url"
echo
-git log $baserev..$headrev | git-shortlog ;
+git log $baserev..$headrev | git-shortlog-script ;
git diff $baserev..$headrev | git-apply --stat --summary
diff --git a/git-shortlog b/git-shortlog-script
similarity index 100%
rename from git-shortlog
rename to git-shortlog-script
diff --git a/git-whatchanged b/git-whatchanged-script
similarity index 100%
rename from git-whatchanged
rename to git-whatchanged-script
^ permalink raw reply
* [PATCH] Add "--sign" option to git-format-patch-script
From: Johannes Schindelin @ 2005-08-12 13:32 UTC (permalink / raw)
To: git
This adds the option "--sign" to git-format-patch-script which adds
a Signed-off-by: line automatically.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-format-patch-script | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
a72d370d43c397238a26c1c7f260a3fd6401f4e6
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -6,7 +6,7 @@
. git-sh-setup-script || die "Not a git archive."
usage () {
- echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [-<diff options>...] upstream [ our-head ]
+ echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [--sign] [-<diff options>...] upstream [ our-head ]
Prepare each commit with its patch since our-head forked from upstream,
one file per patch, for e-mail submission. Each output file is
@@ -46,6 +46,8 @@ do
date=t author=t mbox=t ;;
-n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered)
numbered=t ;;
+ -s|--s|--si|--sig|--sign)
+ signoff=t ;;
-o=*|--o=*|--ou=*|--out=*|--outp=*|--outpu=*|--output=*|--output-=*|\
--output-d=*|--output-di=*|--output-dir=*|--output-dire=*|\
--output-direc=*|--output-direct=*|--output-directo=*|\
@@ -174,6 +176,14 @@ Date: '"$ad"
b body'
sed -ne "$mailScript" <$commsg
+
+ test "$signoff" = "t" && {
+ offsigner=`git-var GIT_COMMITTER_IDENT | sed -e 's/>.*/>/'`
+ echo
+ echo "Signed-off-by: $offsigner"
+ echo
+ }
+
echo '---'
echo
git-diff-tree -p $diff_opts "$commit" | git-apply --stat --summary
^ permalink raw reply
* Re: [PATCH] Clean generated files a bit more.
From: Junio C Hamano @ 2005-08-12 13:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050812114053.GB29893@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> This makes me a bit nervous - why are you making the rules more general?
> make clean removing random tarballs of mine happenning to dwell in that
> directory is fearsome.
That is a valid concern. I'd drop that *.tar.gz part at
least and probably the *.deb *.dsc part as well. Thanks for
sanity checking.
^ permalink raw reply
* Re: [PATCH] Use "-script" postfix for scripts
From: Junio C Hamano @ 2005-08-12 15:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508121526050.25606@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> For consistency reasons, the names of all scripts should end in "-script".
>
> This may be a bit controversial (people might find it unnecessary).
> Subject to discussion.
I have never liked the original -script name convention. It
only meant that they are implemented as scripts (as opposed to
those on the $(PROG) Makefile variable), but the end users who
end up typing their names from the command line, and to a lesser
degree the people who use them in their scripts, should not care
how they are implemented to begin with.
And to cope with long names and make things look a bit more
familiar to CVS migrants, "git" wrapper was invented to supply
the -script suffix to grok "git whatever", but just in case if
something was _not_ implemented as a script, it ends up needing
to try "git-whatever" in addition to "git-whatever-script". The
patch alleviates the "git" problem for "git-whatchanged" and
friends whose names currently do not end with -script, but it
still does not help "git apply", for example. I like the
general direction of making things consistent, but I wonder if
we can become consistent by losing -script suffix, not adding to
the ones that lack it.
And as you imply, this kind of change inevitable breaks people's
scripts. But I do agree with you that we should do something
about it, so it may be better to break them sooner rather than
later, as long as we make sure we break them just once.
^ permalink raw reply
* Re: [PATCH] Re: git-http-pull broken in latest git
From: Daniel Barkalow @ 2005-08-12 15:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vll37afz4.fsf@assigned-by-dhcp.cox.net>
On Thu, 11 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > Petr Baudis <pasky@suse.cz> writes:
> >> Yes, but cg-clone doesn't - it naively depended on the core git tools
> >> actually, er.. working. ;-)
>
> Sorry about that. I used to have a wrapper to deal with packs
> around http-pull before Daniel's pack enhancement, and yanking
> it before really checking that enhanced http-pull actually
> worked was my fault as well.
It was actually the patches after the http-pull fixes (the ones for
parallelizing pull.c) that broke things; one advantage to fixing
local-pull would be that you can set up tests for it reasonably
effectively, which would have caught the regression.
> > At some point, I have to revisit getting git-ssh-* to generate exactly the
> > required pack and transfer that, but that's an efficiency issue, not a
> > correctness one, and shouldn't be relevant to the problem you're having.
>
> Wouldn't enhancing ssh-push to generate packs on the fly involve
> reinventing send-pack and/or upload-pack?
The idea is that you wouldn't have to identify what situation applied
yourself; you could just invoke git-ssh-pull/git-ssh-push, and it would
happen faster due to the compression benefits. The point is that scripts
can just pick which git-*-pull to use based on the format of the remote
branch address, without variation in behavior.
> The same thing can be said about local-pull to a lesser degree.
> Lesser because people, including Pasky who said so on the list
> recently, would like its hard-linking behaviour, and its not
> exploding the existing packs, which send-pack and upload-pack
> would not give. So I would rate local-pull higher than
> ssh-push/pull on the priority scale if I were doing them.
This is a higher priority, but writing more than bugfixes is unpleasent at
the moment due to my home workstation's monitor dying, so it'll probably
be next week that I'll get to it. The git-ssh-* stuff is longer-term,
since it works now, and isn't even all that slow with the overlapping
requests.
You could, actually, probably do the local-pull fix if you wanted. I seem
to recall that being your code originally; you just need to have fetch()
identify that an object is in a pack, copy/link/symlink the index and
pack instead of the object file, and add the pack to the list of
registered packs. I've mostly been failing to deal with reading an index
file that is in some directory that hasn't been registered as somewhere to
read from (i.e. the source repository).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Add "--sign" option to git-format-patch-script
From: Junio C Hamano @ 2005-08-12 15:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508121532051.25606@wgmdd8.biozentrum.uni-wuerzburg.de>
Good intentions, but I'd rather see these S-O-B lines in the
actual commit objects. Giving format-patch this option would
discourage people to do so. Maybe a patch to git commit would
be more appropriate, methinks.
^ permalink raw reply
* Re: git reveals a bug in (some versions) BSD diff
From: Junio C Hamano @ 2005-08-12 15:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508121424500.24891@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Note the missing "\ No newline at end of file". The same happens on
> sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2
> server.
>
> How to go about that? Silently ignore the missing line in apply.c? Force
> users to update their diff to a sane version?
Hmph. We could tackle this two ways. We probably _could_
special case the trailing newline case if this problem is
widespread, but a more general solution would be to teach
git-apply '--fuzz'. On the other hand, we could configure to
use gdiff (or whatever GNU diff is called on those hosts with
broken diff command) at the build time. Probably it would be
the bast to have an explicit option --fuzz to git-apply.
^ permalink raw reply
* Re: [PATCH] Add "--sign" option to git-format-patch-script
From: Daniel Barkalow @ 2005-08-12 15:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vr7czxj6s.fsf@assigned-by-dhcp.cox.net>
On Fri, 12 Aug 2005, Junio C Hamano wrote:
> Good intentions, but I'd rather see these S-O-B lines in the
> actual commit objects. Giving format-patch this option would
> discourage people to do so. Maybe a patch to git commit would
> be more appropriate, methinks.
Maybe also something in format-patch to check that the commit has one? I,
at least, tend to have unsigned commits for tracking stuff I've done but
not cleaned up and signed ones that I want to send off as patches. I've
confused the branches on occasion, although never when sending stuff, and
it would be nice to have format-patch tell you if the commit didn't look
right.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Use "-script" postfix for scripts
From: Johannes Schindelin @ 2005-08-12 16:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtmrxjbb.fsf@assigned-by-dhcp.cox.net>
hI,
On Fri, 12 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > For consistency reasons, the names of all scripts should end in "-script".
> >
> > This may be a bit controversial (people might find it unnecessary).
> > Subject to discussion.
>
> I have never liked the original -script name convention.
Okay. I'm all for dropping the "-script" postfix.
Ciao,
Dscho
^ permalink raw reply
* Re: git reveals a bug in (some versions) BSD diff
From: Johannes Schindelin @ 2005-08-12 16:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5ojxiny.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 12 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Note the missing "\ No newline at end of file". The same happens on
> > sourceforge's compile farm's OS 10.1 server, but not on its OS 10.2
> > server.
> >
> > How to go about that? Silently ignore the missing line in apply.c? Force
> > users to update their diff to a sane version?
>
> Hmph. We could tackle this two ways. We probably _could_
> special case the trailing newline case if this problem is
> widespread, but a more general solution would be to teach
> git-apply '--fuzz'. On the other hand, we could configure to
> use gdiff (or whatever GNU diff is called on those hosts with
> broken diff command) at the build time. Probably it would be
> the bast to have an explicit option --fuzz to git-apply.
I'd prefer to deprecate that diff program by telling so in the test.
Something along the lines "blabla. If this fails, chances are you have a
borked diff. Try GNU diff..."
Ciao,
Dscho
BTW: On my system, gdiff does not exist.
^ permalink raw reply
* Re: [PATCH] Add "--sign" option to git-format-patch-script
From: Johannes Schindelin @ 2005-08-12 16:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7czxj6s.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 12 Aug 2005, Junio C Hamano wrote:
> Good intentions, but I'd rather see these S-O-B lines in the
> actual commit objects. Giving format-patch this option would
> discourage people to do so. Maybe a patch to git commit would
> be more appropriate, methinks.
Maybe in addition to this one? I meant that option to be for on-passers of
commits they are not author of.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] fetch-pack: start multi-head pulling.
From: Linus Torvalds @ 2005-08-12 16:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vwtmr4hm5.fsf@assigned-by-dhcp.cox.net>
On Fri, 12 Aug 2005, Junio C Hamano wrote:
>
> Linus, I need a bit of guidance from you about this one; an
> ancient commit 4f7770c87ce3c302e1639a7737a6d2531fe4b160 removed
> the multi-head support fetch-pack once had, labelling it as "a
> misguided attempt", and I would like to know if I am making the
> same misguided attempt again. This update actually makes
> clone-pack almost redundant.
I like your version.
My misguided attempt was not the ability to pull multiple heads, but what
to _do_ with them. I originally envisioned something more "git-push-pack"
like, where it would pull multiple heads into real references, and _that_
was the misguided part. I then ended up just printing it out to stdout,
and that made it "one ref only".
Your version where you just print out multiple heads with names is, I
think, the right thing to do.
The shell script looks a bit unreadable to me, personally.
> head=$(git-fetch-pack "$merge_repo" "$merge_head")
> + if h=`expr "$head" : '\([^ ][^ ]*\) '`
> + then
> + head=$h
> + fi
Back-ticks, and the ":" operator to "expr". You really _are_ old-fashioned
when it comes to shell ;)
Wouldn't it be simpler/cleaner to just do
head=($(git-fetch-pack "$merge_repo" "$merge_head"))
which gets you "$head" being the same as ${head[0]}, namely the SHA1 you
want (and if you ever implement multi-head pulling, you'll have it all in
${head[..]}..)
Linus
^ permalink raw reply
* Re: [PATCH] fetch-pack: start multi-head pulling.
From: Johannes Schindelin @ 2005-08-12 16:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508120858420.3295@g5.osdl.org>
Hi,
On Fri, 12 Aug 2005, Linus Torvalds wrote:
> Wouldn't it be simpler/cleaner to just do
>
> head=($(git-fetch-pack "$merge_repo" "$merge_head"))
I seem to remember Junio does not like bash arrays... And in a recent
commit message, he even admits to using something different than bash!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add "--sign" option to git-format-patch-script
From: Junio C Hamano @ 2005-08-12 16:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Daniel Barkalow
In-Reply-To: <Pine.LNX.4.63.0508121804240.26333@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Fri, 12 Aug 2005, Junio C Hamano wrote:
>
>> Good intentions, but I'd rather see these S-O-B lines in the
>> actual commit objects. Giving format-patch this option would
>> discourage people to do so. Maybe a patch to git commit would
>> be more appropriate, methinks.
>
> Maybe in addition to this one? I meant that option to be for on-passers of
> commits they are not author of.
Surely. Also I find Daniel's suggestion to check a good one.
^ permalink raw reply
* Re: git reveals a bug in (some versions) BSD diff
From: Junio C Hamano @ 2005-08-12 16:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508121801310.26333@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I'd prefer to deprecate that diff program by telling so in the test.
> Something along the lines "blabla. If this fails, chances are you have a
> borked diff. Try GNU diff..."
Wouldn't it give the people with broken diff a false impression
that their "git diff" actually produces a good result when it
does not?
^ permalink raw reply
* Re: [PATCH] fetch-pack: start multi-head pulling.
From: Junio C Hamano @ 2005-08-12 16:43 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0508121818230.26488@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I seem to remember Junio does not like bash arrays... And in a recent
> commit message, he even admits to using something different than bash!
Correct and somewhat misleading. My usual shell is bash but
from time to time I try to run things with (d)ash to see how far
I strayed from the common denominator.
Yes, I am old fashioned.
I have been trying, admittably perhaps not very successfully, to
stay away from bashism in the core GIT scripts. I knew we
started using shell array when Linus did the git-diff-script,
but I have been hoping somebody coming from other platforms
(hello, Solaris and Darwin guys) would send in patches if they
cared enough. So I try to avoid making their life harder than
already is.
Here is a semi off-topic joke, hopefully to give you a better
sense of where I am coming from.
Anybody can start pretending to be an old fashioned shell
programmer by adhering to the following simple rules:
1. Never, ever say [ ... ]; we old-timers always spell that
"test".
2. Never use "test" when "case" would do; this comes from
the days when test was not built-in and machines were
small. We tried to reduce number of forks in our
scripts. We also never use echo piped to grep when
"case" would do.
3. We tend to write && || more often than we use if
... then ... fi, especially for simple things. We do
not use parantheses () to introduce command grouping
lightly. We usually say braces {} and use parentheses
only when we do want a subshell.
4. Say ${var-default} more often than ${var:-default};
colon form is more recent invention, and we old-timers
tend to be more careful to consider the possibility
that, when a user says this variable is empty, the user
really means it.
5. We are still allowed to use $() form in preference to
``, because it is clearly superior (it can nest) and
should have been the way to spell it from the beginning.
-jc
^ permalink raw reply
* Re: [PATCH] fetch-pack: start multi-head pulling.
From: Linus Torvalds @ 2005-08-12 17:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0508121818230.26488@wgmdd8.biozentrum.uni-wuerzburg.de>
On Fri, 12 Aug 2005, Johannes Schindelin wrote:
>
> I seem to remember Junio does not like bash arrays...
Well, fair enough, although they aren't really "bash" arrays, they
appeared in other shells before "bash".
At least ksh and zsh have them, although the zsh implementation seems to
be pretty broken (indices start at 1, and $var acts like $var[*] etc).
Afaik, ksh is actually the origin of the thing.
Linus
^ permalink raw reply
* git checkout -f branch doesn't remove extra files
From: Luck, Tony @ 2005-08-12 17:31 UTC (permalink / raw)
To: git
I've just got around to noticing some of the new (to
me) features in git, and started experimenting with
branches.
I see that when I switch view to a different
branch with:
$ git checkout -f someoldbranch
that any files that exist in my previous branch view
but not in "someoldbranch" are not deleted. I can
find and remove them easily with:
$ git-ls-files --others | xargs rm -f
but I wondered whether this was a deliberate choice
(to avoid clobbering .o files etc. for people who
have run a make in their tree).
Currently git-ls-files doesn't have a way to specify
a branch ... but it it did, the something like:
comm -1 <(git-ls-files -b oldbranch) \
<(git-ls-files -b newbranch) | xargs rm -f
would clean up the spurious files.
-Tony
^ permalink raw reply
* Re: kernel.org git web interface
From: Jeff Carr @ 2005-08-12 18:08 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Hubert Tonneau, git
In-Reply-To: <20050810162329.GA8574@mars.ravnborg.org>
> On Wed, Aug 10, 2005 at 03:59:02PM +0000, Hubert Tonneau wrote:
>
>>The 'V' column on http://www.kernel.org/ is very convienient to review what
>>has changed in a new kernel (files list, then simple clic diff access to the
>>selected file).
>>
>>Now, the git changelog is also interesting (provides overall explaination),
>>but it's harder to use because the changes stream is so dense.
>>
>>So, what would be helpfull for reviewers is the ability to view the git
>>changelog of only the changes that touch a given file.
>>I mean when we select the 'V' column, have two links per modified file,
>>one displaying the diff has it currently does, and the other displaying
>>the git changes as 'C' column does, but filtered with only changes that
>>touch the selected file.
That would be useful. Maybe someone really ambitious would figure out a
way to use imagemagick to generate visual tiles that could be feed into
the google maps API. Then we could "fly" around the sources too.
Jeff
http://mapki.com/index.php?title=Add_Your_Own_Custom_Map
^ permalink raw reply
* [OT?] git tools at SourceForge ?
From: Wolfgang Denk @ 2005-08-12 19:07 UTC (permalink / raw)
To: git
This is somewhat off topic here, so I apologize, but I didn't know
any better place to ask:
Has anybody any information if SourceForge is going to provide git /
cogito / ... for the projects they host? I asked SF, and they openend
a new Feature Request (item #1252867); the message I received sounded
as if I was the first person on the planet to ask...
Am I really alone with this?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
There are three things I always forget. Names, faces - the third I
can't remember. - Italo Svevo
^ permalink raw reply
* Re: [PATCH] Debian packaging for 0.99.4
From: Junio C Hamano @ 2005-08-12 20:21 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <20050810235436.GW28270@kiste.smurf.noris.de>
Matthias Urlichs <smurf@smurf.noris.de> writes:
> - Split gitk off to its own package;
> it needs tk installed, but nothing else does.
I just noticed from "dpkg --info" output that the generated
git-tk has "Architecture: i386". Shouldn't it read "all" and
resulting package also named git-tk_${VERSION}_all.deb, instead
of whatever architecture I happened to build it?
^ permalink raw reply
* Re: git checkout -f branch doesn't remove extra files
From: Junio C Hamano @ 2005-08-12 20:27 UTC (permalink / raw)
To: Luck, Tony; +Cc: git
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F04214AC7@scsmsx401.amr.corp.intel.com>
"Luck, Tony" <tony.luck@intel.com> writes:
> I see that when I switch view to a different
> branch with:
>
> $ git checkout -f someoldbranch
>
> that any files that exist in my previous branch view
> but not in "someoldbranch" are not deleted.
>
> ... I wondered whether this was a deliberate choice
Not really.
When possible, please use "git checkout" without -f. That form
uses "git-read-tree -u -m", which can tell from your current
index file what's changed and what's going away. This is only
possible if read-tree can rely on what is in your index file
actually matches the status of your working tree, and the -f
flag to checkout is to work around cases where you cannot give
that guarantee to read-tree and would want/need to start over
from scratch. With -f flag, you are telling git-read-tree to
ignore what is currently recorded in your index file, hence what
should be in your working tree before checkout. There is no way
for git-read-tree to tell which are source files that exist only
in the old thing you had checked out before (i.e. should be
removed) and which are files your build procedure left and/or
files you made by hand outside of SCM control (i.e. should be
kept) without that information, so that is why those files were
left behind.
^ permalink raw reply
* Re: gitweb - feature request
From: Kay Sievers @ 2005-08-12 20:27 UTC (permalink / raw)
To: Ian Campbell; +Cc: Sam Ravnborg, git
In-Reply-To: <1123653220.1183.26.camel@azathoth.hellion.org.uk>
On Wed, Aug 10, 2005 at 06:53:40AM +0100, Ian Campbell wrote:
> On Tue, 2005-08-09 at 21:58 +0200, Kay Sievers wrote:
>
> > I was hoping people that want stuff like this would use a RSS reader. :)
>
> I used to subscribe to the kernel RSS feed (using blam) but I found I
> was only getting the most recent 20 commits, which wasn't much good when
> a big batch went in because I would miss some. Has this been fixed or
> was it something I was doing wrong?
It's 30 now and up to 150 if they are not older than 48 hours. We can
tweak the numbers if you like to have it different...
Kay
^ permalink raw reply
* Re: gitweb - feature request
From: Kay Sievers @ 2005-08-12 20:33 UTC (permalink / raw)
To: Mitchell Blank Jr; +Cc: Ian Campbell, git
In-Reply-To: <20050810083113.GN49964@gaz.sfgoth.com>
On Wed, Aug 10, 2005 at 01:31:13AM -0700, Mitchell Blank Jr wrote:
> Ian Campbell wrote:
> > I used to subscribe to the kernel RSS feed (using blam) but I found I
> > was only getting the most recent 20 commits, which wasn't much good when
> > a big batch went in because I would miss some.
>
> Yes, I have that problem too. It appears to be just the way that gitweb
> works - look at the "git_rss" function in the source:
> ftp://ftp.kernel.org/pub/software/scm/gitweb/gitweb.cgi
>
> Kay -- is there any chance of fixing this? I love reading the kernel
> commits via RSS but this makes it a lot less usable than it could be.
> Really it should return all commits within, say, the last 36 hours so as
> long as your aggregator polls reasonably often you won't miss anyhing.
It's 30 now and up to 150 if they are not older than 48 hours.
We can change the numbers, if you hava a better idea...
> The other thing on my wishlish is diffstat -- sometimes the commit messages
> can be a little ambiguous and just adding what files were changed would
> help alot. For commits that touch a large number of files maybe it could
> just show the files that changed the most like:
For now it just lists all changed files to the log message, similar to the
"commit" view. Is that ok, or do we really need the diffstat, It may be
a bit expensive to generate it for all the commits with every RSS request...
Thanks,
Kay
^ 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