Fail git pull --rebase when local merges present? (was: [ANNOUNCE] Git v2.11.1)

[Stephen Bash]

On Thu, Feb 2, 2017 at 6:05 PM, Junio C Hamano  wrote:

>  * "git pull --rebase", when there is no new commits on our side since
>we forked from the upstream, should be able to fast-forward without
>invoking "git rebase", but it didn't.

As someone who has to mentor new developers to Git at my $dayjob, this
is really nice!  Thanks!

Slightly related (in that it's a pitfall of *always* using pull
--rebase), does anyone know if there is a way to make git pull
--rebase fail if there's a local merge?  For our workflow I'd like to
tell new people to just default to pull --rebase, but having to add
(and explain) the "don't rebase a merge" caveat tends to lose them...
(yes we mix merge and rebase; it works for us... most of the time)

Thanks,
Stephen

Re: can't install on OS X

[Stephen Bash]

- Original Message -
> From: "Spencer Graves" 
> Sent: Friday, October 2, 2015 2:50:30 AM
> Subject: can't install on OS X
>
> I downloaded "git-2.5.3-intel-universal-mavericks.dmg" per
> instructions.  When I tried to install it, I first had trouble because
> it wasn't from the Mac App Store nor an "identified developer".

You can also right click on the installer and select "Open" for a very similar 
dialog, but one that gives you the opportunity to run the installer anyway.

> "README.txt" says I need "sudo mv /usr/bin/git /usr/bin/git-system".  I
> tried that and got, "mv: rename /usr/bin/git to /usr/bin/git-system:
> Operation not permitted" (after entering my password).  [My directory
> now includes "/usr/local/git", and "/usr/bin" includes git,
> git-cvsserver, git-receive-pack, git-shell, git-upload-archive, and
> git-upload-pack.]
> 
> Suggestions?

