Re: cherry picking and merge

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

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

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 chang

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

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 commi

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

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 s

Re: cherry picking and merge

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

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

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

Re: cherry picking and merge

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 doe

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

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

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

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

Re: cherry picking and merge

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

Re: cherry picking and merge

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

Re: struct hashmap_entry packing

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

Re: cherry picking and merge

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

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

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 ma

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

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

Re: cherry picking and merge

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 represen

Re: cherry picking and merge

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

Re: cherry picking and merge

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

Re: cherry picking and merge

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 i

Re: cherry picking and merge

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 unsubscr

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

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 ch

Re: cherry picking and merge

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 be

Re: cherry picking and merge

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 poin

RE: Git Help needed

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 He

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

Re: cherry picking and merge

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

Re: cherry picking and merge

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 walkin

RE: Git Help needed

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 availa

RE: Git Help needed

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

Re: cherry picking and merge

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

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

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 w

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.

Re: cherry picking and merge

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,

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

Git Help needed

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 a

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

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

cherry picking and merge

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

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

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

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

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'

Re: Bug report about symlinks

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 b

Fwd: cherry picking and merge

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

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

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

Re: cherry picking and merge

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 f

Re: Show containing branches in log?

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

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

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

Cross compiling git for ARM

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"

Re: cherry picking and merge

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

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

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_fi

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

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

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

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 inserti

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

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,

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

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

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

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

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

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,

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

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

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

[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

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

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_c

Re: cherry picking and merge

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 pet

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

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

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

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

Re: cherry picking and merge

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

Re: Bug report about symlinks

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

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

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 chang

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

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

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

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"); >

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

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

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

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,

Test

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

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

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 se

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

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