The patch is attached gzipped to avoid character encoding issues.
--
\\// Peter - http://www.softwolves.pp.se/
0001-gitk-Update-Swedish-translation-304t.patch.gz
Description: [PATCH] gitk: Update Swedish translation (304t)
Hi,
It's quite annoying that 'git fetch' tries to fetch '.' when the upstream
branch is a local one. This patch series fixes that, and while on it, it also
fixes 'git push'.
Felipe Contreras (3):
fetch: add --allow-local option
fetch: switch allow-local off by default
remote: disable allow-
So that it becomes possible to override the behavior when the remote
tracked is '.'; if it is, we default back to 'origin'.
To do this, we need to add a new helper fetchremote_get() that accepts
the boolean to enable/disable this behavior.
The default is 'true' which shouldn't cause any change in
And force it on in 'git push' to retain the old behavior.
Signed-off-by: Felipe Contreras
---
builtin/fetch.c| 2 +-
git-pull.sh| 2 +-
t/t5513-fetch-track.sh | 14 ++
3 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/builtin/fetch.c b/builtin/fetc
So that 'git push' uses 'origin', instead of '.' by default.
Signed-off-by: Felipe Contreras
---
remote.c| 2 +-
t/t5528-push-default.sh | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index a7e59ab..c1458dc 100644
--- a/remote.c
+++
Showing the tracking information for all the branches takes significant
amount of time. The user might not want that. The --no-show-tracking
option allows that.
Signed-off-by: Felipe Contreras
---
Documentation/git-branch.txt | 5 -
builtin/branch.c | 4 +++-
2 files changed, 7 i
On Thu, May 16, 2013 at 2:48 AM, Felipe Contreras
wrote:
> Showing the tracking information for all the branches takes significant
> amount of time. The user might not want that. The --no-show-tracking
> option allows that.
BTW. I ideally I would switch around so -v has upstream, and --vv has
the
On Thu, May 16, 2013 at 2:48 PM, Felipe Contreras
wrote:
> Showing the tracking information for all the branches takes significant
> amount of time. The user might not want that. The --no-show-tracking
> option allows that.
Or we could cache the information somewhere in .git. If a ref still
point
On Thu, May 16, 2013 at 2:54 AM, Duy Nguyen wrote:
> On Thu, May 16, 2013 at 2:48 PM, Felipe Contreras
> wrote:
>> Showing the tracking information for all the branches takes significant
>> amount of time. The user might not want that. The --no-show-tracking
>> option allows that.
>
> Or we could
Felipe Contreras venit, vidit, dixit 16.05.2013 09:48:
> Showing the tracking information for all the branches takes significant
> amount of time. The user might not want that. The --no-show-tracking
> option allows that.
I really like the idea of allowing that - not just because I've
suggested so
On Thu, May 16, 2013 at 3:00 AM, Michael J Gruber
wrote:
> Felipe Contreras venit, vidit, dixit 16.05.2013 09:48:
>> Showing the tracking information for all the branches takes significant
>> amount of time. The user might not want that. The --no-show-tracking
>> option allows that.
>
> I really l
Felipe Contreras wrote:
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> pushremote = github
> push = refs/heads/master
Hm. Some thoughts:
fetch and push aren't symmetric. By default fetches are batched: when
you say 'git fetch', it f
Felipe Contreras venit, vidit, dixit 16.05.2013 10:09:
> On Thu, May 16, 2013 at 3:00 AM, Michael J Gruber
> wrote:
>> Felipe Contreras venit, vidit, dixit 16.05.2013 09:48:
>>> Showing the tracking information for all the branches takes significant
>>> amount of time. The user might not want that
On Thu, May 16, 2013 at 3:00 PM, Michael J Gruber
wrote:
> I feel, though, that we're really exploding our option and config realm.
> For "git branch" in list mode, we are already able to stack "-v", i.e.
> "-v" and "-vv" do different things. How about maybe adding "-vvv" and
> arranging things so
Felipe Contreras wrote:
> So that it becomes possible to override the behavior when the remote
> tracked is '.'; if it is, we default back to 'origin'.
What is the problem you're trying to solve? Why do you have
branch..remote set to '.' in the first place, if you meant
origin? 'git fetch .' cur
Felipe Contreras wrote:
> git-pull.sh | 6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
This one obviously looks good. I'm not sure why you sent it along
with the other two patches though.
On a related note, I'm interested in fixing pull. What I have on paper so far:
- pull.condit
Hi,
These patches have been cooking in my github repository, and improve the
situation when bzr servers don't support repositories properly.
Felipe Contreras (8):
remote-bzr: recover from failed clones
remote-bzr: fix for files with spaces
remote-bzr: simplify get_remote_branch()
remote-b
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index b295dd4..7cd9ed8 100755
--- a/contrib/remote-helpe
Set the maximum number of splits to make when dividing the diff stat
lines based on space characters.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/rem
No need for 'origin', it's only needed for the bzrdir 'sprout' method,
which can be greatly simplified.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/contrib/remote-helpers/g
Until the branch is actually going to be used.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-b
It's not used anyway.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 2ba49ff..fdc2e69 100755
--- a/contrib/remot
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index fdc2e69..dd3d71c 100755
--- a/contrib/remote-helpers/gi
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 434e613..acc0dc9 100755
--- a/contrib/remote-helpers/git-remote-bz
If the user specified a list of branches, we ignore what the remote
repository lists, and simply use the branches directly. Since some
remotes don't report the branches correctly, this is useful.
Otherwise either fetch the repo, or the branch.
Signed-off-by: Felipe Contreras
---
contrib/remote-
Duy Nguyen venit, vidit, dixit 16.05.2013 10:23:
> On Thu, May 16, 2013 at 3:00 PM, Michael J Gruber
> wrote:
>> I feel, though, that we're really exploding our option and config realm.
>> For "git branch" in list mode, we are already able to stack "-v", i.e.
>> "-v" and "-vv" do different things.
+bare repository= bloßes Repository
Since "bloßes Rep." does not convey any sensible meaning to a german
reader (at least it doesn't to me) it might as well be "bare". Also bare
is used as parameter to commands
+remote tracking branch = externer Übernahmezweig
Anyone use
On Thu, May 16, 2013 at 3:25 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> So that it becomes possible to override the behavior when the remote
>> tracked is '.'; if it is, we default back to 'origin'.
>
> What is the problem you're trying to solve? Why do you have
> branch..remote
On Thu, May 16, 2013 at 3:29 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> git-pull.sh | 6 ++
>> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> This one obviously looks good. I'm not sure why you sent it along
> with the other two patches though.
Because this patch depe
On Thu, May 16, 2013 at 3:40 PM, Michael J Gruber
wrote:
>> What if I want something in - except some in -vv? I think to avoid
>> option explosion, maybe we can adopt --pretty=format:xxx from "git
>> log" and let the user decideswhat (and how) to display. "pretty" code
>> learns about alignmen
Ralf Thielow writes:
> Hi,
>
> I think the discussion might work better via ML than GitHub.
> This is the full glossary of git's de.po as it would look
> like with (hopefully) all the changes included that have been
> discussed here. Still without any reasoning for decisions
> (except HEAD).
[...
On Thu, May 16, 2013 at 3:21 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> pushremote = github
>> push = refs/heads/master
>
> Hm. Some thoughts:
>
> fetch and push aren't
On Thu, May 9, 2013 at 8:13 PM, Junio C Hamano wrote:
>It is a very powerful concept that we can generate data once,
>cast it in stone, and delay the decision on _how_ it is used
>until the last minute, much better than mapping at export time.
>So bundle does not need a similar re
On Wed, May 8, 2013 at 8:31 PM, Felipe Contreras
wrote:
> In order to support pushing old:new refspecs in remote-helpers, the best way
> to
> do what is to add an option to fast-export to rename the refs in the stream,
> so
> here it is:
I'm not going to work on this series any more.
--
Feli
On Wed, May 8, 2013 at 8:16 PM, Felipe Contreras
wrote:
> Cast the object to a commit, only to get the object back?
I'm dropping this one.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo i
Felipe Contreras wrote:
> And is going to change soon.
Your point being? How will this patch interact with push.default = matching?
>> branch..push should probably be named
>> branch..downstreamref and be used only for informational
>> purposes (@{d} and git status)?
>
> That makes absolutely no
On Thu, May 9, 2013 at 6:12 PM, Felipe Contreras
wrote:
> On Thu, May 9, 2013 at 6:09 PM, Junio C Hamano wrote:
>> John Szakmeister writes:
>>
>>> On Wed, May 8, 2013 at 9:16 PM, Felipe Contreras
>>> wrote:
Signed-off-by: Felipe Contreras
---
builtin/fast-export.c | 24
Felipe Contreras wrote:
> % git checkout -t -b devel master
Interesting. Have you considered changing -t to inherit the parent
branch's remote? (Would everyone like that?)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More
On Thu, May 16, 2013 at 4:20 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> And is going to change soon.
>
> Your point being? How will this patch interact with push.default = matching?
>
>>> branch..push should probably be named
>>> branch..downstreamref and be used only for inform
On Thu, May 16, 2013 at 4:27 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> % git checkout -t -b devel master
>
> Interesting. Have you considered changing -t to inherit the parent
> branch's remote? (Would everyone like that?)
Why would I do that? When I do 'git rebase' I want to
Felipe Contreras wrote:
> But my only concern is that there's no way to
> do something like:
>
> % git fetch backup 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
[remote "backup"]
fetch = refs/tags/*:refs/tags/*
fetch = refs/heads/*:refs/heads/*
What am I missing?
--
To unsubscrib
On Thu, May 16, 2013 at 4:34 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> But my only concern is that there's no way to
>> do something like:
>>
>> % git fetch backup 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
>
> [remote "backup"]
> fetch = refs/tags/*:refs/tags/*
>
Johan Herland wrote:
> The disambiguation can probably be resolved, although the resulting
> code will obviously be somewhat more cumbersome and ugly (and IMHO the
> current code is plenty of that already...). Combine this with the
> problems of clobbering of the same remote-tracking ref (describe
Updates since v9:
* Patch 01-04: refactor relative_path() in path.c, and reused it in
quote.c and clean.c.
* Patch 14: add testcases as t7301, and catch two bugs by running
testcases.
* Bugfix: when select by number, range like "5-" does not select
last entry.
@@ -485,7 +443,7
Original design of relative_path() is simple, just strip the prefix
(*base) from the abosolute path (*abs). In most cases, we need a real
relative path, such as: ../foo, ../../bar. That's why there is another
reimplementation (path_relative()) in quote.c.
Refactor relative_path() in path.c to retu
Since there is an enhanced version of relative_path() in path.c,
remove duplicate counterpart path_relative() in quote.c.
Signed-off-by: Jiang Xin
---
quote.c | 55 ++-
1 file changed, 2 insertions(+), 53 deletions(-)
diff --git a/quote.c b/qu
After substitude path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolte in function
quote_path_relative(). Remove unused parameters and the order of
parameters for quote_path_relative() function.
Signed-off-by: Jiang Xin
---
builtin/clean
After substitude path_relative() in quote.c with relative_path() from
path.c, parameters (such as len and prefix_len) are obsolte in function
write_name_quoted_relative(). Remove unused parameters from
write_name_quoted_relative() and related functions.
Signed-off-by: Jiang Xin
---
builtin/ls-fi
Before introducing interactive git-clean, refactor git-clean operations
into two phases:
* hold cleaning items in del_list,
* and remove them in a separate loop at the end.
We will introduce interactive git-clean between the two phases. The
interactive git-clean will show what would be done and
Show what would be done and the user must confirm before actually
cleaning.
Would remove ...
Would remove ...
Would remove ...
Remove [y/n]?
Press "y" to start cleaning, and press "n" if you want to abort.
Signed-off-by: Jiang Xin
---
Documentation/git-clean.txt | 10 ++--
When there are lots of items to be cleaned, it is hard to see them all
in one screen. Show them in columns will solve this problem.
Signed-off-by: Jiang Xin
Comments-by: Matthieu Moy
---
Documentation/config.txt | 4
builtin/clean.c | 49 +++---
Show header, help, error messages, and prompt in colors for interactive
git-clean. Re-use config variables, such as "color.interactive" and
"color.interactive." for command `git-add--interactive`.
Signed-off-by: Jiang Xin
Comments-by: Matthieu Moy
---
Documentation/config.txt | 17 +--
Rewrite menu using a new method `list_and_choose`, which is borrowed
from `git-add--interactive.perl`. We will use this framework to add
new actions for interactive git-clean later.
Please NOTE:
* Method `list_and_choose` return an array of integers, and
* it is up to you to free the allocated
Add a new action for interactive git-clean: filter by pattern. When the
user chooses this action, user can input space-separated patterns (the
same syntax as gitignore), and each clean candidate that matches with
one of the patterns will be excluded from cleaning. When the user feels
it's OK, press
Draw a multiple choice menu using `list_and_choose` to select items
to be deleted by numbers.
User can input:
* 1,5-7 : select 1,5,6,7 items to be deleted
* * : select all items to be deleted
* -*: unselect all, nothing will be deleted
*: (empty) finish selecting, and retur
Add a new action for interactive git-clean: ask each. It's just like
the "rm -i" command, that the user must confirm one by one for each
file or directory to be cleaned.
Signed-off-by: Jiang Xin
---
builtin/clean.c | 36
1 file changed, 36 insertions(+)
diff
Add new section "Interactive mode" for documentation of interactive
git-clean.
Signed-off-by: Jiang Xin
Helped-by: Eric Sunshine
---
Documentation/git-clean.txt | 65 +++--
1 file changed, 63 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-c
Add testcases for git-clean--interactive.
Signed-off-by: Jiang Xin
---
t/t7301-clean-interactive.sh | 439 +++
1 file changed, 439 insertions(+)
create mode 100755 t/t7301-clean-interactive.sh
diff --git a/t/t7301-clean-interactive.sh b/t/t7301-clean-int
Felipe Contreras wrote:
> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
> fatal: Refusing to fetch into current branch
> refs/heads/fc/fast-export/cleanup of non-bare repository
> fatal: The remote end hung up unexpectedly
That's because your HEAD is pointing to somethin
Felipe Contreras wrote:
> Why would I do that? When I do 'git rebase' I want to rebase on top of
> 'master', not 'origin/master' (or whatever the upstream of 'master'
> is).
Ah, so you want @{u} to point to refs/heads/master, but want to modify
fetch to act on the hard-coded "origin", not @{u} (wo
Commit 95b0c60 (remote-bzr: add support for bzr repos) introduced a
regression by assuming all bzr remote repos are listable, but they are
not.
If they are not listable they are basically useless, so let's assume
there is no bzr repo.
Reported-by: Thorsten Kranzkowski
Signed-off-by: Felipe Contr
Felipe Contreras wrote:
>> [remote "origin"]
>> push = refs/heads/master:refs/heads/fc/master
>>
>> [remote "."]
>> push = refs/heads/fc/old-remote/hg:refs/heads/fc/remote/hg
Major thinko. It should be:
[remote "github"]
push = refs/heads/master:refs/heads/fc/master
push = refs/h
On Thu, May 16, 2013 at 4:54 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
>> fatal: Refusing to fetch into current branch
>> refs/heads/fc/fast-export/cleanup of non-bare repository
>> fatal: The remote end hu
Felipe Contreras wrote:
> It doesn't matter if you think it's a bad practice or not, 'git push
> --mirror' works, and it's possible to update a branch even if HEAD is
> point to it. There should be a possibility to do the same with 'git
> fetch'.
So, introduce a configuration variable to turn off
On Thu, May 16, 2013 at 5:06 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>>> [remote "origin"]
>>> push = refs/heads/master:refs/heads/fc/master
>>>
>>> [remote "."]
>>> push = refs/heads/fc/old-remote/hg:refs/heads/fc/remote/hg
>
> Major thinko. It should be:
>
> [remote "g
On Thu, May 16, 2013 at 5:18 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> It doesn't matter if you think it's a bad practice or not, 'git push
>> --mirror' works, and it's possible to update a branch even if HEAD is
>> point to it. There should be a possibility to do the same with
On Thu, May 16, 2013 at 4:58 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> Why would I do that? When I do 'git rebase' I want to rebase on top of
>> 'master', not 'origin/master' (or whatever the upstream of 'master'
>> is).
>
> Ah, so you want @{u} to point to refs/heads/master, bu
Felipe Contreras wrote:
> Answer: because 'git fetch .' doesn't make any sense. So if
> 'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'.
I agree that 'git fetch .' is currently not useful (and I am not
against changing its behavior), but my question pertains to why you
are re
Dear translators,
Here's the main point in this discussion: The translation is not for us! The
translation is for those who don't speak much English and who don't know the
English git terminology very well. By definition, this target audience is not
present here on this mailing list and in this
On Thu, May 16, 2013 at 11:48 AM, Ramkumar Ramachandra
wrote:
> Johan Herland wrote:
>> The disambiguation can probably be resolved, although the resulting
>> code will obviously be somewhat more cumbersome and ugly (and IMHO the
>> current code is plenty of that already...). Combine this with the
Felipe Contreras wrote:
> Would I be able to do:
>
> % git branch --set-upstream-to origin/master --set-downstream-to
> github/fc/master
>
> ?
>
> Would I see these branches when I do 'git branch -vv'?
> Would I be able to do 'git push next@{downstream}'?
Hm, losing this functionality in the name
On Thu, May 16, 2013 at 11:36 AM, Felipe Contreras
wrote:
> Actually trying that command:
>
> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
> fatal: Refusing to fetch into current branch
> refs/heads/fc/fast-export/cleanup of non-bare repository
> fatal: The remote end h
Junio C Hamano wrote:
> It is simpler to use 'default values', no?
>
> local z=${GIT_PS1_STATESEPARATOR-" "}
There don't seem to be any more comments. If there are no issues,
could you fix this up locally before queueing?
Thanks.
--
To unsubscribe from this list: send the line "unsubscri
Johan Herland wrote:
> FWIW, I've abandoned this patch, and don't care much about multi-level
> remote names anymore. They work in current git, and they will sort-of
> work with remote ref namespaces as well, although you will have to use
> full refnames when referring to their remote-tracking refs
This reverts commit 24317ef32ac3111ed00792f9b2921dc19dd28fe2.
Different versions of Mercurial have different arguments for
bookmarks.updatefromremote(), while it should be possible to call the
right function with the right arguments depending on the version, it's
safer to restore the old behavior
On Thu, May 16, 2013 at 5:32 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> Answer: because 'git fetch .' doesn't make any sense. So if
>> 'branch.HEAD.remote' is '.' it doesn't make sense to do 'git fetch .'.
>
> I agree that 'git fetch .' is currently not useful (and I am not
> aga
This is a good default. Users who don't want color can look for "color"
in the git-config(1), and turn it off.
Signed-off-by: Ramkumar Ramachandra
---
color.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/color.c b/color.c
index e8e2681..f672885 100644
--- a/color.c
+++ b/
sam wrote:
> gdb /usr/bin/git core
What exactly are you doing? Is core aliased to something?
> [...]
> Core was generated by `git apply --verbose --check --ignore-whitespace
> --directory=/home/sam/P'.
What is this?
Can you give us clear instructions on how to reproduce the segfault?
--
To uns
Ramkumar Ramachandra wrote:
> sam wrote:
>> gdb /usr/bin/git core
>
> What exactly are you doing? Is core aliased to something?
Sorry about that. I just realized you're loading a core dump.
Please tell us how to reproduce this, or give us the backtrace with
debugging symbols.
--
To unsubscribe
Ramkumar Ramachandra writes:
> This is a good default. Users who don't want color can look for "color"
> in the git-config(1), and turn it off.
Err, you're comming a bit late ;-). See my patch, posted yesterday, for
the same topic.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubs
On Thu, May 16, 2013 at 6:31 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> Would I be able to do:
>>
>> % git branch --set-upstream-to origin/master --set-downstream-to
>> github/fc/master
>>
>> ?
>>
>> Would I see these branches when I do 'git branch -vv'?
>> Would I be able to do
On Thu, May 16, 2013 at 6:54 AM, Antoine Pelisse wrote:
> On Thu, May 16, 2013 at 11:36 AM, Felipe Contreras
> wrote:
>> Actually trying that command:
>>
>> % git fetch origin 'refs/tags/*:refs/tags/*' 'refs/heads/*:refs/heads/*'
>> fatal: Refusing to fetch into current branch
>> refs/heads/fc/fa
Matthieu Moy wrote:
> Err, you're comming a bit late ;-). See my patch, posted yesterday, for
> the same topic.
Ah, too much email :|
Your patch looks good.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info
Felipe Contreras wrote:
> Does branch..merge overrides remote..fetch? No. They
> complement each other.
I often wonder if you are reading what you're responding to:
remote..fetch is operated on by fetch, while branch..merge
is operated on by merge; they are really orthogonal.
> The same that 'gi
Duy Nguyen wrote:
> I tried a more generic approach a while ago.
>
> http://thread.gmane.org/gmane.comp.version-control.git/188705
Looks good. Why didn't you polish it for inclusion?
It's a very useful feature in my opinion: the default git branch
output is quite horrible. I want to make sort,
On Thu, May 16, 2013 at 8:52 AM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> Does branch..merge overrides remote..fetch? No. They
>> complement each other.
>
> I often wonder if you are reading what you're responding to:
And I wonder if you care if what you say is actually true.
> r
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> It doesn't make sense to push to the upstream branch, so create new
>> configurations for the notion of 'downstream' branch, which is basically
>> the branch to push to by default.
>
> It doesn't? That depends.
>
> To people coming from (an
When growing the table, take the opportunity to "compact" it by removing
entries with NULL decoration.
Users may have "removed" decorations by passing NULL to
insert_decoration. An object's table entry can't actually be removed
during normal operation, as it would break the linear hash collision
s
From: Junio C Hamano
Signed-off-by: Junio C Hamano
---
t/t6012-rev-list-simplify.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh
index dd6dc84..4e55872 100755
--- a/t/t6012-rev-list
Reimplement commit 4b7f53da on top of the new simplify-merges
infrastructure, tightening the condition to only consider root parents;
the original version incorrectly dropped parents that were TREESAME to
anything.
Original log message follows.
The merge simplification rule stated in 6546b59 (rev
History simplification previously always treated merges as TREESAME
if they were TREESAME to any parent.
While this was consistent with the default behaviour, this could be
extremely unhelpful when searching detailed history, and could not be
overridden. For example, if a merge had ignored a chang
When using --parents or --children, get_commit_action() previously showed
all merges, even if TREESAME to both parents.
This was intended to tie together the topology of the rewritten parents,
but it was excessive - in fact we only need to show merges that have two
or more relevant parents. Merges
When performing edge-based operations on the revision graph, it can be
useful to be able to identify the INTERESTING graph's connection(s) to
the bottom commit(s) specified by the user.
Conceptually when the user specifies "A..B" (== B ^A), they are asking
for the history from A to B. The first co
Previously, the default history treated bottom commits the same as any
other UNINTERESTING commit, which could force it down side branches.
Consider the following history:
*A--*B---D--*F * marks !TREESAME parent paths
\ /*
`-C-'
When requesting "B..F", B is UNINTERESTIN
Some side branching and odd merging to illustrate various flaws in
revision list scans, particularly when limiting the list.
Many expected failures, which will be gone by the end of the "history
traversal refinements" series.
Signed-off-by: Kevin Bracey
---
t/t6111-rev-list-treesame.sh | 184 ++
Use the BOTTOM flag to define relevance for pruning. Relevant commits
are those that are !UNINTERESTING or BOTTOM, and this allows us to
identify irrelevant side branches (UNINTERESTING && !BOTTOM).
If a merge has relevant parents, and it is TREESAME to them, then do not
let irrelevant parents cau
When simplifying an odd merge, such as one that used "-s ours", we may
find ourselves TREESAME to apparently redundant parents. Prevent
simplify_merges() from removing every TREESAME parent; if this would
happen reinstate the first TREESAME parent - the one that the default
log would have followed.
In the example given, P is not TREESAME to E. This doesn't affect the
current result, but it will matter when we change behaviour.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/rev-list-optio
The documentation of --boundary uses the term "uninteresting", which is
not used or defined anywhere else in the documentation. This is
unhelpful and confusing to anyone who hasn't seen the UNINTERESTING
flag in the source code.
Change to use "excluded", as per revisions.txt.
Signed-off-by: Kevin
No new functionality or bug fixes since v3, just tidying:
* Tests now use Junio's parent-checking functionality
* BOTTOM flags now set in a neater fashion (I think),
separating it out from the cmdline stuff.
* Creation and use of BOTTOM flag now split into 4 separate
commits - last version was
1 - 100 of 166 matches
Mail list logo
