On Thu, Jul 24, 2014 at 8:45 PM, Johannes Sixt wrote:
> Am 23.07.2014 23:28, schrieb Christoph Bonitz:
>> - test "$src" = file10 || test "$src" = file11 &&
>> + test "$src" = file2 || test "$src" = file10 || test "$src" = file11 &&
>
> You can't test for alternatives in this way. It's already wron
On Fri, Jul 25, 2014 at 12:05 AM, Junio C Hamano wrote:
> Johannes Sixt writes:
>> I see a few other no-nos in the context of the changes, in particular,
>> pipelines where git is not the last command; these would not catch
>> failures in the git commands. But a fix for that is certainly outside
On Monday, July 28, 2014, Nguyễn Thái Ngọc Duy wrote:
> Instead of reading the index from disk and worrying about disk
> corruption, the index is cached in memory (memory bit-flips happen
> too, but hopefully less often). The result is faster read.
>
> The biggest gain is not having to verify the
Nico Williams writes:
> On Tue, Jul 29, 2014 at 4:58 AM, Sergei Organov wrote:
>> Nico Williams writes:
>>> That exception aside, keeping all local commits "on top" by always
>>> rebasing them onto the upstream is extremely useful: a) in simplifying
>>> conflict resolution, b) making it easy to
The test case "--amend option copies authorship" specifies that the
git-commit option `--amend` uses the authorship of the replaced
commit for the new commit. Add the omitted check that this property
actually holds.
Signed-off-by: Fabian Ruch
---
Without the check, the test case succeeds even wit
On Tue, Jul 29, 2014 at 12:56:24PM -0700, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > When utf8_width(&src) is called with *src == NULL (because the
> > source string ends with an ansi sequence),
>
> I am not sure what you mean by "because" here. Do you mean somebody
> (who?) de
On Wed, Jul 30, 2014 at 3:51 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> builtin/checkout.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/builtin/checkout.c b/builtin/checkout.c
>> index 173aab1..4fbb
On Wed, Jul 30, 2014 at 3:08 PM, Eric Sunshine wrote:
>> +static void share_index(struct index_state *istate, struct index_shm *is)
>> +{
>> + void *new_mmap;
>> + if (istate->mmap_size <= 20 ||
>> + hashcmp(istate->sha1,
>> + (unsigned char *)istate->mmap +
Greetings from Russia, comrads!
I've noticed something strange with git status when replacing a folder with
symlink to another folder.
There is a git repo with script with demo in the attachment.
Yours sincerely,
NickKolok aka Nikolay Avdeev.
Доброго времени суток, товарищи!
При замене папки
My name is Carlos Ramirez I am lawyer here in Madrid Spain. I want to transfer
an abandoned sum of 3.5 Millions USD to your account.50% will be for you. No
risk involved. Contact me for more details.
Kindly reply me back to my alternative email address ( carlos...@aol.com )
Regards
Carlos
[PATCH v4]: Tiny style nits corrected. Patch 2/5 has been totally reworked.
One thing to check is if the config variables I changed in the series
are single valued or multi valued. Though I have tried to ascertain
if the variable was single valued or not by reading the docs
Use `git_config_get_string()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra
---
branch.c | 24
1 file changed, 4 insertions(+), 20 deletions(-)
diff --git a/branch.c b/branch.c
index 4
Use `git_config_get_value_multi()` instead of `git_config()` to take
advantage of the config-set API which provides a cleaner control flow,
also previously 'string_list_add_refs_by_glob()' was called even when
the retrieved value was NULL, correct it while we are at it.
Signed-off-by: Tanay Abhra
Use `git_config_get_value()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra
---
pager.c | 40 +---
1 file changed, 13 insertions(+), 27 deletions(-)
diff --git a/pager.c b/pa
Use `git_config_get_string()` instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra
---
alias.c | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/alias.c b/alias.c
index 758
Use `git_config_get_*()` family instead of `git_config()` to take advantage of
the config-set API which provides a cleaner control flow.
Signed-off-by: Tanay Abhra
---
imap-send.c | 61 +++--
1 file changed, 27 insertions(+), 34 deletions(-
Tanay Abhra writes:
> [PATCH v4]: Tiny style nits corrected. Patch 2/5 has been totally reworked.
> One thing to check is if the config variables I changed in the series
> are single valued or multi valued. Though I have tried to ascertain
> if the variable was single valued or
On 7/30/2014 7:16 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> [PATCH v4]: Tiny style nits corrected. Patch 2/5 has been totally reworked.
>> One thing to check is if the config variables I changed in the series
>> are single valued or multi valued. Though I have tried to ascert
Tanay Abhra writes:
> - git_config(notes_display_config, &load_config_refs);
> + if (load_config_refs) {
> + values = git_config_get_value_multi("notes.displayref");
> + if (values) {
> + for (i = 0; i < values->nr; i++) {
> +
On 7/30/2014 7:43 PM, Matthieu Moy wrote:
> Tanay Abhra writes:
>
>> -git_config(notes_display_config, &load_config_refs);
>> +if (load_config_refs) {
>> +values = git_config_get_value_multi("notes.displayref");
>> +if (values) {
>> +for (i =
Tanay Abhra writes:
> int read_branch_desc(struct strbuf *buf, const char *branch_name)
> {
> - struct branch_desc_cb cb;
> + char *v = NULL;
> struct strbuf name = STRBUF_INIT;
> strbuf_addf(&name, "branch.%s.description", branch_name);
> - cb.config_name = name.buf;
>
Tanay Abhra writes:
> On 7/30/2014 7:43 PM, Matthieu Moy wrote:
>> Tanay Abhra writes:
>>
>>> - git_config(notes_display_config, &load_config_refs);
>>> + if (load_config_refs) {
>>> + values = git_config_get_value_multi("notes.displayref");
>>> + if (values) {
>>> +
Tanay Abhra writes:
> Yes you are right, there is a call to git_die_config() also in the series. I
> will add
> the info in the next reroll.
If unsure, rebase your branch locally on the commit on which it is meant
to apply, and check that it works for you.
> Also, any thoughts on what to do wi
List, please see here an overview and ordering of the ref transaction
patch series.
These series build on each other and needs to be applied in the order
listed below.
rs/ref-transaction-0
---
Early part of the "ref transaction" topic.
* rs/ref-transaction-0:
Continued: this message only covers the third part (out of the four sections).
| Integrator[[Integrator]]
|
|
| A fairly central person acting as the integrator in a group
| project receives changes made by others, reviews and integrates
| them and publishes the result fo
On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov wrote:
> Nico Williams writes:
>> Local merge commits mean that you either didn't rebase to keep all
>> your local commits on top of the upstream, or that you have multiple
>> upstreams (the example exception I gave).
>
> I rather have multiple (rel
Nguyễn Thái Ngọc Duy writes:
> The series has entered 'next' so I can't replace patches any more.
> Besides the brown paper bag fixes, checkout now rejects if a branch is
> already checked out elsewhere.
I do not think we would want to rush the entire series to 'master'
before the upcoming relea
Michael J Gruber writes:
> As an error message that is completely sufficient.
>
> The advice messages are meant to teach the user about the normal parts
> of the toolchest to use in a situation of "conflict", aren't they?
Not really. They are to remind (to those who learned but forgot)
and to h
Duy Nguyen writes:
>> > it returns 0 and steps 'src' by one.
>>
>> Here "it" refers to utf8_width()? Who steps 'src' by one?
>
> utf8_width() steps 'src'.
>
>>
>> Ahh, did you mean *src == NUL, i.e. "already at the end of the
>> string"?
>
> Yes.. I guess you have a better commit message prep
Please don't do this:
Content-Type: multipart/related; boundary="MIME delimiter for
sendEmail-128858.688128279"
--
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
Nico Williams writes:
> On Wed, Jul 30, 2014 at 3:42 AM, Sergei Organov wrote:
>> Nico Williams writes:
>>> Local merge commits mean that you either didn't rebase to keep all
>>> your local commits on top of the upstream, or that you have multiple
>>> upstreams (the example exception I gave).
>
Junio C Hamano writes:
> Michael J Gruber writes:
>
>> As an error message that is completely sufficient.
>>
>> The advice messages are meant to teach the user about the normal parts
>> of the toolchest to use in a situation of "conflict", aren't they?
>
> Not really. They are to remind (to tho
Christoph Bonitz writes:
> Apart from your change and the word wrap adjustments suggested by
> Pete, would the following also make sense, to fix the other flaw
> Johannes pointed out? With regards to failing, git diff-tree should be
> idempotent. I think those are the two occurrences in this file
On Tue, Jul 29, 2014 at 2:09 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> + /*
>> + * Always copy loose refs that are to be deleted to the packed refs.
>> + * If we are updating multiple refs then copy all non symref refs
>> + * to the packed refs too.
>> + */
On Tue, Jul 29, 2014 at 2:11 PM, Junio C Hamano wrote:
> Ronnie Sahlberg writes:
>
>> + packed = get_packed_refs(&ref_cache);;
>
> s/;;/;/; ;-)
>
> Sorry, I couldn't resist the urge to type many semicolons ;-)
Fixed, thanks!
--
To unsubscribe from this list: send the line "unsubscrib
Tony Finch writes:
> Explicitly mention that leaving imap.authMethod unset makes
> git imap-send use the basic IMAP plaintext LOGIN command.
> ---
> Documentation/git-imap-send.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-imap-send.txt b/Docume
Junio C Hamano writes:
> Jeff King writes:
>
>> When you list stashes, you can provide arbitrary git-log
>> options to change the display. However, adding just "-p"
>> does nothing, because each stash is actually a merge commit.
>>
>> This implementation detail is easy to forget, leading to
>> c
Fabian Ruch writes:
> The test case "--amend option copies authorship" specifies that the
> git-commit option `--amend` uses the authorship of the replaced
> commit for the new commit. Add the omitted check that this property
> actually holds.
>
> Signed-off-by: Fabian Ruch
> ---
> Without the c
Eric Sunshine writes:
>> char *resolve_refdup(const char *ref, unsigned char *sha1, int reading, int
>> *flag)
>> {
>> - const char *ret = resolve_ref_unsafe(ref, sha1, reading, flag);
>> - return ret ? xstrdup(ret) : NULL;
>> + struct strbuf buf = STRBUF_INIT;
>> + if
Signed-off-by: Thomas Ackermann
---
Documentation/RelNotes/2.1.0.txt | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/RelNotes/2.1.0.txt b/Documentation/RelNotes/2.1.0.txt
index be598ad..e958498 100644
--- a/Documentation/RelNotes/2.1.0.txt
+++ b/Documentation/RelNotes/2.1.0.t
Signed-off-by: Ronnie Sahlberg
---
refs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 9c813f9..3e98ca1 100644
--- a/refs.c
+++ b/refs.c
@@ -2574,8 +2574,10 @@ int repack_without_refs(const char **refnames, int n,
struct strbuf *err)
/* Rem
In many places in the code we do not have access to the individual fields
in the committer data. Instead we might only have access to prebaked data
such as what is returned by git_committer_info() containing a string
that consists of email, timestamp, zone etc.
This makes it inconvenient to use tr
Change refs.c to use a single transaction to copy/rename both the refs and
its reflog. Since we are no longer using rename() to move the reflog file
we no longer need to disallow rename_ref for refs with a symlink for its
reflog so we can remove that test from the testsuite.
Change the function to
This patch series adds support for using transactions and atomic renames.
It focuses on what needs to be done in order to support fully atomic
and rollbackable renames that may or may not involve name conflicts.
By performing the actual delete old/create new via a single operation to
the packed r
Change lock_ref_sha1_basic to return an error instead of dying when
we fail to lock a file during a transaction.
This function is only called from transaction_commit() and it knows how
to handle these failures.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 7 +--
1 file changed, 5 insertions(+
Make the deletion of refs during a transaction more atomic.
Start by first copying all loose refs we will be deleting to the packed
refs file and then commit the packed refs file. Then re-lock the packed refs
file to stop anyone else from modifying these refs and keep it locked until
we are finishe
When we are updating more than one single ref, i.e. not a commit, then
write the updated refs directly to the packed refs file instead of writing
them as loose refs.
Change clone to use a transaction instead of using the packed refs API.
This changes the behavior of clone slightly. Previously clon
write_ref_sha1 tries to update the reflog while updating the ref.
Move these reflog changes out into its own function so that we can do the
same thing if we write a sha1 ref differently, for example by writing a ref
to the packed refs file instead.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 62
Transactions now use packed refs when deleting multiple refs so there is no
need to do it manually from remote.c any more.
Signed-off-by: Ronnie Sahlberg
---
builtin/remote.c | 69 +++-
1 file changed, 38 insertions(+), 31 deletions(-)
diff --
This is a small patch series that continues ontop of the
ref-transactions-rename series I posted earlier today.
This series expands the use of the packed refs file to make multi-ref
updates much more atomic. Additionally it allows us to continue pushing
external caller to use transactions instead
Signed-off-by: Ronnie Sahlberg
---
refs.c | 2 +-
refs.h | 3 ---
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index bacce94..fc445e8 100644
--- a/refs.c
+++ b/refs.c
@@ -2538,7 +2538,7 @@ static int curate_packed_ref_fn(struct ref_entry *entry,
void *cb_data)
/
We no longer need to expose the lock/add/commit/rollback functions
for packed refs anymore so make them static and remove them from the
public api.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 8
refs.h | 30 --
2 files changed, 4 insertions(+), 34 deletions(
The latest maintenance release Git v2.0.4 is now available at
the usual places.
This is primarily to fix a regression of "git diff-tree" in v2.0.2.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.0.4'
tag a
On Wed, Jul 30, 2014 at 12:43:09PM -0700, Junio C Hamano wrote:
> > "git log --cc" is one of the things I wanted for a long time to fix.
> > When the user explicitly asks "--cc", we currently ignore it, but
> > because we know the user wants to view combined diff, we should turn
> > "-p" on automa
On Tue, Jul 29, 2014 at 12:27:07PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I think that is my point, though. The user is _not_ aware that the
> > commit in question is a merge. They stashed some stuff, and now they
> > want to see the result. I'd like to show them a vanilla commit
On Tue, Jul 29, 2014 at 11:13:37AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > ... People might be doing things like "git stash show | git
> > apply", and would want to ignore the index content ...
>
> FWIW, that is exactly how I use "git stash show -p" most of the time.
Like I said
On Tue, Jul 29, 2014 at 11:23:16AM -0700, Junio C Hamano wrote:
> I see you added --simplify-combined-diffs to avoid breaking "log",
> so that is not too bad, but I am still unsure what should happen
> when the first parent and the result is the same and only the second
> parent is different (i.e.
On Wed, Jul 30, 2014 at 5:17 PM, Jeff King wrote:
>
> Like I said, I'm iffy on this part of the series for that reason. But
> I'm curious: what do you think should happen in such a use case when
> there are staged contents in the index? Right now we completely ignore
> them.
I think ignoring is a
On Mon, 2014-07-28 at 19:03 +0700, Nguyễn Thái Ngọc Duy wrote:
> +# Define HAVE_SHM if you platform support shm_* functions in librt.
s/you/your/
> +static void free_index_shm(struct index_shm *is)
Does not actually free its argument; should be release_index_shm.
--
To unsubscribe from this
Hi:
> 2014-07-23 19:55 GMT+08:00 Duy Nguyen :
> On Tue, Jul 22, 2014 at 12:04 AM, Junio C Hamano
> wrote:
> > Duy Nguyen writes:
[snip]
> > OK, we should center these efforts around the strbuf_getcwd() topic,
> > basing the other topic on realpath() and this one on it then?
>
> OK.
> --
> Duy
60 matches
Mail list logo
