I'm running 1.9.5.msysgit.1, but this is a general git question...
Upon returning from a vacation, I was looking at what people had been
up to, and discovered on merge in which a colleague had resolved a merge
incorrectly. It turns out that he has pushed *many* merges over the past
year which had
"brian m. carlson" writes:
> Use struct object_id in three fields in struct ref and convert all the
> necessary places that use it.
>
> Signed-off-by: brian m. carlson
> ---
> builtin/clone.c| 16 +++---
> builtin/fetch-pack.c | 4 ++--
> builtin/fetch.c| 50 +
Thanks. Will replace and wait for comments from others.
--
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
Brian Vandenberg writes:
> Would you be less doubtful about adding a lower-level hook for
> update-ref? Or in lieu of that, a config option that can affect the
> behavior of its "-m" and "-d" options?
Not really.
Those who want to bypass your policy can use "vi .git/packed-refs"
and/or "rm .gi
We remove the extracted functions and directly parse into and read out
of the cache. This allows us to have one unified way of accessing
submodule configuration values specific to single submodules. Regardless
whether we need to access a configuration from history or from the
worktree.
Signed-off-
In a superproject some commands need to interact with submodules. They
need to query values from the .gitmodules file either from the worktree
of from certain revisions. At the moment this is quite hard since a
caller would need to read the .gitmodules file from the history and then
parse the value
We should not die when reading the submodule config cache since the user
might not be able to get out of that situation when the configuration is
part of the history.
We should handle this condition later when the value is about to be
used.
Signed-off-by: Heiko Voigt
---
builtin/fetch.c
This is one step towards using the new configuration API. We just
extract these functions to make replacing the actual code easier.
Signed-off-by: Heiko Voigt
---
submodule.c | 142 +---
1 file changed, 97 insertions(+), 45 deletions(-)
di
There have been no code changes in since the last iteration. I changed
the title for the first patch since I realized that the cache is just an
implementation detail and what we are really doing is to provide a new
API for reading values from .gitmodules. I also added an extra paragraph
in the comm
On 15/06, Junio C Hamano wrote:
Johannes Löthberg writes:
else {
+ namespace = get_git_namespace();
+ if (strcmp(namespace, "refs/namespaces/")) {
+ strbuf_addf(&namespaced_head_buf, "%s%s", namespace,
"HEAD");
+ n
On Mon, Jun 15, 2015 at 2:22 PM, Junio C Hamano wrote:
> I am ultra-doubtful at this point ;-)
>
> For one thing, update-ref is not a tool that is exclusive to
> receiving object transfer aka receive-pack, so it makes no sense for
> it to pay attention to post-update.
I was a little dubious about
On Tue, Jun 16, 2015 at 12:57 AM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> The PARSE_OPT_HIDDEN flag is removed below. This means that "--with"
>> will appear in the "git tag -h" output, which means that "--with"
>> should appear in the documentation...
>> The commit message may also
Johannes Löthberg writes:
> On 13/06, Johannes Löthberg wrote:
>>Git should fail to clone if trying to clone from an non-existing
>>ref namespace, since it's the same as a non-existing repository
>>
>>Signed-off-by: Johannes Löthberg
>>---
>>
>>Changes since v1:
>>
>>* Fixed the namespace check,
Johannes Löthberg writes:
> diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> index d2ec52b..0c18c92 100644
> --- a/builtin/receive-pack.c
> +++ b/builtin/receive-pack.c
> @@ -864,7 +864,9 @@ static const char *update(struct command *cmd, struct
> shallow_info *si)
> {
> cons
On Tue, Jun 16, 2015 at 12:19 AM, Junio C Hamano wrote:
> karthik nayak writes:
>
>> The previous version of the patch can be found at :
>> http://thread.gmane.org/gmane.comp.version-control.git/271423
>>
>> Changes :
>> * Removed an unnecessary commit (v7 3/12)
>> * Change a comment in 01/11 (v8
Brian Vandenberg writes:
> From: Junio C Hamano
> Date: 2006-10-08 15:00:32
> Petr Baudis writes:
>
>>> Someone raised a concern that the update and post-update hooks are not
>>> invoked at fetch time in the similar way as they are invoked at push
>>> time, and the idea sort of makes sense. But
Thanks, both. Let's advance this one to 'next' soonish.
--
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
Jeff King writes:
> Subject: Revert "stash: require a clean index to apply"
>
> This reverts commit ed178ef13a26136d86ff4e33bb7b1afb5033f908.
Thanks.
--
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 ht
"Simon A. Eugster" writes:
> ---
- Lack of explanation as to why this is a good thing.
- Lack of sign-off.
Why is there still 1/2, if its effect is wholly annulled by a
subsequent step 2/2?
> Documentation/git-checkout.txt | 39 +++
> 1 file changed, 35 ins
From: Junio C Hamano
Date: 2006-10-08 15:00:32
Petr Baudis writes:
>> Someone raised a concern that the update and post-update hooks are not
>> invoked at fetch time in the similar way as they are invoked at push
>> time, and the idea sort of makes sense. But this patch goes further - it
>> make
On Mon, Jun 15, 2015 at 11:35 AM, Jeff King wrote:
>
> I think the real benefit of naming parameters is that you can talk about
> "fn" and "cb_data" by name in the docstring[1].
Yes, I would think it is a very sensible thing to do, if a patch that adds
docstring adds names so that the documentati
On Mon, Jun 15, 2015 at 11:39 AM, Jeff King wrote:
> On Mon, Jun 15, 2015 at 11:35:28AM -0700, Junio C Hamano wrote:
>
>> But the log message puzzles me. Didn't refs that cannot be deleted
>> cause the original to fail? After repacking without these refs, it
>> called delete-ref, and a failure t
"git clean" uses resolve_gitlink_ref() to check for the presence of
nested git repositories, but it has the drawback of creating a
ref_cache entry for every directory that should potentially be
cleaned. The linear search through the ref_cache list causes a massive
performance hit for large number o
This is v8 of this series. v7 can be found here:
http://thread.gmane.org/gmane.comp.version-control.git/271220
Changes in v8:
* change name and type of file size limit variable in read_git_file_gently
Erik Elfström (5):
setup: add gentle version of read_gitfile
setup: sanity check file siz
The tests are run in dry-run mode to avoid having to restore the test
directories for each timed iteration. Using dry-run is an acceptable
compromise since we are mostly interested in the initial computation
of what to clean and not so much in the cleaning it self.
Signed-off-by: Erik Elfström
--
Signed-off-by: Erik Elfström
---
t/t7300-clean.sh | 142 +++
1 file changed, 142 insertions(+)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 99be5d9..fbfdf2d 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -455,6 +455,148 @@ te
read_gitfile will die on most error cases. This makes it unsuitable
for speculative calls. Extract the core logic and provide a gentle
version that returns NULL on failure.
The first usecase of the new gentle version will be to probe for
submodules during git clean.
Helped-by: Junio C Hamano
Hel
read_gitfile_gently will allocate a buffer to fit the entire file that
should be read. Add a sanity check of the file size before opening to
avoid allocating a potentially huge amount of memory if we come across
a large file that someone happened to name ".git". The limit is set to
a sufficiently u
This round looks good to me.
Thanks all.
--
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
Christian Couder writes:
> The PARSE_OPT_HIDDEN flag is removed below. This means that "--with"
> will appear in the "git tag -h" output, which means that "--with"
> should appear in the documentation...
> The commit message may also want to tell that with is not hidden any more.
Or why is it a
On Mon, Jun 15, 2015 at 11:39:07AM -0700, Junio C Hamano wrote:
> Michael Haggerty writes:
>
> > It would seem to make sense to add a test here that there are no
> > existing references, because that is how the function *should* be
> > used. But in fact, the "testgit" remote helper appears to ca
Michael Haggerty writes:
> + struct ref_transaction *t;
> + struct strbuf err = STRBUF_INIT;
> +
> + t = ref_transaction_begin(&err);
> + if (!t)
> + die(err.buf);
Yikes, and sorry for sending three messages without consolidating
against the same patch, but
d
karthik nayak writes:
> The previous version of the patch can be found at :
> http://thread.gmane.org/gmane.comp.version-control.git/271423
>
> Changes :
> * Removed an unnecessary commit (v7 3/12)
> * Change a comment in 01/11 (v8)
>
> Total changes :
>
> Makefile |1 +
> buil
Michael Rappazzo writes:
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 1d01baa..8ddab77 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -213,6 +213,9 @@ rebase.autoSquash::
> rebase.autoStash::
> If set to true enab
On Mon, Jun 15, 2015 at 11:35:28AM -0700, Junio C Hamano wrote:
> But the log message puzzles me. Didn't refs that cannot be deleted
> cause the original to fail? After repacking without these refs, it
> called delete-ref, and a failure to delete or commit the deletion
> would have hit the error
Michael Haggerty writes:
> It would seem to make sense to add a test here that there are no
> existing references, because that is how the function *should* be
> used. But in fact, the "testgit" remote helper appears to call it
> *after* having set up refs/remotes//HEAD and
> refs/remotes//master
Michael Haggerty writes:
> This will result in errors being emitted for references that can't be
> deleted, but that is a good thing.
>
> Signed-off-by: Michael Haggerty
> ---
> builtin/remote.c | 11 ++-
> 1 file changed, 2 insertions(+), 9 deletions(-)
>
> diff --git a/builtin/remote.
On Mon, Jun 15, 2015 at 11:13:22AM -0700, Junio C Hamano wrote:
> > @@ -78,15 +170,15 @@ typedef int each_ref_fn(const char *refname,
> > * modifies the reference also returns a nonzero value to immediately
> > * stop the iteration.
> > */
> > -extern int head_ref(each_ref_fn, void *);
> > +
Michael Haggerty writes:
> Subject: Re: [PATCH v2 05/12] delete_refs(): improve error message
I'd call this "make error message more generic".
> Change the error message from
>
> Could not remove branch %s
>
> to
>
> could not remove reference %s
>
> * s/branch/reference/. This change m
On Mon, Jun 15, 2015 at 10:42:18AM -0700, Junio C Hamano wrote:
> > I dunno. With respect to the original patch, I am OK if we just want to
> > revert it. This area of stash seems a bit under-designed IMHO, but if
> > people were happy enough with it before, I do not think the safety
> > benefit f
I've recently had an issue where running "gitk --all" has stopped
working on a large repository of mine. Gitk's main window appears with
all of the sections empty, and a modal tells me 'Error executing git
log: couldn't execute "git": argument list too long'.
I'm on OS X, and am running git versio
Michael Haggerty writes:
> delete_ref() uses a different convention for its old_sha1 parameter
> than, say, ref_transaction_delete(): NULL_SHA1 means not to check the
> old value. Make this fact a little bit clearer in the code by handling
> it in explicit, commented code rather than burying it i
Michael Haggerty writes:
> Some functions from the refs module were still declared in cache.h.
> Move them to refs.h.
Yay. But...
> Add some parameter names where they were missing.
... I do not think some of this is a good change.
> @@ -78,15 +170,15 @@ typedef int each_ref_fn(const char *r
Michael Haggerty writes:
> + struct ref_transaction *t;
> + struct strbuf err = STRBUF_INIT;
> +
> + t = ref_transaction_begin(&err);
> + if (!t)
> + die(err.buf);
>
> for (r = local_refs; r; r = r->next) {
> if (!r->peer_ref)
>
Paul Tan writes:
>> The scripted Porcelain is spawned after applying patches 1-3 from
>> here, when you do not have _GIT_USE_BUILTIN_AM exported. Haven't
>> RUN_SETUP code did its thing by that time?
>
> Ah right, the RUN_SETUP code would have chdir()-ed to the working
> directory root, so git-a
Jeff King writes:
> It seems like applying a stash made with "-k" is fundamentally
> misdesigned in the current code. We would want to apply to the working
> tree the difference between the index and the working tree, but instead
> we try to apply the difference between the HEAD and the working t
Currently the diff-highlight script does not try to highlight hunks that
have different numbers of removed/added lines. But we can be a little
smarter than that, without introducing much magic and complexity.
In the case of unevenly-sized hunks, we could still highlight the first
few (lexicograph
On Tue, Jun 16, 2015 at 1:14 AM, Junio C Hamano wrote:
> Paul Tan writes:
>
>> On Mon, Jun 15, 2015 at 6:08 AM, Junio C Hamano wrote:
>>> Paul Tan writes:
diff --git a/git.c b/git.c
index 44374b1..42328ed 100644
--- a/git.c
+++ b/git.c
@@ -370,6 +370,7 @@ static int run
Paul Tan writes:
> On Mon, Jun 15, 2015 at 6:08 AM, Junio C Hamano wrote:
>> Paul Tan writes:
>>> diff --git a/git.c b/git.c
>>> index 44374b1..42328ed 100644
>>> --- a/git.c
>>> +++ b/git.c
>>> @@ -370,6 +370,7 @@ static int run_builtin(struct cmd_struct *p, int argc,
>>> const char **argv)
>
On Sat, Jun 13, 2015 at 10:22:17PM +0200, Karsten Blees wrote:
> Date: Wed, 6 Aug 2014 20:43:46 +0200
>
> The number of loose objects at which git-gui shows a gc warning has
> historically been hardcoded to ~2000, or ~200 on Windows. The warning can
> only be disabled completely via gui.gcwarning=
On 2015-06-15 10.50, Jan-Philip Gehrcke wrote:
> Hello,
>
> I was surprised to see that the output of
>
> git log --encoding=utf-8 "--format=format:%b"
>
> can contain byte sequences that are invalid in UTF-8. Note: I am using git
> 2.1.4 and the %b format specifier represents the commit me
Matthieu Moy writes:
> I would say terms_defined is OK even if only the first patches get
> merged. The reason why you need this variable is because you need to
> know whether the terms have been defined or not, and to me that's the
> most important.
Well said. Thanks.
>
> I'd suggest somethin
Matthieu Moy writes
> To me, the answer should be: do whatever the RFC says in email headers.
> I'd expect anything that works in the To: header to work in the --to
> option of git send-email.
Ok sounds good to me !
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
Hi great "git crew" member :)
I found small, but annoying bug in 'git svn'. If you would try to make
any commit with new files (or delete/modify files) which contain in
name "@" sign - you'll see crash with minimum information about what's
just happened. Such file names are very useful for iOS proj
Remi Lespinet writes:
> Ok, but I don't know what fixed means in these particular cases.
> Actually the problem when we have a quote in a name is: Is this a
> delimiter or is this an ascii char?
To me, the answer should be: do whatever the RFC says in email headers.
I'd expect anything that work
Matthieu Moy writes
> I would say that using parse_address_line is good for consistancy in Git
> anyway. If the behavior of parse_address_line is broken on some
> corner-cases, then it should be fixed anyway.
Ok, but I don't know what fixed means in these particular cases.
Actually the proble
From: "Simon A. Eugster"
Signed-off-by: Simon A. Eugster
---
Documentation/git-checkout.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index d263a56..5c3ef86 100644
--- a/Documentation/git-checkout.txt
---
Documentation/git-checkout.txt | 39 +++
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 5c3ef86..ec0be28 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git
I hope I managed to get this working with replying to your response,
Junio, git send-email is all new to me.
Thanks a lot for your detailled answer. I tried to integrate it and
hope it is understandable this way?
Simon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the b
Remi Lespinet writes:
> Currently, git send-email contains a function which splits at commas
> with respect to quotes (parse_address_line introduced by
> 5012699d9840fe34fe0838ea0d529c2f32f76b82).
It seems I had missed this one, but indeed, it should probably be used
instead of split_at_commas i
Hi,
I'm currently working on git send-email to allow passing names
containing commas. I would like to specify that the comma
shouldn't be interpreted as a delimiter when there's quotes
around:
"Jane, Katarina Doe"
This changes the behavior of the double quote. For example
when passing:
--t
An example of the line in a mercurial patch that specifies the date of
the commit would be:
# Date 1433753301 25200
where the first number is the number of seconds since the unix epoch (in
UTC), and the second number is the offset of the timezone, in second s
west of UTC (negative if the
A StGit series is a directory containing a "series" file which begins
with the line:
# This series applies on GIT commit X
where X is the commit ID that the patch series applies on. Every
following line names a patch in the directory to be applied.
Test that git-am, when given th
git-mailsplit, which splits mbox patches, will read the patch from stdin
when the filename is "-" or there are no files listed on the
command-line.
To be consistent with this behavior, teach the StGit patch parser to
read from stdin if the filename is "-" or no files are listed on the
command-line
git-mailsplit, which splits mbox patches, will read the patch from stdin
when the filename is "-" or there are no files listed on the
command-line.
To be consistent with this behavior, teach the mercurial patch parser to
read from stdin if the filename is "-" or no files are listed on the
command-
By default, an StGit patch separates the subject from the commit message
and headers as follows:
$subject
From: $author_name <$author_email>
$message
---
$diffstats
We test git-am's ability to detect such a patch as an StGit patch, and
its ability to be a
This is a re-roll of [v1].
Previous versions:
[v1] http://thread.gmane.org/gmane.comp.version-control.git/271053
git-am is able to parse StGit and mercurial patches. However, there are no
regression tests in the test suite for these patch formats, and there are some
small bugs as well:
* the me
On Fri, Jun 12, 2015 at 1:39 AM, Stefan Beller wrote:
> On Thu, Jun 11, 2015 at 3:21 AM, Paul Tan wrote:
>> Notes:
>> v2
>>
>> * Declare struct am_state as static
>>
>> builtin/am.c | 164
>> +++
>> 1 file changed, 164 insertions(+
On Fri, Jun 12, 2015 at 1:45 AM, Stefan Beller wrote:
> On Thu, Jun 11, 2015 at 3:21 AM, Paul Tan wrote:
>> @@ -138,13 +202,33 @@ static void am_next(struct am_state *state)
>> */
>> static void am_run(struct am_state *state)
>> {
>> - while (state->cur <= state->last)
>> + while
Am 15.06.2015 um 02:12 schrieb Junio C Hamano:
> Karsten Blees writes:
>
>> diff --git a/Documentation/i18n.txt b/Documentation/i18n.txt
>> index e9a1d5d..e5f6233 100644
>> --- a/Documentation/i18n.txt
>> +++ b/Documentation/i18n.txt
>> @@ -1,18 +1,28 @@
>> -At the core level, Git is character en
On Mon, Jun 15, 2015 at 6:08 AM, Junio C Hamano wrote:
> Paul Tan writes:
>> diff --git a/git.c b/git.c
>> index 44374b1..42328ed 100644
>> --- a/git.c
>> +++ b/git.c
>> @@ -370,6 +370,7 @@ static int run_builtin(struct cmd_struct *p, int argc,
>> const char **argv)
>>
>> static struct cmd_stru
On Tue, Jun 09, 2015 at 08:40:14PM +0200, Jens Lehmann wrote:
> Am 07.06.2015 um 08:26 schrieb Stefan Beller:
> >On 06.06.2015 12:53, Luca Milanesio wrote:
> >>>On 6 Jun 2015, at 18:49, Phil Hord wrote:
> >>>On Fri, Jun 5, 2015, 2:58 AM lucamilanesio
> >>>wrote:
> Ideally, as a "git clone --
Antoine Delaite writes:
> To submit a v3 I would need answer about how we rebase the commit
> history and what do we do to simplify the life of the user with the
> terms (see my last mails).
> I was thinking of:
> -a config variable that would say :"as long as I don't reset keep
> the terms
might contain good thoughts about locking + git:
Jan 12, 2010 Interest in locking mechanism?
http://git.661346.n2.nabble.com/Interest-in-locking-mechanism-td4293383.html
Jul 04, 2013 intend-to-edit flag
http://git.661346.n2.nabble.com/intend-to-edit-flag-tp7591127.html
Sep 17, 2013 Locking file
Antoine Delaite writes:
> Matthieu Moy writes:
>
>>> +if test -s "$GIT_DIR/TERMS_DEFINED"
>>> +then
>>> +terms_defined=1
>>> +get_terms
>>> +rm -rf "$GIT_DIR/TERMS_DEFINED"
>>
>>I don't understand why you need to delete this file. I
Hello,
I was surprised to see that the output of
git log --encoding=utf-8 "--format=format:%b"
can contain byte sequences that are invalid in UTF-8. Note: I am using
git 2.1.4 and the %b format specifier represents the commit message body.
I have seen this with the Linux git repository a
Antoine Delaite writes:
> Louis Stuber writes:
>
>>Matthieu Moy writes:
>>
>>> Modifying in PATCH 7 some code that you introduced in PATCH 3 is
>>> suspicious. Is there any reason you did not name the variable
>>> "terms_defined" in the first place? (i.e. squash this hunk and the other
>>
Remi Galan Alfonso writes:
> Matthieu Moy writes:
>> Remi Galan Alfonso writes:
>>
>> > It is mainly because here the SHA-1 is a long one (40 chars)
>>
>> OK, but then the minimum would be to add a comment saying that.
>>
>> Now, this makes me wonder why you are doing the check after the sha
Junio C Hamano venit, vidit, dixit 14.06.2015 23:23:
> "brian m. carlson" writes:
>
>> Currently, verify-commit and verify-tag produce human-readable output.
>> This is great for humans, and awful for machines. It also lacks a lot
>> of the information that GnuPG's --status-fd output provides.
>
79 matches
Mail list logo
