[PATCH v3 1/2] imap-send: clarify CRAM-MD5 vs LOGIN documentation

[Tony Finch]

Explicitly mention that leaving imap.authMethod unset makes
git imap-send use the basic IMAP plaintext LOGIN command.

Signed-off-by: Tony Finch 
---
 Documentation/git-imap-send.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-imap-send.txt b/Documentation/git-imap-send.txt
index 875d283..770cbe8 100644
--- a/Documentation/git-imap-send.txt
+++ b/Documentation/git-imap-send.txt
@@ -76,7 +76,8 @@ imap.preformattedHTML::

 imap.authMethod::
Specify authenticate method for authentication with IMAP server.
-   Current supported method is 'CRAM-MD5' only.
+   Current supported method is 'CRAM-MD5' only. If this is not set
+   then 'git imap-send' uses the basic IMAP plaintext LOGIN command.

 Examples
 
-- 
2.1.0.rc0.60.gb5b18e5


--
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

[PATCH v3 2/2] imap-send: create target mailbox if it is missing

[Tony Finch]

Some MUAs delete their "drafts" folder when it is empty, so
git imap-send should be able to create it if necessary.

This change checks that the folder exists immediately after
login and tries to create it if it is missing.

There was some vestigial code to handle a [TRYCREATE] response
from the server when an APPEND target is missing. However this
code never ran (the create and trycreate flags were never set)
and when I tried to make it run I found that the code had already
thrown away the contents of the message it was trying to append.

Signed-off-by: Tony Finch 
---
 imap-send.c | 57 ++---
 1 file changed, 26 insertions(+), 31 deletions(-)

