Hi,
I did a series of commits and now I find one of my commit (not the topmost one)
has an incorrect commit message. How can I change that specific one? I believe
git commit --amend works only for the last commit.
Thanks,
Norah Jones
--
To unsubscribe from this list: send the line
Am 04.05.2013 00:46, schrieb Martin Langhoff:
I am building a small git wrapper around puppet, and one of the
actions it performs is auto-fastforwarding of branches without
checking them out.
In simplified code... we ensure that we are on a head called master,
and in some cases ppg commit,
Hi,
I have been looking for such a command/option and no one gave me
sufficient answer. So this message should be considered as a feature
request. I had a situation where I had staged a file with a problem
solution in it, then I wanted to experiment with a different solution
so I had to revert
On Sat, May 4, 2013 at 8:31 AM, Norah Jones nh.jone...@gmail.com wrote:
Hi,
I did a series of commits and now I find one of my commit (not the topmost
one) has an incorrect commit message. How can I change that specific one? I
believe git commit --amend works only for the last commit.
On Thu, May 2, 2013 at 10:09 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
We probably should fix those, but that is orthogonal to the '@' shortcut.
We can have the '@' shortcut *today*, with minimal changes to the code
and the documentation, in a limited and
On Sat, May 4, 2013 at 1:10 AM, David Aguilar dav...@gmail.com wrote:
On Thu, May 2, 2013 at 10:09 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
We probably should fix those, but that is orthogonal to the '@' shortcut.
We can have the '@' shortcut *today*, with
On 05/04/2013 02:31 AM, Felipe Contreras wrote:
Turns out fast-export throws bad 'reset' commands because of a behavior
in transport-helper that is not even needed.
We should ignore them, otherwise we will threat
s/threat/treat/
them as branches and fail.
This was fixed in v1.8.2, but
Junio C Hamano gits...@pobox.com writes:
* jn/config-ignore-inaccessible (2013-04-15) 1 commit
- config: allow inaccessible configuration under $HOME
When $HOME is misconfigured to point at an unreadable directory, we
used to complain and die. This loosens the check.
I do not think we
Dimitar Bonev dsbo...@gmail.com writes:
I have been looking for such a command/option and no one gave me
sufficient answer. So this message should be considered as a feature
request. I had a situation where I had staged a file with a problem
solution in it, then I wanted to experiment with a
I think if there was such a command, it could well be common, at least
for me. I am somewhat surprised that from the three combinations of
resetting index and working dir's states of a file this is the one
that is missing (it is missing at commit level also for what is
worth). Summary table of
On Sat, May 4, 2013 at 3:34 AM, Johannes Sixt j...@kdbg.org wrote:
You mean refs/heads/master and != here because -ne is numeric
comparison in a shell script.
thanks! Yeah, I fixed those up late last night :-)
Since git 1.8.0 you can express this check as
if git merge-base --is-ancestor
[joining the discussion late; was travelling]
Duy Nguyen wrote:
git co long-branch-name
git diff A/@
git reset --hard A/@
In this form, this looks highly inconsistent. You have to decide if
you want @ to resolve to the current branch name or HEAD. Our current
@-proposal makes @@{1} display
On Sat, May 4, 2013 at 7:35 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
[snip]
When I do git pull, git is careful to only update the branch I have
checked out (if appropriate). It leaves any other branches that track
branches on the remote that has just been fetched untouched. I always
Sparse issues an 'sole_interesting' not declared. Should it be static?
warning. In order to suppress the warning, since this symbol does not
need more than file visibility, we simply add the static modifier to
its declaration.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi Kevin,
On 04/05/2013 20:25, Ramsay Jones wrote:
Sparse issues an 'sole_interesting' not declared. Should it be static?
warning. In order to suppress the warning, since this symbol does not
need more than file visibility, we simply add the static modifier to
its declaration.
Thanks! I'll include that
Dimitar Bonev wrote:
@ThomasRast: 'git show HEAD:targetfile targetfile' was proposed in
the both links that I provided in the email that your replied to, but
this introduces external dependency to the command interpreter to
output the file unmodified but not every interpreter does this.
Martin Langhoff wrote:
On Sat, May 4, 2013 at 3:34 AM, Johannes Sixt j...@kdbg.org wrote:
Since git 1.8.0 you can express this check as
if git merge-base --is-ancestor $production_sha1 refs/heads/master
Ah, that's great! Unfortunate it's not there in earlier / more widely
used releases
Felipe Contreras felipe.contre...@gmail.com writes:
This updates the parse_object() moved by the previous patch. At this
point in the codeflow, unlike the original, we already _know_ the
object must be a commit; wouldn't an equivalent of:
object = (lookup_commit(sha1)-object)
be
Thomas Rast tr...@inf.ethz.ch writes:
So for one thing, ha ha we told you so is not an extremely
satisfactory answer, especially since we only told them so with the
recent doc update. Wouldn't a stern warning or even an early error be
better?
Sorry, I am not sure exactly what alternative
Thomas Rast tr...@inf.ethz.ch writes:
I have been looking for such a command/option and no one gave me
sufficient answer. So this message should be considered as a feature
request. I had a situation where I had staged a file with a problem
solution in it, then I wanted to experiment with a
Junio C Hamano gits...@pobox.com writes:
I have something worth saving, better than HEAD in some way
(e.g. contains fixes), in my index. I want to keep it while I
experiment an approach that is unrelated to it, so I want a clean
slate in the working tree from HEAD without disturbing the
Thomas Rast wrote:
Junio C Hamano gits...@pobox.com writes:
* jn/config-ignore-inaccessible (2013-04-15) 1 commit
- config: allow inaccessible configuration under $HOME
When $HOME is misconfigured to point at an unreadable directory, we
used to complain and die. This loosens the check.
On 02/05/2013 23:05, Junio C Hamano wrote:
Z...A===X---o---o---B
\\/
W---Y
OK, I think I understand it, and we are in agreement. For the
purpose of the above paragraph, a side branch is what is not on the
--ancestry-path, so all of the below examples
Ramkumar Ramachandra artag...@gmail.com writes:
On Matthieu's note, I have a comment: symbolic refs are an absolute
dead end. We didn't think of it from the start, and it's too late
now. Do NOT go there: from my investigation, I believe that hooking
up everything to the revision parser is
On Sat, May 4, 2013 at 9:48 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Is there no way to convince PowerShell to treat the output of a
command as binary data with no particular encoding?
The best I could find out is to pipe the output to set-content:
git show HEAD:targetfile | set-content
When expanding shorthand refs to full ref names (e.g. in dwim_ref()),
we use the ref_rev_parse_rules list of expansion patterns. This list
allows origin to be expanded into refs/remotes/origin/HEAD, by
using the refs/remotes/%.*s/HEAD pattern from that list.
shorten_unambiguous_ref() exists to
Some users are interested in fetching remote refs into a separate namespace
in the local repo. E.g. instead of the usual remote config:
[remote origin]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ...
they want to keep remote tags separate from local tags, and they may
This test verifies that the following expressions all evaluate to the
full refname refs/remotes/origin/heads/master:
- refs/remotes/origin/heads/master
- remotes/origin/heads/master
- origin/heads/master
- origin/master
Currently the last of these fail, because the $remote/$branch syntax
In preparation for allowing alternative ways of expanding shorthand refs
(like master) into full refnames (like refs/heads/master): Expand
the current ref_rev_parse_rules list into ref_expand_rules, a list of
struct ref_expand_rule objects that encode both an expansion pattern
(e.g.
shorten_unambiguous_ref() provides the reverse functionality to the
expansion of shorthand names into full refnames, i.e. it takes a full
refname (like refs/heads/master), and matches it against a pattern
(like refs/heads/%.*s) to produce a shorthand name (like master).
Being the last remaining
The $remote/$branch expression is often used as a shorthand with the
intention of referring to the remote-tracking branch corresponding to
the given $branch in the $remote repo.
Currently, Git resolves this by prepending refs/remotes/ to the given
$remote/$branch expression, resulting in
Jonathan Nieder jrnie...@gmail.com writes:
Thomas Rast wrote:
Junio C Hamano gits...@pobox.com writes:
* jn/config-ignore-inaccessible (2013-04-15) 1 commit
- config: allow inaccessible configuration under $HOME
When $HOME is misconfigured to point at an unreadable directory, we
used
Johan Herland jo...@herland.net writes:
The $remote/$branch syntax can be interpreted in two subtly different
ways:
1. A shorthand name for the remote-tracking branch corresponding to a
specific $branch from a specific $remote.
2. A refname fragment, which - when appended to
$ git rev-list --count v3.2..master
9651
$ git rev-list --count v3.3..master
6378
$ git describe --tags master
v3.2-9651-ga018267
I would have expected to see v3.3-6378-ga018267, given the documentation:
If multiple tags were found during the walk then the tag which has the
fewest commits
34 matches
Mail list logo
