Nicolas Pitre writes:
> This goes as follows:
>
> - Tree reference: either variable length encoding of the index
> into the SHA1 table or the literal SHA1 prefixed by 0 (see
> encode_sha1ref()).
>
> - Parent count: variable length encoding of the number of parents.
> This is normally going
On 15:27, Thu 05 Sep 13, Junio C Hamano wrote:
> Now the long option name is "--no-index", it makes me wonder if "-i"
> is a good synonym for it, and the longer I stare at it, the more
> certain I become convinced that it is a bad choice.
>
I had originally called it "--ignore-index" at which poin
There were no hints in the documentation about how to create
replacement objects.
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 16
1 file changed, 16 insertions(+)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index d198006..a
So that they are tested a little bit too.
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 09a2b49..7d47984 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@
A previous patch ensures that both the replaced and the replacement
objects passed to git replace must be of the same type, except if
-f option is used.
While at it state that there is no other restriction on both objects.
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 9 ++
Users replacing an object with one of a different type were not
prevented to do so, even if it was obvious, and stated in the doc,
that bad things would result from doing that.
To avoid mistakes, it is better to just forbid that though.
If -f option, which means '--force', is used, we can allow a
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 6 ++
1 file changed, 6 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 09bad98..09a2b49 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -276,4 +276,10 @@ test_expect_success '-f option bypasses the
It is now standard practice in Git to have both short and long option
names. So let's give a long option name to the git replace options too.
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 3 +++
builtin/replace.c | 6 +++---
2 files changed, 6 insertions(+), 3 d
and that the -f option bypasses the type check
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index decdc33..09bad98 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -263
Many patchs have been squashed together as Junio suggested.
And in patch 3/7 now no grep is done on the error message.
Christian Couder (7):
replace: forbid replacing an object with one of a different type
Documentation/replace: state that objects must be of the same type
t6050-replace: test
On Fri, Sep 6, 2013 at 10:27 AM, Tim Chase wrote:
> I've got a pretty good grasp on git's rather straightforward
> branching, but am trying to wrap my head around Mercurial's
> branching. There seem to be several flavors, some default to
> push-public, while others are private; some are tracked i
On Thu, Sep 5, 2013 at 11:52 PM, Duy Nguyen wrote:
> On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre wrote:
>> Now the pack index v3 probably needs to be improved a little, again to
>> accommodate completion of thin packs. Given that the main SHA1 table is
>> now in the main pack file, it should
I am imagining what I consider to be a naive approach to preventing
loose unreachable object explosions. It may seem a bit heavy handed
at first, but every conversation so far about this issue seems to have
died, so I am looking for a simple incremental improvement to what we
have today. I theori
On Fri, 6 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Should be up to date with Nico's latest implementation and also cover
> additions to the format that everybody seems to agree on:
>
> - new types for canonical trees and commits
> - sha-1 table
I've got a pretty good grasp on git's rather straightforward
branching, but am trying to wrap my head around Mercurial's
branching. There seem to be several flavors, some default to
push-public, while others are private; some are tracked in history,
while others seem more ephemeral; often the docs
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Should be up to date with Nico's latest implementation and also cover
additions to the format that everybody seems to agree on:
- new types for canonical trees and commits
- sha-1 table covering missing objects in thin packs
Documentation/technical
2013/9/4 Junio C Hamano :
> * jx/branch-vv-always-compare-with-upstream (2013-08-26) 2 commits
> - status: always show tracking branch even no change
> - branch: report invalid tracking branch as gone
>
> "git branch -v -v" (and "git status") did not distinguish among a
> branch that does not b
Current code peeks into the transfered pack's header, if the number of
objects is under a limit, unpack-objects is called to handle the rest,
otherwise index-pack is. This patch makes index-pack handle both
cases. After the next patch, unpack-objects will no longer be used. It
may be removed in fut
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/receive-pack.c | 122 ++---
1 file changed, 34 insertions(+), 88 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index e3eb5fc..0a84a61 100644
--- a/builtin/receive-pack.c
+++ b
If the number of objects in the given pack is less than the limit, all
objects in the pack will be unpacked, and the pack will not be created
if it's streamed in. It's intended to replace unpack-objects.
Unlike unpack-objects, this operation requires writing the stream to
disk for delta resolution
On Thu, Sep 05, 2013 at 08:30:53AM +0200, Matthieu Moy wrote:
> Jens Lehmann writes:
>
> > Am 04.09.2013 08:31, schrieb Matthieu Moy:
> >> "brian m. carlson" writes:
> >>
> >>> Tests are included which verify that this change has no effect on git
> >>> submodule
> >>> summary without the --for
On Fri, Sep 6, 2013 at 2:02 AM, Nicolas Pitre wrote:
> I think that we've found a way to better support thin packs.
>
> You said:
>
>> What if the sender prepares the sha-1 table to contain missing objects
>> in advance? The sender should know what base objects are missing. Then
>> we only need to
"Philip Oakley" writes:
> It's not clear to me that a single default that uses a merge or
> rebase, without a 'stop if' criteria would be of any help in my
> situation.
>
> My thoughts are that the options on a fetch-pull are for the branch to
> be:
> * Overwritte (--force) (i.e. a conflict scena
On 9/5/2013 5:23 PM, Junio C Hamano wrote:
> Brad King writes:
>> create SP NUL NUL
>> update SP NUL NUL [] NUL
>
> That SP in '-z' format looks strange. Was there a reason why NUL
> was inappropriate?
The precedent I saw in the -z survey I posted is that NUL is used
to terminate
Junio C Hamano writes:
> I can imagine users might want to say "when I am on these small
> number of branches, I want to merge (or rebase), but when I am on
> other, majority of my branches, because they are private, unfinished
> and unpublished work, please stop me from accidentally messing thei
On Thu, Sep 05, 2013 at 09:36:47PM +0200, Matthieu Moy wrote:
> Junio C Hamano writes:
>
> > One caveat, though. The name "oldStyle" will become problematic,
> > when we want to remove some wart in the output format long after
> > this "no comment prefix by default" series lands. Some people m
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> One caveat, though. The name "oldStyle" will become problematic,
>> when we want to remove some wart in the output format long after
>> this "no comment prefix by default" series lands. Some people may
>> expect setting oldStyle=true would giv
"Philip Oakley" writes:
> From: "Philip Oakley"
> Sent: Saturday, August 31, 2013 11:16 PM
>> From: "Christian Couder"
>>> Signed-off-by: Christian Couder
>>> ---
>>> Documentation/git-replace.txt | 4 +++-
>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/gi
Eric Wong writes:
> Junio C Hamano wrote:
>> "Uli Heller" writes:
>> > Nevertheless, I think it makes sense to fix the issue within the
>> > git perl module Ra.pm, too. The change frees the private copy of
>> > the remote access object on termination which prevents the error
>> > from happening
Hiroshige Umino writes:
> "-" abbreviation is handy for "cherry-pick" like "checkout" and "merge".
>
> It's also good for uniformity that a "-" stands as
> the name of the previous branch where a branch name is
> accepted and it could not mean any other things like stdin.
>
> Signed-off-by: Hiros
Dave Williams writes:
> check-ignore currently shows how .gitignore rules would treat untracked
> paths. Tracked paths do not generate useful output. This prevents
> debugging of why a path became tracked unexpectedly unless that path is
> first removed from the index with `git rm --cached `.
>
From: "Philip Oakley"
Sent: Saturday, August 31, 2013 11:16 PM
From: "Christian Couder"
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-replace.txt
b/Documentation/git-replace.txt
index
On Thu, 5 Sep 2013, Nicolas Pitre wrote:
> On Thu, 5 Sep 2013, Nicolas Pitre wrote:
>
> > If the path or name index is zero, this means the entry data is to be
> > found inline rather than being located in the dictionary table. This is
> > there to allow easy completion of thin packs without havi
I hope it's not too inappropriate to send a random question your way, but I've
exhausted all other means and am quite lost at the moment..
I'm trying to setup a distributed development repository with a central
repository acting as the production copy. I'm doing so on a Windows file share
wit
From: "Junio C Hamano"
"Philip Oakley" writes:
From: "Junio C Hamano"
John Keeping writes:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
...
Peff already covered (1)---it is highly doubtful that a merge is
"almost always wrong". In fact, if that _w
Brad King writes:
> On 09/04/2013 05:27 PM, Junio C Hamano wrote:
>> I am not saying the above is the best format, but the point is that
>> the mode of the operation defines the structure
>
> Great, thanks for your comments. Based on that I've prototyped a
> new format. Rather than jumping stra
On Thu, 5 Sep 2013, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> > On Thu, 5 Sep 2013, Duy Nguyen wrote:
> >
> >> On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre wrote:
> >> > Now the pack index v3 probably needs to be improved a little, again to
> >> > accommodate completion of thin packs.
On Thu, Sep 05, 2013 at 09:18:25AM +, Jørgen Edelbo wrote:
> > -Original Message-
> > From: Johannes Sixt [mailto:j.s...@viscovery.net]
> > Sent: 5. september 2013 10:57
> >
> > Please do not top-post.
> >
> > Am 9/5/2013 10:29, schrieb Jørgen Edelbo:
> > > -Original Message-
On 09/04/2013 05:27 PM, Junio C Hamano wrote:
> I am not saying the above is the best format, but the point is that
> the mode of the operation defines the structure
Great, thanks for your comments. Based on that I've prototyped a
new format. Rather than jumping straight to the patch, here is my
Nicolas Pitre writes:
> On Thu, 5 Sep 2013, Duy Nguyen wrote:
>
>> On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre wrote:
>> > Now the pack index v3 probably needs to be improved a little, again to
>> > accommodate completion of thin packs. Given that the main SHA1 table is
>> > now in the main
Junio C Hamano writes:
> One caveat, though. The name "oldStyle" will become problematic,
> when we want to remove some wart in the output format long after
> this "no comment prefix by default" series lands. Some people may
> expect setting oldStyle=true would give output from 1.8.4 era, while
On Thu, Sep 05, 2013 at 01:13:40PM -0400, John Szakmeister wrote:
> > Yep. These were mostly caused by a bug in Grit that is long-fixed. But
> > the objects remain in many histories. It would have painful to rewrite
> > them back then, and it would be even more painful now.
>
> I guess there's s
From: Junio C Hamano
>
> Christian Couder writes:
>>
>> +test_expect_success 'replaced and replacement objects must be of the same
>> type' '
>> +test_must_fail git replace mytag $HASH1 2>err &&
>> +grep "mytag. points to a replaced object of type .tag" err &&
>> +grep "$HASH1. poi
Junio C Hamano wrote:
> "Uli Heller" writes:
> > Nevertheless, I think it makes sense to fix the issue within the
> > git perl module Ra.pm, too. The change frees the private copy of
> > the remote access object on termination which prevents the error
> > from happening.
> Thanks. Please sign-o
Matthieu Moy writes:
> Compared to v2, this changes essentially:
>
> * The prefix is actually disabled by default in this version. As a
> consequence, the option is renamed to status.oldStyle.
>
> * Since this is the default, the tests are updated to test the new
> defaults. In a first patch,
John Keeping writes:
> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
>> Are there cases where you do not want to either rebase nor merge?
>> If so what do you want to do after "git pull" fetches from the other
>> side? Nothing?
>
> One other thing that I can see being useful oc
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
> >> Are there cases where you do not want to either rebase nor merge?
> >> If so what do you want to do after "git pull" fetches from the o
On Thu, Sep 05, 2013 at 01:09:34PM -0400, Nicolas Pitre wrote:
> On Thu, 5 Sep 2013, Jeff King wrote:
>
> > There are basically two solutions:
> >
> > 1. Add a single-bit flag for "I am 0-padded in the real data". We
> > could probably even squeeze it into the same integer.
> >
> > 2.
On Thu, 5 Sep 2013, Nicolas Pitre wrote:
> If the path or name index is zero, this means the entry data is to be
> found inline rather than being located in the dictionary table. This is
> there to allow easy completion of thin packs without having to add new
> table entries which would have requi
"Uli Heller" writes:
> When using git-svn in combination with serf-1.2.1 core dumps are
> created on termination. This is caused by a bug in serf, a fix for
> the bug exists (see https://code.google.com/p/serf/source/detail?r=2146).
> Nevertheless, I think it makes sense to fix the issue within t
Nguyễn Thái Ngọc Duy writes:
> :(prefix) is in the long form. Suppose people pass :!foo with '!'
> being the short form of magic 'bar', the code will happily turn it to
> :(prefix..)!foo, which makes '!' part of the path and no longer a magic.
>
> The correct form must be ':(prefix..,bar)foo', b
Thanks. It seems that this was broken from the beginning at
77c72780 (Documentation: merging a tag is a special case,
2013-03-21).
Will apply.
--
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://vge
Joergen Edelbo writes:
> +proc get_remote_branch {} {
> + global push_branchtype push_branch push_new
> + set branch {}
> + switch -- $push_branchtype {
> + existing { set branch $push_branch }
> + create { set branch $push_new }
> + }
> + return $branch
> +}
> +
> +pr
i have a business proposal for you, write me back for more info.
-Sent from my ipad.
--
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
Jørgen Edelbo writes:
>> You say I can only push HEAD. I understand this that I have to stop work on C
>> (perhaps commit or stash any unfinished work), then checkout A, push it,
>> checkout B, push it, checkout C and unstash the unfinished work. If my
>> understanding is correct, the new restric
On Thu, 5 Sep 2013, SZEDER Gábor wrote:
> Hi,
>
>
> On Thu, Sep 05, 2013 at 02:19:28AM -0400, Nicolas Pitre wrote:
> > Let's create another dictionary table to hold the author and committer
> > entries. We use the same table format used for tree entries where the
> > 16 bit data prefix is conve
On Thu, 5 Sep 2013, Jeff King wrote:
> On Thu, Sep 05, 2013 at 11:18:24PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > > There are basically two solutions:
> > >
> > > 1. Add a single-bit flag for "I am 0-padded in the real data". We
> > > could probably even squeeze it into the same integer.
On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre wrote:
> Now the pack index v3 probably needs to be improved a little, again to
> accommodate completion of thin packs. Given that the main SHA1 table is
> now in the main pack file, it should be possible to still carry a small
> SHA1 table in the in
On Thu, 5 Sep 2013, Jeff King wrote:
> There are basically two solutions:
>
> 1. Add a single-bit flag for "I am 0-padded in the real data". We
> could probably even squeeze it into the same integer.
>
> 2. Have a "classic" section of the pack that stores the raw object
> bytes. Fo
On Thu, 5 Sep 2013, Duy Nguyen wrote:
> On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre wrote:
> > Now the pack index v3 probably needs to be improved a little, again to
> > accommodate completion of thin packs. Given that the main SHA1 table is
> > now in the main pack file, it should be possibl
On Thu, Sep 5, 2013 at 11:36 AM, Jeff King wrote:
> On Thu, Sep 05, 2013 at 10:00:39AM -0400, John Szakmeister wrote:
>
>> I went to clone a repository from GitHub today and discovered
>> something interesting:
>>
>> :: git clone https://github.com/liebke/incanter.git
>> Cloning into 'inca
On Thu, Sep 05, 2013 at 11:18:24PM +0700, Nguyen Thai Ngoc Duy wrote:
> > There are basically two solutions:
> >
> > 1. Add a single-bit flag for "I am 0-padded in the real data". We
> > could probably even squeeze it into the same integer.
> >
> > 2. Have a "classic" section of the pack
On 09/05/2013 11:36 AM, Jeff King wrote:
[...]
I haven't looked carefully at the pack v4 patches yet, but I suspect
that yes, it's still a problem. The premise of pack v4 is that we can do
better by not storing the raw git object bytes, but rather storing
specialized representations of the var
check-ignore currently shows how .gitignore rules would treat untracked
paths. Tracked paths do not generate useful output. This prevents
debugging of why a path became tracked unexpectedly unless that path is
first removed from the index with `git rm --cached `.
This option (-i, --no-index) simp
On Thu, Sep 5, 2013 at 10:36 PM, Jeff King wrote:
>> > This is going to screw up pack v4 (yes, someday I'll have the
>> > time to make it real).
>>
>> I don't know if this is still true, but given that patches are
>> being sent out about it, I thought it relevant.
>
> I haven't looked carefully at
On Thu, Sep 05, 2013 at 10:00:39AM -0400, John Szakmeister wrote:
> I went to clone a repository from GitHub today and discovered
> something interesting:
>
> :: git clone https://github.com/liebke/incanter.git
> Cloning into 'incanter'...
> remote: Counting objects: 10457, done.
>
You need at least four dashes in a line to have it recognized as listing
block delimiter by asciidoc.
Signed-off-by: Andreas Schwab
---
Documentation/git-merge.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
in
On 2013-09-04 18:59, Junio C Hamano wrote:
> "Philip Oakley" writes:
>
>> From: "Junio C Hamano"
>>> John Keeping writes:
>>>
I think there are two distinct uses for pull, which boil down to:
(1) git pull
>>> ...
>>> Peff already covered (1)---it is highly doubtful that a mer
"-" abbreviation is handy for "cherry-pick" like "checkout" and "merge".
It's also good for uniformity that a "-" stands as
the name of the previous branch where a branch name is
accepted and it could not mean any other things like stdin.
Signed-off-by: Hiroshige Umino
---
builtin/revert.c |
I went to clone a repository from GitHub today and discovered
something interesting:
:: git clone https://github.com/liebke/incanter.git
Cloning into 'incanter'...
remote: Counting objects: 10457, done.
remote: Compressing objects: 100% (3018/3018), done.
error: object 4946e1ba
Junio C Hamano writes:
> Peff already covered (1)---it is highly doubtful that a merge is
> "almost always wrong". In fact, if that _were_ the case, we should
> simply be defaulting to rebase, not failing the command and asking
> between merge and rebase like jc/pull-training-wheel topic did.
>
On Wed, Sep 4, 2013 at 10:45 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> Signed-off-by: Christian Couder
>> ---
>> Documentation/git-replace.txt | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
>> index a2
On Wed, Sep 4, 2013 at 10:44 PM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> If -f option, which means '--force', is used, we can allow an object
>> to be replaced with one of a different type, as the user should know
>> what (s)he is doing.
>>
>> Signed-off-by: Christian Couder
>> ---
Oops, this series forgot to update t7512-status-help.sh, which now
fails.
I'll send a reroll that updates it later (patch below).
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index 31a798f..0688d58 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -25,18 +25,18 @
On Thu, Sep 5, 2013 at 7:38 AM, John Keeping wrote:
> On Thu, Sep 05, 2013 at 07:01:03AM -0400, John Szakmeister wrote:
[snip]
>> So what I really want isn't quite rebase. I'm not sure any of the
>> proposed solutions would work. It'd be really nice to replay only the
>> mainline commits, withou
On Thu, Sep 05, 2013 at 07:01:03AM -0400, John Szakmeister wrote:
> On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano wrote:
> [snip]
> > When "git pull" stops because what was fetched in FETCH_HEAD does
> > not fast-forward, then what did _you_ do (and with the knowledge you
> > currently have, what
On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano wrote:
[snip]
> When "git pull" stops because what was fetched in FETCH_HEAD does
> not fast-forward, then what did _you_ do (and with the knowledge you
> currently have, what would you do)? In a single project, would you
> choose to sometimes rebase
Hi,
On Thu, Sep 05, 2013 at 02:19:28AM -0400, Nicolas Pitre wrote:
> Let's create another dictionary table to hold the author and committer
> entries. We use the same table format used for tree entries where the
> 16 bit data prefix is conveniently used to store the timezone value.
>
> In order
Compared to v2, this changes essentially:
* The prefix is actually disabled by default in this version. As a
consequence, the option is renamed to status.oldStyle.
* Since this is the default, the tests are updated to test the new
defaults. In a first patch, I'm setting status.oldStyle=true i
The --for-status option was an undocumented option used only by
wt-status.c, which inserted a header and commented out the output. We can
achieve the same result within wt-status.c, without polluting the
submodule command-line options.
This will make it easier to disable the comments from wt-statu
The previous commit set status.oldStyle file-wide in t7060-wtstatus.sh
and t7508-status.sh to make the patch small. However, now that
status.oldStyle is not the default, it is better to disable it in tests
so that the most common situation is also the most tested.
While we're there, move the "cat
Signed-off-by: Matthieu Moy
Signed-off-by: Junio C Hamano
---
builtin/stripspace.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index e981dfb..1259ed7 100644
--- a/builtin/stripspace.c
+++ b/builtin/stripspace.c
@@ -89,11
Historically, "git status" needed to prefix each output line with '#' so
that the output could be added as comment to the commit message. This
prefix comment has no real purpose when "git status" is ran from the
command-line, and this may distract users from the real content.
Disable this prefix c
No behavior change, but two slight code reorganization: argv_array_push
doesn't accept NULL strings, and duplicates its argument hence
summary_limit must be written to before being inserted into argv.
Signed-off-by: Matthieu Moy
Signed-off-by: Junio C Hamano
---
wt-status.c | 26 ++-
Am 9/5/2013 11:18, schrieb Jørgen Edelbo:
> Forgetting to push something that you have just
> completed is very far from what I am used to.
"Forgetting to push" is just one of many reasons why a branch that is not
equal to HEAD is not yet pushed... The new restriction is just too tight.
-- Hanne
> -Original Message-
> From: Johannes Sixt [mailto:j.s...@viscovery.net]
> Sent: 5. september 2013 10:57
>
> Please do not top-post.
>
> Am 9/5/2013 10:29, schrieb Jørgen Edelbo:
> > -Original Message- From: Johannes Sixt
> >> Am 9/2/2013 10:54, schrieb Joergen Edelbo:
> >>> Chang
Please do not top-post.
Am 9/5/2013 10:29, schrieb Jørgen Edelbo:
> -Original Message- From: Johannes Sixt
>> Am 9/2/2013 10:54, schrieb Joergen Edelbo:
>>> Changes done:
>>>
>>> Remove selection of branches to push - push always HEAD. This can be
>>> justified by the fact that this far t
Hi,
I am not quite sure what your concern is.
Anyway - I don't think you are any more restricted with this change than
before. If you currently work on a topic branch, and the same branch exists on
the chosen remote, then this branch will be the default one to push to.
BR Jørgen Edelbo
-
Matthieu Moy writes:
> Jens Lehmann writes:
>
>> Fine by me, what would you propose to clarify that? (Though I have the
>> suspicion that the explanation will be three years late ;-)
>
> I have no idea, as I do not understand the reason myself yet. I'm not a
> frequent user of submodules and not
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
> Are there cases where you do not want to either rebase nor merge?
> If so what do you want to do after "git pull" fetches from the other
> side? Nothing?
One other thing that I can see being useful occasionally is:
git rebase
2013/9/4 Junio C Hamano :
> kazuki saitoh writes:
>
>> Currently, git p4 does not support many of the view wildcards,
>> such as * and %%n. It only knows the common ... mapping, and
>> exclusions.
>>
>> Redo the entire wildcard code around the idea of
>> directly querying the p4 server for the ma
On Thu, Sep 05, 2013 at 02:19:54AM -0400, Nicolas Pitre wrote:
> ... replacing the equivalent open coded loop.
>
> Signed-off-by: Nicolas Pitre
> ---
> sha1_file.c | 14 +++---
> 1 file changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/sha1_file.c b/sha1_file.c
> index a298933.
92 matches
Mail list logo
