* Re: weird strncmp usage?
From: Florian Weimer @ 2006-11-03 21:05 UTC (permalink / raw)
To: git
In-Reply-To: <45494D84.2060402@shadowen.org>
* Andy Whitcroft:
> If you are doing these a _lot_ then there is a significant additional
> cost to using strlen on a constant string.
strlen has been a GCC builtin for quite some time. If the wrapper
function is inlined, GCC will optimize it away. (It also turns the
^ permalink raw reply
* Re: git-format-patch little gripe
From: Jakub Narebski @ 2006-11-03 20:53 UTC (permalink / raw)
To: git
In-Reply-To: <20061103195253.9244.qmail@web31814.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> One thing we talked about but nobody stepped up to code [*1*] is
>> to give "git-format-patch --stdin" that reads list of commits,
>> and runs "git-diff-tree --pretty --stat --summary -p $commit".
>> With that, we could do something like:
>>
>> git rev-list linus..orinoco | git format-patch --stdin
>
> That'd be swell to have.
>
>> Your "git-format-patch --single $commit" is a shorthand for a
>> degenerated special case of that pattern.
>
> Yes, except that I'd have to paste the sha-1 into the terminal
> rather than on the command line. This again proves that the current
> git-format-patch <sha-1> to mean "<sha-1>..HEAD" is horribly broken.
First, you could have behavior you wanted by using additional option
--single, i.e. git-format-patch --single <sha-1> would mean
git-format-patch <sha-1>^..<sha-1>
But I agree that it is somewhat counter-intuitive that for all
other commands which use revision list <sha-1> means lineage
of <sha-1> while for git-format-patch it means <sha-1>..HEAD
... and we have <sha-1>.. shortcut (two characters more) to mean
the same.
Another command with non-obvious UI is git-format-branch, which
is not CLI equivalent of gitk/qgit (doesn't accept revision range
for example).
>> You cannot do patch-id based filtering with this form, but I see
>> that "single" is often wanted on the list and #git, and people
>> who want it do not care about patch-id based filtering at all.
>
> The reason it is wanted is because it is _intuitive_. This is
> what engineers (of different backgrounds) tend to intuitively think
> and assume given git's structure and the nature and meaning of
> what an <sha-1> is in git, only to be surprised later when that
> assumption is completely broken by git-format-patch.
Intuiveness is in the eye of beholder :-)
>> And I do not think it is that "they do not realize how much they
>> would be missing without patch-id filtering", in this case. So
>> the above command line would probably be Ok.
>
> I do not think they'd be missing _anything_. After all,
> "git-format-patch <sha-1>..HEAD" is also intuitive.
And we have <sha-1>.. shortcut.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-format-patch little gripe
From: Luben Tuikov @ 2006-11-03 20:37 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20061103185026.GA28566@coredump.intra.peff.net>
--- Jeff King <peff@peff.net> wrote:
> For my own workflow, I don't want to have to pick the commit out of
> rev-list (or log) output. I want to find it and hit a button to say "OK,
> now mail this patch." So I put _all_ of my patches into an mbox, and
> then browse them with mutt. Sort of a poor man's patch browser, but then
> I'm ready to jump into mailing them immediately.
>
> I use the following script:
>
> #!/bin/sh
> root=${1:-origin}
> git-format-patch -s --stdout $root >.mbox
> mutt -f .mbox
> rm -f .mbox
>
> And then in mutt, I use this macro to bind 'b' to editing the full
> message w/ headers:
>
> macro index b ":set edit_headers=yes<enter><resend-message>:set edit_headers=no<enter>"
>
> I know that may be useless if you're not using mutt, but I just wanted
> to stimulate some discussion among patch submitters about how they
> actually do it. I'm not sure how configurable tig is, but it shouldn't
> be too hard to add something like this to it.
That's very cool!
Luben
^ permalink raw reply
* Re: git bug? + question
From: Shawn Pearce @ 2006-11-03 20:36 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, Miles Bader, git, Karl Hasselström
In-Reply-To: <20061102224549.499610d1.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Thu, 02 Nov 2006 18:40:30 -0800
> Junio C Hamano <junkio@cox.net> wrote:
>
> > which is efficient (guaranteed to do only one fetch from remote)
> > and convenient. Also I have Push: mapping set up on my
> > main machine to do master:origin, next:next, maint:maint, and
> > +pu:pu so that I can replace the first "git pull" on the
> > secondary machine with "git push secondary" on my main machine.
>
> 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.
>
> Maybe even going as far as automatically creating a local branch
> for each remote branch on clone is worth considering.
Nack.
I work with a workflow where our central repository has 2 important
branches (vmtip and vmvt), and a bunch of transient developer
topic branches (e.g. sp/foo). We only have a master branch in this
repository so that git-clone will clone it without choking during
the clone. Users tend to do immediately after a clone:
git branch -D master
git branch -D origin
git branch -D ... other topic branches not interested in ...
edit .git/remotes/origin ... delete topic branches ...
Why? Because vmtip and vmdvt have meaning to these users, much as
pu has meaning. Really vmtip is roughly equal to master in Git and
vmdvt is roughly equal to maint but not having the mental mapping of
"vmtip == master" just makes things easier.
Creating a local branch for every remote branch would just make
things worse in the above workflow; not to mention it makes it
confusing for other users who might be fetching into a repository
and expecting their local "next" to to update automatically after
a fetch...
> 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.
Or at least deleting/skipping over a branch you listed to fetch
from the remote that no longer happnes to be on the remote. This is
causing some pain due to the topic branches noted above.
--
^ permalink raw reply
* Re: git bug? + question
From: Shawn Pearce @ 2006-11-03 20:29 UTC (permalink / raw)
To: Sean; +Cc: Karl Hasselström, Junio C Hamano, Miles Bader, git
In-Reply-To: <20061103042540.192bbd18.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> 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.
Yes, definately. For most people I know that use Git the branch
they branched off of is the one they need to pull in on a regular
basis to keep their topic branch current. They rarely pull other
branches in.
> 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.
Nack. I'd rather see the entries added/removed from .git/config when
the branch is created/deleted, just like the ref and the reflog are
created/deleted. It makes behavior more consistent for the user
and it is mostly self documenting...
"why is branch FOO pulling FOO by default? ahhh, its in
.git/config after git branch FOO FOO."
Same goes for git-clone. The branch.master.merge=origin/master
entry should be in .git/config file after the clone is complete.
--
^ permalink raw reply
* Re: [PATCH 4/4] Show the branch type after the branch name for remotes
From: Junio C Hamano @ 2006-11-03 20:08 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611030833.42596.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> 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.
I am a wrong person to ask, since I do not usually work in
repositories with refs/remotes/ myself and the choice would not
affect me either way.
For people who work with multiple remotes (e.g. following both
Linus and Jeff) and work on many separate topic branches of
their own, I would suspect that showing only local branches by
default, with an option to show remote branches from only named
remotes would make things less cluttered, and we can always have
"-a" to mean everything under the sun.
This kind of limiting can be done more flexibly with globbing
than just fixed set of flags.
We could have:
git branch --list 'heads/'
git branch --list 'remotes/jgarzik/'
git branch --list 'heads/??/*'
and that command, crazily enough, would let you do:
git branch --list 'tags/v2.6.19-rc*'
Hmm?
^ permalink raw reply
* Re: git bug? + question
From: Junio C Hamano @ 2006-11-03 19:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0611030741530.25218@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 3 Nov 2006, Junio C Hamano wrote:
>>
>> [remote."gitster"]
>
> Btw, why the '.'? It doesn't even work with a dot, you have to have a
> space, which is also a lot more readable..
Untested example ;-).
I do not have to use any of these in real life because I work in
repositories laid out without separate remotes.
> This would basically require that "git-parse-remote" be re-written as a
> native builtin, because quite frankly, it would be too damn painful any
> other way, but it really shouldn't be that nasty. In fact, I think we
> should have done that long ago, because the shell-code is just horrid for
> things like this.
I agree.
I am rediscovering git-cvsimport and git-cvsexportcommit right
now, and one thing I wished was git-cvsimport to have worked as
if it is a git-fetch of an exotic flavor. Integrating it into
git-fetch so that "URL: cvs://repo.si.to/ry" in .git/remotes
would do a sensible thing and make git-cvsimport honor
"Pull: HEAD:remotes/cvs/master" would both need some work in
parse-remote, and doing anything more complicated than the
current parse-remote in shell is quite painful.
^ permalink raw reply
* Re: git-format-patch little gripe
From: Luben Tuikov @ 2006-11-03 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt6cbwzq.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> It would have been nicer if you made that argument as a reply to
> one of these messages:
>
> http://thread.gmane.org/gmane.comp.version-control.git/4266/focus=4279
> http://thread.gmane.org/gmane.comp.version-control.git/4843/focus=4843
> http://thread.gmane.org/gmane.comp.version-control.git/5440/focus=5446
I'm amazed at people who can read selectively messages in mailing lists.
The amount of messages sometimes is overwhelming.
> It is not an ideology; it is called not breaking existing UI,
> which is rather unfortunate, because its UI is not the greatest
> in the world.
Yes, it is very unfortunate. It's like the metric system... nobody would
want to switch to it if you give them a _choice_... so water is going
to be freezing at 32 degrees and boiling over at 212.
So unless someone submits and commits a patch to fix this, and then we
shelter in the storm, it will never change.
> set" which is roughly "rev-list yours..upstream". Some of your
> patches (i.e. "rev-list upstream..yours") may have already
Yeah, that's exactly what I do.
> One thing we talked about but nobody stepped up to code [*1*] is
> to give "git-format-patch --stdin" that reads list of commits,
> and runs "git-diff-tree --pretty --stat --summary -p $commit".
> With that, we could do something like:
>
> git rev-list linus..orinoco | git format-patch --stdin
That'd be swell to have.
> Your "git-format-patch --single $commit" is a shorthand for a
> degenerated special case of that pattern.
Yes, except that I'd have to paste the sha-1 into the terminal
rather than on the command line. This again proves that the current
git-format-patch <sha-1> to mean "<sha-1>..HEAD" is horribly broken.
> You cannot do patch-id based filtering with this form, but I see
> that "single" is often wanted on the list and #git, and people
> who want it do not care about patch-id based filtering at all.
The reason it is wanted is because it is _intuitive_. This is
what engineers (of different backgrounds) tend to intuitively think
and assume given git's structure and the nature and meaning of
what an <sha-1> is in git, only to be surprised later when that
assumption is completely broken by git-format-patch.
"git-format-patch <sha-1>" intuitively means "Show me the commit identified
by the <sha-1> in a patch format."
Now if it had been called "git-format-patches" then maybe the argument
would've been different.
> And I do not think it is that "they do not realize how much they
> would be missing without patch-id filtering", in this case. So
> the above command line would probably be Ok.
I do not think they'd be missing _anything_. After all,
"git-format-patch <sha-1>..HEAD" is also intuitive.
> With --left-right (in "pu"), you could even do something a bit
> fancier like this:
>
> git rev-list --left-right linus...8139cp linus...airo |
> git format-patch --stdin
>
> The --left-right output option, when used in conjunction with
> the symmetric difference set operator, prefixes each commit with
> '<' (left) or '>' (right) to indicate which ancestry it belongs
> to (in the above example, the commits only in the branch that
Yeah, this is swell too!
> *1* format-patch is primarily the tool for a patch submitter,
> and I did its original version back when I was one. For a long
> time (an equivalent to "eternity" in git timescale back then)
> Linus did not show _any_ interest in it (you can compare the
Yes, this is sad. There's other places where Linus hasn't shown
any interest which have been suffering ever since. Someone needs
to make the decision after all, or at least appoint someone to make
the decision (and then blame them ;-) later).
> dates on the messages I quoted above with the commit date of
> 0acfc972), and I suspect one of the reasons is because he was
> the toplevel maintainer and did not have a need for a tool like
> that. Now I am the toplevel maintainer here and I haven't felt
> the need to update it myself for quite some time ("it works for
> me"), which is a bit sad.
If I had the clout, I'd change "git-format-patch <sha-1>" to
mean "git-format-patch <sha-1>^..<sha-1>" in a heart-beat, without
even blinking.
So what if people find out their tools now generate only _one_ patch
instead of N? They'll revisit their scripts and use "<sha-1>..HEAD",
(which says what it means), instead of the completely broken current
behavior.
Also I doubt how many people actually have coded in their scripts
"git-format-patch <sha-1>" to mead by default "<sha-1>..HEAD" -- I'd think
that maintainers always want to know the "end point" and would always
use the <a>..<b> format, instead of presuming where/what their HEAD is.
Sorry it's my rant. I know it's not your fault.
Luben
^ permalink raw reply
* Re: git bug? + question
From: Junio C Hamano @ 2006-11-03 19:28 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611030909.02564.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> 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
Because I do not need it ;-). If we switch the default to
separate-remote, I'd just let clone to lay it out that way and
then update the ref layout myself to suit my needs. So it is
really just the matter of deciding which is more appropriate
default for the majority.
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Junio C Hamano @ 2006-11-03 19:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611031206.12515.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> I wanted to have a visual indication of which branches are
> local and which are remote in git-branch -a output; however
> Junio was concerned that someone might be using the output in
> a script. This patch addresses the problem by colouring the
> git-branch output - which in "auto" mode won't be activated.
Yuck. We are getting more and more color happy. As long as
this stays optional I'm Ok with it; we'll see if people find it
useful soon enough.
> @@ -165,11 +199,28 @@ static void print_ref_list( int type_wan
> qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
>
> for (i = 0; i < ref_list.index; i++) {
> + switch( ref_list.list[i].type ) {
> + case REF_LOCAL_BRANCH:
> + color = COLOR_BRANCH_LOCAL;
> + break;
Style. SP between "switch" and open parenthesis, no SP after
that open parenthesis. We tend to align "switch", "case", and
"default" on the same column.
^ permalink raw reply
* Re: [PATCH] Add support to git-branch to show local and remote branches
From: Junio C Hamano @ 2006-11-03 19:19 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611031240.34177.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Friday 2006 November 03 12:08, Junio C Hamano wrote:
>
>> > +static int tidy_ref_list( struct ref_list *ref_list )
>>
>> Style. No spaces before or after parameter list.
>
> Bah! It's so hard getting my fingers to remember what style goes in which
> project :-)
>
>> I see you already parse "refs/tags" prefix. "git branch" would
>> not print tags, but that part might be useful when we want to
>> redo git-tag in C.
>
> I'm going to have a look at that soon;...
Just to make sure you do not misunderstand. I do not see much
need for rewriting git-tag in C right now, and often it is more
convenient to leave higher layer commands in shell scripts to
allow people to try out new things and flush out UI issues. I
was merely pointing out that part of the code would be usable if
we were to do it.
^ permalink raw reply
* Re: git-format-patch little gripe
From: Jeff King @ 2006-11-03 18:50 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <376237.14965.qm@web31805.mail.mud.yahoo.com>
On Fri, Nov 03, 2006 at 01:07:20AM -0800, Luben Tuikov wrote:
> 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>
For my own workflow, I don't want to have to pick the commit out of
rev-list (or log) output. I want to find it and hit a button to say "OK,
now mail this patch." So I put _all_ of my patches into an mbox, and
then browse them with mutt. Sort of a poor man's patch browser, but then
I'm ready to jump into mailing them immediately.
I use the following script:
#!/bin/sh
root=${1:-origin}
git-format-patch -s --stdout $root >.mbox
mutt -f .mbox
rm -f .mbox
And then in mutt, I use this macro to bind 'b' to editing the full
message w/ headers:
macro index b ":set edit_headers=yes<enter><resend-message>:set edit_headers=no<enter>"
I know that may be useless if you're not using mutt, but I just wanted
to stimulate some discussion among patch submitters about how they
actually do it. I'm not sure how configurable tig is, but it shouldn't
be too hard to add something like this to it.
^ permalink raw reply
* How to complete t/README file?
From: Jakub Narebski @ 2006-11-03 18:50 UTC (permalink / raw)
To: git
How to complete family numbering in t/README? Curently we have:
-- >8 --
First digit tells the family:
0 - the absolute basics and global stuff
1 - the basic commands concerning database
2 - the basic commands concerning the working tree
3 - the other basic commands (e.g. ls-files)
4 - the diff commands
5 - the pull and exporting commands
6 - the revision tree commands (even e.g. merge-base)
7 - the porcelainish commands concerning the working tree
-- >8 --
But there are tests which have 8 or 9 as first digit:
8 - annotate, blame, pickaxe
9 - send-email, git-svn
8 seems to be porcelanish "archeology" (analysis, interrogators)
commands, 9 seems to be interfaces (to email, to svn). Do you have idea
how to name those families?
P.S. Do I understand correctly that gotweb tests would eblong
to familiy 9 of tests?
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Linus Torvalds @ 2006-11-03 18:48 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Karl Hasselström, Catalin Marinas, git
In-Reply-To: <454B4C43.2040607@shadowen.org>
On Fri, 3 Nov 2006, Andy Whitcroft wrote:
>
> Heh, well the copy thunderbird wrote directly to my mailbox is also
> 8bit. And thinking about it I've seen talk of MTA's not supporting 8bit
> xfers between themselves, so thats probabally when it gets switched.
If your ISP mailer doesn't answer with "8BITMIME" to your EHLO, your mail
client is supposed to downgrade to a 7-bit format (or the same thing can
happen anywhere in between on one of the other hops). Of course, that
would be a really old and broken mailer, and if you find one of those at
the ISP you use, you should probably switch ISPs.
Some other mailers have other issues, and qmail for example is apparently
totally broken (it accepts 8-bit input, but cannot forward it properly to
somebody who wants it converted to 7-bit).
And some of us use "fetchmail" and ask it do do mimedecode for us, so that
even if it arrived as 7-bit crud, we don't have to see it. So the fact
that some people see it as 8-bit can be because the hops to them didn't
involve a broken remailer, but it could also be because something in
between (like fetchmail) tries to fix it up after the fact.
That said: it tends to be unusual to see true 7-bit mailer setups these
days.
So the most _likely_ cause of unnecessary 7-bit QP crud is not in fact a
7-bit mailserver, but usually just the mail client that is just lazy and
just sends out everything as 7-bit because it's too bothersome to even
look at whether the mail server supports 8-bit data. Check your
Thunderbird settings - it's quite possible that there's a flag there
somewhere to turn on 8-bit mail transfers.
^ permalink raw reply
* Re: git bug? + question
From: Josef Weidendorfer @ 2006-11-03 19:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio C Hamano, Karl Hasselström
In-Reply-To: <eiftb1$ild$1@sea.gmane.org>
On Friday 03 November 2006 18:13, Jakub Narebski wrote:
> Josef Weidendorfer wrote:
>
> > Other option: Introduce "fetchonly" line which ignores the original
> > fetch lines in the remote section.
>
> I like this.
That's implementing it:
=================================
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -156,6 +156,18 @@ canon_refs_list_for_fetch () {
# Returns list of src: (no store), or src:dst (store)
get_remote_default_refs_for_fetch () {
+ # if there are any branch.${curr_branch}.fetchonly entries,
+ # only use them as default
+ curr_branch=$(git-symbolic-ref HEAD | \
+ sed -e 's|^refs/heads/||')
+ fetchonly_branches=$(git-repo-config \
+ --get-all "branch.${curr_branch}.fetchonly")
+ if test ! -z $fetchonly_branches
+ then
+ canon_refs_list_for_fetch -d "$1" $fetchonly_branches
+ return
+ fi
+
data_source=$(get_data_source "$1")
case "$data_source" in
'' | config-partial | branches-partial)
=================================
The problem with this small patch is that with
[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
fetchonly = heads/master:remotes/gitster/master
merge = remotes/gitster/master
and current branch "master", even "git fetch gitster" does not
fetch both branches, which is expected IMHO. We would need to
pass the info that an explicit repository was given down to
get_remote_default_refs_for_fetch().
^ permalink raw reply
* Re: git-format-patch little gripe
From: Jakub Narebski @ 2006-11-03 17:51 UTC (permalink / raw)
To: git
In-Reply-To: <87y7qsv3l7.wl%cworth@cworth.org>
Carl Worth wrote:
> (We've currently got "git commit --amend" for example, but
> what I often want is "git goto old-commit; #hack; git commit --amend;
> git replay" or whatever, (in Stacked Git speak that is currently "stg
> goto old-commit; #hack; stg refresh; stg push --all").
<we are on branch 'top', and assume that branch 'tmp' does not exist>
$ git checkout -b tmp old-commit
#hack
$ git commit --amend
$ git rebase --onto tmp old-commit top
$ git branch -D tmp
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git-format-patch little gripe
From: Carl Worth @ 2006-11-03 17:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Luben Tuikov, git
In-Reply-To: <7vwt6cbwzq.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1037 bytes --]
On Fri, 03 Nov 2006 03:17:13 -0800, Junio C Hamano wrote:
>
> It is not an ideology; it is called not breaking existing UI,
> which is rather unfortunate, because its UI is not the greatest
> in the world.
So maybe we could use some new thing here with cleaner UI. Perhaps:
git export
Paired with a new "git import" there would be a much more obvious way
of working for new users than "git format-patch" and "git am".
Meanwhile, I don't think export/import is the right place to do the
patch-id filtering, etc. That seems to work much better in the context
of something like StackedGit, (which I've started playing with
recently and been very impressed with). I'd really like to think about
some ways to bring some of the functionality of StackedGit into the
core tools. (We've currently got "git commit --amend" for example, but
what I often want is "git goto old-commit; #hack; git commit --amend;
git replay" or whatever, (in Stacked Git speak that is currently "stg
goto old-commit; #hack; stg refresh; stg push --all").
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git bug? + question
From: Jakub Narebski @ 2006-11-03 17:13 UTC (permalink / raw)
To: git
In-Reply-To: <200611031815.49553.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> Other option: Introduce "fetchonly" line which ignores the original
> fetch lines in the remote section.
I like this.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git bug? + question
From: Josef Weidendorfer @ 2006-11-03 17:15 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Junio C Hamano, Miles Bader, git
In-Reply-To: <20061103094655.GA16721@diana.vm.bytemark.co.uk>
On Friday 03 November 2006 10:46, Karl Hasselström wrote:
> Hmm. How about changing the meaning of "remote" slightly? Like this:
That's not good, as it changes existing config meaning.
But why not support fetch lines in [branch.*] sections?
Ie. instead of
> [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
make your config look like
[remote."gitster"]
url = gitster.example.com:/home/junio/git.git/
[branch."master"]
remote = gitster
fetch = heads/master:remotes/gitster/master
merge = remotes/gitster/master
[branch."next"]
remote = gitster
fetch = heads/next:remotes/gitster/next
merge = remotes/gitster/next
A fetch line in [branch.*] means: Also fetch this refspec in
addition to the refspecs specified in the remote section.
Problem being that "git fetch gitster" does nothing anymore :-(
Other option: Introduce "fetchonly" line which ignores the original
fetch lines in the remote section.
[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
fetchonly = heads/master:remotes/gitster/master
merge = remotes/gitster/master
^ permalink raw reply
* [PATCH 4/4] git.el: Include MERGE_MSG in the log-edit buffer even when not committing a merge.
From: Alexandre Julliard @ 2006-11-03 16:42 UTC (permalink / raw)
To: git
This lets us take advantage of the fact that git-cherry-pick now saves
the message in MERGE_MSG too.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 6f3b46d..972c402 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -589,6 +589,7 @@ and returns the process output as a stri
(let ((commit (git-commit-tree buffer tree head)))
(git-update-ref "HEAD" commit head)
(condition-case nil (delete-file ".git/MERGE_HEAD") (error nil))
+ (condition-case nil (delete-file ".git/MERGE_MSG") (error nil))
(with-current-buffer buffer (erase-buffer))
(git-set-files-state files 'uptodate)
(when (file-directory-p ".git/rr-cache")
@@ -888,7 +889,7 @@ and returns the process output as a stri
'face 'git-header-face)
(propertize git-log-msg-separator 'face 'git-separator-face)
"\n")
- (cond ((and merge-heads (file-readable-p ".git/MERGE_MSG"))
+ (cond ((file-readable-p ".git/MERGE_MSG")
(insert-file-contents ".git/MERGE_MSG"))
(sign-off
(insert (format "\n\nSigned-off-by: %s <%s>\n"
--
1.4.3.3.gf3240
--
Alexandre Julliard
^ permalink raw reply related
* [PATCH 3/4] git.el: Move point after the log message header when entering log-edit mode.
From: Alexandre Julliard @ 2006-11-03 16:42 UTC (permalink / raw)
To: git
Suggested by Han-Wen Nienhuys.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 08d6404..6f3b46d 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -899,7 +899,8 @@ and returns the process output as a stri
(2 font-lock-function-name-face))
(,(concat "^\\(" (regexp-quote git-log-msg-separator) "\\)$")
(1 font-lock-comment-face)))))
- (log-edit #'git-do-commit nil #'git-log-edit-files buffer))))
+ (log-edit #'git-do-commit nil #'git-log-edit-files buffer)
+ (re-search-forward (regexp-quote (concat git-log-msg-separator "\n")) nil t))))
(defun git-find-file ()
"Visit the current file in its own buffer."
--
1.4.3.3.gf3240
--
Alexandre Julliard
^ permalink raw reply related
* [PATCH 2/4] git.el: Added a function to open the current file in another window.
From: Alexandre Julliard @ 2006-11-03 16:41 UTC (permalink / raw)
To: git
Bound to 'o' by default, compatible with pcl-cvs and
buffer-mode. Suggested by Han-Wen Nienhuys.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index e283df2..08d6404 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -910,6 +910,15 @@ and returns the process output as a stri
(when (eq 'unmerged (git-fileinfo->state info))
(smerge-mode))))
+(defun git-find-file-other-window ()
+ "Visit the current file in its own buffer in another window."
+ (interactive)
+ (unless git-status (error "Not in git-status buffer."))
+ (let ((info (ewoc-data (ewoc-locate git-status))))
+ (find-file-other-window (git-fileinfo->name info))
+ (when (eq 'unmerged (git-fileinfo->state info))
+ (smerge-mode))))
+
(defun git-find-file-imerge ()
"Visit the current file in interactive merge mode."
(interactive)
@@ -994,6 +1003,7 @@ and returns the process output as a stri
(define-key map "M" 'git-mark-all)
(define-key map "n" 'git-next-file)
(define-key map "N" 'git-next-unmerged-file)
+ (define-key map "o" 'git-find-file-other-window)
(define-key map "p" 'git-prev-file)
(define-key map "P" 'git-prev-unmerged-file)
(define-key map "q" 'git-status-quit)
--
1.4.3.3.gf3240
--
Alexandre Julliard
^ permalink raw reply related
* [PATCH 1/4] git.el: Added functions for moving to the next/prev unmerged file.
From: Alexandre Julliard @ 2006-11-03 16:41 UTC (permalink / raw)
To: git
This is useful when doing a merge that changes many files with only a
few conflicts here and there.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 28 ++++++++++++++++++++++++++++
1 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 5354cd6..e283df2 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -670,6 +670,32 @@ and returns the process output as a stri
(unless git-status (error "Not in git-status buffer."))
(ewoc-goto-prev git-status n))
+(defun git-next-unmerged-file (&optional n)
+ "Move the selection down N unmerged files."
+ (interactive "p")
+ (unless git-status (error "Not in git-status buffer."))
+ (let* ((last (ewoc-locate git-status))
+ (node (ewoc-next git-status last)))
+ (while (and node (> n 0))
+ (when (eq 'unmerged (git-fileinfo->state (ewoc-data node)))
+ (setq n (1- n))
+ (setq last node))
+ (setq node (ewoc-next git-status node)))
+ (ewoc-goto-node git-status last)))
+
+(defun git-prev-unmerged-file (&optional n)
+ "Move the selection up N unmerged files."
+ (interactive "p")
+ (unless git-status (error "Not in git-status buffer."))
+ (let* ((last (ewoc-locate git-status))
+ (node (ewoc-prev git-status last)))
+ (while (and node (> n 0))
+ (when (eq 'unmerged (git-fileinfo->state (ewoc-data node)))
+ (setq n (1- n))
+ (setq last node))
+ (setq node (ewoc-prev git-status node)))
+ (ewoc-goto-node git-status last)))
+
(defun git-add-file ()
"Add marked file(s) to the index cache."
(interactive)
@@ -967,7 +993,9 @@ and returns the process output as a stri
(define-key map "m" 'git-mark-file)
(define-key map "M" 'git-mark-all)
(define-key map "n" 'git-next-file)
+ (define-key map "N" 'git-next-unmerged-file)
(define-key map "p" 'git-prev-file)
+ (define-key map "P" 'git-prev-unmerged-file)
(define-key map "q" 'git-status-quit)
(define-key map "r" 'git-remove-file)
(define-key map "R" 'git-resolve-file)
--
1.4.3.3.gf3240
--
Alexandre Julliard
^ permalink raw reply related
* Re: [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
From: Jakub Narebski @ 2006-11-03 16:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvem1s29g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> Junio C Hamano <junkio@cox.net> writes:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> Use "&iquot;" Latin 1 entity ("¿" -- inverted question mark =
>>> turned question mark, U+00BF ISOnum) instead '?' as replacements for
>>> control characters and other undisplayable characters.
>>>
>>> Signed-off-by: Jakub Narebski <jnareb@gmail.com>
>>
>> Do you have something against our Spanish and Latin American
>> friends? ;-)
>>
>> I wonder if there is a more suitable replacement character that
>> is accepted across scripts?
>
> I have a suspicion that instead of finding an exotic character,
> just showing the byte value in \octal, perhaps in different
> color, might be more portable and easier. For one thing, it
> helps to show the exact byte value than just one substitution
> character if you are troubleshooting gitweb.
Or perhaps we can use Unicode Control Pictures U+2400 – U+243F
(9216–9279) ("Unicode quoting"):
http://www.alanwood.net/unicode/control_pictures.html
http://www.unicode.org/charts/PDF/U2400.pdf
# quote unsafe characters and escape filename to HTML
sub esc_path {
my $str = shift;
$str = esc_html($str);
$str =~ s!([[:cntrl:]])!sprintf('<span class="cntrl">&#%04d;</span>', 9216+ord($1))!eg;
return $str;
}
with perhaps the following CSS
span.cntrl {
border: dashed #aaaaaa;
border-width: 1px;
padding: 0px 2px 0px 2px;
margin: 0px 2px 0px 2px;
}
What do you think of it?
--
Jakub Narebski
^ permalink raw reply
* Re: git bug? + question
From: Linus Torvalds @ 2006-11-03 16:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Karl Hasselström, Miles Bader, git
In-Reply-To: <7v3b90gbfv.fsf@assigned-by-dhcp.cox.net>
On Fri, 3 Nov 2006, Junio C Hamano wrote:
>
> [remote."gitster"]
Btw, why the '.'? It doesn't even work with a dot, you have to have a
space, which is also a lot more readable..
Also, may I suggest that we just extend the format with a robust default
value thing?
It should be reasonably easy to have just the rule:
- add a new "remote.<remote>.branch" thing that lists multiple simple
branches separated by whitespace.
- a "simple branch" is just a "implicit refspec" for the relationship
"heads/<name>:remotes/<remote>/<name>"
And then you should be able to write all of your cumbersome config options
as a simple
[remote "gitster"]
url = gitster.example.com:/home/junio/git.git/
branch = maint master next +pu
and you're all done. It would imply everything you said.
This would basically require that "git-parse-remote" be re-written as a
native builtin, because quite frankly, it would be too damn painful any
other way, but it really shouldn't be that nasty. In fact, I think we
should have done that long ago, because the shell-code is just horrid for
things like this.
For example, for builtin-push (which is currently the only thing that
parses "remote" entries in C), you'd just need to do something like the
appended.. It would generate the full refspecs from the "branch" config
automatically.
Linus
---
diff --git a/builtin-push.c b/builtin-push.c
index d23974e..805ffa8 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -123,15 +123,33 @@ static int get_remote_config(const char*
{
if (!strncmp(key, "remote.", 7) &&
!strncmp(key + 7, config_repo, config_repo_len)) {
- if (!strcmp(key + 7 + config_repo_len, ".url")) {
+ const char *subkey = key + 7 + config_repo_len;
+ if (!strcmp(subkey, ".url")) {
if (config_current_uri < MAX_URI)
config_uri[config_current_uri++] = xstrdup(value);
else
error("more than %d URL's specified, ignoring the rest", MAX_URI);
}
- else if (config_get_refspecs &&
- !strcmp(key + 7 + config_repo_len, ".push"))
- add_refspec(xstrdup(value));
+ else if (config_get_refspecs) {
+ if (!strcmp(subkey, ".push"))
+ add_refspec(xstrdup(value));
+ else if (!strcmp(subkey, ".branch")) {
+ while (isspace(*value))
+ value++;
+ while (*value) {
+ const char *end = value;
+ while (!isspace(*end))
+ end++;
+ add_refspec(xsprintf("heads/%.*s:remotes/%.*s/%.*s",
+ end-value, value,
+ config_repo_len, config_repo,
+ end-value, value));
+ while (isspace(*end))
+ end++;
+ value = end;
+ }
+ }
+ }
}
return 0;
^ 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