Junio C Hamano wrote:
> Yes, the aim of the topic should be to make the machinery flexible
> enough so that we can lose -v/-vv implementation and replace them
> with calls to the new machinery with canned set of output format
> templates.
Definitely. I don't want to keep my ugly alias around fore
Junio C Hamano wrote:
> I am having this feeling that we see more and more of this line of
> bad behaviours from some on the list recently to call something that
> is working in which they find itch using unnecessarily derogatory
> terms, and it makes people simply avoid any discussion that starts
Ramkumar Ramachandra writes:
> Duy Nguyen wrote:
>> Then "show @{p}" should show the tip commit of rr/master, not the ref
>> name.
>
> Yes, that is correct.
>
>> rev-parse (with an option, maybe) may be a better place for
>> this.
>
> Er, no. I actually want things like diff @{p}..HEAD. I want
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Duy Nguyen writes:
> On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
> wrote:
>> There is no need to use a hammer and coerce everything into an atom,
>> or throw everything out the window and start from scratch to conform
>> to pretty-formats perfectly. Let's extend the existing format to
Junio C Hamano wrote:
> That is why I rewrote it like so:
>
> The empty string '' is confusing and does not convey information
> about whose logs we are inspecting. Change this so that...
Ah, I didn't notice the rewrite in pu. Thanks.
--
To unsubscribe from this list: send the line "unsu
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> What is this meant to update? I recall rewriting this part on
>> purpose.
>
> I was being verbose to show that I handle the detached HEAD case too,
> which I missed last time.
>
>> Even though it appears unusual and invites confusion, it is
Ramkumar Ramachandra writes:
> The documentation of -S and -G is very sketchy. Completely rewrite the
> sections in Documentation/diff-options.txt and
> Documentation/gitdiffcore.txt.
>
> References:
> 52e9578 ([PATCH] Introducing software archaeologist's tool "pickaxe".)
> f506b8e (git log/diff
On Fri, 24 May 2013 17:05:26 +, Holger Hellmuth (IKS) wrote:
> Am 24.05.2013 15:42, schrieb Andreas Krey:
...
> >The branch name is almost completely meaningless. I could just
> >do my feature in my local master and never have a different name.
>
> In which case parent switching in the commit
Junio C Hamano wrote:
> What is this meant to update? I recall rewriting this part on
> purpose.
I was being verbose to show that I handle the detached HEAD case too,
which I missed last time.
> Even though it appears unusual and invites confusion, it is very
> consistent to say '' when the user
On Thu, 23 May 2013 09:01:15 +, Junio C Hamano wrote:
...
> Instead of having a nice "these six commits marked as 'x' were done
> on a branch forked some time ago, to address only this one issue and
> to address it fully" history that explains how these commits were
> related and these commits
Phil Hord writes:
> On Fri, May 24, 2013 at 5:37 AM, Ramkumar Ramachandra
> wrote:
>> Junio C Hamano wrote:
>>> [...]
>>
>> I agree with the other comments, and have made suitable changes.
>> Let's review your block now.
>>
>>> This transformation is used to find filepairs that represent
Ramkumar Ramachandra writes:
> Currently, when we try to resolve @{} or @{} when the reflog
> doesn't go back far enough, we get errors like:
>
> # on branch master
> $ git show @{1}
> fatal: Log for '' only has 7 entries.
>
> $ git show @{1.days.ago}
> warning: Log for '' only
Hi all,
thanks for all your comments. Here's an updated version of the glossary
including (hopefully) all the changes you've suggested.
Basic repository objects:
blob = Blob
tree = Baum-Objekt (bevorzugt), "Tree"-Objekt
submodule = Submodul
pack(noun)
2013/5/23 Bernhard R. Link :
> * Ralf Thielow [130522 17:17]:
>> >> remote branch = Remote-Branch
>> >> remote-tracking branch = Remote-Tracking-Branch
>> >> upstream branch= Upstream-Branch
>> >
>> > Yes. What's the main reason for using "Branch" in the German text?
Duy Nguyen wrote:
> Then "show @{p}" should show the tip commit of rr/master, not the ref
> name.
Yes, that is correct.
> rev-parse (with an option, maybe) may be a better place for
> this.
Er, no. I actually want things like diff @{p}..HEAD. I want it to be
a first-class revision, just like @
Felipe Contreras writes:
> ... but I don't see why something small like that
> wouldn't make sense:
>
> The pull was not fast-forward, please either merge or rebase.
OK, I think I got what John was getting at and this single liner
message is a good summary of it.
Instead of telling them "you ca
On Fri, May 24, 2013 at 11:15 PM, Ramkumar Ramachandra
wrote:
> Duy Nguyen wrote:
>> On Thu, May 23, 2013 at 10:12 PM, Ramkumar Ramachandra
>> wrote:
>>> Try this now: configure your current branch's pushremote to push to
>>> "refs/heads/*:refs/heads/rr/*". Now, type 'git show @{p}'. Voila!
>>
On Fri, May 24, 2013 at 6:18 PM, Ramkumar Ramachandra
wrote:
> Damn; so it's impossible to have a custom-sorted completion list in
> bash. Any idea about zsh? I know that there are completion groups,
> but I'd really like custom sorting.
I think sorting is required for faster look-up, most like
SZEDER Gábor wrote:
> I don't know who does the sorting (Bash or readline), and I don't know
> any way to disable it.
Damn; so it's impossible to have a custom-sorted completion list in
bash. Any idea about zsh? I know that there are completion groups,
but I'd really like custom sorting.
--
To u
Duy Nguyen wrote:
> On Thu, May 23, 2013 at 10:12 PM, Ramkumar Ramachandra
> wrote:
>> Try this now: configure your current branch's pushremote to push to
>> "refs/heads/*:refs/heads/rr/*". Now, type 'git show @{p}'. Voila!
>
> Voila what? Why not avoid guessing game and describe what the patch
Hi,
On Fri, May 24, 2013 at 05:03:27PM +0530, Ramkumar Ramachandra wrote:
> I'm not able to sort completions for some weird reason. No matter
> what I order I insert stuff into COMPREPLY, bash seems to auto-sort
> them lexically. I tried to pass --sort='-committerdate' to git
> for-each-ref so
(I haven't caught up with git mails lately, but the @{special}
refactoring caught my eyes..)
On Thu, May 23, 2013 at 10:12 PM, Ramkumar Ramachandra
wrote:
> Try this now: configure your current branch's pushremote to push to
> "refs/heads/*:refs/heads/rr/*". Now, type 'git show @{p}'. Voila!
V
On Fri, May 24, 2013 at 03:42:37PM +, Jim Greenleaf wrote:
> John Keeping keeping.me.uk> writes:
>
> > I wonder if this would be better as a file rather than another option to
> > git-update-index. We already have .git/info/exclude so we could add
> > .git/info/freeze or .git/info/local with
Phil Hord wrote:
> It fits the beginning of the
> document where it says this:
Ah, I missed that. Either way, I'm quite happy with v3: we can change
the first paragraph to use the word "transformation" if we really
want.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
Duy Nguyen wrote:
> Usefulness is one thing. Another is maintenance and in that regard I
> still think we should be able to remove -v and -vv code (not the
> functionality) with this topic.
Why? The topic adds good functionality, doesn't break anything,
doesn't paint us into any corner, and has u
John Keeping keeping.me.uk> writes:
> I wonder if this would be better as a file rather than another option to
> git-update-index. We already have .git/info/exclude so we could add
> .git/info/freeze or .git/info/local with the same syntax as the normal
> .gitignore file.
.git/info/freeze would
file:///path/to/repo.git/ is converted to a hyperlink while others are
not. Put a backslash to avoid the conversion. Tested with asciidoc
8.6.5.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/urls.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/urls.t
On Fri, May 24, 2013 at 03:34:26PM +, Jim Greenleaf wrote:
> Phil Hord gmail.com> writes:
>
> > The wording of --ignore-changes suffers the same lack of clarity that
> > --assume-unchanged does.
> > What's better? --sequester is probably too obscure. Maybe --hold.
> > Or --silence. Or --sh
Phil Hord gmail.com> writes:
> The wording of --ignore-changes suffers the same lack of clarity that
> --assume-unchanged does.
> What's better? --sequester is probably too obscure. Maybe --hold.
> Or --silence. Or --shut-up.
How about --freeze?
--
To unsubscribe from this list: send the l
On Fri, May 24, 2013 at 9:19 PM, Ramkumar Ramachandra
wrote:
> There is no need to use a hammer and coerce everything into an atom,
> or throw everything out the window and start from scratch to conform
> to pretty-formats perfectly. Let's extend the existing format to be
> _useful_ sensibly.
Us
On Thu, May 23, 2013 at 7:20 PM, Junio C Hamano wrote:
> Thomas Rast writes:
>
>>> What are the workflows that are helped if we had such a bit? If
>>> we need to support them, I think you need a real --ignore-changes
>>> bit, not an abuse of --assume-unchanged.
>>
>> I gather -- from #git -- tha
Am 24.05.2013 15:42, schrieb Andreas Krey:
On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote:
...
Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that
is updated)
The branch name is almost
On Fri, May 24, 2013 at 5:37 AM, Ramkumar Ramachandra
wrote:
> Junio C Hamano wrote:
>> [...]
>
> I agree with the other comments, and have made suitable changes.
> Let's review your block now.
>
>> This transformation is used to find filepairs that represent
>> two kinds of change
- Original Message -
> From: "Thomas Rast"
> Sent: Thursday, May 23, 2013 6:56:50 PM
> Subject: Re: git stash deletes/drops changes of
>
> Junio C Hamano writes:
>
> > Thomas Rast writes:
> >
> > > So maybe it would be time to first make up our minds as to what
> > > --assume-unchanged
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by the contrib/completion/git-prompt.sh).
Now you can use the following format in for-each-ref:
%C(red)%(HEAD)%C(reset)
%C(green)%(refname:short)%C(
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend the format with
%(HEAD) to do exactly the same thing.
Now you can use the following format in for-each-ref:
%C(red)%(HEAD)%C(reset) %C(green)%(refname:short)%C(reset)
to di
So, while investigating alignment operators in pretty-formats, I found
out that it's way too much effort and totally not worth it (atleast
not immediately; we can add it later if we want). What I want now is
a useable git-branch output. And I think I can say that I've achieved
it.
I currently ha
Since 'git branch' misses important options like --sort, --count, and
--format that are present in 'git for-each-ref'. Until we are in a
position to fix 'git branch', let us enhance the 'git for-each-ref'
format so it can atleast colorize output.
You can use the following format in for-each-ref:
On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote:
...
> Here is an idea (probably already discussed in the long history of git):
> 1) the branch name is recorded in a commit (for merges the branch that
> is updated)
The branch name is almost completely meaningless. I could just
do
Felipe Contreras wrote:
> git push branch@{push}
>
> Is not clear at all: push push of branch?
We can pick the name later. I had to pick a name to write code, and
that happens to be @{push}.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@
On Thu, May 23, 2013 at 10:12 AM, Ramkumar Ramachandra
wrote:
> Introduce an AT_KIND_PUSH to be represented as "@{p[ush]}". Determine
> it using branch.remote.push_refspec.
I think the semantics of this don't make any sense.
git push branch@{upstream}
Is very clear: push upstream of branch.
On Fri, May 24, 2013 at 6:33 AM, Ramkumar Ramachandra
wrote:
> Hi,
>
> I'm not able to sort completions for some weird reason. No matter
> what I order I insert stuff into COMPREPLY, bash seems to auto-sort
> them lexically. I tried to pass --sort='-committerdate' to git
> for-each-ref so I can
On Fri, May 24, 2013 at 01:03:22PM +0200, Petr Baudis wrote:
> On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote:
> > So that it continues to Just Work for people using buildroot but you can
> > create Makefile.config to override those defaults.
>
> Indeed, that doesn't cover some cor
On Fri, May 24, 2013 at 5:52 PM, "Ákos, Tajti" wrote:
> Dear List,
>
> I created a dump from a repository. git bundle list-heads prints all the
> refs I meant to add. The problem is that after exracting the dump with git
> bundle unbundle the target repository doesn't contain any branches (git
> b
Hi,
I'm not able to sort completions for some weird reason. No matter
what I order I insert stuff into COMPREPLY, bash seems to auto-sort
them lexically. I tried to pass --sort='-committerdate' to git
for-each-ref so I can get a sensible 'git checkout ' reply, and
I'm very annoyed that it doesn'
On Fri, May 24, 2013 at 11:40:18AM +0100, John Keeping wrote:
> So that it continues to Just Work for people using buildroot but you can
> create Makefile.config to override those defaults.
Indeed, that doesn't cover some corner cases of (c), but that's not a
big deal in practice I guess.
My
Dear List,
I created a dump from a repository. git bundle list-heads prints all the
refs I meant to add. The problem is that after exracting the dump with
git bundle unbundle the target repository doesn't contain any branches
(git branch -a prints nothing). How can we exract a dump so that the
On Fri, May 24, 2013 at 12:14:16PM +0200, Petr Baudis wrote:
> On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote:
> > I don't see anything wrong with having a template file documenting the
> > parameters, but I think it's important that there are sensible defaults
> > in place when the u
The documentation of -S and -G is very sketchy. Completely rewrite the
sections in Documentation/diff-options.txt and
Documentation/gitdiffcore.txt.
References:
52e9578 ([PATCH] Introducing software archaeologist's tool "pickaxe".)
f506b8e (git log/diff: add -G that greps in the patch text)
Inpu
[1/2] replaces "pickaxe regex" with "regex", as suggested by Junio.
[2/2] is now co-authored by Junio. I've taken what I think are the
best changes introduced by both versions and merged them. The
inter-diff follows.
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
i
Currently, diffcore-pickaxe reports two distinct errors for the same
user error:
$ git log --pickaxe-regex -S'\1'
fatal: invalid pickaxe regex: Invalid back reference
$ git log -G'\1' # --pickaxe-regex is implied
fatal: invalid log-grep regex: Invalid back reference
Since the err
On Fri, May 24, 2013 at 11:06:12AM +0100, John Keeping wrote:
> I don't see anything wrong with having a template file documenting the
> parameters, but I think it's important that there are sensible defaults
> in place when the user's configuration file does not specify a value for
> a parameter.
On Fri, May 24, 2013 at 11:40:07AM +0200, Petr Baudis wrote:
> On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote:
> > On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
> > > Just to clear up on what the best practice is, I'd imagine the setup
> > > to be something like:
> >
On Fri, May 24, 2013 at 09:22:53AM +0100, John Keeping wrote:
> On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
> > Just to clear up on what the best practice is, I'd imagine the setup
> > to be something like:
> >
> > (a) Makefile contains inclusion of Makefile.include.
> >
>
On Fri, May 24, 2013 at 4:29 AM, John Keeping wrote:
[snip]
> Note that in my email that started this, I tried to be clear that I was
> talking about "git pull" *without a branch name*. If this user
> explicitly says "git pull remote branch" then I consider that a clear
> indication that they rea
Junio C Hamano wrote:
> [...]
I agree with the other comments, and have made suitable changes.
Let's review your block now.
> This transformation is used to find filepairs that represent
> two kinds of changes, and is controlled by the -S, -G and
> --pickaxe-all options.
Am 23.05.2013 21:25, schrieb Andreas Krey:
On Thu, 23 May 2013 11:06:57 +, Andreas Krey wrote:
...
...
Don't do that, then.
Ouch, you're right. The problem is not actually in the
pull; only the *last* pull into a feature branch that
then get pushed back ff to master needs to be reversed.
On Thu, May 23, 2013 at 06:53:36PM -0500, Felipe Contreras wrote:
> The alternatives are these:
>
> a) you annoy the vast majority of the user-base by making 'git pull' a
> dangerous operation that should be avoided, and replaced with 'git
> fetch'+'git rebase'.
>
> b) you annoy a minority of the
On Fri, May 24, 2013 at 01:57:12AM +0200, Petr Baudis wrote:
> Just to clear up on what the best practice is, I'd imagine the setup
> to be something like:
>
> (a) Makefile contains inclusion of Makefile.include.
>
> (b) There is a file like Makefile.include.template containing
>
Currently, when we try to resolve @{} or @{} when the reflog
doesn't go back far enough, we get errors like:
# on branch master
$ git show @{1}
fatal: Log for '' only has 7 entries.
$ git show @{1.days.ago}
warning: Log for '' only goes back to Tue, 21 May 2013 14:14:45 +0530.
Currently, when no (valid) upstream is configured for a branch, you get
an error like:
$ git show @{u}
error: No upstream configured for branch 'upstream-error'
error: No upstream configured for branch 'upstream-error'
fatal: ambiguous argument '@{u}': unknown revision or path not in the w
[1/2] clarifies the commit message to say that a grep didn't find
"@{u}" or "@{upstream}" hard-coded by any callers. Thanks to Junio.
[2/2] fixes a small grammar error in the commit message. Thanks to
Eric Sunshine.
Ramkumar Ramachandra (2):
sha1_name: fix error message for @{u}
sha1_name:
101 - 163 of 163 matches
Mail list logo
