On 05/21/2013 07:34 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
revision.c | 20 ++--
revision.h | 32 +---
2 files changed, 35 insertions(+), 17 deletions(-)
On 05/21/2013 07:38 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
The condition under which gc_boundary() is called was previously
if (alloc = nr)
. But by construction, nr can never exceed alloc, so the check looks
unnecessarily mysterious. In fact, the
On 05/21/2013 07:49 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
There is no logical reason for this test to be here. At the caller we
might be able to figure out its meaning.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
I do not think this change
On 05/21/2013 07:27 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Instead of accepting an array and using exactly two elements from the
array, take two single (struct object_array_entry *) arguments.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
On 05/21/2013 07:30 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Change cmd_diff() to use a (struct object_array) for holding the trees
that it accumulates, rather than rolling its own equivalent.
A significant detail missing here is that this lifts the
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
and then run 'rm -rf largedir' in another terminal in parallel.
I would argue that there is something
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 the commit date helps me to quickly recover what were doing
at that time). Long story short, the screeenshot at
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
and then run 'rm -rf largedir' in
On Wed, 22 May 2013 11:07:07 +, Junio C Hamano wrote:
...
If you have a four-commit segment in your commit ancestry graph
I never had yet. :-(
(time flows from left to right; turn your head 90-degrees to the
right if you want a gitk representation):
---A--X
\/
/\
On Thu, May 23, 2013 at 5:06 AM, Andreas Krey a.k...@gmx.de wrote:
[snip]
...
Don't do that, then.
:-) Problem is, in this case 'I' expands to about
17 people I need to educate on this.
This is a feature of `git pull` that I really despise. I really wish
`git pull` treated the remote as
On Thu, May 23, 2013 at 10:45 AM, Ramkumar Ramachandra
artag...@gmail.com 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 the commit date helps me to
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 back the
Junio C Hamano venit, vidit, dixit 22.05.2013 18:36:
Michael J Gruber g...@drmicha.warpmail.net 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
-
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
- Mail original -
On Thu, May 23, 2013 at 5:06 AM, Andreas Krey a.k...@gmx.de wrote:
[snip]
...
Don't do that, then.
:-) Problem is, in this case 'I' expands to about
17 people I need to educate on this.
This is a feature of `git pull` that I really despise. I really
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 any
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
moment.
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
On Thu, May 23, 2013 at 5:42 AM, Ramkumar Ramachandra
artag...@gmail.com 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
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
On Thu, May 23, 2013 at 5:53 AM, Michael S. Tsirkin m...@redhat.com 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
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 find
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 actually only
On Wed, May 22, 2013 at 6:50 AM, Andreas Krey a.k...@gmx.de 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
Antoine Pelisse apeli...@gmail.com writes:
On Thu, May 23, 2013 at 10:45 AM, Ramkumar Ramachandra
artag...@gmail.com 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
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 to
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:
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 tr...@inf.ethz.ch
---
Junio replied privately that it should also mention the --verify
possibility.
So why not. But this needs to be fixed
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
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 m...@redhat.com
To: qemu-de...@nongnu.org
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 m...@redhat.com
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 tr...@inf.ethz.ch
Thanks. FWIW
Reviewed-by: Michael S. Tsirkin
Michael J Gruber g...@drmicha.warpmail.net 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
Ramkumar Ramachandra artag...@gmail.com 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
[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
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
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 artag...@gmail.com
---
remote.c | 2 +-
remote.h | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/remote.c
Introduce an AT_KIND_PUSH to be represented as @{p[ush]}. Determine
it using branch.remote.push_refspec.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
sha1_name.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index
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.name.push is explicitly specified.
2. There is a pattern to match (*).
Proof-of-concept only.
Signed-off-by: Ramkumar
We need it.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
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
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()
Junio C Hamano venit, vidit, dixit 23.05.2013 16:40:
Michael J Gruber g...@drmicha.warpmail.net 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
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
John Keeping j...@keeping.me.uk 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
On Thu, May 23, 2013 at 09:01:15AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
IIRC, git-gui runs two
Adeodato Simó dato at 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
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
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 10:23 PM, Felipe Contreras
felipe.contre...@gmail.com 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
Michael Haggerty mhag...@alum.mit.edu writes:
On 05/21/2013 07:34 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
revision.c | 20 ++--
revision.h | 32 +---
2
Michael Haggerty mhag...@alum.mit.edu 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
Ramkumar Ramachandra artag...@gmail.com 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
Michael J Gruber g...@drmicha.warpmail.net 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
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 it
Antoine Pelisse apeli...@gmail.com 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
Michael Haggerty mhag...@alum.mit.edu 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
Michael S. Tsirkin m...@redhat.com 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
* Ralf Thielow ralf.thie...@gmail.com [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
Junio C Hamano gits...@pobox.com 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
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
Theodore Ts'o ty...@mit.edu 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
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
entry
Theodore Ts'o ty...@mit.edu 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
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
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 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-packs that has been running
for days/weeks without terminating
...
Anyone that has any clues about what could be going
Michael S. Tsirkin m...@redhat.com 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
Junio C Hamano gits...@pobox.com 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
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
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 method
John Keeping j...@keeping.me.uk 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
On Thu, May 23, 2013 at 11:10:32AM -0700, Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 23, 2013 at 5:53 AM, Michael S. Tsirkin m...@redhat.com wrote:
Looks like push can't resolve tags to commits.
Why is that?
linux$ git push -f $PWD
Michael S. Tsirkin m...@redhat.com writes:
On Thu, May 23, 2013 at 11:10:32AM -0700, Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 23, 2013 at 5:53 AM, Michael S. Tsirkin m...@redhat.com
wrote:
Looks like push can't resolve tags to commits.
Why
On Thu, May 23, 2013 at 11:05:00AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com 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
On Thu, May 23, 2013 at 11:10:32AM -0700, Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 23, 2013 at 5:53 AM, Michael S. Tsirkin m...@redhat.com wrote:
Looks like push can't resolve tags to commits.
Why is that?
linux$ git push -f $PWD
On Thu, May 23, 2013 at 12:52:11PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com 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:
Michael S. Tsirkin m...@redhat.com writes:
On Thu, May 23, 2013 at 11:05:00AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com 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
Michael S. Tsirkin m...@redhat.com 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
On Thu, May 23, 2013 at 02:19:40PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
On Thu, May 23, 2013 at 11:05:00AM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
Looks like push can't resolve tags to commits.
Why is that?
How
Michael S. Tsirkin m...@redhat.com 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
On Thu, May 23, 2013 at 11:54 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, May 22, 2013 at 11:07 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, May 22, 2013 at 7:08 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe
On Thu, May 23, 2013 at 02:27:59PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com 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
Felipe Contreras felipe.contre...@gmail.com 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
On Thu, May 23, 2013 at 02:01:39PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk 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
On Thu, May 23, 2013 at 4:52 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
On Thu, May 23, 2013 at 4:55 PM, John Keeping j...@keeping.me.uk 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
Jim Greenleaf james.a.greenl...@gmail.com writes:
Adeodato Simó dato at 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
John Keeping j...@keeping.me.uk 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
Felipe Contreras felipe.contre...@gmail.com 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
On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk 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
Thomas Rast tr...@inf.ethz.ch 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
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk 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
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch 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
On Thu, May 23, 2013 at 5:44 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
On Thu, May 23, 2013 at 5:54 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
This isn't about swap parents, it's about helping
Thomas Rast tr...@inf.ethz.ch 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
Felipe Contreras felipe.contre...@gmail.com 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
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=gitm=135215709307126q=raw
When I use `git log --follow file` all is OK, but once I add
`--reverse` to it, it no longer
On Thu, May 23, 2013 at 6:26 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano gits...@pobox.com 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
1 - 100 of 106 matches
Mail list logo
