* Re: git-format-patch little gripe
From: Luben Tuikov @ 2006-11-03 9:59 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90611030122reecee87ufac5bbaa910ee933@mail.gmail.com>
--- Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 11/3/06, Luben Tuikov <ltuikov@yahoo.com> wrote:
> > Yep, after more than a year, I simply cannot get used to it...
> > http://marc.theaimsgroup.com/?l=git&m=113259043217761&w=2
> > And as I've seen, other people brought that up too.
>
> Hi Luben,
>
> reading the thread, it sounds like you have a couple of shells scripts
> or aliases that do what you want already ;-)
Yeah, would you know it those scripts got lost somewhere. I now
know better -- branch off of git "next" and store in USB key. :-)
So I generally work off of "next" merged to my own branch which includes
extras I've collected along the way.
But what wouldn't I give to have
git-format-_patch_ -o /tmp/ <commit>
generate a _single_ patch just as its name implies...
Luben
^ permalink raw reply
* Re: git bug? + question
From: Martin Waitz @ 2006-11-03 9:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, Miles Bader, git
In-Reply-To: <7v3b90gbfv.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1017 bytes --]
hoi :)
On Fri, Nov 03, 2006 at 12:51:32AM -0800, Junio C Hamano wrote:
> With separate remotes, I'd need something like:
>
> for b in master maint next pu
> do
> git checkout $b && git pull && make || break
> done
>
> And I also would need to have per-branch configuration to merge
> from ". remotes/origin/$b" without re-fetching while on a
> non-master branch $b, for the above to work. I still need to
> remember to process "master" first, so all things considered,
> this is a regression in usability for my workflow.
you could also run git-fetch first and then always default to
the local repository. But that would of course make pull just
a shortcut for merge, without any fetch.
Would it be so bad for you to call fetch three times?
I think the most intuitive thing for pull would be to fetch into
remotes/<remotename>/* and then to merge
remotes/<remotename>/<currentbranch>.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-03 9:58 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0611030139i7be9569bh4a29596a768e82a3@mail.gmail.com>
On 2006-11-03 09:39:57 +0000, Catalin Marinas wrote:
> On 02/11/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > That Gnus shows =20 suggests that I haven't got the QP encoding
> > 100% right. I haven't had time to look at that yet, and it looks
> > like you may beat me to it.
>
> Well, it might be just the way I read the list (via the gmane news
> gateway) but I have to run some tests.
I believe all the mails I send with mutt are QP-encoded, and they
don't look funny, do they? (You'd see the separator just above my
signature as "--=20" if that was the case; it has a trailing
whitespace.)
> However, I'd like the message body to still be 8bit and the QP
> encoding optional (either command line option or [stgit] config
> variable).
Are you sure? Wouldn't it be better to teach StGIT to eat QP-encoded
mails, and use 7bit encoding when the patch is all ascii? (And still
have an option to force 8bit instead of QP if desired, of course.)
I'm really not comfortable with assuming all mail servers are 8-bit
clean, when they're evidently not. :-)
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: git bug? + question
From: Karl Hasselström @ 2006-11-03 9:51 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <20061103042540.192bbd18.seanlkml@sympatico.ca>
On 2006-11-03 04:25:40 -0500, Sean wrote:
> Yeah.. Although fetching multiple remotes makes more sense as an
> optimization, especially when using a separate remotes namespace.
That's what "git fetch" is for. :-)
> Perhaps the real confusion is created because the only porcelain
> level merge command current in Git is "git pull .". A separate name
> might make things easier to grasp.
Indeed. Having pull = fetch + merge and not having a porcelain merge
command is not good, usability-wise. As is, one _has_ to learn the
weird ways of pull even if one is only interested in using separate
commands to fetch and merge.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: git bug? + question
From: Karl Hasselström @ 2006-11-03 9:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, git
In-Reply-To: <7v3b90gbfv.fsf@assigned-by-dhcp.cox.net>
On 2006-11-03 00:51:32 -0800, Junio C Hamano wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:
> >
> > > I still need to remember to process "master" first, so all
> > > things considered, this is a regression in usability for my
> > > workflow.
> >
> > Where does this constraint come from?
>
> Because I'll have to have the per-branch configuration that would
> say something like this:
>
> [remote."gitster"]
> url = gitster.example.com:/home/junio/git.git/
> fetch = heads/maint:remotes/gitster/maint
> fetch = heads/master:remotes/gitster/master
> fetch = heads/next:remotes/gitster/next
> fetch = +heads/pu:remotes/gitster/pu
>
> [branch."master"]
> remote = gitster
> merge = heads/master
> [branch."maint"]
> remote = .
> merge = remotes/gitster/maint
> [branch."next"]
> remote = .
> merge = remotes/gitster/next
> ...
>
> This requires that by the time we update maint, next and pu branches
> with what is in the upstream, their corresponding remotes/gitster/*
> branches are already up-to-date and do not have to be re-fetched,
> and processing master first is what guarantees it.
Ahh, here is where our workflows differ: I would want to have "remote
= ." for all the branches, and use "git fetch" to update the remotes.
(I guess this is only natural; my workflow requires less state in the
head of the user, and so is easier for beginners, while yours is
slightly more efficient in terms of number of commands that have to be
given.)
Hmm. How about changing the meaning of "remote" slightly? Like this:
[remote."gitster"]
url = gitster.example.com:/home/junio/git.git/
fetch = heads/master:remotes/gitster/master
fetch = heads/next:remotes/gitster/next
[branch."master"]
remote = gitster
merge = remotes/gitster/master
[branch."next"]
remote = gitster
merge = remotes/gitster/next
This would mean: When the user says "git pull" in master, use the
remote gitster to fetch updates to remotes/gitster/master, then merge
remotes/gitster/master into master.
With this scheme, "git pull" would never fetch any other branches than
those about to be merged; to fetch more in one go, use "git fetch".
I realize this would break existing configs quite badly, so don't take
it too seriously.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Catalin Marinas @ 2006-11-03 9:39 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20061102113631.GA30507@diana.vm.bytemark.co.uk>
On 02/11/06, Karl Hasselström <kha@treskal.com> wrote:
> That Gnus shows =20 suggests that I haven't got the QP encoding 100%
> right. I haven't had time to look at that yet, and it looks like you
> may beat me to it.
Well, it might be just the way I read the list (via the gmane news
gateway) but I have to run some tests. However, I'd like the message
body to still be 8bit and the QP encoding optional (either command
line option or [stgit] config variable).
--
^ permalink raw reply
* Re: [PATCH 4/n] gitweb: Secure against commit-ish/tree-ish with the same name as path
From: Junio C Hamano @ 2006-11-03 9:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <7vhcxhjbog.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I'd see if I can add some constructive comments on patches 5-10
> tonight, but I'm in the middle of other things so don't hold
> your breath ;-).
7 and 9 look obviously good, so I've applied them without
others.
gitweb: Output also empty patches in "commitdiff" view
gitweb: Better support for non-CSS aware web browsers
5 is terminally linewrapped and rather big to comment on without
comparing pre- and post- patch outputs, so I'll refrain from
commenting on it. 8 is "oops, I made a mistake when I did 5",
which discourages me even more from looking at 5 X-<.
^ permalink raw reply
* Re: [PATCH 6/6] remove .keep pack lock files when done with refs update
From: Junio C Hamano @ 2006-11-03 9:35 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611021218510.11384@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Thu, 2 Nov 2006, Nicolas Pitre wrote:
>
>> Another area of that patch I'm not really sure of is this:
>>
>> @@ -408,6 +415,7 @@ fetch_main () {
>> append_fetch_head "$sha1" "$remote" \
>> "$remote_name" "$remote_nick" "$local_name" "$not_for_merge"
>> done
>> + if [ "$pack_lockfile" ]; then rm -f "$pack_lockfile"; fi
>> ) || exit ;;
>> esac
>>
>> How can I make sure to not clobber a non-zero return code with the rm
>> that would prevent the exit while still performing the rm in all cases?
>
> OK looking at it again I think the || exit is only meant to match the
> exit 1 before that point. Since this is a subshell then the exit 1
> wouldn't exit it all on its own. Otherwise there is no errors expected
> to trickle out of the while loop and I _think_ the above is correct.
I think so too.
> Do you still want a new patch for the micronit quoting issue?
Not needed, will park them in "pu" and play with them --
hopefully in "next" by the end of the week.
Thanks.
^ permalink raw reply
* Re: git bug? + question
From: Sean @ 2006-11-03 9:25 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <20061103081232.GB15972@diana.vm.bytemark.co.uk>
On Fri, 3 Nov 2006 09:12:32 +0100
Karl Hasselström <kha@treskal.com> wrote:
> I would rather see the default pull source of a branch being
> determined by which branch it was branched off of. But this should
> mean the same thing in this case. We'd just have to have the heuristic
> that default pulls from a remotes/*/* branch causes a fetch, while a
> default pull from a local branch does not.
Well, when you create a branch a branch.<branch>.merge entry could be
automatically made so that a merge from the proper place happens.
But in the absence of any config merge entries, it would be nice to
default to the same branch name from the remote namespace. This
removes the need to create merge entries for the initial clone.
Of course, currently you have to create branch.<branch>.merge
entries by hand.
> > On a peripherally related topic, someone on the xorg list was
> > complaining that after the initial clone, there is no easy way to
> > track branches that get added/deleted from the remote repo. It would
> > be nice if pull had an option to automatically add and remove remote
> > branches from the remotes/<remote>/xxx namespace.
>
> That would definitely be useful. But I want it in fetch, not pull. :-)
> Well, I suppose it could be in both.
Yes.
> Hmm, I think my dislike of remote pulls can be summed up as: I find it
> convoluted to have a command that will fetch multiple remote branches,
> then merge just one of them into my current branch. (I have no problem
> with pull when the branches to pull are specified explicitly, since in
> that case they are all merged.) With explicitly specified default pull
> sources it would get better, since then I would know that the correct
> branch would be merged, but I still don't quite like it.
Yeah.. Although fetching multiple remotes makes more sense as an
optimization, especially when using a separate remotes namespace.
Perhaps the real confusion is created because the only porcelain
level merge command current in Git is "git pull .". A separate
name might make things easier to grasp.
Sean
^ permalink raw reply
* Re: git-format-patch little gripe
From: Martin Langhoff @ 2006-11-03 9:22 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <376237.14965.qm@web31805.mail.mud.yahoo.com>
On 11/3/06, Luben Tuikov <ltuikov@yahoo.com> wrote:
> Yep, after more than a year, I simply cannot get used to it...
> http://marc.theaimsgroup.com/?l=git&m=113259043217761&w=2
> And as I've seen, other people brought that up too.
Hi Luben,
reading the thread, it sounds like you have a couple of shells scripts
or aliases that do what you want already ;-)
And for the scenario you mention, where upstream has taken some of
your patches... git-format-patch automatically tries to skip those.
Works well for me at least (ducks).
^ permalink raw reply
* Re: git bug? + question
From: Andy Parkins @ 2006-11-03 9:09 UTC (permalink / raw)
To: git
In-Reply-To: <7v3b90gbfv.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 November 03 08:51, Junio C Hamano wrote:
> time, switch between them only to compile, test and install but
> never develop on them" workflow is rather specific to top-level
> maintainer's workflow and that is why I said defaulting to
> separate-remote would be an inconvenience to a minority.
This is only a question of the default; why couldn't you (when it exists) use?
git clone --dont-use-separate-remote URL
To get exactly what you always had if that's what you want?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* git-format-patch little gripe
From: Luben Tuikov @ 2006-11-03 9:07 UTC (permalink / raw)
To: git
Yep, after more than a year, I simply cannot get used to it...
http://marc.theaimsgroup.com/?l=git&m=113259043217761&w=2
And as I've seen, other people brought that up too.
My brain simply says:
`` "git-format-patch" is singular and so the SHA-1 specified
on the command line should generate a _single_ patch.''
Yeah, but no.
So I still make the mistake of:
# git-rev-list --no-merges --pretty=one-line HEAD -- <somepath>
I select a commit
# git-format-patch -o /tmp/ <commit>
...
Oh, f@#$! <CTRL-C>
# git-format-patch -o /tmp/ <commit>^..<commit>
Is there a chance to make "git-format-patch" output a single
patch? of that commit only?
Luben
P.S. And let "git-format-patches" go wild with the ideologies...
Sorry, needed to vent as I made this mistake twice already
today...
^ permalink raw reply
* Re: git bug? + question
From: Andy Parkins @ 2006-11-03 8:53 UTC (permalink / raw)
To: git
In-Reply-To: <20061103074857.GA15972@diana.vm.bytemark.co.uk>
On Friday 2006 November 03 07:48, Karl Hasselström wrote:
> Hmm, this is interesting. 99% of the time, I use "git fetch", followed
> by "git pull . remotes/origin/foo" (often having run gitk in between
I often do this too; and have found that the "remotes" is not needed provided
there is no overlap with your local branch names. The above can be replaced
with
git pull . origin/foo
This relies on there being no "origin/foo" local branch.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: git bug? + question
From: Junio C Hamano @ 2006-11-03 8:51 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Miles Bader, git
In-Reply-To: <20061103074857.GA15972@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:
>
>> I still need to remember to process "master" first, so all things
>> considered, this is a regression in usability for my workflow.
>
> Where does this constraint come from?
With separate remotes, I'd need something like:
for b in master maint next pu
do
git checkout $b && git pull && make || break
done
And I also would need to have per-branch configuration to merge
from ". remotes/origin/$b" without re-fetching while on a
non-master branch $b, for the above to work. I still need to
remember to process "master" first, so all things considered,
this is a regression in usability for my workflow.
Because I'll have to have the per-branch configuration that
would say something like this:
[remote."gitster"]
url = gitster.example.com:/home/junio/git.git/
fetch = heads/maint:remotes/gitster/maint
fetch = heads/master:remotes/gitster/master
fetch = heads/next:remotes/gitster/next
fetch = +heads/pu:remotes/gitster/pu
[branch."master"]
remote = gitster
merge = heads/master
[branch."maint"]
remote = .
merge = remotes/gitster/maint
[branch."next"]
remote = .
merge = remotes/gitster/next
...
Side note: the above would not actually work because I am
missing an earlier patch by Santi to special case 'dot' as the
value of "branch.$name.remote", but I think you get the idea.
This requires that by the time we update maint, next and pu
branches with what is in the upstream, their corresponding
remotes/gitster/* branches are already up-to-date and do not
have to be re-fetched, and processing master first is what
guarantees it.
I do not mind treating "master" specially at all; my otherwise
idle repositories with working tree (read: ones on secondary
machines I use primarily to build git binary for that machine or
that platform, not to develop on) always have "master" checked
out; I start working in them while "master" is checked out, and
I'll be on "master" before I leave that machine.
If I keep using the traditional layout, where master is fetched
to origin and next, maint and pu are used to track the remote, I
do not have to do any of the above remote/branch configuration
in the .git/config file, and after one "git pull" while on
"master", I'd have all four branches up to date, ready to be
checked out and compiled.
But I suspect this "following multiple branches at the same
time, switch between them only to compile, test and install but
never develop on them" workflow is rather specific to top-level
maintainer's workflow and that is why I said defaulting to
separate-remote would be an inconvenience to a minority.
^ permalink raw reply
* Re: [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals
From: Andy Parkins @ 2006-11-03 8:47 UTC (permalink / raw)
To: git
In-Reply-To: <7vac39mew2.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 November 03 02:40, Junio C Hamano wrote:
> That is a change in behaviour and given that we introduced
> remotes for the explicit purpose of not to clutter the local
> branch namespace, I doubt defaulting to _show_ remotes is a good
Really? I had imagined it was to prevent accidental checking out of an
upstream-tracking branch. Also; I don't think "not cluttering the namespace"
is the same as "not showing multiple namespaces". The local namespace
remains as uncluttered as it ever was. This is a question of what to
display.
Assuming my "mixed mode" display thing were in place, doesn't that make the
two choices of UI
1)
git-branch : show local branches
git-branch --all : show local and remote branches
git-branch -r : show remote branches
2)
git-branch : show local and remote branches
git-branch --local : show local branches
git-branch -r : show remote branches
In case 2) the switch is simply selecting a filter, and so fits in with
the "-r" better.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH 2/4] Rename remote_only to display_mode
From: Andy Parkins @ 2006-11-03 8:40 UTC (permalink / raw)
To: git
In-Reply-To: <7v64dxl0bf.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 November 03 02:40, Junio C Hamano wrote:
> If you make this a "mode", it probably is better to make 1 and 0
> into symbolic constants. This patch taken alone is regression
> in readability.
In my own code I would have done exactly that; however I've been trying to
keep my patches as minimal as possible.
Digressing a little: what is the polite form of patches for git? My strategy
with this set was to make each patch as small as possible to reach my end
point. If those patches were okayed on the list, I could then do a "make
more beautiful" patch, which is really nothing to do with the original
changes to functionality but would make the code prettier. Really I'm asking
what level of intrusiveness of patch is not considered rude? In making my
patches, should I ride rough-shod over current implementation and just do it
how I'd do it or should I try to fit in (as I did in this case)?
> Something like this untested patch, that is...
I'm very much in favour; I shall make changes of this form soon.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH 4/4] Show the branch type after the branch name for remotes
From: Andy Parkins @ 2006-11-03 8:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7qtl0bk.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 November 03 02:40, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
> > Instead of prefixing the remote branches with "remotes/" suffix them with
> > "[read only]"
>
> This is a change in UI and while I understand why you want to
> say r/o instead of remotes/, I think this needs a bit more
> thought and discussion. People should not be feeding the output
> of "git branch" Porcelainish to their scripts, but you'll never
> know...
I intentionally made this patch in such a way as to leave the original form
available. I haven't added a switch to show the original form, but it's
there if it's needed.
The reason I thought it would be acceptable is that the output changed fairly
significantly when git-branch went builtin.
Here's the original and my "git-branch -r" run on my git repository
$ git-branch -r
remotes/up/maint
remotes/up/master
remotes/up/next
remotes/up/pu
$ ./git-branch -r
momentum/master
up/maint
up/master
up/next
up/pu
I've not touched the "-r" path, so this is the same as the unpatched builtin
branch. The "remotes/" prefix is removed in refs.c by for_each_remote_ref()
with do_for_each_ref("refs/remotes/", fn, 13, cb_data); and the spaces are
added because print_ref_list() has only one printing path and that always
includes spaces.
For me personally, I find my git-branch output more useful because in it's
unswitched form it shows me all branches. However, I can easily put this
behaviour under a switch or, and this would get my vote, put the original
behaviour (i.e. show local branches only) under a switch.
Which would you like? If any.
> By the way, does "git branch -r" (without any of your patches)
> even say "remotes/"?
I haven't touched the "-r" path, so that output should be unaffected. As
mentioned above, git-branch.sh did include "remotes/", new builtin branch
does not, but does include " " at the beginning of every line.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] Added description for reversing git-update-index using --index-info
From: Andy Parkins @ 2006-11-03 8:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyd1mew3.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 November 03 02:40, Junio C Hamano wrote:
> > +git ls-tree -r HEAD | git update-index --index-info
>
> While this is correct in the mechanical sense, it _sucks_ as an
> example, especially since you do not mention that the user would
> most likely need to do 'git update-index --refresh' afterwards
> to make the result useful.
I'm happy to ditch it if you wish; I included it only because it was one of
the examples that Shawn gave me in my original question.
Would you like a new patch?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH/RFC 1/n] gitweb: Better git-unquoting and gitweb-quoting of pathnames
From: Junio C Hamano @ 2006-11-03 8:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610301958.23334.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index ec46b80..a15e916 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -563,12 +563,42 @@ sub esc_html {
> return $str;
> }
>
> +# quote unsafe characters and escape filename to HTML
> +sub esc_path {
> + my $str = shift;
> + $str = esc_html($str);
> + $str =~ s/[[:cntrl:]\a\b\e\f\n\r\t\011]/?/g; # like --hide-control-chars in ls
> + return $str;
> +}
> +
When you say "[:cntrl:]" do you need to say anything more?
I was initially puzzled by "\t\011" bit, but I realize that is a
bug that is consistent with the next part I'll comment on.
> # git may return quoted and escaped filenames
> sub unquote {
> my $str = shift;
> +
> + sub unq {
> + my $seq = shift;
> + my %es = (
> + 't' => "\t", # tab (HT, TAB)
> + 'n' => "\n", # newline (NL)
> + 'r' => "\r", # return (CR)
> + 'f' => "\f", # form feed (FF)
> + 'b' => "\b", # backspace (BS)
> + 'a' => "\a", # alarm (bell) (BEL)
> + #'e' => "\e", # escape (ESC)
> + 'v' => "\011", # vertical tab (VT)
> + );
> +
> + # octal char sequence
> + return chr(oct($seq)) if ($seq =~ m/^[0-7]{1,3}$/);
> + # C escape sequence (this includes '\n' (LF) and '\t' (TAB))
> + return $es{$seq} if ($seq =~ m/^[abefnrtv]$/);
Problems in this part of the code X-<.
* Was there a reason not to unwrap '\e' to "\e"?
* The vertical tab is \013 (decimal 11), not \011 (which is TAB).
* The name and the abbreviated name of the character "\n" are
"line feed" and "LF"; I personally do not think these
character name comments are needed in this part of the code,
but I do not object if you want to have them there, as long
as you spell them correctly. cf. ISO/IEC 6429:1992 or
http://www.unicode.org/charts/PDF/U0000.pdf for example.
* The hash %es and the pattern /[abef...]/ must be kept in
sync; it is a maintenance nightmare,
* Worse yet, they do not agree even in this initial version,
which proves the previous point.
Perhaps this is better written as:
if (exists $es{$seq}) {
return $es{$seq};
}
The rest must have been a lot of work to sift through esc_html
and identify which is path and which is not. Much appreciated
and expect a cleaned up patch to be applied.
^ permalink raw reply
* Re: git bug? + question
From: Karl Hasselström @ 2006-11-03 8:12 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <20061102224549.499610d1.seanlkml@sympatico.ca>
On 2006-11-02 22:45:49 -0500, Sean wrote:
> One thing that would make separate-remotes nicer to work with is to
> have an automatic mapping between any local branch and one of the
> same name in remotes.
>
> So for instance, if you have a local branch named pu checked out and
> you pull from origin, remotes/origin/pu would be merged after the
> fetch unless a manual mapping was defined in the remotes or config
> file.
I would rather see the default pull source of a branch being
determined by which branch it was branched off of. But this should
mean the same thing in this case. We'd just have to have the heuristic
that default pulls from a remotes/*/* branch causes a fetch, while a
default pull from a local branch does not.
> Maybe even going as far as automatically creating a local branch for
> each remote branch on clone is worth considering.
Yes, maybe. It should make for a good default for beginners, at least.
> On a peripherally related topic, someone on the xorg list was
> complaining that after the initial clone, there is no easy way to
> track branches that get added/deleted from the remote repo. It would
> be nice if pull had an option to automatically add and remove remote
> branches from the remotes/<remote>/xxx namespace.
That would definitely be useful. But I want it in fetch, not pull. :-)
Well, I suppose it could be in both.
Hmm, I think my dislike of remote pulls can be summed up as: I find it
convoluted to have a command that will fetch multiple remote branches,
then merge just one of them into my current branch. (I have no problem
with pull when the branches to pull are specified explicitly, since in
that case they are all merged.) With explicitly specified default pull
sources it would get better, since then I would know that the correct
branch would be merged, but I still don't quite like it.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: git bug? + question
From: Karl Hasselström @ 2006-11-03 7:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miles Bader, git
In-Reply-To: <7v4pthmew1.fsf@assigned-by-dhcp.cox.net>
On 2006-11-02 18:40:30 -0800, Junio C Hamano wrote:
> which is efficient (guaranteed to do only one fetch from remote) and
> convenient.
Hmm, this is interesting. 99% of the time, I use "git fetch", followed
by "git pull . remotes/origin/foo" (often having run gitk in between
the two in order to see what's coming). I like to know what I'm
pulling (yes, I know how to undo a bad pull, but still ...).
> And I also would need to have per-branch configuration to merge from
> ". remotes/origin/$b" without re-fetching while on a non-master
> branch $b, for the above to work.
This is a good point. The "remotes/$repo/$branch" names are quite a
mouthful to type, so default pull sources would be a definite
improvement. (It would also be an improvement for the case when the
user is susceptible to the human factor.) Simply defaulting to pull
from the branch that this branch was cloned from should do the trick
(but the pull source should of course be editable).
> I still need to remember to process "master" first, so all things
> considered, this is a regression in usability for my workflow.
Where does this constraint come from?
> But that is probably a minor inconvenience to a minority. Most
> of the world follow others' repositories that have a single
> primary head, and defaulting to use separate-remote would help
> them a lot.
I can attest that separate remotes is a usability win also when using
several branches from more than one remote source. It's actually
possible to infer from the branch name (remotes/$repo/$branch) which
branch from which repository is being tracked.
As an aside, in case of several remote repositories, "git fetch --all"
would be handy.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: multiple branches or multiple repositories
From: Linus Torvalds @ 2006-11-03 7:11 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <eie7ae$ib6$1@sea.gmane.org>
On Fri, 3 Nov 2006, Han-Wen Nienhuys wrote:
>
> We're in the process of converting the LilyPond CVS repository at
> savannah.gnu.org to GIT. One of the questions we need to deal with, is how
> handle modules.
>
> There seem to be two approaches:
>
> - for each module, create a separate git repository. Inside the repository,
> each subproject has its own branching
>
> - put each module as a separate branch in a shared repository.
>
> I think the first option is the most natural one, but are there any issues,
> besides namespace pollution to the second option?
There are no real issues either way, and perhaps more importantly, it's
not even something you have to decide on day one.
You can easily do it one way or the other, and either
- switch around as needed
- or even _mix_ the two approaches where it makes sense.
For example, it may be entirely sensible to have the common "distribution
points" use a single shared repository that contains all modules as
separate branches within the same repository.
But even though such a central distribution point repository is set up
that way, individual developers may well decide that they are happier
having separate repositories for different modules. The two approaches are
not mutually incompatible, and you can fetch data and push it back out
between both different kinds of repositories.
The namespace pollution - especially of tags - is indeed likely to be the
worst issue. If you expect to have many independent modules in the same
repository, you obviously shouldn't use tag-names like the Linux kernel
uses (ie "v2.6.18"), since those would not be unambiguous in such a shared
repo.
(The same is true of branches too, but perhaps less so if only because
people are _already_ using different branch names between different
repositories, and we have good support for translating a local branch
name "X" into a remote branch name "Y" when transferring data between the
two. In contrast, tagnames are kind of expected to be "shared")
But if you're ok with always just naming tags "modulename/release-1.2.3"
or similar, you shouldn't really have any issues either way. And most
importantly, if you do decide to go one way, and then later figure out
that it would have been easier the other way, you can just switch between
the two models, exactly because mixing them isn't really a problem.
^ permalink raw reply
* git-svn todo/wishlist
From: Eric Wong @ 2006-11-03 7:01 UTC (permalink / raw)
To: git
There are several things I'd like to see in git-svn, but haven't had
much time to do myself, and more interesting things keep popping up :)
Some of these I dread working on because it involves having to wrangle
with the (imho) overly complex SVN API, but the end user experience
should be better afterwards :)
1. Ability to transfer deltas over fetches. Currently, we transfer
deltas only when committing, but when we fetch, we fetch whole files
if they're modified (like git with dumb protocols). Our current method
is very fast with fast connections and the code is very simple (I
ripped the code off svnimport :), but users behind slower links will
find the waiting for the svn server to generate a delta to be faster.
2. Ability to login and accept SSL certificates without relying on
the caching done by the svn command-line client. I tried doing this
a while back, but was unsuccessful, and didn't look into it further.
I couldn't get svm/SVN::Mirror to work with this, either. This could
be a bug in SVN bindings, too...
3. Documentation. The -i/GIT_SVN_ID= stuff should probably be promoted
more now that branches/tags are better supported. More examples,
too...
4. Would storing the SVN URLs in .git/config be a good idea? I'm
considering it as it would potentially simplify some things for
people tracking multiple trees.
5. Ability to create tags/branches on the SVN side. I'd like to avoid
having to re-fetch all the new stuff into git if I created a new
tag/branch on the SVN side. This shouldn't be very hard to do.
Avoiding re-fetching new stuff when somebody else creates a
tag/branch would also be nice, but more involved.
6. Faster multi-fetch across a single repository. This would probably
be easier if we relied less on global variables and subprocesses.
7. Some method of handling svn:externals would be a nice feature to
have. This would be easier with subproject support from git.
8. Packed refs. I haven't looked into this at all yet, I just heard of
it just heard about it a while back and it ("packed refs") sounded
like it could replace the .rev_db files I'm using in git-svn.
9. If not packed refs, then .rev_db could be transparently compressed.
It's good for high-activity trunks; but very space-inefficient
for tags and sparse branches.
--
^ permalink raw reply
* Re: [PATCH 6/n] gitweb: Remove redundant "blob" links from git_difftree_body
From: Junio C Hamano @ 2006-11-03 6:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200610311707.43054.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> ... First, it did that incompletely: it did not add "blob"
> link for added files, and added block used mixture of tabs and spaces
> for align. Second, in "difftree" view the "blob" link is not the most
> interesting, *contrary* to "blob"/"tree" link in "tree" view, so it
> should be enough to have hidden link in the form of file name entry.
I think these "blob" links are good thing to have, and if you
think the earlier work was incomplete and know some cases are
not covered I think it would be better to help completing it
rather than reverting.
I do not understand why you feel "blob" is not the most
interesting. Often, when it is not obvious if a patch is
correct only with the context, it is useful to view the whole
postimage after applying the patch, and the "blob" link helps
that.
^ permalink raw reply
* Re: [ANNOUNCE] Example Cogito Addon - cogito-bundle
From: Martin Langhoff @ 2006-11-03 6:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Linus Torvalds, Jan Hudec, Jeff King, bazaar-ng, git
In-Reply-To: <200610212121.58245.jnareb@gmail.com>
On 10/22/06, Jakub Narebski <jnareb@gmail.com> wrote:
> Lack of --follow is not a big issue because you can do this "by hand";
> you can use git-diff-tree -M at the end of file history to check if
> [git considers] it was moved from somewhere.
This 'by hand' can be done in shell. cg-log has a half-complete
implementation of it. Seems to be disabled now :-(
cheers,
^ 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