Sounds like you're running afoul of El Capitan's new System Integrity 
Protection (SIP) [1].  The git commands you're seeing there are probably 
Apple's thin wrappers that are mostly meant to provide instructions on 
installing XCode, but SIP is stopping you from modifying the /usr directory 
(ah, Apple's Infinite Wisdom).  There are discussions about working around SIP 
in the Apple forums [2] and Homebrew has some hints as well [3].

[1] 
https://developer.apple.com/library/prerelease/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_11.html
[2] https://forums.developer.apple.com/thread/3981
[3] 
https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md#if-usrlocal-does-not-exist

HTH,
Stephen
--
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: can we prevent reflog deletion when branch is deleted?

[Stephen Bash]

- Original Message -
 From: Jeff King p...@peff.net
 Sent: Thursday, November 14, 2013 3:14:56 AM
 Subject: Re: can we prevent reflog deletion when branch is deleted?
 
 On Thu, Nov 14, 2013 at 05:48:50AM +0530, Sitaram Chamarty wrote:
 
  Is there *any* way we can preserve a reflog for a deleted branch,
  perhaps under logs/refs/deleted/timestamp/full/ref/name ?
 
 At GitHub, we log each change to an audit log in addition to the
 regular reflog (we also stuff extra data from the environment into the
 reflog message). So even after a branch is deleted, its audit log
 entries remain, though you have to pull out the data by hand (git
 doesn't know about it at all, except as an append-only sink for
 writing). 

We recently ran into a similar situation at my $dayjob, so I made our
server side update hook log all pushes (including deletes) and added the
new log file to logrotate(8) -- note: make sure if logrotate recreates
the file that it allows everyone to write to it.  I'm sure it's not as
comprehensive as Peff's solution, but it's pretty simple for smaller
shops that want a little more protection.  Here are the relevant
excerpts from the script:

#!/usr/bin/env python

import os, sys, pwd, stat
from datetime import datetime

def log_push(too_many_changes):
log_file = 'push-log.txt'
try:
f = open(log_file, 'a')

try:
# In case we just created the file, attempt to chmod it
os.chmod(log_file, 0666)
except OSError:
# chmod will fail if the current user isn't the owner, but
# if we've gotten this far we already have write permissions,
# so just continue quietly
pass

# Linux/Mac okay, bad for Windows
username = pwd.getpwuid(os.getuid())[0]
f.write('%s: %s push by %s of %s from %s to %s\n'% \
(datetime.now().strftime('%Y-%m-%d %H:%M:%S'),
'Failed' if too_many_changes else 'Successful', username,
refname, oldsha, newsha))
f.close()
except IOError:
try:
log_stats = os.stat(log_file)
# Figure out owner and permissions
log_owner = pwd.getpwuid(log_stats.st_uid).pw_name
log_perm = oct(stat.S_IMODE(log_stats.st_mode))
print_flush('Unable to open %s for appending. Current owner ' + \
'is %s and permissions are %s.'%(log_file,
log_owner, log_perm))
except:
exception,desc,stack = sys.exc_info()
print_flush('Unable to open log file.  While generating error' + \
' message encountered error: %s'%(desc))

if len(sys.argv) != 4:
print_flush('Usage: %s refname oldsha newsha'%sys.argv[0])
sys.exit(1)

refname = sys.argv[1]
oldsha = sys.argv[2]
newsha = sys.argv[3]

if newsha == '0'*40:
# Deleted ref, nothing to do
log_push(False)
sys.exit(0)

# ... checking for various rule/style violations ...

log_push(too_many_changes)
if too_many_changes:
sys.exit(1)
else:
sys.exit(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

Re: A workflow for local patch maintenance

[Stephen Bash]

- Original Message -
 From: Jeff King p...@peff.net
 Sent: Thursday, October 10, 2013 1:36:28 PM
 Subject: Re: A workflow for local patch maintenance
 
 ... snip ...

 That being said, there are some new downsides, as you noted:
 
   1. Resolving conflicts between your version and the reworked
   upstream version can be a pain.
 
 ... snip ...
 
 To mitigate problem 1, I will sometimes revert a local topic before
 doing the upstream merge, if I know it has been reworked.

Peff (slightly off topic) - A coworker of mine actually ran into this
problem earlier this week.  Is there recommended way to revert a merged
topic branch?  I assume it's essentially reverted each commit introduced
by the branch, but is there a convenient invocation of revert? (easy to 
remember and hard to screw up)

Thanks,
Stephen

--
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 stash deletes/drops changes of

[Stephen Bash]

- Original Message -
 From: Thomas Rast tr...@inf.ethz.ch
 Sent: Thursday, May 23, 2013 6:56:50 PM
 Subject: Re: git stash deletes/drops changes of
 
 Junio C Hamano gits...@pobox.com writes:
 
  Thomas Rast tr...@inf.ethz.ch writes:
 
   So maybe it would be time to first make up our minds as to what
   --assume-unchanged should actually mean:
  
   * Ignore changes to a tracked file, but treat them as valuable.
 In this case we'd have to make sure that failures like
 git-stash's are handled properly.
  
   * Ignore changes to a tracked file, as in who cares if it was
 changed.
  
   * A very specific optimization for users who know what they are
 doing.
 
  It has always been a promise the user makes to Git that the working
  tree files that are marked as such will be kept identical to what is
  in the index (hence there is no need for Git to check if they were
  modified). And by extension, Git is now free to choose reading from
  the working tree file when asked to read from blob object recorded
  in the index for that path, or vice versa, because of that promise.
 
  It is not --ignore-changes bit, and has never been.  What are the
  workflows that are helped if we had such a bit?  If we need to
  support them, I think you need a real --ignore-changes bit, not
  an abuse of --assume-unchanged.
 
 I gather -- from #git -- that it's mostly used for config files, which
 have an annoying habit of being different from the repository.

The web team at my $dayjob has the same problem, and I believe they are also 
using --assume-unchanged.

This may be slightly too tangential, but a different workflow we experimented 
with is marking the config file(s) merge=ours in gitattributes on each branch.  
Ideally then devs can check in their local settings on their local branches.  
Unfortunately, as is probably well known here, the merge attribute is only 
checked by the low level merge algorithm, so too often settings got bashed 
incorrectly (only one merge parent changed the file).  Perhaps there are some 
options in that direction?

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

Already up-to-date! merge isn't a no-op?

[Stephen Bash]

Hi all-

I have a branch history that looks like this:

 --M-M-- master
  \   / /
   x feature
\ \
 x-A- maint

In other words we had a new feature that was so cool that after testing on 
master was back-ported to maint (luckily we knew ahead of time this was 
likely).  When it came time to merge feature into maint the process looked 
something like this:

Yesterday (not shown above):
 $ git checkout master
 $ git merge maint

Today:
 $ git checkout maint
 $ git merge feature
 Merge made by the 'recursive' strategy.
 $ git checkout master
 $ git merge maint
 Already up-to-date!
 Merge made by the 'recursive' strategy.
 $ git --version
 git version 1.8.1.5

In the past, I've only seen Already up-to-date! when there is literally 
nothing to do (all commits are reachable from HEAD).  In this case, the merge 
of feature into maint (commit A) is the only commit not reachable from HEAD, 
and Git does create a merge commit (though the new commit and the first parent 
point to the same tree).  The fact that a commit is created makes me call this 
something more than a no-op, even though no content changed.

So what is the actual meaning of Already up-to-date!?  Is it based on the 
tree, the reachable commits, or something more complicated?

Thanks,
Stephen
--
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-svn with non-standard repository layout

[Stephen Bash]

- Original Message -
 From: Piotr Krukowiecki piotr.krukowie...@gmail.com
 Sent: Wednesday, December 5, 2012 11:26:54 AM
 Subject: Re: git-svn with non-standard repository layout
 
 On Tue, Dec 4, 2012 at 10:19 PM, Carsten Fuchs
 carsten.fu...@cafu.de wrote:
  Hi Piotr,
 
  Am 2012-12-04 18:29, schrieb Piotr Krukowiecki:
 
  Is there a way to handle svn repository with following layout?
 
  repo/trunk
  repo/branches/branch1
  repo/branches/branch2
  repo/branches/work/developer1/branch3
  repo/branches/work/developer1/branch4
  repo/branches/work/developer2/branch5
 
  see my post at
  http://www.cafu.de/forum/viewtopic.php?f=14t=1092
  heading Branches outside branches/.
 
  You may need something like
  git config --add svn-remote.svn.fetch
  path.../branchX:refs/remotes/branchX
  for each of your branches.
 
 that works :)
 
 Although not an ideal solution - I have to manually configure all
 branches + update them as they are created

It's not a 100% solution, but you can use a limited glob-like syntax in the 
branches and tags lines of the svn-remote config block.  You still need to do 
some manual work (one entry for each developer), but the wildcards eliminate a 
lot of the grunt work as individual branches are created.  See the very end of 
the git-svn manpage for examples (section titled CONFIGURATION).  I use that 
technique to track a subdirectory of the Slimdevices SVN repo [1], which has a 
similarly complex layout:

repo/7.1/trunk
repo/7.1/branches/branchA
repo/7.1/branches/branchB
repo/7.1/tags/tag1
repo/7.2/trunk
repo/7.2/branches/branchC
...

HTH,
Stephen
--
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-svn with non-standard repository layout

[Stephen Bash]

- Original Message -
 From: Piotr Krukowiecki piotr.krukowie...@gmail.com
 Sent: Wednesday, December 5, 2012 5:19:44 PM
 Subject: Re: git-svn with non-standard repository layout
 
 Do you mean something like
 
branches = branches/work/*/*:refs/remotes/work/*
branches = branches/{branch1,branch2}:refs/remotes/branches/*
 
 instead of (currently used)
 
branches = branches/work/*/*:refs/remotes/work/*
fetch = branches/branch1:refs/remotes/branches/branch1
fetch = branches/branch2:refs/remotes/branches/branch2

Essentially yes.  But I guess since you have branches at the same level as the 
work directory, you either have to add to the glob for each new branch or add 
another fetch line...  Doesn't seem like a big win to me.  Jumping on a 
tangent, I thought there could only be one wildcard on the left side of the ':' 
(and the '*' on the right).  If your work/*/* is actually working, that's quite 
interesting.
 
 BTW what's the difference between fetch and branches keys? I could
 only find one: fetch does not support glob arguments and branches
 do.

That's the only difference I've discovered, though someone more familiar with 
the code might be able to say more.

Here's my config for the Slimdevices repo I mentioned:

[svn-remote svn]
url = http://svn.slimdevices.com/repos/slim

fetch = trunk/server:refs/remotes/trunk
fetch = 7.5/trunk/server:refs/remotes/7.5/trunk
fetch = 7.6/trunk/server:refs/remotes/7.6/trunk
fetch = 7.7/trunk/server:refs/remotes/7.7/trunk
fetch = 7.8/trunk/server:refs/remotes/7.8/trunk

branches = branches/*/server:refs/remotes/pre7/*
branches = 7.5/branches/*/server:refs/remotes/7.5/*
branches = 7.6/branches/*/server:refs/remotes/7.6/*
branches = 7.7/branches/*/server:refs/remotes/7.7/*
branches = 7.8/branches/*/server:refs/remotes/7.8/*

tags = 7.5/tags/*/server:refs/remotes/7.5/tags/*
tags = 7.6/tags/*/server:refs/remotes/7.6/tags/*
tags = 7.7/tags/*/server:refs/remotes/7.7/tags/*
tags = 7.8/tags/*/server:refs/remotes/7.8/tags/*

Lots of repetition, but now that I look at it this repo doesn't have the 
branches/work clash yours does, which simplifies the config.

HTH,
Stephen
--
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: Python extension commands in git - request for policy change

[Stephen Bash]

- Original Message -
 From: Felipe Contreras felipe.contre...@gmail.com
 Sent: Tuesday, December 4, 2012 9:19:18 AM
 Subject: Re: Python extension commands in git - request for policy change
 
   Also, you are ignoring all the advantages that shell has and
   python does not.
 
  Out of curiosity, can you list the advantages? From what I
  gathered:
 
  - no need to install bash
 
 Unless you are in Windows or OS X. OS X has a shell, but not bash.

From http://support.apple.com/kb/TA27005:

The default shell (or command-line interface) used in Mac OS X 10.0 through 
10.2.8 is tcsh (with 10.3 and 10.4 it's bash). With Mac OS X 10.2 or later, 
other interactive shells are included, such as bash and zsh.

Stephen
--
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 bundle format [OT]

[Stephen Bash]

- Original Message -
 From: Jason J CTR Pyeron (US) jason.j.pyeron@mail.mil
 Sent: Monday, November 26, 2012 4:06:59 PM
 Subject: RE: git bundle format [OT]
 
  First, a shot out of left field: how about a patch based workflow?
  (similar to the mailing list, just replace email with sneakernet)
  Patches are plain text and simple to review (preferable to an
  opaque binary format?).
 
 This is to only address the accidental development on a high side.
 Using this or any process should come with shame or punishment for
 wasting resources/time by not developing on a low side to start
 with.

Ah, if only more of those I (previously) worked with thought as you do :)

 But accepting reality there will be times where code and its
 metadata (commit logs, etc) will be created on a high side and
 should be brought back to the low side.

Using git format-patch and git am it's possible to retain the commit messages 
(and other associated metadata).  But again, I'm not the expert on this :)  
I've made it work a few times to test patches from this list, but so far I've 
avoided serious integration into the mailing list workflow.

2) Do the diffs applied to public repo contain any sensitive
data?
 
 That is a great question. Can the change of code while neither the
 original or the resultant be secret while the change imply or
 demonstrate the secret. I think the answer is yes.

In actual fact I was thinking about the simple case where the result included 
an Eek! 3.1415926 cannot show up in this code! (sometimes that's easier to 
see in a diff than a full text blob).  Obviously the first line of defense 
should catch such mistakes.  But yes, your point is also a good one.  I'd be 
hard pressed to argue that a particular series of commits leaks information on 
their own, but they can certainly corroborate other available information.

  Question 2 is relatively straight forward and lead me to the patch
  idea.  I would:
- Bundle the public repository
- Init a new repo in the secure space from the public bundle
- Fetch from the to-be-sanitized bundle into the new repo
- Examine commits (diffs) introduced by branches in the to-be-
sanitized bundle
- Perhaps get a list of all the objects in the to-be-sanitized
bundle and do a git-cat-file on each of them (if the bundle is
assembled correctly it shouldn't have any unreachable objects...).
This step may be extraneous after the previous.
 
 Here we would be missing the metadata that goes along with the
 commit. Especially the SHA sums.

Ah sorry, I guess I wasn't complete.  Once that process has been done on the 
high side one has to go back to question 1 and see if it's safe to move the 
bundle out to repeat the process on the low side. 
 
Stephen
--
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: Overlong lines with git-merge --log

[Stephen Bash]

- Original Message -
 From: Tim Janik t...@gnu.org
 Sent: Friday, November 2, 2012 9:24:29 AM
 Subject: Re: Overlong lines with git-merge --log
 
 On 02.11.2012 11:05, Jeff King wrote:
 
  Taking just the first line of those often cuts off the useful part.
  It was deemed less bad to show the whole message as a subject rather
  than cut it off arbitrarily.
 
 Thanks a lot for the explanation, I'm using git directly here, but the
 two cases I had indeed lacked this newline.

FWIW we use merge --log quite extensively here at the office, and I've 
developed a habit to skim the extremely long lines and attempt to cut them 
intelligently (something I don't trust the computer to do for me).  Sometimes 
that means taking the second or third sentence if it's a better summary, 
sometimes it's just abbreviating the first.  Now that merge automatically 
spawns an editor, this is quite convenient (though it does take a bit longer).

Thanks,
Stephen
--
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: fa/remote-svn (Re: What's cooking in git.git (Oct 2012, #01; Tue, 2))

[Stephen Bash]

- Original Message -
 From: Jonathan Nieder jrnie...@gmail.com
 Sent: Thursday, October 4, 2012 4:30:01 AM
 Subject: Re: fa/remote-svn (Re: What's cooking in git.git (Oct 2012, #01; 
 Tue, 2))
 
   * fa/remote-svn (2012-09-19) 16 commits
   - Add a test script for remote-svn
   - remote-svn: add marks-file regeneration
   - Add a svnrdump-simulator replaying a dump file for testing
   - remote-svn: add incremental import
   - remote-svn: Activate import/export-marks for fast-import
   - Create a note for every imported commit containing svn metadata
   - vcs-svn: add fast_export_note to create notes
   - Allow reading svn dumps from files via file:// urls
   - remote-svn, vcs-svn: Enable fetching to private refs
   - When debug==1, start fast-import with --stats instead of
   --quiet
   - Add documentation for the 'bidi-import' capability of
   remote-helpers
   - Connect fast-import to the remote-helper via pipe, adding
   'bidi-import' capability
   - Add argv_array_detach and argv_array_free_detached
   - Add svndump_init_fd to allow reading dumps from arbitrary FDs
   - Add git-remote-testsvn to Makefile
   - Implement a remote helper for svn in C
   (this branch is used by fa/vcs-svn.)
  
   A GSoC project.
   Waiting for comments from mentors and stakeholders.
 
  I have reviewed this topic and am happy with the design and
  implementation.  I support this topic for inclusion.
 
 Thanks!  I'll try moving the tests to the first patch and trying it
 and hopefully send out a branch to pull tomorrow.
 
 If I don't send anything tomorrow, that's probably a sign that I never
 will, so since I like the goal of the series I guess it would be a
 kind of implied ack.

I seemed to have missed the GSoC wrap up conversation... (links happily
accepted)  Looking at the big picture (as much as I can remember) it
seems to me the missing pieces now are branch mapping (lots of hard
work), and possibly parts (all?) of the push to SVN functionality?

Thoughts?

Thanks,
Stephen
--
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: [RFC/PATCH 0/3] git log --pretty=lua

[Stephen Bash]

- Original Message -
 From: Nguyen Thai Ngoc Duy pclo...@gmail.com
 Sent: Tuesday, September 25, 2012 7:22:49 AM
 Subject: Re: [RFC/PATCH 0/3] git log --pretty=lua
 
 On Tue, Sep 25, 2012 at 7:23 AM, Jeff King p...@peff.net wrote:
  We've talked off and on about extending the --pretty=format
  specifiers to something more flexible. There's also been talk
  recently of more flexible commit-filtering (e.g., grepping
  individual notes).  Rather than invent a new Turing-complete
  language, I thought I'd try building on somebody else's work by
  embedding an existing language.
 
  Why Lua? I don't especially like it as a language. But it's designed
  for this purpose, which makes it very lightweight and relatively
  simple to embed.
 
 Personally I'd prefer a Scheme variant.

Scheme only brings up bad memories for me ;)  And while we use Lua at
$dayjob, I, like Peff, am not a huge fan of the syntax.  So turning to
the internet to solve my problem, a quick Google search for embeddable
scripting languages (assuming the heavyweights like Perl and Python are
already out) produces Lua, JavaScript or specifically SpiderMonkey [1]
(yay buzzword compliance!), Ch [2] (unfortunately closed source), and
AngelScript [3].

From a brief read of the webpage, AngelScript looks pretty interesting.
I'm much better with (and thus preferential to) Python and Perl myself,
but I can understand anyone's reservation in bundling/depending on
libraries of that size.

[1] https://developer.mozilla.org/en-US/docs/SpiderMonkey
[2] http://www.softintegration.com/
[3] http://angelcode.com/angelscript/

Thanks,
Stephen
--
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 2/2] attr: binary attribute should choose built-in binary merge driver

[Stephen Bash]

- Original Message -
 From: Junio C Hamano gits...@pobox.com
 Sent: Wednesday, September 12, 2012 4:55:53 AM
 Subject: Re: [PATCH 2/2] attr: binary attribute should choose built-in 
 binary merge driver
 
 Jeff King p...@peff.net writes:
 
  On Sat, Sep 08, 2012 at 09:40:39PM -0700, Junio C Hamano wrote:
 
  The built-in binary attribute macro expands to -diff -text, so
  that textual diff is not produced, and the contents will not go
  through any CR/LF conversion ever.  During a merge, it should also
  choose the binary low-level merge driver, but it didn't.
  
  Make it expand to -diff -merge -text.
 
  Yeah, that seems like the obviously correct thing to do. In
  practice,
  most files would end up in the first few lines of ll_xdl_merge
  checking
  buffer_is_binary anyway, so I think this would really only make a
  difference when our is it binary? heuristic guesses wrong.
 
 You made me look at that part again and then made me notice
 something unrelated.
 
   if (buffer_is_binary(orig-ptr, orig-size) ||
   buffer_is_binary(src1-ptr, src1-size) ||
   buffer_is_binary(src2-ptr, src2-size)) {
   warning(Cannot merge binary files: %s (%s vs. %s),
   path, name1, name2);
   return ll_binary_merge(drv_unused, result,
  path,
  orig, orig_name,
  src1, name1,
  src2, name2,
  opts, marker_size);
   }
 
 Given that we now may know how to merge these things, the
 unconditional warning feels very wrong.
 
 Perhaps something like this makes it better.

Patch didn't apply on top of the previous two for me, but after making the 
edits manually does what it claims to do (and makes the merge output much nicer 
to read, thanks!).  The only remaining question for me is should -Xtheirs 
resolve deleted by them conflicts?

Thanks,
Stephen
--
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 2/2] attr: binary attribute should choose built-in binary merge driver

[Stephen Bash]

- Original Message -
 From: Junio C Hamano gits...@pobox.com
 Sent: Wednesday, September 12, 2012 1:01:30 PM
 Subject: Re: [PATCH 2/2] attr: binary attribute should choose built-in 
 binary merge driver
 
  Perhaps something like this makes it better.
 
  Patch didn't apply on top of the previous two for me,...
 
 Look at 'pu' and see how it applies.

Ah, that seems to work better.
 
  ...  The only remaining
  question for me is should -Xtheirs resolve deleted by them
  conflicts?
 
 I do not know, and I do not care to worry about it too deeply, which
 means I would rather err on the safe side and have users inspect the
 situation, make the decision when such a conflict happens and
 resolve them themselves, instead of claiming a clean resolution that
 is possibly wrong.

A reasonable approach.  Thanks for clarifying.

Stephen
--
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 0/2] Teaching -Xours/-Xtheirs to binary ll-merge driver

[Stephen Bash]

- Original Message -
 From: Junio C Hamano gits...@pobox.com
 Sent: Sunday, September 9, 2012 12:40:37 AM
 Subject: [PATCH 0/2] Teaching -Xours/-Xtheirs to binary ll-merge driver
 
 The part that grants Stephen's wish is unchanged from the earlier
 perhaps like this patch, but this time with a bit of documentation
 and test.
 
 A more important change between the two actually is [PATCH 2/2].
 When a binary synthetic attribute is given to a path, we used to
 (1) disable textual diff and (2) disable CR/LF conversion, but it is
 also sane to disable the textual merge for a path marked as
 binary, and setting the -merge attribute to summon the binary
 ll-merge driver is the way to do so.
 
 Junio C Hamano (2):
   merge: teach -Xours/-Xtheirs to binary ll-merge driver
   attr: binary attribute should choose built-in binary merge
   driver
 
  Documentation/gitattributes.txt|  2 +-
  Documentation/merge-strategies.txt |  3 ++-
  attr.c |  2 +-
  ll-merge.c | 25 -
  t/t6037-merge-ours-theirs.sh   | 14 +-
  5 files changed, 37 insertions(+), 9 deletions(-)

Thanks for this Junio.  After figuring out how to make the corporate email 
server NOT munge the patches, I was able to apply these with no problem.  Then 

  $ git merge -Xtheirs maint

mostly does what I want, but conflicting files deleted on the incoming branch 
are still marked unmerged/deleted by them (binary or not).  I'm not sure what 
the best (most common?) resolution is for that.  In my case I would be happy 
for the -Xtheirs to also delete the files, but that might not always be the 
right answer (but then again -Xtheirs is a pretty heavy hammer to begin with).

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

Binary file-friendly merge -Xours or -Xtheirs?

[Stephen Bash]

Hi all-

Helping a coworker resolve merge conflicts today I found I wanted a -Xtheirs 
that completely replaces conflicted binary files with the copy from the 
incoming branch.  In other words rather than doing

  $ git merge maint
  ... conflicts occur ...
  $ git checkout --theirs -- path/to/binary-file
  $ git add path/to/binary-file
  $ git commit

I'd like to do

  $ git merge -Xbinary_theirs maint
  ... binary conflicts are resolved automatically ...

From reading the docs it's obvious the current -Xours and -Xtheirs expect to 
work on hunks, so I (mostly) understand the current behavior, but as a user it 
feels like I'm telling you how to resolve conflicts, please do the same thing 
for binary files.

I am missing a solution that already exists?  Or is this perhaps an improvement 
that could be made?

Thanks,
Stephen
--
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: diff/merge tool that ignores whitespace changes

[Stephen Bash]

- Original Message -
 From: Enrico Weigelt enrico.weig...@vnc.biz
 Sent: Tuesday, August 28, 2012 12:26:39 PM
 Subject: diff/merge tool that ignores whitespace changes
 
 I'm looking for a diff / merge tool that treats lines with
 only whitespace changes (trailing or leading whitespaces,
 linefeeds, etc) as equal.
 
 The goal is to make reviews as well as merging or rebasing
 easier when things like indentions often change.
 
 Does anybody know an solution for that ?

I use kdiff3 which has the option to ignore whitespace changes (bonus: I can 
use it on all three major OSes as my work requires).  It's GUI based, so that 
could be considered a downside to some.

I usually use a combination of Git's built-in diff and kdiff to check my work.

HTH,
Stephen
--
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: diff/merge tool that ignores whitespace changes

[Stephen Bash]

- Original Message -
 From: Matthew Caron matt.ca...@redlion.net
 Sent: Tuesday, August 28, 2012 1:41:51 PM
 Subject: Re: diff/merge tool that ignores whitespace changes
 
   I'm looking for a diff / merge tool that treats lines with only
   whitespace changes (trailing or leading whitespaces, linefeeds,
   etc) as equal.
  
   The goal is to make reviews as well as merging or rebasing easier
   when things like indentions often change.
  
   Does anybody know an solution for that ?
 
 I'm fond of Meld.

I loved Meld when I was working exclusively on Linux several years ago.  
Honestly I think I set up my kdiff fonts/highlight colors/etc. to be very 
Meld-like (unintentionally, just what looked right).  Looking at the website, 
technically Meld should build/run on a variety of OSes, but at some point (lost 
to the sands of time) I ran into trouble which is why I switched.

Stephen
--
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: Temporary merge branch 2 Conflicts

[Stephen Bash]

- Original Message -
 From: Junio C Hamano gits...@pobox.com
 Sent: Friday, August 17, 2012 5:10:47 PM
 Subject: Re: Temporary merge branch 2 Conflicts
 
 Stephen Bash b...@genarts.com writes:
 
  What is the recommended method for resolving this sort of merge?
  kdiff3 obviously doesn't understand the situation.  Do the working
  tree files contain all the conflicts?  If so, I can just go
  through by hand and resolve the conflicts the old fashion way.
 
 Yes.  External tools like kdiff3 may not understand the conflict in
 the working tree, but the files in the working tree should have
 resolved the naturally resolvable bits and only left the conflicted
 bits conflicted.  Just resolve manually if you can, and then look at
 what both branches wanted to do to the file (git log -p --merge
 $that_path before you git add as the final sanity check would
 work nicely) to make sure your resolution makes sense.

Thanks for the clarification Junio.  I'll take another swipe at it this week 
now that I know what I'm doing!

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

Temporary merge branch 2 Conflicts

[Stephen Bash]

Hi all-

Given this branch history:

 -M--M---M--- dev
 \   /  /   /
  --   v1-maint
\   \   \
 M---M--- v1.5-maint

I am attempting to merge v1.5-maint into dev.  There are some expected 
conflicts, but when I start mergetool (kdiff3) there are also a lot of conflict 
markers in the base that look like this

 Temporary merge branch 1
... code here ...
===
... more code here ...
 Temporary merge branch 2

which confuse kdiff3.  Googling around I found a few mentions of these 
temporary merge branches, e.g. $gmane/157591, but I don't think we have any 
criss-cross merges.  Can anyone provide some advice?

Any suggestions are greatly appreciated!

Thanks,
Stephen
--
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: Temporary merge branch 2 Conflicts

[Stephen Bash]

- Original Message -
 From: Stephen Bash b...@genarts.com
 Sent: Friday, August 17, 2012 9:48:45 AM
 Subject: Temporary merge branch 2 Conflicts
 
 Given this branch history:
 
  -M--M---M--- dev
  \   /  /   /
   --   v1-maint
 \   \   \
  M---M--- v1.5-maint
 
 I am attempting to merge v1.5-maint into dev.

Turns out (not surprisingly) the graph is not that simple.  I have multiple 
(disjoint) merge bases:

  $ git merge-base --all dev v1.5-maint 
  ad9ed6c207fba9419b10a394e3721333d0d73e81
  5ff4cb0927188fb7246a0eff22d7ffed1a91fe2d
  $ git rev-list --ancestry-path 5ff4cb0..ad9ed6c
  $

A little investigation of 5ff4cb0 shows the branch structure looks more like:

   A-C- v1-maint
  /  |\
 o   | \
  \  |  \
   B |   \
   |\|\
 --|-M---|-M--- v1.5-maint
   | |
 --M-M- dev

B is 5ff4cb0 and C is ad9ed6c (with several months and commits separating 
them).  A and B are tree-same (the only difference is the commit time and the 
log message).  Again, I'm attempting to merge v1.5-maint into dev.

 Googling around I found a few mentions of these temporary merge
 branches, e.g. $gmane/157591, but I don't think we have any
 criss-cross merges.

And now I'm convinced I do have some form of degenerate merge case.  I made 
several attempts to dig myself out of this hole, but failed.  

What is the recommended method for resolving this sort of merge?  kdiff3 
obviously doesn't understand the situation.  Do the working tree files contain 
all the conflicts?  If so, I can just go through by hand and resolve the 
conflicts the old fashion way.

Separately, is mergetool passing the correct base file to the external tool if 
I'm seeing Temporary merge branch conflicts in it?  (I'm using git 1.7.11.4)

Thanks!
Stephen
--
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 2/4] Allow reading svn dumps from files via file:// urls.

[Stephen Bash]

- Original Message -
 From: Junio C Hamano gits...@pobox.com
 To: Dmitry Ivankov divanor...@gmail.com
 Cc: git@vger.kernel.org
 Sent: Wednesday, July 11, 2012 1:00:29 PM
 Subject: Re: [PATCH 2/4] Allow reading svn dumps from files via file:// urls.
 
 Dmitry Ivankov divanor...@gmail.com writes:
 
  Florian Achleitner florian.achleitner.2.6.31 at gmail.com
  writes:
 
   Especially for testing and development it's useful to bypass
   svnrdump and replay the svndump from a file without connecting to
   an svn server.
   
   Add support for file:// urls in the remote url.  e.g.
   svn::file:///path/to/dump When the remote helper finds an url
   starting with file:// it tries to open that file instead of
   invoking svnrdump.
 
  file:// is a bad choice because file:// style repo urls are valid
  for svn and it's for local repos rather than dumpfiles.
 
 Thanks; I had the same reaction when I saw it.
 
  Maybe something like dumpfile:// instead?
 
 If dumpfile:// pseudo URL is an established convention in the
 Subversion land, that sounds like a sensible direction, but if that is
 not the case, it may be cleaner if you can find some other way to
 convey the information to the backend out-of-band, instead of
 overloading it in the URL used to access the repository.

Others may have a different opinion, but in my experience dump files are always 
handled via stdin/stdout in Subversion land.  For example:

http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.dump.html
http://svnbook.red-bean.com/en/1.7/svn.ref.svnadmin.c.load.html
http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.filtering

I'm not sure that helps in this scenario, but that was the convention I grew 
used to.

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