* Re: [PATCH v3] contrib git-resurrect: find traces of a branch name and resurrect it
From: Junio C Hamano @ 2009-02-02 2:31 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Boyd Stephen Smith Jr.
In-Reply-To: <1233524085-25342-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
>> Reading everything down to the root commit sounds like fun. rev-list
>> gives you the output from newer to older so you may want to break out once
>> you have found enough candidates.
>>
>> Anyway, if I were doing this script, I'd write this part like this without
>> a shell loop:
>>
>> _x40="[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]"
>> _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
>>
>> git rev-list --all --grep="Merge branch '$1'" \
>> --pretty=tformat:"%H %P %s" |
>> sed -ne "s/^$_x40 $_x40 \($_x40\) Merge .*/\1/p"
>
> Nice trick. The same also works for scan_merge_targets() and gives it
> a nice speed boost too. Unfortunately my sed-fu is not good enough to
> figure out how to only print the first line (for resurrections from
> pu, we expect there to be a single match).
Do you mean something like this?
sed -n -e "/^$_x40 $_x40 \($_x40\) Merge .*/ {
s//\1/p
q
}"
^ permalink raw reply
* Re: Newbie question regarding 3way merge order.
From: Sitaram Chamarty @ 2009-02-02 1:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vskmyt127.fsf@gitster.siamese.dyndns.org>
On 2009-02-01, Junio C Hamano <gitster@pobox.com> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
>> Reversing A and B is one thing, applying a sequence of
>> merges in a different order is quite something else.
>
> This point is true in theory but I haven't found it to cause problems in
> practice. Textual conflicts between topics do happen, but it does not
> happen so often in overlapping areas across more than two topics that
> earlier resolutions to them cannot be reused by the rerere mechanism.
[snip]
> to force a merge order to the mainline can be used not only to deal with
> semantic conflicts but textual ones, too. If two branches textually
> interact badly, you prepare a consolidated topic between the two, so that
> you can merge A alone, B alone, or A+B together to the mainline.
>
> If you end up merging A first and then want to merge B later (or the other
> way around, merge B and then A), and if the second merge to the mainline
> causes huge textual conflicts, you can instead merge the conslidated topic
> A+B to the mainline.
Thanks; great explanation. I notice you blogged it too, and
similar to the "Never merging back" post, the message is: if
something is (or is likely to be) an independent feature, it
should have its own branch and be merged into others as soon
as it is known they need it. (In that post, it was a random
crazy feature that one might normally dump into a customer
branch, here it's a bugfix B that you might naively dump
into feature A, but the basic logic is the same)
^ permalink raw reply
* Re: How let git think UTF-16 file as text file
From: Pieter de Bie @ 2009-02-02 0:50 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660902011643h379e41f1nd2f2c5f7b8d729f3@mail.gmail.com>
On 2 feb 2009, at 00:43, Frank Li wrote:
> VS project resource file and resource header file use UTF-16 as
> unicode.
> Default git think it is binary file.
> How to let git think it is text file.
Perhaps something like
*vs diff crlf
in your .gitattributes file?
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Tuncer Ayaz @ 2009-02-02 0:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsc9rae9.fsf@gitster.siamese.dyndns.org>
On Mon, Feb 2, 2009 at 12:43 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
>
>> On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>>> Junio C Hamano <gitster@pobox.com> wrote:
>>>> Thomas Rast <trast@student.ethz.ch> writes:
>>>>
>>>> > + if test ! -z "$GIT_PS1_EXPENSIVE"; then
>>>> > + git update-index --refresh >/dev/null 2>&1 || w="*"
>>>>
>>>> This makes the feature unavailable for people who care about the stat
>>>> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?
>>>
>>> Yup, and I'm one of those people who sets autorefresindex to false
>>> in my ~/.gitconfig, usually before I even have user.{name,email} set.
>>>
>>> I do like the idea of what Thomas is trying to do here, but its
>>> so bloody expensive to compute dirty state on every prompt in
>>> some repositories that I'd shoot myself. E.g. WebKit is huge,
>>
>> I've been thinking about this and wondered
>> whether implementing "status --mini" or
>> "status --short" which prints "+?*" in wt-status.c
>> could be made fast enough.
>>
>> Should we try to implement and profile this
>> or do we know it will be slow beforehand?
>
> I think I've seen a patch to do something like that, soon after Shawn
> announced his repo tool.
The best I could find is your patch from October 25th 2008
which implements:
$ ./git-shortstatus
M Makefile
R100 COPYING -> RENAMING
M builtin-commit.c
M builtin-revert.c
M builtin.h
M git.c
M wt-status.c
M wt-status.h
Is this what you meant?
^ permalink raw reply
* Re: [PATCH,v2] git-bundle(1): add no references required simplest case
From: Junio C Hamano @ 2009-02-02 0:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: jidanni, gitster, mdl123, spearce, git
In-Reply-To: <alpine.DEB.1.00.0902020056520.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> +A complete bundle is one that does not require you to have any
>
> I have not heard of any "complete" bundle before, and I do not understand
> the need for such a definition, either.
Sorry, that's mine, not Jidanni's fault. I agree that we do not
necessarily have to introduce a new term.
>> +as if it was a remote repository, like this:
>> +
>> +----------------
>> +$ git clone /home/me/tmp/file.bdl mine.git
>> +----------------
>> +
>> +This will define a remote called "origin" in the resulting
>> +repository that lets you fetch and pull from the bundle, just
>> +like the previous example lets you do with the remote called
>> +"bundle", and from then on you can fetch/pull to update the
>> +resulting mine.git repository after replacing the bundle you store
>> +at /home/me/tmp/file.bdl with incremental updates.
>
> IMO this paragraph just adds words, not anything the user does not know
> already by that stage.
True again.
The only justification that an example of cloning from a complete (or
"baseless" or "full" or whatever new term we have already agreed that is
not needed ;-)) bundle in the example I can think of is that by having
such an example way earlier in the example sequence, we could show a full
cycle of sneakernetting into a repository. You bootstrap it by cloning
from a complete bundle, so that the clone has remotes set up to facilitate
further updates via fetch/pull pointing at a known location. Then you
drop a new bundle to the same location that is relative to an earlier one,
and pull from it to incrementally keep the repository up-to-date.
In other words, we currently have a very cursory description that says you
can ls-remote and fetch from a bundle at the end, and mention that the
remote configuration can be defined to facilitate repeated sneakernet
operation. But we could reorganize the example this way (the ones with
asterisk are already in our example section, the ones with plus are
additions):
* you first create a full bundle without basis
$ git bundle create mybundle master
* you make note of the current tip to optimize later bundles
$ git tag -f lastR2bundle master
+ sneakernet it and clone it to prime the recipient
... sneakernet mybundle to /home/me/tmp/mybundle
$ git clone /home/me/tmp/mybundle mine.git
+ after working more in the original, create an incremental bundle
$ git bundle create mybundle lastR2bundle..master
$ git tag -f lastR2bundle master
+ sneakernet it again, and use it to update the recipient
... sneakernet the new mybundle to /home/me/tmp/mybundle
$ git pull /home/me/tmp/mybundle mine.git
to show the simplest "full cycle" of sneakernet workflow. And then show
various variations we already have in the existing examples.
Something like:
In addition, if you know up to what commit the intended recipient
repository should have the necessary objects for, you can use that
knowledge to specify the basis, giving a cut-off point to limit the
revisions and objects that go in to the resulting bundle. Here are the
examples:
* using a tag present in both to optimize the bundle
$ git bundle create mybundle master ^v1.0.0
* using a basis based on time to optimize the bundle
$ git bundle create mybundle master --since=10.days
* using the number of commits to optimize the bundle
$ git bundle create mybundle master -n 10
A bundle from a recipient repository's point of view is just like a
regular repository it fetches/pulls from. You can for example map
refs, like this example, when fetching.
$ git fetch mybundle master:localRef
Or see what refs it offers
$ git ls-remote mybundle
^ permalink raw reply
* How let git think UTF-16 file as text file
From: Frank Li @ 2009-02-02 0:43 UTC (permalink / raw)
To: git
VS project resource file and resource header file use UTF-16 as unicode.
Default git think it is binary file.
How to let git think it is text file.
^ permalink raw reply
* Re: [PATCH,v2] git-bundle(1): add no references required simplest case
From: Johannes Schindelin @ 2009-02-02 0:04 UTC (permalink / raw)
To: jidanni; +Cc: gitster, mdl123, spearce, git
In-Reply-To: <87pri12078.fsf@jidanni.org>
Hi,
On Mon, 2 Feb 2009, jidanni@jidanni.org wrote:
> Words totally by Junio C Hamano.
> Signed-off-by: jidanni <jidanni@jidanni.org>
> ---
>
> Junio: I used your words.
> You might have missed this patch. Resending.
You are not serious, are you? People have explained time and time again
what is required by a commit message.
Now, I am not a native speaker, but the commit subject seems to contain
grammatical errors. Even if it weren't, it is not understandable.
So the only thing that is in your complete commit message remotely
purporting to explain what the patch is about and why it is good, fails to
do so.
Also, we always have an empty line before SOB lines.
> +A complete bundle is one that does not require you to have any
I have not heard of any "complete" bundle before, and I do not understand
the need for such a definition, either.
> +prerequisite object for you to extract its contents. Not only you
> +can fetch/pull from a bundle, you can clone from a complete bundle
"Not only you can" violates grammar in my book.
> +as if it was a remote repository, like this:
> +
> +----------------
> +$ git clone /home/me/tmp/file.bdl mine.git
> +----------------
> +
> +This will define a remote called "origin" in the resulting
> +repository that lets you fetch and pull from the bundle, just
> +like the previous example lets you do with the remote called
> +"bundle", and from then on you can fetch/pull to update the
> +resulting mine.git repository after replacing the bundle you store
> +at /home/me/tmp/file.bdl with incremental updates.
IMO this paragraph just adds words, not anything the user does not know
already by that stage.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Junio C Hamano @ 2009-02-01 23:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nanako Shiraishi, Jay Soffian, git, gitster
In-Reply-To: <alpine.DEB.1.00.0902012349360.3586@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> at the cost of annoying
>
> - a few oldtimers
> - now, instead of later
Nobody seems to have realized this, but suddenly changing the default to
refuse without giving people enough advance warning to adjust will hurt
not just the old-timers (a rough definition is people who are from the
kernel circle and have been using git since summer of 2005), but people
who picked up a recipe from various how-to web pages to push to a live
repository and updating the checkout that is otherwise never touched by
the humans with its post-update hook running "reset --hard". Old timers
may be savvy enough to know what has changed and may be able to grudgingly
react, but what is your plans for these recipe following kids?
How many times do I have to repeat that it is much worse to break a
working setup of people without advance warning and sound transition
guidance than having a known breakage that users can be trained to avoid?
And realize that I am not saying we need to keep the known breakage
forever.
The only thing I am saying is that you need to have a smooth transition
plan for changing the default, and a mechanism to guide people in place.
I'll ignore you if you keep repeating "all it takes is for old timers to
flip a switch". Such an argument shows that you didn't learn a thing
after the 1.6.0 fallout.
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Junio C Hamano @ 2009-02-01 23:43 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: Shawn O. Pearce, Thomas Rast, git
In-Reply-To: <4ac8254d0902011448t242e7fcek3ae7fda609648ef0@mail.gmail.com>
Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
> On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
>> Junio C Hamano <gitster@pobox.com> wrote:
>>> Thomas Rast <trast@student.ethz.ch> writes:
>>>
>>> > + if test ! -z "$GIT_PS1_EXPENSIVE"; then
>>> > + git update-index --refresh >/dev/null 2>&1 || w="*"
>>>
>>> This makes the feature unavailable for people who care about the stat
>>> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?
>>
>> Yup, and I'm one of those people who sets autorefresindex to false
>> in my ~/.gitconfig, usually before I even have user.{name,email} set.
>>
>> I do like the idea of what Thomas is trying to do here, but its
>> so bloody expensive to compute dirty state on every prompt in
>> some repositories that I'd shoot myself. E.g. WebKit is huge,
>
> I've been thinking about this and wondered
> whether implementing "status --mini" or
> "status --short" which prints "+?*" in wt-status.c
> could be made fast enough.
>
> Should we try to implement and profile this
> or do we know it will be slow beforehand?
I think I've seen a patch to do something like that, soon after Shawn
announced his repo tool.
^ permalink raw reply
* Re: [PATCH,v2] git-bundle(1): add no references required simplest case
From: jidanni @ 2009-02-01 23:42 UTC (permalink / raw)
To: gitster; +Cc: mdl123, spearce, git
In-Reply-To: <87tz7i6scg.fsf_-_@jidanni.org>
Words totally by Junio C Hamano.
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Junio: I used your words.
You might have missed this patch. Resending.
Documentation/git-bundle.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-bundle.txt b/Documentation/git-bundle.txt
index 1b66ab7..42c2abc 100644
--- a/Documentation/git-bundle.txt
+++ b/Documentation/git-bundle.txt
@@ -164,6 +164,22 @@ $ git pull bundle
would treat it as if it is talking with a remote side over the
network.
+A complete bundle is one that does not require you to have any
+prerequisite object for you to extract its contents. Not only you
+can fetch/pull from a bundle, you can clone from a complete bundle
+as if it was a remote repository, like this:
+
+----------------
+$ git clone /home/me/tmp/file.bdl mine.git
+----------------
+
+This will define a remote called "origin" in the resulting
+repository that lets you fetch and pull from the bundle, just
+like the previous example lets you do with the remote called
+"bundle", and from then on you can fetch/pull to update the
+resulting mine.git repository after replacing the bundle you store
+at /home/me/tmp/file.bdl with incremental updates.
+
Author
------
Written by Mark Levedahl <mdl123@verizon.net>
--
1.6.0.6
^ permalink raw reply related
* Re: git monthly links: 2009-01
From: Johannes Schindelin @ 2009-02-01 23:26 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Felipe Contreras, git list
In-Reply-To: <bd6139dc0902011050m585e4710mf9de95a04b36c135@mail.gmail.com>
Hi,
On Sun, 1 Feb 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Sun, Feb 1, 2009 at 18:01, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > Tracking an entire Windows system inside Git
> > Avery Pennarun explains his endeavor of tracking windows with git...
> > "If I get a virus, I can 'git revert' it."
> > http://alumnit.ca/~apenwarr/log/?m=200901#21
>
> Omg, this is so totally insane that I've been laughing the entire time
> while reading the post, and then for a minute after that :P. Johannes,
> I think we have a new contender for the UGFWIINI contest.
Indeed. It even beats the way we use Git to track the MSys installation
in msysgit.git...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Johannes Schindelin @ 2009-02-01 22:59 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Jay Soffian, git, gitster
In-Reply-To: <20090131095622.6117@nanako3.lavabit.com>
Hi,
On Sat, 31 Jan 2009, Nanako Shiraishi wrote:
> Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > You cannot just cater for one workflow and fsck the other workflows
> > over.
> >
> > You'll have to devise a method that helps the workflow you are
> > interested in, but leaves the others alone.
>
> I think you'd want to repeat that to yourself when you propose to switch
> the default for denyCurrentcurrentBranch config to "true" too hastily
> the next time?
Nanako, what exactly do you think I did before writing these lines:
Granted, we wanted to have a longer grace period for old-timers, but
let's face it:
[... a discussion on the pros and cons ...]
? Do you think I did that just on a whim, or do you rather assume that I
thought long and hard about it?
> I don't think your patch matches the tradition of how defaults are
> changed in git project. You don't introduce a large change just after
> the maintainer hints about going into a freeze for 1.X.Y release when Y
> isn't zero.
Indeed. That is why I wrote "Granted, we wanted to have a longer grace
period"!
> I assume that everybody, including the maintainer who is too heavyweight
I saw Junio. He is in no way heavyweight. He is actually rather skinny.
> and has too much inertia to accept too sudden a change of the course,
> wants to eventually make the default to deny pushing to the current
> branch. But I think such a change should come at 1.7.0 release at the
> earliest, and a constructive thing to do is to put in a patch to 1.6.2
> that helps the users with the eventual transition.
So what do you want to achieve? Annoy me? Annoy Git newbies? Annoy Git
oldtimers?
Eventually, it will boil down to
- who
- when
to annoy.
And I have a strong suspicion that it does not help the reputation of Git
at all, if we annoy
- new Git users
- for a long time
Rather, I'd like to annoy only
- a few oldtimers who should know better by now
- just once, when they upgrade to a new minor release and see that they
forgot to mark their repository as "bare".
If you would think about it as long and hard as I did, you would see that
we have to annoy
- a few oldtimers
- at some stage
anyway, but in the meantime, we could avoid to annoy
- a lot of new Git users
- for a long time
at the cost of annoying
- a few oldtimers
- now, instead of later
which cost will come to
- us
- anyway
Frankly, I am surprised that people do not agree with me on this point.
> What do people think?
Seriously, when it comes to the Git users I interact with, they think
"what the bl**dy fsck did the Git people smoke when they made it _so_ hard
on new Git users, I am certainly not the only person bitten by
this."
I know, because they let me in on their thoughts, but are too shy to
mention them here on the Git list.
And as everybody knows, I am a nice guy, and I listen.
Ciao,
Dscho
^ permalink raw reply
* Re: Linus and whitespace
From: Linus Torvalds @ 2009-02-01 22:56 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <87fxix3hub.fsf@jidanni.org>
On Mon, 2 Feb 2009, jidanni@jidanni.org wrote:
>
> Gentlemen, I couldn't help but notice a certain Linus B. Torvalds is
> producing mail with trailing whitespace.
alpine does it when word-wrapping my messages.
But I don't word-wrap my _patches_. Those I just insert, and alpine gets
it right.
Linus
^ permalink raw reply
* Re: Linus and whitespace
From: A Large Angry SCM @ 2009-02-01 22:48 UTC (permalink / raw)
To: jidanni; +Cc: torvalds, git
In-Reply-To: <87fxix3hub.fsf@jidanni.org>
jidanni@jidanni.org wrote:
> Gentlemen, I couldn't help but notice a certain Linus B. Torvalds is
> producing mail with trailing whitespace.
>
> I recall one should (linux-doc-*/Documentation/CodingStyle*:)
> "Get a decent editor and don't leave whitespace at the end of lines."
>
> Indeed, with my GNU Emacs show-trailing-whitespace X-ray
> eyespecs on all day, whitespace becomes screaming purple space, so you
> can't blame me for noticing.
>
> Anyway, I have analyzed his messages,
> (User-Agent: Alpine 2.00 (LFD 1167 2008-08-23))
> and discovered that the whitespace phenomenon almost always occurs if
> the lines are more than 60 characters long, the "danger zone", we might say.
>
> $ perl -nwle 'print length if / $/' recent_linus_postings|
> sort|uniq -c|sort -k 2nr
> 1 77
> 1 76
> 17 75
> 17 74
> 11 73
> 18 72
> 12 71
> 6 70
> 8 69
> 6 68
> 2 67
> 1 66
> 2 64
> 1 63
> 1 40
> 9 2
CodingStyle applies to *patches* not to discussion. In how many of those
emails you analyzed were there any trailing whitespace in a patch?
^ permalink raw reply
* Re: [PATCH] bash: offer to show (un)staged changes
From: Tuncer Ayaz @ 2009-02-01 22:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20090119172939.GA14053@spearce.org>
On Mon, Jan 19, 2009 at 6:29 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>> Thomas Rast <trast@student.ethz.ch> writes:
>>
>> > + if test ! -z "$GIT_PS1_EXPENSIVE"; then
>> > + git update-index --refresh >/dev/null 2>&1 || w="*"
>>
>> This makes the feature unavailable for people who care about the stat
>> dirtiness and explicitly set diff.autorefreshindex to false, doesn't it?
>
> Yup, and I'm one of those people who sets autorefresindex to false
> in my ~/.gitconfig, usually before I even have user.{name,email} set.
>
> I do like the idea of what Thomas is trying to do here, but its
> so bloody expensive to compute dirty state on every prompt in
> some repositories that I'd shoot myself. E.g. WebKit is huge,
I've been thinking about this and wondered
whether implementing "status --mini" or
"status --short" which prints "+?*" in wt-status.c
could be made fast enough.
Should we try to implement and profile this
or do we know it will be slow beforehand?
I am actually using this feature on the bash
prompt via calls to git commands and parsing
for added=+, unknown=? and changed=* as
others have done in combination with __git_ps1.
> computing the dirty state inside of the WebKit repository on each
> prompt would absolutely kill CLI performance to a point of it not
> being usuable. But git.git is small enough its OK on pretty much
> everything except Cygwin.
>
> So as much as I'd like to use this without the update-index --refresh
> bit, I'm not sure its viable in every project out there. If we had
> an inotify sort of daemon to keep the data current so the prompt
> doesn't have to stat every source file on every display it would
> be reasonable, but we don't have such a thing yet for Git.
>
> --
> Shawn.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Bus Error- git merge
From: Johannes Schindelin @ 2009-02-01 22:48 UTC (permalink / raw)
To: Brian Moran; +Cc: git@vger.kernel.org
In-Reply-To: <C5A8D5E0.E29D%bmoran@onehub.com>
Hi,
On Fri, 30 Jan 2009, Brian Moran wrote:
> With subsequent changes to the merged-to repository, the bug does not
> manifest. I will attempt to reproduce when we encounter it next.
Please do not top-post; it is annoying. If that is not good enough a
reason for you to avoid it: it is also against the customs in this list.
Second, it is a pity that you did not work with me to resolve the issue.
I would have liked to squash this bug very much, but your unwillingness to
work with me on the bug does not make me enthusiastic about trying to help
you in the future. As it is, my time writing the mails to you seems to
have been wasted.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] http-push: refactor request url creation
From: Johannes Schindelin @ 2009-02-01 22:45 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Junio C Hamano
In-Reply-To: <4983929B.2010901@gmail.com>
Hi,
On Sat, 31 Jan 2009, Tay Ray Chuan wrote:
> * split "append_remote_object_url" signature across 3 lines at Dscho's suggestion
This line is longer than 80 characters (and I seem to remember that the
recommended maximum for emails is even less than that).
>
> http-push.c | 62 +++++++++++++++++++++++-----------------------------------
> 1 files changed, 25 insertions(+), 37 deletions(-)
>
> diff --git a/http-push.c b/http-push.c
> index 59037df..ba217fc 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -209,6 +209,22 @@ static struct curl_slist *get_dav_token_headers(struct remote_lock *lock, enum d
> return dav_headers;
> }
>
> +static void append_remote_object_url(struct strbuf *buf, const char *url,
> + const char *hex,
> + int only_two_digit_prefix)
> +{
Fine. You changed that, although I find the indentation rather funny,
too. I would have expected one tab and then the rest of the signature.
> + strbuf_addf(buf, "%sobjects/%.*s/", url, 2, hex);
> + if (!only_two_digit_prefix)
> + strbuf_addf(buf, "%s", hex+2);
> +}
> +
> +static char *get_remote_object_url(const char *url, const char *hex, int only_two_digit_prefix)
But this is still too long. And no, I will not go through your patch and
point out every too-long line; I'll expect you to do that yourself...
Ciao,
Dscho
^ permalink raw reply
* Re: [EGIT PATCH] Resurrect group filtering options in history pane
From: Shawn O. Pearce @ 2009-02-01 22:39 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <1233520578-10453-1-git-send-email-robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> This commit restores the ability to filter on not only the selected
> resource but instead all changes in the same folder, same project
> or same repository. The filtering levels supported are Resource (no button
> pessed), Folder, Project and Repository. Only the highest level has any
> effect. The flags are persistent between eclipse sessions in the same
> workspace.
Shouldn't these filtering flag buttons be exclusive buttons,
in the sense that only one can be depressed at a time, or none
are depressed?
I managed to depress R,P,F by doing it in the opposite order (push
F, then P, then R) and I have no clue what that should really mean
when looking at the history.
Also, the R/P/F labels are a bit too similar. I know its what we
had before, but these are blending too much to me visually and I
keep reading the F as though it were a misdrawn R or P, like the
box isn't big enough for it. Which actually has me thinking that
with the proportional width font on my workbench the F is using a
narrower button box than the R or P, which looks funny.
> diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/GitHistoryPage.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/GitHistoryPage.java
> index d718cd7..4e95df4 100644
> --- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/GitHistoryPage.java
> +++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/history/GitHistoryPage.java
> @@ -96,7 +96,7 @@
>
> /**
> * Determine if the input can be shown in this viewer.
> - *
> + *
> * @param object
> * an object that is hopefully of type ResourceList or IResource,
> * but may be anything (including null).
Unnecessary re-formatting hunk. Please discard from the patch.
--
Shawn.
^ permalink raw reply
* Linus and whitespace
From: jidanni @ 2009-02-01 22:36 UTC (permalink / raw)
To: torvalds; +Cc: git
Gentlemen, I couldn't help but notice a certain Linus B. Torvalds is
producing mail with trailing whitespace.
I recall one should (linux-doc-*/Documentation/CodingStyle*:)
"Get a decent editor and don't leave whitespace at the end of lines."
Indeed, with my GNU Emacs show-trailing-whitespace X-ray
eyespecs on all day, whitespace becomes screaming purple space, so you
can't blame me for noticing.
Anyway, I have analyzed his messages,
(User-Agent: Alpine 2.00 (LFD 1167 2008-08-23))
and discovered that the whitespace phenomenon almost always occurs if
the lines are more than 60 characters long, the "danger zone", we might say.
$ perl -nwle 'print length if / $/' recent_linus_postings|
sort|uniq -c|sort -k 2nr
1 77
1 76
17 75
17 74
11 73
18 72
12 71
6 70
8 69
6 68
2 67
1 66
2 64
1 63
1 40
9 2
^ permalink raw reply
* Re: [PATCH] builtin-blame.c: Use utf8_strwidth for author's names
From: Johannes Schindelin @ 2009-02-01 22:34 UTC (permalink / raw)
To: Geoffrey Thomas; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0901301710130.1984@vinegar-pot.mit.edu>
Hi,
On Fri, 30 Jan 2009, Geoffrey Thomas wrote:
> Currently, however, printf("%*.*s", width, width, author) is simply
> wrong, because printf only cares about bytes, not screen columns. Do you
> think I should fall back on the old behavior if i18n.commitencoding is
> set, or if at least one of the author names isn't parseable as UTF-8, or
> something? Or should I be doing this with iconv and assuming all commits
> are encoded in the current encoding specified via $LANG or $LC_whatever?
I do not know what encoding the author is at that point, but if you cannot
be sure that it is UTF-8, using utf8_strwidth() is just as wrong as the
current code, IMHO.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] bash: offer to show (un)staged changes
From: Shawn O. Pearce @ 2009-02-01 22:29 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1233526423-30694-1-git-send-email-trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> wrote:
> Add a bit of code to __git_ps1 that lets it append '*' to the branch
> name if there are any unstaged changes, and '+' if there are any
> staged changes.
>
> Since this is a rather expensive operation and will force a lot of
> data into the cache whenever you first enter a repository, you have to
> enable it manually by setting bash.showDirtyState to a true value.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
>
> This got no replies... was there anything wrong with v2?
Dropped on the floor by me. Sorry.
But I'm a bit worried about the config --bool test in the prompt.
Its a new fork+exec we weren't doing before. I wonder if we should
use a shell variable to consider whether or not this should even
be executed and try to shortcut out if not. E.g.:
if test -n "$GIT_PS1_SHOWDIRTYSTATE"; then
... your new code block ...
fi
and ask that users at some point set GIT_PS1_SHOWDIRTYSTATE=1 in
their shell startup scripts, and also set bash.showDirtyState true
in any of the repositories they care about it in.
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index f8b845a..7864ca7 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -34,6 +34,10 @@
> # are currently in a git repository. The %s token will be
> # the name of the current branch.
> #
> +# In addition, if you set bash.showDirtyState to a true value,
> +# unstaged (*) and staged (+) changes will be shown next to the
> +# branch name.
> +#
> # To submit patches:
> #
> # *) Read Documentation/SubmittingPatches
> @@ -116,10 +120,24 @@ __git_ps1 ()
> fi
> fi
>
> + local w
> + local i
> +
> + if test "$(git config --bool bash.showDirtyState)" = "true"; then
> + git diff --no-ext-diff --ignore-submodules \
> + --quiet --exit-code || w="*"
> + if git rev-parse --quiet --verify HEAD >/dev/null; then
> + git diff-index --cached --quiet \
> + --ignore-submodules HEAD -- || i="+"
> + else
> + i="#"
> + fi
> + fi
> +
> if [ -n "${1-}" ]; then
> - printf "$1" "${b##refs/heads/}$r"
> + printf "$1" "${b##refs/heads/}$w$i$r"
> else
> - printf " (%s)" "${b##refs/heads/}$r"
> + printf " (%s)" "${b##refs/heads/}$w$i$r"
> fi
> fi
> }
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] t3412: clean up GIT_EDITOR usage
From: Johannes Schindelin @ 2009-02-01 22:24 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <1233355621-4783-1-git-send-email-trast@student.ethz.ch>
Hi,
On Fri, 30 Jan 2009, Thomas Rast wrote:
> a6c7a27 (rebase -i: correctly remember --root flag across --continue,
> 2009-01-26) introduced a more portable GIT_EDITOR usage, but left the
> old tests unchanged.
>
> Since we never use the editor (all tests run the rebase script as
> proposed by rebase -i), just disable it outright, which simplifies the
> tests.
>
> Signed-off-by: Thomas Rast <trast@student.ethz.ch>
> ---
> t/t3412-rebase-root.sh | 38 +++++++++++++-------------------------
> 1 files changed, 13 insertions(+), 25 deletions(-)
>
> diff --git a/t/t3412-rebase-root.sh b/t/t3412-rebase-root.sh
> index 9fc528f..8a9154a 100755
> --- a/t/t3412-rebase-root.sh
> +++ b/t/t3412-rebase-root.sh
> @@ -6,6 +6,10 @@ Tests if git rebase --root --onto <newparent> can rebase the root commit.
> '
> . ./test-lib.sh
>
> +# we always run the interactive rebases unchanged, so just disable the editor
> +GIT_EDITOR=:
> +export GIT_EDITOR
> +
According to my analysis, this is unneeded. Just leave GIT_EDITOR alone
in the whole test.
Ciao,
Dscho
^ permalink raw reply
* [PATCH v2] bash: offer to show (un)staged changes
From: Thomas Rast @ 2009-02-01 22:13 UTC (permalink / raw)
To: git, Shawn O. Pearce; +Cc: Junio C Hamano
In-Reply-To: <1232401089-27512-1-git-send-email-trast@student.ethz.ch>
Add a bit of code to __git_ps1 that lets it append '*' to the branch
name if there are any unstaged changes, and '+' if there are any
staged changes.
Since this is a rather expensive operation and will force a lot of
data into the cache whenever you first enter a repository, you have to
enable it manually by setting bash.showDirtyState to a true value.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
This got no replies... was there anything wrong with v2?
contrib/completion/git-completion.bash | 22 ++++++++++++++++++++--
1 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index f8b845a..7864ca7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -34,6 +34,10 @@
# are currently in a git repository. The %s token will be
# the name of the current branch.
#
+# In addition, if you set bash.showDirtyState to a true value,
+# unstaged (*) and staged (+) changes will be shown next to the
+# branch name.
+#
# To submit patches:
#
# *) Read Documentation/SubmittingPatches
@@ -116,10 +120,24 @@ __git_ps1 ()
fi
fi
+ local w
+ local i
+
+ if test "$(git config --bool bash.showDirtyState)" = "true"; then
+ git diff --no-ext-diff --ignore-submodules \
+ --quiet --exit-code || w="*"
+ if git rev-parse --quiet --verify HEAD >/dev/null; then
+ git diff-index --cached --quiet \
+ --ignore-submodules HEAD -- || i="+"
+ else
+ i="#"
+ fi
+ fi
+
if [ -n "${1-}" ]; then
- printf "$1" "${b##refs/heads/}$r"
+ printf "$1" "${b##refs/heads/}$w$i$r"
else
- printf " (%s)" "${b##refs/heads/}$r"
+ printf " (%s)" "${b##refs/heads/}$w$i$r"
fi
fi
}
--
tg: (7bbd8d6..) t/ps1-dirty-state (depends on: origin/master)
^ permalink raw reply related
* Git setup for kernel in-house development + mainstream submissions?
From: PaV @ 2009-02-01 21:25 UTC (permalink / raw)
To: git
Hello,
I would like to kindly ask for suggestions how to setup and use git in a
company that performs in-house kernel development (drivers mostly) for
its own devices and would like to occasionaly submit patches for mainstream.
I've come up with a short list of use cases/requirements (possibly not
exhaustive, any suggestions here as well please?):
1) a way to separate development of in-house code (various drivers)
2) a place to merge everything done in-house and provide current
development snapshot for internal use
3) something that tracks the current mainstream tree, to be merged with
(3) ocassionaly (or (2)?)
4) a simple way to select changes (which may be as small as only parts
of any of the drivers), format them and submit for upstream merge.
Preferably, if possible, prepare those series of patches and store them
for later use (immediate submission might not be possible and might not
be done at all).
5) (more?)
So the proposed setup might be:
(1) - in-house devel could be done on separate branches for each driver
(2) - a master branch (on the main server) for in-house snapshots and
distribution
(3) - a separate tracking branch for mainstream
(4) - now this is hard.
The main problems are how to create, how to diff and how to manage those
patches (stgit?) and what to do when mainstream gets updated, etc...
So ideas are: rebase and/or stgit/quilt. Or/and maybe topic branches,
creating new branches for each new kernel version for each driver,
copying the old branch and rebasing?
This is the most important part for which I'd like to ask for suggestions...
Any other suggestions are of course also welcome, my experience in git
is small and I might have missed things.
Thank you!
Paul
^ permalink raw reply
* [PATCH 4/3] gitweb: Update README that gitweb works better with PATH_INFO
From: Jakub Narebski @ 2009-02-01 21:37 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano, bug-CGI.pm
In-Reply-To: <1233365512-7130-4-git-send-email-giuseppe.bilotta@gmail.com>
One had to configure gitweb for it to find static files (stylesheets,
images) when using path_info URLs. Now that it is not necessary
thanks to adding BASE element to HTML head if needed, update README to
reflect this fact.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is update of gitweb/README to fit state after Giuseppe patches.
There is a little problem either with terminology, or with CGI.pm
module itself. RFC 1808 "Relative Uniform Resource Locators" says
that:
http://git.example.com/cgi-bin/gitweb.cgi is absolute URL
/cgi-bin/gitweb.cgi is relative URL
but absolute path
gitweb.cgi is relative URL
and relative path
while CGI.pm (or, to be more exact, its url() method) says:
url() or url(-full) returns http://git.example.com/cgi-bin/gitweb.cgi
url(-absolute) returns /cgi-bin/gitweb.cgi
url(-relative) returns gitweb.cgi (or /cgi-bin/gitweb.cgi)
That is why I used "Full URL" for $my_url = $cgi->url();
and "absolute URL" (as before) for $my_uri = $cgi->url(-absolute);
in gitweb/README.
gitweb/README | 10 ++++------
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 52ad88b..a9dc2e5 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -162,14 +162,12 @@ not include variables usually directly set during build):
$GITWEB_LIST during installation. If empty, $projectroot is used
to scan for repositories.
* $my_url, $my_uri
- URL and absolute URL of gitweb script; you might need to set those
- variables if you are using 'pathinfo' feature: see also below.
+ Full URL and absolute URL of gitweb script;
+ in earlier versions of gitweb you might have need to set those
+ variables, now there should be no need to do it.
* $home_link
Target of the home link on top of all pages (the first part of view
- "breadcrumbs"). By default set to absolute URI of a page; you might
- need to set it up to [base] gitweb URI if you use 'pathinfo' feature
- (alternative format of the URLs, with project name embedded directly
- in the path part of URL).
+ "breadcrumbs"). By default set to absolute URI of a page ($my_uri).
* @stylesheets
List of URIs of stylesheets (relative to base URI of a page). You
might specify more than one stylesheet, for example use gitweb.css
--
1.6.1
^ permalink raw reply related
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