If I do this:
$ git config merge.ff false
And then:
$ git merge --squash topic
I get:
> fatal: You cannot combine --squash with --no-ff.
I can work around this by executing:
$ git merge --squash --ff topic
Which essentially negates the `merge.ff` configuration. In this
scenario, wouldn't it
On Fri, Sep 13, 2019 at 10:30 PM Jeff King wrote:
> SNIP
>
> > Now this looks more like it. I can actually see a useful diff here,
> > instead of everything looking like a new file. But there is a lot of
> > confusion here:
> >
> > 1. `diff --follow` is not a documented[1] option. Why does it work
I'm using Git version 2.23. I have the `diff.renames` setting set to
`copies`. My code base has a file named `JniPaymentManager.hpp` (and
`cpp`) that had too much code in it, so I refactored this file by
splitting out a significant portion of the code in it to another file,
named `ZPayClient.hpp` (
I've observed that when merging a branch, and there's a submodule
conflict, sometimes Git will prompt a suggested resolution like so:
```
Failed to merge submodule Core (not fast-forward)
Found a possible merge resolution for the submodule:
If this is correct simply add it to the index for exampl
On Tue, May 28, 2019 at 8:35 AM Robert Dailey wrote:
>
> On Fri, May 24, 2019 at 12:11 PM Andreas Schwab wrote:
> >
> > On Mai 24 2019, Robert Dailey wrote:
> >
> > > Can anyone provide some advice on how to properly restructure this
> > > repository
On Fri, May 24, 2019 at 12:11 PM Andreas Schwab wrote:
>
> On Mai 24 2019, Robert Dailey wrote:
>
> > Can anyone provide some advice on how to properly restructure this
> > repository to create some ancestry, as if all along a `master` existed
> > and all release branc
On Fri, May 24, 2019 at 9:04 AM Robert Dailey wrote:
>
> Everything I'm going to describe is related to this repository:
>
> https://github.com/powervr-graphics/Native_SDK
>
> This repo has several distinct branches. None of them seem to be tied
> to each other. Instead
Everything I'm going to describe is related to this repository:
https://github.com/powervr-graphics/Native_SDK
This repo has several distinct branches. None of them seem to be tied
to each other. Instead of having a `master` where they branched off
each of their releases (e.g. 3.1, 3.2, 4.0), it
On Tue, May 7, 2019 at 9:10 AM Robert Dailey wrote:
> Your example is very helpful. I understand what you're saying for
> conflicted lines. But the "whatever the default merge resolution would
> have been" doesn't exist, because there's no reality where line
On Mon, May 6, 2019 at 6:52 PM Ævar Arnfjörð Bjarmason wrote:
> Maybe an example helps, let's say you have two paint buckets, one with
> red paint, one with yellow paint. You mix them. What happens?
>
> (
> rm -rf /tmp/git &&
> git init /tmp/git &&
> cd /tmp/git &&
>
I feel like you got hung up too much on exact wording of what I was
trying to describe. I do apologize I don't have the background to
explain things 100% accurately, especially at a low level. My
explanations are mostly intended to be as a user, based on what is
observable, and based on intent. I'l
I'm hoping this is mostly a learning opportunity for me. I'm assuming
things are working as designed, but I just don't understand something
fundamental.
I have a merge commit. HEAD is currently pointing at this merge
commit. To be exact, HEAD points to master, which points to the merge
commit. My
When I perform a rebase and it stops at a commit due to a conflict,
the messages printed are very verbose. Example:
```
Applying: Delete run configuration for zPayServiceStandalone
Using index info to reconstruct a base tree...
A .idea/runConfigurations/zPayServiceStandalone.xml
Falling back
On Thu, Apr 4, 2019 at 4:50 PM Junio C Hamano wrote:
>
> Robert Dailey writes:
>
> > It might be fine within the realm of git itself, because git knows how
> > to deal with them by peeling, as you say, but there are 3 reasons I
> > dislike that this is allowed:
>
On Thu, Apr 4, 2019 at 8:56 AM Robert Dailey wrote:
>
> On Thu, Apr 4, 2019 at 7:06 AM Jeff King wrote:
> >
> > On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote:
> >
> > > Agreed.
> > >
> > > I think that the implement is a little
On Thu, Apr 4, 2019 at 7:06 AM Jeff King wrote:
>
> On Wed, Apr 03, 2019 at 08:26:06PM -0700, Taylor Blau wrote:
>
> > Agreed.
> >
> > I think that the implement is a little different than "add a --no-edit"
> > flag, though. 'git tag' already has a OPT_BOOL for '--edit', which means
> > that '--no
On Thu, Apr 4, 2019 at 4:32 AM Junio C Hamano wrote:
>
> Robert Dailey writes:
>
> >> > more clear in the doc and/or in the proposed log message what
> >> > practical downside there are to the end users if we do not stop this
> >> > "mistake&quo
On Wed, Apr 3, 2019 at 3:50 AM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> > I am not sure if this is so bad, actually. Why do we need to treat
> > it as a mistake? When a command that wants a commit is fed a tag
> > (either a tag that directly refers to a commit, or a tag that tags
>
Similar to git commit, it would be nice to have a --no-edit option for
git tag. Use case is when I force-recreate a tag:
$ git tag -af 1.0 123abc
An editor will be prompted with the previous annotated tag message. I
would like to add --no-edit to instruct it to use any previously
provided message
On Wed, Mar 27, 2019 at 5:27 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Wed, Mar 27 2019, Elijah Newren wrote:
>
> > On Tue, Mar 26, 2019 at 12:56 AM Denton Liu wrote:
> >>
> >> Robert Dailey reported confusion on the mailing list about a recursive
>
On Mon, Mar 25, 2019 at 9:49 AM Jeff King wrote:
> I think "just commits" is too restrictive. linux.git contains a tag of a
> tree, for example (we also have tags pointing to blobs in git.git, but
> they are not annotated).
>
> However, I could see an argument for the git-tag porcelain to notice a
On Thu, Mar 21, 2019 at 2:29 PM Jeff King wrote:
> Tags can point to any object, including another tag. It looks like
> somebody made an annotated tag of an annotated tag (probably by
> mistake, given that they have the same tag-name).
>
> Try this:
>
> git init
> git commit -m commit --allow-
I have a particular tag in my repo that shows 2 annotated
descriptions, which is very confusing.
The command I ran:
```
git show --format=fuller 4.2.0.1900
```
And the output:
```
tag 4.2.0/1900
Tagger: John Doe
TaggerDate: Fri Jul 18 10:46:30 2014 -0500
QA/Internal Release for 4.2.0.19
On Wed, Oct 17, 2018 at 1:47 PM Jeff King wrote:
> Hmm, I feel like another person asked for this recently, but I can't
> seem to find the thread.
Is it this one?
https://www.mail-archive.com/git@vger.kernel.org/msg159212.html
That's the only one I was able to find, but no one replied. Thanks fo
I'd like to sort the output of `git diff --stat` such that files are
listed in descending order based on number of lines changed. The
closest solution I've found online[1] has several readability issues.
I'd rather see a built-in solution in git, if one exists. Can anyone
recommend a solution?
[1]
On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder wrote:
>
> Hi,
>
> Robert Dailey wrote:
>
> > Is there an 'auto' setting for the 'core.autocrlf' config? Reason I
> > ask is, I want that setting to be 'input' on linux but 'true
On Mon, Aug 27, 2018 at 12:32 PM Andrei Rybak wrote:
>
> On 2018-08-27 17:52, Duy Nguyen wrote:
> > On Mon, Aug 27, 2018 at 5:37 PM Torsten Bögershausen wrote:
> >>> In those cases, when it falls back to
> >>> configuration for line ending management, I want it to be
> >>> automatically configure
On Mon, Aug 27, 2018 at 10:53 AM Duy Nguyen wrote:
>
> On Mon, Aug 27, 2018 at 5:37 PM Torsten Bögershausen wrote:
> > > In those cases, when it falls back to
> > > configuration for line ending management, I want it to be
> > > automatically configured based on the host platform.
> >
> > There i
Is there an 'auto' setting for the 'core.autocrlf' config? Reason I
ask is, I want that setting to be 'input' on linux but 'true' on
Windows. I have a global .gitconfig that I sync across different
platforms with Google Drive, and I hate to manage 2 copies of it on
each platform (linux and Windows)
On Mon, Aug 6, 2018 at 10:41 AM, Jonathan Nieder wrote:
> Robert Dailey wrote:
>
>> Automatic would be
>> great if submodules were treated as integrated in a similar manner to
>> subtree, but it's not there. I wasn&#
On Thu, Aug 2, 2018 at 1:08 AM, Jonathan Nieder wrote:
> I think I misread this the first time. I got distracted by your
> mention of the --remote option, but you mentioned you want to use the
> SHA-1 of the submodule listed, so that was silly of me.
>
> I think you'll find that "git fetch --no-r
Problem: I want to avoid recursively fetching submodules when I run a
`fetch` command, and instead defer that operation to the next
`submodule update`. Essentially I want `fetch.recurseSubmodules` to be
`false`, and `get submodule update` to do exactly what it does with
the `--remote` option, but s
I noticed that when stepping into a new file while doing `git add -p`,
pressing `k` or `K` does not go back to the previous file. Is this a
bug? Is there a setting for it? I googled & checked out the git docs,
I didn't find any specific information on this.
On Mon, Apr 2, 2018 at 1:53 AM, Johannes Sixt wrote:
> Am 02.04.2018 um 02:36 schrieb Robert Dailey:
>>
>> I'm struggling with a bug that I found introduced in git v2.13.2. The
>> bug was not reproducible in v2.13.1. The issue is that using arguments
>> like "
On Tue, Mar 27, 2018 at 5:17 PM, Stefan Beller wrote:
>> >> $ git diff --submodule=log --submodule-log-detail=(long|short)
>> >>
>> >> I'm not sure what makes sense here. I welcome thoughts/discussion and
>> >> will provide follow-up patches.
>> >
>> > The case of merges is usually configured with
I'm struggling with a bug that I found introduced in git v2.13.2. The
bug was not reproducible in v2.13.1. The issue is that using arguments
like "@{-1}" to aliases causes those curly braces to be removed, so
once the command is executed after alias processing the argument looks
like "@-1". This br
On Tue, Mar 13, 2018 at 11:51 AM, Elijah Newren wrote:
> Anyway, I recorded this at
> https://bugs.chromium.org/p/git/issues/detail?id=11. Sorry I don't
> have a workaround, but I'll try to eventually get back to this and fix
> it.
Thank you for taking the time to verify this for me. I will keep
On Thu, Mar 8, 2018 at 10:01 AM, Robert Dailey wrote:
> I'm on Windows and core.ignorecase is set to 'true' when I clone/init
> a repository. I've got a branch where I started making changes to a
> file AND renamed it only to change its case. The changes I've m
I'm on Windows and core.ignorecase is set to 'true' when I clone/init
a repository. I've got a branch where I started making changes to a
file AND renamed it only to change its case. The changes I've made
were significant enough that git no longer detects a rename, instead
the files show up as "D"
=long-log
Or a supplementary option such as:
$ git diff --submodule=log --submodule-log-detail=(long|short)
I'm not sure what makes sense here. I welcome thoughts/discussion and
will provide follow-up patches.
Signed-off-by: Robert Dailey
---
submodule.c | 3 ++-
1 file changed, 2 insert
On Thu, Jan 25, 2018 at 6:21 PM, Isaac Hier wrote:
> Hi Jeff,
>
> I have been looking at the build generator, which looks promising, but
> I have one concern. Assuming I can generate a CMakeLists.txt that
> appropriately updates the library sources, etc. how do you suggest I
> handle new portabili
On Fri, Feb 16, 2018 at 10:34 AM, Torsten Bögershausen wrote:
> On Thu, Feb 15, 2018 at 09:24:40AM -0600, Robert Dailey wrote:
>> On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote:
>
> []
>>
>> Sorry to bring this old thread back to life, but I did notice that
&
On Thu, Feb 15, 2018 at 1:16 PM, Junio C Hamano wrote:
> I think the message you are referring to is a tangent that discusses
> how it was done in the old world, with issues that come from the
> fact that with such an approach the paths are first removed from the
> index and then added afresh to t
On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>>> $ git rm -r --cached . && git add .
>>
>> (Both should work)
>>
>> To be honest, from the documentation, I can't figure out the difference
>> between
>> $ git read-tree --empty
>> and
>> $ git rm -r --cach
I haven't seen such an option, but I think it would be nice to be able
to ignore submodules when creating a stash. When I stash changes in a
directory, almost always I intend to only stash real files, not
modified submodules. When I pop the stash later, it gets disrupted due
to submodule conflicts.
On Fri, Jan 5, 2018 at 2:54 PM, Bryan Turner wrote:
> The two _aren't_ distinctly separate, though. "git merge --squash
> --ff-only" has very different semantics to "git merge --squash --ff",
> in that it will only create a new squashed commit (or fast-forward a
> single commit) if the incoming co
On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith wrote:
> On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:
>> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey
>> wrote:
>> > Not sure if this is intended or a bug, but with the following
>> > configuration:
>>
Not sure if this is intended or a bug, but with the following configuration:
$ git config --global merge.ff false
I am not able to merge my topic branch into master with squash option:
$ git checkout master
$ git merge --squash topic
fatal: You cannot combine --squash with --no-ff.
I'm not sure
I keep expecting that pressing K during patch add that it will cross
file boundaries and go to previous hunks in files before the current
one. However, it reports "no hunks" when reaching the top hunk in the
current file. Is there a way to go to the previous file?
When upstream is not specified for the rebase command (e.g. I just do
`git rebase`), `--fork-point` is assumed which results in commits
regenerating SHA1 even if the merge-base would otherwise be identical.
Here's my scenario:
I set my remote tracking branch to my parent branch:
$ git branch -u
When doing a rebase, sometimes I will get `DU` and `UU` conflicts
(locally deleted and locally modified, respectively). Furthermore, in
some of these cases, I want to take "ours" for all conflicts,
including ones where the local file is deleted. Ideally, it's just one
command:
$ git checkout -
Suppose the tip commit of my branch contains changes to multiple
files. If I want to revert all changes in one file from that commit, I
have two options that I know of:
$ git reset @^ -- foo.txt
$ git commit --amend --no-edit
$ git checkout -- foo.txt
Or:
$ git checkout @^ -- foo.txt
$ git commi
On Wed, Oct 4, 2017 at 11:59 AM, Jonathan Nieder wrote:
> Hi Robert,
>
> Robert Dailey wrote:
>
>> You guys are obviously worlds ahead of me on the internals of things,
>> but from my perspective I like to avoid the "plumbing" commands as
>> much as I can.
On Tue, Oct 3, 2017 at 9:00 PM, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>>> $ git rm -r --cached . && git add .
>>
>> (Both should work)
>>
>> To be honest, from the documentation, I can't figure out the difference
>> between
>> $ git read-tree --empty
>> and
>> $ git rm -r --cach
On Tue, Oct 3, 2017 at 11:26 AM, Torsten Bögershausen wrote:
> The short version is, that the instructions on Github are outdated.
> This is the official procedure (since 2016, Git v2.12 or so)
> But it should work even with older version of Git.
>
> $ echo "* text=auto" >.gitattributes
> $ git re
I'm on Windows using Git for Windows v2.13.1. Following github's
recommended process for fixing line endings after adding a
`.gitattributes` file[1], I run the following:
$ rm .git/index && git reset
Once I run `git status`, I see that no files have changed. Note that I
know for a fact in my repo
On Thu, Sep 14, 2017 at 10:57 AM, Nicolas Morey-Chaisemartin
wrote:
> Without changing your workflow too much,
If you mean to imply that you have other recommendations if I'm
willing to change my workflow, then please by all means share them.
I'm very interested. I'm not too hooked on my workflow
So I often will have a submodule that points to one of my own forks,
because I will have work done on a feature branch that hasn't been
merged upstream yet. Assuming this merge takes a long time to get
approved, I will occasionally rebase my topic branch to keep things up
to date and clean.
Howeve
The gitmodules documentation[1] states that the .gitmodules file is at
the root. However, it would be nice if this could be supported in any
directory similar to how .gitignore works. Right now git-subrepo does
not support submodules inside of a subrepo[2] (I suspect subtrees
would have the same pr
So I found out about "subrepo" today: https://github.com/ingydotnet/git-subrepo
I'm still reading about how it works internally, but what do you guys
think about it? Is it a more or less perfect alternative to
submodules? What would be a reason not to use it?
On Mon, Jun 19, 2017 at 3:56 PM, Jeff King wrote:
> On Mon, Jun 19, 2017 at 03:32:54PM -0500, Robert Dailey wrote:
>
>> To drop a stash, I have to do this (example):
>>
>> $ git stash drop stash@{3}
>>
>> Using the full "stash@{N}" seems superfluous
To drop a stash, I have to do this (example):
$ git stash drop stash@{3}
Using the full "stash@{N}" seems superfluous since the documentation
states it must be a stash in the first place. It would make more sense
(and be quicker to type) to do:
$ git stash drop 3
Is there a trick I can use to m
On Fri, Jun 9, 2017 at 8:53 PM, Junio C Hamano wrote:
> Robert Dailey writes:
>
>> So I want to update my remote fork with all my local branches.
>> Normally I'd do this:
>>
>> $ git push --mirror fork
>>
>> However this will also push everything u
So I want to update my remote fork with all my local branches.
Normally I'd do this:
$ git push --mirror fork
However this will also push everything under `refs/remotes` which I do
not want. And it fails if I specify a refspec parameter with --mirror.
Is there a way to achieve this through one o
On Wed, May 24, 2017 at 9:22 AM, Robert Dailey wrote:
> Hello,
>
> Is it possible to hide decorated refs in `git log` even if they are
> reachable from the refs I'm actually interested in seeing the logs of?
>
> For example, if I do `git log --graph --decorate --onelin
Hello,
Is it possible to hide decorated refs in `git log` even if they are
reachable from the refs I'm actually interested in seeing the logs of?
For example, if I do `git log --graph --decorate --oneline --branches
'feature/*'`, I'd like to *only* see refnames that match the glob
pattern. Howeve
On Wed, May 17, 2017 at 8:39 AM, Robert Dailey wrote:
> Thanks Junio, I forgot about merge-base. I'll create some aliases for now:
>
> # Diff Branch
> db = "!f() { : git diff ; git diff $(git merge-base @{upstream}
> HEAD) ; }; f"
>
> # Diff Tool B
On Tue, May 16, 2017 at 9:47 PM, Junio C Hamano wrote:
> Robert Dailey writes:
>
>> So for a topic branch based on master, I can diff ONLY my changes on
>> the topic branch by doing this simple command:
>>
>> $ git diff origin/master...
>>
>> However,
So for a topic branch based on master, I can diff ONLY my changes on
the topic branch by doing this simple command:
$ git diff origin/master...
However, this does not include uncommitted working copy changes. To
work around this, I can do this instead:
$ git diff origin/master
(No three-dot not
On Thu, May 11, 2017 at 6:36 PM, Jeff King wrote:
> On Thu, May 11, 2017 at 04:23:03PM -0500, Robert Dailey wrote:
>
>> On Thu, May 11, 2017 at 3:17 PM, Jeff King wrote:
>> > I think you want:
>> >
>> > [push]
>> > default = current
>>
On Thu, May 11, 2017 at 3:17 PM, Jeff King wrote:
> I think you want:
>
> [push]
> default = current
> [remote]
> pushDefault = myfork
>
> to make "git push" do what you want. And then generally have branches
> mark their counterparts on "origin" (which you can do either at creation
> time
I know Git has evolved to support the "triangle" workflow model in
different ways, with the goal of making it better. However because
there are so many different options from separate push URLs for
remotes to various ways to manage tracking branches, it's not clear to
me which specific configuratio
On Fri, Mar 3, 2017 at 12:04 PM, Junio C Hamano wrote:
> Robert Dailey writes:
>
>> Sometimes I run into a situation where I need to find out which
>> release of the product a submodule change was introduced in. This is
>> nontrivial, since there are no tags in the su
I have the following log:
$ git log
commit 7ffb909bb8f38607e3d6d9f3504a66ca978f0ac2
Author: Robert Dailey
Date: Mon Dec 12 11:01:00 2016 -0600
Add initial skeleton files & a few interfaces for new kizi/sc16 stuff
This is still FAR from complete
I want to generate change
I have a repository with a single submodule in it. Since the parent
repository represents the code base for an actual product, I tag
release versions in the parent repository. I do not put tags in the
submodule since multiple other products may be using it there and I
wanted to avoid ambiguous tags
On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley wrote:
> From: "Robert Dailey"
>>
>> Here's the scenario:
>>
>> I create a topic branch so one other developer and myself can work on
>> a feature that takes 2 weeks to complete. During that 2 week p
Here's the scenario:
I create a topic branch so one other developer and myself can work on
a feature that takes 2 weeks to complete. During that 2 week period,
changes are occurring on master that I need in my topic branch. Since
I have a collaborator on the branch, I opt for merges instead of
reb
The release notes mention a new heuristic for diff:
* Output from "git diff" can be made easier to read by selecting
which lines are common and which lines are added/deleted
intelligently when the lines before and after the changed section
are the same. A command line option is added to help with
On Wed, Oct 19, 2016 at 2:51 PM, Robert Dailey wrote:
> On Wed, Oct 19, 2016 at 2:45 PM, Stefan Beller wrote:
>> On Wed, Oct 19, 2016 at 12:19 PM, Robert Dailey
>> wrote:
>>> On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller wrote:
>>>> You could try this p
On Wed, Oct 19, 2016 at 2:45 PM, Stefan Beller wrote:
> On Wed, Oct 19, 2016 at 12:19 PM, Robert Dailey
> wrote:
>> On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller wrote:
>>> You could try this patch series:
>>> https://github.com/jlehmann/git-submod-enhancem
On Wed, Oct 19, 2016 at 11:23 AM, Stefan Beller wrote:
> You could try this patch series:
> https://github.com/jlehmann/git-submod-enhancements/tree/git-checkout-recurse-submodules
> (rebased to a newer version; no functional changes:)
> https://github.com/stefanbeller/git/tree/submodule-co
> (I'l
On Tue, Oct 18, 2016 at 4:17 PM, Stefan Beller wrote:
> On Tue, Oct 18, 2016 at 12:35 PM, Robert Dailey
> wrote:
>> Hello git experts,
>>
>> I have in the past attempted to integrate submodules into my primary
>> repository using the same directory name. Howe
Hello git experts,
I have in the past attempted to integrate submodules into my primary
repository using the same directory name. However, this has always
caused headache when going to and from branches that take you between
when this integration occurred and when it didn't. It's a bit hard to
exp
I have 3 remotes registered in my clone:
origin, fork, drive
When I do:
$ git log --oneline --decorate --graph
I only want to see branches under:
refs/heads/*
refs/remotes/origin/*
I tried the following:
$ git log --oneline --decorate --graph --simplify-by-decoration
--remote=origin topic1..
Normally when I use interactive add, I just want to add files to the
index via simple numbers, instead of typing paths. So I'll do this as
quick as I can:
1. Type `git add -i`
2. Press `u` after prompt appears
3. Press numbers for the files I want to add, ENTER key
4. ENTER key again to go back to
On Fri, Sep 2, 2016 at 9:22 PM, Junio C Hamano wrote:
> Perhaps a change like this to "rebase -i":
>
> - The search for "original" when handling "pick fixup! original",
>when it does not find "original", could turn it into "reword
>fixup! original" without changing its position in the ins
Suppose I have a branch with 4 commits, in the following order (as you
might see during interactive rebase):
pick 123 Original Change
pick 789 fixup! Original Change
pick 456 Some Other Thing
pick abc fixup! fixup! Original Change
However, let's say the first commit is already pushed upstream on
On Wed, Aug 24, 2016 at 11:00 AM, Michael J Gruber
wrote:
> The 3-dot notation means:
>
> Show the difference between the merge-base of master and topic, and topic.
>
> I'm not completely sure, but I guess what you want is:
>
> Show the difference between the merge-base of master and topic, and th
I want to view the complete diff of my branch (topic) relative to its
parent branch (master). This should include cached/staged files and
unstaged working tree changes.
If I do this:
$ git diff master
This will include changes on master *since* my last merge, which I do
not want (I don't want to
On Wed, Aug 17, 2016 at 1:34 PM, Junio C Hamano wrote:
> Robert Dailey writes:
>
>> My use case is that I do a merge from branch A to branch B. Branch A
>> modified a file which is already deleted on B some time before the
>> merge.
>>
>> When I do a `git st
My use case is that I do a merge from branch A to branch B. Branch A
modified a file which is already deleted on B some time before the
merge.
When I do a `git status -sb`, these locally deleted but remotely
modified files show up as "DU".
I want to invoke git status or diff (or something else) t
On Mon, May 30, 2016 at 5:00 PM, Junio C Hamano wrote:
> Robert Dailey writes:
>
>> I like your solution better than mine because it utilizes the rules
>> defined in .gitattributes.
>
> A difference that may be more important is that I do not do
> generation of a
On Mon, May 30, 2016 at 2:06 PM, Junio C Hamano wrote:
> I have had this in my ~/.gitconfig for a long time.
>
> [alias]
> wsadd = "!sh -c 'git diff -- \"$@\" | git apply --cached
> --whitespace=fix;\
> git co -- ${1-.} \"$@\"' -"
>
> That is, "take what's different from t
I think it would be useful to have a '-w' option for 'git add' that
completely ignores whitespace changes, the same way that 'git diff -w'
does.
Real life scenario:
Sometimes developers will use tooling that does not properly strip
trailing whitespace in source files. Next time I edit those files
Sometimes, I merge 2 branches that have deviated quite a bit. A
worst-case example would be some API change. The topic branch
(long-lived) may start using the old API. However, once I merge the
topic back to master, that API no longer exists. As such, every place
that introduces a usage of the old
On Sat, May 14, 2016 at 6:30 PM, Junio C Hamano wrote:
> Robert Dailey writes:
>
>> This is because the merge base commit isn't shown. I understand this
>> is "by-design", but is there a way to include it? It's necessary to
>> have it, for this graph
If you consider a simple case where I run the following command:
$ git log --oneline --graph --decorate A...B
Where A and B are both branches with a single merge base and a series
of commits on each branch. Very simple example with no loops or crazy
ancestry. Below is an example repo I set up, wh
On Fri, Mar 25, 2016 at 1:58 PM, Junio C Hamano wrote:
> I thought these are clear from their documentation. "push" works on
> refnames, "branch" works on branch names. "push" takes an branch
> name as a short-hand and adds refs/heads/ when it makes sense, but
> because it does not make any sens
On Fri, Mar 25, 2016 at 1:02 PM, Robert Dailey wrote:
> On Fri, Mar 25, 2016 at 12:45 PM, Junio C Hamano wrote:
>> You can ask rev-parse to give you --symbolic-full-name, error out if
>> it is empty (i.e. detached HEAD), and otherwise use the result, no?
>>
>&
On Fri, Mar 25, 2016 at 12:45 PM, Junio C Hamano wrote:
> You can ask rev-parse to give you --symbolic-full-name, error out if
> it is empty (i.e. detached HEAD), and otherwise use the result, no?
>
> $ git checkout next
> $ git checkout master
> $ git rev-parse --symbolic-full-name @{
1 - 100 of 198 matches
Mail list logo
