All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j.sixt@viscovery.net>
To: Patrick Doyle <wpdster@gmail.com>
Cc: git <git@vger.kernel.org>
Subject: Re: yet another workflow question...
Date: Thu, 11 Oct 2007 16:37:57 +0200	[thread overview]
Message-ID: <470E3545.4060005@viscovery.net> (raw)
In-Reply-To: <e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com>

Patrick Doyle schrieb:
> I've been working on my project and I realize that I have 3-4 files
> modified with two orthogonal sets of changes.  (I didn't realize this
> until I said to myself -- "Self, I should really check in these files
> before I go too much further down this path".)  So I start "git
> diff"-ing the files and I find that most files have differences
> related to only one change or the other, but one file has differences
> related to both changes.
> 
> What do others do in this situation?
> a) Not allow themselves to get into this situation in the first place
> by careful planning?
> 
> b) Copy the file to "file.bothchanges", edit out one set of changes,
> commit that with one log message, edit back in the other set of
> changes, edit in the other set of changes, commit that with another
> log message?
> 
> c) Use some sort of automation to do option (b) for them?
> 
> d) Something else?

Use git-gui.

Stage the files relevant for the first change. In the file where you have an 
overlap with the second change, you can right-click in the diff pane and 
select "Stage Hunk for Commit" on the hunk relevant for the first change.[*]

Commit with a message.

Stage the remaining changes and commit again.

At this point, I usually check out HEAD~1, i.e. the state *without* the 
second change, and compile and test to make sure I have a bisectable history.

[*] Of course, this works only if the changes are not in the same hunk. If 
there are at least 3 unmodified lines between the changes, you can choose 
"Less context" until they are in separate hunks.

-- Hannes

  parent reply	other threads:[~2007-10-11 14:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-11 14:11 yet another workflow question Patrick Doyle
2007-10-11 14:18 ` David Kastrup
2007-10-11 14:44   ` Steffen Prohaska
2007-10-11 14:37 ` Johannes Sixt [this message]
2007-10-11 14:39 ` Wincent Colaiuta
2007-10-11 15:10 ` Andy Parkins
2007-10-11 17:28   ` Andreas Ericsson
2007-10-11 20:40   ` Jing Xue
2007-10-12  7:25     ` Andy Parkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=470E3545.4060005@viscovery.net \
    --to=j.sixt@viscovery.net \
    --cc=git@vger.kernel.org \
    --cc=wpdster@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.