diff --git a/imap-send.c b/imap-send.c
index 524fbab..a29d03e 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -128,7 +128,6 @@ struct imap_cmd_cb {
char *data;
int dlen;
int uid;
-   unsigned create:1, trycreate:1;
 };

 struct imap_cmd {
@@ -714,8 +713,8 @@ static int parse_response_code(struct imap_store *ctx, 
struct imap_cmd_cb *cb,
 static int get_cmd_result(struct imap_store *ctx, struct imap_cmd *tcmd)
 {
struct imap *imap = ctx->imap;
-   struct imap_cmd *cmdp, **pcmdp, *ncmdp;
-   char *cmd, *arg, *arg1, *p;
+   struct imap_cmd *cmdp, **pcmdp;
+   char *cmd, *arg, *arg1;
int n, resp, resp2, tag;

for (;;) {
@@ -801,30 +800,9 @@ static int get_cmd_result(struct imap_store *ctx, struct 
imap_cmd *tcmd)
if (!strcmp("OK", arg))
resp = DRV_OK;
else {
-   if (!strcmp("NO", arg)) {
-   if (cmdp->cb.create && cmd && 
(cmdp->cb.trycreate || !memcmp(cmd, "[TRYCREATE]", 11))) { /* SELECT, APPEND or 
UID COPY */
-   p = strchr(cmdp->cmd, '"');
-   if (!issue_imap_cmd(ctx, NULL, 
"CREATE \"%.*s\"", (int)(strchr(p + 1, '"') - p + 1), p)) {
-   resp = RESP_BAD;
-   goto normal;
-   }
-   /* not waiting here violates 
the spec, but a server that does not
-  grok this nonetheless 
violates it too. */
-   cmdp->cb.create = 0;
-   if (!(ncmdp = 
issue_imap_cmd(ctx, &cmdp->cb, "%s", cmdp->cmd))) {
-   resp = RESP_BAD;
-   goto normal;
-   }
-   free(cmdp->cmd);
-   free(cmdp);
-   if (!tcmd)
-   return 0;   /* 
ignored */
-   if (cmdp == tcmd)
-   tcmd = ncmdp;
-   continue;
-   }
+   if (!strcmp("NO", arg))
resp = RESP_NO;
-   } else /*if (!strcmp("BAD", arg))*/
+   else /*if (!strcmp("BAD", arg))*/
resp = RESP_BAD;
fprintf(stderr, "IMAP command '%s' returned 
response (%s) - %s\n",
 memcmp(cmdp->cmd, "LOGIN", 5) ?
@@ -833,7 +811,6 @@ static int get_cmd_result(struct imap_store *ctx, struct 
imap_cmd *tcmd)
}
if ((resp2 = parse_response_code(ctx, &cmdp->cb, cmd)) 
> resp)
resp = resp2;
-   normal:
if (cmdp->cb.done)
cmdp->cb.done(ctx, cmdp, resp);
free(cmdp->cb.data);
@@ -944,7 +921,7 @@ static int auth_cram_md5(struct imap_store *ctx, struct 
imap_cmd *cmd, const cha
return 0;
 }

-static struct imap_store *imap_open_store(struct imap_server_conf *srvc)
+static struct imap_store *imap_open_store(struct imap_server_conf *srvc, char 
*folder)
 {
struct credential cred = CREDENTIAL_INIT;
struct imap_store *ctx;
@@ -1156,6 +1133,25 @@ static struct imap_store *imap_open_store(struct 
imap_server_conf *srvc)
credential_approve(&cred);
credential_clear(&cred);

+   /* check the target mailbox exists */
+   ctx->name = folder;
+   switch (imap_exec(ctx, NULL, "EXAMINE \"%s\"", ctx->name)) {
+   case RESP_OK:
+   /* ok */
+   bre

Test

[Fra_Mos_21]

Test.

---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz 
ist aktiv.
http://www.avast.com

--
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

Re: [PATCH v6 6/7] config: add `git_die_config()` to the config-set API

[Matthieu Moy]

Junio C Hamano  writes:

> Hmm, I am still confused ;-)
>
> Can there be more than one 'i' whose value->items[i].string is the
> same as the given value?  IOW, if you have "[user] name" in
> both .git/config and ~/.gitconfig, don't we want to make sure that
> we complain on the one in .git/config, which would have taken
> precedence if it were spelled correctly?

For single-valued variables, yes. And for them, git_die_config(), as
currently implemented does the right thing. My proposed change does not
modify the behavior, it just extracts error messages and an if/then/else
into a helper that can be used elsewhere.

For multi-valued variables, it's different. If you have a boggus value,
further values will not override it. It will remain bogus.

The code consuming such multi-valued variable has to iterate over the
string_list, and raise an error on bogus values. Ideally, it could show
all the errors, but it's also reasonable to die() at the first one. The
simplest behavior to implement is to die() at the first error.

(currently, git _segfaults_ at the first NULL value for
notes.displayref, so it can't be much worse)

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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

Re: [PATCH v6 6/7] config: add `git_die_config()` to the config-set API

[Tanay Abhra]

On 8/1/2014 12:11 AM, Matthieu Moy wrote:
> Tanay Abhra  writes:
> 
>> On 7/31/2014 11:39 PM, Matthieu Moy wrote:
>>
>>> This is the part I find weird. You're calling git_die_config_exact() on
>>> the first boggus value, and git_die_config_exact() will notify an error
>>> at the line of the last boggus value.
>>
>> Hmn, we may have some confusion here. I meant the implementation of
>> git_config_exact() to look like this,
>>
>> void git_die_config_exact(const char *key, const char *value)
>> {
>>  int i;
>>  const struct string_list *values;
>>  struct key_value_info *kv_info;
>>  values = git_config_get_value_multi(key);
>>  for (i = 0; i < values.nr; i++) {
>>  kv_info = values->items[i].util;
>>  /* A null check will be here also */
>>  if (!strcmp(value, values->items[i].string)) {
>>  if (!kv_info->linenr)
>>  die(_("unable to parse '%s' from command-line 
>> config"), key);
>>  else
>>  die(_("bad config variable '%s' at file line %d 
>> in %s"),
>>  key,
>>  kv_info->linenr,
>>  kv_info->filename);
>>  }
>>  }
>> }
>>
>> The above code would print the info on first bogus value.
> 
> OK, I got confused because git_die_config() errors out at the first
> error. So, your version works, but I do not see any added value in this
> extra complexity.
> 
> To be cleary, my version would be
> 
> NORETURN static /* not sure about the "static" */
> void git_die_config_linenr(const char *key,
>const char *filename, int linenr)
> {
>   if (!linenr)
>   die(_("unable to parse '%s' from command-line config"), key);
>   else
>   die(_("bad config variable '%s' at file line %d in %s"),
>   key,
>   linenr,
>   filename);
> }
> 
> (hmm, I actually do not need the value, it's not printed)
> 
> NORETURN
> void git_die_config(const char *key)
> {
>   const struct string_list *values;
>   struct key_value_info *kv_info;
>   values = git_config_get_value_multi(key);
>   kv_info = values->items[values->nr - 1].util;
>   git_die_config_linenr(key, kv_info->linenr, kv_info->filename);
> }
> 
> (we forgot the NORETURN in previous version BTW. It should be there in
> both functions here and in the .h file)
> 
> In my version, git_die_config uses git_die_config_linenr, and there's no
> issue with first/last boggus value. Callers of git_die_config_linenr
> have all the information to call it directly.
> 
> There are 3 code path that leads to the final die() calls, and having
> this little helper allows making sure the messages are the same for
> every callers, by construction (as opposed to cut-and-pasting).
> 
> Really, I don't see any reason to do anything more complex.
>

Thanks, I am sending your version with the reroll.
Also, for clarity the multi value use case would look like,

struct key_value_info *kv_info;
if (load_config_refs) {
values = git_config_get_value_multi("notes.displayref");
if (values) {
for (i = 0; i < values->nr; i++) {
if (!values->items[i].string) {

config_error_nonbool("notes.displayref");
kv_info = values->items[i].util;

git_die_config_linenr("notes.displayref",
  kv_info->filename,
  kv_info->linenr);
}
else

string_list_add_refs_by_glob(&display_notes_refs,
 
values->items[i].string);
}
}
}

with my function it would have looked like,

if (load_config_refs) {
values = git_config_get_value_multi("notes.displayref");
if (values) {
for (i = 0; i < values->nr; i++) {
if (!values->items[i].string) {

config_error_nonbool("notes.displayref");

git_die_config_exact("notes.displayref", values->items[i].string);
}
else

string_list_add_refs_by_glob(&display_notes_refs,
 
values->items[i].string);
}
}
}

Thanks.
--
To unsubscribe from this list: send the lin

Re: [PATCH v6 6/7] config: add `git_die_config()` to the config-set API

[Matthieu Moy]

Tanay Abhra  writes:

> Thanks, I am sending your version with the reroll.
> Also, for clarity the multi value use case would look like,
>
>   struct key_value_info *kv_info;
>   if (load_config_refs) {
>   values = git_config_get_value_multi("notes.displayref");
>   if (values) {
>   for (i = 0; i < values->nr; i++) {
>   if (!values->items[i].string) {
>   
> config_error_nonbool("notes.displayref");
>   kv_info = values->items[i].util;
>   
> git_die_config_linenr("notes.displayref",
> kv_info->filename,
> kv_info->linenr);
>   }
>   else
>   
> string_list_add_refs_by_glob(&display_notes_refs,
>
> values->items[i].string);
>   }
>   }
>   }
>
> with my function it would have looked like,
>
>   if (load_config_refs) {
>   values = git_config_get_value_multi("notes.displayref");
>   if (values) {
>   for (i = 0; i < values->nr; i++) {
>   if (!values->items[i].string) {
>   
> config_error_nonbool("notes.displayref");
>   
> git_die_config_exact("notes.displayref", values->items[i].string);
>   }
>   else
>   
> string_list_add_refs_by_glob(&display_notes_refs,
>
> values->items[i].string);
>   }
>   }
>   }

I still think that checking for non-null values should be done in a
helper in config.c, and then the code would look like

if (load_config_refs) {
values = git_config_get_value_multi_nonbool("notes.displayref");
if (values)
for (i = 0; i < values->nr; i++)

string_list_add_refs_by_glob(&display_notes_refs,
 
values->items[i].string);
}

The same helper could at least be used for "branch..merge".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
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

[BUG] Assertion failed: (child->real_type == OBJ_REF_DELTA), function find_unresolved_deltas_1, file builtin/index-pack.c

[Martin von Gagern]

Hi!

See also https://code.google.com/p/support/issues/detail?id=31571

Executing the command

git clone https://code.google.com/p/mapsforge/

fails with the error message

Assertion failed: (child->real_type == OBJ_REF_DELTA),
function find_unresolved_deltas_1, file builtin/index-pack.c

Bisecting the code I found that 7218a215efc7ae46f7ca8d82 (from 2011,
first released in git 1.7.7) is the first bad commit. It is also the one
to introduce that assertion.

The idea behind that commit seems simple: instead of just sorting by
base hash, also sort by type. Then when iterating over the matching
objects, we can rely on the type and don't have to check that.

So far, so good. But the problem here is that the sorting is based on
the "type" attribute, while the assertion and the case distinction it
replaces was based on "real_type". I guess that at the point where the
sorting takes place, these two should be identical. But once
resolve_delta gets called, the real_type is changed to that of the base
object. Which means that the original case distinction did more than
just drop deltas of the wrong type: it also prevented resolution of
already-resolved deltas. Therefore the change caused stuff to fail which
used to work before. In this particular instance, the real_type changed
from OBJ_REF_DELTA to OBJ_TREE which caused the assertion to fail.

I'm not sure whether this kind of duplicate resolution is something
normal or indicates some breakage in the repository in question. If it
is considered normal (although rare, otherwise others would have
complained by now), then someone should likely turn the assertion back
into a normal conditional. If this is a broken repository, then I think
it should be reported as such, since in my book a failed assertion
indicates a problem with the program itself, not its input data.

Thank you very much,
 Martin von Gagern



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] l10n: de.po: fix typo

[Hartmut Henkel]

Dear Ralf,

thanks a lot for signing off the tiny patch below. Yet somehow it didn't 
make it into git version 2.1.0.rc0.52.gaa544bf.

Regards, Hartmut


On Wed, 11 Jun 2014, Ralf Thielow wrote:

> Reported-by: Hartmut Henkel
> Signed-off-by: Ralf Thielow 
> ---
>  po/de.po | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/po/de.po b/po/de.po
> index b777ef4..88d10ed 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -10551,13 +10551,13 @@ msgstr "Bitte committen Sie die Änderungen oder 
> benutzen Sie \"stash\"."
>  #: git-rebase.sh:577
>  #, sh-format
>  msgid "Current branch $branch_name is up to date."
> -msgstr "Aktueller Branch $branch_name ist auf dem neusten Stand."
> +msgstr "Aktueller Branch $branch_name ist auf dem neuesten Stand."
>  
>  #: git-rebase.sh:581
>  #, sh-format
>  msgid "Current branch $branch_name is up to date, rebase forced."
>  msgstr ""
> -"Aktueller Branch $branch_name ist auf dem neusten Stand, Rebase erzwungen."
> +"Aktueller Branch $branch_name ist auf dem neuesten Stand, Rebase erzwungen."
>  
>  #: git-rebase.sh:592
>  #, sh-format
> -- 
> 2.0.0.415.g8cd8cf8

Re: Bug report about symlinks

[Junio C Hamano]

René Scharfe  writes:

> # Create test repo with two directories with two files each.
> $ git init
> Initialized empty Git repository in /tmp/.git/
> $ mkdir a b
> $ echo x >a/equal
> $ echo x >b/equal
> $ echo y >a/different
> $ echo z >b/different
> $ git add a b
> $ git commit -minitial
> [master (root-commit) 6d36895] initial
>  4 files changed, 4 insertions(+)
>  create mode 100644 a/different
>  create mode 100644 a/equal
>  create mode 100644 b/different
>  create mode 100644 b/equal
>
> # Replace one directory with a symlink to the other.
> $ rm -rf b
> $ ln -s a b
>
> # First git status call.
> $ git status
> On branch master
> Changes not staged for commit:
>   (use "git add/rm ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
>
> deleted:b/different
>
> Untracked files:
>   (use "git add ..." to include in what will be committed)
>
> b
>
> no changes added to commit (use "git add" and/or "git commit -a")
> ...
>
> It could be debated if the first git status call should also report
> b/equal as deleted.

Hmph.

I wonder if "could be" is an understatement.  The difference of
reporting between b/equal and b/different may indicate that somebody
is mistakenly comparing the index with these paths, without first
checking each path with has_symlink_leading_path(), or something,
no?

Or am I misreading the report and codepath?

Puzzled...

--
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

Re: cherry picking and merge

[Jakub Narębski]

W dniu 2014-08-01 04:43, brian m. carlson pisze:

On Thu, Jul 31, 2014 at 05:58:17PM -0700, Mike Stump wrote:



Cherry picking doesn’t work as well as it should.  I was testing on
git version 1.7.9.5.

Put in a line in a file, call it:

first version

then cherry pick this into your branch. Then update on master and transform 
that into:

second version

then, merge that branch back to master.  Death in the form of conflicts.

In gcc land, I do this sort of thing all the time, and I need a
merging subsystem to actually keep track of things.  I can manage this
will diff and patch and it works flawlessly.  The point of using
something better than diff and patch is for it to be better than diff
and patch.

I’d like for merge to merge in the work that has yet to be merged.
Not that, plus blindly try and apply or reapply cherry picked items.


Note that you should try to avoid cherry-picking, as they do not
leave trace in the graph of revisions.

For example if you are creating a bugfix, instead of putting it
directly on maint, and then cherry-picking to master, it is better
to create a separate feature branch for this fix (based at an early
version), and then merge said branch into maint, then into master.
It is described in blog post by Junio Hamano (which I cannot find now).


You're not the first person to be surprised by the way merge works.
 From the git-merge manpage:

   [This behavior] occurs because only the heads and the merge base are
   considered when performing a merge, not the individual commits.

(That was added after 1.7.9.5.)

If you want the behavior of applying multiple patches in a row, you want
to use git rebase, not git merge.  Since rebase re-applies the patches
of each of your commits on top of another branch, the identical change
won't cause conflicts.


There is also git-imerge, third party tool that is intended to help
merging changes (and make it possible to do it in incremental way).

HTH
--
Jakub Narębski


--
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

Re: [PATCH] l10n: de.po: fix typo

[Ralf Thielow]

Hi Hartmut,

2014-08-01 15:37 GMT+02:00 Hartmut Henkel :
> Dear Ralf,
>
> thanks a lot for signing off the tiny patch below. Yet somehow it didn't
> make it into git version 2.1.0.rc0.52.gaa544bf.
>

my plan is to make this patch be part of the translations
for the 2.1.0 release. I'll be sending a pull request
(containing this patch) to the l10n coordinator when the
other translations for this release are done.

Ralf

> Regards, Hartmut
>
>
> On Wed, 11 Jun 2014, Ralf Thielow wrote:
>
>> Reported-by: Hartmut Henkel
>> Signed-off-by: Ralf Thielow 
>> ---
>>  po/de.po | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/po/de.po b/po/de.po
>> index b777ef4..88d10ed 100644
>> --- a/po/de.po
>> +++ b/po/de.po
>> @@ -10551,13 +10551,13 @@ msgstr "Bitte committen Sie die Änderungen oder 
>> benutzen Sie \"stash\"."
>>  #: git-rebase.sh:577
>>  #, sh-format
>>  msgid "Current branch $branch_name is up to date."
>> -msgstr "Aktueller Branch $branch_name ist auf dem neusten Stand."
>> +msgstr "Aktueller Branch $branch_name ist auf dem neuesten Stand."
>>
>>  #: git-rebase.sh:581
>>  #, sh-format
>>  msgid "Current branch $branch_name is up to date, rebase forced."
>>  msgstr ""
>> -"Aktueller Branch $branch_name ist auf dem neusten Stand, Rebase erzwungen."
>> +"Aktueller Branch $branch_name ist auf dem neuesten Stand, Rebase 
>> erzwungen."
>>
>>  #: git-rebase.sh:592
>>  #, sh-format
>> --
>> 2.0.0.415.g8cd8cf8
--
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

Re: [PATCH v3 1/3] lockfile.c: remove PATH_MAX limitation (except in resolve_symlink)

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> Signed-off-by: Nguyễn Thái Ngọc Duy 

Somewhat underexplained, given that it seems to add some new
semantics.

> +static void clear_filename(struct lock_file *lk)
> +{
> + free(lk->filename);
> + lk->filename = NULL;
> +}

It is good to abstract out lk->filename[0] = '\0', which used to be
the way we say that we are done with the lock.  But I am somewhat
surprised to see that there aren't so many locations that used to
check !!lk->filename[0] to see if we are done with the lock to require
a corresponding wrapper.

>  static void remove_lock_file(void)
>  {
>   pid_t me = getpid();
>  
>   while (lock_file_list) {
>   if (lock_file_list->owner == me &&
> - lock_file_list->filename[0]) {
> + lock_file_list->filename) {

... and this seems to be the only location?

> @@ -124,17 +136,12 @@ static char *resolve_symlink(char *p, size_t s)
>  
>  static int lock_file(struct lock_file *lk, const char *path, int flags)
>  {
> - /*
> -  * subtract 5 from size to make sure there's room for adding
> -  * ".lock" for the lock file name
> -  */
> - static const size_t max_path_len = sizeof(lk->filename) - 5;
> -
> - if (strlen(path) >= max_path_len)
> + int len;
> + if (!(flags & LOCK_NODEREF) && !(path = resolve_symlink(path)))
>   return -1;

Somehow I found it unnecessarily denser; had to read it twice before
caffeine kicked in ;-)

> @@ -231,16 +238,17 @@ int close_lock_file(struct lock_file *lk)
>  
>  int commit_lock_file(struct lock_file *lk)
>  {
> - char result_file[PATH_MAX];
> - size_t i;
> - if (lk->fd >= 0 && close_lock_file(lk))
> + char *result_file;
> + if ((lk->fd >= 0 && close_lock_file(lk)) || !lk->filename)
>   return -1;

We did not protect against somebody calling this with an already
closed lock, but we now return early without attempting renameing
etc., which is a good change but is not explained.  Was there a
specific code path that you needed this change for?

Also the order of the check is not consistent with how the same
check is done in rollback_lock_file().  The order you use in this
new code (and also in commit_locked_index()) may be better than the
existing order in the rollback code path; we want to see the fd
closed, if it is open, even if lk->filename has already been
cleared.  On the other hand, one could argue that anything such a
broken caller tells this function is suspicious, and we shouldn't
close random file descriptor that is likely not owned by the caller
in the first place.  I dunno.

> @@ -273,10 +281,10 @@ int commit_locked_index(struct lock_file *lk)
>  
>  void rollback_lock_file(struct lock_file *lk)
>  {
> - if (lk->filename[0]) {
> + if (lk->filename) {
>   if (lk->fd >= 0)
>   close(lk->fd);
>   unlink_or_warn(lk->filename);
>   }
> - lk->filename[0] = 0;
> + clear_filename(lk);
>  }
--
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

Re: cherry picking and merge

[Mike Stump]

On Jul 31, 2014, at 7:43 PM, brian m. carlson  
wrote:
> 
> You're not the first person to be surprised by the way merge works.

I’m not the first, because the merge command is broken.  Once fixed, I would be 
happy to be the last.  Until then, the bug remains unfixed.  I’m sending the 
mail to petition for this bug to be fixed.

> From the git-merge manage:
> 
>  [This behavior] occurs because only the heads and the merge base are
>  considered when performing a merge, not the individual commits.

From:

google(”git merge”):

> git-merge - Join two or more development histories together

Either, the command should do as documented, or be fixed.  In that reference, 
there is no mention that merge will not merge.  There is no mention that merge 
isn’t the command I want to merge, but that I should use rebase.

Further, google(“git rebase”) says:

> There is no difference in the end product of the integration,

Clearly, this is a lie.  There is a difference.

Now, about rebase:

> Do not rebase commits that you have pushed to a public repository.
> 
> If you follow that guideline, you’ll be fine. If you don’t, people will hate 
> you, and you’ll be scorned by friends and family.


Since everything I do goes up and down into repositories and I don’t want my 
friends and family to scorn me, rebase isn’t the command I want to use.

I want to use the simple, it works, named for the operation I want to perform, 
merge.  I’m a simple user, and the simple command I want to work.  You can name 
the old merge command, merge-mostly or merge-fast and the new one can be called 
merge.

> (That was added after 1.7.9.5.)

I don’t want bugs documented, I want them fixed.  I’m not reporting a doc bug, 
the doc is correct.

> If you want the behavior of applying multiple patches in a row, you want
> to use git rebase, not git merge.  Since rebase re-applies the patches
> of each of your commits on top of another branch, the identical change
> won't cause conflicts.

But, I don’t want the series of patches, I just want a simple,  merged feature 
X on trunk single commit that merge does.

Given branch B, master M, and cherry picked C, what I want merged is B-(M+C), 
not B-M.  The problem with B-M, is that when you do B += C (aka cherry pick 
from master onto your branch), then M += B-M (merge your branch into master), 
that C is then replicated.  This replication is wrong, always wrong, never 
right, incorrect, broken.  This is the bug I want fixed.--
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

[PATCH v7 5/8] config: add `git_die_config()` to the config-set API

[Tanay Abhra]

Add `git_die_config` that dies printing the line number and the file name
of the highest priority value for the configuration variable `key`.

It has usage in non-callback based config value retrieval where we can
raise an error and die if there is a semantic error.
For example,

if (!git_config_get_value(key, &value)) {
/* NULL values not allowed */
if (!value)
git_config_die(key);
else
/* do work */
}

Signed-off-by: Tanay Abhra 
---
 Documentation/technical/api-config.txt | 12 
 cache.h|  2 ++
 config.c   | 34 --
 3 files changed, 46 insertions(+), 2 deletions(-)

diff --git a/Documentation/technical/api-config.txt 
b/Documentation/technical/api-config.txt
index 815c1ee..d6a2c39 100644
--- a/Documentation/technical/api-config.txt
+++ b/Documentation/technical/api-config.txt
@@ -155,6 +155,18 @@ as well as retrieval for the queried variable, including:
Similar to `git_config_get_string`, but expands `~` or `~user` into
the user's home directory when found at the beginning of the path.
 
+`void git_die_config(const char *key)`::
+
+   Dies printing the line number and the file name of the highest
+   priority value for the configuration variable `key`.
+
+`void git_die_config_linenr(const char *key, const char *filename, int 
linenr)`::
+
+   Helper function which formats the die error message according to the
+   parameters entered. Used by `git_die_config()`. It can be used by 
callers
+   handling `git_config_get_value_multi()` to print the correct error 
message
+   for the desired value.
+
 See test-config.c for usage examples.
 
 Value Parsing Helpers
diff --git a/cache.h b/cache.h
index c61919d..9ec2f4e 100644
--- a/cache.h
+++ b/cache.h
@@ -1382,6 +1382,8 @@ extern int git_config_get_bool(const char *key, int 
*dest);
 extern int git_config_get_bool_or_int(const char *key, int *is_bool, int 
*dest);
 extern int git_config_get_maybe_bool(const char *key, int *dest);
 extern int git_config_get_pathname(const char *key, const char **dest);
+extern void git_die_config(const char *key);
+extern void git_die_config_linenr(const char *key, const char *filename, int 
linenr);
 
 extern int committer_ident_sufficiently_given(void);
 extern int author_ident_sufficiently_given(void);
diff --git a/config.c b/config.c
index f923b1c..ddbfe4d 100644
--- a/config.c
+++ b/config.c
@@ -1474,8 +1474,12 @@ const struct string_list 
*git_config_get_value_multi(const char *key)
 
 int git_config_get_string_const(const char *key, const char **dest)
 {
+   int ret;
git_config_check_init();
-   return git_configset_get_string_const(&the_config_set, key, dest);
+   ret = git_configset_get_string_const(&the_config_set, key, dest);
+   if (ret < 0)
+   git_die_config(key);
+   return ret;
 }
 
 int git_config_get_string(const char *key, char **dest)
@@ -1516,8 +1520,34 @@ int git_config_get_maybe_bool(const char *key, int *dest)
 
 int git_config_get_pathname(const char *key, const char **dest)
 {
+   int ret;
git_config_check_init();
-   return git_configset_get_pathname(&the_config_set, key, dest);
+   ret = git_configset_get_pathname(&the_config_set, key, dest);
+   if (ret < 0)
+   git_die_config(key);
+   return ret;
+}
+
+NORETURN
+void git_die_config_linenr(const char *key, const char *filename, int linenr)
+{
+   if (!linenr)
+   die(_("unable to parse '%s' from command-line config"), key);
+   else
+   die(_("bad config variable '%s' at file line %d in %s"),
+   key,
+   linenr,
+   filename);
+}
+
+NORETURN
+void git_die_config(const char *key)
+{
+   const struct string_list *values;
+   struct key_value_info *kv_info;
+   values = git_config_get_value_multi(key);
+   kv_info = values->items[values->nr - 1].util;
+   git_die_config_linenr(key, kv_info->filename, kv_info->linenr);
 }
 
 /*
-- 
1.9.0.GIT

--
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

[PATCH v7 2/8] config.c: fix accuracy of line number in errors

[Tanay Abhra]

From: Matthieu Moy 

If a callback returns a negative value to `git_config*()` family,
they call `die()` while printing the line number and the file name.
Currently the printed line number is off by one, thus printing the
wrong line number.

Make `linenr` point to the line we just parsed during the call
to callback to get accurate line number in error messages.

Commit-message-by: Tanay Abhra 
Signed-off-by: Tanay Abhra 
---
 config.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/config.c b/config.c
index 34940fd..bb4629e 100644
--- a/config.c
+++ b/config.c
@@ -244,6 +244,7 @@ static int get_next_char(void)
cf->linenr++;
if (c == EOF) {
cf->eof = 1;
+   cf->linenr++;
c = '\n';
}
return c;
@@ -319,6 +320,7 @@ static int get_value(config_fn_t fn, void *data, struct 
strbuf *name)
 {
int c;
char *value;
+   int ret;
 
/* Get the full name */
for (;;) {
@@ -341,7 +343,15 @@ static int get_value(config_fn_t fn, void *data, struct 
strbuf *name)
if (!value)
return -1;
}
-   return fn(name->buf, value, data);
+   /*
+* We already consumed the \n, but we need linenr to point to
+* the line we just parsed during the call to fn to get
+* accurate line number in error messages.
+*/
+   cf->linenr--;
+   ret = fn(name->buf, value, data);
+   cf->linenr++;
+   return ret;
 }
 
 static int get_extended_base_var(struct strbuf *name, int c)
-- 
1.9.0.GIT

--
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

[PATCH v7 0/8] Rewrite `git_config()` using config-set API

[Tanay Abhra]

[Patch v7]: style nit corrected. (1/8) is Matthieu's translation patch.
git_die_config_linenr() helper function added. Diff between v6
and v7 appended for review.

[Patch v6]: Added _() to error messages.
Diff between v6 and v4 at the bottom.

[PATCH v5]: New patch added (3/7). git_config() now returns void.

[PATCH v4]: One style nit corrected, also added key to error messages.

[PATCH V3]:All the suggestions in [3] applied. Built on top of [1].

[PATCH V2]: All the suggestions in [2] incorporated. git_config() now follows
correct parsing order. Reordered the patches. Removed xfuncname patch
as it was unnecssary.

This series builds on the top of topic[1] in the mailing list with name
"git config cache & special querying API utilizing the cache".

This series aims to do these three things,

* Use the config-set API to rewrite git_config().

* Solve any legacy bugs in the previous system while at it.

* To be feature complete compared to the previous git_config() implementation,
which I think it is now. (added the line number and file name info just 
for
completeness)

Also, I haven't yet checked the exact improvements but still as a teaser,
git status now only rereads the configuration files twice instead of four
times.

[1]: http://thread.gmane.org/gmane.comp.version-control.git/254286
[2]: http://thread.gmane.org/gmane.comp.version-control.git/254101
[3]: http://thread.gmane.org/gmane.comp.version-control.git/254211

Matthieu Moy (1):
  config.c: mark error and warnings strings for translation

Tanay Abhra (7):
  config.c: fix accuracy of line number in errors
  add line number and file name info to `config_set`
  change `git_config()` return value to void
  config: add `git_die_config()` to the config-set API
  rewrite git_config() to use the config-set API
  add a test for semantic errors in config files
  add tests for `git_config_get_string_const()`

 Documentation/technical/api-config.txt |  12 +++
 branch.c   |   5 +-
 cache.h|  28 +-
 config.c   | 152 +++--
 t/t1308-config-set.sh  |  21 +
 t/t4055-diff-context.sh|   2 +-
 test-config.c  |  10 +++
 7 files changed, 200 insertions(+), 30 deletions(-)

-- 
1.9.0.GIT

-- 8< --
diff --git a/Documentation/technical/api-config.txt 
b/Documentation/technical/api-config.txt
index e7ec7cc..d6a2c39 100644
--- a/Documentation/technical/api-config.txt
+++ b/Documentation/technical/api-config.txt
@@ -160,6 +160,13 @@ as well as retrieval for the queried variable, including:
Dies printing the line number and the file name of the highest
priority value for the configuration variable `key`.
 
+`void git_die_config_linenr(const char *key, const char *filename, int 
linenr)`::
+
+   Helper function which formats the die error message according to the
+   parameters entered. Used by `git_die_config()`. It can be used by 
callers
+   handling `git_config_get_value_multi()` to print the correct error 
message
+   for the desired value.
+
 See test-config.c for usage examples.
 
 Value Parsing Helpers
diff --git a/cache.h b/cache.h
index 243f618..ff17889 100644
--- a/cache.h
+++ b/cache.h
@@ -1407,6 +1407,7 @@ extern int git_config_get_bool_or_int(const char *key, 
int *is_bool, int *dest);
 extern int git_config_get_maybe_bool(const char *key, int *dest);
 extern int git_config_get_pathname(const char *key, const char **dest);
 extern void git_die_config(const char *key);
+extern void git_die_config_linenr(const char *key, const char *filename, int 
linenr);
 
 extern int committer_ident_sufficiently_given(void);
 extern int author_ident_sufficiently_given(void);
diff --git a/config.c b/config.c
index 15fcd91..cf9124f 100644
--- a/config.c
+++ b/config.c
@@ -461,9 +461,9 @@ static int git_parse_source(config_fn_t fn, void *data)
break;
}
if (cf->die_on_error)
-   die("bad config file line %d in %s", cf->linenr, cf->name);
+   die(_("bad config file line %d in %s"), cf->linenr, cf->name);
else
-   return error("bad config file line %d in %s", cf->linenr, 
cf->name);
+   return error(_("bad config file line %d in %s"), cf->linenr, 
cf->name);
 }
 
 static int parse_unit_factor(const char *end, uintmax_t *val)
@@ -579,9 +579,9 @@ static void die_bad_number(const char *name, const char 
*value)
value = "";
 
if (cf && cf->name)
-   die("bad numeric config value '%s' for '%s' in %s: %s",
+   die(_("bad numeric config value '%s' for '%s' in %s: %s"),
value, name, cf->name, reason);
-   die("bad numeric config value '%s' for '%s': %s", value, name, reason);
+   die(_("bad numeric config value '%s' for '%s': %s"), value, name, 
reason);
 }

[PATCH v7 1/8] config.c: mark error and warnings strings for translation

[Tanay Abhra]

From: Matthieu Moy 

Signed-off-by: Matthieu Moy 
---
 config.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/config.c b/config.c
index a191328..34940fd 100644
--- a/config.c
+++ b/config.c
@@ -457,9 +457,9 @@ static int git_parse_source(config_fn_t fn, void *data)
break;
}
if (cf->die_on_error)
-   die("bad config file line %d in %s", cf->linenr, cf->name);
+   die(_("bad config file line %d in %s"), cf->linenr, cf->name);
else
-   return error("bad config file line %d in %s", cf->linenr, 
cf->name);
+   return error(_("bad config file line %d in %s"), cf->linenr, 
cf->name);
 }
 
 static int parse_unit_factor(const char *end, uintmax_t *val)
@@ -575,9 +575,9 @@ static void die_bad_number(const char *name, const char 
*value)
value = "";
 
if (cf && cf->name)
-   die("bad numeric config value '%s' for '%s' in %s: %s",
+   die(_("bad numeric config value '%s' for '%s' in %s: %s"),
value, name, cf->name, reason);
-   die("bad numeric config value '%s' for '%s': %s", value, name, reason);
+   die(_("bad numeric config value '%s' for '%s': %s"), value, name, 
reason);
 }
 
 int git_config_int(const char *name, const char *value)
@@ -662,7 +662,7 @@ int git_config_pathname(const char **dest, const char *var, 
const char *value)
return config_error_nonbool(var);
*dest = expand_user_path(value);
if (!*dest)
-   die("Failed to expand user dir in: '%s'", value);
+   die(_("failed to expand user dir in: '%s'"), value);
return 0;
 }
 
@@ -740,7 +740,7 @@ static int git_default_core_config(const char *var, const 
char *value)
if (level == -1)
level = Z_DEFAULT_COMPRESSION;
else if (level < 0 || level > Z_BEST_COMPRESSION)
-   die("bad zlib compression level %d", level);
+   die(_("bad zlib compression level %d"), level);
zlib_compression_level = level;
zlib_compression_seen = 1;
return 0;
@@ -751,7 +751,7 @@ static int git_default_core_config(const char *var, const 
char *value)
if (level == -1)
level = Z_DEFAULT_COMPRESSION;
else if (level < 0 || level > Z_BEST_COMPRESSION)
-   die("bad zlib compression level %d", level);
+   die(_("bad zlib compression level %d"), level);
core_compression_level = level;
core_compression_seen = 1;
if (!zlib_compression_seen)
@@ -873,7 +873,7 @@ static int git_default_core_config(const char *var, const 
char *value)
else if (!strcmp(value, "link"))
object_creation_mode = OBJECT_CREATION_USES_HARDLINKS;
else
-   die("Invalid mode for object creation: %s", value);
+   die(_("invalid mode for object creation: %s"), value);
return 0;
}
 
@@ -1173,7 +1173,7 @@ int git_config_early(config_fn_t fn, void *data, const 
char *repo_config)
 
switch (git_config_from_parameters(fn, data)) {
case -1: /* error */
-   die("unable to parse command-line config");
+   die(_("unable to parse command-line config"));
break;
case 0: /* found nothing */
break;
@@ -1514,7 +1514,7 @@ static int store_aux(const char *key, const char *value, 
void *cb)
case KEY_SEEN:
if (matches(key, value)) {
if (store.seen == 1 && store.multi_replace == 0) {
-   warning("%s has multiple values", key);
+   warning(_("%s has multiple values"), key);
}
 
ALLOC_GROW(store.offset, store.seen + 1,
-- 
1.9.0.GIT

--
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

[PATCH v7 6/8] rewrite git_config() to use the config-set API

[Tanay Abhra]

Of all the functions in `git_config*()` family, `git_config()` has the
most invocations in the whole code base. Each `git_config()` invocation
causes config file rereads which can be avoided using the config-set API.

Use the config-set API to rewrite `git_config()` to use the config caching
layer to avoid config file rereads on each invocation during a git process
lifetime. First invocation constructs the cache, and after that for each
successive invocation, `git_config()` feeds values from the config cache
instead of rereading the configuration files.

Signed-off-by: Tanay Abhra 
---
 cache.h | 24 +++
 config.c| 51 +
 t/t4055-diff-context.sh |  2 +-
 3 files changed, 68 insertions(+), 9 deletions(-)

diff --git a/cache.h b/cache.h
index 9ec2f4e..ff17889 100644
--- a/cache.h
+++ b/cache.h
@@ -8,6 +8,7 @@
 #include "gettext.h"
 #include "convert.h"
 #include "trace.h"
+#include "string-list.h"
 
 #include SHA1_HEADER
 #ifndef git_SHA_CTX
@@ -1351,9 +1352,32 @@ extern int parse_config_key(const char *var,
const char **subsection, int *subsection_len,
const char **key);
 
+struct config_set_element {
+   struct hashmap_entry ent;
+   char *key;
+   struct string_list value_list;
+};
+
+struct configset_list_item {
+   struct config_set_element *e;
+   int value_index;
+};
+
+/*
+ * the contents of the list are ordered according to their
+ * position in the config files and order of parsing the files.
+ * (i.e. key-value pair at the last position of .git/config will
+ * be at the last item of the list)
+ */
+struct configset_list {
+   struct configset_list_item *items;
+   unsigned int nr, alloc;
+};
+
 struct config_set {
struct hashmap config_hash;
int hash_initialized;
+   struct configset_list list;
 };
 
 extern void git_configset_init(struct config_set *cs);
diff --git a/config.c b/config.c
index ddbfe4d..cf9124f 100644
--- a/config.c
+++ b/config.c
@@ -35,12 +35,6 @@ struct config_source {
long (*do_ftell)(struct config_source *c);
 };
 
-struct config_set_element {
-   struct hashmap_entry ent;
-   char *key;
-   struct string_list value_list;
-};
-
 static struct config_source *cf;
 
 static int zlib_compression_seen;
@@ -1235,7 +1229,7 @@ struct key_value_info {
int linenr;
 };
 
-void git_config(config_fn_t fn, void *data)
+static void git_config_raw(config_fn_t fn, void *data)
 {
if (git_config_with_options(fn, data, NULL, 1) < 0)
/*
@@ -1252,6 +1246,33 @@ void git_config(config_fn_t fn, void *data)
die(_("unknown error occured while reading the configuration 
files"));
 }
 
+static void configset_iter(struct config_set *cs, config_fn_t fn, void *data)
+{
+   int i, value_index;
+   struct string_list *values;
+   struct config_set_element *entry;
+   struct configset_list *list = &cs->list;
+   struct key_value_info *kv_info;
+
+   for (i = 0; i < list->nr; i++) {
+   entry = list->items[i].e;
+   value_index = list->items[i].value_index;
+   values = &entry->value_list;
+   if (fn(entry->key, values->items[value_index].string, data) < 
0) {
+   kv_info = values->items[value_index].util;
+   git_die_config_linenr(entry->key, kv_info->filename, 
kv_info->linenr);
+   }
+   }
+}
+
+static void git_config_check_init(void);
+
+void git_config(config_fn_t fn, void *data)
+{
+   git_config_check_init();
+   configset_iter(&the_config_set, fn, data);
+}
+
 static struct config_set_element *configset_find_element(struct config_set 
*cs, const char *key)
 {
struct config_set_element k;
@@ -1278,6 +1299,7 @@ static int configset_add_value(struct config_set *cs, 
const char *key, const cha
 {
struct config_set_element *e;
struct string_list_item *si;
+   struct configset_list_item *l_item;
struct key_value_info *kv_info = xmalloc(sizeof(*kv_info));
 
e = configset_find_element(cs, key);
@@ -1293,6 +1315,12 @@ static int configset_add_value(struct config_set *cs, 
const char *key, const cha
hashmap_add(&cs->config_hash, e);
}
si = string_list_append_nodup(&e->value_list, value ? xstrdup(value) : 
NULL);
+
+   ALLOC_GROW(cs->list.items, cs->list.nr + 1, cs->list.alloc);
+   l_item = &cs->list.items[cs->list.nr++];
+   l_item->e = e;
+   l_item->value_index = e->value_list.nr - 1;
+
if (cf) {
kv_info->filename = strintern(cf->name);
kv_info->linenr = cf->linenr;
@@ -1316,6 +1344,9 @@ void git_configset_init(struct config_set *cs)
 {
hashmap_init(&cs->config_hash, (hashmap_cmp_fn)config_set_element_cmp, 
0);
cs->hash_initialized = 1;
+   cs->list.nr = 0;
+ 

[PATCH v7 3/8] add line number and file name info to `config_set`

[Tanay Abhra]

Store file name and line number for each key-value pair in the cache
during parsing of the configuration files.

Signed-off-by: Tanay Abhra 
---
 config.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/config.c b/config.c
index bb4629e..e685b66 100644
--- a/config.c
+++ b/config.c
@@ -1230,6 +1230,11 @@ int git_config_with_options(config_fn_t fn, void *data,
return ret;
 }
 
+struct key_value_info {
+   const char *filename;
+   int linenr;
+};
+
 int git_config(config_fn_t fn, void *data)
 {
return git_config_with_options(fn, data, NULL, 1);
@@ -1260,6 +1265,9 @@ static struct config_set_element 
*configset_find_element(struct config_set *cs,
 static int configset_add_value(struct config_set *cs, const char *key, const 
char *value)
 {
struct config_set_element *e;
+   struct string_list_item *si;
+   struct key_value_info *kv_info = xmalloc(sizeof(*kv_info));
+
e = configset_find_element(cs, key);
/*
 * Since the keys are being fed by git_config*() callback mechanism, 
they
@@ -1272,7 +1280,16 @@ static int configset_add_value(struct config_set *cs, 
const char *key, const cha
string_list_init(&e->value_list, 1);
hashmap_add(&cs->config_hash, e);
}
-   string_list_append_nodup(&e->value_list, value ? xstrdup(value) : NULL);
+   si = string_list_append_nodup(&e->value_list, value ? xstrdup(value) : 
NULL);
+   if (cf) {
+   kv_info->filename = strintern(cf->name);
+   kv_info->linenr = cf->linenr;
+   } else {
+   /* for values read from `git_config_from_parameters()` */
+   kv_info->filename = strintern("parameter");
+   kv_info->linenr = 0;
+   }
+   si->util = kv_info;
 
return 0;
 }
@@ -1299,7 +1316,7 @@ void git_configset_clear(struct config_set *cs)
hashmap_iter_init(&cs->config_hash, &iter);
while ((entry = hashmap_iter_next(&iter))) {
free(entry->key);
-   string_list_clear(&entry->value_list, 0);
+   string_list_clear(&entry->value_list, 1);
}
hashmap_free(&cs->config_hash, 1);
cs->hash_initialized = 0;
-- 
1.9.0.GIT

--
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

[PATCH v7 4/8] change `git_config()` return value to void

[Tanay Abhra]

Currently `git_config()` returns an integer signifying an error code.
During rewrites of the function most of the code was shifted to
`git_config_with_options()`. `git_config_with_options()` normally
returns positive values if its `config_source` parameter is set as NULL,
as most errors are fatal, and non-fatal potential errors are guarded
by "if" statements that are entered only when no error is possible.

Still a negative value can be returned in case of race condition between
`access_or_die()` & `git_config_from_file()`. Also, all callers of
`git_config()` ignore the return value except for one case in branch.c.

Change `git_config()` return value to void and make it die if it receives
a negative value from `git_config_with_options()`.

Original-patch-by: Matthieu Moy 
Signed-off-by: Tanay Abhra 
---
 branch.c |  5 +
 cache.h  |  2 +-
 config.c | 16 ++--
 3 files changed, 16 insertions(+), 7 deletions(-)

diff --git a/branch.c b/branch.c
index 46e8aa8..735767d 100644
--- a/branch.c
+++ b/branch.c
@@ -161,10 +161,7 @@ int read_branch_desc(struct strbuf *buf, const char 
*branch_name)
strbuf_addf(&name, "branch.%s.description", branch_name);
cb.config_name = name.buf;
cb.value = NULL;
-   if (git_config(read_branch_desc_cb, &cb) < 0) {
-   strbuf_release(&name);
-   return -1;
-   }
+   git_config(read_branch_desc_cb, &cb);
if (cb.value)
strbuf_addstr(buf, cb.value);
strbuf_release(&name);
diff --git a/cache.h b/cache.h
index 7292aef..c61919d 100644
--- a/cache.h
+++ b/cache.h
@@ -1294,7 +1294,7 @@ extern int git_config_from_buf(config_fn_t fn, const char 
*name,
   const char *buf, size_t len, void *data);
 extern void git_config_push_parameter(const char *text);
 extern int git_config_from_parameters(config_fn_t fn, void *data);
-extern int git_config(config_fn_t fn, void *);
+extern void git_config(config_fn_t fn, void *);
 extern int git_config_with_options(config_fn_t fn, void *,
   struct git_config_source *config_source,
   int respect_includes);
diff --git a/config.c b/config.c
index e685b66..f923b1c 100644
--- a/config.c
+++ b/config.c
@@ -1235,9 +1235,21 @@ struct key_value_info {
int linenr;
 };
 
-int git_config(config_fn_t fn, void *data)
+void git_config(config_fn_t fn, void *data)
 {
-   return git_config_with_options(fn, data, NULL, 1);
+   if (git_config_with_options(fn, data, NULL, 1) < 0)
+   /*
+* git_config_with_options() normally returns only
+* positive values, as most errors are fatal, and
+* non-fatal potential errors are guarded by "if"
+* statements that are entered only when no error is
+* possible.
+*
+* If we ever encounter a non-fatal error, it means
+* something went really wrong and we should stop
+* immediately.
+*/
+   die(_("unknown error occured while reading the configuration 
files"));
 }
 
 static struct config_set_element *configset_find_element(struct config_set 
*cs, const char *key)
-- 
1.9.0.GIT

--
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

[PATCH v7 8/8] add tests for `git_config_get_string_const()`

[Tanay Abhra]

Add tests for `git_config_get_string_const()`, check whether it
dies printing the line number and the file name if a NULL
value is retrieved for the given key.

Signed-off-by: Tanay Abhra 
---
 t/t1308-config-set.sh | 10 ++
 test-config.c | 10 ++
 2 files changed, 20 insertions(+)

diff --git a/t/t1308-config-set.sh b/t/t1308-config-set.sh
index e2f9d0b..f012dd6 100755
--- a/t/t1308-config-set.sh
+++ b/t/t1308-config-set.sh
@@ -119,6 +119,16 @@ test_expect_success 'find integer value for a key' '
check_config get_int lamb.chop 65
 '
 
+test_expect_success 'find string value for a key' '
+   check_config get_string case.baz hask &&
+   check_config expect_code 1 get_string case.ba "Value not found for 
\"case.ba\""
+'
+
+test_expect_success 'check line error when NULL string is queried' '
+   test_expect_code 128 test-config get_string case.foo 2>result &&
+   grep "fatal: bad config variable '\''case.foo'\'' at file line 7 in 
.git/config" result
+'
+
 test_expect_success 'find integer if value is non parse-able' '
check_config expect_code 128 get_int lamb.head
 '
diff --git a/test-config.c b/test-config.c
index 9dd1b22..6a77552 100644
--- a/test-config.c
+++ b/test-config.c
@@ -16,6 +16,8 @@
  *
  * get_bool -> print bool value for the entered key or die
  *
+ * get_string -> print string value for the entered key or die
+ *
  * configset_get_value -> returns value with the highest priority for the 
entered key
  * from a config_set constructed from files entered as 
arguments.
  *
@@ -84,6 +86,14 @@ int main(int argc, char **argv)
printf("Value not found for \"%s\"\n", argv[2]);
goto exit1;
}
+   } else if (argc == 3 && !strcmp(argv[1], "get_string")) {
+   if (!git_config_get_string_const(argv[2], &v)) {
+   printf("%s\n", v);
+   goto exit0;
+   } else {
+   printf("Value not found for \"%s\"\n", argv[2]);
+   goto exit1;
+   }
} else if (!strcmp(argv[1], "configset_get_value")) {
for (i = 3; i < argc; i++) {
int err;
-- 
1.9.0.GIT

--
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

[PATCH v7 7/8] add a test for semantic errors in config files

[Tanay Abhra]

Semantic errors (for example, for alias.* variables NULL values are
not allowed) in configuration files cause a die printing the line
number and file name of the offending value.

Add a test documenting that such errors cause a die printing the
accurate line number and file name.

Signed-off-by: Tanay Abhra 
---
 t/t1308-config-set.sh | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/t/t1308-config-set.sh b/t/t1308-config-set.sh
index 7fdf840..e2f9d0b 100755
--- a/t/t1308-config-set.sh
+++ b/t/t1308-config-set.sh
@@ -197,4 +197,15 @@ test_expect_success 'proper error on error in custom 
config files' '
test_cmp expect actual
 '
 
+test_expect_success 'check line errors for malformed values' '
+   mv .git/config .git/config.old &&
+   test_when_finished "mv .git/config.old .git/config" &&
+   cat >.git/config <<-\EOF &&
+   [alias]
+   br
+   EOF
+   test_expect_code 128 git br 2>result &&
+   grep "fatal: bad config variable '\''alias.br'\'' at file line 2 in 
.git/config" result
+'
+
 test_done
-- 
1.9.0.GIT

--
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

Re: [PATCH v3 1/3] lockfile.c: remove PATH_MAX limitation (except in resolve_symlink)

[Junio C Hamano]

Nguyễn Thái Ngọc Duy   writes:

> diff --git a/lockfile.c b/lockfile.c
> index 8fbcb6a..968b28f 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -7,13 +7,19 @@
>  static struct lock_file *lock_file_list;
>  static const char *alternate_index_output;
>  
> +static void clear_filename(struct lock_file *lk)
> +{
> + free(lk->filename);
> + lk->filename = NULL;
> +}
> +

Given that you move commit_locked_index(), which you need to use
this function in, to read-cache.c in your own nd/split-index series,
this will need to be exposed to the wider world, and at that point,
its name will turn out to be too generic.
--
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

Re: cherry picking and merge

[Mike Stump]

On Aug 1, 2014, at 9:27 AM, Jakub Narębski  wrote:
> 
> Note that you should try to avoid cherry-picking, as they do not
> leave trace in the graph of revisions.

Fine, then I want a new command to merge in a change into my branch from 
another branch and I want merge to account for the motion and not duplicate it 
when I merge that branch back into master.  Funny thing is, cherry and merge 
seem to be documented mostly to do exactly what I want.

> For example if you are creating a bugfix, instead of putting it
> directly on maint, and then cherry-picking to master, it is better
> to create a separate feature branch for this fix

You’re assuming that I’m the author of master, I’m not, I’m merely a 
contributor.  This tail doesn’t wag that dog.  What that means is that I cannot 
change the world to work around a simple bug in git.

> There is also git-imerge, third party tool that is intended to help
> merging changes (and make it possible to do it in incremental way).

Then remove git merge and replace it with git-imerge.  :-)  Anyway, I read 
that, and I can see some beauty of that that might be nice in complex merges.  
The problem is, I want git merge to work.


I was curious if svn handles this better the same or worse, and it did it just 
fine.  I know that a while ago, svn could not handle this, it would do what git 
does currently.  Apparently they figured out it was a bug and fixed it.  Have 
you guys figured out it is a bug yet?  The first step in solving a problem, is 
admitting you have a problem.--
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

Cross compiling git for ARM

[Robert Dailey]

Hello,

I'm interested in cross compiling Git 2.0.3 (I have a clone from
github) for ARM. Ideally I'd like to use the prebuilt gcc eabi
toolchain bundled with Android NDK, since I plan to run the git
executable on an ARM device running the android kernel.

I've looked into the "./configure --help" documentation but nothing
strikes me as helpful for this. I also have relied heavily on Google
searching but again I'm hitting dead ends.

I'm not an expert with Linux, so it would really help to have a set of
instructions that are detailed and easy to understand.

Here is as far as I've gotten:

1. Ran "autoconf" inside my git clone root.
2. Ran "./configure --prefix=/home/fe/git-arm --build=x86_64-linux-gnu
--host=arm-linux-gnueabi"
3. Ran "make"
4. Build fails because there is no OpenSSL.

Then I began to wonder, do I need to cross compile OpenSSL, ZLib, and
other things too? This is getting pretty messy :(

Note that on step #2 I am using the gcc arm cross compiler from Ubuntu
package manager, because I couldn't for the life of me get the Android
NDK toolchain working. I'm fine with using the ubuntu one as long as
it yields an ARM executable that can be run on my device.

Our device is ARM Cortex - A8, so I'm not sure what version of GCC ARM
is compatible with this chip.

Thanks in advance for any help at 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

Re: [PATCH v3 1/3] lockfile.c: remove PATH_MAX limitation (except in resolve_symlink)

[Junio C Hamano]

Junio C Hamano  writes:

> Nguyễn Thái Ngọc Duy   writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy 
>
> Somewhat underexplained, given that it seems to add some new
> semantics.
>
>> +static void clear_filename(struct lock_file *lk)
>> +{
>> +free(lk->filename);
>> +lk->filename = NULL;
>> +}
>
> It is good to abstract out lk->filename[0] = '\0', which used to be
> the way we say that we are done with the lock.  But I am somewhat
> surprised to see that there aren't so many locations that used to
> check !!lk->filename[0] to see if we are done with the lock to require
> a corresponding wrapper.
>
>>  static void remove_lock_file(void)
>>  {
>>  pid_t me = getpid();
>>  
>>  while (lock_file_list) {
>>  if (lock_file_list->owner == me &&
>> -lock_file_list->filename[0]) {
>> +lock_file_list->filename) {
>
> ... and this seems to be the only location?

While looking at possible fallout of merging this topic to any
branch, I am starting to suspect that it is probably a bad idea for
clear-filename to free lk->filename.  I am wondering if it would be
safer to do:

 - in lock_file(), free lk->filename if it already exists before
   what you do in that function with your series;

 - update "is this lock already held?" check !!lk->filename[0] to
   check for (lk->filename && !!lk->filename[0]);

 - in clear_filename(), clear lk->filename[0] = '\0', but do not
   free lk->filename itself.

Then existing callers that never suspected that lk->filename can be
NULL and thought that it does not need freeing can keep doing the
same thing as before without leaking nor breaking.

If we want to adopt the new world order at once, alternatively, you
can keep the code in this series but then lk->filename needs to be
renamed to something that the current code base has not heard of to
force breakage at the link time for us to notice.

I grepped for 'lk->filename' and checked if the ones in read-cache.c
and refs.c are OK (they seem to be), but that is not a very robust
check.

I dunno.

--
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

Re: Show containing branches in log?

[Robert Dailey]

On Thu, Jul 3, 2014 at 2:41 PM, Øyvind A. Holm  wrote:
> I have created a script for just this functionality which I use very
> often, and have created a gist with the files at
> , I think it
> should solve your problem. It contains these files:
>
>   git-wn
>
> "wn" means "What's New" and will create a visual graph of all commits
> which has a specified ref as ancestor. It also needs the following
> script, just put it into your $PATH somewhere:
>
>   git-lc
>
> "lc" means "List branches Containing this commit" and generates a list
> of all branches containing a specified ref.
>
> The files originates from , but
> I've modified them in the gist to make your life easier. :)

Sorry for the late response. I forgot to thank you for this! This is
very detailed and helpful... I will try this soon and see how it
works.

Great job.
--
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

Re: cherry picking and merge

[Philip Oakley]

From: "Mike Stump" 

On Aug 1, 2014, at 9:27 AM, Jakub Narębski  wrote:


Note that you should try to avoid cherry-picking, as they do not
leave trace in the graph of revisions.


Fine, then I want a new command to merge in a change into my branch 
from another branch and I want merge to account for the motion and not 
duplicate it when I merge that branch back into master.  Funny thing 
is, cherry and merge seem to be documented mostly to do exactly what I 
want.



For example if you are creating a bugfix, instead of putting it
directly on maint, and then cherry-picking to master, it is better
to create a separate feature branch for this fix


You’re assuming that I’m the author of master, I’m not, I’m merely a 
contributor.  This tail doesn’t wag that dog.  What that means is that 
I cannot change the world to work around a simple bug in git.



There is also git-imerge, third party tool that is intended to help
merging changes (and make it possible to do it in incremental way).


Then remove git merge and replace it with git-imerge.  :-)  Anyway, I 
read that, and I can see some beauty of that that might be nice in 
complex merges.  The problem is, I want git merge to work.



I was curious if svn handles this better the same or worse, and it did 
it just fine.  I know that a while ago, svn could not handle this, it 
would do what git does currently.  Apparently they figured out it was 
a bug and fixed it.  Have you guys figured out it is a bug yet?  The 
first step in solving a problem, is admitting you have a problem.

--
But that goes both ways, and is a philosophical issue about what is to 
be expected in various cases. For some central control use styles, the 
ideas behind _distributed_ version control are anathema and (Git) just 
grinds away at the policies that are expected.


That said, Git doesn't claim to be perfect (and can't because of the 
'relativity' that comes with being distributed - truth has to give way 
to a web of trust). Also the artefacts that Git validates are at a 
different level of abstraction i.e. the whole project as a commit, 
rather than just a few/one file at a time.


In your example (when generalised) the problem is deciding when, in the 
change sequence, the cherry pick is to be backed out, especially if 
there are conflicts in the change sequence that would need fixing 
anyway, and in a long change sequence that would be a lot of conflict 
fix-ups, hence the current choice of getting the merge conflicts all 
resolved in the one go.


The alternate case, mentioned/implied by Brian, is to use a rebase 
(probably after duplicating the branch so as to retain the original if 
required) so as to see each patch/changeset being applied, and doing 
any/many conflit resolutions as they appear, before finally doing any 
merge of the new line of development back into the mainline (which again 
presumes your earlier resolutions don't cause more conflicts on that 
merge). But do note that I've hidden the problem of deciding where the 
rebase start point should be, relative to the merge point, because 
that's actually where the original problem is hidden (which bits merge 
with what!)


git-imerge is a visual tool to show which bits merge cleanly with what 
between two change sequences.


Selecting a compatible workflow is a problem of usage, rather than a 
problem in Git. If Git has a problem, it's that it has too many ways of 
doing things, leaving most of us with too much rope entangled round our 
neck.

--
Philip

--
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

Re: Is there a way to mark a branch as published?

[Dennis Kaarsemaker]

On di, 2014-07-29 at 17:40 -0500, Nico Williams wrote:
> (or all of a repo's branches)
> 
> Teamware recorded whether it had any "children" and warned about
> rebasing published contents.  Perhaps git could do the same.

Git doesn't record this directly, but you can see which known remote
branches contain the tip of a branch:

git branch -a --contains yourbranchnamehere | grep remotes/

That doesn't say anything about remotes you don't know about of course.
-- 
Dennis Kaarsemaker
www.kaarsemaker.net

--
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

Fwd: cherry picking and merge

[Jakub Narębski]

[sorry for duplicate sent as private mail; I forgot to turn off HTML
when sending to the git mailing list]

On Fri, Aug 1, 2014 at 7:48 PM, Mike Stump  wrote:
[...]
>
> I was curious if svn handles this better the same or worse, and it did it 
> just fine.  I know that a while ago, svn could not handle this, it would do 
> what git does currently.  Apparently they figured out it was a bug and fixed 
> it.  Have you guys figured out it is a bug yet?  The first step in solving a 
> problem, is admitting you have a problem.


It can work in Subversion because Subversion stores information about
what was merged in (and this includes cherry-picks, or whatever it is
named in svn) in svn:mergeinfo property. Git does not track what was
merged in, instead it represent the history as the graph of revisions,
and tracks merges (by storing that it came from two or more commits)
and not merged-in information.

When merging Git uses only what is being merged and its common
ancestor (3-point merge). It is simple, and simple works!!!
Unfortunately, it does not see cherry-picked commits - it is invisible
to merge as being on the chain from one of merged commits to the
common ancestor.

The rebase command handles cherry-picked commits by detecting that the
change was already applied. I think that git-imerge does the same (but
I have not used it myself).

Have you tried git-imerge?

-- 
Jakub Narębski



-- 
Jakub Narebski
--
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

Re: Bug report about symlinks

[Dennis Kaarsemaker]

On wo, 2014-07-30 at 15:30 +0400, NickKolok wrote:
> 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.

I think there is a bug here:

+ mkdir bug
+ cd bug
+ git init
Initialized empty Git repository in /tmp/bug/.git/
+ mkdir dir1 dir2
+ echo 1
+ echo 1
+ echo 2a
+ echo 2b
+ git add dir1/1.txt dir1/2.txt dir2/1.txt dir2/2.txt
+ git commit -m first
[master (root-commit) b60ecc8] first
 4 files changed, 4 insertions(+)
 create mode 100644 dir1/1.txt
 create mode 100644 dir1/2.txt
 create mode 100644 dir2/1.txt
 create mode 100644 dir2/2.txt
+ rm -r dir2
+ ln -s dir1 dir2
+ git status
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working
directory)

deleted:dir2/2.txt

Untracked files:
  (use "git add ..." to include in what will be committed)

dir2

no changes added to commit (use "git add" and/or "git commit -a")

It looks like git status is thinking dir2/1.txt still exists with the
same content, even though dir2 is gone, and now an untracked symlink. 

Moreover, git diff and git status disagree with each other:

dennis@spirit:/tmp/bug$ git status
On branch master
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working
directory)

deleted:dir2/2.txt

Untracked files:
  (use "git add ..." to include in what will be committed)

dir2

no changes added to commit (use "git add" and/or "git commit -a")
dennis@spirit:/tmp/bug$ git --no-pager diff
diff --git a/dir2/1.txt b/dir2/1.txt
deleted file mode 100644
index d00491f..000
--- a/dir2/1.txt
+++ /dev/null
@@ -1 +0,0 @@
-1
diff --git a/dir2/2.txt b/dir2/2.txt
deleted file mode 100644
index b8a4cf4..000
--- a/dir2/2.txt
+++ /dev/null
@@ -1 +0,0 @@
-2b

-- 
Dennis Kaarsemaker
www.kaarsemaker.net

--
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

Re: Is there a way to mark a branch as published?

[Nico Williams]

On Friday, August 1, 2014, Dennis Kaarsemaker  wrote:
>
> On di, 2014-07-29 at 17:40 -0500, Nico Williams wrote:
> > (or all of a repo's branches)
> >
> > Teamware recorded whether it had any "children" and warned about
> > rebasing published contents.  Perhaps git could do the same.
>
> Git doesn't record this directly, but you can see which known remote
> branches contain the tip of a branch:

Yes, but that says nothing about whether they accept non-ff merge
pushes, or should reject them, and it says nothing about whether they
are intended to be seen as "published" in the sense of having stable
history.  (Teamware would mark repos as published when cloned, but
that often meant needing to reset that flag [it wasn't a flag, but i'm
eliding irrelevant details].)

Yes, non-fast-forward pushes can be rejected with a hook, but a flag
that could be set with a git command would be more convenient.
--
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

[PATCH] doc: format-patch: don't use origin as a branch name

[Philip Oakley]

Historically (5 Nov 2005 v0.99.9-46-g28ffb89) the git-format-patch used
'origin' as the upstream branch name. This is now used to name the remote.
Use the more modern 'master' as the branch name.

Signed-off-by: Philip Oakley 
---

I noticed this while cross-checking details for updating the guide
Documentation/(git)everyday.txt
--
Philip

 Documentation/git-format-patch.txt | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/git-format-patch.txt 
b/Documentation/git-format-patch.txt
index c0fd470..b0f041f 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -523,25 +523,25 @@ $ git format-patch -k --stdout R1..R2 | git am -3 -k
 
 
 * Extract all commits which are in the current branch but not in the
-origin branch:
+master branch:
 +
 
-$ git format-patch origin
+$ git format-patch master
 
 +
 For each commit a separate file is created in the current directory.
 
-* Extract all commits that lead to 'origin' since the inception of the
+* Extract all commits that lead to 'master' since the inception of the
 project:
 +
 
-$ git format-patch --root origin
+$ git format-patch --root master
 
 
 * The same as the previous one:
 +
 
-$ git format-patch -M -B origin
+$ git format-patch -M -B master
 
 +
 Additionally, it detects and handles renames and complete rewrites
-- 
1.9.4.msysgit.0

--
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

cherry picking and merge

[Nico Williams]

On Thursday, July 31, 2014, Mike Stump  wrote:
>
> Cherry picking doesn’t work as well as it should.  I was testing on git 
> version 1.7.9.5.
>
> Put in a line in a file, call it:
>
> first version
>
> then cherry pick this into your branch. Then update on master and transform 
> that into:
>
> second version
>
> then, merge that branch back to master.  Death in the form of conflicts.

The problem is that cherry-picked commits lack the metadata that git
merge could use to avoid this spurious conflict report.  The reflog
has the metadata in question, but there's no guarantee that that
reflog will be available where you do the merge.  (IMO this is another
reason to want branches as objects, so such ancillary information can
be recorded somewhere, but in a way that can get dropped if desired
and without changing commit hashes, but I digress.)

If you always rebase your commits on top of the upstream, then this
problem goes away.  You can't always rebase your commits on top of the
upstream though, but wherever possible it's the best course of action
for this and other reasons.

Nico
--
--
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

Re: [PATCH] doc: format-patch: don't use origin as a branch name

[Jonathan Nieder]

Philip Oakley wrote:

> Historically (5 Nov 2005 v0.99.9-46-g28ffb89) the git-format-patch used
> 'origin' as the upstream branch name. This is now used to name the remote.
> Use the more modern 'master' as the branch name.

Would 'origin/master' make sense?

Thanks,
Jonathan
--
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

Git Help needed

[RaviKiranGoud_Palpanoori]

Hi,
I am writing below couple of questions. If it is not the right place to ask 
please ignore and suggest me what to do to get the help on these questions.

1) What version of SSL is supported by GIT 1.8.3 or GIT 1.9.0

2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked fine and 
able to extract code from git repository directly as well as from ant. 
Everything went well.
Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git commands 
are not working. Basic help and version works fine as expected. When I try to 
pull the code from git repository it give SSL library compatibility issue.

The error is 
OpenSSL version mismatch. Built agains 1000105f, you have 10bf
fatal: Could not read from remote repository

In order to get rid of this, I upgraded git to 1.9.0 GIT. But still it didn't 
work. The issue is still coming. 

git help, version works. 
When I tried directly pulling code using git pull command - didn't work.
When I try to pull the code through the ant - didn't work

The ant version is 1.8.0RC1

AIX admin worked on this and provided below comments

Comments form AIX system admin  (Pasted as it is)
Even after installing 1.9.0 version of GIT the library files are not compatible 
with the latest version of SSL (1.0.5.1).
SSL works fine as a root user and other users. This compatibility issue only a 
raises when the LIBPATH for GIT is set and the SSL picks up its LIBPATH from 
the same location as GIT and this causes the incompatibility.
Can you find out from the GIT/ANT support team on what version of SSL GIT 
supports exactly. - The is specifically with the GIT/SSL as the user "xyzabc" . 
The SSL otherwise works perfectly fine.
You will have to re-compile the ANT libraries to use the latest library files.

Thanks in advance.

Regards,
Ravi.
--
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

Re: Git Help needed

[Ronnie Sahlberg]

This looks more like a packaging/build issue than a git issue.

It looks like whomever built your version of git built it against a
specific version of the OpenSSL library.
You should probably contact the folks that built your binary and ask
them to update and build against the version that the new version of
aix ships with.

Alternatively if you build git yourself on that host you should end up
with a binary that links with the version of the library that you
currently have.



On Fri, Aug 1, 2014 at 12:30 PM,   wrote:
> Hi,
> I am writing below couple of questions. If it is not the right place to ask 
> please ignore and suggest me what to do to get the help on these questions.
>
> 1) What version of SSL is supported by GIT 1.8.3 or GIT 1.9.0
>
> 2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked fine and 
> able to extract code from git repository directly as well as from ant. 
> Everything went well.
> Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git commands 
> are not working. Basic help and version works fine as expected. When I try to 
> pull the code from git repository it give SSL library compatibility issue.
>
> The error is
> OpenSSL version mismatch. Built agains 1000105f, you have 10bf
> fatal: Could not read from remote repository
>
> In order to get rid of this, I upgraded git to 1.9.0 GIT. But still it didn't 
> work. The issue is still coming.
>
> git help, version works.
> When I tried directly pulling code using git pull command - didn't work.
> When I try to pull the code through the ant - didn't work
>
> The ant version is 1.8.0RC1
>
> AIX admin worked on this and provided below comments
>
> Comments form AIX system admin  (Pasted as it is)
> Even after installing 1.9.0 version of GIT the library files are not 
> compatible with the latest version of SSL (1.0.5.1).
> SSL works fine as a root user and other users. This compatibility issue only 
> a raises when the LIBPATH for GIT is set and the SSL picks up its LIBPATH 
> from the same location as GIT and this causes the incompatibility.
> Can you find out from the GIT/ANT support team on what version of SSL GIT 
> supports exactly. - The is specifically with the GIT/SSL as the user "xyzabc" 
> . The SSL otherwise works perfectly fine.
> You will have to re-compile the ANT libraries to use the latest library files.
>
> Thanks in advance.
>
> Regards,
> Ravi.
> --
> 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
--
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

Re: cherry picking and merge

[Jonathan Nieder]

Hi Mike,

Mike Stump wrote:

> Cherry picking doesn’t work as well as it should.  I was testing on
> git version 1.7.9.5.
>
> Put in a line in a file, call it:
>
> first version
>
> then cherry pick this into your branch. Then update on master and
> transform that into:
>
> second version
>
> then, merge that branch back to master.  Death in the form of conflicts.

Do you mean that "git merge" should be aware of what changes you have
already cherry-picked?

It isn't, and that's deliberate ("git merge" is designed to be simple
as possible, though no more simple than that).  This way, if on a side
branch someone makes a change that would conflict with "master" and
then backs it out, then the branch can still merge cleanly.

Generally people do one of the following:

 * Use a merge-centric workflow.  Don't cherry-pick "forward" but
   merge instead.  (Do use cherry-pick for backports when you forgot
   to commit a fix on top of the oldest supported branch that would
   need it.)  The gitworkflows(7) manpage has more details on how
   this works.

 * Use a cherry-pick-centric workflow.  Never merge.  Notice when
   you're trying to apply a patch you already applied and skip it.
   (Others in the thread have covered this workflow a little.)

Even in those workflows, it's possible to have conflicts due to
genuinely conflicting changes, even with no cherry-pick involved.  I
find the '[merge] conflictstyle = diff3' setting (see git-config(1))
and git-rerere(1) to be helpful in making that less painful.

Hope that helps,
Jonathan
--
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

Re: Git Help needed

[brian m. carlson]

On Fri, Aug 01, 2014 at 07:30:11PM +, ravikirangoud_palpano...@vfc.com 
wrote:
> Hi,
> I am writing below couple of questions. If it is not the right place
> to ask please ignore and suggest me what to do to get the help on
> these questions.
> 
> 1) What version of SSL is supported by GIT 1.8.3 or GIT 1.9.0

The INSTALL file doesn't mention a particular OpenSSL version that we
require, but I know that it works with versions as old as 0.9.8 and as
new as 1.0.1g.  It may work with still older versions, but I recommend
1.0.1 or newer as it gives you proper TLS 1.2 support.

> 2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked
> fine and able to extract code from git repository directly as well as
> from ant. Everything went well.
> Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git
> commands are not working. Basic help and version works fine as
> expected. When I try to pull the code from git repository it give SSL
> library compatibility issue.
> 
> The error is 
> OpenSSL version mismatch. Built agains 1000105f, you have 10bf
> fatal: Could not read from remote repository

OpenSSL 1.0.0 (which you were using before) and OpenSSL 1.0.1 are binary
compatible if compiled with the same flags, but they contain a hard
version check that fails if they're not the same version.

This means you need to recompile git against the newer OpenSSL version,
or ask your vendor to patch this check out.  This is true for any
program that gives you this error.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: [PATCH] doc: format-patch: don't use origin as a branch name

[Junio C Hamano]

Jonathan Nieder  writes:

> Philip Oakley wrote:
>
>> Historically (5 Nov 2005 v0.99.9-46-g28ffb89) the git-format-patch used
>> 'origin' as the upstream branch name. This is now used to name the remote.
>> Use the more modern 'master' as the branch name.
>
> Would 'origin/master' make sense?

It would make a lot more sense than 'master', I think.

The 'origin' will be DWIMmed to whatever the remote designated as
its primary branch, i.e. refs/remotes/origin/HEAD, and the
assumption the examples in question makes is that the user is
following along the simplest workflow to fork from it and upstream
her changes.  Between 'origin' and 'origin/master', there isn't much
difference because of it.  In the same spirit of following the
simplest workflow, that primary branch is likely to be their
'master', so 'origin/master' is OK but longer than 'origin' [*1*].

On the other hand, 'master' names the local 'master', which may be
very stale with respect to 'origin/master', or may have tons of
unrelated things that are not in origin/master, some of which may
have come from the branch the user is running format-patch to grab
patches to upstream.  For this reason, changing 'origin' to 'master'
is not an improvement at all, I would have to say.

We could further adjust the underlying assumption to more modern
"checkout -t -b" era, and use "format-patch @{u}", but I suspect
that the readers of these examples are not yet ready for magic
before the basics to spell out things more explicitly is covered.


[Footnote]

*1* Also using 'origin' will cover the case when the primary branch
at the remote were not named 'master', so in that sense it is
slightly better and more generally applicable.
--
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

Re: cherry picking and merge

[Sam Vilain]

On 08/01/2014 10:48 AM, Mike Stump wrote:
>> There is also git-imerge, third party tool that is intended to help
>> merging changes (and make it possible to do it in incremental way).
> Then remove git merge and replace it with git-imerge.  :-)  Anyway, I read 
> that, and I can see some beauty of that that might be nice in complex merges. 
>  The problem is, I want git merge to work.


Git merge has a notion of discrete "merge strategies".  The default,
"recursive" merge strategy isn't completely oblivious to history; in the
event that the two branches don't have a single merge bases, it performs
3-way merges (strangely enough) recursively, with the merge bases of the
branch you're trying to merge until it completes.  In general, this
works pretty well.  Some systems even simpler than that (eg, github's
green merge button) work acceptably as well.

There's no particular reason that you couldn't implement a merge
strategy which works more like SVN's approach, which essentially does an
internal rebase and then commits the result.  The advantages of a rebase
in this situation is that you get to eliminate changes which don't need
to be applied, either because (in SVN's case), it had some
metadata/hearsay information that told it that it could skip that
change, or (in git's case), because it found content/facts that the
change already was applied on one side.

However, there are corresponding disadvantages to this strategy.  It's
just as easy to contrive a situation where this "internal rebasing"
doesn't do the right thing, even without cheating by getting the
metadata wrong.  And besides, there's already a way to do this: do an
actual rebase.  You could also do a rebase, and then if, say, the
original branch you're rebasing is published and you don't want to
rewrite, then you can easily enough use squash merging, merge -s ours,
etc to make it look like the strategy you wanted was a built-in git
merge strategy.  Or, in the spirit of open source, you could contribute
the code required to make 'imerge' a built-in strategy.

> I was curious if svn handles this better the same or worse, and it did it 
> just fine.  I know that a while ago, svn could not handle this, it would do 
> what git does currently.  Apparently they figured out it was a bug and fixed 
> it.  Have you guys figured out it is a bug yet?  The first step in solving a 
> problem, is admitting you have a problem.

So, I have to chuckle when I read this indignant comment.  There's a
funny story to the "while ago" you refer to.  This refers to the time
period during which SVN was relevant; about versions 1.4 and earlier
(being generous).  Back in those days, SVN projects for the most part
avoided merging, because it was so problematic and not tracked at all. 
As one core SVN developer said to me, they found "teams collaborate more
closely if they're all working on the same branch".  Sure, you could do
it, and I even know of a few communities who did, but by and large, it
was avoided.  Then, the new wave of version control systems including
Git, bzr and Mercurial were cropping up, and their merges were actually
good enough that you could practically use them.

The SVN core team had to keep pace to match.  So, in 1.5 the "merge
tracking" system, previously only supplied as a "contrib" script, became
core.  This is ironic, because the version control system which SVN
imitated poorly--Perforce--had a very sophisticated, if
over-complicated, merge tracking system which was also based on
metadata.  Per-branch, per-patch, per-file entries for whether or not a
patch had been "integrated" into the target branch.  I can only guess
that the reason they didn't implement this in the original SVN version
was that it was something of a pain point for users in Perforce. 
Possibly something to do with the way that Perforce would store double
entries for each merge (yes: two rows in a relational store, one
representing the mirror image of the other), and differentiated between
many different forms of "integrated" (ie, 2 rows and 4 states instead
of, say, a single bit).  So the underlying data model wasn't as simple
as it could have been, and this was reflected in the difficult to use
command-line tools.  Plus, they were using BerkeleyDB for metadata
instead of the relational ISAM library, and debugging a rabbit's nest of
merge record as Perforce used would have been a nightmare.  They didn't
go there.  And besides, they found that often, detecting patches as
already applied based on content, like 'patch' did, worked.

Prior to 1.5, the Perl community developed SVK, an offline version of
SVN, and this had a far simpler model for merge tracking, more similar
to git's: just tracking whole-branch merges rather than individual
files, patches, and branches.  SVN eventually added two separate ways of
tracking merges: either a per-file, per-branch, per-commit or a
per-branch, per-commit model.

Anyway, I'm not sure where I'm going with this, but I guess a little
extra perspec

RE: Git Help needed

[RaviKiranGoud_Palpanoori]

Hi Ronnie Sahlberg,
Thanks for your quick reply.

I downloaded git 1.9.0 from the site 
https://code.google.com/p/git-core/downloads/list.
Does it mean the package available at above location has issue? OR
The person  who built/installed git in AIX sever did something wrong by 
building it against a specific OpenSSL library


Could you please suggest the site from where I need to download git for AIX OS.

Regards,
Ravi.

-Original Message-
From: Ronnie Sahlberg [mailto:sahlb...@google.com] 
Sent: Friday, August 01, 2014 3:58 PM
To: Ravi Kiran Goud Palpanoori
Cc: git@vger.kernel.org
Subject: Re: Git Help needed

This looks more like a packaging/build issue than a git issue.

It looks like whomever built your version of git built it against a specific 
version of the OpenSSL library.
You should probably contact the folks that built your binary and ask them to 
update and build against the version that the new version of aix ships with.

Alternatively if you build git yourself on that host you should end up with a 
binary that links with the version of the library that you currently have.



On Fri, Aug 1, 2014 at 12:30 PM,   wrote:
> Hi,
> I am writing below couple of questions. If it is not the right place to ask 
> please ignore and suggest me what to do to get the help on these questions.
>
> 1) What version of SSL is supported by GIT 1.8.3 or GIT 1.9.0
>
> 2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked fine and 
> able to extract code from git repository directly as well as from ant. 
> Everything went well.
> Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git commands 
> are not working. Basic help and version works fine as expected. When I try to 
> pull the code from git repository it give SSL library compatibility issue.
>
> The error is
> OpenSSL version mismatch. Built agains 1000105f, you have 10bf
> fatal: Could not read from remote repository
>
> In order to get rid of this, I upgraded git to 1.9.0 GIT. But still it didn't 
> work. The issue is still coming.
>
> git help, version works.
> When I tried directly pulling code using git pull command - didn't work.
> When I try to pull the code through the ant - didn't work
>
> The ant version is 1.8.0RC1
>
> AIX admin worked on this and provided below comments
>
> Comments form AIX system admin  (Pasted as it is) Even after 
> installing 1.9.0 version of GIT the library files are not compatible with the 
> latest version of SSL (1.0.5.1).
> SSL works fine as a root user and other users. This compatibility issue only 
> a raises when the LIBPATH for GIT is set and the SSL picks up its LIBPATH 
> from the same location as GIT and this causes the incompatibility.
> Can you find out from the GIT/ANT support team on what version of SSL GIT 
> supports exactly. - The is specifically with the GIT/SSL as the user "xyzabc" 
> . The SSL otherwise works perfectly fine.
> You will have to re-compile the ANT libraries to use the latest library files.
>
> Thanks in advance.
>
> Regards,
> Ravi.
> --
> 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
N�r��yb�X��ǧv�^�)޺{.n�+ا���ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf

RE: Git Help needed

[RaviKiranGoud_Palpanoori]

Hi brian,
Thanks for your quick reply.

I downloaded git 1.9.0 from the site 
https://code.google.com/p/git-core/downloads/list.
Does it mean the package available at above location has built with specific 
version of OpenSSL. How can I find out which OpenSSL version is used in the 
packages available at the above location.

Could you please suggest the site from where I need to download git for AIX OS.
Who are the vendors of git so that I will check how to proceed on this.

Regards,
Ravi.

-Original Message-
From: brian m. carlson [mailto:sand...@crustytoothpaste.net] 
Sent: Friday, August 01, 2014 4:05 PM
To: Ravi Kiran Goud Palpanoori
Cc: git@vger.kernel.org
Subject: Re: Git Help needed

On Fri, Aug 01, 2014 at 07:30:11PM +, ravikirangoud_palpano...@vfc.com 
wrote:
> Hi,
> I am writing below couple of questions. If it is not the right place 
> to ask please ignore and suggest me what to do to get the help on 
> these questions.
> 
> 1) What version of SSL is supported by GIT 1.8.3 or GIT 1.9.0

The INSTALL file doesn't mention a particular OpenSSL version that we require, 
but I know that it works with versions as old as 0.9.8 and as new as 1.0.1g.  
It may work with still older versions, but I recommend
1.0.1 or newer as it gives you proper TLS 1.2 support.

> 2) I have installed git 1.8.3 in AIX server 6.1 TL8 SP2. It worked 
> fine and able to extract code from git repository directly as well as 
> from ant. Everything went well.
> Recently Aix OS upgraded to 6100-09-01-1341. After OS upgrade my git 
> commands are not working. Basic help and version works fine as 
> expected. When I try to pull the code from git repository it give SSL 
> library compatibility issue.
> 
> The error is
> OpenSSL version mismatch. Built agains 1000105f, you have 10bf
> fatal: Could not read from remote repository

OpenSSL 1.0.0 (which you were using before) and OpenSSL 1.0.1 are binary 
compatible if compiled with the same flags, but they contain a hard version 
check that fails if they're not the same version.

This means you need to recompile git against the newer OpenSSL version, or ask 
your vendor to patch this check out.  This is true for any program that gives 
you this error.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Re: cherry picking and merge

[Jonathan Nieder]

Jonathan Nieder wrote:

> Do you mean that "git merge" should be aware of what changes you have
> already cherry-picked?
>
> It isn't, and that's deliberate

That said, when today's "git merge" fails to resolve conflicts, it's
easily possible that we could do better at resolving the merge by
walking through both sides and understanding what happened.

The detailed history lets you

   i) Present conflicts in an easier to resolve way.

  "Patch #1 which tries to do X conflicted with patch #2 which
  tries to do Y; please reconcile them" can be less painful to
  deal with than "Something in this pile conflicted with something
  in that pile".

  ii) Break a seeming conflict into pieces that can be automatically
  resolved more easily.

  X vs X'+Y may conflict where X' is a cherry-pick of X, if X and
  Y touch the same code.  Meanwhile if we're lucky then X vs X'
  will not conflict because they make the same change, and Y can
  apply on top.

 iii) Handle cherry-picked changes in a *different* way.  For example,
  if patch X was applied on one side and applied and then reverted
  on the other side, this could show up as a conflict.  After all,
  the two sides don't agree on whether patch X is a good change or
  not.

These features have corresponding downsides:

   i') (Speaking from experience of using git-imerge) Too many tiny
   conflicts can sometimes be more painful to resolve than all the
   conflicts at once.  When X, Y, Z, and W had various conflicts,
   how to reconcile X and Y alone or Z and W alone are academic
   questions that don't actually need to be answered to produce
   the merge result.

  ii') This kind of clean, broken-down merge can produce a "clean"
   but wrong result.

   For example, if the following sequence of events occured:

 1. Build fancy new feature X on "master".

 2. Cherry-pick X to the bugfixes-only branch "maint".
Whoops.
 3. Correct the mistake: revert X on "maint".  Now "maint"
is bugfixes-only again!

 4. Merge "maint" to "master".

   Then a naive, 3-way merge will notice there is no change
   on "maint" since it was last merged to master and the
   merge will bring in no change (good).

   And on the other hand a one-patch-at-a-time merge would
   try to apply X (with no effect, since it's already applied)
   and then try to apply the revert of X.  The net effect would
   be to revert X from "master" (bad)!

 iii') See (ii').

git-imerge from https://github.com/mhagger/git-imerge can help with
(i) and (ii) but not (iii).

Hoping that clarifies,
Jonathan
--
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

Re: cherry picking and merge

[Nico Williams]

On Fri, Aug 1, 2014 at 3:50 PM, Jonathan Nieder  wrote:
> Jonathan Nieder wrote:
>
>> Do you mean that "git merge" should be aware of what changes you have
>> already cherry-picked?
>>
>> It isn't, and that's deliberate
>
> That said, when today's "git merge" fails to resolve conflicts, it's
> easily possible that we could do better at resolving the merge by
> walking through both sides and understanding what happened.

It would help if cherry-pick history where recorded somewhere (beyond
the reflog)...

Cherry-picks should record two parents, like merges.

(Of course, it does no good to know about an unreachable parent, when
a commit with two parents is pushed to a repo that doesn't have one of
those parents, which can happen when topic branches aren't pushed
upstream.)

Nico
--
--
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

Re: Git Help needed

[brian m. carlson]

On Fri, Aug 01, 2014 at 08:27:24PM +, ravikirangoud_palpano...@vfc.com 
wrote:
> Hi brian,
> Thanks for your quick reply.
> 
> I downloaded git 1.9.0 from the site
> https://code.google.com/p/git-core/downloads/list.

That URL is obsolete.  Try https://www.kernel.org/pub/software/scm/git/
Google Code no longer allows anyone to upload tarballs.

> Does it mean the package available at above location has built with
> specific version of OpenSSL. How can I find out which OpenSSL version
> is used in the packages available at the above location.

If you're downloading the source tarball and building it yourself, then
it's whatever version of OpenSSL is on your system.  To my knowledge,
nobody provides pre-built packages of git for AIX.

> Could you please suggest the site from where I need to download git
> for AIX OS.

As I mentioned above, you'll probably need to build it yourself.

> Who are the vendors of git so that I will check how to proceed on this.

When I referred to having your vendor patch the check out, I meant your
vendor of OpenSSL.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

RE: Git Help needed

[RaviKiranGoud_Palpanoori]

Hi Brian,
Thank you.
Understood OpeSSL and vendor from your original message now.

Thanks,
Ravi.

-Original Message-
From: brian m. carlson [mailto:sand...@crustytoothpaste.net] 
Sent: Friday, August 01, 2014 5:00 PM
To: Ravi Kiran Goud Palpanoori
Cc: git@vger.kernel.org
Subject: Re: Git Help needed

On Fri, Aug 01, 2014 at 08:27:24PM +, ravikirangoud_palpano...@vfc.com 
wrote:
> Hi brian,
> Thanks for your quick reply.
> 
> I downloaded git 1.9.0 from the site
> https://code.google.com/p/git-core/downloads/list.

That URL is obsolete.  Try https://www.kernel.org/pub/software/scm/git/
Google Code no longer allows anyone to upload tarballs.

> Does it mean the package available at above location has built with 
> specific version of OpenSSL. How can I find out which OpenSSL version 
> is used in the packages available at the above location.

If you're downloading the source tarball and building it yourself, then it's 
whatever version of OpenSSL is on your system.  To my knowledge, nobody 
provides pre-built packages of git for AIX.

> Could you please suggest the site from where I need to download git 
> for AIX OS.

As I mentioned above, you'll probably need to build it yourself.

> Who are the vendors of git so that I will check how to proceed on this.

When I referred to having your vendor patch the check out, I meant your vendor 
of OpenSSL.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
--
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

Re: cherry picking and merge

[Junio C Hamano]

Nico Williams  writes:

> Cherry-picks should record two parents, like merges.

No.

It is OK to record where it came from, and we let you do so with the
"-x" option.

But the "where it came from" commit is very different from being
parent, which implies "all the history behind it".  The whole point
of a cherry-pick is that you do not want to grab the changes behind
the commit you are cherry-picking and you want the _change_ the
cherry-picked commit (and that commit alone) brings in.  It should
never record "two parents, like merges."

--
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

Re: cherry picking and merge

[Nico Williams]

On Fri, Aug 1, 2014 at 4:44 PM, Junio C Hamano  wrote:
> Nico Williams  writes:
>
>> Cherry-picks should record two parents, like merges.
>
> No.
>
> It is OK to record where it came from, and we let you do so with the
> "-x" option.
>
> But the "where it came from" commit is very different from being
> parent, which implies "all the history behind it".  The whole point
> of a cherry-pick is that you do not want to grab the changes behind
> the commit you are cherry-picking and you want the _change_ the
> cherry-picked commit (and that commit alone) brings in.  It should
> never record "two parents, like merges."

I didn't mean to imply all that.  s/parent/where it came from/, but -x
edits the commit message, not the metadata...

The point remains: to do what the OP wants git merge would have to be
able to notice that a given commit was cherry-picked from the other
branch, and what commit it was on that other branch, and right now the
only place where that information is available is in the reflog.
Recording that metadata somewhere in the commit resulting from the
cherry-pick would be better.

Nico
--
--
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

What's cooking in git.git (Aug 2014, #01; Fri, 1)

[Junio C Hamano]

Here are the topics that have been cooking.  Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.

First release candidate 2.1.0-rc1 expected early next week, after
merging a couple of obvious documentation update patches.

You can find the changes described here in the integration branches
of the repositories listed at

http://git-blame.blogspot.com/p/git-public-repositories.html

--
[Graduated to "master"]

* ep/avoid-test-a-o (2014-07-25) 1 commit
  (merged to 'next' on 2014-07-27 at 45de31d)
 + t9814: fix misconversion from test $a -o $b to test $a || test $b

 Fix a post v2.0 regression in 'master'.


* jk/more-push-completion (2014-07-22) 3 commits
  (merged to 'next' on 2014-07-28 at d1d4c27)
 + completion: complete `git push --force-with-lease=`
 + completion: add some missing options to `git push`
 + completion: complete "unstuck" `git push --recurse-submodules`


* sk/mingw-tests-workaround (2014-07-21) 6 commits
  (merged to 'next' on 2014-07-28 at 2f3b7ac)
 + t800[12]: work around MSys limitation
 + t9902: mingw-specific fix for gitfile link files
 + t4210: skip command-line encoding tests on mingw
 + MinGW: disable legacy encoding tests
 + t0110/MinGW: skip tests that pass arbitrary bytes on the command line
 + MinGW: Skip test redirecting to fd 4
 (this branch is used by jc/not-mingw-cygwin.)

 Make tests pass on msysgit by mostly disabling ones that are
 infeasible on that platform.


* sk/mingw-uni-fix-more (2014-07-21) 14 commits
  (merged to 'next' on 2014-07-28 at 0945196)
 + Win32: enable color output in Windows cmd.exe
 + Win32: patch Windows environment on startup
 + Win32: keep the environment sorted
 + Win32: use low-level memory allocation during initialization
 + Win32: reduce environment array reallocations
 + Win32: don't copy the environment twice when spawning child processes
 + Win32: factor out environment block creation
 + Win32: unify environment function names
 + Win32: unify environment case-sensitivity
 + Win32: fix environment memory leaks
 + Win32: Unicode environment (incoming)
 + Win32: Unicode environment (outgoing)
 + Revert "Windows: teach getenv to do a case-sensitive search"
 + tests: do not pass iso8859-1 encoded parameter

 Most of these are battle-tested in msysgit and are needed to
 complete what has been merged to 'master' already.

--
[New Topics]

* jk/stash-list-p (2014-07-30) 7 commits
 - SQUASH??? future-proof, log --cc should imply -p without being told
 - stash: show combined diff with "stash show"
 - stash: default listing to "--cc --simplify-combined-diff"
 - add --simplify-combined-diff option
 - pretty: make empty userformats truly empty
 - pretty: treat "--format=" as an empty userformat
 - revision: drop useless string offset when parsing "--pretty"

 Teach "git stash list -p" to DWIM to "git stash list -p --cc", with
 even nicer twist to collapse combined diff from identical two
 parents into a regular diff.


* pr/remotes-in-hashmap (2014-07-30) 1 commit
 - use a hashmap to make remotes faster

 Optimize remotes configuration look-up in a repository with very
 many remotes defined.


* rs/ref-transaction-multi (2014-07-31) 5 commits
 - refs.c: make the *_packed_refs functions static
 - refs.c: make repack_without_refs static
 - remote.c: use a transaction for deleting refs
 - refs.c: write updates to packed refs when a transaction has more than one ref
 - refs.c: move reflog updates into its own function
 (this branch uses rs/ref-transaction, rs/ref-transaction-1, 
rs/ref-transaction-reflog and rs/ref-transaction-rename.)

 Follow-up on rs/ref-transaction series to use the packed-ref to
 achieve atomicity when multiple refs are involved.


* rs/ref-transaction-rename (2014-07-31) 5 commits
 - refs.c: rollback the lockfile before we die() in repack_without_refs
 - refs.c: update rename_ref to use a transaction
 - refs.c: use packed refs when deleting refs during a transaction
 - refs.c: return error instead of dying when locking fails during transaction
 - refs.c: allow passing raw git_committer_info as email to _update_reflog
 (this branch is used by rs/ref-transaction-multi; uses rs/ref-transaction, 
rs/ref-transaction-1 and rs/ref-transaction-reflog.)

 Follow-up on rs/ref-transaction series to make renaming a ref
 transactional (i.e. "delete old and create new" should not leave
 an in-between state behind when it fails).


* ta/doc-config (2014-07-30) 1 commit
  (merged to 'next' on 2014-07-31 at ec577fa)
 + add documentation for writing config files

 Will merge to 'master'.


* tf/maint-doc-push (2014-07-31) 1 commit
  (merged to 'next' on 2014-07-31 at 6a8ef70)
 + git-push: fix link in man page

 Will merge to 'master' and later to 'maint'.


* nd/lock-paths-absolute (2014-08-01) 3 commits
 - lockfile.c: store absolute path
 - lockfile.c: remove PATH_MAX limit in resolve_symlink()
 

Re: cherry picking and merge

[Junio C Hamano]

Nico Williams  writes:

> branch, and what commit it was on that other branch, and right now the
> only place where that information is available is in the reflog.

... or the line in "-x".

We do not add random unstructured cruft in the commit object
header.  Check the list archive.
--
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

Re: cherry picking and merge

[Mike Stump]

On Aug 1, 2014, at 12:22 PM, Nico Williams  wrote:
> If you always rebase

I can’t use rebase unless you make rebase work with multiple users and pushing 
pulling.--
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

Re: cherry picking and merge

[Mike Stump]

On Aug 1, 2014, at 11:57 AM, Philip Oakley  wrote:
> But that goes both ways, and is a philosophical issue about what is to be 
> expected in various cases.

The problem is, users expect merge to merge.  There isn’t a user that expects 
it to scramble the source code, because the command is called merge, not 
scramble.  That word has semantics that were not invented by your project.  You 
cannot change the semantic of the word.  Merge has a nice mathematical 
definition.  Merge branch into master means, place into into master the work 
from that branch.  git already does this 99% correct, it is missing one corner 
case.

This is not a philosophical issue.  It is a definitional one.

> For some central control use styles, the ideas behind _distributed_ version 
> control are anathema and (Git) just grinds away at the policies that are 
> expected.

This is irrelevant to the issue at hand.

> That said, Git doesn't claim to be perfect

Again, irrelevant.

> (and can't because

Do you mean, and can’t be?  If so, you are wrong in the case at hand.  svn is 
an existence proof that you are wrong.

> of the 'relativity' that comes with being distributed - truth has to give way 
> to a web of trust). Also the artefacts that Git validates are at a different 
> level of abstraction i.e. the whole project as a commit, rather than just a 
> few/one file at a time.

Ah, so that gives me an idea.  [ pause ] If we try the cherry-pick as 
retroactively creating a feature branch, cherrying into that, then merge 
unconditionally so that no change happens that into trunk (thus killing those 
conflicts), and then git merge that feature branch into branch then it all 
works perfectly.  See, another existence proof that you are wrong, this time 
with git itself.

It was 13 lines of code, so, apparently, it is possible and easy to do, in git. 
 Now, we just want the cherry-pick to create a temporary cherry branch, cherry 
the pick into it, merge and drop into trunk and merge into branch…

I tested with the below and it worked just fine.  Things to clean up, we want 
the meta data on the cherry on the merge commit, but, you get the idea.

branch=b
master=master
base=$(git merge-base $branch $master)
cherry="$1"

git checkout -b cherry-$branch $base
git cherry-pick "$cherry"
git checkout $master
git merge -s ours cherry-$branch
git checkout $branch
git merge cherry-$branch
git branch -d cherry-$branch
git cherry-pick --strategy=ours --allow-empty "$cherry"
git commit --allow-empty

I tested that with two cherries with further changes on master to ensure that 
it works for more than a single one, no problem.  Wow, even tried a merge of 
master back into b, and it worked just fine, no conflicts, yet, all the code 
was jammed up together nicely.

So, if you wish to continue your position, please explain why it can’t get this 
better, given the existence proof above of it working better in git.

> In your example (when generalized)

I’m not interested in other bugs that I didn’t state, in this email.  I don’t 
care about those.  Please don’t detract from fixing this issue, because you can 
identify other things that might not be perfect.  We attain perfection one step 
at a time.

> the problem is deciding when, in the change sequence, the cherry pick is to 
> be backed out, especially if there are conflicts in the change sequence that 
> would need fixing anyway, and in a long change sequence that would be a lot 
> of conflict fix-ups, hence the current choice of getting the merge conflicts 
> all resolved in the one go.

I have two possible conflict fixups in the above.  In my case (I have a 
specific patch in gcc-land i wanted to cherry), those fixups were trivial (no 
conflicts).  When they are trivial, I don’t care much that there were two of 
them.  When non-trivial, well, I’m resigned to the idea that I have to explain 
what is going on.

> Selecting a compatible workflow is a problem of usage,

Not when the workflow is mandated on you to work around trivial little bugs 
that can be fixed but for which the author’s don't even comprehend the bug.

> rather than a problem in Git.
--
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

Re: cherry picking and merge

[Nico Williams]

On Fri, Aug 1, 2014 at 5:13 PM, Mike Stump  wrote:
> On Aug 1, 2014, at 12:22 PM, Nico Williams  wrote:
>> If you always rebase
>
> I can’t use rebase unless you make rebase work with multiple users and 
> pushing pulling.

That works now, and I do it all the time.  Have a single repo ("the
truth"), always rebase local commits on top of the latest upstream,
always do fast-forward pushes.  Done.
--
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

Re: cherry picking and merge

[Mike Stump]

On Aug 1, 2014, at 12:01 PM, Jakub Narębski  wrote:
> It can work in Subversion because Subversion stores information about
> what was merged in (and this includes cherry-picks, or whatever it is
> named in svn) in svn:mergeinfo property. Git does not track what was
> merged in, instead it represent the history as the graph of revisions,
> and tracks merges (by storing that it came from two or more commits)
> and not merged-in information.

So, as a dumb user that just wants it to work, I am unsympathetic to the `but 
software is hard’ excuse.  I am aware that some bugs are harder to fix than 
others.  svn took a long time to fix this bug, but they did.  I can wait, the 
only question is, will it be a week, a month, a year, or a decade.

> When merging Git uses only what is being merged and its common
> ancestor (3-point merge). It is simple, and simple works!!!

I gave a solution for git using branches and it works just fine.  It retains 
the simple 3-point merge as well.

> Unfortunately, it does not see cherry-picked commits - it is invisible
> to merge as being on the chain from one of merged commits to the
> common ancestor.

Im the solution that I sketched in my previous email, that information is then 
exposed so that the right merge happens.

> The rebase command handles

I can’t use rebase as it is unfriendly to coworkers.

> cherry-picked commits by detecting that the
> change was already applied. I think that git-imerge does the same (but
> I have not used it myself).
> 
> Have you tried git-imerge?

No, not yet.  I’m not as interested in using it, as I would like git itself to 
just work.--
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

Re: [PATCH] doc: format-patch: don't use origin as a branch name

[Philip Oakley]

From: "Junio C Hamano" 

Jonathan Nieder  writes:


Philip Oakley wrote:

Historically (5 Nov 2005 v0.99.9-46-g28ffb89) the git-format-patch 
used
'origin' as the upstream branch name. This is now used to name the 
remote.

Use the more modern 'master' as the branch name.


Would 'origin/master' make sense?


It would make a lot more sense than 'master', I think.

The 'origin' will be DWIMmed to whatever the remote designated as


I'd rather not provide an example that requires extra understanding on 
behalf of the reader on the DWIMing, especially as the example doesn't 
actually match the guidance in gitrevisions(7) [2].


The synopsis says it should either be a single commit , or a 
, the latter specified via gitrevisions(7), so theirs 
already an opportunity for confusion, but I take your point.



its primary branch, i.e. refs/remotes/origin/HEAD, and the
assumption the examples in question makes is that the user is
following along the simplest workflow to fork from it and upstream
her changes.  Between 'origin' and 'origin/master', there isn't much
difference because of it.  In the same spirit of following the
simplest workflow, that primary branch is likely to be their
'master', so 'origin/master' is OK but longer than 'origin' [*1*].


which suggests that maybe the example text should clarify any assumprion 
like that..


On the other hand, 'master' names the local 'master', which may be
very stale with respect to 'origin/master', or may have tons of
unrelated things that are not in origin/master, some of which may
have come from the branch the user is running format-patch to grab
patches to upstream.  For this reason, changing 'origin' to 'master'
is not an improvement at all, I would have to say.


I didn't see it that way, my view (presumption?) of the workflow was 
that the user had a branch 'current' which they had branched from their 
'master', thus the updated command felt natural.


We could further adjust the underlying assumption to more modern
"checkout -t -b" era, and use "format-patch @{u}", but I suspect
that the readers of these examples are not yet ready for magic
before the basics to spell out things more explicitly is covered.


agreed




[Footnote]

*1* Also using 'origin' will cover the case when the primary branch
at the remote were not named 'master', so in that sense it is
slightly better and more generally applicable.


--
Philip
[2] the DWIMs listed in the  example of gitrevisions(7), to the 
niave reader, needs to be ref/ prefixed, which isn't what we'd hope 
(assuming they ever read it ;-). 


--
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

Re: [PATCH v3 2/2] imap-send: create target mailbox if it is missing

[Junio C Hamano]

Tony Finch  writes:

> Some MUAs delete their "drafts" folder when it is empty, so
> git imap-send should be able to create it if necessary.

Thanks for an update; queued.
--
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

Re: cherry picking and merge

[Mike Stump]

On Aug 1, 2014, at 1:02 PM, Jonathan Nieder  wrote:
> 
> Do you mean that "git merge" should be aware of what changes you have
> already cherry-picked?

Yes, it amounts to that.

> It isn't, and that's deliberate

Deliberate bugs are still bugs.  In time, users will either wear you down until 
you fix it, or they will move on to other systems that work better.

> ("git merge" is designed to be simple as possible, though no more simple than 
> that).

I sketched a solution that retains a simple git merge…

> This way, if on a side branch someone makes a change that would conflict with 
> "master" and
> then backs it out, then the branch can still merge cleanly.

Yeah, my solution doesn’t impinge upon that working nicely.  In it, I make 
cherry use scratch branches to record meta information so that the existing git 
merge just works.  git cherry is free to do the same.  Having a git cherry that 
fully interoperates with git merge, is a feature.

> Even in those workflows, it's possible to have conflicts due to

> genuinely conflicting changes, even with no cherry-pick involved.  I
> find the '[merge] conflictstyle = diff3' setting (see git-config(1))
> and git-rerere(1) to be helpful in making that less painful.

I think those two should be the default, but it is easy enough to turn them on 
that it doesn’t matter much.  In my environment, I have both on.--
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

Re: struct hashmap_entry packing

[Jeff King]

On Tue, Jul 29, 2014 at 10:40:12PM +0200, Karsten Blees wrote:

> > The sizeof() has to be the same regardless of whether the hashmap_entry
> > is standalone or in another struct, and therefore must be padded up to
> > 16 bytes. If we stored "x" in that padding in the combined struct, it
> > would be overwritten by our memset.
> > 
> 
> The struct-packing patch was ultimately dropped because there was no way
> to reliably make it work on all platforms. See [1] for discussion, [2] for
> the final, 'most compatible' version.

Thanks for the pointers; I should have guessed there was more to it and
searched the archive myself.

> Hmmm. Now that we have "__attribute__((packed))" in pack-bitmap.h, perhaps
> we should do the same for stuct hashmap_entry? (Which was the original
> proposal anyway...). Only works for GCC, but that should cover most builds
> / platforms.

I don't see any reason to avoid the packed attribute, if it helps us. As
you noted, anything using __attribute__ probably supports it, and if
not, we can conditionally #define PACKED_STRUCT or something, like we do
for NORETURN. Since it's purely an optimization, if another compiler
doesn't use it, no big deal.

That being said, I don't know if those padding bytes are actually
causing a measurable slowdown. It may not even be worth the trouble.

> Btw.: Using struct-packing on 'struct bitmap_disk_entry' means that the
> binary format of .bitmap files is incompatible between GCC and other
> builds, correct?

The on-disk format is defined by JGit; if there are differences between
the builds, that's a bug (and I would not be too surprised if there is
one, as bitmaps have gotten very extensive testing on 32- and 64-bit
gcc, but probably not much elsewhere).

We do use structs to represent disk structures in other bits of the
packfile code (e.g., struct pack_idx_header), but the struct is vanilla
enough that we assume every compiler gives us two tightly-packed 32-bit
integers without having to bother with the "packed" attribute (and it
seems to have worked in practice).

We should probably be more careful with that bitmap code. It looks like
it wouldn't be too bad to drop it. I'll see if I can come up with a
patch.

-Peff
--
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

Re: cherry picking and merge

[Jonathan Nieder]

Mike Stump wrote:
> On Aug 1, 2014, at 1:02 PM, Jonathan Nieder  wrote:

>> It isn't, and that's deliberate
>
> Deliberate bugs are still bugs.

Yes, you and I disagree about what the behavior should be.

I actively prefer the current behavior over the one you proposed,
unless I'm misunderstanding the one you proposed.  As I understand it,
there would be no way to undo the mistake of cherry-picking a change
that didn't belong on "maint".

You said that 3-way merge doesn't fit your idea of what a merge is.
It does fit mine.

I'm even slightly against there being an option for the 'git cherry'
based thing.  I think it would be a support burden.  But if someone
else wants to do the work of implementing it, I wouldn't stop them
(and would instead just help make sure the documentation is crystal
clear).

Hoping that clarifies,
Jonathan
--
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

Re: cherry picking and merge

[Mike Stump]

On Aug 1, 2014, at 1:12 PM, Sam Vilain  wrote:
> Git merge has a notion of discrete "merge strategies”.

> There's no particular reason that you couldn't implement a merge
> strategy which works more like SVN's approach, which essentially does an
> internal rebase and then commits the result.

Well, being a simple user, wanting to do a simple thing, I want the default 
strategy to just work.  The expert that wants it to work faster, but less well, 
well, they can use a merge -s faster, or cherry-pick -s faster.

> However, there are corresponding disadvantages to this strategy.  It's
> just as easy to contrive a situation where this "internal rebasing"
> doesn't do the right thing, even without cheating by getting the
> metadata wrong.

I sketched a solution using branches…  A large portion of the failures that 
happen when a cherry is remerged are gone.  I feel that benefit easily swamps 
the problem you sketched.

> And besides, there's already a way to do this: do an actual rebase.

One problem is that rebase doesn’t work with co-workers nicely…  The other is 
that it isn’t spelled merge.  I am a simple user.

>> I was curious if svn handles this better the same or worse, and it did it 
>> just fine.  I know that a while ago, svn could not handle this, it would do 
>> what git does currently.  Apparently they figured out it was a bug and fixed 
>> it.  Have you guys figured out it is a bug yet?  The first step in solving a 
>> problem, is admitting you have a problem.
> 
> So, I have to chuckle when I read this indignant comment.

:-)  Yeah, a chuckle, good.  Actually, no anger is involved.  I’d just like for 
git to work better in this regard.--
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

[PATCH] pack-bitmap: do not use gcc packed attribute

[Jeff King]

On Fri, Aug 01, 2014 at 06:37:39PM -0400, Jeff King wrote:

> > Btw.: Using struct-packing on 'struct bitmap_disk_entry' means that the
> > binary format of .bitmap files is incompatible between GCC and other
> > builds, correct?
> 
> The on-disk format is defined by JGit; if there are differences between
> the builds, that's a bug (and I would not be too surprised if there is
> one, as bitmaps have gotten very extensive testing on 32- and 64-bit
> gcc, but probably not much elsewhere).
> 
> We do use structs to represent disk structures in other bits of the
> packfile code (e.g., struct pack_idx_header), but the struct is vanilla
> enough that we assume every compiler gives us two tightly-packed 32-bit
> integers without having to bother with the "packed" attribute (and it
> seems to have worked in practice).
> 
> We should probably be more careful with that bitmap code. It looks like
> it wouldn't be too bad to drop it. I'll see if I can come up with a
> patch.

I confirmed that this does break horribly without the packed attribute
(as you'd expect; it's asking for 48-bit alignment!). p5310 notices it,
_if_ you have jgit installed to check against.

Here's a fix.

-- >8 --
Subject: pack-bitmap: do not use gcc packed attribute

The "__attribute__" flag may be a noop on some compilers.
That's OK as long as the code is correct without the
attribute, but in this case it is not. We would typically
end up with a struct that is 2 bytes too long due to struct
padding, breaking both reading and writing of bitmaps.

We can work around this by using an array of unsigned char
to represent the data, and relying on get/put_be32 to handle
alignment issues as we interact with the array.

Signed-off-by: Jeff King 
---
The accessors may be overkill; each function is called only a single
time in the whole codebase. But doing it this way rather than accessing
entry[4] inline at least puts the magic constants all in one place.

 pack-bitmap-write.c | 10 --
 pack-bitmap.c   | 12 ++--
 pack-bitmap.h   | 42 +-
 3 files changed, 47 insertions(+), 17 deletions(-)

diff --git a/pack-bitmap-write.c b/pack-bitmap-write.c
index 5f1791a..f885a7a 100644
--- a/pack-bitmap-write.c
+++ b/pack-bitmap-write.c
@@ -473,7 +473,7 @@ static void write_selected_commits_v1(struct sha1file *f,
 
for (i = 0; i < writer.selected_nr; ++i) {
struct bitmapped_commit *stored = &writer.selected[i];
-   struct bitmap_disk_entry on_disk;
+   unsigned char on_disk[BITMAP_DISK_ENTRY_LEN];
 
int commit_pos =
sha1_pos(stored->commit->object.sha1, index, index_nr, 
sha1_access);
@@ -481,11 +481,9 @@ static void write_selected_commits_v1(struct sha1file *f,
if (commit_pos < 0)
die("BUG: trying to write commit not in index");
 
-   on_disk.object_pos = htonl(commit_pos);
-   on_disk.xor_offset = stored->xor_offset;
-   on_disk.flags = stored->flags;
-
-   sha1write(f, &on_disk, sizeof(on_disk));
+   bitmap_disk_entry_create(on_disk, commit_pos,
+stored->xor_offset, stored->flags);
+   sha1write(f, on_disk, sizeof(on_disk));
dump_bitmap(f, stored->write_as);
}
 }
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 91e4101..1b2a473 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -203,7 +203,7 @@ static int load_bitmap_entries_v1(struct bitmap_index 
*index)
 
uint32_t i;
struct stored_bitmap **recent_bitmaps;
-   struct bitmap_disk_entry *entry;
+   unsigned char *entry;
 
recent_bitmaps = xcalloc(MAX_XOR_OFFSET, sizeof(struct stored_bitmap));
 
@@ -214,14 +214,14 @@ static int load_bitmap_entries_v1(struct bitmap_index 
*index)
uint32_t commit_idx_pos;
const unsigned char *sha1;
 
-   entry = (struct bitmap_disk_entry *)(index->map + 
index->map_pos);
-   index->map_pos += sizeof(struct bitmap_disk_entry);
+   entry = index->map + index->map_pos;
+   index->map_pos += BITMAP_DISK_ENTRY_LEN;
 
-   commit_idx_pos = ntohl(entry->object_pos);
+   commit_idx_pos = bitmap_disk_entry_object_pos(entry);
sha1 = nth_packed_object_sha1(index->pack, commit_idx_pos);
 
-   xor_offset = (int)entry->xor_offset;
-   flags = (int)entry->flags;
+   xor_offset = (int)bitmap_disk_entry_xor_offset(entry);
+   flags = (int)bitmap_disk_entry_flags(entry);
 
bitmap = read_bitmap_1(index);
if (!bitmap)
diff --git a/pack-bitmap.h b/pack-bitmap.h
index 8b7f4e9..0d57706 100644
--- a/pack-bitmap.h
+++ b/pack-bitmap.h
@@ -5,11 +5,43 @@
 #include "khash.h"
 #include "pack-objects.h"
 
-struct bitmap_disk_entry {
-   uint32_t object_pos;
- 

Re: [PATCH] pack-bitmap: do not use gcc packed attribute

[Jeff King]

On Fri, Aug 01, 2014 at 07:10:44PM -0400, Jeff King wrote:

> I confirmed that this does break horribly without the packed attribute
> (as you'd expect; it's asking for 48-bit alignment!). p5310 notices it,
> _if_ you have jgit installed to check against.

Er, that should be t5310, of course. p5310 is the perf test, which does
not notice the problem. :)

-Peff
--
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

Re: cherry picking and merge

[Nico Williams]

On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump  wrote:
> On Aug 1, 2014, at 1:12 PM, Sam Vilain  wrote:
>> Git merge has a notion of discrete "merge strategies”.
>
>> There's no particular reason that you couldn't implement a merge
>> strategy which works more like SVN's approach, which essentially does an
>> internal rebase and then commits the result.
>
> Well, being a simple user, wanting to do a simple thing, I want the default 
> strategy to just work.  [...]

Different users want different defaults.  You can't always have the
one you want.

As for rebase, I still don't understand why it doesn't work for you.
You didn't really explain.  Suppose we're right and it's the right
solution for you, then you might be ecstatic, but you gotta try it
first.

My workflow is rebase-heavy.  It's long been so, and it was so before
git happened.  The only case where I can imagine not using a
rebase-heavy workflow is where I have to track multiple forked
upstreams and so I want to merge each into my branch.

If tracking multiple forked upstreams is not your case and yet rebase
can't work for you then I'd like to understand why.  Please help me
understand your use case.  OTOH, if your use case is amenable to
rebase, then I highly recommend that you try it.

(I find that many users are allergic to rebasing.  Many people have
told me that rebase is lying, that history must be immutable, and so
on, all ignoring that: git users don't rebase published branches, and
that other VCSes tend to squash (therefore lose) history anyways when
pushing merges upstream.  But this all seems theological rather than
rational.  It's true that I dislike merge commits, but that's a
different story; I'm not allergic to merging after all.)

Nico
--
--
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

Re: cherry picking and merge

[Mike Stump]

On Aug 1, 2014, at 1:50 PM, Jonathan Nieder  wrote:
> 
>   And on the other hand a one-patch-at-a-time merge would
>   try to apply X (with no effect, since it's already applied)
>   and then try to apply the revert of X.  The net effect would
>   be to revert X from "master" (bad)!

Yeah, I appreciate that.  I know the type of user that would do that, and I 
understand why you would want to do that and even do that by default.

However, as an expert user, I don’t need that particular type of hand holding 
given the cost of more conflicts and would like an option to let me to choose 
to have fewer conflicts when merging.--
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

Re: [PATCH v1 03/19] rebase -i: reword executes pre-commit hook on interim commit

[Jeff King]

On Tue, Jul 29, 2014 at 01:18:03AM +0200, Fabian Ruch wrote:

> Specify the git-commit option `--no-verify` to disable the pre-commit
> hook when editing the log message. Because `--no-verify` also skips
> the commit-msg hook, execute the hook from within
> git-rebase--interactive after the commit is created. Fortunately, the
> commit message is still available in `$GIT_DIR/COMMIT_EDITMSG` after
> git-commit terminates. Caveat: In case the commit-msg hook finds the
> new log message ill-formatted, the user is only notified of the
> failed commit-msg hook but the log message is used for the commit
> anyway. git-commit ought to offer more fine-grained control over
> which hooks are executed.

Thanks for a nice explanation of the tradeoff. Have you looked at adding
an option to git-commit? We already have --no-post-rewrite. I think you
would just need:

diff --git a/builtin/commit.c b/builtin/commit.c
index 5ed6036..f7af220 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -102,6 +102,7 @@ static int quiet, verbose, no_verify, allow_empty, dry_run, 
renew_authorship;
 static int no_post_rewrite, allow_empty_message;
 static char *untracked_files_arg, *force_date, *ignore_submodule_arg;
 static char *sign_commit;
+static int no_pre_commit;
 
 /*
  * The default commit message cleanup mode will remove the lines
@@ -661,7 +662,8 @@ static int prepare_to_commit(const char *index_file, const 
char *prefix,
/* This checks and barfs if author is badly specified */
determine_author_info(author_ident);
 
-   if (!no_verify && run_commit_hook(use_editor, index_file, "pre-commit", 
NULL))
+   if (!no_verify && !no_pre_commit &&
+   run_commit_hook(use_editor, index_file, "pre-commit", NULL))
return 0;
 
if (squash_message) {
@@ -1604,6 +1606,7 @@ int cmd_commit(int argc, const char **argv, const char 
*prefix)
 N_("terminate entries with NUL")),
OPT_BOOL(0, "amend", &amend, N_("amend previous commit")),
OPT_BOOL(0, "no-post-rewrite", &no_post_rewrite, N_("bypass 
post-rewrite hook")),
+   OPT_BOOL(0, "no-pre-commit", &no_pre_commit, N_("bypass 
pre-commit hook")),
{ OPTION_STRING, 'u', "untracked-files", &untracked_files_arg, 
N_("mode"), N_("show untracked files, optional modes: all, normal, no. 
(Default: all)"), PARSE_OPT_OPTARG, NULL, (intptr_t)"all" },
/* end commit contents options */
 

though I would also not be opposed to some more uniform hook selection
mechanism (e.g., "--no-verify=pre-commit" or something).

-Peff
--
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

Re: [PATCH v1 07/19] rebase -i: log the replay of root commits

[Jeff King]

On Tue, Jul 29, 2014 at 01:18:07AM +0200, Fabian Ruch wrote:

> The command line used to recreate root commits specifies the option
> `-q` which suppresses the commit summary message. However,
> git-rebase--interactive tends to tell the user about the commits it
> creates in the final history, if she wishes (cf. command line option
> `--verbose`). The code parts handling non-root commits and squash
> commits all output commit summary messages. Do not make the replay of
> root commits an exception. Remove the option to make the report of
> the rebased history complete.
> 
> It is OK that the commit summary is still suppressed when git-commit
> is used to initialize the authorship of the sentinel commit because
> this additional commit is an implementation detail hidden from the
> final history. The removed `-q` option was probably introduced as a
> copy-and-paste error stemming from that part of the root commit
> handling code.

I'm confused. This implies that we should be seeing summaries for other
commits, but not root commits, and this patch is bring them into
harmony.  But if I have a repo like this:

  git init -q repo &&
  cd repo &&
  for i in one two; do
echo $i >file &&
git add file &&
git commit -q -m $i
  done

then using stock git gives me this:

  $ GIT_EDITOR=true git rebase -i --root 2>&1 | perl -pe 's/\r/\\r\n/g'
  Rebasing (1/2)\r
  Rebasing (2/2)\r
  Successfully rebased and updated refs/heads/master.

but with your patch, I get:

  $ GIT_EDITOR=true git.compile rebase -i --root 2>&1 | perl -pe 's/\r/\\r\n/g'
  Rebasing (1/2)\r
  [detached HEAD 60834b3] one
   Date: Fri Aug 1 20:00:05 2014 -0400
   1 file changed, 1 insertion(+)
   create mode 100644 file
  Rebasing (2/2)\r
  Successfully rebased and updated refs/heads/master.

Am I misunderstanding the purpose of the patch?

-Peff
--
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

Re: [PATCH v1 08/19] rebase -i: root commits are replayed with an unnecessary option

[Jeff King]

On Tue, Jul 29, 2014 at 01:18:08AM +0200, Fabian Ruch wrote:

> The command line used to recreate root commits specifies the
> effectless option `-C`. It makes git-commit reuse commit message and
> authorship of the named commit. However, the commit being amended
> here, which is the sentinel commit, already carries the authorship
> and log message of the commit being replayed. Remove the option.
> 
> Since `-C` (in contrast to `-c`) does not invoke the editor and the
> `--amend` option invokes it by default, disable editor invocation
> again by specifying `--no-edit`.

I found this description a little backwards. The "-C" does have an
effect, as you noticed in the second paragraph.

I think the reasoning is more like:

  The command line used to recreate root commits uses "-C" to
  suppress the commit editor. This is unnecessarily confusing,
  though, because that suppression is a secondary effect of the
  option. The main purpose of "-C" is to pull the metadata from
  another commit, but here we know that this is a noop, since we
  are amending a commit just created from the same data.

  At the time, commit did not yet know "--no-edit", and this was a
  reasonable way to get the desired behavior. We can switch it to
  use "--no-edit" to make the intended effect more obvious.

-Peff
--
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

Re: [PATCH v1 09/19] rebase -i: commit only once when rewriting picks

[Jeff King]

On Tue, Jul 29, 2014 at 01:18:09AM +0200, Fabian Ruch wrote:

> The options passed to `do_pick` determine whether the picked commit
> will be rewritten or not. If the commit gets rewritten, because the
> user requested to edit the commit message for instance, let
> `pick_one` merely apply the changes introduced by the commit and do
> not commit the resulting tree yet. If the commit is replayed as is,
> leave it to `pick_one` to recreate the commit (possibly by
> fast-forwarding the head). This makes it easier to combine git-commit
> options like `--edit` and `--amend` in `do_pick` because
> git-cherry-pick does not support `--amend`.
> 
> In the case of `--edit`, do not `exit_with_patch` but assign
> `rewrite` to pick the changes with `-n`. If the pick conflicts, no
> commit is created which we would have to amend when continuing the
> rebase. To complete the pick after the conflicts are resolved the
> user just resumes with `git rebase --continue`.

Hmm. So does this mean the user will actually see a different state
during such a conflict?

E.g., if I have instructions like:

  pick A
  squash B
  squash C

and there is a conflict picking C, then what state do I see? Right now I
see a commit with the A+B squash prepared. But your description sounds
to me like we would avoid the squash for "B", and the user would see a
different state.

However, I couldn't trigger that behavior in a few experiments. Am I
misunderstanding, or is there some case where the user-visible state
will be different?

-Peff
--
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

Re: cherry picking and merge

[Alex Davidson]

On Fri, 2014-08-01 at 18:40 -0500, Nico Williams wrote:
> On Fri, Aug 1, 2014 at 6:06 PM, Mike Stump  wrote:
> > On Aug 1, 2014, at 1:12 PM, Sam Vilain  wrote:
> >> Git merge has a notion of discrete "merge strategies”.
> >
> >> There's no particular reason that you couldn't implement a merge
> >> strategy which works more like SVN's approach, which essentially does an
> >> internal rebase and then commits the result.
> >
> > Well, being a simple user, wanting to do a simple thing, I want the default 
> > strategy to just work.  [...]
> 
> Different users want different defaults.  You can't always have the
> one you want.

Or to put it another way: one man's bug is another man's feature.

> 
> As for rebase, I still don't understand why it doesn't work for you.
> You didn't really explain.  Suppose we're right and it's the right
> solution for you, then you might be ecstatic, but you gotta try it
> first.
> ...
> Nico
> --

Data point:

We've been using a rebase-centric workflow for a while at my current
employer. It's simple and generally straightforward for new development
on master.

However we need to maintain multiple 'released' version branches which
receive hotfixes and (sadly) features from later development, and merges
make it much easier to visualise which releases have received specific
fixes/shinies than cherry-picks do.

In a hybrid merge/rebase workflow it is convenient to have the option of
merges which yield rebase-like output. We have seen awkward merges
outside of master, but I mostly see that as an indication that we
shouldn't be mixing workflows so much, ie. hotfixing one thing with a
cherry-pick and another with a merge (usually only happens when the
branch predates our use of merges).

TL;DR: The option of a rebase-like merge would be a nice feature, but
the default system does not seem so onerous.

Alex

--
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