On Fri, May 15, 2015 at 02:28:37PM -0400, Konstantin Ryabitsev wrote:
On 15/05/15 02:22 PM, Junio C Hamano wrote:
Also, is it worth allocating small and then growing up to the maximum?
I think this only relays one request at a time anyway, and I suspect
that a single 1MB allocation at the
When http-backend spawns upload-pack to do ref
negotiation, it streams the http request body to
upload-pack, who then streams the http response back to the
client as it reads. In theory, git can go full-duplex; the
client can consume our response while it is still sending
the request. In
Add a winmerge scriptlet with the commands described in [1] so
that users can use winmerge without needing to perform any
additional configuration.
[1] http://thread.gmane.org/gmane.comp.version-control.git/268631
Helped-by: Philip Oakley philipoak...@iee.org
Helped-by: Johannes Schindelin
Junio C Hamano gitster at pobox.com writes:
Laszlo Papp lpapp at kde.org writes:
Is there any benefit about having it like it is today or is it just
the usual no one has implemented it yet?
It actually is even more sketchy than that. A single file following
was done merely as a
On Wed, May 20, 2015 at 9:42 AM, David Aguilar dav...@gmail.com wrote:
+ OIFS=$IFS
+ IFS='
+'
I guess this is just a formatting issue with the mail export as it should read
IFS=$'\n'
Otherwise looks good to me.
--
Sebastian Schuberth
--
To unsubscribe from this list: send the
git-sh-setup sets IFS but it is not used by git-difftool--helper.
Set IFS in git-mergetool--lib so that the mergetool scriptlets,
diftool, and mergetool do not need to do so.
Signed-off-by: David Aguilar dav...@gmail.com
---
This patch is new since last time. It simplifies the patch that
On di, 2015-05-19 at 19:19 -0700, Junio C Hamano wrote:
Hopefully now you have some idea how your approach is problematic.
Yes, thanks for the thorough explanation!
Two more bad sideeffects, so two more reasons not to take this approach:
- test_must_fail tests might now fail for the wrong
From: Jeff King p...@peff.net
Written-by: Jeff King p...@peff.net
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/for-each-ref.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/builtin/for-each-ref.c
On Wed, May 20, 2015 at 03:13:59PM +0200, Philippe De Muyter wrote:
My initial problem (still unresolved/unanswered) is that some commits
that appeared between v3.14-rc1 and v3.14-rc2 (specifically
817c27a128e18aed840adc295f988e1656fed7d1) are present in v3.15, but not
in my branch.
I have
Hi John,
On Wed, May 20, 2015 at 02:25:34PM +0100, John Keeping wrote:
On Wed, May 20, 2015 at 03:13:59PM +0200, Philippe De Muyter wrote:
My initial problem (still unresolved/unanswered) is that some commits
that appeared between v3.14-rc1 and v3.14-rc2 (specifically
On Wed, May 20, 2015 at 04:12:38PM +0200, Philippe De Muyter wrote:
After reading the man page of 'git log', should --topo-order not be the
default log order ?
The problem with --topo-order is that it has to traverse all of the
commits before starting output. So:
$ time git log | head -1
Hi,
Clone the repos https://github.com/fmitha/SICL.
Then
git show 280c12ab49223c64c6f914944287a7d049cf4dd0
gives
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
But
git fsck
gives
Checking object directories: 100% (256/256), done.
Checking objects: 100%
Faheem Mitha fah...@faheem.info writes:
Hi,
Clone the repos https://github.com/fmitha/SICL.
Then
git show 280c12ab49223c64c6f914944287a7d049cf4dd0
gives
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
It seems 280c12ab49223c64c6f914944287a7d049cf4dd0 is not an
Karthik Nayak karthik@gmail.com writes:
From: Jeff King p...@peff.net
This means that git am will consider Peff as the author ...
Written-by: Jeff King p...@peff.net
... hence this is not needed: in the final history, it will appear as if
Peff wrote this Written-by: himself, which would
Jeff King p...@peff.net writes:
Not related to your patch, but I've often wondered if we can just get
rid of hold_lock_file_for_append. There's exactly one caller, and I
think it is doing the wrong thing. It is add_to_alternates_file(), but
shouldn't it probably read the existing lines to
Hello,
I stumbled upon something that annoyed me a bit, as I was working with
git stash to commit some big pile of modifications in small commits...
I wanted to get help wrt git stash drop and did it the following way :
[steps to reproduce]
mkdir tmp
cd tmp
git init
touch test.txt
git add
This version of the patch squashes in Ramsay Jones's fixes for a
couple of warnings. Thanks, Ramsay!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Add a new function, get_tree_entry_follow_symlinks, to tree-walk.[ch].
The function is not yet used. It will be used to implement git
cat-file --batch --follow-symlinks.
The function locates an object by path, following symlinks in the
repository. If the symlinks lead outside the repository,
Wire up get_sha1_with_context to call get_tree_entry_follow_symlinks
when GET_SHA1_FOLLOW_SYMLINKS is passed in flags. G_S_FOLLOW_SYMLINKS
is incompatible with G_S_ONLY_TO_DIE because the diagnosis
that ONLY_TO_DIE triggers does not at present consider symlinks, and
it would be a significant
This wires the in-repo-symlink following code through to the cat-file
builtin. In the event of an out-of-repo link, cat-file will print
the link in a new format.
Signed-off-by: David Turner dtur...@twopensource.com
---
Documentation/git-cat-file.txt | 99 +++-
re-rolled, thanks.
On Tue, 2015-05-19 at 23:16 +0100, Ramsay Jones wrote:
Commit 811cd77b (tree-walk: learn get_tree_entry_follow_symlinks,
14-05-2015) introduced a new function to locate an object by path
while following symlinks in the repository. However, sparse now
issues some Using plain
Jeff King p...@peff.net writes:
Your revised patch 2 looks good to me. I think you could test it more
reliably by simply adding a larger file, like:
test-genrandom foo $((128 * 1024 + 1)) big
echo 'big filter=epipe' .gitattributes
git config filter.epipe.clean true
git add big
$ git clone https://github.com/fmitha/SICL
cd SICL
$ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
$ git show 12323213123 # just to be sure to have a different error
message for non existing objects.
fatal: ambiguous argument
On Wed, May 20, 2015 at 11:02:14AM -0700, Stefan Beller wrote:
$ git clone https://github.com/fmitha/SICL
cd SICL
$ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
$ git show 12323213123 # just to be sure to have a different error
On 05/20/2015 09:32 PM, Stefan Beller wrote:
On Wed, May 20, 2015 at 12:27 PM, Sébastien Guimmara
sebastien.guimm...@gmail.com wrote:
On 05/20/2015 09:22 PM, Sébastien Guimmara wrote:
From: Eric Sunshine sunsh...@sunshineco.com
It looks like 'git send-email' got confused with the CC field.
David Aguilar dav...@gmail.com writes:
On Wed, May 20, 2015 at 09:47:56AM +0200, Sebastian Schuberth wrote:
On Wed, May 20, 2015 at 9:42 AM, David Aguilar dav...@gmail.com wrote:
+ OIFS=$IFS
+ IFS='
+'
I guess this is just a formatting issue with the mail export as it
David Aguilar dav...@gmail.com writes:
+ for directory in $(env | grep -Ei '^PROGRAM(FILES(\(X86\))?|W6432)=' |
+ cut -d '=' -f 2- | sort -u)
Is the final sort really desired? I am wondering if there are
fixed precedence/preference order among variants of %PROGRAMFILES%
Sebastian Schuberth sschube...@gmail.com writes:
On Wed, May 20, 2015 at 10:13 PM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com writes:
+ for directory in $(env | grep -Ei '^PROGRAM(FILES(\(X86\))?|W6432)=' |
+ cut -d '=' -f 2- | sort -u)
Is the
Jeff King p...@peff.net writes:
I should have looked before replying. It would indeed break cat-file
-e horribly. So the right answer may be to just improve the bad
object message (probably by checking has_sha1_file there and diagnosing
it either as missing or corrupted).
I should have
Thanks; will replace.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
sbel...@google.com writes:
$ git clone https://github.com/fmitha/SICL
cd SICL
$ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
$ git show 12323213123 # just to be sure to have a different error message
for non existing objects.
On Wed, May 20, 2015 at 10:23:55PM +0200, Sebastian Schuberth wrote:
I was in need to find out the path to the system-wide config file that
Git is using. I need to do this in a platform-independent way (Linux,
Mac OS X, Windows). What I came up with is
$ GIT_EDITOR=echo git config --system
On 20/05/15 20:23, Sébastien Guimmara wrote:
'git help' shows common commands in alphabetical order:
The most commonly used git commands are:
addAdd file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or
On Wed, May 20, 2015 at 1:39 PM, Junio C Hamano gits...@pobox.com wrote:
So...
maybe we need a command:
Given this SHA1, tell me anything you know about it,
Is it a {blob,tree,commit,tag}?
Is it referenced from anywhere else in this repository and if so, which type?
And if it is not
Hi,
I was in need to find out the path to the system-wide config file that
Git is using. I need to do this in a platform-independent way (Linux,
Mac OS X, Windows). What I came up with is
$ GIT_EDITOR=echo git config --system --edit
to trick Git into printing the path instead of opening the
Junio C Hamano gits...@pobox.com writes:
Luke Diamand l...@diamand.org writes:
+
+test_expect_failure 'EDITOR has options' '
+# Check that the P4EDITOR argument can be given command-line
+# options, which git-p4 will then pass through to the shell.
+test_expect_success 'EDITOR has options'
On Wed, May 20, 2015 at 11:01 PM, Jeff King p...@peff.net wrote:
Of course adding a new option probably won't help you, as it will take
some time before it can be used reliably. I think the hack you came up
with is pretty reasonable in the meantime.
Right, so I'll keep using that hack,
On 20/05/15 21:56, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Luke Diamand l...@diamand.org writes:
+
+test_expect_failure 'EDITOR has options' '
+# Check that the P4EDITOR argument can be given command-line
+# options, which git-p4 will then pass through to the shell.
Jeff King p...@peff.net writes:
We could add a has_sha1_file() check in get_sha1 for this case.
Please don't. get_sha1() is merely I have this string, which may
be a 40-hex or an extended SHA-1 expression. Turn it into a 20-byte
binary and does not require you to have any such object.
--
To
On Wed, May 20, 2015 at 10:13 PM, Junio C Hamano gits...@pobox.com wrote:
David Aguilar dav...@gmail.com writes:
+ for directory in $(env | grep -Ei '^PROGRAM(FILES(\(X86\))?|W6432)=' |
+ cut -d '=' -f 2- | sort -u)
Is the final sort really desired? I am wondering if there
Stefan Beller sbel...@google.com writes:
On Wed, May 20, 2015 at 1:39 PM, Junio C Hamano gits...@pobox.com wrote:
So...
maybe we need a command:
Given this SHA1, tell me anything you know about it,
Is it a {blob,tree,commit,tag}?
Is it referenced from anywhere else in this repository and
On Wed, May 20, 2015 at 2:06 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
On Wed, May 20, 2015 at 1:39 PM, Junio C Hamano gits...@pobox.com wrote:
So...
maybe we need a command:
Given this SHA1, tell me anything you know about it,
Is it a
On Wed, May 20, 2015 at 11:00 PM, Junio C Hamano gits...@pobox.com wrote:
Yuck. So even though %PROGRAMFILES% and %PROGRAMFILES(X86)% look as
if they are variables that can point at arbitrary places, they in
reality don't? Otherwise %PROGRAMFILES% may point at D:\Program
Correct. In the
On 05/20/2015 11:39 PM, Ramsay Jones wrote:
On 20/05/15 20:23, Sébastien Guimmara wrote:
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
This should be (at most) 'Helped-by:' - my 'contribution' was
so minor that even a 'Helped-by:' is
On Wed, May 20, 2015 at 01:39:36PM -0700, Junio C Hamano wrote:
Yeah, bad object sounds as if we tried to parse something that
exists and it was corrupt. So classifying a file or a pack index
entry exists where a valid object with that name should reside in
as bad object and there is no such
On Wed, 20 May 2015, Stefan Beller wrote:
On Wed, May 20, 2015 at 11:24 AM, Faheem Mitha fah...@faheem.info wrote:
So, is the repos corrupt or not? Also, I don't understand why you say
There is no file 28/0c... however.
Why would you expect there to be? I don't see it mentioned in
Jeff King p...@peff.net writes:
On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:
A quick git grep packfile vs git grep pack-file inside
Documentation/ directory indicates that we seem to use 'packfile'
primarily in the lower-level technical documents that are not
end-user
2015-05-20 0:00 GMT+02:00 Junio C Hamano gits...@pobox.com:
Fredrik Medley fredrik.med...@gmail.com writes:
static int upload_pack_config(const char *var, const char *value, void
*unused)
{
- if (!strcmp(uploadpack.allowtipsha1inwant, var))
- allow_tip_sha1_in_want =
On Wed, May 20, 2015 at 3:27 PM, Sébastien Guimmara
sebastien.guimm...@gmail.com wrote:
On 05/20/2015 09:22 PM, Sébastien Guimmara wrote:
From: Eric Sunshine sunsh...@sunshineco.com
It looks like 'git send-email' got confused with the CC field.
I'm sorry for that.
Confused in what way? The
On Wed, May 20, 2015 at 12:27 PM, Sébastien Guimmara
sebastien.guimm...@gmail.com wrote:
On 05/20/2015 09:22 PM, Sébastien Guimmara wrote:
From: Eric Sunshine sunsh...@sunshineco.com
It looks like 'git send-email' got confused with the CC field.
I'm sorry for that.
It's to keep
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
On Tue, May 19, 2015 at 12:34:03PM -0700, Junio C Hamano wrote:
A quick git grep packfile vs git grep pack-file inside
Documentation/ directory indicates that we seem to use 'packfile'
primarily in the lower-level
On Wed, 20 May 2015, Matthieu Moy wrote:
Faheem Mitha fah...@faheem.info writes:
Hi,
Clone the repos https://github.com/fmitha/SICL.
Then
git show 280c12ab49223c64c6f914944287a7d049cf4dd0
gives
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
It seems
Hi Stefan,
Thank you for the reply, but I don't follow what conclusion you are
drawing, if any.
On Wed, 20 May 2015, Stefan Beller wrote:
$ git clone https://github.com/fmitha/SICL
cd SICL
$ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
fatal: bad object
On 05/20/2015 09:22 PM, Sébastien Guimmara wrote:
From: Eric Sunshine sunsh...@sunshineco.com
It looks like 'git send-email' got confused with the CC field.
I'm sorry for that.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Wed, May 20, 2015 at 12:45:09PM -0700, Junio C Hamano wrote:
One related thing is that there are few mentions of idx file to
refer to pack index (e.g. show-index and verify-pack documentation
pages); I think this was an attempt to disambiguate pack index
from the Index, but as long as we
You are required to click on the link to verify your email account
because we are upgrading our
webmail.http://distilleries-provence.com/webalizer/eupdate/
Webmail Technical Support
Copyright 2012. All Rights Reserved
--
To unsubscribe from this list: send the line unsubscribe git in
the body of
On Wed, May 20, 2015 at 02:22:19PM -0400, Jeff King wrote:
On Wed, May 20, 2015 at 11:02:14AM -0700, Stefan Beller wrote:
$ git clone https://github.com/fmitha/SICL
cd SICL
$ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
On Wed, May 20, 2015 at 3:22 PM, Sébastien Guimmara
sebastien.guimm...@gmail.com wrote:
The ultimate goal is for git help to display common commands in
groups rather than alphabetically. As a first step, define the
groups in a new block, and then assign a group to each
common command.
Add a
Luke Diamand l...@diamand.org writes:
+
+test_expect_failure 'EDITOR has options' '
+# Check that the P4EDITOR argument can be given command-line
+# options, which git-p4 will then pass through to the shell.
+test_expect_success 'EDITOR has options' '
+ git p4 clone --dest=$git //depot
On 05/20/2015 09:48 PM, Eric Sunshine wrote:
On Wed, May 20, 2015 at 3:22 PM, Sébastien Guimmara
sebastien.guimm...@gmail.com wrote:
The ultimate goal is for git help to display common commands in
groups rather than alphabetically. As a first step, define the
groups in a new block, and then
On Wed, May 20, 2015 at 10:25:41AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Not related to your patch, but I've often wondered if we can just get
rid of hold_lock_file_for_append. There's exactly one caller, and I
think it is doing the wrong thing. It is
On Wed, May 20, 2015 at 02:01:32PM -0400, Jeff King wrote:
This takes away the immediate pain. We may also want to
teach --help to the option. I guess we cannot do better
than just having it run git help stash in all cases (i.e.,
we have no way to get the help for a specific subcommand).
Hi,
On 2015-05-20 19:19, Matthieu Moy wrote:
Faheem Mitha fah...@faheem.info writes:
Clone the repos https://github.com/fmitha/SICL.
Then
git show 280c12ab49223c64c6f914944287a7d049cf4dd0
gives
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
It seems
The option parser for git-stash stuffs unknown flags into
the $FLAGS variable, where they can be accessed by the
individual commands. However, most commands do not even look
at these extra flags, leading to unexpected results like
this:
$ git stash drop --help
Dropped refs/stash@{0}
On Wed, May 20, 2015 at 11:24 AM, Faheem Mitha fah...@faheem.info wrote:
So, is the repos corrupt or not? Also, I don't understand why you say
There is no file 28/0c... however.
Why would you expect there to be? I don't see it mentioned in that list.
Each object is stored at
On Wed, May 20, 2015 at 9:18 AM, Karthik Nayak karthik@gmail.com wrote:
add a ref-filter API to provide functions to filter refs for listing.
This will act as a common library for commands like 'tag -l',
'branch -l' and 'for-each-ref'. ref-filter will enable each of these
commands to
'git help' shows common commands in alphabetical order:
The most commonly used git commands are:
addAdd file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or
From: Eric Sunshine sunsh...@sunshineco.com
Parse the group block to create the array of group descriptions:
static char *common_cmd_groups[] = {
N_(starting a working area),
N_(working on the current change),
N_(working with others),
N_(examining the history and state),
The ultimate goal is for git help to display common commands in
groups rather than alphabetically. As a first step, define the
groups in a new block, and then assign a group to each
common command.
Add a block at the beginning of command-list.txt:
init start a working area (see also:
From: Eric Sunshine sunsh...@sunshineco.com
The ultimate goal is for git help to classify common commands by
group. Toward this end, a subsequent patch will add a new common
groups section to command-list.txt preceding the actual command list.
As preparation, teach existing command-list.txt
command-list.sh, retired in the previous patch, was the only
consumer of the common tag, so drop this now-unnecessary
attribute.
before:
git-add mainporcelaincommon worktree
after:
git-add mainporcelainworktree
Helped-by: Eric Sunshine
On Wed, May 20, 2015 at 3:22 PM, Sébastien Guimmara
sebastien.guimm...@gmail.com wrote:
The major modification of this reroll [1] is the use of the perl version
of generate-cmdlist instead of the awk one.
help.c:
1. change the introductory message from:
The typical Git workflow
On Wed, May 20, 2015 at 11:02:14AM -0700, Stefan Beller wrote:
$ git clone https://github.com/fmitha/SICL
cd SICL
$ git show 280c12ab49223c64c6f914944287a7d049cf4dd0
fatal: bad object 280c12ab49223c64c6f914944287a7d049cf4dd0
$ git show 12323213123 # just to be sure to have a different error
The major modification of this reroll [1] is the use of the perl version
of generate-cmdlist instead of the awk one.
help.c:
1. change the introductory message from:
The typical Git workflow includes:
to:
These are common Git commands used in various situations:
2. include Ramsay's
It's better to start the man page with a description of what submodules
actually are instead of saying what they are not.
Reorder the paragraphs such that
the first short paragraph introduces the submodule concept,
the second paragraph highlights the usage of the submodule command,
the third
Jeff King p...@peff.net writes:
On Wed, May 20, 2015 at 12:45:09PM -0700, Junio C Hamano wrote:
One related thing is that there are few mentions of idx file to
refer to pack index (e.g. show-index and verify-pack documentation
pages); I think this was an attempt to disambiguate pack index
Karthik Nayak karthik@gmail.com writes:
convert 'for-each-ref' to use the common API provided by 'ref-filter'.
Start a sentence with capital?
More importantly, the above is misleading, as if you invented a new
ref-filter API and made for-each-ref build on that new
infrastructure.
This
Jeff King p...@peff.net writes:
Yeah, I agree they should agree with the EBNF. And my inclination is for
packfile, as it is refering to the concept of the on-the-wire packfile
data (there is no file ending in .pack in this context).
Which I guess argues for a further patch.
I'm fine with
When the previous commit introduced the branch_get_upstream
helper, there was one call-site that could not be converted:
the one in sha1_name.c, which gives detailed error messages
for each possible failure.
Let's teach the helper to optionally report these specific
errors. This lets us convert
Before the previous commit, we had to make sure that
read_config() was called before entering remote_get_1,
because we needed to pass pushremote_name by value. But now
that we pass a function, we can let remote_get_1 handle
loading the config itself, turning our wrappers into true
one-liners.
In a triangular workflow, each branch may have two distinct
points of interest: the @{upstream} that you normally pull
from, and the destination that you normally push to. There
isn't a shorthand for the latter, but it's useful to have.
For instance, you may want to know which commits you haven't
All of the information needed to find the @{upstream} of a
branch is included in the branch struct, but callers have to
navigate a series of possible-NULL values to get there.
Let's wrap that logic up in an easy-to-read helper.
Signed-off-by: Jeff King p...@peff.net
---
builtin/branch.c |
Just as we have %(upstream) to report the @{upstream}
for each ref, this patch adds %(push) to match @{push}.
It supports the same tracking format modifiers as upstream
(because you may want to know, for example, which branches
have commits to push).
Signed-off-by: Jeff King p...@peff.net
---
When remote.c loads its config, it records the
branch.*.pushremote for the current branch along with the
global remote.pushDefault value, and then binds them into a
single value: the default push for the current branch. We
then pass this value (which may be NULL) to remote_get_1
when looking up a
This saves us having to maintain a magic number to skip past
the matched prefix.
Signed-off-by: Jeff King p...@peff.net
---
builtin/for-each-ref.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/for-each-ref.c b/builtin/for-each-ref.c
index 18d209b..345d8dd
We'll want to use this logic as a fallback when looking up
the pushremote, so let's pull it out into its own function.
We don't technically need to make this available outside of
remote.c, but doing so will provide a consistent API with
pushremote_for_branch, which we will add later.
In a triangular workflow, the place you pull from and the
place you push to may be different. As we have
branch_get_upstream for the former, this patch adds
branch_get_push for the latter (and as the former implements
@{upstream}, so will this implement @{push} in a future
patch).
Note that the
We will be adding new mark types in the future, so separate
the suffix data from the logic.
Signed-off-by: Jeff King p...@peff.net
---
sha1_name.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 461157a..1005f45 100644
---
Now that most of the logic for our local get_upstream_branch
has been pushed into the generic branch_get_upstream, we can
fold the remainder into interpret_upstream_mark.
Furthermore, what remains is generic to any branch-related
@{foo} we might add in the future, and there's enough
boilerplate
When we call branch_get() to lookup or create a struct
branch, we make sure the merge field is filled in so that
callers can access it. But the conditions under which we do
so are a little confusing, and can lead to two funny
situations:
1. If there's no branch.*.remote config, we cannot
When we create each branch struct, we fill in the
remote_name field from the config, and then fill in the
actual remote field (with a struct remote) based on that
name. However, it turns out that nobody really cares about
the latter field. The only two sites that access it at all
are:
1.
When we read the remote config from disk, we update a
default_remote_name variable if we see branch.*.remote
config for the current branch. This isn't wrong, or even all
that complicated, but it is a bit simpler (because it
reduces our overall state) to just lazily compute the
default when we need
In a thread a few months ago[1], we discussed the idea that the
--dissociate --reference=foo interface was somewhat awkward for
somebody who just wants to optimize their clone. This is mostly due to
the historical development of the features. The logical interface for
somebody who just wants a
Not only does this save us having to implement a custom
callback, but it handles --no-reference in the usual way
(to clear the list).
The generic callback does copy the string, which we don't
technically need, but that should not hurt anything.
Signed-off-by: Jeff King p...@peff.net
---
This is a re-roll of the series at:
http://thread.gmane.org/gmane.comp.version-control.git/268185
The only changes here are the addition of patches 2 and 6, which are
both cleanups that help make the other patches more readable/sensible.
They are the same as what was posted during review of
On Wed, May 20, 2015 at 10:01:49PM -0700, Junio C Hamano wrote:
1. Assuming that seed is a reasonable verb for this concept, is
--seed=repo OK for the option? Would --seed-from=repo be
better? (Also, the response bleh, seed is a terrible name is
fine, too, but only if
On Wed, May 20, 2015 at 03:37:23PM -0700, Junio C Hamano wrote:
In any case, even though I merged these three to 'next', I think we
need to either revert 3/3 or do s/pack-file/packfile/ throughout the
pack-protocol documentation. The original has something like this:
The pack-file MUST
The safe way to use `--reference` is to add in the recent
`--dissociate` option, which optimizes the initial clone,
but does not create any obligation to avoid pruning or
deleting the reference repository. However, it can be rather
tricky to explain why two options are necessary, and why
using
These options are intimately related, so it makes sense to
list them nearby in the -h output (they are already
adjacent in the manpage).
Signed-off-by: Jeff King p...@peff.net
---
builtin/clone.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/clone.c
On Thu, May 21, 2015 at 12:44:29AM -0400, Jeff King wrote:
This is a re-roll of the series at:
http://thread.gmane.org/gmane.comp.version-control.git/268185
The only changes here are the addition of patches 2 and 6, which are
both cleanups that help make the other patches more
1 - 100 of 101 matches
Mail list logo
