Dear Colleagues,
You are invited to upload your papers to our upcoming conferences
Paris, France, October 29-31, 2013. More details: http://www.wseas.org
Scientific Sponsors:
a) University of Zagreb, Croatia,
b) Music Academy "Studio Musica", Italy,
c) Constanta Maritime University, Romania,
On Fri, 6 Sep 2013, Nicolas Pitre wrote:
> On Fri, 6 Sep 2013, Duy Nguyen wrote:
>
> > In your code you reject sha1ref starting with zero too
> > (sha1_file.c::get_base_delta and packv4-parse.c::decode_entries)
>
> Yeah... because I wrote the minimum code to make it work with the
> current enco
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
On Fri, 6 Sep 2013, Junio C Hamano wrote:
> Nicolas Pitre writes:
>
> > OK. If I understand correctly, the committer time stamp is more
> > important than the author's, right?
>
> Yeah, it matters a lot more when doing timestamp based traversal
> without the reachability bitmaps.
>
> > ... m
It is Private
I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through the bank D.T.C Screen in
my office yesterday so I decided to use this very chance to know you. I
believe we should use every opportunity to know each other better.
Junio C Hamano wrote:
> Sebastian Schuberth writes:
>
> > For custom builds of Git it sometimes is inconvenient to annotate tags
> > because there simply is nothing to say, so do not require an annotation.
> >
> > Signed-off-by: Sebastian Schuberth
> > ---
>
> H, personally I'd actually wan
From: "Junio C Hamano"
"Philip Oakley" writes:
Does this have any impact on the alleged bug in `git bundle --all`
(which can then be cloned from) where the current HEAD ref wasn't
included in the bundle? Or am I mis-remembering?
Not "current HEAD ref", but "git clone" will fail to check out
On Sep 6, 2013, at 13:10, Sebastian Schuberth wrote:
For custom builds of Git it sometimes is inconvenient to annotate tags
because there simply is nothing to say, so do not require an
annotation.
It's not that hard to add -m "" to the command line:
git tag -a -m "" new-annotated-tag
if y
Linux Mint has an implementation of the highlight command (unrelated
to the one from http://www.andre-simon.de) that works as a simple
filter. The script uses 'sed' to add terminal colour escape codes
around text matching a regular expression. When t9500-*.sh attempts
to run "highlight --version",
On Fri, Sep 06, 2013 at 07:28:43PM +0200, Matthieu Moy wrote:
> >> FWIW, I had the same thought as Junio. I much prefer something like
> >> status.displayCommentPrefix for clarity and future-proofing.
> >
> > Sounds fine, but I don't understand why we'd want this to be an option
> > with a future
Nicolas Pitre writes:
> OK. If I understand correctly, the committer time stamp is more
> important than the author's, right?
Yeah, it matters a lot more when doing timestamp based traversal
without the reachability bitmaps.
> ... may I suggest keeping the tree reference first. That
> is ea
On Fri, Sep 06, 2013 at 11:42:02AM -0700, Junio C Hamano wrote:
> > It is not like we want to add a blank line at the end of each
> > element; it is rather that we want to have a blank line between each
> > element, so that they can have a bit of breathing room between them.
> >
> > The output loo
Jonathan Nieder writes:
> John Keeping wrote:
>> On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
>
>>> I somehow thought that rebase by default looked in the reflog to do
>>> exactly that. Perhaps I am not remembering correctly.
>>
>> It just does @{upstream} by default, which ten
Sebastian Schuberth writes:
> For custom builds of Git it sometimes is inconvenient to annotate tags
> because there simply is nothing to say, so do not require an annotation.
>
> Signed-off-by: Sebastian Schuberth
> ---
H, personally I'd actually want this to stay the way it is, or
even re
On Fri, Sep 6, 2013 at 6:30 AM, Joergen Edelbo wrote:
> Problem: It is not possible to push for Gerrit review as you will
> always try to push to "refs/heads/..." on the remote.
>
> Changes done:
>
> Add an option to select "Gerrit review" and a corresponding entry
> for a branch name. If this opt
Sebastian Schuberth writes:
> AsciiDoc's "link" is supposed to create hyperlinks for HTML output, so
> prefer a "link" to point to an HTML file instead of a text file if an HTML
> version of the file is being generated. For RelNotes, keep pointing to
> text files as no equivalent HTML files are g
John Keeping wrote:
> On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
>> I somehow thought that rebase by default looked in the reflog to do
>> exactly that. Perhaps I am not remembering correctly.
>
> It just does @{upstream} by default, which tends to get messy if the
> upstream
Junio C Hamano writes:
> Christian Couder writes:
>
>> +obj_type = sha1_object_info(object, NULL);
>> +repl_type = sha1_object_info(repl, NULL);
>
> That we can do this is somewhat curious
Note that this was a comment on the sha1_object_info() API, which,
unlike read_sha1_file() API
On Thu, 5 Sep 2013, Junio C Hamano wrote:
> 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 e
On Fri, Sep 6, 2013 at 7:32 PM, Junio C Hamano wrote:
> Johan Herland writes:
>> diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
>> index dee55e4..6c78fba 100755
>> --- a/t/t2024-checkout-dwim.sh
>> +++ b/t/t2024-checkout-dwim.sh
>> @@ -113,9 +113,9 @@ test_expect_success 'setup
Christian Couder writes:
> + obj_type = sha1_object_info(object, NULL);
> + repl_type = sha1_object_info(repl, NULL);
That we can do this is somewhat curious. If an object is replaced
with a different one, would it mean that this code snippet is
totally bogus?
type1 = sha1_obje
For custom builds of Git it sometimes is inconvenient to annotate tags
because there simply is nothing to say, so do not require an annotation.
Signed-off-by: Sebastian Schuberth
---
GIT-VERSION-GEN | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION
Andreas Krey writes:
> On Fri, 06 Sep 2013 10:46:24 +, Junio C Hamano wrote:
>> Andreas Krey writes:
>>
> ...
>> reason later, on-the-wire format should be prepared to support such
>> later enhancement. I think sending
>>
>> symref=HEAD:refs/heads/master
>
> Mirco-bikeshed: Should th
Andreas Krey writes:
> Can I assume that the only capability list is always on the
> first ref sent (as it is now)?
The capability list _could_ be sent more than once, and the
receiving end is prepared to accept such a stream. Everything
learned from an older capability list needs to be forgot
AsciiDoc's "link" is supposed to create hyperlinks for HTML output, so
prefer a "link" to point to an HTML file instead of a text file if an HTML
version of the file is being generated. For RelNotes, keep pointing to
text files as no equivalent HTML files are generated.
If appropriate, also update
On Fri, 06 Sep 2013 10:46:24 +, Junio C Hamano wrote:
> Andreas Krey writes:
>
...
> reason later, on-the-wire format should be prepared to support such
> later enhancement. I think sending
>
> symref=HEAD:refs/heads/master
Mirco-bikeshed: Should that possibly be
symref:HEAD=refs/
On Fri, 06 Sep 2013 10:56:51 +, Junio C Hamano wrote:
> Andreas Krey writes:
>
...
> > + if (symref) {
> > + ref->symref = xcalloc(symref_len + 1, 1);
> > + strncpy(ref->symref, symref, symref_len);
> > + }
...
>
> This looks utterly wr
On 2013-09-06 17:51, Konstantin Khomoutov wrote:
> I found this guide [1] very useful back in the time I tried to grok
> Mercurial.
>
> 1.
> http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/
Indeed, after reading it, that's the most sense I've been able to make
of Mercurial's s
On Mon, Sep 02, 2013 at 08:42:36PM +0100, Luke Diamand wrote:
> I guess you could try changing the OOM score for git-fast-import.
>
> change /proc//oomadj.
>
> I think a value of -31 would make it very unlikely to be killed.
>
> On 29/08/13 23:46, Pete Wyckoff wrote:
> >I usually just do "git p4
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> List of files in other sections ("Changes to be committed", ...) end with
>> a blank line.
>
> It is not like we want to add a blank line at the end of each
> element; it is rather that we want to have a blank line between each
> element, so tha
Junio C Hamano writes:
> Actually, "nothing added ..." is not a part of status proper; it
> will be clear if you run the command with comment prefix, whose
> output may end like so:
>
> # Untracked files:
> # (use "git add ..." to include in what will be committed)
> #
> #
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> List of files in other sections ("Changes to be committed", ...) end with
>>> a blank line.
>>
>> It is not like we want to add a blank line at the end of each
>> element; it is rather that we want to have a blank li
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> List of files in other sections ("Changes to be committed", ...) end with
>> a blank line.
>
> It is not like we want to add a blank line at the end of each
> element; it is rather that we want to have a blank line between each
> element, so tha
"Philip Oakley" writes:
> Does this have any impact on the alleged bug in `git bundle --all`
> (which can then be cloned from) where the current HEAD ref wasn't
> included in the bundle? Or am I mis-remembering?
Not "current HEAD ref", but "git clone" will fail to check out from
a bundle that do
Matthieu Moy writes:
> List of files in other sections ("Changes to be committed", ...) end with
> a blank line.
It is not like we want to add a blank line at the end of each
element; it is rather that we want to have a blank line between each
element, so that they can have a bit of breathing ro
Matthieu Moy writes:
>>> Untracked files:
>>> t/foo
>>> test-obj-pool
>>> test-string-pool
>>> test-treap
>>> test-url-normalize
>>>
>>> nothing added to commit but untracked files present
>>
>> The added blank line before "nothing added" soun
On Friday, September 06, 2013 11:19:02 am Junio C Hamano
wrote:
> mf...@codeaurora.org writes:
> > Object lookups should likely not get any slower than if
> > repack were not run, and the extra new pack might
> > actually help find some objects quicker.
>
> In general, having an extra pack, only
Andreas Krey writes:
> Signed-off-by: Andreas Krey
> ---
> connect.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/connect.c b/connect.c
> index a0783d4..98c4868 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -72,8 +72,8 @@ struct ref **get_remote_heads(i
Compared to v5:
* One test update I had forgotten. Now, the testsuite actually pass.
* Changed the config to status.displayCommentPrefix.
* Added the last patch, to add a missing blank line.
Matthieu Moy (6):
builtin/stripspace.c: fix broken indentation
wt-status: use argv_array API
submo
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
Andreas Krey writes:
> From: Junio C Hamano
>
> This implements the server side of protocol extension to show which branch
> the HEAD points at. The information is sent as a capability symref=.
>
> Signed-off-by: Junio C Hamano
> Signed-off-by: Andreas Krey
> ---
> upload-pack.c | 8 ++--
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 ++-
List of files in other sections ("Changes to be committed", ...) end with
a blank line. It is not the case with the "Untracked files" and "Ignored
files" sections. The issue become particularly visible after the #-prefix
removal, as the last line (e.g. "nothing added to commit but untracked
files p
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
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
Johan Herland writes:
> Signed-off-by: Johan Herland
> ---
> t/t2024-checkout-dwim.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
> index dee55e4..6c78fba 100755
> --- a/t/t2024-checkout-dwim.sh
> +++ b/t/t2024
mf...@codeaurora.org writes:
> Object lookups should likely not get any slower than if
> repack were not run, and the extra new pack might actually help
> find some objects quicker.
In general, having an extra pack, only to keep objects that you know
are available in other packs, will make _all_
Jonathan Nieder writes:
> Jeff King wrote:
>> On Thu, Sep 05, 2013 at 09:36:47PM +0200, Matthieu Moy wrote:
>
>>> I'm fine with any name actually (since it is enabled by default, people
>>> don't need to know the name to benefit from the new output). Maybe
>>> status.displayCommentPrefix was the
Jeff King wrote:
> On Thu, Sep 05, 2013 at 09:36:47PM +0200, Matthieu Moy wrote:
>> I'm fine with any name actually (since it is enabled by default, people
>> don't need to know the name to benefit from the new output). Maybe
>> status.displayCommentPrefix was the best name after all.
>
> FWIW, I
From: "Andreas Krey"
Ok, here are some patches that make git actually
check out the current remote branch when cloning.
Up to now this failed when there were two branches that pointed to
the HEAD commit of the remote repo, and git clone would sometimes
choose the wrong one as the HEAD ref isn't
Johan Herland writes:
> However, in addition to requiring a matching remote/refspec, I also
> (for reasons that are still unclear to me) added a requirement that
> the resulting remote ref name (to be stored into branch..merge)
> must start with "refs/heads/" (see the last line of
> branch.c:chec
On 6 September 2013 08:45, Ping Yin wrote:
> On Wed, Sep 4, 2013 at 2:08 PM, William Swanson wrote:
>> On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras
>> wrote:
>>> It has been discussed many times in the past that 'index' is not an
>>> appropriate description for what the high-level user doe
"Uli Heller" writes:
> On Fri, September 6, 2013 2:44 pm, Kyle J. McKay wrote:
> ...
>> In any case, I can now reproduce the problem (serf 1.3.1 still breaks
>> since it does not yet contain the fix and it is the most recent serf
>> release available).
>>
>> And the Git/SVN/Ra.pm fix does elimina
From: "Konstantin Khomoutov"
To: "Tim Chase"
On Thu, 5 Sep 2013 21:27:14 -0500
Tim Chase wrote:
[...]
Do any git users here have good "understanding Mercurial branches
for the git user" resources they've found helpful when working with
Mercurial? Preferably a "for dummies" resource with ill
Jeff King writes:
> # and have 472 and 59 different commits each, respectively.
> #
> # Untracked files:
[...]
> and have 472 and 59 different commits each, respectively.
> Untracked files:
Indeed, I forgot the else branch in wt_status_print_tracking:
if (s->display_comment_ch
On Fri, 6 Sep 2013, Duy Nguyen wrote:
> On Fri, Sep 6, 2013 at 8:25 PM, Nicolas Pitre wrote:
> > On Fri, 6 Sep 2013, Duy Nguyen wrote:
> >
> >> On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre wrote:
> >> > On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote:
> >> >
> >> >>
> >> >> Signed-off-by: Nguy
From: Junio C Hamano
Signed-off-by: Junio C Hamano
Signed-off-by: Andreas Krey
---
t/t5601-clone.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0629149..ccda6df 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -285,4 +285,15
Signed-off-by: Andreas Krey
---
connect.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index a0783d4..98c4868 100644
--- a/connect.c
+++ b/connect.c
@@ -72,8 +72,8 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t
src_len,
Ok, here are some patches that make git actually
check out the current remote branch when cloning.
Up to now this failed when there were two branches that pointed to
the HEAD commit of the remote repo, and git clone would sometimes
choose the wrong one as the HEAD ref isn't transmitted in all
tra
From: Junio C Hamano
This implements the server side of protocol extension to show which branch
the HEAD points at. The information is sent as a capability symref=.
Signed-off-by: Junio C Hamano
Signed-off-by: Andreas Krey
---
upload-pack.c | 8 ++--
1 file changed, 6 insertions(+), 2 de
Dave Williams writes:
> 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 i
Jiang Xin writes:
> 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
On Wed, Sep 4, 2013 at 2:08 PM, William Swanson wrote:
> On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras
> wrote:
>> It has been discussed many times in the past that 'index' is not an
>> appropriate description for what the high-level user does with it, and
>> it has been agreed that 'staging
On Thu, 5 Sep 2013 21:27:14 -0500
Tim Chase wrote:
[...]
> Do any git users here have good "understanding Mercurial branches
> for the git user" resources they've found helpful when working with
> Mercurial? Preferably a "for dummies" resource with illustrations &
> comparison charts so I can se
On Fri, Sep 6, 2013 at 8:25 PM, Nicolas Pitre wrote:
> On Fri, 6 Sep 2013, Duy Nguyen wrote:
>
>> On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre wrote:
>> > On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote:
>> >
>> >>
>> >> Signed-off-by: Nguyn Thái Ng÷c Duy
>> >> ---
>> >> Should be up to date
On Fri, 6 Sep 2013, Duy Nguyen wrote:
> On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre wrote:
> > On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote:
> >
> >>
> >> Signed-off-by: Nguyn Thái Ng÷c Duy
> >> ---
> >> Should be up to date with Nico's latest implementation and also cover
> >> additions
On 2013-09-06 12:39, Tay Ray Chuan wrote:
> First: recognize Mercurial's branches are entirely different beasts
> from Git's. They just happen to be given a same sequence of
> characters, b-r-a-n-c-h. The similarities end there!
Yeah, I'm trying to create a mental map between what Git means by
bra
On Fri, 6 Sep 2013, Duy Nguyen wrote:
> 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 ta
On Fri, September 6, 2013 2:44 pm, Kyle J. McKay wrote:
> On Sep 6, 2013, at 05:06, Uli Heller wrote:
>>> I'm using Git built from master (57e4c1783). I see the same behavior
>>> both with and without the SVN/Ra.pm patch (and using both bulk
>>> updates
>>> and skelta mode). Does the problem not
On Fri, 06 Sep 2013 13:41:30 +, Andreas Krey wrote:
...
> If I run the exact same commands in a shell script they succeed,
> in t5601-clone.sh the clone step seems to fail, and I have no
> clue where to look for a clue.
Oh, never mind. --verbose shows that the test is borked;
it tries a checko
On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
I am Cc'ing Kyle McKay who apparently had some experience working
with git-svn with newer svn that can only use serf, hoping that we
can get an independent opinion/test just to be sure.
On Sep 3, 2013, at 00:35, Uli Heller wrote:
When using git-s
On Sep 6, 2013, at 05:06, Uli Heller wrote:
I'm using Git built from master (57e4c1783). I see the same behavior
both with and without the SVN/Ra.pm patch (and using both bulk
updates
and skelta mode). Does the problem not happen on a git svn clone? I
can force serf back to version 1.2.1 an
On Fri, September 6, 2013 1:46 pm, Kyle J. McKay wrote:
> On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
>> "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
>
On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
"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
On Tue, 03 Sep 2013 08:33:39 +, Junio C Hamano wrote:
...
> Reading the patch series from 2008 again, I do agree with J6t's
> comment that it should be just a regular capability,
I've implemented it as a 'sym=refs/heads/foo' capability.
It actually makes the patch series a lot shorter; the onl
Problem: It is not possible to push for Gerrit review as you will
always try to push to "refs/heads/..." on the remote.
Changes done:
Add an option to select "Gerrit review" and a corresponding entry
for a branch name. If this option is selected, push the changes to
"refs/for//". In this way the
Signed-off-by: Johan Herland
---
t/t2024-checkout-dwim.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index dee55e4..6c78fba 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -113,9 +113,9 @@ tes
Make it easier for readers to find the actual config variables that
implement the "upstream" relationship.
Suggested-by: Per Cederqvist
Signed-off-by: Johan Herland
---
In a private email exchange, Per noted that it was hard for someone reading
the git-branch docs to grasp what really happens w
From: Per Cederqvist
When creating an upstream relationship, we use the configured remotes and
their refspecs to determine the upstream configuration settings
branch..remote and branch..merge. However, if the matching
refspec does not have refs/heads/ on the remote side, we end
up rejecting the m
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of
refs/remotes/*), we changed the rules for what is considered a valid tracking
branch (a.k.a. upstream branch). We now use the configured remotes and their
refspecs to determine whether a proposed tracking branch is in fact wi
We're testing that trying to --track a ref that is not covered by any remote
refspec should fail. For that, we want to have refs/remotes/local/master
present, but we also want the remote.local.fetch refspec to NOT match
refs/remotes/local/master (so that the tracking setup will fail, as intended).
Hi,
Per Cederqvist alerted me to a change in v1.8.3.2 that broke his
build/test infrastructure. Specifically, before 41c21f2 (branch.c:
Validate tracking branches with refspecs instead of refs/remotes/*)
Git allowed a local branch to --track anything within refs/remotes/*,
and in 41c21f2, I change
On Thu, 5 Sep 2013 14:43:52 -0700 (PDT)
Eyal Zinder wrote:
[...]
> The problem I faced later on was in parallel development, when
> changes were made to a file in one repository, and at the same time
> other changes made to the same file in another repository.. I
> couldh't push changes from the
On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre wrote:
> On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote:
>
>>
>> Signed-off-by: Nguyn 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:
>>
>>
Junio C Hamano < gits...@pobox.com> writes:
> Isn't the right way to improve the situation to let the command line tools
> know how the user wants to push things out and just have Git-GUI delegate
> the choice to the underlying "git push"?
Thank you for all the constructive feedback. I realize th
Am 9/5/2013 23:43, schrieb Eyal Zinder:
> 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 with no SSH / HTTP accessibility. Basically each developer
> will have their own copy of the project
86 matches
Mail list logo
