Ramkumar Ramachandra wrote:
> you'd essentially have to grab the remote..push refspec, rewrite
> it to replace refs/heads/*: with $HEAD: and feed that refspec to the
> transport layer
Um, sorry. It involves two independent steps:
1. add_refspec() $HEAD:$HEAD@{push} to feed to the transport layer
On Thu, May 23, 2013 at 7:25 PM, Felipe Contreras
wrote:
> On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano wrote:
>> Linus Torvalds writes:
>>
>>> It would be a *horrible* mistake to make "rebase" the default, because
>>> it's so much easier to screw things up that way.
>>>
>>> That said, making
On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano wrote:
> Linus Torvalds writes:
>
>> It would be a *horrible* mistake to make "rebase" the default, because
>> it's so much easier to screw things up that way.
>>
>> That said, making "no-ff" the default, and then if that fails, saying
>>
>>The
On Thu, May 23, 2013 at 5:21 PM, Junio C Hamano wrote:
>
> I would assume that "no-ff" above was meant to be "--ff-only" from
> the first part of the message.
Yeah, I may need more coffee..
> I also would assume that I can rephrase that setting pull.merge
> (which does not exist) as setting pull
On Thu, May 23, 2013 at 6:47 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> If the change in HEAD^ in the above example were to copy the whole A
>>> and C from a different file, then your !found_guilty logic would
>>> kick in and say all lines of A where copied from elsewhere in HEAD^
Linus Torvalds writes:
> It would be a *horrible* mistake to make "rebase" the default, because
> it's so much easier to screw things up that way.
>
> That said, making "no-ff" the default, and then if that fails, saying
>
>The pull was not a fast-forward pull, please say if you want to
> mer
Hi!
On Fri, May 24, 2013 at 12:56:50AM +0200, Thomas Rast wrote:
> > It is not --ignore-changes bit, and has never been.
Indeed, it has been my lack of imagination regarding what can go
wrong. I am fine with the changes not being shown in `git diff` and even
not so worried about them being ov
On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano wrote:
>
> If the proposal were to make pull.rebase the default at a major
> version bump and force all integrators and other people who are
> happy with how "pull = fetch + merge" (not "fetch + rebase") works
> to say "pull.rebase = false" in their
On Thu, May 23, 2013 at 6:26 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
> Unless your primary user base is those who use Git as a deployment
> tool to always follow along the tip of some external repository
> without doing anything on your own on the branch you run your "g
Felipe Contreras writes:
>> If the change in HEAD^ in the above example were to copy the whole A
>> and C from a different file, then your !found_guilty logic would
>> kick in and say all lines of A where copied from elsewhere in HEAD^,
>> but again we would not learn the same information for C.
Hello!
This [has been reported][1] to this list about half a year ago
but with no response so I'm not even sure if it's been
acknowledged as bug.
[1]: http://marc.info/?l=git&m=135215709307126&q=raw
When I use `git log --follow file` all is OK, but once I add
`--reverse` to it, it no longer f
Felipe Contreras writes:
Unless your primary user base is those who use Git as a deployment
tool to always follow along the tip of some external repository
without doing anything on your own on the branch you run your "git
pull" on, defaulting it to --ff-only does not make muc
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 -- that it's mostly used for config files, which
> have an annoying ha
On Thu, May 23, 2013 at 5:54 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano wrote:
>>> John Keeping writes:
>>>
This isn't about "swap parents", it's about helping people realise that
just "git pull" isn't necessarily the best
On Thu, May 23, 2013 at 5:44 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> Then in that "next iteration", we pick blame entry for A and decide
>>> to see if HEAD^, which is the suspect for A, can be exonerated of
>>> blames for _any_ (not just A) blame entry it currently is suspected
Junio C Hamano writes:
> Thomas Rast writes:
>
>> So maybe it would be time to first make up our minds as to what
>> --assume-unchanged should actually mean:
>>
>> * Ignore changes to a tracked file, but treat them as valuable. In
>> this case we'd have to make sure that failures like git-sta
Felipe Contreras writes:
> On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano wrote:
>> John Keeping writes:
>>
>>> This isn't about "swap parents", it's about helping people realise that
>>> just "git pull" isn't necessarily the best thing for them to do, and
>>> that they may want --rebase.
>>>
Thomas Rast writes:
> So maybe it would be time to first make up our minds as to what
> --assume-unchanged should actually mean:
>
> * Ignore changes to a tracked file, but treat them as valuable. In
> this case we'd have to make sure that failures like git-stash's are
> handled properly.
>
On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano wrote:
> John Keeping writes:
>
>> This isn't about "swap parents", it's about helping people realise that
>> just "git pull" isn't necessarily the best thing for them to do, and
>> that they may want --rebase.
>>
>> So I was asking if it would be s
Felipe Contreras writes:
>> Then in that "next iteration", we pick blame entry for A and decide
>> to see if HEAD^, which is the suspect for A, can be exonerated of
>> blames for _any_ (not just A) blame entry it currently is suspected
>> for. We call pass_blame() and it will find and process bo
John Keeping writes:
> This isn't about "swap parents", it's about helping people realise that
> just "git pull" isn't necessarily the best thing for them to do, and
> that they may want --rebase.
>
> So I was asking if it would be sensible (possibly in Git 2.0) to make
> git-pull pass --ff-only
Jim Greenleaf writes:
> Adeodato Simó net.com.org.es> writes:
>
>> I was unpleasantly surprised to discover yesterday that doing `git
>> stash` on a repository where I had previously run `git update-index
>> --assume-unchanged FOO` completely lost all changes I had in file FOO.
>
> I just ran in
On Thu, May 23, 2013 at 4:55 PM, John Keeping wrote:
> So I was asking if it would be sensible (possibly in Git 2.0) to make
> git-pull pass --ff-only to git-merge by default.
Definitely yes.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a
On Thu, May 23, 2013 at 4:52 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> Imagine that your scoreboard originally has three blocks of text
>>> (i.e. blame_entry) A, B, and C, and the current suspect for A and C
>>> are the same, while we already know what the final guilty party for
On Thu, May 23, 2013 at 02:01:39PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > I have to wonder how often "git pull" with no arguments actually does
> > what users really want (even if they don't know it!) when it doesn't
> > result in a fast-forward (and pull.rebase isn't configure
Felipe Contreras writes:
>> Imagine that your scoreboard originally has three blocks of text
>> (i.e. blame_entry) A, B, and C, and the current suspect for A and C
>> are the same, while we already know what the final guilty party for
>> B is (which may be some descendant of the "suspect").
>
> I
On Thu, May 23, 2013 at 02:27:59PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> >> Is $author already sanitized at this point in the code? I see it
> >> was unwrapped with unquote_rfc2047 after it was read from the From:
> >> line; will it always be the same as sanitize_addres
On Thu, May 23, 2013 at 11:54 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
>> wrote:
>>> On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano wrote:
Felipe Contreras writes:
>> IIRC, git-gui runs two blames, one without a
"Michael S. Tsirkin" writes:
>> Is $author already sanitized at this point in the code? I see it
>> was unwrapped with unquote_rfc2047 after it was read from the From:
>> line; will it always be the same as sanitize_address($author) would
>> return, and if not, would you rather compare between s
On Thu, May 23, 2013 at 02:19:40PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, May 23, 2013 at 11:05:00AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > Looks like push can't resolve tags to commits.
> >> > Why is that?
> >>
> >> How el
"Michael S. Tsirkin" writes:
> It's a tag and not a branch since I need to sign the tag.
> I push to a branch and not just the tag since this way
> people can track it and do downstream development on top.
> So pushing the tag to branch would save me some churn.
It seems our messages crossed.
E
"Michael S. Tsirkin" writes:
> On Thu, May 23, 2013 at 11:05:00AM -0700, Junio C Hamano wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > Looks like push can't resolve tags to commits.
>> > Why is that?
>>
>> How else would you push a tag out?
>
> Well my reaction is, it seems to figure out it ne
On Thu, May 23, 2013 at 12:52:11PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > When patch sender's name has special characters,
> > git send-email did not quote it before matching
> > against the author name.
> > As a result it would produce mail like this:
> >
> > Date:
On Thu, May 23, 2013 at 11:10:32AM -0700, Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > On Thu, May 23, 2013 at 5:53 AM, Michael S. Tsirkin wrote:
> >> Looks like push can't resolve tags to commits.
> >> Why is that?
> >>
> >> linux$ git push -f $PWD v3.10-rc2:refs/heads/vhost-next
> >
On Thu, May 23, 2013 at 11:05:00AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Looks like push can't resolve tags to commits.
> > Why is that?
>
> How else would you push a tag out?
Well my reaction is, it seems to figure out it needs a commit and then
instead of just gett
"Michael S. Tsirkin" writes:
> On Thu, May 23, 2013 at 11:10:32AM -0700, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>> > On Thu, May 23, 2013 at 5:53 AM, Michael S. Tsirkin
>> > wrote:
>> >> Looks like push can't resolve tags to commits.
>> >> Why is that?
>> >>
>> >> linux$ git pus
On Thu, May 23, 2013 at 11:10:32AM -0700, Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > On Thu, May 23, 2013 at 5:53 AM, Michael S. Tsirkin wrote:
> >> Looks like push can't resolve tags to commits.
> >> Why is that?
> >>
> >> linux$ git push -f $PWD v3.10-rc2:refs/heads/vhost-next
> >
John Keeping writes:
> I have to wonder how often "git pull" with no arguments actually does
> what users really want (even if they don't know it!) when it doesn't
> result in a fast-forward (and pull.rebase isn't configured).
If you are in a totally centralized shared repository mindset
without
On Thu, 23 May 2013 12:01:43 +, Brett Trotter wrote:
> In my work, we have a lot of autogenerated files that need to exist so
> a script will replace their contents, but tracking the contents
> creates a lot of unnecessary conflicts. I would love to see an option
> for a different tracking meth
My use-case is an invalid SSL certificate. Pulling from the wiki with a
recent version of libwww-perl fails, and git-remote-mediawiki gave no
clue about the reason. Give the mediawiki API detailed error message, and
since it is not so informative, hint the user about an invalid SSL
certificate on h
Junio C Hamano writes:
>> +my $sanitized_sender = sanitize_address($sender);
>> +if (defined $author and $author ne $sanitized_sender) {
>> $message = "From: $author\n\n$message";
>> if (defined $author_encoding) {
>> if ($has_content_type) {
"Michael S. Tsirkin" writes:
> When patch sender's name has special characters,
> git send-email did not quote it before matching
> against the author name.
> As a result it would produce mail like this:
>
> Date: Thu, 23 May 2013 16:36:00 +0300
> From: "Michael S. Tsirkin"
> T
On Thursday, May 23, 2013 07:01:43 am you wrote:
>
> I'm running a rather special configuration, basically i
> have a gerrit server pushing
...
> I have found "git receive-pack"s that has been running
> for days/weeks without terminating
>
...
> Anyone that has any clues about what could be
On Thu, 23 May 2013 07:45:34 +, Junio C Hamano wrote:
...
> Even with 'mv', between the time the main in mv starts and the
> process finally issues rename(2) on the directory, you can start
> running what competes and interferes with it in another terminal,
> so it does not fundamentally change
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.
And at that time you don't know it's the
Theodore Ts'o writes:
> Spekaing of which, what I'd really appreciate is timestamps associated
> with the reflog. That's because the most common time when I've
> screwed something up is after doing a "git rebase -i" and so the
> reflog has a *huge* number of entries on it, and figuring out which
Theodore Ts'o wrote:
> Spekaing of which, what I'd really appreciate is timestamps associated
> with the reflog. That's because the most common time when I've
> screwed something up is after doing a "git rebase -i" and so the
> reflog has a *huge* number of entries on it, and figuring out which
>
Theodore Ts'o writes:
> On Wed, May 22, 2013 at 11:55:00AM -0700, Junio C Hamano wrote:
>> But in a triangular workflow, the way to make the result reach the
>> "upstream" is *not* by pushing there yourself. For developers at
>> the leaf level, it is to push to their own repository (often on
>>
On Thu, May 23, 2013 at 03:22:50PM +0530, Ramkumar Ramachandra wrote:
> Theodore Ts'o wrote:
> > Right now I do this just by being careful, but if there was an
> > automatic safety mechanism, it would save me a bit of work, since
> > otherwise I might not catch my mistake until I do the "git push
>
Junio C Hamano writes:
> Users of full-output may want to be able to see the same thing.
... but I agree we may be able to cheat if we only want to support
interactive, and we do want to find a way to cheat when we are
running interactive without having to store much more information in
each bla
* 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?
> > Consistency
> > with the command
Felipe Contreras writes:
> On Thu, May 23, 2013 at 5:53 AM, Michael S. Tsirkin wrote:
>> Looks like push can't resolve tags to commits.
>> Why is that?
>>
>> linux$ git push -f $PWD v3.10-rc2:refs/heads/vhost-next
>
> Perhaps v3.10-rc2^{}. Yeah, totally and completely not-user-friendly,
More co
"Michael S. Tsirkin" writes:
> Looks like push can't resolve tags to commits.
> Why is that?
How else would you push a tag out?
--
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/m
Michael Haggerty writes:
> 1. The function name gc_boundary() suggests that it will do a garbage
> collection unconditionally. In fact, it might or might not depending on
> this test. At the caller, this made it look like a gc was happening
> each time through the loop, which made me nervous ab
Antoine Pelisse writes:
> I'm really not convinced this kind of changes should make it into
> Junio's tree (of course, he's the only one to decide). I really
> believe this is a very specific solution to a very specific problem
> (that is not for me to judge if the problem is real). Bloating the
Junio C Hamano wrote:
> I am not saying default=single would be _the_ single right way to
> solve it, but "when you have default=single, remote.$name.push is
> used only to describe the mapping, not forcing you to push
> everything out at once" is one possible solution to that.
The big advantage i
Michael J Gruber writes:
> Well, if we decide "showing blobs with textconv is fundamentally
> different from showing diffs with textconv" then "--textconv" should not
> apply any textconv filters on blobs unless the user has specified them
> using a separate attribute (different from "diff").
I
Ramkumar Ramachandra writes:
> [remote "theodore"]
> push = master
> push = +pu
>
> This means that I will always push master without force and pu with
> force, irrespective of the branch I'm on.
>
> [remote "origin"]
> push = refs/heads/*:refs/heads/rr/*
>
> This means that I will al
Michael Haggerty writes:
> It seems to me that
>
> git rev-list --first-parent --ancestry-path A..B
>
> is well-defined and should list the commits in the intersection between
>
> git rev-list --first-parent A..B
>
> and
>
> git rev-list--ancestry-pa
Michael Haggerty writes:
> On 05/21/2013 07:34 PM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>>
>>> Signed-off-by: Michael Haggerty
>>> ---
>>> revision.c | 20 ++--
>>> revision.h | 32 +---
>>> 2 files changed, 35 insertions(+), 17 deletio
Felipe Contreras writes:
> On Wed, May 22, 2013 at 10:23 PM, Felipe Contreras
> wrote:
>> This doesn't make any sense:
>
> Ah, never mind, it's COPYING the one being modified, not EXTRACTING.
Yes.
The different levels of -C happens to correspond to the software
engineering practice from best t
In my work, we have a lot of autogenerated files that need to exist so
a script will replace their contents, but tracking the contents
creates a lot of unnecessary conflicts. I would love to see an option
for a different tracking method that just makes sure a file or
directory exists. This would al
Adeodato Simó net.com.org.es> writes:
> I was unpleasantly surprised to discover yesterday that doing `git
> stash` on a repository where I had previously run `git update-index
> --assume-unchanged FOO` completely lost all changes I had in file FOO.
I just ran into this today.
Was a decision ab
Felipe Contreras writes:
> On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
> wrote:
>> On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
> IIRC, git-gui runs two blames, one without any -C and one with (I do
> not offhand recall how many -C it u
On Thu, May 23, 2013 at 09:01:15AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > I've been annoyed by this at $DAYJOB recently. A lot of people seem to
> > blindly "git pull" without much thought about how the history is ending
> > up and what they actually want to do.
>
> I think t
John Keeping writes:
> I've been annoyed by this at $DAYJOB recently. A lot of people seem to
> blindly "git pull" without much thought about how the history is ending
> up and what they actually want to do.
I think these two are essentially the same thing, and having an
option to flip the head
Am 23.05.2013 14:44, schrieb Joel Kaasinen:
[pseudo:~/tmp]% git --version
git version 1.7.10.4
[pseudo:~/tmp]% git init git-test
Initialized empty Git repository in/home/opqdonut/tmp/git-test/.git/
[pseudo:~/tmp]% cd git-test
[pseudo:~/tmp/git-test:master()]% mkdir -p a/data
[pseudo:~/tmp/git-tes
Junio C Hamano venit, vidit, dixit 23.05.2013 16:40:
> Michael J Gruber writes:
>
>> Didn't you have concerns about storing the context in the object struct?
>> I can't quite judge how much of an issue this can be for fsck and such.
>> I don't want to increase the memory footprint unnecessarily,
We need it.
Signed-off-by: Ramkumar Ramachandra
---
remote.c | 2 +-
remote.h | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index 99c44da..9ae1fc5 100644
--- a/remote.c
+++ b/remote.c
@@ -1168,7 +1168,7 @@ static int match_explicit_refs(struct ref *sr
The first caller get_sha1_basic() just wants to make sure that no
non-numerical @{...} form was matched, so that it can proceed with
processing numerical @{...} forms. Since we're going to introduce more
non-numerical @{...} forms, replace this upstream_mark() call with a
call to at_mark() passing
Try this now: configure your current branch's pushremote to push to
"refs/heads/*:refs/heads/rr/*". Now, type 'git show @{p}'. Voila!
It currently only works when:
1. remote..push is explicitly specified.
2. There is a pattern to match (*).
Proof-of-concept only.
Signed-off-by: Ramkumar Ramac
Introduce an AT_KIND_PUSH to be represented as "@{p[ush]}". Determine
it using branch.remote.push_refspec.
Signed-off-by: Ramkumar Ramachandra
---
sha1_name.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 106716e..5f6958b 1006
Currently, the only non-numerical @{...} expression we support is
@{u[pstream]}. Since we're slowly growing git to support triangular
workflows, it might make sense to have a @{p[ush]} and various other
special @{...} expressions in the future. To prepare for this, abstract
out the upstream_mark(
parse_fetch_refspec() is already available to other callers via
remote.h. There's no reason why parse_push_refspec() shouldn't be.
Signed-off-by: Ramkumar Ramachandra
---
remote.c | 2 +-
remote.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index 68e
Currently interpret_branch_name() tries to parse various things, and
finally falls back to parsing @{u[pstream]}. It dies if the
input string contained an "@{u[pstream]}" but an upstream could not be
found. The logic can be generalized to check for any branch property
after branch_get(). In prep
[7/7] is the meat. Sorry it's in such a messy state: I was having a
field day tracing what push is actually doing. Anyway, I wanted to
send out the series now to get early feedback.
In other news: why on earth is push doing _so_ much processing before
pushing? Is it written very badly, or am I
Ramkumar Ramachandra writes:
> I would argue that there is something to "fix", but that fix involves
> making the cp a purely atomic operation which is super-complicated,
> and totally not worth it. Would you _not_ like the above example to
> work?
No. I do not think I like the above example t
Andreas Krey writes:
> On Thu, 23 May 2013 13:25:55 +, Ramkumar Ramachandra wrote:
>> Junio C Hamano wrote:
>> > I have "largedir" I want to get rid of, but there is a directory
>> > I want to save, "largedir/precious", in it, so I do
>> >
>> > cp -R largedir/precious precious
Michael J Gruber writes:
> Didn't you have concerns about storing the context in the object struct?
> I can't quite judge how much of an issue this can be for fsck and such.
> I don't want to increase the memory footprint unnecessarily, of course.
Yes. I thought I had a weather-balloon patch to
On Thu, May 23, 2013 at 03:34:11PM +0200, Thomas Rast wrote:
> ec9 (push: Add support for pre-push hooks, 2013-01-13) forgot to
> add a note to git-push(1) about the new --no-verify option.
>
> Signed-off-by: Thomas Rast
Thanks. FWIW
Reviewed-by: Michael S. Tsirkin
> ---
>
> Junio repli
When patch sender's name has special characters,
git send-email did not quote it before matching
against the author name.
As a result suppress_cc = self did not work:
sender is still Cc'd.
Fix by sanitizing before matching to patch author name.
Signed-off-by: Michael S. Tsirkin
---
git-send-ema
When patch sender's name has special characters,
git send-email did not quote it before matching
against the author name.
As a result it would produce mail like this:
Date: Thu, 23 May 2013 16:36:00 +0300
From: "Michael S. Tsirkin"
To: qemu-de...@nongnu.org
Cc: "Mi
Hi,
I'm running a rather special configuration, basically i have a gerrit
server pushing
git data over openvpn connections (company regulations n' stuff)...
git 1.8.2.1 is started by xinetd
...
port= 9418
socket_type = stream
wait= no
us
ec9 (push: Add support for pre-push hooks, 2013-01-13) forgot to
add a note to git-push(1) about the new --no-verify option.
Signed-off-by: Thomas Rast
---
Junio replied privately that it should also mention the --verify
possibility.
So why not. But this needs to be fixed across the board
Greetings,
I bumped into a problem where git grep thinks files in repo/a/data are
binary files when it is invoked from repo/a and
repo/data/.gitattributes contains "* binary".
I can reproduce this on 1.7.9.5 and 1.7.10.4. Unfortunately I don't
have a newer version at hand.
How to reproduce:
[ps
On Thu, 23 May 2013 06:34:38 +, Felipe Contreras wrote:
...
> I don't understand; gitk already shows the first parent starting from
> the bottom, and the merge commits arrive from the right side. What am
> I missing?
That this isn't (consistently) the case in complicated situations.
I'll need
Antoine Pelisse writes:
On Thu, May 23, 2013 at 10:45 AM, Ramkumar Ramachandra
wrote:
> Alessandro Di Marco wrote:
>> this is a hack I made a couple of years ago in order to store my current
>> location in git commits (I travel a lot and being able to associate a
>> place with
On Wed, May 22, 2013 at 6:50 AM, Andreas Krey wrote:
> Hi everyone,
>
> I'm just looking into better displays of the commit graph (as
> displayed with gitk, smartgit, fisheye) - they tend to quickly
> dissolve into a heap of spaghetti.
>
> We had the idea that treating the first parent specially w
On Thu, May 23, 2013 at 12:29:59PM +0200, Andreas Krey wrote:
> On Thu, 23 May 2013 05:48:38 +, John Szakmeister wrote:
> ...
> > This is a feature of `git pull` that I really despise. I really wish
> > `git pull` treated the remote as the first parent in its merge
> > operation.
>
> I'd actu
Junio C Hamano wrote:
> If you have to ask why, and cannot answer the question yourself,
> then you would not know if such a caller exists. After a code
> audit, I know there is no such caller that appends @{u} but if you
> were writing a quick-and-dirty caller, I would not be surprised if
> you f
On Thu, May 23, 2013 at 5:53 AM, Michael S. Tsirkin wrote:
> Looks like push can't resolve tags to commits.
> Why is that?
>
> linux$ git push -f $PWD v3.10-rc2:refs/heads/vhost-next
Perhaps v3.10-rc2^{}. Yeah, totally and completely not-user-friendly,
I already complained about it to no avail.
On Thu, May 23, 2013 at 01:53:10PM +0300, Michael S. Tsirkin wrote:
> Looks like push can't resolve tags to commits.
> Why is that?
>
> linux$ git push -f $PWD v3.10-rc2:refs/heads/vhost-next
> error: Trying to write non-commit object
> a8c6d53c4d84b3a5eb182758a9cdceceba4691da to branch refs/heads
On Thu, May 23, 2013 at 5:42 AM, Ramkumar Ramachandra
wrote:
> Junio C Hamano wrote:
>> And that was done with extensivility your example implied in mind:
>> you may later be allowed to push other branches as well to origin.
>> That is why the refspec definition for 'origin' does not hardcode
>> t
Looks like push can't resolve tags to commits.
Why is that?
linux$ git push -f $PWD v3.10-rc2:refs/heads/vhost-next
error: Trying to write non-commit object
a8c6d53c4d84b3a5eb182758a9cdceceba4691da to branch refs/heads/vhost-next
To /scm/linux
! [remote rejected] v3.10-rc2 -> vhost-next (failed t
Junio C Hamano wrote:
> And that was done with extensivility your example implied in mind:
> you may later be allowed to push other branches as well to origin.
> That is why the refspec definition for 'origin' does not hardcode
> the name of the branch you are permitted to push there at this
> mome
On Thu, 23 May 2013 05:48:38 +, John Szakmeister wrote:
...
> This is a feature of `git pull` that I really despise. I really wish
> `git pull` treated the remote as the first parent in its merge
> operation.
I'd actually only like it that way when pulling from
the tracking branch, not for an
- Mail original -
> On Thu, May 23, 2013 at 5:06 AM, Andreas Krey wrote:
> [snip]
> > ...
> >> Don't do that, then.
> >
> > :-) Problem is, in this case 'I' expands to about
> > 1<<7 people I need to educate on this.
>
> This is a feature of `git pull` that I really despise. I reall
It seems to me that
git rev-list --first-parent --ancestry-path A..B
is well-defined and should list the commits in the intersection between
git rev-list --first-parent A..B
and
git rev-list--ancestry-path A..B
But in many cases the first command
Junio C Hamano venit, vidit, dixit 22.05.2013 18:36:
> Michael J Gruber writes:
>
>>> * mg/more-textconv (2013-05-10) 7 commits
>>> - grep: honor --textconv for the case rev:path
>>> - grep: allow to use textconv filters
>>> - t7008: demonstrate behavior of grep with textconv
>>> - cat-file:
Theodore Ts'o wrote:
> Right now I do this just by being careful, but if there was an
> automatic safety mechanism, it would save me a bit of work, since
> otherwise I might not catch my mistake until I do the "git push
> publish", at which point I curse and then start consulting the reflog
> to ba
1 - 100 of 110 matches
Mail list logo
